From n21102008@gmail.com Sat Nov 1 18:06:58 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B880A3A6935; Sat, 1 Nov 2008 18:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.501 X-Spam-Level: ** X-Spam-Status: No, score=2.501 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQC9fM2dBVqh; Sat, 1 Nov 2008 18:06:58 -0700 (PDT) Received: from maildcarg4.dc-host.net.ar (maildcarg4.dc-host.net.ar [200.55.6.135]) by core3.amsl.com (Postfix) with ESMTP id 78DEF3A686C; Sat, 1 Nov 2008 18:06:58 -0700 (PDT) Received: from coloso ([200.122.92.50]) by maildcarg4.dc-host.net.ar (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0K9O00812LR51V70@maildcarg4.dc-host.net.ar>; Sat, 01 Nov 2008 22:06:41 -0300 (ART) Date: Sat, 01 Nov 2008 22:07:28 -0300 From: "n21102008@gmail.com" Subject: NOTEBOOKS DELL, TOSHIBA y HP SOLO POR HOY To: notebooks por hoy Message-id: <388-2200811021728569@coloso> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable SOLO POR HOY NOTEBOOKS con GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALLITO - CAPITAL = FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS EMail: n21102008@gmail=2Ecom CEL: 15-3197-5821 NOTEBOOKS CON DISPONIBILIDAD INMEDIATA DELL VOSTRO 1000 Procesador AMD Turion TL-60 2=2E0GHz Memoria 2GB DDR2 at 667MHz Disco Rigido 120GB SATA Hard Drive (5400RPM) Regrabadora de DVD+/-RW Pantalla 15=2E4 pulgadas WXGA Wireless WIFI Windows Vista Home en Espa=F1ol Color Negro Teclado en Espa=F1ol Precio: $2650 Toshiba Satellite M305D-S4829 Pantalla 14=2E1" Widescreen CPU AMD Turion 64 DUAL CORE X2 RM-70 2GHz x 2 NUCLEOS Memoria 4GB DDR2 Disco de 250GB Regrabadora de DVDs and CDs Built-in 802=2E11bgn wireless, Built-in webcam y microfono Precio: $3700 Hewlett Packard Pavilion dv6810us Procesador AMD Turion 64 X2 Dual-Core TL-60 2GHz Memoria 3GB (1x2GB, 1x1GB) Disco Rigidos 160GB SATA HD SuperMulti DVD Burner w/ LightScribe Placa de VIDEO nVIDIA GeForce Go 7150M Pantalla 15=2E4" 802=2E11b/g Wi-Fi Bluetooth WVHP Precio: $3200 From mext-bounces@ietf.org Sat Nov 1 21:10:14 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBD7E3A68C5; Sat, 1 Nov 2008 21:10:14 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F26D3A690B for ; Sat, 1 Nov 2008 21:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, 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 cSi6mg4ryNXv for ; Sat, 1 Nov 2008 21:10:12 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 80BA53A67B3 for ; Sat, 1 Nov 2008 21:10:12 -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=1225599011; x=1257135011; 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:=20Vijay=20Devarapalli=20,=0D=0A =20=20=20=20=20=20=20=20"Charles=20E.=20Perkins"=0D=0A=09 ,=0D=0A=20=20=20=20=20=20 =20=20"mext@ietf.org"=20|Date:=20Sat,=201 =20Nov=202008=2021:09:52=20-0700|Subject:=20RE:=20[MEXT] =20Issue=20#11:=20De-registration=20when=20returning=20ho me|Thread-Topic:=20[MEXT]=20Issue=20#11:=20De-registratio n=20when=20returning=20home|Thread-Index:=20Ackj9r1RcaVLg cTcSsa0GEklWWnH3AXtGQogAD1uWZw=3D|Message-ID:=20<057632CE 4CE10D45A1A3D6D19206C3A3D5AD8C38@NASANEXMB08.na.qualcomm. com>|References:=20<48E3C678.5060509@earthlink.net>,|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-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5421"=3B=20a=3D"11671615"; bh=w6SoBZDmdA9jcgWF716fbbqn5vjzL6b3uMCMklaus9g=; b=mLxcrJW+D7O9F7kFknxLOC7e/DkL8BtRSY2MnKnU/rMEvv7FyY0/0B79 mSxfgQkINlabP+wcU9AhNh3XnENzO+niU7mSUDcbCqGiuENQXTM+j+izY pLK3qTTtl4fJ0YlCJNlwtxlsjCJ/Wqxfz9ff0F8qL0XfgBEjSjMD+3ZhH 0=; X-IronPort-AV: E=McAfee;i="5300,2777,5421"; a="11671615" 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; 01 Nov 2008 21:10:11 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mA24AAUC025528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 1 Nov 2008 21:10:10 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mA24A8i8001335 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 1 Nov 2008 21:10:10 -0700 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhc03.na.qualcomm.com ([172.30.33.34]) with mapi; Sat, 1 Nov 2008 21:10:07 -0700 From: "Giaretta, Gerardo" To: Vijay Devarapalli , "Charles E. Perkins" , "mext@ietf.org" Date: Sat, 1 Nov 2008 21:09:52 -0700 Thread-Topic: [MEXT] Issue #11: De-registration when returning home Thread-Index: Ackj9r1RcaVLgcTcSsa0GEklWWnH3AXtGQogAD1uWZw= Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D5AD8C38@NASANEXMB08.na.qualcomm.com> References: <48E3C678.5060509@earthlink.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [MEXT] 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, this is fine to me Thanks Gerardo ________________________________________ From: mext-bounces@ietf.org [mext-bounces@ietf.org] On Behalf Of Vijay Devarapalli [vijay@wichorus.com] Sent: Friday, October 31, 2008 3:56 PM To: Charles E. Perkins; mext@ietf.org Subject: Re: [MEXT] Issue #11: De-registration when returning home Hi Charlie, In the previous discussions on this issue (July 2008), we had almost concluded on the following text. A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. 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 a de-registration Binding Update, it will not be able to send and receive packets using its home address from the home link. The home agent will continue to intercept all packets sent to the mobile's home address and tunnel to the previously registered care-of address. Only Sri had an objection to this text. He was objecting to the last two sentences. Until the mobile node sends a de-registration Binding Update, it will not be able to send and receive packets using its home address from the home link. The home agent will continue to intercept all packets sent to the mobile's home address and tunnel to the previously registered care-of address. For the last sentences, we can replace the text with what you proposed in your email. So the final text would be A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. 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. Is this acceptable? Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Charles E. Perkins > Sent: Wednesday, October 01, 2008 11:51 AM > To: mext@ietf.org > Subject: [MEXT] Issue #11: De-registration when returning home > > > Hello folks, > > Perhaps this issue is ready to be closed. > > I suggest we use the text offered by George > Tsirtsis, but with one additional change: > > > > OLD Text: > > 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). > The mobile > node SHOULD then send a Binding Update to its home agent, > to instruct > its home agent to no longer intercept or tunnel packets for it. > > > > George's Text: > > 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. > The mobile node SHOULD then send a Binding Update to its > home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. Until the mobile node sends a de-registration > Binding Update, > it will not be able to send and receive packets using its > home address > from the home link. The home agent will continue to intercept all > packets sent to the mobile's home address and tunnel to > the previously > registered care-of address. > > > > A slightly amended version of George's Text: > > 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. > The mobile node SHOULD then send a Binding Update to its > home agent, > to instruct its home agent to no longer intercept or tunnel packets > for it. Until the mobile node sends 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. > > ================================================== > > Regards, > Charlie P. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 1 21:14:19 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 792B73A6826; Sat, 1 Nov 2008 21:14:19 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54DD63A6826 for ; Sat, 1 Nov 2008 21:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.812 X-Spam-Level: X-Spam-Status: No, score=-103.812 tagged_above=-999 required=5 tests=[AWL=-1.212, 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 SbQAcMWepSQZ for ; Sat, 1 Nov 2008 21:14:17 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 567713A67B3 for ; Sat, 1 Nov 2008 21:14:17 -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=1225599256; x=1257135256; 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:=20Vijay=20Devarapalli=20,=0D=0A =20=20=20=20=20=20=20=20"Charles=20E.=20Perkins"=0D=0A=09 ,=0D=0A=20=20=20=20=20=20 =20=20Benjamin=20Lim=0D=0A=09|CC:=20"mext@ietf.org"=20|Date:=20Sat ,=201=20Nov=202008=2021:10:19=20-0700|Subject:=20RE:=20[M EXT]=20Issue=20#17:=20Multi-homed=20mobile=20node=20can =20cause=20routing=0D=0A=09loop=20between=20home=20agents |Thread-Topic:=20[MEXT]=20Issue=20#17:=20Multi-homed=20mo bile=20node=20can=20cause=20routing=0D=0A=09loop=20betwee n=20home=20agents|Thread-Index:=20Ackk6dl9GZJg9nlmTHiz1sR Kz2u5AwWw4WiwADzi7Zo=3D|Message-ID:=20<057632CE4CE10D45A1 A3D6D19206C3A3D5AD8C39@NASANEXMB08.na.qualcomm.com> |References:=20<48E55E5F.5040101@earthlink.net>,|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-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5421"=3B=20a=3D"11601844"; bh=9W56W9InMqg/q0pdfxQ/TeJtagZuRQCUwJSW4424rbc=; b=Cs2eg//FdRzt2R64unmLKDrTc2jSbksCYdqhVx32kH42NuL+dRCxtckg waYfKrDTCl8wf+j8oKwaenYn0I+dybOcGXR2DxMotgK3ClpY3S7pDs0RX AsIEJICydZUVyKwye9gdGzzVcHKgFHkfe1XtDR/thxrB6zyO8jAphKKuM 8=; X-IronPort-AV: E=McAfee;i="5100,188,5421"; a="11601844" 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; 01 Nov 2008 21:14:15 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mA24EFZE026423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 1 Nov 2008 21:14:15 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mA24EEdH013345 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 1 Nov 2008 21:14:14 -0700 Received: from nasanexhub05.na.qualcomm.com (129.46.134.219) by nasanexhc03.na.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.311.2; Sat, 1 Nov 2008 21:14:14 -0700 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Sat, 1 Nov 2008 21:14:13 -0700 From: "Giaretta, Gerardo" To: Vijay Devarapalli , "Charles E. Perkins" , Benjamin Lim Date: Sat, 1 Nov 2008 21:10:19 -0700 Thread-Topic: [MEXT] Issue #17: Multi-homed mobile node can cause routing loop between home agents Thread-Index: Ackk6dl9GZJg9nlmTHiz1sRKz2u5AwWw4WiwADzi7Zo= Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D5AD8C39@NASANEXMB08.na.qualcomm.com> References: <48E55E5F.5040101@earthlink.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, Charlie and all, I tend to agree with Raj that this does not seem a MIP6-specific issue or at least it does not require any MIP6-specific solution. While the way of creating the routing loop is specific to MIP6, in the sense that MIP6 signaling is used, the outcome of the attack may be just a flood of packets to the HA. How is this flooding of packets different from any other DoS/flooding? Does the HA anyway be equipped to drop packets in case of packets floods? The HA may just drop packets if they exceed a ceratin threshold and optionally delete the binding. This seems to be enough in my view considering that there is anyway a long trust relationship between the attacker (i.e. the MN) and the HA. What do you think? Gerardo ________________________________________ From: mext-bounces@ietf.org [mext-bounces@ietf.org] On Behalf Of Vijay Devarapalli [vijay@wichorus.com] Sent: Friday, October 31, 2008 4:15 PM To: Charles E. Perkins; Benjamin Lim Cc: mext@ietf.org Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can cause routing loop between home agents Hi Charlie, > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Charles E. Perkins > Sent: Thursday, October 02, 2008 4:51 PM > To: Benjamin Lim > Cc: mext@ietf.org > Subject: [MEXT] Issue #17: Multi-homed mobile node can cause > routing loop between home agents > > > Hello Benjamin, > > I have not seen any further discussion about this issue, > but I agree that the problem does exist. > > It might be possible to specify that the Home Agent should (or, > ?may?) use the RFC 2473 "Tunnel Encapsulation Limit Option". > to help avert the threat. Otherwise, the loop could persist for > an annoyingly long amount of time. It is also possible for the > home agent to enforce a policy by which a home address on > a network cannot be bound to a care-of address on the same > network, but in fact there may be cases where that would be > a valid binding. > > I hope that other people in the working group will > express an opinion about this. At minimum, we could > certainly include text within the Security Considerations > section. Recommending the use of the Tunnel Encapsulation Limit Option" in the security considerations section seems to be the best option to me. Here is some text. A malicious mobile node associated to multiple home agents could create a routing loop amongst the home agents. 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. To present this routing loop, it is recommended for the home agents to use the Tunnel Encapsulation Limit Option [RFC 2473], when tunneling packets for the mobile node. It would be good to recommend a default value for the "Tun Encap Lim" field, but I don't know what to recommend. How about '5'? This should be sufficient for any additional GTP, PMIPv6, HMIPv6 or FMIPv6 tunneling between the home agent and the mobile node. :) Vijay > > The existing discussion is documented at the following URL: > http://trac.tools.ietf.org/wg/mext/trac/ticket/17 > > 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 banking@americanexpress.com Sun Nov 2 01:49:00 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA803A68A7 for ; Sun, 2 Nov 2008 01:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -85.09 X-Spam-Level: X-Spam-Status: No, score=-85.09 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FORGED_MUA_OUTLOOK=3.116, FORGED_OUTLOOK_HTML=0.001, FORGED_OUTLOOK_TAGS=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SARE_FORGED_AMEX=3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKzpk2gqau6y for ; Sun, 2 Nov 2008 01:48:59 -0800 (PST) Received: from skilfab.com (server.skilfab.com [74.94.76.193]) by core3.amsl.com (Postfix) with ESMTP id A19613A6882 for ; Sun, 2 Nov 2008 01:48:59 -0800 (PST) Received: from User ([64.62.194.52]) by skilfab.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 2 Nov 2008 01:57:23 -0700 Reply-To: From: "American Express" Subject: Notification from American Express Date: Sun, 2 Nov 2008 03:58:29 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 02 Nov 2008 08:57:24.0523 (UTC) FILETIME=[0619FFB0:01C93CC9] X-TM-AS-Product-Ver: SMEX-7.5.0.1243-5.5.1027-16254.005 X-TM-AS-Result: Yes-36.347600-5.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No To: undisclosed-recipients:;

Dear American Express customer,


During our regualry scheduled accounts maintenance and verification procedures,
we have detected a slight error regarding your American Express Account.

This might be due to one of the following reasons:

1. A recent change in your personal information (i.e. address changing)
2. Submitting invalid information during the initial sign up process.
4. Multiple failed logins in your personal account.
3. An inabillity to accurately verify your selected option of payment due
    to an internal error within our system.

Please update and verify your information by clicking the following link:

Continue To American Express Online Update Form

*If you account information is not updated within 48 hours then your ability to access your account will be restricted.

Thank you,
American Express , Billing Department.


E-mail Security Information

E-mail intended for your account.
If you are concerned about the authenticity of this message, please click here or call the phone number on the back of your credit card. If you would like to learn more about e-mail security or want to report a suspicious e-mail, click here

Note: If you are concerned about clicking links in this e-mail, the American Express mentioned above can be accessed by typing https://www.americanexpress.com directly into your browser.


ABOUT THIS MESSAGE:
This service message was delivered to you as a American Express customer to provide you with account updates and information about your card benefits.

® 2008 American Express

From mext-bounces@ietf.org Sun Nov 2 02:16:34 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8861F3A6A3A; Sun, 2 Nov 2008 02:16:34 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8DF53A6872 for ; Sun, 2 Nov 2008 02:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.812 X-Spam-Level: X-Spam-Status: No, score=-4.812 tagged_above=-999 required=5 tests=[AWL=1.787, 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 8bk8lj5qjmYR for ; Sun, 2 Nov 2008 02:16:33 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 3D13B28C0FC for ; Sun, 2 Nov 2008 02:16:09 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (243.pool85-53-147.dynamic.orange.es [85.53.147.243])by smtp03.uc3m.es (Postfix) with ESMTP id B6A116AE9C2for ; Sun, 2 Nov 2008 11:06:39 +0100 (CET) Message-ID: <490D7BAE.3060003@it.uc3m.es> Date: Sun, 02 Nov 2008 11:06:38 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: mext X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-4.1576 TC:1F TRN:6 TV:5.5.1026(16254.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [MEXT] Draft agenda for ietf 73 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Please find a first version of the agenda at: http://www3.ietf.org/proceedings/08nov/agenda/mext.txt Let me know if something is missing or should be changed. Regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From apache@server.aprilvpshost.net Sun Nov 2 03:07:58 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9573A6A37 for ; Sun, 2 Nov 2008 03:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.674 X-Spam-Level: X-Spam-Status: No, score=-91.674 tagged_above=-999 required=5 tests=[AWL=-0.883, BAYES_50=0.001, DATE_IN_PAST_06_12=1.069, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RDNS_NONE=0.1, SUBJ_ALL_CAPS=2.077, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCKM4T1AHBxO for ; Sun, 2 Nov 2008 03:07:58 -0800 (PST) Received: from server.aprilvpshost.net (giat-bekerja.sabar.berdoa.agar.sukses2u.com [72.20.24.115]) by core3.amsl.com (Postfix) with ESMTP id E6BB13A6A22 for ; Sun, 2 Nov 2008 03:07:57 -0800 (PST) Received: from apache by server.aprilvpshost.net with local (Exim 4.67) (envelope-from ) id 1KwRPZ-0000yB-CT for nemo-archive@ietf.org; Sat, 01 Nov 2008 20:05:49 -0500 To: nemo-archive@ietf.org Subject: RESPOND IMMEDIATELY - REGARDING YOUR SME GRANT X-PHP-Script: 72.20.24.115/~april/mailers/3/index.php for 216.139.189.105 From: European Commission Reply-To: dominic.brett@live.co.uk MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit Message-Id: Date: Sat, 01 Nov 2008 20:05:49 -0500 New Page 1

European Commission
Enterprise and Industry DG
Communication and Information Unit/R4
BREY 13/ 092
B - 1049 Brussels (Belgium)

Released: October 2008.

We bring to your notice the decision by the board of trustees of The European Union to choose you as one of the final recipients of a cash grant/donation for your own personal, educational, and business development (SME funding).

To promote growth and creating new jobs in the European economy, we are giving out a yearly donation of £402,000.00 (four hundred and two thousand pounds) to 10 lucky recipients who have been selected from over 25,000 websites all over the globe, as funding/aid from the European Union, European Commission, and the United Nations in accordance with enabling acts of Parliament.

Please contact paying office (England)

Name: Dr. Dominic Brett
E-mail: dominic.brett@live.co.uk

Remember to quote your identification numbers. Find your identification numbers below:

BATCH NUMBER: EC-078419XN
UNIQUE NUMBER: SME48153

Note that these numbers fall within your location file.

Thank you and accept my congratulations once again!

Janet Williamson
Information Officer and Coordinator,
Scottish European Resources Network

========
+++++CONFIDENTIALITY NOTICE+++++
the information in this e-mail may be confidential and/or privileged. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this e-mail and its attachments, if any, or the information contained herein is prohibited. If you have received this e-mail in error, please immediately notify the sender by return e-mail and delete this e-mail from your computer system. Thank you.

From mext-bounces@ietf.org Mon Nov 3 00:45:06 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BB9C28C127; Mon, 3 Nov 2008 00:45:06 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2D54C3A698B; Mon, 3 Nov 2008 00:45: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: <20081103084502.2D54C3A698B@core3.amsl.com> Date: Mon, 3 Nov 2008 00:45:02 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mip6-radius-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --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 : RADIUS Mobile IPv6 Support Author(s) : A. Lior, et al. Filename : draft-ietf-mip6-radius-06.txt Pages : 48 Date : 2008-11-03 This document defines new attributes to facilitate Mobile IPv6 operations using RADIUS infrastructure. The operations include bootstrapping of information required by the Mobile Node and the interface between the Network Access Server, Home Agent and the RADIUS server used to assist MIP6 operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-06.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-mip6-radius-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03003715.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Mon Nov 3 02:26:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FDC83A6A27; Mon, 3 Nov 2008 02:26:48 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DB8E3A6407 for ; Mon, 3 Nov 2008 02:26:47 -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 GCNkum1dqgqp for ; Mon, 3 Nov 2008 02:26:46 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 742CC3A67B4 for ; Mon, 3 Nov 2008 02:26:46 -0800 (PST) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 8855220220E; Mon, 3 Nov 2008 12:26:43 +0200 (EET) Received: from inside.nomadiclab.com (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 240EE2021C8; Mon, 3 Nov 2008 12:26:43 +0200 (EET) Date: Mon, 3 Nov 2008 12:26:43 +0200 (EET) From: Teemu Rinta-aho To: mext@ietf.org Message-ID: MIME-Version: 1.0 X-Virus-Scanned: ClamAV using ClamSMTP Subject: [MEXT] A few findings on the binding revocation draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi all, here are some newcomer's findings on the binding revocation draft -01: 1) In Fig 2 and 3 there is a field "Cause" in BRA. Where is it defined in more detail? 2) In 9.1.1. it is stated that "The Global (G) bit MUST be set and..." without any conditions. However, in the next bullet, it is stated that "Whenever the Global (G) bit is set", implying that it does not always need to be set. These texts are controversial and should be fixed. Some typos found: 3.4.3: "LMA may only supports IPv4" -> "LMA may only support IPv4" 8.2: "the home SHOULD examine" -> "the home agent SHOULD examine" "the home agent delete" -> "the home agent deletes" 9.1.1: "anchor send a" -> "anchor sends a" "LMA MUST sends a" -> "LMA MUST send a" Best regards, Teemu Rinta-aho -- Teemu Rinta-aho Tel: +358 9 299 3078 NomadicLab, Ericsson Research Fax: +358 9 299 3535 Oy L M Ericsson Ab Mobile: +358 40 562 3066 FIN-02420 Jorvas, Finland E-mail: teemu.rinta-aho@nomadiclab.com _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 3 05:01:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A404328C154; Mon, 3 Nov 2008 05:01:35 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CAC428C11C for ; Mon, 3 Nov 2008 05:01:34 -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 zOHvmkgYiFM4 for ; Mon, 3 Nov 2008 05:01:33 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 2B63628C11B for ; Mon, 3 Nov 2008 05:00:59 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so870350eyd.31 for ; Mon, 03 Nov 2008 05:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=EocXLUSebsfE6Dd0s+9bbeoRp/4VO2mZ9ihMnMcGstA=; b=bDJsX5bPB18FmEIgFuTJ5AcofrOsmTBg+vRqpEKZ7ibo1AOiFSbdSIYpJadV8/Lr1T PfeBN3tJcdrqRr9pxEANtpdaDTkhGB4hVeQFSnJRyDkzs75e/zX9nOIoYLG61QQ8php6 MW5mgwm10EHc3sI3sb668QMO4p3Z7w8/1e1iM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:cc:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id:from; b=FAfmMPx04Yd/juzCC28z4ywbyWsK7DjgPeieT5CPZFbrip18BEfxiMNw3J1ryrZWEP 80ATyq6z/sPo2YiQVpTQzKsZrU9M2EkteaPvHZhUTN/A1FhXILbS89SI5wWDdp+r11gW eSnAheJzudn0OGzsyjV/GTxSnpKMaYhJCmd8g= Received: by 10.210.139.15 with SMTP id m15mr43609ebd.182.1225717256902; Mon, 03 Nov 2008 05:00:56 -0800 (PST) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id t2sm14271602gve.5.2008.11.03.05.00.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 Nov 2008 05:00:55 -0800 (PST) To: "Vijay Devarapalli" Date: Mon, 3 Nov 2008 14:00:49 +0100 User-Agent: KMail/1.9.10 References: <490A12E9.60907@hp.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200811031400.50598.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: Christian.Kaas-Petersen@tietoenator.com, mext@ietf.org Subject: Re: [MEXT] Home Agent Switch Message (RFC 5142) and DSMIP X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay, > >>> Wouldn't a new DSMIP companion document just define a new > >>> mobility option to use with HA Switch and how it should be used? > >>> I wouldn't think we'd revise 5142 to add DSMIP-specific content > >>> to it. > >> > >> That will result in two documents for the same purpose. We should > >> avoid that. I don't see any issue with 5142bis talking about the > >> IPv4 home agent address. > > > > I see a possible issue with having both plain-MIPv6 and DSMIPv6 > > support in the same RFC, e.g. 5142bis. > > > > There will be MIPv6 only systems with HA switch functionality but > > without DSMIP capability. Can such systems claim conformance to > > 5142bis? > > We can add a mobility option for the carrying the HA IPv4 address, > not modify the message itself. Existing implementations would become > conformant to 5142bis when they get updated to support the new > mobility option. This is normal, though. But I don't see why a MIPv6 only systems would need to support the new (IPv4) option when it doesn't support DSMIPv6... I think we should define the new option in a new document. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 3 07:24:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6645928C2DF; Mon, 3 Nov 2008 07:24:23 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04B028C254 for ; Mon, 3 Nov 2008 07:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 JHAGnsqXSCxc for ; Mon, 3 Nov 2008 07:24:21 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 4B92A3A6BBC for ; Mon, 3 Nov 2008 07:20:45 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1Kx1EP-0007Lb-8M; Tue, 04 Nov 2008 02:20:41 +1100 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Tue, 04 Nov 2008 02:20:38 +1100 From: Hesham Soliman To: "mext@ietf.org" Message-ID: Thread-Topic: New Version Notification for draft-ietf-mext-nemo-v4traversal-06 Thread-Index: Ack9x7mxle0Dqmy0RU28NG8+40KK4w== In-Reply-To: <20081103151919.7F14D3A6BE7@core3.amsl.com> Mime-version: 1.0 Cc: Jari Arkko Subject: [MEXT] FW: New Version Notification for draft-ietf-mext-nemo-v4traversal-06 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org FYI ------ Forwarded Message > From: IETF I-D Submission Tool > Date: Mon, 3 Nov 2008 07:19:19 -0800 (PST) > To: Hesham Soliman > Cc: Hesham Soliman > Subject: New Version Notification for draft-ietf-mext-nemo-v4traversal-06 > > > A new version of I-D, draft-ietf-mext-nemo-v4traversal-06.txt has been > successfuly submitted by Hesham Soliman and posted to the IETF repository. > > Filename: draft-ietf-mext-nemo-v4traversal > Revision: 06 > Title: Mobile IPv6 Support for Dual Stack Hosts and Routers > Creation_date: 2008-11-03 > WG ID: mext > Number_of_pages: 50 > > Abstract: > The current Mobile IPv6 and NEMO specifications support IPv6 only. > This specification extends those standards to allow the registration > of IPv4 addresses and prefixes, respectively, and the transport of > both IPv4 and IPv6 packets over the tunnel to the home agent. This > specification also allows the Mobile Node to roam over both IPv6 and > IPv4, including the case where Network Address Translation is present > on the path between the mobile node and its home agent. > > > > The IETF Secretariat. > > ------ End of Forwarded Message _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 3 07:25:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C3CF28C2BD; Mon, 3 Nov 2008 07:25:31 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03DA728C2BA for ; Mon, 3 Nov 2008 07:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.465, 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 GNmRWxUGaA28 for ; Mon, 3 Nov 2008 07:25:26 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 36DF628C2D0 for ; Mon, 3 Nov 2008 07:24:17 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9R003PKK4EF2@usaga04-in.huawei.com> for mext@ietf.org; Mon, 03 Nov 2008 09:24:15 -0600 (CST) Received: from X24512z ([10.124.12.63]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K9R00BG4K4CGM@usaga04-in.huawei.com> for mext@ietf.org; Mon, 03 Nov 2008 09:24:14 -0600 (CST) Date: Mon, 03 Nov 2008 09:24:11 -0600 From: Frank Xia To: Avi Lior , jouni.korhonen@teliasonera.com Message-id: <005a01c93dc8$3a0ca2f0$3f0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <20081103084502.2D54C3A698B@core3.amsl.com> Cc: mext@ietf.org Subject: Re: [MEXT] I-D Action:draft-ietf-mip6-radius-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi folks Please check if the draft supports dual stack MIPv6. The corresponding Dimameter draft can be referred to http://tools.ietf.org/id/draft-ietf-dime-mip6-split-13.txt. BR Frank ----- Original Message ----- From: To: Cc: Sent: Monday, November 03, 2008 2:45 AM Subject: [MEXT] I-D Action:draft-ietf-mip6-radius-06.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 : RADIUS Mobile IPv6 Support > Author(s) : A. Lior, et al. > Filename : draft-ietf-mip6-radius-06.txt > Pages : 48 > Date : 2008-11-03 > > This document defines new attributes to facilitate Mobile IPv6 > operations using RADIUS infrastructure. The operations include > bootstrapping of information required by the Mobile Node and the > interface between the Network Access Server, Home Agent and the > RADIUS server used to assist MIP6 operations. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 3 07:30:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80D4228C21B; Mon, 3 Nov 2008 07:30:03 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5D0773A6BE5; Mon, 3 Nov 2008 07:30: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: <20081103153001.5D0773A6BE5@core3.amsl.com> Date: Mon, 3 Nov 2008 07:30:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --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 : Mobile IPv6 Support for Dual Stack Hosts and Routers Author(s) : H. Soliman Filename : draft-ietf-mext-nemo-v4traversal-06.txt Pages : 50 Date : 2008-11-03 The current Mobile IPv6 and NEMO specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-06.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-v4traversal-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03071919.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Mon Nov 3 09:03:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE58C3A69E0; Mon, 3 Nov 2008 09:03:12 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53A493A69E0 for ; Mon, 3 Nov 2008 09:03:11 -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 tbceROpDqG8E for ; Mon, 3 Nov 2008 09:03:10 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 427393A686A for ; Mon, 3 Nov 2008 09:03:10 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mA3H2tD26327; Mon, 3 Nov 2008 17:02:55 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Nov 2008 11:02:46 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] A few findings on the binding revocation draft Thread-Index: Ack9nrMNVQXy1pFJSiaO8dfwuTmx0gANKP3g References: From: "Ahmad Muhanna" To: "Teemu Rinta-aho" , Subject: Re: [MEXT] A few findings on the binding revocation draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Teemu, Thanks for the comments. Please see inline. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Teemu Rinta-aho > Sent: Monday, November 03, 2008 4:27 AM > To: mext@ietf.org > Subject: [MEXT] A few findings on the binding revocation draft > > Hi all, > > here are some newcomer's findings on the binding revocation draft -01: > > 1) In Fig 2 and 3 there is a field "Cause" in BRA. > Where is it defined in more detail? [Ahmad] Thanks. This needs to be corrected and replaced by "Status" > > 2) In 9.1.1. it is stated that "The Global (G) bit MUST > be set and..." without any conditions. However, in the > next bullet, it is stated that "Whenever the Global (G) > bit is set", implying that it does not always need to > be set. These texts are controversial and should be fixed. [Ahmad] I do not think that there is any contradiction in there. In the first bullet, if you continue reading you find the following: ".... to request the mobile access gateway to remove all Per-Peer bindings that are registered with the LMA and hosted at this MAG." We could rearrange the bullet to read as follows: In case of revoking all Per-Peer bindings, the Global (G) bit MUST be set and the Revocation Trigger MUST contain a value of "Per-Peer Policy" in the Binding Revocation Indication to request the mobile access gateway to remove all Per- Peer bindings that are registered with the LMA and hosted at this MAG. Would that makes it clearer? > > Some typos found: > > 3.4.3: "LMA may only supports IPv4" -> "LMA may only support IPv4" > > 8.2: "the home SHOULD examine" -> "the home agent SHOULD examine" > > "the home agent delete" -> "the home agent deletes" > > 9.1.1: "anchor send a" -> "anchor sends a" > > "LMA MUST sends a" -> "LMA MUST send a" [Ahmad] Thanks. Will take care of them. > > > Best regards, > Teemu Rinta-aho > > -- > Teemu Rinta-aho Tel: +358 9 299 3078 > NomadicLab, Ericsson Research Fax: +358 9 299 3535 > Oy L M Ericsson Ab Mobile: +358 40 562 3066 > FIN-02420 Jorvas, Finland E-mail: > teemu.rinta-aho@nomadiclab.com > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 3 09:57:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D26033A67B0; Mon, 3 Nov 2008 09:57:40 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E73433A6782 for ; Mon, 3 Nov 2008 09:57:39 -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 Y+sZKVy6DCPq for ; Mon, 3 Nov 2008 09:57:39 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 1F93F3A67B0 for ; Mon, 3 Nov 2008 09:57:39 -0800 (PST) Received: from [192.168.1.113] ([99.138.86.46]) by outbound.mse15.exchange.ms with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Nov 2008 12:57:33 -0500 Message-ID: <490F3B88.9030102@wichorus.com> Date: Mon, 03 Nov 2008 09:57:28 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Julien Laganier References: <490A12E9.60907@hp.com> <200811031400.50598.julien.laganier.IETF@googlemail.com> In-Reply-To: <200811031400.50598.julien.laganier.IETF@googlemail.com> X-OriginalArrivalTime: 03 Nov 2008 17:57:33.0413 (UTC) FILETIME=[A5B7E950:01C93DDD] Cc: Christian.Kaas-Petersen@tietoenator.com, mext@ietf.org Subject: Re: [MEXT] Home Agent Switch Message (RFC 5142) and DSMIP X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien Laganier wrote: > Vijay, > >>>>> Wouldn't a new DSMIP companion document just define a new >>>>> mobility option to use with HA Switch and how it should be used? >>>>> I wouldn't think we'd revise 5142 to add DSMIP-specific content >>>>> to it. >>>> That will result in two documents for the same purpose. We should >>>> avoid that. I don't see any issue with 5142bis talking about the >>>> IPv4 home agent address. >>> I see a possible issue with having both plain-MIPv6 and DSMIPv6 >>> support in the same RFC, e.g. 5142bis. >>> >>> There will be MIPv6 only systems with HA switch functionality but >>> without DSMIP capability. Can such systems claim conformance to >>> 5142bis? >> We can add a mobility option for the carrying the HA IPv4 address, >> not modify the message itself. Existing implementations would become >> conformant to 5142bis when they get updated to support the new >> mobility option. This is normal, though. > > But I don't see why a MIPv6 only systems would need to support the new > (IPv4) option when it doesn't support DSMIPv6... 5142bis would obviously say that this new mobility option, that carries the IPv4 address of the home agent, MUST be implemented if the home agent supports DS-MIPv6. So if you are planning on a MIPv6 HA implementation without DS-MIPv6 extensions, you can skip implementing the new mobility option in 5142bis. > I think we should define the new option in a new document. I disagree. Vijay > > --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 3 10:04:11 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFB7F28C0FF; Mon, 3 Nov 2008 10:04:10 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479E428C0F4 for ; Mon, 3 Nov 2008 10:04:09 -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 AnX+M++ecKqp for ; Mon, 3 Nov 2008 10:04:08 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 7A89A3A6BF6 for ; Mon, 3 Nov 2008 10:04:07 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so948012eyd.31 for ; Mon, 03 Nov 2008 10:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=8IWEDq1+hrZxEg/qLxF2wY4SNHJtIN6ijj9ngv1WlhM=; b=plScox4bBIm7lbhrcvJPnXg365EwqSjzmD+R2gWa+6R5Y56SM8wVRKrOKhWpjRdHO1 3Dp7v26sFSXm7XX+x6r5qC+B65gKjDyep+l5R9TYP4VGDAb4KAgCwPWj9w0CKbtms9wM W0cyhOdJCELlYsCxjk6RXmizRNXrOmJmbCqc0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:cc:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id:from; b=By8xnVih6m31opx8Vgm9JvpFwhn5xu5rBYqtHmDVN7wLrGCo0tNrmh80AB4AKlThRl MT5AaQk6qJUBYb8CbEIBTJFxJPTRze75PtiiglXHSsqNbUjnzh4GeHg0PVQR5klSJbPx OXdo3AUpvljtbwMOjpoL9iPVnLeGtIAqanPDU= Received: by 10.210.124.8 with SMTP id w8mr452822ebc.92.1225735443941; Mon, 03 Nov 2008 10:04:03 -0800 (PST) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id p10sm14956477gvf.7.2008.11.03.10.04.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 Nov 2008 10:04:02 -0800 (PST) To: Vijay Devarapalli Date: Mon, 3 Nov 2008 19:04:00 +0100 User-Agent: KMail/1.9.10 References: <200811031400.50598.julien.laganier.IETF@googlemail.com> <490F3B88.9030102@wichorus.com> In-Reply-To: <490F3B88.9030102@wichorus.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200811031904.00824.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: Christian.Kaas-Petersen@tietoenator.com, mext@ietf.org Subject: Re: [MEXT] Home Agent Switch Message (RFC 5142) and DSMIP X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Monday 03 November 2008, Vijay Devarapalli wrote: > Julien Laganier wrote: > > Vijay, > > > >>>>> Wouldn't a new DSMIP companion document just define a new > >>>>> mobility option to use with HA Switch and how it should be > >>>>> used? I wouldn't think we'd revise 5142 to add DSMIP-specific > >>>>> content to it. > >>>> > >>>> That will result in two documents for the same purpose. We > >>>> should avoid that. I don't see any issue with 5142bis talking > >>>> about the IPv4 home agent address. > >>> > >>> I see a possible issue with having both plain-MIPv6 and DSMIPv6 > >>> support in the same RFC, e.g. 5142bis. > >>> > >>> There will be MIPv6 only systems with HA switch functionality but > >>> without DSMIP capability. Can such systems claim conformance to > >>> 5142bis? > >> > >> We can add a mobility option for the carrying the HA IPv4 address, > >> not modify the message itself. Existing implementations would > >> become conformant to 5142bis when they get updated to support the > >> new mobility option. This is normal, though. > > > > But I don't see why a MIPv6 only systems would need to support the > > new (IPv4) option when it doesn't support DSMIPv6... > > 5142bis would obviously say that this new mobility option, that > carries the IPv4 address of the home agent, MUST be implemented if > the home agent supports DS-MIPv6. So if you are planning on a MIPv6 > HA implementation without DS-MIPv6 extensions, you can skip > implementing the new mobility option in 5142bis. That wasn't obvious to me. The approach is fine w/ me. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 3 10:30:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84E2128C1DC; Mon, 3 Nov 2008 10:30:05 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9159E3A6BE4; Mon, 3 Nov 2008 10:30: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: <20081103183001.9159E3A6BE4@core3.amsl.com> Date: Mon, 3 Nov 2008 10:30:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --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-01.txt Pages : 13 Date : 2008-11-03 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-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-nemo-pd-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03102732.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Mon Nov 3 11:15:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E507F28C211; Mon, 3 Nov 2008 11:15:04 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D678F3A696C; Mon, 3 Nov 2008 11: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: <20081103191501.D678F3A696C@core3.amsl.com> Date: Mon, 3 Nov 2008 11:15:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-10.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --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-10.txt Pages : 41 Date : 2008-11-03 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-10.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-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03111253.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Mon Nov 3 12:22:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A783428C0FC; Mon, 3 Nov 2008 12:22:54 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1AFD3A6A7D for ; Mon, 3 Nov 2008 12:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.955 X-Spam-Level: X-Spam-Status: No, score=-0.955 tagged_above=-999 required=5 tests=[AWL=1.645, 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 SUN7UmqTjv7Z for ; Mon, 3 Nov 2008 12:22:50 -0800 (PST) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 3BF8B3A69C3 for ; Mon, 3 Nov 2008 12:22:50 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Kx5wg-00011Q-IW for mext@ietf.org; Mon, 03 Nov 2008 21:22:43 +0100 X-Hashcash: 1:20:081103:mext@ietf.org::y0/fZ5dNBmO9lRDD:0000DG8i From: arno@natisbad.org (Arnaud Ebalard) To: mext@ietf.org References: <20081102223002.210293A69EB@core3.amsl.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:081103:internet-drafts@ietf.org::Xg1jOutlpwvV/Eq+:00000000000000000000000000000000000004fWt X-Hashcash: 1:20:081103:i-d-announce@ietf.org::Wip9l8G8B8JRuDnG:0000000000000000000000000000000000000000ETnD X-Hashcash: 1:20:081103:mip6@ietf.org::EjS7roLdI5yEeL5t:0000GUZE Date: Mon, 03 Nov 2008 21:20:57 +0100 In-Reply-To: <20081102223002.210293A69EB@core3.amsl.com> (Internet-Drafts@ietf.org's message of "Sun, 2 Nov 2008 14:30:02 -0800 (PST)") Message-ID: <87iqr4ims6.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Subject: Re: [MEXT] [Mip6] I-D Action:draft-ietf-mip6-whyauthdataoption-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Some typos, while reading the document. Some questions too. Internet-Drafts@ietf.org writes: > 2. Introduction > > Mobile IPv6 relies on the IPsec Security Association between the > Mobile Node (MN) and the Home Agent (HA) for authentication of the MN > to its HA before a binding cache can be created at the HA. An > alternate mechanism that does not rely on the existence of the IPsec > SA between the MN and HA for authenticating the MN is needed in > certain deployment environments. This document captures the reasons > that were outlined, and explains why such a mechanism was considered > essential to ensure the applicability of MIP6 as a protocol for wider > deployment. It was noted that the alternate solution does not imply > that the IPsec based solution would be deprecated. It simply meant > that in certain deployment scenarios there was a need for supporting > MIP6 without an IPsec SA between the MN and HA. So the alternate > solution would be in addition to the IPsec based mechanism specified > in the base RFCs, RFC 3775 [RFC3775], RFC 3776 [RFC3776] and RFC 4877 > [RFC4877]. It was noted that some of the challenges of deploying > MIP6 in certain types of networks arose from the dependence on IKE > which did not integrate will with a AAA backend infrastructure. ^^^^ well > [snip] > > 3. Background > > Mobile IPv6 signaling involves several messages. These include: > > o The Binding update/Binding ACK between the mobile node and the Binding Update/Binding Ack > home agent. > > o The route optimization signaling messages which include HoTI/Hot, HoT ^^^ > [snip] > > 4. Applicability Statement > > The authentication option specified in the Authentication Protocol > for MIP6 [RFC4285] provides a solution for MIP6 deployment in > environments which an operator may not require IPsec based security > for the signaling. The reasons for an operator choosing to deploy > MIP6 without mandating IPsec based security for signaling messages > between the MN and HA could be many. Some of these are for example: > > 1. Operators deploying MIP6 in cellular networks may consider IPsec > and IKEv2 as adding overhead to the limited bandwidth over the > air interface. The overhead here is in terms of the bytes that > IPsec and IKEv2 introduce to the signaling. > > 2. Operators may consider the number of messages between the MN and > HA that are required to establish the IPsec SA as too many. The > number of transactions chew into the capacity of limited > bandwidth air interfaces when MIP6 is used in such environments. > It also adds additional latency to the establishment of the > binding. > > 3. In many deployments the authentication credentials already exist > in a AAA server. These credentials are used for authenticating a > user and authorizing network access. The same credentials and > security parameters can be reused for MIP6 security as well. > > 4. Dynamic assignment of home agents is needed in certain > deployments to minmize the latency of the backhaul. This is done ^^^^^^^ minimize > by allocating an HA in a visited network for example. Requiring > IPsec SAs with home agents that are dynamically assigned is an > overhead especially when the HA is in a visited network. > > 5. Signaling messages between the MN and HA may be in certain > deployments over secure link-layers. The lower layers provide > ciphering and security for the messages and hence the need for > IPsec to do the same for MIP6 messages does not exist. > > One such example of networks that have such characteristics are cdma > networks as defined in the 3GPP2 X.S0011-002-D [3GPP2 X.S0011-002-D] > specification. Mobile WiMAX (Worldwide interoperability for > Microwave Access) which is based on IEEE 802.16e also specifies in > the network architecture the use of MIP6, with the default security > for signaling being the authentication protocol (RFC4285). The WiMAX > network architecture specifications are available at: [WiMAX-NWG]. The pointer provided in the reference section gives me a 404. As I am not familiar with the document, can you just tell me if/how a MN moving from a WiMAX link to another link (ethernet, wifi, ...) can protect its data traffic to deal with the fact that previous point 5 does not hold anymore. Or is it just not expected, and the MN is stuck in some kind of closed domain (w/ secure link layer)? > 5. Justification for the use of the authentication option > > The following two sections provide the reasoning for standardizing > the authentication option based registration process for Mobile IPv6. > Section 5.1 provides the key arguments for the use of authentication > option. Section 5.2 provides further explanation and additional > motivations for the authentication option. > > 5.1. Motivation for use of authentication option in cdma2000 wireless > networks > > cdma2000 networks deployed and operational today use Mobile IPv4 for > IP mobility. Operators have gained a significant amount of > operational experience in the process of deploying and operating > these networks. 3GPP2 has specified Mobile IPv6 in Revision D of the > 3GPP2 X.S0011-002-D [3GPP2 X.S0011-002-D] specification (which > specifies the packet data architecture). The following are the > deployment constraints that existing CDMA networks have to deal with > when deploying Mobility service based on IPv6: > > o Operators intend to leverage the Mobile IPv4 deployment and > operational experience by ensuring that Mobile IPv6 has a similar > deployment and operating model. > > o Operators will have two parallel networks, one that offers IPv4 > mobility with MIP4 and another providing IPv6 mobility using MIP6. > > o The same backend subscriber profile database, security keys etc. > are intended to be used for both Mobile IPv4 and, Mobile IPv6 > service. However from a security standpoint, the reuse of the > same keys with multiple algorithms/protocols is a bad idea. > > o The same user configuration information, i.e the identity and keys > associated with a user will be used for IP mobility service in > IPv4 and/or IPv6 networks. The only security association that is > preconfigured is a shared secret between the mobile node and the > home-AAA server. This was in contrast with an earlier version of > the Mobile IPv6 model which required an IPsec SA between the MN > and HA. At the time of this writing the IKEV2 based solution for ^^^^^ IKEv2 > establishing an IPsec SA [RFC4877] was not available. IKEv2 does > enable integration with a a AAA backend. ^^^^^ > > o At the time of specifying the authentication protocol, the Mobile > IPv6 specification did not support the dynamic assignment of home > agent and home address. However work done in the MIP6 working > group on bootstrapping of Mobile IPv6 as specified in [RFC5026] > and MIP6-bootstrapping for the Integrated Scenario > [I-D.ietf-mip6-bootstrapping-integrated-dhc] addresses this > > > > Patil & Dommety Expires May 6, 2009 [Page 7] > > Internet-Draft Why authdata option for MIP6 November 2008 > > > deficiency. The mechanism defined in Authentication protocol for > Mobile IPv6 [RFC4285] is capable of handling authentication even > in the case of dynamic assignments (and is similar to what is used > in current MIPv4 deployments). > > Consequently, MIP6 as specified at the time the authentication > protocol was being specifid did not satisfy many of the deployment > requirements. The Authentication protocol for MIP6 [RFC4285] along > with the MN Identifier option for MIP6 [RFC4283] are enabling the > deployment of Mobile IPv6 in a manner that is similar to what is > deployed in cdma2000 networks today. This authentication model is > very similar to the one adopted by the MIPv4 WG. This is explained > in detail in the 3GPP2 X.S0011-002-D [3GPP2 X.S0011-002-D] > specification. > > The earlier MIP6 deployment model which requires an IPsec SA which is > either configured manually or established using IKE does not have > synergy with the deployment models of 3GPP2 or WiMAX networks. This > issue has however been alleviated with the publication of RFC4877 > which enables the establishment of an IPsec SA using IKEv2 and is > also able to integrate with the backend AAA infrastrucuture that is > responsible for the authentication of the MN in 3GPP2 and WiMAX > networks. > > 5.2. Additional arguments for the use of Authentication option > > The use of IPsec for performing Registration with a home agent is not > always an optimal solution. While it is true that IPsec is an > integral part of the IPv6 stack, it is still a considerable overhead > from a deployment perspective of using IPsec as the security > mechanism for the signaling messages between the MN and HA. This > statement is a result of experience gained from deployment of Mobile > IPv4. Was IPsec the issue or IPsec in NAT environments? Can you be more specific on that point? > MIP4 does not rely on IPsec for securing the Registration > signaling messages. > > Deployment of Mobile IPv6 on a large scale is possible only when the > protocol is flexible for being adapted to various scenarios. The > scenario being considered is the deployment in cdma2000 net- works or ^^^^^^^^^^ > WiMAX networks. cdma2000 networks are currently deployed in many > countries today and WiMAX deployments are beginning. The packet data > network architecture of cdma2000 [3GPP2 X.S0011-002-D] includes a > MIP4 foreign agent/Home agent and a Radius based AAA infrastrucutre > for authentication, authorization and accounting purposes. The AAA > infrastructure provides the authentication capability in the case of > Mobile IPv4. > > Typically, the Mobile Node shares a security association with the > AAA-Home entity. This is the preferred mode of operation over having > > > > Patil & Dommety Expires May 6, 2009 [Page 8] > > Internet-Draft Why authdata option for MIP6 November 2008 > > > a shared secret between the MN and HA because the AAA-Home entity > provides a central location for provisioning and administering the > shared secrets for a large number of mobiles (millions). This mode > of operation also makes dynamic home address and dynamic home agent > assignment easier. A similar approach is needed for the deployment > of Mobile IPv6 in these networks. There is no practical mechanism to > use IPsec directly with the AAA infrastructure with out the use of ^^^^^^^^ > IKE or some other mechanism that enables the establishment of the > IPsec SA between the MN and HA. > > Mobile IPv6 as specified in RFC3775 and RFC3776 is based on a very refs, i.e. [RFC3775] > specific model for deployment. It anticipates the Mobile nodes > having a static home IPv6 address and a designated home agent. This > is not practical in most deployment scenarios being considered. An > IPsec SA is expected to be created, either via manual keying or > established dynamically by using IKE or IKEv2. These assumptions do > not necessarily fit in very well for the deployment model envisioned > in cdma2000 or WiMAX networks. These limitations have however been > overcome as a result of the bootstrapping specifications as per > [RFC5026] and MIP6-bootstrapping for the Integrated Scenario > [I-D.ietf-mip6-bootstrapping-integrated-dhc] > > cdma2000 and WiMAX networks would prefer to allocate home addresses > to MNs on a dynamic basis. The advantage of doing so is the fact > that the HA can be assigned on a link that is close to the MNs point > of attachment. While route-optimization negates the benefit of > having a home-agent on a link close to the MN, it cannot be always > guaranteed that the MN and CN will use or support route optimization. > There may also be instances where the operator prefers to not allow > route optimization for various reasons such as accounting aggregation > or enforcing service contracts. In such cases an HA that is close to > the MNs point of attachment reduces the issues of latency etc. of > forward and reverse tunnelling of packets between the MN and HA. > > cdma2000 networks that are operational today have large numbers of > subscribers who are authenticated via the AAA infrastrucure. > Deployment of Mobile IPv6 should leverage the existing AAA > infrastructure. The security model needed in these networks is an SA > between the MN and AAA-Home entity. This is the primary security > association that should be used for authenticating and authorizing > users to utilize MIPv6 service. This SA is then used for > establishing session keys between the MN and the dynamically assigned > HA for authenticating subsequent binding updates and binding > acknowledgements between them. Establishing an IPsec SA between the > MN and HA using AAA infrastrucure was not specified for Mobile IPv6 > at the time the Authentication protocol was being specified. RFC3776 > explains how IKE is used for establishing the SA between the MN and > HA. [RFC4877] has been published subsequently and hence the issue of > > > > Patil & Dommety Expires May 6, 2009 [Page 9] > > Internet-Draft Why authdata option for MIP6 November 2008 > > > establishing an IPsec SA dynamically between the MN and HA no longer > exists. cdma2000 network operators would prefer to assign home > addresses to the MN on a dynamic basis and do this preferably using > the AAA infrastrucutre which contains subscriber profile and > capability information. This was not possible prior to the > specification of the bootstrapping mechanism in [RFC5026]. > > A large subset of MNs in cdma2000 networks do not have IKE > capability. As a result the use of RFC3776 for setting up the MN-HA > IPsec SA is not an option. It should also be noted that IKE requires > several transactions before it is able to establish the IPsec SA. > [RFC4877] specifies the establishment of an IPsec SA between the MN > and HA using IKEv2. It is possible that not all MNs in a deployment > will support IKEv2 and hence an alternative mechanism provides the > needed flexibility. > > cdma2000 network operators are extremely conscious in terms of the > number of messages sent and received over the air-interface for > signaling. The overhead associated with sending/receiving a large > number of signaling messages over the air interface has a direct > impact on the overall capacity and cost for the operator. > Optimization of the number of messages needed for using a service > like Mobile IPv6 is of great concern. As a result the use of IKE for > Mobile IPv6 deployment is considered as being suboptimal in certain > network architectures and deployment scenarios from the perspective > of message overhead. > > Another downside of IKE for setting up the IPsec SA between the MN > and HA is that IKE does not integrate very well with the Radius based > AAA back-end. Since operators rely on the AAA infrastrucure to > provision subscribers as well as define profiles, keys etc. in the > AAA-Home, there is no getting away from the use of AAA in cdma2000 > networks. IKEv2 does address this problem. However from a timeline > perspective the availability of IKEv2 specifications for Mobile IPv6 > Operation with IKEv2 and the revised IPsec Architecture [RFC4877] and > implementations did not meet the need of operators that were relying > on 3GPP2 specifications. With the specification of IKEv2 and > publication of RFC4877 the integration with AAA backends is no longer > an issue. Is it just me or the same arguments are repeated multiple times? > In summary the model of Mobile IPv6 deployment which mandated the > existence of an IPsec SA between the MN and HA, as specified in RFCs > 3775 and 3776, was too rigid and did not meet the requirements of > operators building networks based on the cdma2000 [3GPP2 > X.S0011-002-D] specifications. To address this shortcoming, the > authentication protocol [RFC4285] was specified. > > > > > > Patil & Dommety Expires May 6, 2009 [Page 10] > > Internet-Draft Why authdata option for MIP6 November 2008 > > > 6. Application of Mobile IPv6 in CDMA Networks I did not read that part, i.e. no comments. > 7. Limitations of the Authentication Protocol option > > While the authentication protocol as specified in [RFC4285] provides > Mobile IPv6 [RFC3775] deployments a certain degree of flexibility it > does have a few disadvantages as well. These are: > > (1) The route optimization feature specified in RFC3775 requires a > secure transport (IPsec/ESP mode) between the MN and HA. In > cases where the authentication protocol (RFC4285) is used as the > means for securing the MIP6 signaling between the MN and HA, > route optimization should be switched off unless the security of > the signaling between the MN and HA can be guaranteed via other > means (such as link layer security in the case of 3GPP2 > networks). > > (2) The MIP6 protocol is responsible for the security of the > signaling messages as opposed to relying on IPsec for providing > the security. > > (3) In 3GPP2 networks, link-layer security mechanisms, ingress > filtering at the PDSN, and various network domain security > mechanisms largely ensure that reverse tunnelled packets > received by the HA do not have spoofed source addresses, and > their contents have not been modified. This implies the HA can > determine the specific MN which sent the packet simply by > verifying the outer source IP address matches the currently > registered care-of address. Authentication of payload packets > can be necessary for e.g.: > > - Authenticating signalling messages other than BU/BAck > between the MN and HA, such as ICMPv6, MLD, and DHCPv6. > > - Enforcing access control to the network behind the HA. > > - Accounting or other flow-specific processing performed by > the HA. > > This means the authentication option is of limited > applicability in environments where the HA can received > reverse tunneled packets with spoofed source IP addresses > and/or modified contents. > > (4) As described in [RFC4285], the authentication option assumes > that the MN-AAA shared key and security association are created > by out-of-band mechanisms. These mechanisms are specific to > specific deployment environments. IKEv2, on the other hand, > supports a wide range of authentication mechanisms, such as > certificates and EAP methods, and is independent of the access > > > > Patil & Dommety Expires May 6, 2009 [Page 17] > > Internet-Draft Why authdata option for MIP6 November 2008 > > > network technology being used. However, it would be possible to > specify a similar authentication and key management protocol for > the authentication option in the future. > > (5) Sending the long-term user identity (NAI) in clear raises > privacy concerns. These concerns are addressed by access > network and network domain security mechanisms in 3GPP2 > networks, but do limit the applicability in networks where > sniffing other users' traffic is possible. > > (6) RFC 4285 does not specify a mechanism for creating the MN-HA > shared key and SA from the MN-AAA SA (unlike similar Mobile IPv4 > mechanisms defined in [RFC3957], and thus rely on deployment > specific mechanisms not standardized in IETF. > > (7) The authentication option does not support negotiation of > cryptographic algorithms. > > (8) The replay protection mechanisms in [RFC4285] rely on > timestamps, and thus requires reasonably synchronized clocks (by > default, +/- 7 seconds). This assumes the MN implements, and is > configured to use, some mechanism for synchronizing its clock. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Patil & Dommety Expires May 6, 2009 [Page 18] > > Internet-Draft Why authdata option for MIP6 November 2008 > > > 8. Security Considerations > > When MIP6 signaling messages use IPsec with ESP encapsulation, they > are accorded privacy on the links over which the messages traverse. > When MIP6 signaling messages are secured using the authentication > protocol, such ciphering capability will have to be enabled by the > underlying link layers. It should be noted that the MIP6 signaling > messages are susceptible to snooping/sniffing when the authentication > protocol [RFC4285] is used. Route optimization messages need to be > secured between the MN and HA and this is not possible with the > authentication protocol. Howver route optimization is not supported ^^^^^^^ However > in the current specification of the authentication protocol in > [RFC4285]. > > Security issues with RFC4285 are specifically: > > 1. Key length. This is being addressed in the 4285bis I-D > [I-D.ietf-mip6-rfc4285bis] at the present time. > > 2. The keys used for securing the signaling between the MN and HA > are derived from a security association that exists between the > MN and AAA. The MIP6 keys which are bootstrapped from the MN-AAA > SA are transient. Limiting the lifetime of the keys to shorter > periods should be recommended. > > 3. Location privacy is an issue in the absence of lower layer > security in the case of shared links. > > > > 10. Conclusion > > Mobile IPv6 has been published as a standards track RFC [RFC3775] in > 2004. Deployment of this protocol on a large scale is in the > interest of the IETF and the working group as well as that of many > people who have worked on this. A rigid model for deployment will > cause the protocol to be limited to an academic exercise only. It is > extremely critical that the working group consider the needs of the > industry and the deployment scenarios and address them accordingly. > This document captures the reasoning behind the need for the > authentication protocol which has been published as RFC 4285. > RFC4877 has alleviated some of the issues that have been of primary > concern and motivators for the authentication protocol. However the > IETF should consider the architectures of networks such as 3GPP2 and > WiMAX and their security models and enable deployment of Mobile IPv6 > without requiring IPsec. Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 3 16:40:27 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA7A28C29C; Mon, 3 Nov 2008 16:40:27 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B785628C29C for ; Mon, 3 Nov 2008 16:40:26 -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 ILbbCvyEk0Wf for ; Mon, 3 Nov 2008 16:40:25 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id B08F83A689F for ; Mon, 3 Nov 2008 16:40:25 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Nov 2008 19:40:18 -0500 Message-ID: In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D5AD8C39@NASANEXMB08.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Issue #17: Multi-homed mobile node can cause routingloop between home agents Thread-Index: Ackk6dl9GZJg9nlmTHiz1sRKz2u5AwWw4WiwADzi7ZoAGOFAIA== References: <48E55E5F.5040101@earthlink.net>, <057632CE4CE10D45A1A3D6D19206C3A3D5AD8C39@NASANEXMB08.na.qualcomm.com> From: "Vijay Devarapalli" To: "Giaretta, Gerardo" , "Charles E. Perkins" , "Benjamin Lim" Cc: mext@ietf.org Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can cause routingloop 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Gerardo, One difference is that this flooding attack is too easy to launch. The mobile node needs to just performing the two binding registrations and then start a session. Vijay > I tend to agree with Raj that this does not seem a > MIP6-specific issue or at least it does not require any > MIP6-specific solution. > > While the way of creating the routing loop is specific to > MIP6, in the sense that MIP6 signaling is used, the outcome > of the attack may be just a flood of packets to the HA. How > is this flooding of packets different from any other > DoS/flooding? Does the HA anyway be equipped to drop packets > in case of packets floods? > > The HA may just drop packets if they exceed a ceratin > threshold and optionally delete the binding. This seems to be > enough in my view considering that there is anyway a long > trust relationship between the attacker (i.e. the MN) and the HA. > > What do you think? > > Gerardo > > ________________________________________ > From: mext-bounces@ietf.org [mext-bounces@ietf.org] On Behalf > Of Vijay Devarapalli [vijay@wichorus.com] > Sent: Friday, October 31, 2008 4:15 PM > To: Charles E. Perkins; Benjamin Lim > Cc: mext@ietf.org > Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can > cause routing loop between home agents > > Hi Charlie, > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of Charles E. Perkins > > Sent: Thursday, October 02, 2008 4:51 PM > > To: Benjamin Lim > > Cc: mext@ietf.org > > Subject: [MEXT] Issue #17: Multi-homed mobile node can cause > > routing loop between home agents > > > > > > Hello Benjamin, > > > > I have not seen any further discussion about this issue, > > but I agree that the problem does exist. > > > > It might be possible to specify that the Home Agent should (or, > > ?may?) use the RFC 2473 "Tunnel Encapsulation Limit Option". > > to help avert the threat. Otherwise, the loop could persist for > > an annoyingly long amount of time. It is also possible for the > > home agent to enforce a policy by which a home address on > > a network cannot be bound to a care-of address on the same > > network, but in fact there may be cases where that would be > > a valid binding. > > > > I hope that other people in the working group will > > express an opinion about this. At minimum, we could > > certainly include text within the Security Considerations > > section. > > Recommending the use of the Tunnel Encapsulation Limit Option" in the > security considerations section seems to be the best option > to me. Here > is some text. > > A malicious mobile node associated to multiple home agents could > create a routing loop amongst the home agents. 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. To present this routing loop, it is recommended for > the home agents to use the Tunnel Encapsulation Limit Option > [RFC 2473], when tunneling packets for the mobile node. > > It would be good to recommend a default value for the "Tun Encap Lim" > field, but I don't know what to recommend. How about '5'? > This should be > sufficient for any additional GTP, PMIPv6, HMIPv6 or FMIPv6 tunneling > between the home agent and the mobile node. :) > > Vijay > > > > > > The existing discussion is documented at the following URL: > > http://trac.tools.ietf.org/wg/mext/trac/ticket/17 > > > > Regards, > > Charlie P. > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 3 18:26:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762B028C3CB; Mon, 3 Nov 2008 18:26:55 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62AA228C3CB for ; Mon, 3 Nov 2008 18:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.759 X-Spam-Level: X-Spam-Status: No, score=-5.759 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, J_CHICKENPOX_52=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 W5Ps5xNlkvZn for ; Mon, 3 Nov 2008 18:26:52 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id BAA5F3A6931 for ; Mon, 3 Nov 2008 18:26:51 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mA42QkHo013507; Tue, 4 Nov 2008 04:26:46 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Nov 2008 04:26:45 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Nov 2008 04:26:45 +0200 Received: from 10.241.58.88 ([10.241.58.88]) by daebe104.NOE.Nokia.com ([10.241.36.13]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Nov 2008 02:26:43 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Mon, 03 Nov 2008 20:26:45 -0500 From: Basavaraj Patil To: ext Arnaud Ebalard Message-ID: Thread-Topic: [MEXT] FW: New Version Notification for draft-patil-mext-mip6issueswithipsec-00 Thread-Index: Ack+JMfi9ocOeWp3k0uE2VRGzS84Jw== In-Reply-To: <87iqrdvhsc.fsf@natisbad.org> Mime-version: 1.0 X-OriginalArrivalTime: 04 Nov 2008 02:26:45.0612 (UTC) FILETIME=[C83F82C0:01C93E24] X-Nokia-AV: Clean Cc: "mext@ietf.org" Subject: Re: [MEXT] FW: New Version Notification for draft-patil-mext-mip6issueswithipsec-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello, My responses inline: On 10/27/08 4:40 PM, "ext Arnaud Ebalard" wrote: > Hi, > > Comments inline below. I am certainly biased on the topic but I try to > keep my comments below objective. Don't take the ones with smileys too > seriously. The bias does show distinctly :) > >> Abstract >> >> Mobile IPv6 as specified in RFC3775 relies on IPsec for security. An >> IPsec SA between the mobile node and the home agent provides security >> for the mobility signaling. Use of IPsec for securing the data >> traffic between the mobile node and home agent is optional. This >> document analyses the implications of the design decision to mandate >> IPsec as the default security protocol for Mobile IPv6 and recommends >> revisiting this decision > > At least, this will not fit in the scope of 3775bis ;-) > Lets not be too concerned about the scope of 3775bis. >> in view of the experience gained from implementation > > That is fair! > >> and adoption in other standards bodies. > > Is that fair? I believe so. > >> 2. Introduction >> >> Mobile IPv6 as specified in RFC3775 [RFC3775] requires an IPsec >> security association between the mobile node (MN) and home agent >> (HA). The IPsec SA protects the mobility signaling messages between >> the MN and HA. The user data may be optionally protected by the > > ^^^ > another Yes.. Agree. > >> IPsec SA but is not required. >> >> The use of IPsec and IKE (v1 and v2) with Mobile IPv6 are specified >> in RFCs 3776 [RFC3776] and 4877 [RFC4877]. The Mobile IP and MIP6 >> working groups in the IETF chose to mandate IPsec as the default >> security protocol for Mobile IPv6 based on various criteria and >> discussions between the years 2000 and 2004. Implementation >> experience with Mobile IPv6 and the security variants with which it >> has been specified in some SDOs indicates a need to revisit the >> design choice for MIP6 signaling security. >> >> This document discusses the issues and concerns with the use of IPsec >> for MIP6 security and proposes revisiting the security design for >> MIP6 protocol. >> >> 3. Terminology >> >> This document refers to [RFC3775][RFC4877] for terminology. >> >> 4. Background >> >> IP mobility support in IPv6 was considered to be an integral feature >> of the IPv6 stack based on the experience gained from developing >> mobility support for IPv4. The design of Mobile IPv6 was worked on >> by the Mobile IP WG in the late 90s and by the MIP6 WG until its >> publication as [RFC3775] in 2004. >> >> IPsec was also intended to be a default component of the IPv6 stack >> and was the preferred protocol choice for use by any other IPv6 >> protocols that needed security. Rather than design security into >> every protocol feature the intent was to reuse a well-defined >> security protocol to meet security needs. Hence Mobile IPv6 has been >> designed with a direct dependency on IPsec. >> >> The Mobile IPv6 specification [RFC3775] was published along with the >> companion specification "Using IPsec to Protect Mobile IPv6 Signaling >> Between Mobile Nodes and Home Agents", [RFC3776]. The establishment >> of the IPsec SA between the MN and HA as per RFC 3776 is based on the >> use of IKE. The use of IKE in the context of Mobile IPv6 for IPsec >> SA establishment did not gain traction because of factors such as >> complexity of IKE and the IETF transitioning to IKEv2. The MIP6 WG >> completed the specification, Mobile IPv6 Operation with IKEv2 and the > > ^^^^^^^^^ > IMHO, it is not complete. Hmmm... Wonder what happened. Will correct it in the next rev. > >> Revised IPsec Architecture [RFC4877] in April 2007. This [RFC4877] >> is considered as the default security protocol solution for MIP6 and >> updates [RFC3776]. >> >> 5. Problem Statement >> >> Mobile IPv6 is encumbered by its reliance on IPsec from an >> implementation and deployment perspective. As a protocol solution >> for host based mobility, MIP6 can be simpler without the IPsec >> baggage. The issues with IPsec are even more exacerbated in the case >> of dual-stack MIP6 [DSMIP6]. > > The problem of IPsec and DSMIPv6 is NAT, which is an IPv4 issue. NAT is an issue. But the combination of IPsec and NAT is not helping either. > >> IPsec SAs between the MN and HA are established either manually or by >> the use of IKEv2. Manual SA configuration is not a scalable solution >> and hence MIP6 hosts and Home agents rely on IKEv2 for establishing >> dynamically IPsec SAs. As a result MIP6 depends on the existence of >> IPsec and IKEv2 for successful operation. > > yes. > >> The problem in summary for MIP6 is the dependence on IPsec and IKEv2 >> for operation. > > You see it as a problem instead of seeing it as a *global* *solution* for > IPv6 security. IPsec is usable and used on IPv6 networks. Ipsec is no doubt used widely. But it is just not the right solution for securing MIP6 signaling. Ipsec in fact is used primarily in IPv4 networks today. However there is no reason for relying on Ipsec for MIP6 security. It is equivalent to Ipsec being the hammer for every security nail. > >> 6. Issues with the use of IPsec >> >> This section captures several issues with the use of IPsec by MIP6. >> >> (1) The design of Mobile IPv6 emphasized on the reuse of IPv6 >> features such as IPsec. IPsec for IPv4 was a bolt-on solution. >> With the increasing need for security, IPv6 designers chose to >> incorporate IPsec as a default feature. There existed an >> assumption in the MIP6 working group that every IPv6 host would >> have IPsec capability as a standard feature. While this is true >> in many host implementations today, the existence of IPsec in >> every IPv6 stack is not a given. > > As you say, it is true in many host implementation today; including many > mobile devices. It seems you want to remove IPsec/IKEv2 from IPv6 > devices, use a different solution for protecting MIPv6 signaling. Let's > say you have managed to do that: any solution for data protection? any > solution for protecting common IPv6 traffic to/from those nodes? > Specific solutions too? MIP6 is not a protocol that is intended to solve the data protection problem. If you need data protection use something else. And what other common IPv6 traffic between the MN and HA needs protection? MIP6 is a protocol for enabling host mobility. The signaling messages need to be secured. So lets just solve that. The intent is to not solve world hunger. > >> Hence a host which needs to >> implement Mobile IPv6 must ensure that IPsec and IKEv2 are also >> available. As a result of this dependence, MIP6 is no longer a >> standalone host-based mobility protocol. A good example of a >> host based mobility protocol that works as a self-sufficient >> module is Mobile IPv4. The security associated with MIP4 >> signaling is integrated into the protocol itself. MIP4 has been >> successfully deployed on large scale in several networks. > > No sarcasm at all: large scale public or *private* network? Can you give > examples? Large scale public networks. Almost all CDMA networks today use Mobile IPv4. I believe CDMA mobiles number in the 100s of millions. > > Another note: I don't know any administrator that can give the udp port > number for MIP4. They all know IPsec and may even be able to give > protocol numbers for AH and ESP. I guess you have been talking to the wrong people. I agree that MIP4 use in the enterprise does not exist and hence I would'nt expect an admin in such a domain to know the MIP4 UDP port number. But of course literally every enterprise has a VPN gateway. So it is not surprising that they would know Ipsec and not MIP4. > >> (2) IPsec use in most hosts is generally for the purpose of VPN >> connectivity to enterprises. It has not evolved into a generic >> security protocol that can be used by Mobile IPv6 easily. > > That's not true. See draft-ebalard-mext-pfkey-enhanced-migrate-00. This > is the only need from an interface perspective between IPsec/IKE and > MIPv6. There are public implementations available: > > - Linux 2.6.28 will be fully compliant with the feature > - Patches for racoon have recently been posted. They are currently being > reviewed. > - patches for Linux MIPv6 implementation maintained by USAGI people are > available. > > The only problem is the lack of traction in mext and the lack of > coordination with IPsec WG. The lack of traction is because of the complexity of integrating MIP6 with Ipsec and IKEv2. And given this complexity and other reasons the lack of traction is understandable. You may be an exception here and not the norm. > >> While >> RFC4877 does specify the details which enable only the MIP6 >> signaling to be encapsulated with IPsec, the general method of >> IPsec usage has been such that all traffic between a host and >> the IPsec gateway is carried via the tunnel. Selective >> application of IPsec to protocols is not the norm. Use of IPsec >> with Mobile IPv6 requires configuration which in many cases is >> not easily done because of reasons such as enterprise >> environments preventing changing to IPsec policies or other. > > I do not fully understand the argument. What I meant was that enterprise hosts which have Ipsec (VPN) clients essentially specify rules which tunnel all traffic via their gateway. Modifying these policies to allow only MIP6 signaling to be transported over Ipsec is not easily done because administrators do not allow an end user to change those policies. > >> (3) A MIP6 home agent is one end of the IPsec SA in a many-to-one >> relationship. A MIP6 HA may support a very large of mobile >> nodes which could number in the hundreds of thousands to >> millions. The ability to terminate a large number of IPsec SAs >> (millions) requires signifiant hardware and platform capability. >> The cost issues of such an HA are detrimental and hence act as a >> barrier to deployment. > > IPsec is efficient. What would you propose as an equivalent solution > (security wise) that would be more scalable than IPsec? Let me just say that there are alternative means of securing MIP6 signaling and the intent is to get the WG to begin work on developing such a solution. > >> (4) The implementation complexity of Mobile IPv6 is greatly >> increased because of the interaction with IPsec and IKEv2. > > This is just false. Please, just take a look at previous draft. Look at > the additional amount of code added in Linux kernel to support the > feature, for instance. I guess all I can say is YMMV. And it is not about the amount of code. > >> A >> standalone MIP6 protocol is easier to implement and deploy (such >> as MIP4 [RFC3344]). The complexity of the protocol >> implementation is even more so in the case of [DSMIP6]. > > Are you trying to remove IPsec/IKE of the picture with the hope that > DSMIPv6 issues will also disappear? > Yes... The issues with Ipsec/IKE are applicable to MIP6 and DSMPI6. > >> (5) IPsec and IKEv2 is not implemented in every IPv6 or dual stack >> host. > > Not in all, but most stacks. The assumption at the time of MIP6 design was that every IPv6 stack would by default include Ipsec. This is not true. > >> Mobile IPv6 support on such devices is not an option. >> Many low-end cellular hosts have IP stacks. The need for IPsec >> and IKEv2 in these devices is not important whereas mobility >> support is needed in many cases. MIP6 without any dependencies >> on protocols for security is easier to implement and has wider >> applicability. > > The idea of having every specific protocol specify its own security > mechanism is just the worst idea ever: interoperability issues, more > flaws, more code, ... > I am not suggesting that every protocol specify its own security mechanism. Lets look at what works and simplification. > >> (6) [RFC4877] which specifies the use of IKEv2 and IPsec with Mobile >> IPv6 essentially results in a variant of IPsec which is specific >> to Mobile IP. Hence this results in added complexity to >> implementations. > > ??? > >> (7) Mobile IPv6 needs to be capable of being deployed in situations >> where alternative security mechanisms are already well- >> understood by the network administration. It should be possible >> to enable Mobile IPv6 to work in situations where alternative >> security mechanisms already supply the necessary authentication >> and privacy. > > Can you be more specific and give some example? As an example consider a cellular network where access authentication between the MN and the home AAA is based on credentials and keys. The same can be leveraged for securing the MIP6 signaling. > >> (8) IPsec has been successfully applied to VPN and other >> infrastructure operations, but less so for general end-to-end >> applications. Thus, the granularity for selectors was >> originally not at all sufficient for Mobile IPv6. > > That issue was solved. I don't see the point. >> (9) The way that the IPsec code sits in the usual kernel, and the >> access mechanisms for the SA database, are not very convenient >> for use by straightforward implementations of Mobile IPv6. >> Unusual calling sequences and parameter passing seems to be >> required on many platforms. > > True. > >> (10) In certain environments the use of IPsec and IKEv2 for >> establishing the SA is considered as an overhead. Bandwidth >> constrained links such as cellular networks and air interfaces >> which are in the licensed spectrum tend to be optimized for user >> traffic. MIP6 signaling with the IPsec overhead and the IKEv2 >> messages are viewed negatively. It is more acceptable to have >> signaling without IPsec encapsulation. > > I must be missing something. Are you removing the security or are you > considering another mechanism when doing such a comparsion? The former > does not make sense, in the case of the latter, which one? > >> The issues listed above have been a cause for MIP6 not being >> implemented widely or adopted by other SDOs which are considering IP >> mobility solutions. > > Which ones? What did they choose? What provides security for the mobile > solution's traffic? What provides data security? There is no need for securing the traffic. If data security is needed, use something else (as I stated above). MIP6 is not a solution for securing the traffic. > >> 7. MIP6 evolution >> >> In order to make the Mobile Ipv6 protocol a solution that is easy to >> implement and available in even low-end devices, it is necessary to >> simplify the protocol. > > True. RO would look better with IPsec ;-) RO is a feature that is even less understood and used. Just get mobility deployed first and RO can come subsequently. > >> The design or the security architecture for MIP6 needs to be >> revisited and a solution that does not rely on other components >> developed. > > MIPv6v2 ? ;-) At least, with the generic notification, this will be > easier to distinguish. MIPv6 simplified is what I would call it. > > >> 8. Security Considerations >> >> This I-D discusses the security architecture of Mobile IPv6 which is >> based on IPsec. The dependency on IPsec for security of MIP6 >> signaling is a detriment to the protocol implementation and >> deployment. Hence the security architecture needs to be revisited. >> >> The experience gained over the last few years indicates that IPsec >> cannot necessarily be used as a generic solution for security. The >> design choice made for MIP6 in the initial stages no longer are valid >> and is hampering the implementation and use. > > What is hampering the implementation and use is the lack of IPv6 > deployment and the decision of the WG not to complete IPsec/IKE > integration and spend time on additional *features*. At the end, > security work is not complete and you have many features that are now in > the way. The WG can specify more Ipsec/IKE documents. But that will in no way ease implementation of the protocol and adoption. Simplifying the protocol and solving the mobility problems based on what we know now and not relying on the assumptions made at the time of MIP6 design originally will help. > > This is not an argument but it is worth mentioning: at some point, > MS had a (experimental) MIPv6 implementation on their OS. This has been > removed from latest versions of the OS while the IPv6 stack was > promoted. From a discussion with a developer of the stack, *one* of the > reason was that security work was not over. Or maybe they found the complexity of integrating the security module (Ipsec/IKEv2) with the MIP6 module simply too great and not worth the effort??? :) -Raj > > Cheers, > > a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 3 20:52:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68CD53A688B; Mon, 3 Nov 2008 20:52:54 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E59E3A686E for ; Mon, 3 Nov 2008 20:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.677 X-Spam-Level: X-Spam-Status: No, score=-105.677 tagged_above=-999 required=5 tests=[AWL=0.922, BAYES_00=-2.599, 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 X-Bku6nh2Khs for ; Mon, 3 Nov 2008 20:52:52 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 2C3513A684A for ; Mon, 3 Nov 2008 20:52:52 -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=1225774370; x=1257310370; 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:=20Vijay=20Devarapalli=20,=0D=0A =20=20=20=20=20=20=20=20"Charles=20E.=20Perkins"=0D=0A=09 ,=0D=0A=20=20=20=20=20=20 =20=20Benjamin=20Lim=0D=0A=09|CC:=20"mext@ietf.org"=20|Date:=20Mon ,=203=20Nov=202008=2020:52:42=20-0800|Subject:=20RE:=20[M EXT]=20Issue=20#17:=20Multi-homed=20mobile=20node=20can =20cause=20routingloop=0D=0A=20between=20home=20agents |Thread-Topic:=20[MEXT]=20Issue=20#17:=20Multi-homed=20mo bile=20node=20can=20cause=0D=0A=20routingloop=20between =20home=20agents|Thread-Index:=20Ackk6dl9GZJg9nlmTHiz1sRK z2u5AwWw4WiwADzi7ZoAGOFAIABNIbPw|Message-ID:=20<057632CE4 CE10D45A1A3D6D19206C3A3D5A19063@NASANEXMB08.na.qualcomm.c om>|References:=20<48E55E5F.5040101@earthlink.net>,=0D=0A=20<057632CE4CE10D45A1A3D6D19206C3A3D5AD8C39@ NASANEXMB08.na.qualcomm.com>=0D=0A=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-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5422"=3B=20a=3D"11896123"; bh=DMn1LUR4/pMW5FlHRDKM+vsDju5+qJ9EWQ/sJ6FhKKg=; b=cG8+4iSAmlrRqAOcYiP4UiDovesm3UgAwQg7UD2vxSZLGiYfa8gnGsdJ 1Ed4O6BdKcxEwLU/fYYR9SUfdFPUIeJAtDEEfxuTN3uCk/Bf5Wpm4FdZt VEO2PuHlRXQoGoLIIq7xw1nrjXCXfsLG1O84MCwyHg36qRc/4rNiBpumA M=; X-IronPort-AV: E=McAfee;i="5300,2777,5422"; a="11896123" 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; 03 Nov 2008 20:52:48 -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 mA44qldS007262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Nov 2008 20:52:47 -0800 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mA44qkrK021551 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 3 Nov 2008 20:52:47 -0800 (PST) Received: from nasanexhub02.na.qualcomm.com (10.46.143.120) by nasanexhc02.na.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.311.2; Mon, 3 Nov 2008 20:52:46 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Mon, 3 Nov 2008 20:52:45 -0800 From: "Giaretta, Gerardo" To: Vijay Devarapalli , "Charles E. Perkins" , Benjamin Lim Date: Mon, 3 Nov 2008 20:52:42 -0800 Thread-Topic: [MEXT] Issue #17: Multi-homed mobile node can cause routingloop between home agents Thread-Index: Ackk6dl9GZJg9nlmTHiz1sRKz2u5AwWw4WiwADzi7ZoAGOFAIABNIbPw Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D5A19063@NASANEXMB08.na.qualcomm.com> References: <48E55E5F.5040101@earthlink.net>, <057632CE4CE10D45A1A3D6D19206C3A3D5AD8C39@NASANEXMB08.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can cause routingloop 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org HI Vijay, I would actually claim the opposite. This attack needs multiple tunneling of binding update messages in particular in case ingress filtering is in place. This to me seems more complex than just flood one given IP address with packets. Gerardo > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Monday, November 03, 2008 4:40 PM > To: Giaretta, Gerardo; Charles E. Perkins; Benjamin Lim > Cc: mext@ietf.org > Subject: RE: [MEXT] Issue #17: Multi-homed mobile node can cause routingloop > between home agents > > Hi Gerardo, > > One difference is that this flooding attack is too easy to launch. The > mobile node needs to just performing the two binding registrations and > then start a session. > > Vijay > > > I tend to agree with Raj that this does not seem a > > MIP6-specific issue or at least it does not require any > > MIP6-specific solution. > > > > While the way of creating the routing loop is specific to > > MIP6, in the sense that MIP6 signaling is used, the outcome > > of the attack may be just a flood of packets to the HA. How > > is this flooding of packets different from any other > > DoS/flooding? Does the HA anyway be equipped to drop packets > > in case of packets floods? > > > > The HA may just drop packets if they exceed a ceratin > > threshold and optionally delete the binding. This seems to be > > enough in my view considering that there is anyway a long > > trust relationship between the attacker (i.e. the MN) and the HA. > > > > What do you think? > > > > Gerardo > > > > ________________________________________ > > From: mext-bounces@ietf.org [mext-bounces@ietf.org] On Behalf > > Of Vijay Devarapalli [vijay@wichorus.com] > > Sent: Friday, October 31, 2008 4:15 PM > > To: Charles E. Perkins; Benjamin Lim > > Cc: mext@ietf.org > > Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can > > cause routing loop between home agents > > > > Hi Charlie, > > > > > -----Original Message----- > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > > Behalf Of Charles E. Perkins > > > Sent: Thursday, October 02, 2008 4:51 PM > > > To: Benjamin Lim > > > Cc: mext@ietf.org > > > Subject: [MEXT] Issue #17: Multi-homed mobile node can cause > > > routing loop between home agents > > > > > > > > > Hello Benjamin, > > > > > > I have not seen any further discussion about this issue, > > > but I agree that the problem does exist. > > > > > > It might be possible to specify that the Home Agent should (or, > > > ?may?) use the RFC 2473 "Tunnel Encapsulation Limit Option". > > > to help avert the threat. Otherwise, the loop could persist for > > > an annoyingly long amount of time. It is also possible for the > > > home agent to enforce a policy by which a home address on > > > a network cannot be bound to a care-of address on the same > > > network, but in fact there may be cases where that would be > > > a valid binding. > > > > > > I hope that other people in the working group will > > > express an opinion about this. At minimum, we could > > > certainly include text within the Security Considerations > > > section. > > > > Recommending the use of the Tunnel Encapsulation Limit Option" in the > > security considerations section seems to be the best option > > to me. Here > > is some text. > > > > A malicious mobile node associated to multiple home agents could > > create a routing loop amongst the home agents. 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. To present this routing loop, it is recommended for > > the home agents to use the Tunnel Encapsulation Limit Option > > [RFC 2473], when tunneling packets for the mobile node. > > > > It would be good to recommend a default value for the "Tun Encap Lim" > > field, but I don't know what to recommend. How about '5'? > > This should be > > sufficient for any additional GTP, PMIPv6, HMIPv6 or FMIPv6 tunneling > > between the home agent and the mobile node. :) > > > > Vijay > > > > > > > > > > The existing discussion is documented at the following URL: > > > http://trac.tools.ietf.org/wg/mext/trac/ticket/17 > > > > > > Regards, > > > Charlie P. > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 4 00:17:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36CF33A698B; Tue, 4 Nov 2008 00:17:46 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A05EF3A68A0 for ; Tue, 4 Nov 2008 00:17:44 -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 T2bkuUXSw80K for ; Tue, 4 Nov 2008 00:17:43 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 47B503A698B for ; Tue, 4 Nov 2008 00:17:43 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1063921eyd.31 for ; Tue, 04 Nov 2008 00:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=PPDZ3zJtUb7D+q/oqKAssYYCx6SvhNX7VI0+h6829CY=; b=XciIjJRwv5fYeAe0GtUEcdrhAGduRK50jLuUJSnaQfhsAb21iI3KyRGReqbM5KQNh1 DkWfe5RLsouiO1J9mLd9rlAN0qksgDoGErIWISowcfP3Wya61qjCNQ2pyJ+NxgGAoffG PR6XLWtQMfGTnRm8jX7LT1T+pEP/6r9kMzdqI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:cc:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id:from; b=FBkJ1udDFvyImdjOTZF598zjf1UlFkfu83H7fWph67Zq5+Ql1uRxNKbqTE6F4IZqj8 J8QbvFfs0g2jjkrNiL8v8gw+pPTcw/f7pT683sq2kG8nl6bJqWcnmKWNNVjmsKTFJWkq l5gnZt8wykwKPBEafU4kTa5tR6VzGdbqCpeTE= Received: by 10.210.46.12 with SMTP id t12mr1320798ebt.17.1225786659415; Tue, 04 Nov 2008 00:17:39 -0800 (PST) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id u14sm1536656gvf.6.2008.11.04.00.17.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 04 Nov 2008 00:17:38 -0800 (PST) To: mext@ietf.org Date: Tue, 4 Nov 2008 09:17:37 +0100 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200811040917.37306.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: Teemu Rinta-aho Subject: Re: [MEXT] A few findings on the binding revocation draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Ahmad, Another finding in 9.1.1. Sending Binding Revocation Indication: When the mobile node is registered with an IPv4 proxy home address in addition to the Home Network Prefix where both of the IPv4 pHoA and HNP are bound to the same proxy CoA, the local mobility anchor MAY revoke the mobile node IPv4 proxy HoA binding to the current mobile node proxy CoA while maintaining the mobile node binding of the HNP to its current pCoA as part of the mobile node BCE. In this case, if the LMA decides to revoke the mobile node IPv4 proxy HoA ONLY, the LMA MUST sends a BRI message following the procedure in Section 7.1 and the following rules: o The Acknowledge (A) bit MUST be set in the BRI to request the MAG to send a BRA message. o The Revocation Trigger field MUST be set to "IPv4 HoA Binding ONLY". But the "IPv4 HoA Binding ONLY" revocation trigger isn't listed in 6.1. Binding Revocation Indication Message: Revocation Trigger 8-bit unsigned integer indicting the event which triggered the revoking node to send the BRI message. The following Revocation Trigger values are currently defined: 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 Possible Out-of Sync BCE State. 250-255 Reserved For Testing Purposes only. All other values are Reserved. Cheers, --julien On Monday 03 November 2008, Ahmad Muhanna wrote: > Hi Teemu, > > Thanks for the comments. Please see inline. > > Regards, > Ahmad > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of Teemu Rinta-aho > > Sent: Monday, November 03, 2008 4:27 AM > > To: mext@ietf.org > > Subject: [MEXT] A few findings on the binding revocation draft > > > > Hi all, > > > > here are some newcomer's findings on the binding revocation draft > > -01: > > > > 1) In Fig 2 and 3 there is a field "Cause" in BRA. > > Where is it defined in more detail? > > [Ahmad] > Thanks. This needs to be corrected and replaced by "Status" > > > 2) In 9.1.1. it is stated that "The Global (G) bit MUST > > be set and..." without any conditions. However, in the > > next bullet, it is stated that "Whenever the Global (G) > > bit is set", implying that it does not always need to > > be set. These texts are controversial and should be fixed. > > [Ahmad] > I do not think that there is any contradiction in there. In the first > bullet, if you continue reading you find the following: ".... to > request the mobile access gateway to remove all Per-Peer bindings > that are registered with the LMA and hosted at this MAG." > > We could rearrange the bullet to read as follows: > > In case of revoking all Per-Peer bindings, the Global (G) bit MUST be > set and the Revocation Trigger MUST contain a value of "Per-Peer > Policy" in the Binding Revocation Indication to request the mobile > access gateway to remove all Per- > Peer bindings that are registered with the LMA and hosted at this > MAG. > > Would that makes it clearer? > > > Some typos found: > > > > 3.4.3: "LMA may only supports IPv4" -> "LMA may only support IPv4" > > > > 8.2: "the home SHOULD examine" -> "the home agent SHOULD examine" > > > > "the home agent delete" -> "the home agent deletes" > > > > 9.1.1: "anchor send a" -> "anchor sends a" > > > > "LMA MUST sends a" -> "LMA MUST send a" > > [Ahmad] > Thanks. Will take care of them. > > > Best regards, > > Teemu Rinta-aho > > > > -- > > Teemu Rinta-aho Tel: +358 9 299 3078 > > NomadicLab, Ericsson Research Fax: +358 9 299 3535 > > Oy L M Ericsson Ab Mobile: +358 40 562 3066 > > FIN-02420 Jorvas, Finland E-mail: > > teemu.rinta-aho@nomadiclab.com > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext -- --julien [ New email address: julien.laganier.IETF@googlemail.com ] _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 4 02:09:02 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6B023A695D; Tue, 4 Nov 2008 02:09:01 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17353A68D5 for ; Tue, 4 Nov 2008 02:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFVr89PmBVxD for ; Tue, 4 Nov 2008 02:09:00 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 277BE3A695D for ; Tue, 4 Nov 2008 02:09:00 -0800 (PST) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3127A1EF151; Tue, 4 Nov 2008 12:08:56 +0200 (EET) Received: from [127.0.0.1] (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id E3E4C1EF12C; Tue, 4 Nov 2008 12:08:55 +0200 (EET) Message-ID: <49101F37.2060809@nomadiclab.com> Date: Tue, 04 Nov 2008 12:08:55 +0200 From: Teemu Rinta-aho User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Ahmad Muhanna References: In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: mext@ietf.org Subject: Re: [MEXT] A few findings on the binding revocation draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, > In case of revoking all Per-Peer bindings, the Global (G) bit MUST be > set and the Revocation Trigger MUST contain a value of "Per-Peer Policy" > in the Binding Revocation Indication to request the mobile access > gateway to remove all Per- > Peer bindings that are registered with the LMA and hosted at this MAG. maybe it was not a critical problem, but I think this version is clearer and should be used to replace the current version. Thanks! Best regards, Teemu _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 4 02:16:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACD013A6931; Tue, 4 Nov 2008 02:16:07 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAC413A69F3 for ; Tue, 4 Nov 2008 02:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.796, 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 5nCf6cWOPPw8 for ; Tue, 4 Nov 2008 02:16:05 -0800 (PST) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 95C4A3A6A04 for ; Tue, 4 Nov 2008 02:16:03 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KxIx2-0000dF-1o; Tue, 04 Nov 2008 11:15:56 +0100 From: arno@natisbad.org (Arnaud Ebalard) To: Basavaraj Patil References: 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:081104:mext@ietf.org::J4tBihDpGlNxuGYw:00000fxS X-Hashcash: 1:20:081104:basavaraj.patil@nokia.com::fk3jqkQnf4L6YSj2:0000000000000000000000000000000000004mXn Date: Tue, 04 Nov 2008 11:14:11 +0100 Message-ID: <871vxrre6k.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] FW: New Version Notification for draft-patil-mext-mip6issueswithipsec-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Basavaraj, Basavaraj Patil writes: >>> Revised IPsec Architecture [RFC4877] in April 2007. This [RFC4877] >>> is considered as the default security protocol solution for MIP6 and >>> updates [RFC3776]. >>> >>> 5. Problem Statement >>> >>> Mobile IPv6 is encumbered by its reliance on IPsec from an >>> implementation and deployment perspective. As a protocol solution >>> for host based mobility, MIP6 can be simpler without the IPsec >>> baggage. The issues with IPsec are even more exacerbated in the case >>> of dual-stack MIP6 [DSMIP6]. >> >> The problem of IPsec and DSMIPv6 is NAT, which is an IPv4 issue. > > NAT is an issue. But the combination of IPsec and NAT is not helping either. I still think the issues associated with the path selected for DSMIPv6 are used as an argument against IPsec for MIPv6. If you consider MIPv6 and the networks it is expected to operate in (IPv6 ones), there is no issue. >>> IPsec SAs between the MN and HA are established either manually or by >>> the use of IKEv2. Manual SA configuration is not a scalable solution >>> and hence MIP6 hosts and Home agents rely on IKEv2 for establishing >>> dynamically IPsec SAs. As a result MIP6 depends on the existence of >>> IPsec and IKEv2 for successful operation. >> >> yes. >> >>> The problem in summary for MIP6 is the dependence on IPsec and IKEv2 >>> for operation. >> >> You see it as a problem instead of seeing it as a *global* *solution* for >> IPv6 security. IPsec is usable and used on IPv6 networks. > > Ipsec is no doubt used widely. But it is just not the right solution for > securing MIP6 signaling. Ipsec in fact is used primarily in IPv4 networks > today. However there is no reason for relying on Ipsec for MIP6 security. It > is equivalent to Ipsec being the hammer for every security nail. When "Security Considerations" sections of IETF protocol specification simply states "IPsec can be used to secure the protocol", I agree. But in MIPv6 case, time has been spent and specifications have been written to provide a working solution. >>> 6. Issues with the use of IPsec >>> >>> This section captures several issues with the use of IPsec by MIP6. >>> >>> (1) The design of Mobile IPv6 emphasized on the reuse of IPv6 >>> features such as IPsec. IPsec for IPv4 was a bolt-on solution. >>> With the increasing need for security, IPv6 designers chose to >>> incorporate IPsec as a default feature. There existed an >>> assumption in the MIP6 working group that every IPv6 host would >>> have IPsec capability as a standard feature. While this is true >>> in many host implementations today, the existence of IPsec in >>> every IPv6 stack is not a given. >> >> As you say, it is true in many host implementation today; including many >> mobile devices. It seems you want to remove IPsec/IKEv2 from IPv6 >> devices, use a different solution for protecting MIPv6 signaling. Let's >> say you have managed to do that: any solution for data protection? any >> solution for protecting common IPv6 traffic to/from those nodes? >> Specific solutions too? > > MIP6 is not a protocol that is intended to solve the data protection > problem. If you are an operator and your Mobile Nodes are only moving in a closed environment, probably. When you are a common user on real *foreign* networks, I bet that you expect some ability to protect your data, at least between you and you HA. > If you need data protection use something else. IPsec/IKE seems like the right solution to me. It is the one I use. > And what other common IPv6 traffic between the MN and HA needs protection? > > MIP6 is a protocol for enabling host mobility. The signaling messages need > to be secured. So lets just solve that. IMHO, it has been solved already. Someone tries to reopen the case because of DSMIPv6 issues with current solutions or other specific incompatibilities with some internal practices, AFAICT. Please, note that I am not against alternative solution if they are chosen for the right reasons and if their drawbacks and scope of deployments are known. If the intent is to provide a specific operator compatible solution with no expected ability to support movement to common foreign networks or expected support for movement to IPv4 network, that goal should be clearly stated. In a sense, I prefer how things are stated in draft-ietf-mip6-whyauthdataoption-07.txt. >>> Hence a host which needs to >>> implement Mobile IPv6 must ensure that IPsec and IKEv2 are also >>> available. As a result of this dependence, MIP6 is no longer a >>> standalone host-based mobility protocol. A good example of a >>> host based mobility protocol that works as a self-sufficient >>> module is Mobile IPv4. The security associated with MIP4 >>> signaling is integrated into the protocol itself. MIP4 has been >>> successfully deployed on large scale in several networks. >> >> No sarcasm at all: large scale public or *private* network? Can you give >> examples? > > Large scale public networks. Almost all CDMA networks today use Mobile IPv4. > I believe CDMA mobiles number in the 100s of millions. ok. thanks. >> Another note: I don't know any administrator that can give the udp port >> number for MIP4. They all know IPsec and may even be able to give >> protocol numbers for AH and ESP. > > I guess you have been talking to the wrong people. I agree that MIP4 use in > the enterprise does not exist and hence I would'nt expect an admin in such a > domain to know the MIP4 UDP port number. But of course literally every > enterprise has a VPN gateway. So it is not surprising that they would know > Ipsec and not MIP4. ok. >>> (2) IPsec use in most hosts is generally for the purpose of VPN >>> connectivity to enterprises. It has not evolved into a generic >>> security protocol that can be used by Mobile IPv6 easily. >> >> That's not true. See draft-ebalard-mext-pfkey-enhanced-migrate-00. This >> is the only need from an interface perspective between IPsec/IKE and >> MIPv6. There are public implementations available: >> >> - Linux 2.6.28 will be fully compliant with the feature >> - Patches for racoon have recently been posted. They are currently being >> reviewed. >> - patches for Linux MIPv6 implementation maintained by USAGI people are >> available. >> >> The only problem is the lack of traction in mext and the lack of >> coordination with IPsec WG. > > The lack of traction is because of the complexity of integrating MIP6 with > Ipsec and IKEv2. I don't think this is the *real* issue: the changes required at the IPsec stack level and in the IKE implementations to support MIPv6 are not so huge. > And given this complexity and other reasons the lack of > traction is understandable. You may be an exception here and not the > norm. yes. I don't work for a phone manufacturer or a network operator. >>> While >>> RFC4877 does specify the details which enable only the MIP6 >>> signaling to be encapsulated with IPsec, the general method of >>> IPsec usage has been such that all traffic between a host and >>> the IPsec gateway is carried via the tunnel. Selective >>> application of IPsec to protocols is not the norm. Use of IPsec >>> with Mobile IPv6 requires configuration which in many cases is >>> not easily done because of reasons such as enterprise >>> environments preventing changing to IPsec policies or other. >> >> I do not fully understand the argument. > > What I meant was that enterprise hosts which have Ipsec (VPN) clients > essentially specify rules which tunnel all traffic via their gateway. > Modifying these policies to allow only MIP6 signaling to be transported over > Ipsec is not easily done because administrators do not allow an end user to > change those policies. Well, I would not expect users to do those changes either but in the end, why would they need to switch off the protection of data to only have MIPv6 signaling transport-mode protected. From my point of view, as expected by the reference document, MIPv6 signaling is protected using transport mode and data traffic is protected using tunnel mode. This just perfectly fit the need, doesn't it? >>> (3) A MIP6 home agent is one end of the IPsec SA in a many-to-one >>> relationship. A MIP6 HA may support a very large of mobile >>> nodes which could number in the hundreds of thousands to >>> millions. The ability to terminate a large number of IPsec SAs >>> (millions) requires signifiant hardware and platform capability. >>> The cost issues of such an HA are detrimental and hence act as a >>> barrier to deployment. >> >> IPsec is efficient. What would you propose as an equivalent solution >> (security wise) that would be more scalable than IPsec? > > Let me just say that there are alternative means of securing MIP6 signaling > and the intent is to get the WG to begin work on developing such a solution. Would you agree with the following summary: the intent is to provide a specific solution targeting *only* protection of MIPv6 signaling. Unlike currently specified IPsec/IKE protection, extending it to support protection of data traffic (MN-HA and possibly MN-CN) at some point is not expected and will not be easily possible. This solution would be in sync with the specific networks it is expected to be deployed in. >>> (4) The implementation complexity of Mobile IPv6 is greatly >>> increased because of the interaction with IPsec and IKEv2. >> >> This is just false. Please, just take a look at previous draft. Look at >> the additional amount of code added in Linux kernel to support the >> feature, for instance. > > I guess all I can say is YMMV. And it is not about the amount of code. Is that for "Your Mileage May Vary" or "Your Market May Vary" ? :-) >>> A >>> standalone MIP6 protocol is easier to implement and deploy (such >>> as MIP4 [RFC3344]). The complexity of the protocol >>> implementation is even more so in the case of [DSMIP6]. >> >> Are you trying to remove IPsec/IKE of the picture with the hope that >> DSMIPv6 issues will also disappear? >> > > Yes... The issues with Ipsec/IKE are applicable to MIP6 and DSMPI6. I don't think there are issues with MIPv6. I expect there are with DSMIPv6. >>> (5) IPsec and IKEv2 is not implemented in every IPv6 or dual stack >>> host. >> >> Not in all, but most stacks. > > The assumption at the time of MIP6 design was that every IPv6 stack would by > default include Ipsec. This is not true. ? >>> Mobile IPv6 support on such devices is not an option. >>> Many low-end cellular hosts have IP stacks. The need for IPsec >>> and IKEv2 in these devices is not important whereas mobility >>> support is needed in many cases. MIP6 without any dependencies >>> on protocols for security is easier to implement and has wider >>> applicability. >> >> The idea of having every specific protocol specify its own security >> mechanism is just the worst idea ever: interoperability issues, more >> flaws, more code, ... >> > > I am not suggesting that every protocol specify its own security mechanism. > Lets look at what works and simplification. Hum. You don't suggest that but you want that for MIPv6. If everyone does that for his protocol (HIP, ...), we just have what I describe above. >>> (6) [RFC4877] which specifies the use of IKEv2 and IPsec with Mobile >>> IPv6 essentially results in a variant of IPsec which is specific >>> to Mobile IP. Hence this results in added complexity to >>> implementations. >> >> ??? >> >>> (7) Mobile IPv6 needs to be capable of being deployed in situations >>> where alternative security mechanisms are already well- >>> understood by the network administration. It should be possible >>> to enable Mobile IPv6 to work in situations where alternative >>> security mechanisms already supply the necessary authentication >>> and privacy. >> >> Can you be more specific and give some example? > > As an example consider a cellular network where access authentication > between the MN and the home AAA is based on credentials and keys. The same > can be leveraged for securing the MIP6 signaling. Tell me if this is correct: - cellular network operator have AAA deployed - they have IPv4 - they have specific architectures they are used to manage - they don't have IPsec/IKE deployed (for end devices) - they don't need to secure data traffic >>> (8) IPsec has been successfully applied to VPN and other >>> infrastructure operations, but less so for general end-to-end >>> applications. Thus, the granularity for selectors was >>> originally not at all sufficient for Mobile IPv6. >> >> That issue was solved. I don't see the point. > >>> (9) The way that the IPsec code sits in the usual kernel, and the >>> access mechanisms for the SA database, are not very convenient >>> for use by straightforward implementations of Mobile IPv6. >>> Unusual calling sequences and parameter passing seems to be >>> required on many platforms. >> >> True. >> >>> (10) In certain environments the use of IPsec and IKEv2 for >>> establishing the SA is considered as an overhead. Bandwidth >>> constrained links such as cellular networks and air interfaces >>> which are in the licensed spectrum tend to be optimized for user >>> traffic. MIP6 signaling with the IPsec overhead and the IKEv2 >>> messages are viewed negatively. It is more acceptable to have >>> signaling without IPsec encapsulation. >> >> I must be missing something. Are you removing the security or are you >> considering another mechanism when doing such a comparsion? The former >> does not make sense, in the case of the latter, which one? >> >>> The issues listed above have been a cause for MIP6 not being >>> implemented widely or adopted by other SDOs which are considering IP >>> mobility solutions. >> >> Which ones? What did they choose? What provides security for the mobile >> solution's traffic? What provides data security? > > There is no need for securing the traffic. Let say operators do not have the need. > If data security is needed, use something else (as I stated > above). MIP6 is not a solution for securing the traffic. No, it is not. >>> 7. MIP6 evolution >>> >>> In order to make the Mobile Ipv6 protocol a solution that is easy to >>> implement and available in even low-end devices, it is necessary to >>> simplify the protocol. >> >> True. RO would look better with IPsec ;-) > > RO is a feature that is even less understood and used. Just get mobility > deployed first and RO can come subsequently. cellular network operators will not allow that anyway, will they? >>> The design or the security architecture for MIP6 needs to be >>> revisited and a solution that does not rely on other components >>> developed. >> >> MIPv6v2 ? ;-) At least, with the generic notification, this will be >> easier to distinguish. > > MIPv6 simplified is what I would call it. ok. >>> 8. Security Considerations >>> >>> This I-D discusses the security architecture of Mobile IPv6 which is >>> based on IPsec. The dependency on IPsec for security of MIP6 >>> signaling is a detriment to the protocol implementation and >>> deployment. Hence the security architecture needs to be revisited. >>> >>> The experience gained over the last few years indicates that IPsec >>> cannot necessarily be used as a generic solution for security. The >>> design choice made for MIP6 in the initial stages no longer are valid >>> and is hampering the implementation and use. >> >> What is hampering the implementation and use is the lack of IPv6 >> deployment and the decision of the WG not to complete IPsec/IKE >> integration and spend time on additional *features*. At the end, >> security work is not complete and you have many features that are now in >> the way. > > The WG can specify more Ipsec/IKE documents. But that will in no way ease > implementation of the protocol and adoption. Simplifying the protocol and > solving the mobility problems based on what we know now and not relying on > the assumptions made at the time of MIP6 design originally will help. Sorry, I don't see it that way. I write stuff, have it reviewed, implement it, correct it based on that feedback. And at the moment, I don't see issues with IPsec/IKE being used for MIPv6 protection (and yes, for both signaling and data traffic). The only issue I see is operators that don't see how this IPsec/IKE protection could fit in their networks (management, billing, IPv4 compatibility, ...). AFAICT, some documents have already being produced towards that goal. If this is the issue, it should be stated that way. Is that correct? >> This is not an argument but it is worth mentioning: at some point, >> MS had a (experimental) MIPv6 implementation on their OS. This has been >> removed from latest versions of the OS while the IPv6 stack was >> promoted. From a discussion with a developer of the stack, *one* of the >> reason was that security work was not over. > > Or maybe they found the complexity of integrating the security module > (Ipsec/IKEv2) with the MIP6 module simply too great and not worth the > effort??? :) Thanks for you answers Basavaraj. Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 4 04:03:19 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E78A3A6966; Tue, 4 Nov 2008 04:03:19 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769A43A6867 for ; Tue, 4 Nov 2008 04:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 CtMhRrUHe0py for ; Tue, 4 Nov 2008 04:03:17 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 7EE603A6966 for ; Tue, 4 Nov 2008 04:03:17 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (108.pool85-53-138.dynamic.orange.es [85.53.138.108])by smtp02.uc3m.es (Postfix) with ESMTP id DBC755CA432; Tue, 4 Nov 2008 13:02:01 +0100 (CET) Message-ID: <491039B9.6090400@it.uc3m.es> Date: Tue, 04 Nov 2008 13:02:01 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: mext , Julien Laganier , Ralph Droms X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-4.4939 TC:1F TRN:9 TV:5.5.1026(16258.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, We now start the WGLC for: DHCPv6 Prefix Delegation for NEMO draft-ietf-mext-nemo-pd-01.txt http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt Please send comments about the draft till the November 19. Regards, Julien and marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 4 05:42:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 675EE3A67AF; Tue, 4 Nov 2008 05:42:00 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375CC3A67AF for ; Tue, 4 Nov 2008 05:41:59 -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 xthG4NCVcA8Z for ; Tue, 4 Nov 2008 05:41:57 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id B54D93A6358 for ; Tue, 4 Nov 2008 05:41:57 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mA4Dfot02919; Tue, 4 Nov 2008 13:41:50 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Nov 2008 07:41:48 -0600 Message-ID: In-Reply-To: <200811040917.37306.julien.laganier.IETF@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] A few findings on the binding revocation draft Thread-Index: Ack+Vc94qc3PdbNeQOGr0P7SXG/oEAALHj8w References: <200811040917.37306.julien.laganier.IETF@googlemail.com> From: "Ahmad Muhanna" To: "Julien Laganier" , Cc: Teemu Rinta-aho Subject: Re: [MEXT] A few findings on the binding revocation draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, Yes, that was an oversight and will be fixed in the next revision. We will publish a new revision with all of the identified comments/correction after the IETF-73 discussion/meeting hoping that revision will be ready for a wg Last Call. Regards, Ahmad > -----Original Message----- > From: Julien Laganier [mailto:julien.laganier.ietf@googlemail.com] > Sent: Tuesday, November 04, 2008 2:18 AM > To: mext@ietf.org > Cc: Muhanna, Ahmad (RICH1:2H10); Teemu Rinta-aho > Subject: Re: [MEXT] A few findings on the binding revocation draft > > Hello Ahmad, > > Another finding in 9.1.1. Sending Binding Revocation Indication: > > When the mobile node is registered with an IPv4 proxy home > address in > addition to the Home Network Prefix where both of the IPv4 pHoA and > HNP are bound to the same proxy CoA, the local mobility anchor MAY > revoke the mobile node IPv4 proxy HoA binding to the current mobile > node proxy CoA while maintaining the mobile node binding of the HNP > to its current pCoA as part of the mobile node BCE. In > this case, if > the LMA decides to revoke the mobile node IPv4 proxy HoA ONLY, the > LMA MUST sends a BRI message following the procedure in Section 7.1 > and the following rules: > > o The Acknowledge (A) bit MUST be set in the BRI to > request the MAG > to send a BRA message. > > o The Revocation Trigger field MUST be set to "IPv4 HoA Binding > ONLY". > > But the "IPv4 HoA Binding ONLY" revocation trigger isn't > listed in 6.1. > Binding Revocation Indication Message: > > Revocation Trigger > > 8-bit unsigned integer indicting the event which triggered the > revoking node to send the BRI message. The following Revocation > Trigger values are currently defined: > > 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 Possible Out-of Sync BCE State. > 250-255 Reserved For Testing Purposes only. > All other values are Reserved. > > Cheers, > > --julien > > On Monday 03 November 2008, Ahmad Muhanna wrote: > > Hi Teemu, > > > > Thanks for the comments. Please see inline. > > > > Regards, > > Ahmad > > > > > -----Original Message----- > > > From: mext-bounces@ietf.org > [mailto:mext-bounces@ietf.org] On Behalf > > > Of Teemu Rinta-aho > > > Sent: Monday, November 03, 2008 4:27 AM > > > To: mext@ietf.org > > > Subject: [MEXT] A few findings on the binding revocation draft > > > > > > Hi all, > > > > > > here are some newcomer's findings on the binding revocation draft > > > -01: > > > > > > 1) In Fig 2 and 3 there is a field "Cause" in BRA. > > > Where is it defined in more detail? > > > > [Ahmad] > > Thanks. This needs to be corrected and replaced by "Status" > > > > > 2) In 9.1.1. it is stated that "The Global (G) bit MUST > > > be set and..." without any conditions. However, in the > > > next bullet, it is stated that "Whenever the Global (G) > > > bit is set", implying that it does not always need to > > > be set. These texts are controversial and should be fixed. > > > > [Ahmad] > > I do not think that there is any contradiction in there. In > the first > > bullet, if you continue reading you find the following: ".... to > > request the mobile access gateway to remove all Per-Peer > bindings that > > are registered with the LMA and hosted at this MAG." > > > > We could rearrange the bullet to read as follows: > > > > In case of revoking all Per-Peer bindings, the Global (G) > bit MUST be > > set and the Revocation Trigger MUST contain a value of "Per-Peer > > Policy" in the Binding Revocation Indication to request the mobile > > access gateway to remove all Per- Peer bindings that are registered > > with the LMA and hosted at this MAG. > > > > Would that makes it clearer? > > > > > Some typos found: > > > > > > 3.4.3: "LMA may only supports IPv4" -> "LMA may only support IPv4" > > > > > > 8.2: "the home SHOULD examine" -> "the home agent SHOULD examine" > > > > > > "the home agent delete" -> "the home agent deletes" > > > > > > 9.1.1: "anchor send a" -> "anchor sends a" > > > > > > "LMA MUST sends a" -> "LMA MUST send a" > > > > [Ahmad] > > Thanks. Will take care of them. > > > > > Best regards, > > > Teemu Rinta-aho > > > > > > -- > > > Teemu Rinta-aho Tel: +358 9 299 3078 > > > NomadicLab, Ericsson Research Fax: +358 9 299 3535 > > > Oy L M Ericsson Ab Mobile: +358 40 562 3066 > > > FIN-02420 Jorvas, Finland E-mail: > > > teemu.rinta-aho@nomadiclab.com > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > -- > --julien > > [ New email address: julien.laganier.IETF@googlemail.com ] > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 4 06:29:33 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 802273A6A5B; Tue, 4 Nov 2008 06:29:33 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id D553D3A6A61; Tue, 4 Nov 2008 06:29:32 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20081104142932.D553D3A6A61@core3.amsl.com> Date: Tue, 4 Nov 2008 06:29:32 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] Last Call: draft-ietf-mext-nemo-v4traversal (Mobile IPv6 Support for Dual Stack Hosts and Routers) to Proposed Standard X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org The IESG has received a request from the Mobility EXTensions for IPv6 WG (mext) to consider the following document: - 'Mobile IPv6 Support for Dual Stack Hosts and Routers ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-11-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16873&rfc_flag=0 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 4 07:55:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 285D13A6955; Tue, 4 Nov 2008 07:55:35 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE77D3A6955 for ; Tue, 4 Nov 2008 07:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 NVkfqqEuE455 for ; Tue, 4 Nov 2008 07:55:33 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id BC6A63A67AF for ; Tue, 4 Nov 2008 07:55:33 -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 mA4FvNE7022485; Tue, 4 Nov 2008 09:57:23 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Nov 2008 09:55:29 -0600 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Nov 2008 09:55:28 -0600 Message-ID: <49107009.4050306@ericsson.com> Date: Tue, 04 Nov 2008 10:53:45 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: <48E55E5F.5040101@earthlink.net>, <057632CE4CE10D45A1A3D6D19206C3A3D5AD8C39@NASANEXMB08.na.qualcomm.com> <057632CE4CE10D45A1A3D6D19206C3A3D5A19063@NASANEXMB08.na.qualcomm.com> In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D5A19063@NASANEXMB08.na.qualcomm.com> X-OriginalArrivalTime: 04 Nov 2008 15:55:28.0859 (UTC) FILETIME=[C25B6AB0:01C93E95] Cc: "mext@ietf.org" Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can cause routingloop 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Gerardo, I agree more with Vijay. This attack is harder to INITIATE but way way easier to SUSTAIN. In a direct denial of service attack, you are limited by the bandwidth you have on your uplink and you need to keep sending the packets. In the HA routing loop. You can use well connected servers (Google,Youtube...) to perform your attack for you. You just setup the bindings, request a video and just go away. The HAs will be busy for a while :-) and they would not notice you went away. Cheers Suresh Giaretta, Gerardo wrote: > HI Vijay, > > I would actually claim the opposite. This attack needs multiple tunneling of binding update messages in particular in case ingress filtering is in place. This to me seems more complex than just flood one given IP address with packets. > > Gerardo > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >> Sent: Monday, November 03, 2008 4:40 PM >> To: Giaretta, Gerardo; Charles E. Perkins; Benjamin Lim >> Cc: mext@ietf.org >> Subject: RE: [MEXT] Issue #17: Multi-homed mobile node can cause routingloop >> between home agents >> >> Hi Gerardo, >> >> One difference is that this flooding attack is too easy to launch. The >> mobile node needs to just performing the two binding registrations and >> then start a session. >> >> Vijay >> >>> I tend to agree with Raj that this does not seem a >>> MIP6-specific issue or at least it does not require any >>> MIP6-specific solution. >>> >>> While the way of creating the routing loop is specific to >>> MIP6, in the sense that MIP6 signaling is used, the outcome >>> of the attack may be just a flood of packets to the HA. How >>> is this flooding of packets different from any other >>> DoS/flooding? Does the HA anyway be equipped to drop packets >>> in case of packets floods? >>> >>> The HA may just drop packets if they exceed a ceratin >>> threshold and optionally delete the binding. This seems to be >>> enough in my view considering that there is anyway a long >>> trust relationship between the attacker (i.e. the MN) and the HA. >>> >>> What do you think? >>> >>> Gerardo >>> >>> ________________________________________ >>> From: mext-bounces@ietf.org [mext-bounces@ietf.org] On Behalf >>> Of Vijay Devarapalli [vijay@wichorus.com] >>> Sent: Friday, October 31, 2008 4:15 PM >>> To: Charles E. Perkins; Benjamin Lim >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can >>> cause routing loop between home agents >>> >>> Hi Charlie, >>> >>>> -----Original Message----- >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>> Behalf Of Charles E. Perkins >>>> Sent: Thursday, October 02, 2008 4:51 PM >>>> To: Benjamin Lim >>>> Cc: mext@ietf.org >>>> Subject: [MEXT] Issue #17: Multi-homed mobile node can cause >>>> routing loop between home agents >>>> >>>> >>>> Hello Benjamin, >>>> >>>> I have not seen any further discussion about this issue, >>>> but I agree that the problem does exist. >>>> >>>> It might be possible to specify that the Home Agent should (or, >>>> ?may?) use the RFC 2473 "Tunnel Encapsulation Limit Option". >>>> to help avert the threat. Otherwise, the loop could persist for >>>> an annoyingly long amount of time. It is also possible for the >>>> home agent to enforce a policy by which a home address on >>>> a network cannot be bound to a care-of address on the same >>>> network, but in fact there may be cases where that would be >>>> a valid binding. >>>> >>>> I hope that other people in the working group will >>>> express an opinion about this. At minimum, we could >>>> certainly include text within the Security Considerations >>>> section. >>> Recommending the use of the Tunnel Encapsulation Limit Option" in the >>> security considerations section seems to be the best option >>> to me. Here >>> is some text. >>> >>> A malicious mobile node associated to multiple home agents could >>> create a routing loop amongst the home agents. 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. To present this routing loop, it is recommended for >>> the home agents to use the Tunnel Encapsulation Limit Option >>> [RFC 2473], when tunneling packets for the mobile node. >>> >>> It would be good to recommend a default value for the "Tun Encap Lim" >>> field, but I don't know what to recommend. How about '5'? >>> This should be >>> sufficient for any additional GTP, PMIPv6, HMIPv6 or FMIPv6 tunneling >>> between the home agent and the mobile node. :) >>> >>> Vijay >>> >>> >>>> The existing discussion is documented at the following URL: >>>> http://trac.tools.ietf.org/wg/mext/trac/ticket/17 >>>> >>>> Regards, >>>> Charlie P. >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 4 07:59:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B79083A6A95; Tue, 4 Nov 2008 07:59:07 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 96C0C3A6A80; Tue, 4 Nov 2008 07:59:06 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20081104155906.96C0C3A6A80@core3.amsl.com> Date: Tue, 4 Nov 2008 07:59:06 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] Last Call: draft-ietf-monami6-multiplecoa (Multiple Care-of Addresses Registration) to Proposed Standard X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org The IESG has received a request from the Mobility EXTensions for IPv6 WG (mext) to consider the following document: - 'Multiple Care-of Addresses Registration ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-11-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-10.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14776&rfc_flag=0 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 4 09:02:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D410628B56A; Tue, 4 Nov 2008 09:02:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C99523A6AEA for ; Tue, 4 Nov 2008 09:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.769 X-Spam-Level: X-Spam-Status: No, score=-105.769 tagged_above=-999 required=5 tests=[AWL=0.830, BAYES_00=-2.599, 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 Oli+ggGEkBWM for ; Tue, 4 Nov 2008 09:02:47 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 737153A6B4A for ; Tue, 4 Nov 2008 09:02:47 -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=1225818165; x=1257354165; 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:=20Suresh=20Krishnan=20 |CC:=20Vijay=20Devarapalli=20,=0D=0A =20=20=20=20=20=20=20=20"Charles=20E.=20Perkins"=0D=0A=09 ,=0D=0A=20=20=20=20=20=20 =20=20Benjamin=20Lim=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"mext@ietf.org"=20|Date:=20Tue,=204=20Nov=202008=2009:02:36=20- 0800|Subject:=20RE:=20[MEXT]=20Issue=20#17:=20Multi-homed =20mobile=20node=20can=20cause=20routingloop=0D=0A=20betw een=20home=20agents|Thread-Topic:=20[MEXT]=20Issue=20#17: =20Multi-homed=20mobile=20node=20can=20cause=0D=0A=20rout ingloop=20between=20home=20agents|Thread-Index:=20Ack+lcm 1Dgh+pZfKSjmQK2AvrQ0JeQACPcsA|Message-ID:=20<057632CE4CE1 0D45A1A3D6D19206C3A3D5A19097@NASANEXMB08.na.qualcomm.com> |References:=20<48E55E5F.5040101@earthlink.net>,=0D=0A=09 =0D=0A=09<057632CE4CE10D45A1A3D6D19206C3A3D5A D8C39@NASANEXMB08.na.qualcomm.com>=0D=0A=09 =0D=0A=20<057632CE4CE10D45A1A3D6D19206C3A3D5A19063@NASANE XMB08.na.qualcomm.com>=0D=0A=20<49107009.4050306@ericsson .com>|In-Reply-To:=20<49107009.4050306@ericsson.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"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5423"=3B=20a=3D"11945837"; bh=5g76/TpQ85nxyJfuBzwxtAJcnLXGbj+shdT2/ScC1+w=; b=ZGmvBySn3HgQG/6ENhAfiiGOYcMx0I6W5M3F2bek+wFcbBsiUYD6XBK6 Ykg8ZBo7btMJAzikooMNyOzib6m3MNhufcEkdwD1/yZI4auw/nS2KGuhM coWGMHTI/3YJZsCwkeRMZ/Lo50bWJL3kiRaHWccg5XSOGpQoMb14+PMzG 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5423"; a="11945837" 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 Nov 2008 09:02:41 -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 mA4H2f4Z026260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Nov 2008 09:02:41 -0800 Received: from nasanexhc01.na.qualcomm.com (nasanexhc01.na.qualcomm.com [172.30.37.21]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mA4H2WaQ015648 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Nov 2008 09:02:40 -0800 (PST) Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhc01.na.qualcomm.com ([172.30.37.21]) with mapi; Tue, 4 Nov 2008 09:02:38 -0800 From: "Giaretta, Gerardo" To: Suresh Krishnan Date: Tue, 4 Nov 2008 09:02:36 -0800 Thread-Topic: [MEXT] Issue #17: Multi-homed mobile node can cause routingloop between home agents Thread-Index: Ack+lcm1Dgh+pZfKSjmQK2AvrQ0JeQACPcsA Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D5A19097@NASANEXMB08.na.qualcomm.com> References: <48E55E5F.5040101@earthlink.net>, <057632CE4CE10D45A1A3D6D19206C3A3D5AD8C39@NASANEXMB08.na.qualcomm.com> <057632CE4CE10D45A1A3D6D19206C3A3D5A19063@NASANEXMB08.na.qualcomm.com> <49107009.4050306@ericsson.com> In-Reply-To: <49107009.4050306@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can cause routingloop 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Suresh, The point I was trying to make is that the HAs will be anyway equipped to handle DoS attacks. This is done independently of the type of attack performed. So the point is the following: do we need a MIP6-specific solution to prevent the attack given the fact that we already have existing solutions which are not MIP6-specific and which will address the issue? Gerardo > -----Original Message----- > From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] > Sent: Tuesday, November 04, 2008 7:54 AM > To: Giaretta, Gerardo > Cc: Vijay Devarapalli; Charles E. Perkins; Benjamin Lim; mext@ietf.org > Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can cause routingloop > between home agents > > Hi Gerardo, > I agree more with Vijay. This attack is harder to INITIATE but way > way easier to SUSTAIN. In a direct denial of service attack, you are > limited by the bandwidth you have on your uplink and you need to keep > sending the packets. In the HA routing loop. You can use well connected > servers (Google,Youtube...) to perform your attack for you. You just > setup the bindings, request a video and just go away. The HAs will be > busy for a while :-) and they would not notice you went away. > > Cheers > Suresh > > Giaretta, Gerardo wrote: > > HI Vijay, > > > > I would actually claim the opposite. This attack needs multiple tunneling of > binding update messages in particular in case ingress filtering is in place. > This to me seems more complex than just flood one given IP address with > packets. > > > > Gerardo > > > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] > >> Sent: Monday, November 03, 2008 4:40 PM > >> To: Giaretta, Gerardo; Charles E. Perkins; Benjamin Lim > >> Cc: mext@ietf.org > >> Subject: RE: [MEXT] Issue #17: Multi-homed mobile node can cause > routingloop > >> between home agents > >> > >> Hi Gerardo, > >> > >> One difference is that this flooding attack is too easy to launch. The > >> mobile node needs to just performing the two binding registrations and > >> then start a session. > >> > >> Vijay > >> > >>> I tend to agree with Raj that this does not seem a > >>> MIP6-specific issue or at least it does not require any > >>> MIP6-specific solution. > >>> > >>> While the way of creating the routing loop is specific to > >>> MIP6, in the sense that MIP6 signaling is used, the outcome > >>> of the attack may be just a flood of packets to the HA. How > >>> is this flooding of packets different from any other > >>> DoS/flooding? Does the HA anyway be equipped to drop packets > >>> in case of packets floods? > >>> > >>> The HA may just drop packets if they exceed a ceratin > >>> threshold and optionally delete the binding. This seems to be > >>> enough in my view considering that there is anyway a long > >>> trust relationship between the attacker (i.e. the MN) and the HA. > >>> > >>> What do you think? > >>> > >>> Gerardo > >>> > >>> ________________________________________ > >>> From: mext-bounces@ietf.org [mext-bounces@ietf.org] On Behalf > >>> Of Vijay Devarapalli [vijay@wichorus.com] > >>> Sent: Friday, October 31, 2008 4:15 PM > >>> To: Charles E. Perkins; Benjamin Lim > >>> Cc: mext@ietf.org > >>> Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can > >>> cause routing loop between home agents > >>> > >>> Hi Charlie, > >>> > >>>> -----Original Message----- > >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > >>>> Behalf Of Charles E. Perkins > >>>> Sent: Thursday, October 02, 2008 4:51 PM > >>>> To: Benjamin Lim > >>>> Cc: mext@ietf.org > >>>> Subject: [MEXT] Issue #17: Multi-homed mobile node can cause > >>>> routing loop between home agents > >>>> > >>>> > >>>> Hello Benjamin, > >>>> > >>>> I have not seen any further discussion about this issue, > >>>> but I agree that the problem does exist. > >>>> > >>>> It might be possible to specify that the Home Agent should (or, > >>>> ?may?) use the RFC 2473 "Tunnel Encapsulation Limit Option". > >>>> to help avert the threat. Otherwise, the loop could persist for > >>>> an annoyingly long amount of time. It is also possible for the > >>>> home agent to enforce a policy by which a home address on > >>>> a network cannot be bound to a care-of address on the same > >>>> network, but in fact there may be cases where that would be > >>>> a valid binding. > >>>> > >>>> I hope that other people in the working group will > >>>> express an opinion about this. At minimum, we could > >>>> certainly include text within the Security Considerations > >>>> section. > >>> Recommending the use of the Tunnel Encapsulation Limit Option" in the > >>> security considerations section seems to be the best option > >>> to me. Here > >>> is some text. > >>> > >>> A malicious mobile node associated to multiple home agents could > >>> create a routing loop amongst the home agents. 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. To present this routing loop, it is recommended for > >>> the home agents to use the Tunnel Encapsulation Limit Option > >>> [RFC 2473], when tunneling packets for the mobile node. > >>> > >>> It would be good to recommend a default value for the "Tun Encap Lim" > >>> field, but I don't know what to recommend. How about '5'? > >>> This should be > >>> sufficient for any additional GTP, PMIPv6, HMIPv6 or FMIPv6 tunneling > >>> between the home agent and the mobile node. :) > >>> > >>> Vijay > >>> > >>> > >>>> The existing discussion is documented at the following URL: > >>>> http://trac.tools.ietf.org/wg/mext/trac/ticket/17 > >>>> > >>>> Regards, > >>>> Charlie P. > >>>> > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext > >>>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >>> > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 4 11:03:59 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD8A628C237; Tue, 4 Nov 2008 11:03:59 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEB2028C139 for ; Tue, 4 Nov 2008 11:03:57 -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 C5X75lhs4aSu for ; Tue, 4 Nov 2008 11:03:57 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id C375C3A6C19 for ; Tue, 4 Nov 2008 11:03:56 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Nov 2008 14:03:23 -0500 Message-ID: In-Reply-To: <491039B9.6090400@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt Thread-Index: Ack+dVcmbdMFOgZjR/yrViXknMazigAOh8xA References: <491039B9.6090400@it.uc3m.es> From: "Vijay Devarapalli" To: "marcelo bagnulo braun" , "mext" , "Julien Laganier" , "Ralph Droms" Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, We should remove the extensions to DHAAD from this document. IMO, it's a bad idea to keep extending DHAAD every time we add an extension to MIPv6. We could extend DNS-based HA lookup for discovering a home agent that is capable of NEMO prefix delegation. But I think this is also unnecessary. The mobile router can always try the next home agent in the list of the home agents if the first one does not respond to DHCPv6 messages. If none of the home agents are capable of prefix delegation, then there is nothing the mobile router can do about it, maybe use some static mobile network prefixes. We had a discussion at the last IETF and on the mailing list before on this, but there was no conclusion. Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of marcelo bagnulo braun > Sent: Tuesday, November 04, 2008 4:02 AM > To: mext; Julien Laganier; Ralph Droms > Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt > > Hi, > > We now start the WGLC for: > > DHCPv6 Prefix Delegation for NEMO > draft-ietf-mext-nemo-pd-01.txt > > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt > > > Please send comments about the draft till the November 19. > > Regards, Julien and marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 4 11:36:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66FF73A6C1C; Tue, 4 Nov 2008 11:36:29 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05C23A69EC for ; Tue, 4 Nov 2008 11:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 pQciB4jaiXjh for ; Tue, 4 Nov 2008 11:36:25 -0800 (PST) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id AB9003A696F for ; Tue, 4 Nov 2008 11:36:24 -0800 (PST) Received: from mgw-mx09.nokia.com ([192.100.105.134]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mA4JIlB0013895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 4 Nov 2008 21:18:49 +0200 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mA4JEoL6001630; Tue, 4 Nov 2008 13:15:36 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Nov 2008 21:15:18 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Nov 2008 21:15:18 +0200 Received: from 172.19.60.170 ([172.19.60.170]) by daebe104.NOE.Nokia.com ([10.241.36.13]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Nov 2008 19:15:15 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Tue, 04 Nov 2008 13:15:18 -0500 From: Basavaraj Patil To: ext Arnaud Ebalard , Message-ID: Thread-Topic: [MEXT] [Mip6] I-D Action:draft-ietf-mip6-whyauthdataoption-07.txt Thread-Index: Ack+saxxg9ENKjzR80ysDUqYEwLdrg== In-Reply-To: <87iqr4ims6.fsf@natisbad.org> Mime-version: 1.0 X-OriginalArrivalTime: 04 Nov 2008 19:15:18.0562 (UTC) FILETIME=[ACC6E820:01C93EB1] X-Nokia-AV: Clean Subject: Re: [MEXT] [Mip6] I-D Action:draft-ietf-mip6-whyauthdataoption-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello, Responses inline: On 11/3/08 3:20 PM, "ext Arnaud Ebalard" wrote: > Hi, > > Some typos, while reading the document. Some questions too. > > Internet-Drafts@ietf.org writes: > >> 2. Introduction >> >> Mobile IPv6 relies on the IPsec Security Association between the >> Mobile Node (MN) and the Home Agent (HA) for authentication of the MN >> to its HA before a binding cache can be created at the HA. An >> alternate mechanism that does not rely on the existence of the IPsec >> SA between the MN and HA for authenticating the MN is needed in >> certain deployment environments. This document captures the reasons >> that were outlined, and explains why such a mechanism was considered >> essential to ensure the applicability of MIP6 as a protocol for wider >> deployment. It was noted that the alternate solution does not imply >> that the IPsec based solution would be deprecated. It simply meant >> that in certain deployment scenarios there was a need for supporting >> MIP6 without an IPsec SA between the MN and HA. So the alternate >> solution would be in addition to the IPsec based mechanism specified >> in the base RFCs, RFC 3775 [RFC3775], RFC 3776 [RFC3776] and RFC 4877 >> [RFC4877]. It was noted that some of the challenges of deploying >> MIP6 in certain types of networks arose from the dependence on IKE >> which did not integrate will with a AAA backend infrastructure. > > ^^^^ well Ack. > >> [snip] >> >> 3. Background >> >> Mobile IPv6 signaling involves several messages. These include: >> >> o The Binding update/Binding ACK between the mobile node and the > > Binding Update/Binding Ack > Ack. >> home agent. >> >> o The route optimization signaling messages which include HoTI/Hot, > > HoT ^^^ Ack. > >> [snip] >> >> 4. Applicability Statement >> >> The authentication option specified in the Authentication Protocol >> for MIP6 [RFC4285] provides a solution for MIP6 deployment in >> environments which an operator may not require IPsec based security >> for the signaling. The reasons for an operator choosing to deploy >> MIP6 without mandating IPsec based security for signaling messages >> between the MN and HA could be many. Some of these are for example: >> >> 1. Operators deploying MIP6 in cellular networks may consider IPsec >> and IKEv2 as adding overhead to the limited bandwidth over the >> air interface. The overhead here is in terms of the bytes that >> IPsec and IKEv2 introduce to the signaling. >> >> 2. Operators may consider the number of messages between the MN and >> HA that are required to establish the IPsec SA as too many. The >> number of transactions chew into the capacity of limited >> bandwidth air interfaces when MIP6 is used in such environments. >> It also adds additional latency to the establishment of the >> binding. >> >> 3. In many deployments the authentication credentials already exist >> in a AAA server. These credentials are used for authenticating a >> user and authorizing network access. The same credentials and >> security parameters can be reused for MIP6 security as well. >> >> 4. Dynamic assignment of home agents is needed in certain >> deployments to minmize the latency of the backhaul. This is done > > ^^^^^^^ minimize Ack. > >> by allocating an HA in a visited network for example. Requiring >> IPsec SAs with home agents that are dynamically assigned is an >> overhead especially when the HA is in a visited network. >> >> 5. Signaling messages between the MN and HA may be in certain >> deployments over secure link-layers. The lower layers provide >> ciphering and security for the messages and hence the need for >> IPsec to do the same for MIP6 messages does not exist. >> >> One such example of networks that have such characteristics are cdma >> networks as defined in the 3GPP2 X.S0011-002-D [3GPP2 X.S0011-002-D] >> specification. Mobile WiMAX (Worldwide interoperability for >> Microwave Access) which is based on IEEE 802.16e also specifies in >> the network architecture the use of MIP6, with the default security >> for signaling being the authentication protocol (RFC4285). The WiMAX >> network architecture specifications are available at: [WiMAX-NWG]. > > The pointer provided in the reference section gives me a 404. I should have checked the pointer. I guess it has changed. The correct pointer is : http://www.wimaxforum.org/documents/documents/WiMAX_Forum_Network_Architectu re_Stage_2-3_Rel_1v1.2.zip Will fix it in the revised I-D. > As I am not > familiar with the document, can you just tell me if/how a MN moving from > a WiMAX link to another link (ethernet, wifi, ...) can protect its data > traffic to deal with the fact that previous point 5 does not hold > anymore. Or is it just not expected, and the MN is stuck in some kind of > closed domain (w/ secure link layer)? There is no expectation that the data traffic is secured when the MN moves to a link which may not provide link-layer security. Security for data traffic is optional. If the MN desires data traffic security, the MN would not do a handover to an access which does not provide link-layer security (as an example). Or alternatively a solution that is used in networks such as 3GPP is to establish an Ipsec SA with an intermediate gateway, refered to as PDG [Packet Data Gateway], and tunnel data traffic over the Ipsec SA to the gateway in the home network. > >> 5. Justification for the use of the authentication option >> >> The following two sections provide the reasoning for standardizing >> the authentication option based registration process for Mobile IPv6. >> Section 5.1 provides the key arguments for the use of authentication >> option. Section 5.2 provides further explanation and additional >> motivations for the authentication option. >> >> 5.1. Motivation for use of authentication option in cdma2000 wireless >> networks >> >> cdma2000 networks deployed and operational today use Mobile IPv4 for >> IP mobility. Operators have gained a significant amount of >> operational experience in the process of deploying and operating >> these networks. 3GPP2 has specified Mobile IPv6 in Revision D of the >> 3GPP2 X.S0011-002-D [3GPP2 X.S0011-002-D] specification (which >> specifies the packet data architecture). The following are the >> deployment constraints that existing CDMA networks have to deal with >> when deploying Mobility service based on IPv6: >> >> o Operators intend to leverage the Mobile IPv4 deployment and >> operational experience by ensuring that Mobile IPv6 has a similar >> deployment and operating model. >> >> o Operators will have two parallel networks, one that offers IPv4 >> mobility with MIP4 and another providing IPv6 mobility using MIP6. >> >> o The same backend subscriber profile database, security keys etc. >> are intended to be used for both Mobile IPv4 and, Mobile IPv6 >> service. However from a security standpoint, the reuse of the >> same keys with multiple algorithms/protocols is a bad idea. >> >> o The same user configuration information, i.e the identity and keys >> associated with a user will be used for IP mobility service in >> IPv4 and/or IPv6 networks. The only security association that is >> preconfigured is a shared secret between the mobile node and the >> home-AAA server. This was in contrast with an earlier version of >> the Mobile IPv6 model which required an IPsec SA between the MN >> and HA. At the time of this writing the IKEV2 based solution for > > ^^^^^ IKEv2 Ack. > >> establishing an IPsec SA [RFC4877] was not available. IKEv2 does >> enable integration with a a AAA backend. > > ^^^^^ Ack. >> >> o At the time of specifying the authentication protocol, the Mobile >> IPv6 specification did not support the dynamic assignment of home >> agent and home address. However work done in the MIP6 working >> group on bootstrapping of Mobile IPv6 as specified in [RFC5026] >> and MIP6-bootstrapping for the Integrated Scenario >> [I-D.ietf-mip6-bootstrapping-integrated-dhc] addresses this >> >> >> >> Patil & Dommety Expires May 6, 2009 [Page 7] >> >> Internet-Draft Why authdata option for MIP6 November 2008 >> >> >> deficiency. The mechanism defined in Authentication protocol for >> Mobile IPv6 [RFC4285] is capable of handling authentication even >> in the case of dynamic assignments (and is similar to what is used >> in current MIPv4 deployments). >> >> Consequently, MIP6 as specified at the time the authentication >> protocol was being specifid did not satisfy many of the deployment >> requirements. The Authentication protocol for MIP6 [RFC4285] along >> with the MN Identifier option for MIP6 [RFC4283] are enabling the >> deployment of Mobile IPv6 in a manner that is similar to what is >> deployed in cdma2000 networks today. This authentication model is >> very similar to the one adopted by the MIPv4 WG. This is explained >> in detail in the 3GPP2 X.S0011-002-D [3GPP2 X.S0011-002-D] >> specification. >> >> The earlier MIP6 deployment model which requires an IPsec SA which is >> either configured manually or established using IKE does not have >> synergy with the deployment models of 3GPP2 or WiMAX networks. This >> issue has however been alleviated with the publication of RFC4877 >> which enables the establishment of an IPsec SA using IKEv2 and is >> also able to integrate with the backend AAA infrastrucuture that is >> responsible for the authentication of the MN in 3GPP2 and WiMAX >> networks. >> >> 5.2. Additional arguments for the use of Authentication option >> >> The use of IPsec for performing Registration with a home agent is not >> always an optimal solution. While it is true that IPsec is an >> integral part of the IPv6 stack, it is still a considerable overhead >> from a deployment perspective of using IPsec as the security >> mechanism for the signaling messages between the MN and HA. This >> statement is a result of experience gained from deployment of Mobile >> IPv4. > > Was IPsec the issue or IPsec in NAT environments? Can you be more > specific on that point? The use of IPsec itself is/was the issue. Basically operators who deployed MIP4 have not really had concerns w.r.t security. And given that MIP4 works without any IPsec SAs, there was at least a view to have MIP6 operate with a similar model. > >> MIP4 does not rely on IPsec for securing the Registration >> signaling messages. >> >> Deployment of Mobile IPv6 on a large scale is possible only when the >> protocol is flexible for being adapted to various scenarios. The >> scenario being considered is the deployment in cdma2000 net- works or > > ^^^^^^^^^^ > Ack. >> WiMAX networks. cdma2000 networks are currently deployed in many >> countries today and WiMAX deployments are beginning. The packet data >> network architecture of cdma2000 [3GPP2 X.S0011-002-D] includes a >> MIP4 foreign agent/Home agent and a Radius based AAA infrastrucutre >> for authentication, authorization and accounting purposes. The AAA >> infrastructure provides the authentication capability in the case of >> Mobile IPv4. >> >> Typically, the Mobile Node shares a security association with the >> AAA-Home entity. This is the preferred mode of operation over having >> >> >> >> Patil & Dommety Expires May 6, 2009 [Page 8] >> >> Internet-Draft Why authdata option for MIP6 November 2008 >> >> >> a shared secret between the MN and HA because the AAA-Home entity >> provides a central location for provisioning and administering the >> shared secrets for a large number of mobiles (millions). This mode >> of operation also makes dynamic home address and dynamic home agent >> assignment easier. A similar approach is needed for the deployment >> of Mobile IPv6 in these networks. There is no practical mechanism to >> use IPsec directly with the AAA infrastructure with out the use of > > ^^^^^^^^ > Ack. >> IKE or some other mechanism that enables the establishment of the >> IPsec SA between the MN and HA. >> >> Mobile IPv6 as specified in RFC3775 and RFC3776 is based on a very > > refs, i.e. [RFC3775] > Ack. >> specific model for deployment. It anticipates the Mobile nodes >> having a static home IPv6 address and a designated home agent. This >> is not practical in most deployment scenarios being considered. An >> IPsec SA is expected to be created, either via manual keying or >> established dynamically by using IKE or IKEv2. These assumptions do >> not necessarily fit in very well for the deployment model envisioned >> in cdma2000 or WiMAX networks. These limitations have however been >> overcome as a result of the bootstrapping specifications as per >> [RFC5026] and MIP6-bootstrapping for the Integrated Scenario >> [I-D.ietf-mip6-bootstrapping-integrated-dhc] >> >> cdma2000 and WiMAX networks would prefer to allocate home addresses >> to MNs on a dynamic basis. The advantage of doing so is the fact >> that the HA can be assigned on a link that is close to the MNs point >> of attachment. While route-optimization negates the benefit of >> having a home-agent on a link close to the MN, it cannot be always >> guaranteed that the MN and CN will use or support route optimization. >> There may also be instances where the operator prefers to not allow >> route optimization for various reasons such as accounting aggregation >> or enforcing service contracts. In such cases an HA that is close to >> the MNs point of attachment reduces the issues of latency etc. of >> forward and reverse tunnelling of packets between the MN and HA. >> >> cdma2000 networks that are operational today have large numbers of >> subscribers who are authenticated via the AAA infrastrucure. >> Deployment of Mobile IPv6 should leverage the existing AAA >> infrastructure. The security model needed in these networks is an SA >> between the MN and AAA-Home entity. This is the primary security >> association that should be used for authenticating and authorizing >> users to utilize MIPv6 service. This SA is then used for >> establishing session keys between the MN and the dynamically assigned >> HA for authenticating subsequent binding updates and binding >> acknowledgements between them. Establishing an IPsec SA between the >> MN and HA using AAA infrastrucure was not specified for Mobile IPv6 >> at the time the Authentication protocol was being specified. RFC3776 >> explains how IKE is used for establishing the SA between the MN and >> HA. [RFC4877] has been published subsequently and hence the issue of >> >> >> >> Patil & Dommety Expires May 6, 2009 [Page 9] >> >> Internet-Draft Why authdata option for MIP6 November 2008 >> >> >> establishing an IPsec SA dynamically between the MN and HA no longer >> exists. cdma2000 network operators would prefer to assign home >> addresses to the MN on a dynamic basis and do this preferably using >> the AAA infrastrucutre which contains subscriber profile and >> capability information. This was not possible prior to the >> specification of the bootstrapping mechanism in [RFC5026]. >> >> A large subset of MNs in cdma2000 networks do not have IKE >> capability. As a result the use of RFC3776 for setting up the MN-HA >> IPsec SA is not an option. It should also be noted that IKE requires >> several transactions before it is able to establish the IPsec SA. >> [RFC4877] specifies the establishment of an IPsec SA between the MN >> and HA using IKEv2. It is possible that not all MNs in a deployment >> will support IKEv2 and hence an alternative mechanism provides the >> needed flexibility. >> >> cdma2000 network operators are extremely conscious in terms of the >> number of messages sent and received over the air-interface for >> signaling. The overhead associated with sending/receiving a large >> number of signaling messages over the air interface has a direct >> impact on the overall capacity and cost for the operator. >> Optimization of the number of messages needed for using a service >> like Mobile IPv6 is of great concern. As a result the use of IKE for >> Mobile IPv6 deployment is considered as being suboptimal in certain >> network architectures and deployment scenarios from the perspective >> of message overhead. >> >> Another downside of IKE for setting up the IPsec SA between the MN >> and HA is that IKE does not integrate very well with the Radius based >> AAA back-end. Since operators rely on the AAA infrastrucure to >> provision subscribers as well as define profiles, keys etc. in the >> AAA-Home, there is no getting away from the use of AAA in cdma2000 >> networks. IKEv2 does address this problem. However from a timeline >> perspective the availability of IKEv2 specifications for Mobile IPv6 >> Operation with IKEv2 and the revised IPsec Architecture [RFC4877] and >> implementations did not meet the need of operators that were relying >> on 3GPP2 specifications. With the specification of IKEv2 and >> publication of RFC4877 the integration with AAA backends is no longer >> an issue. > > Is it just me or the same arguments are repeated multiple times? > Let me check.... >> In summary the model of Mobile IPv6 deployment which mandated the >> existence of an IPsec SA between the MN and HA, as specified in RFCs >> 3775 and 3776, was too rigid and did not meet the requirements of >> operators building networks based on the cdma2000 [3GPP2 >> X.S0011-002-D] specifications. To address this shortcoming, the >> authentication protocol [RFC4285] was specified. >> >> >> >> >> >> Patil & Dommety Expires May 6, 2009 [Page 10] >> >> Internet-Draft Why authdata option for MIP6 November 2008 >> >> >> 6. Application of Mobile IPv6 in CDMA Networks > > I did not read that part, i.e. no comments. > >> 7. Limitations of the Authentication Protocol option >> >> While the authentication protocol as specified in [RFC4285] provides >> Mobile IPv6 [RFC3775] deployments a certain degree of flexibility it >> does have a few disadvantages as well. These are: >> >> (1) The route optimization feature specified in RFC3775 requires a >> secure transport (IPsec/ESP mode) between the MN and HA. In >> cases where the authentication protocol (RFC4285) is used as the >> means for securing the MIP6 signaling between the MN and HA, >> route optimization should be switched off unless the security of >> the signaling between the MN and HA can be guaranteed via other >> means (such as link layer security in the case of 3GPP2 >> networks). >> >> (2) The MIP6 protocol is responsible for the security of the >> signaling messages as opposed to relying on IPsec for providing >> the security. >> >> (3) In 3GPP2 networks, link-layer security mechanisms, ingress >> filtering at the PDSN, and various network domain security >> mechanisms largely ensure that reverse tunnelled packets >> received by the HA do not have spoofed source addresses, and >> their contents have not been modified. This implies the HA can >> determine the specific MN which sent the packet simply by >> verifying the outer source IP address matches the currently >> registered care-of address. Authentication of payload packets >> can be necessary for e.g.: >> >> - Authenticating signalling messages other than BU/BAck >> between the MN and HA, such as ICMPv6, MLD, and DHCPv6. >> >> - Enforcing access control to the network behind the HA. >> >> - Accounting or other flow-specific processing performed by >> the HA. >> >> This means the authentication option is of limited >> applicability in environments where the HA can received >> reverse tunneled packets with spoofed source IP addresses >> and/or modified contents. >> >> (4) As described in [RFC4285], the authentication option assumes >> that the MN-AAA shared key and security association are created >> by out-of-band mechanisms. These mechanisms are specific to >> specific deployment environments. IKEv2, on the other hand, >> supports a wide range of authentication mechanisms, such as >> certificates and EAP methods, and is independent of the access >> >> >> >> Patil & Dommety Expires May 6, 2009 [Page 17] >> >> Internet-Draft Why authdata option for MIP6 November 2008 >> >> >> network technology being used. However, it would be possible to >> specify a similar authentication and key management protocol for >> the authentication option in the future. >> >> (5) Sending the long-term user identity (NAI) in clear raises >> privacy concerns. These concerns are addressed by access >> network and network domain security mechanisms in 3GPP2 >> networks, but do limit the applicability in networks where >> sniffing other users' traffic is possible. >> >> (6) RFC 4285 does not specify a mechanism for creating the MN-HA >> shared key and SA from the MN-AAA SA (unlike similar Mobile IPv4 >> mechanisms defined in [RFC3957], and thus rely on deployment >> specific mechanisms not standardized in IETF. >> >> (7) The authentication option does not support negotiation of >> cryptographic algorithms. >> >> (8) The replay protection mechanisms in [RFC4285] rely on >> timestamps, and thus requires reasonably synchronized clocks (by >> default, +/- 7 seconds). This assumes the MN implements, and is >> configured to use, some mechanism for synchronizing its clock. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Patil & Dommety Expires May 6, 2009 [Page 18] >> >> Internet-Draft Why authdata option for MIP6 November 2008 >> >> >> 8. Security Considerations >> >> When MIP6 signaling messages use IPsec with ESP encapsulation, they >> are accorded privacy on the links over which the messages traverse. >> When MIP6 signaling messages are secured using the authentication >> protocol, such ciphering capability will have to be enabled by the >> underlying link layers. It should be noted that the MIP6 signaling >> messages are susceptible to snooping/sniffing when the authentication >> protocol [RFC4285] is used. Route optimization messages need to be >> secured between the MN and HA and this is not possible with the >> authentication protocol. Howver route optimization is not supported > > ^^^^^^^ However Ack. > >> in the current specification of the authentication protocol in >> [RFC4285]. >> >> Security issues with RFC4285 are specifically: >> >> 1. Key length. This is being addressed in the 4285bis I-D >> [I-D.ietf-mip6-rfc4285bis] at the present time. >> >> 2. The keys used for securing the signaling between the MN and HA >> are derived from a security association that exists between the >> MN and AAA. The MIP6 keys which are bootstrapped from the MN-AAA >> SA are transient. Limiting the lifetime of the keys to shorter >> periods should be recommended. >> >> 3. Location privacy is an issue in the absence of lower layer >> security in the case of shared links. >> >> >> >> 10. Conclusion >> >> Mobile IPv6 has been published as a standards track RFC [RFC3775] in >> 2004. Deployment of this protocol on a large scale is in the >> interest of the IETF and the working group as well as that of many >> people who have worked on this. A rigid model for deployment will >> cause the protocol to be limited to an academic exercise only. It is >> extremely critical that the working group consider the needs of the >> industry and the deployment scenarios and address them accordingly. >> This document captures the reasoning behind the need for the >> authentication protocol which has been published as RFC 4285. >> RFC4877 has alleviated some of the issues that have been of primary >> concern and motivators for the authentication protocol. However the >> IETF should consider the architectures of networks such as 3GPP2 and >> WiMAX and their security models and enable deployment of Mobile IPv6 >> without requiring IPsec. Thanks for the review and comments. Will revise the I-D with the corrections. -Raj > > Cheers, > > a+ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 4 12:29:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BEE73A6C6F; Tue, 4 Nov 2008 12:29:25 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA6B3A6C65 for ; Tue, 4 Nov 2008 12:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[AWL=0.897, 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 GFV4-ny2NelU for ; Tue, 4 Nov 2008 12:29:23 -0800 (PST) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 898E13A6AEA for ; Tue, 4 Nov 2008 12:29:23 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KxSWF-0000oc-0t; Tue, 04 Nov 2008 21:28:55 +0100 From: arno@natisbad.org (Arnaud Ebalard) To: Basavaraj Patil References: 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:081104:mext@ietf.org::ItGMf/RSZt16F8TB:00000tq7 X-Hashcash: 1:20:081104:basavaraj.patil@nokia.com::c2Qfhs/r7RBQYNP0:0000000000000000000000000000000000009yb1 Date: Tue, 04 Nov 2008 21:27:08 +0100 In-Reply-To: (Basavaraj Patil's message of "Tue, 04 Nov 2008 13:15:18 -0500") Message-ID: <87mygfjkyr.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] [Mip6] I-D Action:draft-ietf-mip6-whyauthdataoption-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Basavaraj Patil writes: >>> 5. Signaling messages between the MN and HA may be in certain >>> deployments over secure link-layers. The lower layers provide >>> ciphering and security for the messages and hence the need for >>> IPsec to do the same for MIP6 messages does not exist. >>> >>> One such example of networks that have such characteristics are cdma >>> networks as defined in the 3GPP2 X.S0011-002-D [3GPP2 X.S0011-002-D] >>> specification. Mobile WiMAX (Worldwide interoperability for >>> Microwave Access) which is based on IEEE 802.16e also specifies in >>> the network architecture the use of MIP6, with the default security >>> for signaling being the authentication protocol (RFC4285). The WiMAX >>> network architecture specifications are available at: [WiMAX-NWG]. >> >> The pointer provided in the reference section gives me a 404. > > I should have checked the pointer. I guess it has changed. The correct > pointer is : > http://www.wimaxforum.org/documents/documents/WiMAX_Forum_Network_Architectu > re_Stage_2-3_Rel_1v1.2.zip Funny archive: the zip file contains 2 zip files which contain pdf ;-) > Will fix it in the revised I-D. > > >> As I am not >> familiar with the document, can you just tell me if/how a MN moving from >> a WiMAX link to another link (ethernet, wifi, ...) can protect its data >> traffic to deal with the fact that previous point 5 does not hold >> anymore. Or is it just not expected, and the MN is stuck in some kind of >> closed domain (w/ secure link layer)? > > There is no expectation that the data traffic is secured when the MN moves > to a link which may not provide link-layer security. Security for data > traffic is optional. ok. > If the MN desires data traffic security, the MN would not do a > handover to an access which does not provide link-layer security > (as an example). funny answer. > Or alternatively a solution that is used in networks such as 3GPP is > to establish an Ipsec SA with an intermediate gateway, refered to > as PDG [Packet Data Gateway], and tunnel data traffic over the Ipsec > SA to the gateway in the home network. Hum. I will take a look at the content of the zip file. But allow me a last question: is there a way for the Home Agent to be deployed where the client see fits, like its home, its corporate network, ... ? Perhaps the question just does not make sense. >>> 5.2. Additional arguments for the use of Authentication option >>> >>> The use of IPsec for performing Registration with a home agent is not >>> always an optimal solution. While it is true that IPsec is an >>> integral part of the IPv6 stack, it is still a considerable overhead >>> from a deployment perspective of using IPsec as the security >>> mechanism for the signaling messages between the MN and HA. This >>> statement is a result of experience gained from deployment of Mobile >>> IPv4. >> >> Was IPsec the issue or IPsec in NAT environments? Can you be more >> specific on that point? > > The use of IPsec itself is/was the issue. Basically operators who deployed > MIP4 have not really had concerns w.r.t security. And given that MIP4 works > without any IPsec SAs, there was at least a view to have MIP6 operate with a > similar model. So the main reason is that there was no need for IPsec and no previous experience on the topic. >>> implementations did not meet the need of operators that were relying >>> on 3GPP2 specifications. With the specification of IKEv2 and >>> publication of RFC4877 the integration with AAA backends is no longer >>> an issue. >> >> Is it just me or the same arguments are repeated multiple times? >> > > Let me check.... Thanks. Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 4 12:48:24 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7EC23A6C93; Tue, 4 Nov 2008 12:48:24 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C4E3A6C84 for ; Tue, 4 Nov 2008 12:48:23 -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 Rs39npSqFqav for ; Tue, 4 Nov 2008 12:48:22 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 9DCB83A6C72 for ; Tue, 4 Nov 2008 12:48:21 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so1995572qwe.31 for ; Tue, 04 Nov 2008 12:48:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=UYQ4sDXbDZzMCwjoft92rYEhAqqmJScVBdwiyVRpf/g=; b=CqURrz9lAHFf9YXsCt/te9IRxfiok3921lF0fo1CdVDbkdBwNyxQE9yaEmFJrWGcsP tQ4e5NaukNs1qFrvFdOoHVWplSyaw7Ls1Q5QaQhrS7aR8eQyIKSOPernenVjpVEMTAti QD4pP82I3qOzDzq9q6Il/1Idx+mrVUu2jr8g4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=luOKRbDGUTl5L2exNw3pQcuMMsWg9l4eOtmAF5jJMzf6Un0/h3cV3YwFg4F6sUjbiR 90Y2Zn/yKJF6aCOUTNVhbPqUnEtF53jLK6DEGOiiHNur6wMzOXyt+s2HTvDpjGfTDSNK i/zmqZhisbkovISrNGTRQk4U2QGJxMM8qizfQ= Received: by 10.214.244.6 with SMTP id r6mr25311qah.267.1225831694151; Tue, 04 Nov 2008 12:48:14 -0800 (PST) Received: by 10.215.100.8 with HTTP; Tue, 4 Nov 2008 12:48:14 -0800 (PST) Message-ID: Date: Tue, 4 Nov 2008 12:48:14 -0800 From: "fan zhao" To: "Giaretta, Gerardo" In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D5A19097@NASANEXMB08.na.qualcomm.com> MIME-Version: 1.0 Content-Disposition: inline References: <48E55E5F.5040101@earthlink.net> <057632CE4CE10D45A1A3D6D19206C3A3D5AD8C39@NASANEXMB08.na.qualcomm.com> <057632CE4CE10D45A1A3D6D19206C3A3D5A19063@NASANEXMB08.na.qualcomm.com> <49107009.4050306@ericsson.com> <057632CE4CE10D45A1A3D6D19206C3A3D5A19097@NASANEXMB08.na.qualcomm.com> Cc: "mext@ietf.org" Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can cause routingloop 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Gerardo, Suresh and Vijay et al, I agree on the view of Suresh and Vijay. The DoS attack caused by the tunnel loop is much worse than the regular flooding attack. Furthermore, whether the generic DoS protection solution would work depends on its implementation; for example, some solution may not look into the signaling message, thus the tunnel loop can result in signaling message flooding. The details of such protection solution is not specified anywhere. Also the attack messages may look complicated, but it is not technically difficult for attackers to launch such attack. I think there are two kinds of solutions. One is to detect/drop the looped payload packets, such as using the tunnel limit option. However, such solution still results in amplified effects even the tunnel limit can be set. Another solution is to prevent the looping binding state created when the attacker sends the bogus binding update messages. I think the latter is much cleaner. What do you think? Sincerely, fan On Tue, Nov 4, 2008 at 9:02 AM, Giaretta, Gerardo wrote: > Hi Suresh, > > The point I was trying to make is that the HAs will be anyway equipped to handle DoS attacks. This is done independently of the type of attack performed. So the point is the following: do we need a MIP6-specific solution to prevent the attack given the fact that we already have existing solutions which are not MIP6-specific and which will address the issue? > > Gerardo > >> -----Original Message----- >> From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] >> Sent: Tuesday, November 04, 2008 7:54 AM >> To: Giaretta, Gerardo >> Cc: Vijay Devarapalli; Charles E. Perkins; Benjamin Lim; mext@ietf.org >> Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can cause routingloop >> between home agents >> >> Hi Gerardo, >> I agree more with Vijay. This attack is harder to INITIATE but way >> way easier to SUSTAIN. In a direct denial of service attack, you are >> limited by the bandwidth you have on your uplink and you need to keep >> sending the packets. In the HA routing loop. You can use well connected >> servers (Google,Youtube...) to perform your attack for you. You just >> setup the bindings, request a video and just go away. The HAs will be >> busy for a while :-) and they would not notice you went away. >> >> Cheers >> Suresh >> >> Giaretta, Gerardo wrote: >> > HI Vijay, >> > >> > I would actually claim the opposite. This attack needs multiple tunneling of >> binding update messages in particular in case ingress filtering is in place. >> This to me seems more complex than just flood one given IP address with >> packets. >> > >> > Gerardo >> > >> >> -----Original Message----- >> >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >> >> Sent: Monday, November 03, 2008 4:40 PM >> >> To: Giaretta, Gerardo; Charles E. Perkins; Benjamin Lim >> >> Cc: mext@ietf.org >> >> Subject: RE: [MEXT] Issue #17: Multi-homed mobile node can cause >> routingloop >> >> between home agents >> >> >> >> Hi Gerardo, >> >> >> >> One difference is that this flooding attack is too easy to launch. The >> >> mobile node needs to just performing the two binding registrations and >> >> then start a session. >> >> >> >> Vijay >> >> >> >>> I tend to agree with Raj that this does not seem a >> >>> MIP6-specific issue or at least it does not require any >> >>> MIP6-specific solution. >> >>> >> >>> While the way of creating the routing loop is specific to >> >>> MIP6, in the sense that MIP6 signaling is used, the outcome >> >>> of the attack may be just a flood of packets to the HA. How >> >>> is this flooding of packets different from any other >> >>> DoS/flooding? Does the HA anyway be equipped to drop packets >> >>> in case of packets floods? >> >>> >> >>> The HA may just drop packets if they exceed a ceratin >> >>> threshold and optionally delete the binding. This seems to be >> >>> enough in my view considering that there is anyway a long >> >>> trust relationship between the attacker (i.e. the MN) and the HA. >> >>> >> >>> What do you think? >> >>> >> >>> Gerardo >> >>> >> >>> ________________________________________ >> >>> From: mext-bounces@ietf.org [mext-bounces@ietf.org] On Behalf >> >>> Of Vijay Devarapalli [vijay@wichorus.com] >> >>> Sent: Friday, October 31, 2008 4:15 PM >> >>> To: Charles E. Perkins; Benjamin Lim >> >>> Cc: mext@ietf.org >> >>> Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can >> >>> cause routing loop between home agents >> >>> >> >>> Hi Charlie, >> >>> >> >>>> -----Original Message----- >> >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> >>>> Behalf Of Charles E. Perkins >> >>>> Sent: Thursday, October 02, 2008 4:51 PM >> >>>> To: Benjamin Lim >> >>>> Cc: mext@ietf.org >> >>>> Subject: [MEXT] Issue #17: Multi-homed mobile node can cause >> >>>> routing loop between home agents >> >>>> >> >>>> >> >>>> Hello Benjamin, >> >>>> >> >>>> I have not seen any further discussion about this issue, >> >>>> but I agree that the problem does exist. >> >>>> >> >>>> It might be possible to specify that the Home Agent should (or, >> >>>> ?may?) use the RFC 2473 "Tunnel Encapsulation Limit Option". >> >>>> to help avert the threat. Otherwise, the loop could persist for >> >>>> an annoyingly long amount of time. It is also possible for the >> >>>> home agent to enforce a policy by which a home address on >> >>>> a network cannot be bound to a care-of address on the same >> >>>> network, but in fact there may be cases where that would be >> >>>> a valid binding. >> >>>> >> >>>> I hope that other people in the working group will >> >>>> express an opinion about this. At minimum, we could >> >>>> certainly include text within the Security Considerations >> >>>> section. >> >>> Recommending the use of the Tunnel Encapsulation Limit Option" in the >> >>> security considerations section seems to be the best option >> >>> to me. Here >> >>> is some text. >> >>> >> >>> A malicious mobile node associated to multiple home agents could >> >>> create a routing loop amongst the home agents. 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. To present this routing loop, it is recommended for >> >>> the home agents to use the Tunnel Encapsulation Limit Option >> >>> [RFC 2473], when tunneling packets for the mobile node. >> >>> >> >>> It would be good to recommend a default value for the "Tun Encap Lim" >> >>> field, but I don't know what to recommend. How about '5'? >> >>> This should be >> >>> sufficient for any additional GTP, PMIPv6, HMIPv6 or FMIPv6 tunneling >> >>> between the home agent and the mobile node. :) >> >>> >> >>> Vijay >> >>> >> >>> >> >>>> The existing discussion is documented at the following URL: >> >>>> http://trac.tools.ietf.org/wg/mext/trac/ticket/17 >> >>>> >> >>>> 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 > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 4 12:57:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FA2028C1FC; Tue, 4 Nov 2008 12:57:01 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C7333A6996 for ; Tue, 4 Nov 2008 12:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.981 X-Spam-Level: X-Spam-Status: No, score=-0.981 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_53=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 ZSlPSRmlLBp9 for ; Tue, 4 Nov 2008 12:56:58 -0800 (PST) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 6C47628C1FD for ; Tue, 4 Nov 2008 12:56:57 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KxSx6-00010k-16; Tue, 04 Nov 2008 21:56:40 +0100 X-Hashcash: 1:20:081104:hesham@elevatemobile.com::3yTZ9C6SJQN7IDXf:00000000000000000000000000000000000003dfn From: arno@natisbad.org (Arnaud Ebalard) To: Hesham Soliman References: <20081103153001.5D0773A6BE5@core3.amsl.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:081104:i-d-announce@ietf.org::vuvbrFAVSSooIrnH:00000000000000000000000000000000000000000p/Q X-Hashcash: 1:20:081104:internet-drafts@ietf.org::s7Gn8415FxfNDcyK:00000000000000000000000000000000000008t9e X-Hashcash: 1:20:081104:mext@ietf.org::vB3LlonPsautwmLg:0000CA4f Date: Tue, 04 Nov 2008 21:54:53 +0100 Message-ID: <87bpwvjjoi.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] I-D Action:draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Sorry for the late review. Some comments inline. Some questions too. Internet-Drafts@ietf.org writes: > 2.1. Motivation for Using Mobile IPv6 Only > > IPv6 offers a number of improvements over today's IPv4, primarily due > to its large address space. Mobile IPv6 offers a number of > improvements over Mobile IPv4 [RFC3344], mainly due to capabilities > inherited from IPv6. For instance, route optimization and dynamic > home agent discovery can only be achieved with Mobile IPv6. > > One of the advantages of the large address space provided by IPv6 is > that it allows mobile nodes to obtain a globally unique care-of > address wherever they are. Hence, there is no need for Network > Address Translator (NAT) traversal techniques designed for Mobile > IPv4. This allows Mobile IPv6 to be a significantly simpler and more > bandwidth efficient mobility management protocol. At the same time, > during the transition towards IPv6, NAT traversal for existing > private IPv4 networks needs to be considered. This specification > introduces NAT traversal for this purpose. > > The above benefits make the case for using Mobile IPv6 only for dual > stack mobile nodes in order to allow for a long lasting mobility > solution and minimize the need to changing the mobility stack due to > the introduction of IPv6 within a deployed network. Perhaps it is just my english, but I fail to understand last paragraph. > 3.2. Mobile Prefix Solicitation and Advertisement > > According to [RFC3775], the mobile node can send a Mobile Prefix > Solicitation and receive a Mobile Prefix Advertisement containing all > prefixes advertised on the home link. > > A dual stack mobile node MAY send a Mobile Prefix Solicitation > message encapsulated in IPv4 (i.e., IPv6 in IPv4) in the case where > the mobile node has no access to IPv6 within the local network. > Securing these messages requires the mobile node to have a security > association with the home agent, using IPsec (AH or ESP) and based on > the mobile node's IPv4 care-of address as described in [RFC3775]. > Since the mobile node needs to encapsulate all IPv6 traffic sent to > the home agent into IPv4 while located in an IPv4-only visited > network, this SA would match all packets if the selectors were based > on the information in the outer header. That is, the SA selectors > being the protocol number (protocol is always IP in IP), as well as, > source and destination addresses are all common to all packets. Possibly me but last sentence seems incorrect. If not, what is its meaning? > If > this effect is not desired, the mobile node can base the SA on the > information in the inner header (i.e., using the home agent's IPv6 > address, the mobile node's home address and the ICMP protocol > number). This security association would use transport mode ESP > protection. Not clear, IMHO. > 3.3.1. Foreign Network Supports IPv6 > > In this case, the mobile node is able to configure a globally unique > IPv6 address. The mobile node will send a binding update to the IPv6 > address of its home agent, as defined in [RFC3775]. The binding > update MAY include the IPv4 home address option introduced in this > document. After receiving the binding update, the home agent creates > two binding cache entries, one for the mobile node's IPv4 home > address, and another for the mobile node's IPv6 home address. Both > entries will point to the mobile node's IPv6 care-of address. Hence, > whenever a packet is addressed to the mobile node's IPv4 or IPv6 home > addresses, the home agent will tunnel it in IPv6 to the mobile node's > IPv6 care-of address included in the binding update. Effectively, > the mobile node establishes two different tunnels, one for its IPv4 > traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6) > with a single binding update. > > In this scenario, the only addition to [RFC3775] is the inclusion of > the IPv4 home address option in the binding update message. > > After accepting the binding update and creating the corresponding > binding cache entries, the home agent MUST send a binding > acknowledgement to the mobile node as defined in [RFC3775]. In > addition, if the binding update included an IPv4 home address option, > the binding acknowledgement MUST include the IPv4 address > acknowledgment option as described later in this specification. This > option informs the mobile node whether the binding was accepted for > the IPv4 home address. If this option is not included in the binding > acknowledgement and the IPv4 home address option was included in the > binding update, the mobile node MUST assume that the home agent does > not support the IPv4 home address option and therefore SHOULD NOT > include the option in future binding updates to that home agent > address. > > When a mobile node acquires both IPv4 and IPv6 care-of addresses at > the foreign network, it SHOULD prioritize the IPv6 care-of address > for it MIPv6 its binding. Last sentence seems incorrect. > 4.1.2. The IPv4 Care-of Address Option > > This option is included in the Mobility Header including the binding > update message sent from the mobile node to a home agent or Mobility > Anchor Point. The alignment requirement for this option is 4n. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv4 Care-of address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 2: The IPv4 CoA Option > > Type > > TBD > > Length > > 6 > > Reserved > > This field is set to zero by the sender and ignored by the > receiver. > > > > > Soliman Expires May 7, 2009 [Page 15] > > Internet-Draft dsmipv6 November 2008 > > > IPv4 Care-of Address > > This field contains the mobile node's IPv4 care- of address. The care-of > 5.2. NAT Detection > > This section deals with NAT detection for the purpose of > encapsulating packets between the mobile node and the home agent. > Mobile IPv6 uses IKEv2 to establish te IPsec security association > between the mobile node and the home agent. IKE is not mandatory, it is only optional. Or did I missed a reference document? What about 'may use IKE ...' > IKEv2 has its own NAT detection mechanism. However, IKEv2's NAT > detection is only used for the purpose of setting up the IPsec SA > for secure traffic. The interactions between the two NAT traversal > mechanisms are described in Section 6 > > NAT detection is done when the initial binding update message is sent > from the mobile node to the home agent. When located in an IPv4-only > foreign link, the mobile node sends the binding update message > encapsulated in UDP and IPv4. The source address of the IPv6 packet > is the mobile node's IPv6 home address. The destination address is > the IPv6 address of the home agent. The IPv4 header contains the > IPv4 care-of address in the source address field and the IPv4 address > of the home agent in the destination address field. > > 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. > Otherwise, a NAT device was in the path and the NAT detection option > is included in the binding acknowledgement. The binding > acknowledgement, and all future packets, are then encapsulated in UDP > and IPv4. The source address in the IPv4 header is the IPv4 address > of the home agent. The destination address is the IPv4 address > received in the IPv4 header encapsulating the binding update (this > address will be different from the IPv4 care-of address when a NAT is > in the path). The source port in the packet is the home agent's > source port. The destination port is the source port received in the > binding update message. Note that the home agent stores the port > numbers and associates them with the mobile node's tunnel in order to > forward future packets. > > Upon receiving the binding acknowledgement with the NAT detection > option, the mobile node sets the tunnel to the home agent to UDP > encapsulation. Hence, all future packets to the home agent are > tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source > address in the IPv6 header is the mobile node's IPv6 home address and > the destination address is the correspondent node's IPv6 address. > All tunneled IPv4 packets will contain the mobile node's IPv4 home > address in the source address field of the inner IPv4 packet and the > correspondent node's IPv4 address in the destination address field. > The outer IPv4 header is the same whether the inner packet is IPv4 or > IPv6. > > If no NAT device was detected in the path between the mobile node and > the home agent then IPv6 packets are tunneled in an IPv4 header, > unless the home agent forces UDP encapsulation using the F flag. The > content of the inner and outer headers are identical to the UDP > encapsulation case. What if filtering somewhere prevents IP over IP but is fine with UDP encapsulated traffic. If the HA decides to go for IP over IP (i.e. does not force the F flag), this will not work. > 5.4.1. Selecting a Care-of address > > When a mobile node is in a dual stacked visited network, it will have > a choice between an IPv4 and an IPv6 care-of address. The mobile > node SHOULD prefer the IPv6 care-of address and bind it to its home > address(es). If a mobile node attempted to bind the IPv6 care-of > address to its home address(es) and the binding update timed out, the > mobile node SHOULD: > > o Resend the binding update using the exponential back-off algorithm > described in [RFC3775]. > > o If after three attempts in total a binding acknowledgement was not > received, the mobile node SHOULD send a new binding update using > the IPv4 care-of address. The exponential backoff algorithm > described in [RFC3775] should be used for re-transmission of the > binding update if needed. > > This procedure should be used to avoid scenarios where IPv6 > connectivity may not be as reliable as IPv4. This may take place > during early deployments of IPv6, or simply due to temporary outages > affecting IPv6 routing. > > It is RECOMMENDED that upon movement the mobile node does not change > the IP address family chosen for the previous binding update unless > the mobile node is aware that it has moved to a different > administrative domain where previous problems with IPv6 routing may > not be present. Repeating the above procedure upon every movement > can cause significant degradation of the mobile node's applications' > performace due to extended periods of packet losses after handover if > the routing outage is still in effect. > > When using an IPv4 care-of address and IP in IP encapsulation, if the > mobile node implementation is made aware by upper layers of > persistent packet losses , it may attempt to resend the binding > update with the F flag set, requesting UDP encapsulation for all > packets. This may avoid packet losses due to situations where local > firewalling policies prevent the use of IP in IP encapsulation. > > The effect of these address selection mechanism is to allow the > follwing preferences: following > 6. Security Considerations > > This specification allows a mobile node to send one binding update > for its IPv6 and IPv4 home addresses. This is a slight deviation > from [RFC3775] which requires one binding update per home address. > However, like [RFC3775], the IPsec security association needed to > authenticate the binding update is still based on the mobile node's > IPv6 home address. Therefore, in order to authorize the mobile > node's IPv4 home address binding, the home agent MUST store the IPv4 > address corresponding to the IPv6 address that is allocated to a > mobile node. Therefore, it is sufficient for the home agent to know > that the IPsec verification for the packet containing the binding > update was valid provided that it knows which IPv4 home address is > associated with which IPv6 home address. Hence, the security of the > IPv4 home address binding is the same as the IPv6 binding. > > In effect, associating the mobile node's IPv4 home address with its > IPv6 home address moves the authorization of the binding update for > the IPv4 address to the Mobile IPv6 implementation, which infers it > from the fact that the mobile node has an IPv6 home address and the > right credentials for sending an authentic binding update for the > IPv6 address. ok. > In cases where this specification is used for NAT traversal, it is > important to note that it has the same vulnerabilities associated > with [RFC3519]. An attacker is able to hijack the mobile node's > session with the home agent if it can modify the contents of the > outer IPv4 header. The contents of the header are not authenticated > and there is no way for the home agent to verify their validity. > Hence, a man in the middle attack where a change in the contents of > the IPv4 header can cause a legitimate mobile node's traffic to be > diverted to an illegitimate receiver independently of the > authenticity of the binding update message. > > In this specification, the binding update message MUST be protected > using ESP transport mode. Just to be sure: IP / UDP / IPv6 / ESP / MH ? > When the mobile node is located in an > IPv4-only network, the binding update message is encapsulated in UDP > as described earlier. However, UDP SHOULD NOT be used to encapsulate > the binding update message when the mobile node is located in an > IPv6-enabled network. If protection of payload traffic is needed > when the mobile node is located in an IPv4-only network, > encapsulation is done using tunnel mode ESP over port 4500 as > described in [RFC3948]. During the IKE negotiation with the home > agent, if the mobile node and home agent support the use of port > 4500, the mobile node MUST establish the security association over > port 4500, regardless of the presence of a NAT. This is done to > avoid the switching between ports 500 and 4500 and the potential > traffic disruption resulting from this switch. Is this summary correct for a MIPv6 MN that uses IPsec for both signaling and data (payload) on an IPv4 network: - signaling: IP / UDP / IPv6 / ESP / MH - data: IP / UDP / ESP / IPv6 / L4 > 6.1. Handover Interactions for IPsec and IKE > > After the mobile node detects movement it configures a new care-of > address. If the mobile node is in an IPv4-only network, it removes > binding update list entries for correspondent nodes since route > optimisation cannot be supported. This may cause inbound packet > losses as remote correspondent nodes are unaware of such movement. > To avoid confusion in the correspondent node, the mobile node SHOULD > deregister its binding with each correspondent node by sending a > deregistration binding update. The deregistration binding update > message is tunnelled to the home agent and onto the correspondent > node. This is done after the mobile node updates the home agent with > its new location as discussed below. > > The mobile node sends the binding update message to the home agent. > If the mobile node is in an IPv6-enabled network, the binding update > is sent without IPv4/UDP encapsulation. If the mobile node is in an > IPv4-only network, then after IPsec processing of the BU message, it > encapsulates the BU in UDP/IPv4 as discussed in sections 5.2 and 5.4. > In order to be able to send the binding update while in an IPv4-only > network, the mobile node needs to use the new IPv4 care-of address in > the outer header, which is different from the care-of address used in > the existing tunnel. This should be done without permanently > updating the tunnel within the mobile node's implementation in order > to allow the mobile node to receive packets on the old care-of > address until the binding acknowledgement is received. The method > used to achieve this effect is implementation dependent and is > outside the scope of this specification. This implies that the IP > forwarding function (which selects the interface or tunnel through > which a packet is sent) is not based solely on the destination > address: some IPv6 packets destined to the home agent are sent via > the existing tunnel, while BUs are sent using the new care-of > address. Since BUs are protected by IPsec, the forwarding function > cannot necessarily determine the correct treatment from the packet > headers. Thus, the DSMIPv6 implementation has to attach additional > information to BUs, and this information has to be preserved after > IPsec processing and made available to the forwarding function, or > additional DSMIP processing added to the forwarding function. > Depending on the mobile node's implementation, meeting this > requirement may require changes to the IPsec implementation. > > Upon receiving the binding update message encapsulated in UDP/IPv4, IPv4/UDP > the home agent processes it as follows. In order to allow the > DSMIPv6 implementation in the home agent to detect the presence of a > NAT on the path to the mobile node, it needs to compare the outer > IPv4 source address with the IPv4 address in the IPv4 care-of address > option. This implies that the information in the outer header will > be preserved after IPsec processing and made available to the DSMIPv6 > implementation in the home agent. Depending on the home agent's > implementation, meeting this requirement may require changes to the > IPsec implementation. > > The home agent updates its tunnel mode security association to > include the mobile node's care-of address as the remote tunnel header > address, and 4500 as the port number. The IPv4 address and port > number are likely to be wrong; the mobile node provides the correct > information in a separate exchange as described below. When the > mobile node is located in a private IPv4 network (which is detected > as described above), the new address and port number are allocated by > the NAT. The home agent will also enable or disable UDP > encapsulation for outgoing ESP packets for the purpose of NAT > traversal. > > If the Key Management Mobility Capability (K) bit was set in the > binding update, and the home agent supports this feature, the home > agent updates its IKE security associations to include the mobile > node's care-of address as the peer address and 4500 as the port > number. How? > The home agent may also need to change NAT traversal fields > in the IKE_SA to enable the dynamic update of the IP address and port > number based on the reception of authenticated IKE messages, or Following standard IKE procedure (i.e. 2.23 of RFC 4306) or is something else expected? > authenticated packets using tunnel mode ESP. How? > The dynamic updates are described in section 2.23 of RFC 4306. For IKE, yes. For other cases, it is not. > As described above, when the > mobile node is located in a private IPv4 network, the address and > port number used for IPsec and IKE traffic is not yet known by the > home agent at this point. > > The mobile node updates the IKE SA in one of two ways. If the K flag > was set in the binding acknowledgement message, the mobile node > SHOULD send an empty informational message, How does the MIPv6 modules manages to tell the IKE module to do that? > which results in the IKE > module in the home agent to dynamically update the SA information. > The IKE implementation in the home agent is REQUIRED to support this > feature. You mean on the MN, the HA or both? > Alternatively, the IKE SA should be re-negotiated. Note > that updating the IKE SA MUST take place after the mobile node has > sent the binding update and received the acknowledgement from the > home agent. > > It is important to note that the mobile node's IPv4 care-of address > seen by the DSMIPv6 module in the home agent upon receiving the > binding update may differ from the IPv4 care-of address seen by the > IKE module and the care-of address used for forwarding IPsec tunnel > mode traffic. Hence, it is probable that different modules in the > home agent will have a different care-of address that should be used > for encapsulating traffic to the mobile node. What does last sentence means? > After successfully processing the binding update, the home agent > sends the binding acknowledgement to the mobile node's care-of > address as received in the outer header of the packet containing the > binding update. Note that if the BU was rejected, the BAck is sent > to the same address where the BU was received from. This may require > special treatment in IP forwarding and/or IPsec processing which > resembles sending of BUs in the mobile node (described above). > > Upon receiving the binding acknowledgement, the mobile node updates > its local tunnel mode Security Association information to include the > tunnel header IP source address, which is the mobile node's address > and the tunnel header IP destination, which is the home agent's > address. The mobile node may also need to enable or disable UDP > encapsulation for outgoing ESP packets for the purpose of NAT > traversal and the sending of keep alives. How? > The mobile node MAY use [RFC4555] to update its IKE SA with the home > agent. Using MOBIKE requires negotiating this capability with the > home agent when establishing the SA. In this case, the mobile node > and the home agent MUST NOT update their IPsec SAs locally as this > step is performed by MOBIKE. Furthermore, the use of MOBIKE allows > the mobile node to update the SA independently of the binding update > exchange. Hence, there is no need for the mobile node to wait for a > binding acknowledgement before performing MOBIKE. The use of MOBIKE > is OPTIONAL in this specification. How IKE module and MIPv6 do synchronize on which address to use? More precisely, how is MIPv6 module expected to tell IKE implementation to use the correct address for update in MOBIKE context. > 6.2. IKE negotiation messages between the mobile node and Home Agent > > This specification defines a number of possible data encapsulation > formats depending on the mobile node's connectivity to the visited > network. When connected to an IPv6-enabled network, the tunnelling > formats are clear. However, when connected to an IPv4-only network, > care should be taken when negotiating the IKE association and the > consequential tunnelling formats used for secure and insecure > traffic. This section illustrates the IKE message exchange between > the mobile node and home agent when the mobile node is located in an > IPv4-only network. Two different IKE negotiations are considered: > > o IKEv2 operation for securing DSMIPv6 Signaling. > > o IKEv2 operation for securing Data over IPv4 > > 6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling > > A mobile node connected to an IPv4-only network SHOULD follow the > procedures described below in order to establish an SA for the > protection of binding update and binding acknowledgement messages. > > Mobile Node Home Agent > ----------- ---------- > IPv4(source_addr=V4ADDR, dest_addr=HAADDR) > UDP (500, 500) HDR, SAi1, KEi, Ni > NAT-D, NAT-D --> > > <- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) > UDP(500,X) HDR, SAr1, KEr, Nr, [CERTREQ] > NAT-D, NAT-D > > IPv4(source_addr=V4ADDR, dest_addr=HAADDR) > UDP (4500,4500) HDR, SK > {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, N(USE_TRANSPORT_MODE), > SAi2, TSi, TSr} > --> > > <-- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) > UDP (4500,Y) HDR, SK > {IDr, [CERT,] AUTH, N(USE_TRANSPORT_MODE), > SAr2, TSi, TSr} > > > The corresponding SPD entries are shown below. > > Mobile node SPD-S: > > IF local_address = home_address_1 & > > remote_address = home_agent_1 & > > proto = MH & local_mh_type = BU & remote_mh_type = BAck Then use > SA ESP transport mode > > Initiate using IDi = user_1 to address home_agent_1 > > Home Agent SPD-S: > > IF local_address = home_agent_1 & > > remote_address = home_address_1 & > > proto = MH & local_mh_type = BAck & remote_mh_type = BU Then use > SA ESP transport mode > > where home_address_1 is the mobile node's registered IPv6 home > address and home_agent_1 is the IP address of the home agent Maybe it is a dumb question: How will the IKE daemon know how to contact the HA (i mean decide to use V4ADDR as source and HAADDR as destination)? > The above should result in BU/BA messages with the following BU > received by the home agent. > > IPv4 header (src=V4ADDR, dst=HA_V4ADDR) > > UDP header (sport=Z, dport=DSMIPv6) > > IPv6 header (src=V6HOA, dst=HAADDR) > > ESP Header in Transport Mode > > Mobility header > > BU [IPv4 HAO] > > IPv4 CoA option > > (+ other as needed) > > At the home agent, following UDP de-capsulation, the binding update > is delivered to the IPsec module as shown below: > > IPv6 header (src=V6HOA, dst=HAADDR) > > ESP Header in Transport Mode > > Mobility header > > BU [IPv4 HAO] > > IPv4 CoA option > > (+other as needed) > > In addition, V4ADDR and the sport (Z) need to be passed with the > packet to ensure correct processing. > > Following IPsec processing, the binding update is delivered to the > DSMIPv6 home agent module as follows: > > IPv6 header (src=V6HOA, dst=HAADDR) > > Mobility Header > > BU [IPv4 HAO] > > IPv4 CoA option > > (+other as needed) > > In addition, V4ADDR and the sport (Z) need to be passed with the > packet to ensure correct processing. > > The binding acknowledgement sent by the home agent module to the > IPsec module is as follows: > > IPv6 header (src=HAADDR, dst=V6HOA) > > Mobility Header > > BA ([IPv4 ACK], NAT DET) > > (+ other as needed) > > In addition, V4ADDR, the sport from the BU (Z), and an indication > that vanilla UDP encapsulation must be used, need to be passed with > the packet to ensure correct processing. > > The binding acknowledgement sent by the home agent to the mobile node > is as follows: > > IPv4 header (src= HA_V4ADDR, dst=V4ADDR) > > UDP Header (sport=DSMIPv6, dport=Z) > > IPv6 header (src=HAADDR, dst=V6HOA) > > ESP Header in Transport Mode > > Mobility Header > > BA ([IPv4 ACK], NAT DET) > > 6.2.2. IKEv2 Operation for Securing Data over IPv4 > > To secure data traffic when the mobile node is located in an IPv4- > only network, the mobile node MUST establish a child_SA for that > purpose. The procedure is as follows: > > Mobile Node Home Agent > ----------- ---------- > IPv4(source_addr=V4ADDR, dest_addr=HAADDR) > UDP (4500,4500) < non-ESP Marker > HDR, SK > {[N], SA, Ni, [KEi], TSi, TSr} --> > > <--IPv4(source_addr=HAADDR, dest_addr=V4ADDR) > UDP (4500,Y) < non-ESP Marker > HDR, SK > SA, Nr, [KEr], TSi, TSr} > > > If no NAT is detected, the encapsulation used will be: > > IPv4 (source_addr=v4CoA, dest_addr=HAAddr) > > ESP > > IP (source_addr=HoA, set_addr=CNAddr) > > Upper_layer_HDR > > where IP=IPv4 or IPv6 and HoA=v4HoA or v6HoA > > If a NAT were detected, the encapsulation used will be: > > IPv4 (source_addr=v4Addr, dest_addr=HAAddr) > > UDP (sport=Y, dport=4500) > > ESP > > IP (source_addr=HoA, set_addr=CNAddr) > > Upper_layer_HDR > > Where v4CoA may be the external IPv4 address of the NAT, IP is either > an IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA. > The above format shows the packet as seen by the home agent. > > The SPD, whether a NAT were detected or not, is set as follows. Note > that this rule is designed to match all data from the MN to nodes > other than the home agent. This is done so that this rule does not > overlap with the earlier rule securing BU/BA signaling between the MN > and the HA. > > Mobile Node SPD-S: > > IF local_address = home_address & > > remote_address != home_agent & > > proto=any, then use SA ESP tunnel mode > > Initiate using IDi = user_1 to address home_agent_1 > > home agent SPD-S: > > IF local_address != home_agent & > > remote_address = home_address & > > proto=any, then use SA ESP tunnel mode > > Where home_address is the MN's registered IPv6 or IPv4 home address > and home_agent is the IPv6 or the IPv4 address of the home agent. Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 4 15:19:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8403A69A8; Tue, 4 Nov 2008 15:19:26 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E7B13A69A8 for ; Tue, 4 Nov 2008 15:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.429, 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 kxolS0W5vqEw for ; Tue, 4 Nov 2008 15:19:24 -0800 (PST) Received: from web38808.mail.mud.yahoo.com (web38808.mail.mud.yahoo.com [209.191.125.99]) by core3.amsl.com (Postfix) with SMTP id 2062D3A698D for ; Tue, 4 Nov 2008 15:19:24 -0800 (PST) Received: (qmail 78647 invoked by uid 60001); 4 Nov 2008 23:19:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=uAkuctShyS9mxWEaGX+QgFBC+wjcvDhKtrriViQT3qlKfkMa3a1tdZVpgRPQkT6M8fBtIoCt3CdooCI0XH7bBnmxP/qhgQekB5az/zHmL8JPEt+Y0TvySkvs9eX1TQComq2yNGb9RCdniiYbopdQ1JVyD3tzxdOX8W2WNqz1EBM=; X-YMail-OSG: 2ReGDucVM1nxEf62LVLkeDZdeihoWHUtnDjx4PT5hJ8gXduF17EE87PIHJCdl5eVJE3pxUb.4oGQMd.o6ztbJnHZHNjOz1cdc8AEVBxF0vPXtTlmZiizbWdFot9xfUWZZNfo0YAusuypa3vkk2KWZ13NzVaTCzjpG_82VjYRmuKQyPs- Received: from [206.16.17.212] by web38808.mail.mud.yahoo.com via HTTP; Tue, 04 Nov 2008 15:19:20 PST X-Mailer: YahooMailRC/1155.20 YahooMailWebService/0.7.247.3 Date: Tue, 4 Nov 2008 15:19:20 -0800 (PST) From: Behcet Sarikaya To: marcelo bagnulo braun MIME-Version: 1.0 Message-ID: <424099.78321.qm@web38808.mail.mud.yahoo.com> Cc: mext Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0973534377==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0973534377== Content-Type: multipart/alternative; boundary="0-977464033-1225840760=:78321" --0-977464033-1225840760=:78321 Content-Type: text/plain; charset=us-ascii Hi Marcelo, I am forwarding this part from Pascal's email he sent on June 13, 2008 basically suggesting that a simpler solutions (on the MR) needs to be considered: Once the DHCP based solution is advanced enough, I hope we consider deployements that require a different or simpler solution, and at that time, we might want to couple your work on the back end with http://tools.ietf.org/id/draft-ietf-nemo-prefix-delegation-02.txt. That would make a lot of sense to me. Regards, Behcet ________________________________ From: Vijay Devarapalli To: marcelo bagnulo braun ; mext ; Julien Laganier ; Ralph Droms Sent: Tuesday, November 4, 2008 1:03:23 PM Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt Hi Marcelo, We should remove the extensions to DHAAD from this document. IMO, it's a bad idea to keep extending DHAAD every time we add an extension to MIPv6. We could extend DNS-based HA lookup for discovering a home agent that is capable of NEMO prefix delegation. But I think this is also unnecessary. The mobile router can always try the next home agent in the list of the home agents if the first one does not respond to DHCPv6 messages. If none of the home agents are capable of prefix delegation, then there is nothing the mobile router can do about it, maybe use some static mobile network prefixes. We had a discussion at the last IETF and on the mailing list before on this, but there was no conclusion. Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of marcelo bagnulo braun > Sent: Tuesday, November 04, 2008 4:02 AM > To: mext; Julien Laganier; Ralph Droms > Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt > > Hi, > > We now start the WGLC for: > > DHCPv6 Prefix Delegation for NEMO > draft-ietf-mext-nemo-pd-01.txt > > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt > > > Please send comments about the draft till the November 19. > > Regards, Julien and marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-977464033-1225840760=:78321 Content-Type: text/html; charset=us-ascii
Hi Marcelo,
  I am forwarding this part from Pascal's email he sent on June 13, 2008 basically suggesting that a simpler solutions (on the MR) needs to be considered:

Once the DHCP based solution is advanced enough, I hope we consider deployements that require a different or simpler solution, and at that time, we might want to couple your work on the back end with http://tools.ietf.org/id/draft-ietf-nemo-prefix-delegation-02.txt. That would make a lot of sense to me.


Regards,

Behcet
From: Vijay Devarapalli <vijay@wichorus.com>
To: marcelo bagnulo braun <marcelo@it.uc3m.es>; mext <mext@ietf.org>; Julien Laganier <julien.laganier.ietf@googlemail.com>; Ralph Droms <rdroms@cisco.com>
Sent: Tuesday, November 4, 2008 1:03:23 PM
Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt

Hi Marcelo,

We should remove the extensions to DHAAD from this document. IMO, it's a
bad idea to keep extending DHAAD every time we add an extension to
MIPv6.

We could extend DNS-based HA lookup for discovering a home agent that is
capable of NEMO prefix delegation. But I think this is also unnecessary.
The mobile router can always try the next home agent in the list of the
home agents if the first one does not respond to DHCPv6 messages. If
none of the home agents are capable of prefix delegation, then there is
nothing the mobile router can do about it, maybe use some static mobile
network prefixes.

We had a discussion at the last IETF and on the mailing list before on
this, but there was no conclusion.

Vijay

> -----Original Message-----
> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On
> Behalf Of marcelo bagnulo braun
> Sent: Tuesday, November 04, 2008 4:02 AM
> To: mext; Julien Laganier; Ralph Droms
> Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt
>
> Hi,
>
> We now start the WGLC for:
>
> DHCPv6 Prefix Delegation for NEMO
> draft-ietf-mext-nemo-pd-01.txt
>
> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt
>
>
> Please send comments about the draft till the November 19.
>
> Regards, Julien and marcelo
>
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext

--0-977464033-1225840760=:78321-- --===============0973534377== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0973534377==-- From mext-bounces@ietf.org Wed Nov 5 09:14:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ECC93A69EA; Wed, 5 Nov 2008 09:14:52 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B4DC3A6864 for ; Wed, 5 Nov 2008 09:14:51 -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 JjWLydfPSc0O for ; Wed, 5 Nov 2008 09:14:50 -0800 (PST) Received: from xenon2.um.es (xenon2.um.es [155.54.212.162]) by core3.amsl.com (Postfix) with ESMTP id 1F38A3A69F1 for ; Wed, 5 Nov 2008 09:14:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon2.um.es (Postfix) with ESMTP id 1C6B4CA8BB for ; Wed, 5 Nov 2008 18:14:47 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at xenon2.telemat.um.es Received: from xenon2.um.es ([127.0.0.1]) by localhost (xenon2.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6t8TZwUjwgVX for ; Wed, 5 Nov 2008 18:14:46 +0100 (CET) Received: from aries.dif.um.es (aries.inf.um.es [155.54.210.253]) by xenon2.um.es (Postfix) with SMTP id 7C372CA4EF for ; Wed, 5 Nov 2008 18:14:46 +0100 (CET) Received: (qmail 15934 invoked from network); 5 Nov 2008 17:14:46 -0000 Received: from inf-205-158.um.es (HELO ?155.54.205.158?) (155.54.205.158) by aries.dif.um.es with SMTP; 5 Nov 2008 17:14:46 -0000 Message-ID: <4911D476.6040303@dif.um.es> Date: Wed, 05 Nov 2008 18:14:30 +0100 From: "Francisco J. Galera Cuesta" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: mext@ietf.org Subject: [MEXT] Question about draft-ietf-monami6-multiplecoa-10.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello all, I have a doubt in draft-ietf-monami6-multiplecoa-10.txt, but also = related to draft-ietf-monami6-mipv6-analysis-05 and = draft-ietf-monami6-multihoming-motivation-scenario-03.txt I'm considering a scenario such as the one specified in subsection 5.3. = ((1,n): 1 HoA, n CoAs) of draft-ietf-monami6-mipv6-analysis-05: My = scenario consists on a multihoming mobile node with several interfaces = of multiple types of access technologies. The node configures one CoA in = each interface, but it only has one HoA. The node may be moving and = changing its CoAs, but it needs ubiquitous access to the Internet, = maintaining communications when it is moving out of the coverage area of = a specific technology. My doubt is how a HoA can be binded to several interfaces? This issue is = commented in subsection 6.3.3 (Binding HoA to interface) of = draft-ietf-monami6-mipv6-analysis-05, but it is no clear for me. Is not = there a contradiction with RFC 2373 (IP Version 6 Addressing = Architecture) and especially with the following paragraph? "IPv6 addresses of all types are assigned to interfaces, not nodes. An IPv6 unicast address refers to a single interface. Since each interface belongs to a single node, any of that node's interfaces' unicast addresses may be used as an identifier for the node." Thanks in advance! -- = ---------------------------------------------------------- Francisco J. Galera Cuesta Dpto. Ingenier=EDa de la Informaci=F3n y las Comunicaciones Facultad de Inform=E1tica Universidad de Murcia 30100 Murcia (Spain) Tlf: +34 968 364644 ---------------------------------------------------------- _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Nov 5 11:27:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14A8F3A6A28; Wed, 5 Nov 2008 11:27:00 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583053A6A28 for ; Wed, 5 Nov 2008 11:26:58 -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 uJJsi1T3eS9z for ; Wed, 5 Nov 2008 11:26:57 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id BA9273A67F8 for ; Wed, 5 Nov 2008 11:26:55 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Nov 2008 14:24:22 -0500 Message-ID: In-Reply-To: <4900BB68.6090806@trajano.us.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] A comment on draft-ietf-monami6-multiplecoa-09.txt Thread-Index: Ack1OTeO0p8iSqdJS4qctaIap9tRfQKQrcEw References: <4900BB68.6090806@trajano.us.es> From: "Vijay Devarapalli" To: "Juan A. Ternero" , Subject: Re: [MEXT] A comment on draft-ietf-monami6-multiplecoa-09.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Juan, > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Juan A. Ternero > Sent: Thursday, October 23, 2008 10:59 AM > To: mext@ietf.org > Subject: [MEXT] A comment on draft-ietf-monami6-multiplecoa-09.txt > > Dear members: > Length field in Binding Identifier Mobility Option is explained > as follows: > "Length > > 8-bit unsigned integer. Length of the option, in octets, > excluding the Type and Length fields. It MUST be set to either 4, > 12, or 20 depending on the care-of address field. When the > care-of address is not carried by this option, the length value > MUST be set to 4. If the IPv4 care-of address is stored in the > care-of address field, the length MUST be 12. Otherwise, the > Length value MUST be set to 20 for IPv6 care-of address." > > According to that, possible values of length field are only 4-12-20 > (4=No_CoA, 12=IPv4_CoA, 20=IPv6_CoA). > > I have read last versions of the draft and I have detected that > possible values of this field changed from 4-8-20 in version 06 > to 4-12-20 in version 07. > I think the correct ones are 4-8-20, because an IPv4 address only > adds 4 bytes to the option. > > In that case, alignment should be modified from: > > "The Binding Identifier Mobility Option has an alignment requirement > of 2n if the Care-of Address field is not present. Otherwise, it has > the alignment requirement of 8n + 2." > > to > > "The Binding Identifier Mobility Option has an alignment requirement > of 2n if the Care-of Address field is not present, 4n+2 if the Care-of > Address field stores an IPv4 address, an 8n+2 if the Care-of Address > field stores an IPv6 address." Thanks for catching this. Will be fixed in the next version. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 6 01:57:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E01F3A6993; Thu, 6 Nov 2008 01:57:26 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9783A6993 for ; Thu, 6 Nov 2008 01:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[AWL=0.150, 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 aY7vpYGPXPUm for ; Thu, 6 Nov 2008 01:57:23 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 938AC3A69FC for ; Thu, 6 Nov 2008 01:57:22 -0800 (PST) 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 mA69vGNO024900; Thu, 6 Nov 2008 18:57:16 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id mA69vHP19493; Thu, 6 Nov 2008 18:57:17 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili01) with ESMTP id mA69vEM14018; Thu, 6 Nov 2008 18:57:14 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Nov 2008 17:56:56 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD02F58A50@pslexc01.psl.local> In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D5A19097@NASANEXMB08.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Issue #17: Multi-homed mobile node can cause routingloop between home agents Thread-Index: Ack+lcm1Dgh+pZfKSjmQK2AvrQ0JeQACPcsAAFR121A= References: <48E55E5F.5040101@earthlink.net>, <057632CE4CE10D45A1A3D6D19206C3A3D5AD8C39@NASANEXMB08.na.qualcomm.com><057632CE4CE10D45A1A3D6D19206C3A3D5A19063@NASANEXMB08.na.qualcomm.com><49107009.4050306@ericsson.com> <057632CE4CE10D45A1A3D6D19206C3A3D5A19097@NASANEXMB08.na.qualcomm.com> From: "Mohana Jeyatharan" To: "Giaretta, Gerardo" , "Suresh Krishnan" Cc: mext@ietf.org Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can cause routingloop 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Gerardo, Of course as you say currently implemented HAs have adequate mechanisms to handle DoS attack. However, if such attacks are launched frequently, it is essential for the HA to detect this early and handle it as quickly as possibly. Thus it is essential to solve it. Yes, as you say there is an existing mechanism but it is not sufficient in the sense that it is general and not targetting at identifying the tunnel loop as early as possible and acting on it such that looping does not occur again! Moreover in the current mechanism what value to set for TEL? The MN's home agents are unknown to the first tunnel entry node and it is difficult to set adequate value TEL. Also, the important thing is that a loop is detected and it is not a mere completion of TEL option decrementation. Once loop is detected all concerned nodes are alerted and this prevents further such loops being formed due to malicious MN. All this is explanied in the ID called draft-ng-intarea-tunnel-loop-00 which provides further details. Moreover the solution is simple and requires some changes to the HA and I don't see why it cannot be incorporated into MIPv6 Bis. BR, Mohana > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Giaretta, Gerardo > Sent: Wednesday, November 05, 2008 1:03 AM > To: Suresh Krishnan > Cc: mext@ietf.org > Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can > cause routingloop between home agents > > Hi Suresh, > > The point I was trying to make is that the HAs will be anyway > equipped to handle DoS attacks. This is done independently of > the type of attack performed. So the point is the following: > do we need a MIP6-specific solution to prevent the attack > given the fact that we already have existing solutions which > are not MIP6-specific and which will address the issue? > > Gerardo > > > -----Original Message----- > > From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] > > Sent: Tuesday, November 04, 2008 7:54 AM > > To: Giaretta, Gerardo > > Cc: Vijay Devarapalli; Charles E. Perkins; Benjamin Lim; > mext@ietf.org > > Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can cause > > routingloop between home agents > > > > Hi Gerardo, > > I agree more with Vijay. This attack is harder to > INITIATE but way > > way easier to SUSTAIN. In a direct denial of service > attack, you are > > limited by the bandwidth you have on your uplink and you > need to keep > > sending the packets. In the HA routing loop. You can use well > > connected servers (Google,Youtube...) to perform your > attack for you. > > You just setup the bindings, request a video and just go > away. The HAs > > will be busy for a while :-) and they would not notice you > went away. > > > > Cheers > > Suresh > > > > Giaretta, Gerardo wrote: > > > HI Vijay, > > > > > > I would actually claim the opposite. This attack needs multiple > > > tunneling of > > binding update messages in particular in case ingress > filtering is in place. > > This to me seems more complex than just flood one given IP address > > with packets. > > > > > > Gerardo > > > > > >> -----Original Message----- > > >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] > > >> Sent: Monday, November 03, 2008 4:40 PM > > >> To: Giaretta, Gerardo; Charles E. Perkins; Benjamin Lim > > >> Cc: mext@ietf.org > > >> Subject: RE: [MEXT] Issue #17: Multi-homed mobile node can cause > > routingloop > > >> between home agents > > >> > > >> Hi Gerardo, > > >> > > >> One difference is that this flooding attack is too easy > to launch. > > >> The mobile node needs to just performing the two binding > > >> registrations and then start a session. > > >> > > >> Vijay > > >> > > >>> I tend to agree with Raj that this does not seem a > MIP6-specific > > >>> issue or at least it does not require any MIP6-specific > solution. > > >>> > > >>> While the way of creating the routing loop is specific > to MIP6, in > > >>> the sense that MIP6 signaling is used, the outcome of > the attack > > >>> may be just a flood of packets to the HA. How is this > flooding of > > >>> packets different from any other DoS/flooding? Does the > HA anyway > > >>> be equipped to drop packets in case of packets floods? > > >>> > > >>> The HA may just drop packets if they exceed a ceratin threshold > > >>> and optionally delete the binding. This seems to be > enough in my > > >>> view considering that there is anyway a long trust relationship > > >>> between the attacker (i.e. the MN) and the HA. > > >>> > > >>> What do you think? > > >>> > > >>> Gerardo > > >>> > > >>> ________________________________________ > > >>> From: mext-bounces@ietf.org [mext-bounces@ietf.org] On > Behalf Of > > >>> Vijay Devarapalli [vijay@wichorus.com] > > >>> Sent: Friday, October 31, 2008 4:15 PM > > >>> To: Charles E. Perkins; Benjamin Lim > > >>> Cc: mext@ietf.org > > >>> Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can > > >>> cause routing loop between home agents > > >>> > > >>> Hi Charlie, > > >>> > > >>>> -----Original Message----- > > >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > >>>> Behalf Of Charles E. Perkins > > >>>> Sent: Thursday, October 02, 2008 4:51 PM > > >>>> To: Benjamin Lim > > >>>> Cc: mext@ietf.org > > >>>> Subject: [MEXT] Issue #17: Multi-homed mobile node can cause > > >>>> routing loop between home agents > > >>>> > > >>>> > > >>>> Hello Benjamin, > > >>>> > > >>>> I have not seen any further discussion about this issue, but I > > >>>> agree that the problem does exist. > > >>>> > > >>>> It might be possible to specify that the Home Agent should (or, > > >>>> ?may?) use the RFC 2473 "Tunnel Encapsulation Limit Option". > > >>>> to help avert the threat. Otherwise, the loop could > persist for > > >>>> an annoyingly long amount of time. It is also > possible for the > > >>>> home agent to enforce a policy by which a home address on a > > >>>> network cannot be bound to a care-of address on the > same network, > > >>>> but in fact there may be cases where that would be a valid > > >>>> binding. > > >>>> > > >>>> I hope that other people in the working group will express an > > >>>> opinion about this. At minimum, we could certainly > include text > > >>>> within the Security Considerations section. > > >>> Recommending the use of the Tunnel Encapsulation Limit > Option" in > > >>> the security considerations section seems to be the > best option to > > >>> me. Here is some text. > > >>> > > >>> A malicious mobile node associated to multiple home > agents could > > >>> create a routing loop amongst the home agents. 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. To present this routing loop, it is > recommended for > > >>> the home agents to use the Tunnel Encapsulation Limit Option > > >>> [RFC 2473], when tunneling packets for the mobile node. > > >>> > > >>> It would be good to recommend a default value for the > "Tun Encap Lim" > > >>> field, but I don't know what to recommend. How about '5'? > > >>> This should be > > >>> sufficient for any additional GTP, PMIPv6, HMIPv6 or FMIPv6 > > >>> tunneling between the home agent and the mobile node. :) > > >>> > > >>> Vijay > > >>> > > >>> > > >>>> The existing discussion is documented at the following URL: > > >>>> http://trac.tools.ietf.org/wg/mext/trac/ticket/17 > > >>>> > > >>>> 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 > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 6 08:43:11 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2AE73A68DD; Thu, 6 Nov 2008 08:43:10 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 309BE3A68DD for ; Thu, 6 Nov 2008 08:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.85 X-Spam-Level: X-Spam-Status: No, score=-2.85 tagged_above=-999 required=5 tests=[AWL=0.912, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 WJswwGdFm7Pp for ; Thu, 6 Nov 2008 08:43:09 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 38EC13A657C for ; Thu, 6 Nov 2008 08:43:08 -0800 (PST) Received: from dummyhost1.it.uc3m.es (dummyhost33.it.uc3m.es [163.117.139.223])by smtp02.uc3m.es (Postfix) with ESMTP id AFC575CB734;Thu, 6 Nov 2008 17:35:50 +0100 (CET) Message-ID: <49131CE6.3080609@it.uc3m.es> Date: Thu, 06 Nov 2008 17:35:50 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Vijay Devarapalli References: <491039B9.6090400@it.uc3m.es> In-Reply-To: X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-22.8644 TC:1F TRN:33 TV:5.5.1026(16264.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier , mext Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Anyone else has an opinion on whether we should cover DHAAD on this = document or not? regards, marcelo Vijay Devarapalli escribi=F3: > Hi Marcelo, > > We should remove the extensions to DHAAD from this document. IMO, it's a > bad idea to keep extending DHAAD every time we add an extension to > MIPv6. > > We could extend DNS-based HA lookup for discovering a home agent that is > capable of NEMO prefix delegation. But I think this is also unnecessary. > The mobile router can always try the next home agent in the list of the > home agents if the first one does not respond to DHCPv6 messages. If > none of the home agents are capable of prefix delegation, then there is > nothing the mobile router can do about it, maybe use some static mobile > network prefixes. = > > We had a discussion at the last IETF and on the mailing list before on > this, but there was no conclusion. > > Vijay > > = >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On = >> Behalf Of marcelo bagnulo braun >> Sent: Tuesday, November 04, 2008 4:02 AM >> To: mext; Julien Laganier; Ralph Droms >> Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt >> >> Hi, >> >> We now start the WGLC for: >> >> DHCPv6 Prefix Delegation for NEMO >> draft-ietf-mext-nemo-pd-01.txt >> >> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt >> >> >> Please send comments about the draft till the November 19. >> >> Regards, Julien and marcelo >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> = > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 6 10:30:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E81E3A69EF; Thu, 6 Nov 2008 10:30:40 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55BBF3A69E2 for ; Thu, 6 Nov 2008 10:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.168 X-Spam-Level: X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[AWL=0.431, 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 ZLpRwHG4Ko8Y for ; Thu, 6 Nov 2008 10:30:38 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 3BA0D3A68FA for ; Thu, 6 Nov 2008 10:30:38 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mA6ISVu6028776; Thu, 6 Nov 2008 20:30:06 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 20:30:02 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 20:30:02 +0200 Received: from 172.19.60.151 ([172.19.60.151]) by daebe104.NOE.Nokia.com ([10.241.36.13]) with Microsoft Exchange Server HTTP-DAV ; Thu, 6 Nov 2008 18:29:47 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Thu, 06 Nov 2008 12:29:50 -0600 From: Basavaraj Patil To: Marcelo Bagnulo , Vijay Devarapalli Message-ID: Thread-Topic: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt Thread-Index: AclAPadA/KtNPic1R0ejN4rGdzabqw== In-Reply-To: <49131CE6.3080609@it.uc3m.es> Mime-version: 1.0 X-OriginalArrivalTime: 06 Nov 2008 18:30:02.0315 (UTC) FILETIME=[AE9801B0:01C9403D] X-Nokia-AV: Clean Cc: Julien Laganier , mext Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I agree with Vijay. No reason to have DHAAD text in this document. -Raj On 11/6/08 10:35 AM, "Marcelo Bagnulo" wrote: > Anyone else has an opinion on whether we should cover DHAAD on this > document or not? > = > regards, marcelo > = > = > Vijay Devarapalli escribi=F3: >> Hi Marcelo, >> = >> We should remove the extensions to DHAAD from this document. IMO, it's a >> bad idea to keep extending DHAAD every time we add an extension to >> MIPv6. >> = >> We could extend DNS-based HA lookup for discovering a home agent that is >> capable of NEMO prefix delegation. But I think this is also unnecessary. >> The mobile router can always try the next home agent in the list of the >> home agents if the first one does not respond to DHCPv6 messages. If >> none of the home agents are capable of prefix delegation, then there is >> nothing the mobile router can do about it, maybe use some static mobile >> network prefixes. >> = >> We had a discussion at the last IETF and on the mailing list before on >> this, but there was no conclusion. >> = >> Vijay >> = >> = >>> -----Original Message----- >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>> Behalf Of marcelo bagnulo braun >>> Sent: Tuesday, November 04, 2008 4:02 AM >>> To: mext; Julien Laganier; Ralph Droms >>> Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt >>> = >>> Hi, >>> = >>> We now start the WGLC for: >>> = >>> DHCPv6 Prefix Delegation for NEMO >>> draft-ietf-mext-nemo-pd-01.txt >>> = >>> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt >>> = >>> = >>> Please send comments about the draft till the November 19. >>> = >>> Regards, Julien and marcelo >>> = >>> = >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> = >>> = >> = >> = > = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 6 10:43:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2023A69F5; Thu, 6 Nov 2008 10:43:15 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509C33A69C4 for ; Thu, 6 Nov 2008 10:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 LfSiy6vBZZaO for ; Thu, 6 Nov 2008 10:43:13 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1F3123A6940 for ; Thu, 6 Nov 2008 10:43:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,559,1220227200"; d="scan'208";a="26962730" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 06 Nov 2008 18:42:23 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mA6IgNZY025650; Thu, 6 Nov 2008 13:42:23 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mA6IgNKO019210; Thu, 6 Nov 2008 18:42:23 GMT Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 13:42:23 -0500 Received: from 161.44.65.201 ([161.44.65.201]) by xmb-rtp-212.amer.cisco.com ([64.102.31.111]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Thu, 6 Nov 2008 18:41:37 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Thu, 06 Nov 2008 13:41:36 -0500 From: Ralph Droms To: Basavaraj Patil , Marcelo Bagnulo , Vijay Devarapalli Message-ID: Thread-Topic: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt Thread-Index: AclAPadA/KtNPic1R0ejN4rGdzabqwAAaTPw In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 06 Nov 2008 18:42:23.0343 (UTC) FILETIME=[6847E7F0:01C9403F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2778; t=1225996943; x=1226860943; c=relaxed/simple; s=rtpdkim1001; 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]=20WGLC=20for=20draft-ietf-mext-n emo-pd-01.txt |Sender:=20 |To:=20Basavaraj=20Patil=20,=0A= 20=20=20=20=20=20=20=20Marcelo=20Bagnulo=20,=0A=20=20=20=20=20=20=20=20Vijay=20Devarapalli=20; bh=O691Y3pW+jbIssTMpEFnBwRMode01XY7DdzZEYtcvHs=; b=o7noFaynziZ04Xkwt7hYMnP+oWis5sU71H4kl9dYgTR/nCMZjOmBfZZU1f kXEWYjQzIzBJUCJHN+ZPlgNOvBjzNtYCfDtlsNnle379qujQcnO4f9E+X0v/ bNYbG3Qu1/; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Julien Laganier , mext Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I'd be inclined to agree about not needing DHAAD if I knew more about typical deployment scenarios. What's the likelihood of multiple HAs and the likelihood that some subset won't support NEMO PD? If the typical scnenario is just one or two Has, then a search across all HAs for NEMO PD is probably a reasonable solution. - Ralph On 11/6/08 Nov 6, 2008,1:29 PM, "Basavaraj Patil" wrote: > = > I agree with Vijay. No reason to have DHAAD text in this document. > = > -Raj > = > = > On 11/6/08 10:35 AM, "Marcelo Bagnulo" wrote: > = >> Anyone else has an opinion on whether we should cover DHAAD on this >> document or not? >> = >> regards, marcelo >> = >> = >> Vijay Devarapalli escribi=F3: >>> Hi Marcelo, >>> = >>> We should remove the extensions to DHAAD from this document. IMO, it's a >>> bad idea to keep extending DHAAD every time we add an extension to >>> MIPv6. >>> = >>> We could extend DNS-based HA lookup for discovering a home agent that is >>> capable of NEMO prefix delegation. But I think this is also unnecessary. >>> The mobile router can always try the next home agent in the list of the >>> home agents if the first one does not respond to DHCPv6 messages. If >>> none of the home agents are capable of prefix delegation, then there is >>> nothing the mobile router can do about it, maybe use some static mobile >>> network prefixes. >>> = >>> We had a discussion at the last IETF and on the mailing list before on >>> this, but there was no conclusion. >>> = >>> Vijay >>> = >>> = >>>> -----Original Message----- >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>> Behalf Of marcelo bagnulo braun >>>> Sent: Tuesday, November 04, 2008 4:02 AM >>>> To: mext; Julien Laganier; Ralph Droms >>>> Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt >>>> = >>>> Hi, >>>> = >>>> We now start the WGLC for: >>>> = >>>> DHCPv6 Prefix Delegation for NEMO >>>> draft-ietf-mext-nemo-pd-01.txt >>>> = >>>> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt >>>> = >>>> = >>>> Please send comments about the draft till the November 19. >>>> = >>>> Regards, Julien and marcelo >>>> = >>>> = >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> = >>>> = >>> = >>> = >> = >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 6 10:49:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC8743A6813; Thu, 6 Nov 2008 10:49:48 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF68A3A657C for ; Thu, 6 Nov 2008 10:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.215 X-Spam-Level: X-Spam-Status: No, score=-6.215 tagged_above=-999 required=5 tests=[AWL=0.384, 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 z5I++U9vTwan for ; Thu, 6 Nov 2008 10:49:47 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id E70F13A6813 for ; Thu, 6 Nov 2008 10:49:46 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mA6ImoM3021394; Thu, 6 Nov 2008 12:49:33 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 20:49:32 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 20:49:31 +0200 Received: from 172.19.60.151 ([172.19.60.151]) by daebe104.NOE.Nokia.com ([10.241.36.13]) with Microsoft Exchange Server HTTP-DAV ; Thu, 6 Nov 2008 18:49:29 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Thu, 06 Nov 2008 12:49:33 -0600 From: Basavaraj Patil To: ext Ralph Droms , Marcelo Bagnulo , Vijay Devarapalli Message-ID: Thread-Topic: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt Thread-Index: AclAPadA/KtNPic1R0ejN4rGdzabqwAAaTPwAABHFSY= In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 06 Nov 2008 18:49:31.0685 (UTC) FILETIME=[6797B550:01C94040] X-Nokia-AV: Clean Cc: Julien Laganier , mext Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org With no practical experience in terms of MIP6 deployments, I would say that there is essentially no real information to make a decision. Multiple HAs are likely. But even in such a case, the numbers would be small. = -Raj On 11/6/08 12:41 PM, "ext Ralph Droms" wrote: > I'd be inclined to agree about not needing DHAAD if I knew more about > typical deployment scenarios. What's the likelihood of multiple HAs and = the > likelihood that some subset won't support NEMO PD? If the typical scnena= rio > is just one or two Has, then a search across all HAs for NEMO PD is proba= bly > a reasonable solution. > = > - Ralph > = > = > On 11/6/08 Nov 6, 2008,1:29 PM, "Basavaraj Patil" > wrote: > = >> = >> I agree with Vijay. No reason to have DHAAD text in this document. >> = >> -Raj >> = >> = >> On 11/6/08 10:35 AM, "Marcelo Bagnulo" wrote: >> = >>> Anyone else has an opinion on whether we should cover DHAAD on this >>> document or not? >>> = >>> regards, marcelo >>> = >>> = >>> Vijay Devarapalli escribi=F3: >>>> Hi Marcelo, >>>> = >>>> We should remove the extensions to DHAAD from this document. IMO, it's= a >>>> bad idea to keep extending DHAAD every time we add an extension to >>>> MIPv6. >>>> = >>>> We could extend DNS-based HA lookup for discovering a home agent that = is >>>> capable of NEMO prefix delegation. But I think this is also unnecessar= y. >>>> The mobile router can always try the next home agent in the list of the >>>> home agents if the first one does not respond to DHCPv6 messages. If >>>> none of the home agents are capable of prefix delegation, then there is >>>> nothing the mobile router can do about it, maybe use some static mobile >>>> network prefixes. >>>> = >>>> We had a discussion at the last IETF and on the mailing list before on >>>> this, but there was no conclusion. >>>> = >>>> Vijay >>>> = >>>> = >>>>> -----Original Message----- >>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>>> Behalf Of marcelo bagnulo braun >>>>> Sent: Tuesday, November 04, 2008 4:02 AM >>>>> To: mext; Julien Laganier; Ralph Droms >>>>> Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt >>>>> = >>>>> Hi, >>>>> = >>>>> We now start the WGLC for: >>>>> = >>>>> DHCPv6 Prefix Delegation for NEMO >>>>> draft-ietf-mext-nemo-pd-01.txt >>>>> = >>>>> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt >>>>> = >>>>> = >>>>> Please send comments about the draft till the November 19. >>>>> = >>>>> Regards, Julien and marcelo >>>>> = >>>>> = >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> = >>>>> = >>>> = >>>> = >>> = >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> = >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 6 13:36:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0020728C0EE; Thu, 6 Nov 2008 13:36:51 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AC3B3A6A6C for ; Thu, 6 Nov 2008 13:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.653 X-Spam-Level: X-Spam-Status: No, score=-105.653 tagged_above=-999 required=5 tests=[AWL=0.946, BAYES_00=-2.599, 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 rAoOhoY6TwZ7 for ; Thu, 6 Nov 2008 13:36:50 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 964B33A6ACF for ; Thu, 6 Nov 2008 13:36:50 -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=1226007408; x=1257543408; 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:=20marcelo=20bagnulo=20braun=20, =0D=0A=20=20=20=20=20=20=20=20Vijay=20Devarapalli=0D=0A =09|CC:=20Julien=20Laganier=20,=0D=0A=20=20=20=20=20=20 =20=20mext=0D=0A=09|Date:=20Thu,=206=20Nov =202008=2013:36:19=20-0800|Subject:=20RE:=20[MEXT]=20WGLC =20for=20draft-ietf-mext-nemo-pd-01.txt|Thread-Topic:=20[ MEXT]=20WGLC=20for=20draft-ietf-mext-nemo-pd-01.txt |Thread-Index:=20AclALshSNRnfYvQQRCOXH5qMOPyUKwAKMVvw |Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3D5A19306@ NASANEXMB08.na.qualcomm.com>|References:=20<491039B9.6090 400@it.uc3m.es>=0D=0A=20=09=0D=0A=20<49131CE6 .3080609@it.uc3m.es>|In-Reply-To:=20<49131CE6.3080609@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"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5426"=3B=20a=3D"12174923"; bh=aP3E/VEUcauZCrmTUXDu8uktfJu2CUDhmKxu/y3htrE=; b=O6dHHe6DAzoyVj27LsVZ90Lqk/SEth2FTwEKRHXj9rzU6zi0219HxhjO L0eeg5uqVvzaxEHurIo44xAiLg0IHT6bKXU20NrbERW1uJzCT506kblvh N09ICj2PhSQTc+Od958BvmEsm9Nhensg5cK5tpNrA+4G5v155j5y7UXSX 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5426"; a="12174923" 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; 06 Nov 2008 13:36:38 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mA6Lab2f016422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Nov 2008 13:36:38 -0800 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mA6LaCue022706 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 Nov 2008 13:36:35 -0800 Received: from nasanexhub02.na.qualcomm.com (10.46.143.120) by nasanexhc03.na.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 6 Nov 2008 13:36:21 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Thu, 6 Nov 2008 13:36:21 -0800 From: "Giaretta, Gerardo" To: marcelo bagnulo braun , Vijay Devarapalli Date: Thu, 6 Nov 2008 13:36:19 -0800 Thread-Topic: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt Thread-Index: AclALshSNRnfYvQQRCOXH5qMOPyUKwAKMVvw Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D5A19306@NASANEXMB08.na.qualcomm.com> References: <491039B9.6090400@it.uc3m.es> <49131CE6.3080609@it.uc3m.es> In-Reply-To: <49131CE6.3080609@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Julien Laganier , mext Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I also think we should not have DHAAD on this document. If we need somethin= g about capability of the HA, we need it in the discovery defined in 5026 a= nd not for DHAAD; but I think we don't need to indicate the support of PD a= t the discovery phase at all Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > marcelo bagnulo braun > Sent: Thursday, November 06, 2008 8:36 AM > To: Vijay Devarapalli > Cc: Julien Laganier; mext > Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt > = > Anyone else has an opinion on whether we should cover DHAAD on this > document or not? > = > regards, marcelo > = > = > Vijay Devarapalli escribi=F3: > > Hi Marcelo, > > > > We should remove the extensions to DHAAD from this document. IMO, it's a > > bad idea to keep extending DHAAD every time we add an extension to > > MIPv6. > > > > We could extend DNS-based HA lookup for discovering a home agent that is > > capable of NEMO prefix delegation. But I think this is also unnecessary. > > The mobile router can always try the next home agent in the list of the > > home agents if the first one does not respond to DHCPv6 messages. If > > none of the home agents are capable of prefix delegation, then there is > > nothing the mobile router can do about it, maybe use some static mobile > > network prefixes. > > > > We had a discussion at the last IETF and on the mailing list before on > > this, but there was no conclusion. > > > > Vijay > > > > > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > >> Behalf Of marcelo bagnulo braun > >> Sent: Tuesday, November 04, 2008 4:02 AM > >> To: mext; Julien Laganier; Ralph Droms > >> Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt > >> > >> Hi, > >> > >> We now start the WGLC for: > >> > >> DHCPv6 Prefix Delegation for NEMO > >> draft-ietf-mext-nemo-pd-01.txt > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt > >> > >> > >> Please send comments about the draft till the November 19. > >> > >> Regards, Julien and marcelo > >> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > >> > > > > > = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 00:48:09 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5A553A6B36; Fri, 7 Nov 2008 00:48:08 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09843A6B36 for ; Fri, 7 Nov 2008 00:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.75 X-Spam-Level: X-Spam-Status: No, score=-3.75 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 O2zr9ePfxSfu for ; Fri, 7 Nov 2008 00:48:06 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id F3BAB3A6B34 for ; Fri, 7 Nov 2008 00:48:05 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.139.83])by smtp01.uc3m.es (Postfix) with ESMTP id 8A2B5ACA3F2;Fri, 7 Nov 2008 09:47:29 +0100 (CET) Message-ID: <491400A0.50700@it.uc3m.es> Date: Fri, 07 Nov 2008 09:47:28 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: mext X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-8.7484 TC:1F TRN:16 TV:5.5.1026(16264.005) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier Subject: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, There has been a very long debate on whether we should keep or remove dhaad from rfc3775bis. We would like to ask people to express whether they want to keep dhaad or remove it from rfc3775bis at this point. Please send your opinion before the 14 of november. (we are going to consider for this poll only the opinions sent as reply to this email, so even if you think your opinion is well known, reply to this email stating it again, so it can be considered as part of this poll) Regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 02:40:36 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D5C3A69FE; Fri, 7 Nov 2008 02:40:36 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5072D3A69FE for ; Fri, 7 Nov 2008 02:40:35 -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 E6nn82E-1kch for ; Fri, 7 Nov 2008 02:40:34 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 6C9243A6892 for ; Fri, 7 Nov 2008 02:40:34 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1226054423!10736843!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 30026 invoked from network); 7 Nov 2008 10:40:23 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-153.messagelabs.com with SMTP; 7 Nov 2008 10:40:23 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mA7AeHbQ010410; Fri, 7 Nov 2008 03:40:17 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id mA7AeHUZ019506; Fri, 7 Nov 2008 04:40:17 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id mA7AeFqS019493; Fri, 7 Nov 2008 04:40:16 -0600 (CST) Message-ID: <49141B0F.1080806@gmail.com> Date: Fri, 07 Nov 2008 11:40:15 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: marcelo bagnulo braun References: <491400A0.50700@it.uc3m.es> In-Reply-To: <491400A0.50700@it.uc3m.es> X-Antivirus: avast! (VPS 081106-0, 06/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org marcelo bagnulo braun wrote: > Hi, > > There has been a very long debate on whether we should keep or remove > dhaad from rfc3775bis. We would like to ask people to express > whether they want to keep dhaad or remove it from rfc3775bis at this > point. Please send your opinion before the 14 of november. DHAAD has been implemented and tested for interoperability, and is used by NEMOv6 rfc3963 as well - keep it in rfc3775bis. Alex > > (we are going to consider for this poll only the opinions sent as > reply to this email, so even if you think your opinion is well known, > reply to this email stating it again, so it can be considered as part > of this poll) > > Regards, marcelo > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 07:00:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E28433A6972; Fri, 7 Nov 2008 07:00:17 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5771B3A6972 for ; Fri, 7 Nov 2008 07:00:16 -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 FQpzbuQasoqu for ; Fri, 7 Nov 2008 07:00:15 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.245.51]) by core3.amsl.com (Postfix) with SMTP id 53CD83A690A for ; Fri, 7 Nov 2008 07:00:15 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1226069997!36409030!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 25135 invoked from network); 7 Nov 2008 14:59:57 -0000 Received: from unknown (HELO motgate3.mot.com) (136.182.1.13) by server-4.tower-119.messagelabs.com with SMTP; 7 Nov 2008 14:59:57 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id mA7ExuTY027462; Fri, 7 Nov 2008 07:59:56 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id mA7Exugf001194; Fri, 7 Nov 2008 08:59:56 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id mA7Extox001181; Fri, 7 Nov 2008 08:59:55 -0600 (CST) Message-ID: <491457EA.7070908@gmail.com> Date: Fri, 07 Nov 2008 15:59:54 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: marcelo bagnulo braun References: <491039B9.6090400@it.uc3m.es> <49131CE6.3080609@it.uc3m.es> In-Reply-To: <49131CE6.3080609@it.uc3m.es> X-Antivirus: avast! (VPS 081106-0, 06/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org marcelo bagnulo braun wrote: > Anyone else has an opinion on whether we should cover DHAAD on this = > document or not? I'd say yes. Using DHAAD to remotely discover a DHCP Server may make sense, as the MN can't use link-local scoped multicast - the typical method to discover a DHCP Server - when it's away from home. Alex > = > regards, marcelo > = > = > Vijay Devarapalli escribi=F3: >> Hi Marcelo, >> = >> We should remove the extensions to DHAAD from this document. IMO, >> it's a bad idea to keep extending DHAAD every time we add an >> extension to MIPv6. >> = >> We could extend DNS-based HA lookup for discovering a home agent >> that is capable of NEMO prefix delegation. But I think this is also >> unnecessary. The mobile router can always try the next home agent >> in the list of the home agents if the first one does not respond to >> DHCPv6 messages. If none of the home agents are capable of prefix >> delegation, then there is nothing the mobile router can do about >> it, maybe use some static mobile network prefixes. We had a >> discussion at the last IETF and on the mailing list before on this, >> but there was no conclusion. >> = >> Vijay >> = >> = >>> -----Original Message----- From: mext-bounces@ietf.org >>> [mailto:mext-bounces@ietf.org] On Behalf Of marcelo bagnulo braun >>> Sent: Tuesday, November 04, 2008 4:02 AM To: mext; Julien >>> Laganier; Ralph Droms Subject: [MEXT] WGLC for >>> draft-ietf-mext-nemo-pd-01.txt >>> = >>> Hi, >>> = >>> We now start the WGLC for: >>> = >>> DHCPv6 Prefix Delegation for NEMO draft-ietf-mext-nemo-pd-01.txt >>> = >>> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt >>> = >>> = >>> = >>> Please send comments about the draft till the November 19. >>> = >>> Regards, Julien and marcelo >>> = >>> = >>> _______________________________________________ MEXT mailing list >>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >>> = >>> = >> = >> = > = > _______________________________________________ MEXT mailing list = > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > = ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email = ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 07:22:28 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086B128C127; Fri, 7 Nov 2008 07:22:28 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E582628C0F5 for ; Fri, 7 Nov 2008 07:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=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 dZjyV2CCrHpj for ; Fri, 7 Nov 2008 07:22:25 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.245.51]) by core3.amsl.com (Postfix) with SMTP id 8746328C10E for ; Fri, 7 Nov 2008 07:22:25 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1226071289!27613360!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 25574 invoked from network); 7 Nov 2008 15:21:29 -0000 Received: from unknown (HELO motgate3.mot.com) (136.182.1.13) by server-9.tower-119.messagelabs.com with SMTP; 7 Nov 2008 15:21:29 -0000 Received: from il27exr02.cig.mot.com (il27exr02.mot.com [10.17.196.71]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id mA7FLTws001336; Fri, 7 Nov 2008 08:21:29 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr02.cig.mot.com (8.13.1/Vontu) with SMTP id mA7FLS0a003955; Fri, 7 Nov 2008 09:21:28 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il27exr02.cig.mot.com (8.13.1/8.13.0) with ESMTP id mA7FLRcP003888; Fri, 7 Nov 2008 09:21:27 -0600 (CST) Message-ID: <49145CF6.7010409@gmail.com> Date: Fri, 07 Nov 2008 16:21:26 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: marcelo bagnulo braun References: <491039B9.6090400@it.uc3m.es> In-Reply-To: <491039B9.6090400@it.uc3m.es> X-Antivirus: avast! (VPS 081106-0, 06/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org marcelo bagnulo braun wrote: > Hi, > > We now start the WGLC for: > > DHCPv6 Prefix Delegation for NEMO draft-ietf-mext-nemo-pd-01.txt > > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt > > > Please send comments about the draft till the November 19. I think it's very close to LC, my oppinion is. Arnaud had some relevant points on IPsec and use of DHCPv6-PD between MR and HA - if I'm to refine that: what do the SAs and SPDs look like on MR and HA when they do DHCPv6-PD? Example? Then, if potentially using IKE, what's the sequence: IKE/BUBack/DHCP? Or IKE/DHCP/BUBack? Or DHCP/IKE/BUBack? Or maybe IKE for DHCPv6PD/BUBAck is too early to introduce now? Then only the shared key method maybe. Also, the draft has no picture. I can draw topology pictures as ASCII art showing MR, HA, DR, RR potentially a Relay and LFN and maybe CN. I can also draw a diagram of the exchanged messages - does the BU/BAck happen before or after the DHCP Sol/Advertise/Req/Ack? I'm asking because the draft currentlyis not clear on this: > The MR initiates a DHCPv6 message exchange for prefix delegation > whenever it establishes an MR-HA tunnel to its HA. 'Whenver' - ok, but before or after? This clarification can help the implementer. Section 3.3.2 (and in other places) implies MR may be a Relay, or at least run the DHCPv6 Relay software: > 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. Huh? I thought the HA could be a Relay, but not the MR be a Relay too. BEcause earlier it says this: > To use DHCPv6PD for Mobile Networks, the HA assumes the role of > either the DR or a DHCPv6 relay agent and the MR assumes the role of > the RR. Throughout the remainder of this document, the HA will be > assumed to be acting as a DHCPv6PD DR or relay agent and the MR will > be assumed to be acting as a RR. I understand ok why it's proposed the MR to be a Relay (such that it unicasts the requests across the Internet, instead of sending link-local multicast packets). But the MR could simply be a client and put the multicast request in the tunnel _if_ the tunnel is established prior to the DHCPv6-PD exchange. Which brings it back (se mord la queue) to the question whether DHCPv6-PD happens prior or after the BU/BAck exchange. Let's fix this; I can draw the pictures. Alex > > Regards, Julien and marcelo > > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 09:56:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C50803A69B8; Fri, 7 Nov 2008 09:56:51 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200903A6B3A for ; Fri, 7 Nov 2008 09:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 blP5nC753ymP for ; Fri, 7 Nov 2008 09:56:49 -0800 (PST) Received: from web38802.mail.mud.yahoo.com (web38802.mail.mud.yahoo.com [209.191.125.93]) by core3.amsl.com (Postfix) with SMTP id E3DAC3A6ACD for ; Fri, 7 Nov 2008 09:56:48 -0800 (PST) Received: (qmail 32582 invoked by uid 60001); 7 Nov 2008 17:56:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=xzZi3lpu8jYPDIaHC3yS1zNZtkt4sm5fiXBs8oZtpxPPFzUFeekYDhsNP+bFF8NyiQR1rBqLWyDk3Vlpu3oJugBdoI1J0L8KL/MuxlK0FywPTjYFo+F3mTW7BrkBAa1wcNO26y31pYpcS5KYJ7xqKyXhyo7NFP4WLVjQERPv9Ng=; X-YMail-OSG: TxxQZG8VM1mPVUg1.HrsqeYIKGvPOIF5qgOKJ_lWxhRmYBvfpGpY0qe2YWPCc8S6xtFhT0nx26XOWk.CpObTDPbZavnhbmn1DD9FcF3wUuUfibMLSC4QZ4e4ArDRkD7O58GUgQcBHz7WJnP_slLqbRzPBWryMzBwc09qrnvDiqpewlM- Received: from [206.16.17.212] by web38802.mail.mud.yahoo.com via HTTP; Fri, 07 Nov 2008 09:56:26 PST X-Mailer: YahooMailRC/1155.20 YahooMailWebService/0.7.260.1 References: <491039B9.6090400@it.uc3m.es> <49145CF6.7010409@gmail.com> Date: Fri, 7 Nov 2008 09:56:26 -0800 (PST) From: Behcet Sarikaya To: Alexandru Petrescu , marcelo bagnulo braun MIME-Version: 1.0 Message-ID: <730452.32196.qm@web38802.mail.mud.yahoo.com> Cc: Julien Laganier , mext Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1382737300==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1382737300== Content-Type: multipart/alternative; boundary="0-834121434-1226080586=:32196" --0-834121434-1226080586=:32196 Content-Type: text/plain; charset=us-ascii Hi Alex, You have a mobile RR in this draft. That's why you need a DHCP Relay Agent at the MR's egress interface. If you're saying no, then simply talk to Francis. Regards, Behcet ________________________________ From: Alexandru Petrescu To: marcelo bagnulo braun Cc: Julien Laganier ; mext Sent: Friday, November 7, 2008 9:21:26 AM Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt marcelo bagnulo braun wrote: > Hi, > > We now start the WGLC for: > > DHCPv6 Prefix Delegation for NEMO draft-ietf-mext-nemo-pd-01.txt > > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt > > > Please send comments about the draft till the November 19. I think it's very close to LC, my oppinion is. Arnaud had some relevant points on IPsec and use of DHCPv6-PD between MR and HA - if I'm to refine that: what do the SAs and SPDs look like on MR and HA when they do DHCPv6-PD? Example? Then, if potentially using IKE, what's the sequence: IKE/BUBack/DHCP? Or IKE/DHCP/BUBack? Or DHCP/IKE/BUBack? Or maybe IKE for DHCPv6PD/BUBAck is too early to introduce now? Then only the shared key method maybe. Also, the draft has no picture. I can draw topology pictures as ASCII art showing MR, HA, DR, RR potentially a Relay and LFN and maybe CN. I can also draw a diagram of the exchanged messages - does the BU/BAck happen before or after the DHCP Sol/Advertise/Req/Ack? I'm asking because the draft currentlyis not clear on this: > The MR initiates a DHCPv6 message exchange for prefix delegation whenever it establishes an MR-HA tunnel to its HA. 'Whenver' - ok, but before or after? This clarification can help the implementer. Section 3.3.2 (and in other places) implies MR may be a Relay, or at least run the DHCPv6 Relay software: > 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. Huh? I thought the HA could be a Relay, but not the MR be a Relay too. BEcause earlier it says this: > To use DHCPv6PD for Mobile Networks, the HA assumes the role of either the DR or a DHCPv6 relay agent and the MR assumes the role of the RR. Throughout the remainder of this document, the HA will be assumed to be acting as a DHCPv6PD DR or relay agent and the MR will be assumed to be acting as a RR. I understand ok why it's proposed the MR to be a Relay (such that it unicasts the requests across the Internet, instead of sending link-local multicast packets). But the MR could simply be a client and put the multicast request in the tunnel _if_ the tunnel is established prior to the DHCPv6-PD exchange. Which brings it back (se mord la queue) to the question whether DHCPv6-PD happens prior or after the BU/BAck exchange. Let's fix this; I can draw the pictures. Alex > > Regards, Julien and marcelo > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-834121434-1226080586=:32196 Content-Type: text/html; charset=us-ascii
Hi Alex,
  You have a mobile RR in this draft. That's why you need a DHCP Relay Agent at the MR's egress interface.
  If you're saying no, then simply talk to Francis.

Regards,

Behcet

From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
Cc: Julien Laganier <julien.laganier.ietf@googlemail.com>; mext <mext@ietf.org>
Sent: Friday, November 7, 2008 9:21:26 AM
Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt

marcelo bagnulo braun wrote:
> Hi,
>
> We now start the WGLC for:
>
> DHCPv6 Prefix Delegation for NEMO draft-ietf-mext-nemo-pd-01.txt
>
> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt
>
>
> Please send comments about the draft till the November 19.

I think it's very close to LC, my oppinion is.

Arnaud had some relevant points on IPsec and use of DHCPv6-PD between MR
and HA - if I'm to refine that: what do the SAs and SPDs look
like on MR and HA when they do DHCPv6-PD?  Example?  Then, if
potentially using IKE, what's the sequence: IKE/BUBack/DHCP?  Or
IKE/DHCP/BUBack?  Or DHCP/IKE/BUBack?  Or maybe IKE for DHCPv6PD/BUBAck
is too early to introduce now?  Then only the shared key method maybe.

Also, the draft has no picture.  I can draw topology pictures as ASCII
art showing MR, HA, DR, RR potentially a Relay and LFN and maybe CN.
I can also draw a diagram of the exchanged messages - does
the BU/BAck happen before or after the DHCP Sol/Advertise/Req/Ack?  I'm
asking because the draft currentlyis not clear on this:

> The MR initiates a DHCPv6 message exchange for prefix delegation whenever it establishes an MR-HA tunnel to its HA.

'Whenver' - ok, but before or after?

This clarification can help the implementer.

Section 3.3.2 (and in other places) implies MR may be a Relay, or at
least run the DHCPv6 Relay software:
> 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.

Huh?  I thought the HA could be a Relay, but not the MR be a Relay too.
BEcause earlier it says this:
> To use DHCPv6PD for Mobile Networks, the HA assumes the role of either the DR or a DHCPv6 relay agent and the MR assumes the role of the RR.  Throughout the remainder of this document, the HA will be assumed to be acting as a DHCPv6PD DR or relay agent and the MR will be assumed to be acting as a RR.

I understand ok why it's proposed the MR to be a Relay (such that it
unicasts the requests across the Internet, instead of sending link-local
multicast packets).  But the MR could simply be a client and put the
multicast request in the tunnel _if_ the tunnel is established prior to
the DHCPv6-PD exchange.  Which brings it back (se mord la queue) to the
question whether DHCPv6-PD happens prior or after the BU/BAck exchange.
Let's fix this; I can draw the pictures.

Alex

>
> Regards, Julien and marcelo
>
>
> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext
>


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext

--0-834121434-1226080586=:32196-- --===============1382737300== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1382737300==-- From mext-bounces@ietf.org Fri Nov 7 12:09:13 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E65E63A69A4; Fri, 7 Nov 2008 12:09:12 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F02583A6B77 for ; Fri, 7 Nov 2008 12:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.147 X-Spam-Level: X-Spam-Status: No, score=-5.147 tagged_above=-999 required=5 tests=[AWL=-1.152, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rb5EHiE33cYA for ; Fri, 7 Nov 2008 12:09:10 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.245.51]) by core3.amsl.com (Postfix) with SMTP id DD2E53A696F for ; Fri, 7 Nov 2008 12:09:09 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1226088537!35964315!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 13257 invoked from network); 7 Nov 2008 20:08:57 -0000 Received: from unknown (HELO motgate3.mot.com) (136.182.1.13) by server-14.tower-119.messagelabs.com with SMTP; 7 Nov 2008 20:08:57 -0000 Received: from il27exr04.cig.mot.com ([10.17.196.73]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id mA7K8tBj018894; Fri, 7 Nov 2008 13:08:55 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id mA7K8suY012539; Fri, 7 Nov 2008 14:08:54 -0600 (CST) Received: from [127.0.0.1] (zuk02-5537.corp.mot.com [10.129.40.73] (may be forged)) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id mA7K8r5X012527; Fri, 7 Nov 2008 14:08:53 -0600 (CST) Message-ID: <4914A053.3010707@gmail.com> Date: Fri, 07 Nov 2008 21:08:51 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Behcet Sarikaya References: <491039B9.6090400@it.uc3m.es> <49145CF6.7010409@gmail.com> <730452.32196.qm@web38802.mail.mud.yahoo.com> In-Reply-To: <730452.32196.qm@web38802.mail.mud.yahoo.com> X-Antivirus: avast! (VPS 081106-0, 06/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext Subject: Re: [MEXT] 'serialized' DHCP Relays (was: WGLC for draft-ietf-mext-nemo-pd-01.txt) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Behcet Sarikaya wrote: > Hi Alex, You have a mobile RR in this draft. YEs I agree, it is as a mobile Requesting Router. > That's why you need a DHCP Relay Agent at the MR's egress interface. If we consider MR to also be a DHCP Relay Agent on its egress interface, and - in addition to being a DHCPClient - have the DHCPServer's address pre-configured in its configuration file, then this paragraph is incomplete: > To use DHCPv6PD for Mobile Networks, the HA assumes the role of > either the DR or a DHCPv6 relay agent and the MR assumes the role of > the RR. Throughout the remainder of this document, the HA will be > assumed to be acting as a DHCPv6PD DR or relay agent and the MR will > be assumed to be acting as a RR. because at its end it should say "the MR will be assumed to be acting as a RR and as a DHCP Relay", instead of just saying "the MR will be assumed to be acting as a RR". BEsides, whereas it's common to have a topology like this: DHCPClient-----DHCPRelay-----------DHCPServer (I think) DHCPv6 does not suggest to have a topology with 'serialized' DHCPRelays, like this: DHCPClient-----DHCPRelay-----DHCPRelay---....----DHCPRelay----DHCPServer If we agree on this impossibility, then once the MR is a DHCPRelay the HA can't be a DHCPRelay at the same time, and vice-versa. Which would imply further changes in the above mentioned paragraph. > If you're saying no, then simply talk to Francis. Well I guess he's reading this list and if he considers the above remark worth a dime he'd reply a cent. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 12:58:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0627728C127; Fri, 7 Nov 2008 12:58:50 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B338E28C127 for ; Fri, 7 Nov 2008 12:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.361 X-Spam-Level: X-Spam-Status: No, score=-6.361 tagged_above=-999 required=5 tests=[AWL=0.238, 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 dnESN+1qqL5m for ; Fri, 7 Nov 2008 12:58:45 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 9B19E3A6BA5 for ; Fri, 7 Nov 2008 12:58:44 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mA7KwLLa031605; Fri, 7 Nov 2008 22:58:22 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Nov 2008 22:58:20 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Nov 2008 22:58:20 +0200 Received: from 172.19.60.131 ([172.19.60.131]) by daebe104.NOE.Nokia.com ([10.241.36.13]) with Microsoft Exchange Server HTTP-DAV ; Fri, 7 Nov 2008 20:58:08 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Fri, 07 Nov 2008 14:58:10 -0600 From: Basavaraj Patil To: Marcelo Bagnulo , mext Message-ID: Thread-Topic: [MEXT] consensus call on dhaad Thread-Index: AclBG4p6C5sYNFInN0C9CV3/KXcawg== In-Reply-To: <491400A0.50700@it.uc3m.es> Mime-version: 1.0 X-OriginalArrivalTime: 07 Nov 2008 20:58:20.0704 (UTC) FILETIME=[90DC2A00:01C9411B] X-Nokia-AV: Clean Cc: Julien Laganier Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, With the boostrapping specifications for MIP6 (RFC5026, draft-ietf-mip6-bootstrapping-integrated-dhc-06.txt and, draft-ietf-mip6-hiopt) and the capability to obtain HNP and HoA via IKEv2 (RFC4877), I think there are enough mechanisms to discover an HA, HoA and Home prefix. So there is no need for DHAAD. MIP6 is overloaded with unnecessary features such as DHAAD and hence getting rid of it from 3775bis would be a simplification of the base protocol. Hence I would be in favor of dropping DHAAD from 3775bis. -Basavaraj On 11/7/08 2:47 AM, "Marcelo Bagnulo" wrote: > Hi, > > There has been a very long debate on whether we should keep or remove > dhaad from rfc3775bis. > We would like to ask people to express whether they want to keep dhaad > or remove it from rfc3775bis at this point. > Please send your opinion before the 14 of november. > > (we are going to consider for this poll only the opinions sent as reply > to this email, so even if you think your opinion is well known, reply to > this email stating it again, so it can be considered as part of this poll) > > Regards, marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 13:00:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9527628C126; Fri, 7 Nov 2008 13:00:31 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1639E28C126 for ; Fri, 7 Nov 2008 13:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.779 X-Spam-Level: X-Spam-Status: No, score=-103.779 tagged_above=-999 required=5 tests=[AWL=-1.180, 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 AUPcLRcISCef for ; Fri, 7 Nov 2008 13:00:29 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 0F2223A6B95 for ; Fri, 7 Nov 2008 13:00:29 -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=1226091626; x=1257627626; 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:=20Basavaraj=20Patil=20, =0D=0A=20=20=20=20=20=20=20=20Marcelo=20Bagnulo=0D=0A=09< marcelo@it.uc3m.es>,=20mext=20|CC:=20Julie n=20Laganier=20 |Date:=20Fri,=207=20Nov=202008=2013:00:16=20-0800 |Subject:=20RE:=20[MEXT]=20consensus=20call=20on=20dhaad |Thread-Topic:=20[MEXT]=20consensus=20call=20on=20dhaad |Thread-Index:=20AclBG4p6C5sYNFInN0C9CV3/KXcawgAAEFmw |Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3D5A193FC@ NASANEXMB08.na.qualcomm.com>|References:=20<491400A0.5070 0@it.uc3m.es>=0D=0A=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 100,188,5427"=3B=20a=3D"12225078"; bh=vm2V7b7+4vxOOXqgi/g90mfs5U9meiFCWqoi7vWirZ8=; b=t9PjFF1X19QR4Y62THAgNsBK+L0hFBEhh01N7CVEwl/OA/bxuOqRNBxg V1fE9grVF4qALQcf62O6yt1PtlNauDkhEXhaFaa+cG5qKc7X8WKf+WerJ SMEEa/KN2P1rViUJUv+r9k/0I+FMTJL+ACNBw6yUTuncdn3AaEK/JRgaG k=; X-IronPort-AV: E=McAfee;i="5100,188,5427"; a="12225078" 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; 07 Nov 2008 13:00:21 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mA7L0KdY018744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Nov 2008 13:00:20 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mA7L0KTN005836 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Nov 2008 13:00:20 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Fri, 7 Nov 2008 13:00:19 -0800 From: "Giaretta, Gerardo" To: Basavaraj Patil , Marcelo Bagnulo , mext Date: Fri, 7 Nov 2008 13:00:16 -0800 Thread-Topic: [MEXT] consensus call on dhaad Thread-Index: AclBG4p6C5sYNFInN0C9CV3/KXcawgAAEFmw Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D5A193FC@NASANEXMB08.na.qualcomm.com> References: <491400A0.50700@it.uc3m.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Julien Laganier Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I support Raj's point of view. Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Basavaraj Patil > Sent: Friday, November 07, 2008 12:58 PM > To: Marcelo Bagnulo; mext > Cc: Julien Laganier > Subject: Re: [MEXT] consensus call on dhaad > > > Hi Marcelo, > > With the boostrapping specifications for MIP6 (RFC5026, > draft-ietf-mip6-bootstrapping-integrated-dhc-06.txt and, > draft-ietf-mip6-hiopt) and the capability to obtain HNP and HoA via IKEv2 > (RFC4877), I think there are enough mechanisms to discover an HA, HoA and > Home prefix. So there is no need for DHAAD. > > MIP6 is overloaded with unnecessary features such as DHAAD and hence getting > rid of it from 3775bis would be a simplification of the base protocol. > > Hence I would be in favor of dropping DHAAD from 3775bis. > > -Basavaraj > > > On 11/7/08 2:47 AM, "Marcelo Bagnulo" wrote: > > > Hi, > > > > There has been a very long debate on whether we should keep or remove > > dhaad from rfc3775bis. > > We would like to ask people to express whether they want to keep dhaad > > or remove it from rfc3775bis at this point. > > Please send your opinion before the 14 of november. > > > > (we are going to consider for this poll only the opinions sent as reply > > to this email, so even if you think your opinion is well known, reply to > > this email stating it again, so it can be considered as part of this poll) > > > > Regards, marcelo > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 13:24:28 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035F43A6B94; Fri, 7 Nov 2008 13:24:28 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8BC73A6B94 for ; Fri, 7 Nov 2008 13:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 w56Kp6r59oip for ; Fri, 7 Nov 2008 13:24:26 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 089303A6B7E for ; Fri, 7 Nov 2008 13:24:25 -0800 (PST) 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 mA7LO0xL005635; Fri, 7 Nov 2008 15:24:01 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Nov 2008 15:23:59 -0600 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Nov 2008 15:23:59 -0600 Message-ID: <4914B192.4020406@ericsson.com> Date: Fri, 07 Nov 2008 16:22:26 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: marcelo bagnulo braun References: <491400A0.50700@it.uc3m.es> In-Reply-To: <491400A0.50700@it.uc3m.es> X-OriginalArrivalTime: 07 Nov 2008 21:23:59.0356 (UTC) FILETIME=[25F7D3C0:01C9411F] Cc: Julien Laganier , mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, While I have no strong position on the issue, if I was forced to pick, I would pick removing DHAAD and not burden all our future specs and implementations with this seldom used feature. Thanks Suresh marcelo bagnulo braun wrote: > Hi, > > There has been a very long debate on whether we should keep or remove > dhaad from rfc3775bis. > We would like to ask people to express whether they want to keep dhaad > or remove it from rfc3775bis at this point. > Please send your opinion before the 14 of november. > > (we are going to consider for this poll only the opinions sent as reply > to this email, so even if you think your opinion is well known, reply to > this email stating it again, so it can be considered as part of this poll) > > Regards, marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 13:35:19 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6DC33A6BB3; Fri, 7 Nov 2008 13:35:19 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE0733A6BB3; Fri, 7 Nov 2008 13:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 pO9Vj6VO+GeM; Fri, 7 Nov 2008 13:35:17 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 8A9183A6B8C; Fri, 7 Nov 2008 13:35:17 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mA7LZBHe018022; Fri, 7 Nov 2008 23:35:11 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Nov 2008 23:35:10 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Nov 2008 23:35:10 +0200 Received: from 172.19.60.131 ([172.19.60.131]) by daebe104.NOE.Nokia.com ([10.241.36.13]) with Microsoft Exchange Server HTTP-DAV ; Fri, 7 Nov 2008 21:35:08 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Fri, 07 Nov 2008 15:35:10 -0600 From: Basavaraj Patil To: ext Vijay Devarapalli , "Narayanan, Vidya" , Jonne Soininen Message-ID: Thread-Topic: [netlmm] Conclusion and way forward for PMIP6-MIP6 interactions Thread-Index: AclBILWzJq/jNzMmO0GLUHAmjTbKrA== In-Reply-To: <49149931.9060202@wichorus.com> Mime-version: 1.0 X-OriginalArrivalTime: 07 Nov 2008 21:35:10.0676 (UTC) FILETIME=[B61B2140:01C94120] X-Nokia-AV: Clean Cc: "netlmm@ietf.org" , mext Subject: Re: [MEXT] [netlmm] Conclusion and way forward for PMIP6-MIP6 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, On 11/7/08 1:38 PM, "ext Vijay Devarapalli" wrote: > Hi Vidya, Jonne, > > For a mobile node that has two interfaces and wants to use both > interfaces, while using the same home address across the two interfaces, > we need some extensions. Mobile IPv6 [RFC 3775] does not allow a mobile > node to use both the home link and the visited link simultaneously when > the mobile node has only one home address. > > For the home agent to allow the mobile node to use both the home link > and the visited link, we need the MCoA extensions. The MCoA extension allows the MN to register multiple CoAs associated with the same HoA. The scenario where the MN is on its home link as a virtue of PMIP6 on one interface and continues to be on a foreign link on another IMO are not captured. Sec 5.6. Returning Home: Simultaneous Home and Visited Link Operation of I-D: draft-ietf-monami6-multiplecoa does provide some guidelines but given that the PMIP6 aspect is not covered, it may be worthwhile to revisit the issue. > Specifically, the > mobile node must indicate to the home agent that it wants to do so. Agree. But this is specified in the MCoA I-D, right? > > It doesn't matter if the home link is provided by PMIPv6, GTP or direct > attachment to the home link, the above is valid. In the case of PMIP6, there is a BCE for the MN in the LMA, unlike the MIP6 case where the MN returns home and the BCE is deleted. > > Instead, what I see being designed is a solution where the GTP/PMIPv6 > process on the GGSN/LMA/HA entity maintains state that is independent of > the HA process on the same GGSN/LMA/HA entity. In fact what you are > trying to force through consensus here, i.e., keep the MIPv6 and PMIPv6 > BCE separate is actually influenced by an SDO-specific scenario. While an SDO has an interest in keeping the BCEs separate, why would the same not apply in general as well? Given the scenario, I do think that having separate BCEs is the correct approach. > I > believe there is a scenario in 3GPP where folks wanted the mobile node > to be able to keep its GPRS/UMTS interface up, while using another > interface like WiFi, so that it can quickly fall back to the GRPS/UMTS > interface, when it loses WiFi access. And you are saying, we shouldn't > consider SDO-specific scenarios. When you said that, my initial reaction > was "you gotta be kidding me". :) And what is wrong with such a scenario and for the WG to address it. Because the scenario is not SDO specific. > > I am not saying the above is not a valid scenario. Lets support it, but > in the right away, by an explicit indication from the mobile node to the > home agent that it does want to use the home link and the visited link > at the same time. This would allow the GGSN/LMA/HA entity maintain > forwarding state for both the home link and the visited link at the same > time. This would work irrespective of how the home link is created. Good. As I said it may be worthwhile to add the PMIP6 created home link scenario to the MCoA I-D. > Lastly, we do need to consider the single radio handover in the > PMIPv6-MIPv6 interactions document. I don't understand how you can > declare that out-of-scope. The concept of single radio is not applicable in the context of IETF IMO. A host may be able to use multiple interfaces simultaneously. If we go down the path where we start discussing why the host may not be able to do so, we are essentially getting down in to the details of PHY/MAC issues, interference, spectrums that the interfaces may be operating in, and many other issues. This is not in the domain of the IETF WGs. It is better to define optimizations for handovers which do not necessarily assume too much about whether the underlying interfaces operate (connect/attach) simultaneously or otherwise. -Raj > > Vijay > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 13:48:22 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EEB83A6BC4; Fri, 7 Nov 2008 13:48:22 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2690E3A6B8C; Fri, 7 Nov 2008 13:48:20 -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 tV6LtS5QtbQE; Fri, 7 Nov 2008 13:48:19 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 23DEF3A6B56; Fri, 7 Nov 2008 13:48:19 -0800 (PST) Received: from [10.166.254.86] ([75.26.137.116]) by outbound.mse15.exchange.ms with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Nov 2008 16:48:15 -0500 Message-ID: <4914B799.3080508@wichorus.com> Date: Fri, 07 Nov 2008 13:48:09 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: X-OriginalArrivalTime: 07 Nov 2008 21:48:16.0030 (UTC) FILETIME=[8A36A3E0:01C94122] Cc: Jonne Soininen , "netlmm@ietf.org" , mext Subject: Re: [MEXT] [netlmm] Conclusion and way forward for PMIP6-MIP6 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Basavaraj Patil wrote: > > > Hi Vijay, > > > On 11/7/08 1:38 PM, "ext Vijay Devarapalli" wrote: > >> Hi Vidya, Jonne, >> >> For a mobile node that has two interfaces and wants to use both >> interfaces, while using the same home address across the two interfaces, >> we need some extensions. Mobile IPv6 [RFC 3775] does not allow a mobile >> node to use both the home link and the visited link simultaneously when >> the mobile node has only one home address. >> >> For the home agent to allow the mobile node to use both the home link >> and the visited link, we need the MCoA extensions. > > The MCoA extension allows the MN to register multiple CoAs associated with > the same HoA. The scenario where the MN is on its home link as a virtue of > PMIP6 on one interface and continues to be on a foreign link on another IMO > are not captured. Sec 5.6. Returning Home: Simultaneous Home and Visited > Link Operation of I-D: draft-ietf-monami6-multiplecoa does provide some > guidelines but given that the PMIP6 aspect is not covered, it may be > worthwhile to revisit the issue. This was brought up during the AD review of the MCoA draft. It shouldn't matter if the home link is created by the MN attaching directly to the home agent or by GTP or PMIPv6. The MCoA extensions can be used. The plan is to add some text on this. > >> Specifically, the >> mobile node must indicate to the home agent that it wants to do so. > > Agree. But this is specified in the MCoA I-D, right? > >> It doesn't matter if the home link is provided by PMIPv6, GTP or direct >> attachment to the home link, the above is valid. > > In the case of PMIP6, there is a BCE for the MN in the LMA, unlike the MIP6 > case where the MN returns home and the BCE is deleted. In the simultaneous home and visited link attachment, there is a binding for the home link too. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 14:35:10 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63CDA28C133; Fri, 7 Nov 2008 14:35:10 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3252F28C139 for ; Fri, 7 Nov 2008 14:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.236, 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 VRKKE65hzci6 for ; Fri, 7 Nov 2008 14:35:08 -0800 (PST) Received: from web38807.mail.mud.yahoo.com (web38807.mail.mud.yahoo.com [209.191.125.98]) by core3.amsl.com (Postfix) with SMTP id 4483E3A6BD3 for ; Fri, 7 Nov 2008 14:35:08 -0800 (PST) Received: (qmail 50483 invoked by uid 60001); 7 Nov 2008 22:35:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=SM/ONoY9CdPZcQT5DIDBfwXXZi6rqFzYaQRXiPJkM7eWsmaFqSyYYIwXfyojW7AgUJtRACsVKhvGqQg4dDahM9Cj6ITNpCD7YZh2WMmSerYYaQFwHrPONnfhTC6bTHI5TpfAqmWk8iEkWXbrM0iqzUihJQsqf/UipiKuYKeaHtE=; X-YMail-OSG: QHz64y0VM1mTlsgoX9kL1JRyQWRb_8cBZPAZoRCjP0cloHkvUSNxIVURwY8zOKAeCStz.I.VeEuvd.pgkf2caLguGTO30NJl2RyT1U53s203LdvM_kIeE6QnQD5UHBf9hh3GYXbVgU.tfzMPR363jbnqDOE5kIR44W2_ku2e7_qkpPI- Received: from [206.16.17.212] by web38807.mail.mud.yahoo.com via HTTP; Fri, 07 Nov 2008 14:35:05 PST X-Mailer: YahooMailRC/1155.20 YahooMailWebService/0.7.260.1 References: <491400A0.50700@it.uc3m.es> <4914B192.4020406@ericsson.com> Date: Fri, 7 Nov 2008 14:35:05 -0800 (PST) From: Behcet Sarikaya To: Suresh Krishnan , marcelo bagnulo braun MIME-Version: 1.0 Message-ID: <737787.49417.qm@web38807.mail.mud.yahoo.com> Cc: Julien Laganier , mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0713345782==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0713345782== Content-Type: multipart/alternative; boundary="0-1385456241-1226097305=:49417" --0-1385456241-1226097305=:49417 Content-Type: text/plain; charset=us-ascii I also agree. Regards, Behcet ________________________________ From: Suresh Krishnan To: marcelo bagnulo braun Cc: Julien Laganier ; mext Sent: Friday, November 7, 2008 3:22:26 PM Subject: Re: [MEXT] consensus call on dhaad Hi Marcelo, While I have no strong position on the issue, if I was forced to pick, I would pick removing DHAAD and not burden all our future specs and implementations with this seldom used feature. Thanks Suresh marcelo bagnulo braun wrote: > Hi, > > There has been a very long debate on whether we should keep or remove dhaad from rfc3775bis. > We would like to ask people to express whether they want to keep dhaad or remove it from rfc3775bis at this point. > Please send your opinion before the 14 of november. > > (we are going to consider for this poll only the opinions sent as reply to this email, so even if you think your opinion is well known, reply to this email stating it again, so it can be considered as part of this poll) > > Regards, marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-1385456241-1226097305=:49417 Content-Type: text/html; charset=us-ascii
I also agree.

Regards,

Behcet

From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
Cc: Julien Laganier <julien.laganier.ietf@googlemail.com>; mext <mext@ietf.org>
Sent: Friday, November 7, 2008 3:22:26 PM
Subject: Re: [MEXT] consensus call on dhaad

Hi Marcelo,
  While I have no strong position on the issue, if I was forced to pick, I would pick removing DHAAD and not burden all our future specs and implementations with this seldom used feature.

Thanks
Suresh

marcelo bagnulo braun wrote:
> Hi,
>
> There has been a very long debate on whether we should keep or remove dhaad from rfc3775bis.
> We would like to ask people to express whether they want to keep dhaad or remove it from rfc3775bis at this point.
> Please send your opinion before the 14 of november.
>
> (we are going to consider for this poll only the opinions sent as reply to this email, so even if you think your opinion is well known, reply to this email stating it again, so it can be considered as part of this poll)
>
> Regards, marcelo
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext

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

--0-1385456241-1226097305=:49417-- --===============0713345782== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0713345782==-- From mext-bounces@ietf.org Fri Nov 7 15:03:27 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2774628C123; Fri, 7 Nov 2008 15:03:27 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2593A6BB5 for ; Fri, 7 Nov 2008 15:03: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 GuKFzl9CSIpU for ; Fri, 7 Nov 2008 15:03:24 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DE8AD3A6BD8 for ; Fri, 7 Nov 2008 15:03:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,566,1220227200"; d="scan'208";a="190709802" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 07 Nov 2008 23:03:21 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id mA7N3LmK019212; Fri, 7 Nov 2008 15:03:21 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id mA7N3LPq001036; Fri, 7 Nov 2008 23:03:21 GMT Date: Fri, 7 Nov 2008 15:03:21 -0800 (PST) From: Sri Gundavelli To: Alexandru Petrescu In-Reply-To: <49141B0F.1080806@gmail.com> Message-ID: References: <491400A0.50700@it.uc3m.es> <49141B0F.1080806@gmail.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2149; t=1226099001; x=1226963001; 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]=20consensus=20call=20on=20dhaad |Sender:=20; bh=adKjTxYtM18GMoGvl+MrjkeAsZXQ3qXavwk3CPBaXAg=; b=TbtfJzwMbFF2zXWWc5TrdLnHSMLxRI4Z5eiM/rTNfimzYKtufkJTv4b/gn 5pgUpcVc6geT6bWMFVhqEPhyODl73OVwrI2po/f2lgkKf9EReLwpbUWdr6et 4a2nIMunAq; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Julien Laganier , mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, Not sure, why we are running a consensus call on this issue. We already discussed this in March IETF and clearly the general input from the group was to retain DHAAD support in Mobile IPv6 specification. That is a feature that exists in MIP6 implementations today, in released products. Its used in NEMO spec and all Mobile Routers support this. So, we (Cisco) have two released products that support this feature. We cannot take out features in this random fashion and after a quick 2 week consensus call. This is a big decision as there is impact on released products. Also, the input from our Area Director in meeting during March IETF was to retain this in the spec. Bottom line, I strongly disagree taking DHAAD out. Regards Sri On Fri, 7 Nov 2008, Alexandru Petrescu wrote: > marcelo bagnulo braun wrote: >> Hi, >> >> There has been a very long debate on whether we should keep or remove >> dhaad from rfc3775bis. We would like to ask people to express >> whether they want to keep dhaad or remove it from rfc3775bis at this >> point. Please send your opinion before the 14 of november. > > DHAAD has been implemented and tested for interoperability, and is used > by NEMOv6 rfc3963 as well - keep it in rfc3775bis. > > Alex > >> >> (we are going to consider for this poll only the opinions sent as >> reply to this email, so even if you think your opinion is well known, >> reply to this email stating it again, so it can be considered as part >> of this poll) >> >> Regards, marcelo >> >> _______________________________________________ MEXT mailing list >> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >> > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > _______________________________________________ _______________________ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 15:18:43 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C62028C14E; Fri, 7 Nov 2008 15:18:43 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D89BE28C14E for ; Fri, 7 Nov 2008 15:18:41 -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 N8JPvsPNI3sQ for ; Fri, 7 Nov 2008 15:18:41 -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 308FA3A6AD2 for ; Fri, 7 Nov 2008 15:18:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,566,1220227200"; d="scan'208";a="101854155" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 07 Nov 2008 23:18:37 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id mA7NIbhB010212; Fri, 7 Nov 2008 15:18:37 -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 mA7NIagJ023834; Fri, 7 Nov 2008 23:18:36 GMT Date: Fri, 7 Nov 2008 15:18:36 -0800 (PST) From: Sri Gundavelli To: mext@ietf.org Message-ID: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1095; t=1226099917; x=1226963917; 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[OFFLIST]=20consensus=20call=20on=20dha ad=20(fwd) |Sender:=20; bh=FzQYyiMu4oBpvQ65PEG2gZXRMBiHgqFnM2IDyYBiSLk=; b=pNezL2xgFj7wXjBdjw4EExMHvVFGAN+TyUJnhW5qL8nYn9fCHI2YX5PSml 6JMgeeTgeCZuc1XPsWqLMqz4Zji36nAR2N7gy9XSlmX5zkbEER2Xx7p1CXgT 9F7Wr38lNN; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: jari.arkko@piuha.net Subject: Re: [MEXT] [OFFLIST] consensus call on dhaad (fwd) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Charlie's response on DHAAD deprecation issue. Also, the purpose of 3775-bis is primarily to fix some bugs and not a major rewrite of the spec. In that sense, we dont have the ability or charter to make such a fundamental change. Sri ---------- Forwarded message ---------- Date: Fri, 07 Nov 2008 14:58:59 -0800 From: Charles E. Perkins To: Sri Gundavelli Subject: Re: [OFFLIST] consensus call on dhaad (fwd) Hello Sri, Actually, I am neutral on this point. I don't think it matters whether or not it's in the spec, unless people are using it. And, I think that if there are people using it, that will present a very strong reason for retaining it. If, on the other hand, no one is using it or wants to use it, then we should take it out or perhaps republish it as a separate document. My previous argument for leaving it in, was just that taking it out would exceed the original purpose that was proposed for rfc3775bis. You can forward this to the list if you see fit, or to Jari. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 15:27:11 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AFF028C164; Fri, 7 Nov 2008 15:27:11 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D638928C133 for ; Fri, 7 Nov 2008 15:27:09 -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 uRf2hMjCJsj0 for ; Fri, 7 Nov 2008 15:27: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 25B5828C123 for ; Fri, 7 Nov 2008 15:27:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,566,1220227200"; d="scan'208";a="101857614" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 07 Nov 2008 23:25:13 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mA7NPCha002850; Fri, 7 Nov 2008 15:25:12 -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 mA7NPCQV028880; Fri, 7 Nov 2008 23:25:12 GMT Date: Fri, 7 Nov 2008 15:25:12 -0800 (PST) From: Sri Gundavelli To: mext@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1384; t=1226100313; x=1226964313; 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]=20consensus=20call=20on=20dhaad= 20(fwd) |Sender:=20; bh=QhGNUJGC9+Hmcl6AXw/+5NjvVPvvVvgbCo5IANE7eEA=; b=wTnrvbw9c5wknR3Ll/XqXjQsg5NNkQ2UCNOx2GOP+McnA/Si2j31+ppZuL QAXqqdD5s8Jzu416lgcSjxNcxgYOP9k/olUL013ZTOIIL/DLAb/wkKhSQjzw rEIzk6lRFE; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: jari.arkko@piuha.net Subject: Re: [MEXT] consensus call on dhaad (fwd) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org (resend, fixing the subject line) On Fri, 7 Nov 2008, Sri Gundavelli wrote: > > Charlie's response on DHAAD deprecation issue. > Also, the purpose of 3775-bis is primarily to fix some > bugs and not a major rewrite of the spec. In that sense, > we dont have the ability or charter to make such a > fundamental change. > > Sri > > ---------- Forwarded message ---------- > Date: Fri, 07 Nov 2008 14:58:59 -0800 > From: Charles E. Perkins > To: Sri Gundavelli > Subject: Re: [OFFLIST] consensus call on dhaad (fwd) > > > Hello Sri, > > Actually, I am neutral on this point. I don't think > it matters whether or not it's in the spec, unless > people are using it. And, I think that if there are > people using it, that will present a very strong > reason for retaining it. If, on the other hand, no > one is using it or wants to use it, then we should take > it out or perhaps republish it as a separate document. > > My previous argument for leaving it in, was just > that taking it out would exceed the original > purpose that was proposed for rfc3775bis. > > You can forward this to the list if you see fit, > or to Jari. > > Regards, > Charlie P. > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 15:28:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C8B328C16A; Fri, 7 Nov 2008 15:28:01 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D68D28C16A for ; Fri, 7 Nov 2008 15:28:00 -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 XM9kxuy9Kv9w for ; Fri, 7 Nov 2008 15:27:59 -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 30E5528C167 for ; Fri, 7 Nov 2008 15:27:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=GOE4hOUK3w3cmUpz1MrGBRstTLpYZe3AEz7JkgHY0JW64Pg/BA79C3YQ6t0dwphJ; 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 [75.26.137.116] (helo=[10.166.254.11]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Kyak5-0004Ud-7M; Fri, 07 Nov 2008 18:27:53 -0500 Message-ID: <4914CEF6.5040509@earthlink.net> Date: Fri, 07 Nov 2008 15:27:50 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: mext References: <491400A0.50700@it.uc3m.es> <49141B0F.1080806@gmail.com> In-Reply-To: X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f522ef5b148f6e70df2bc961c697842ac8e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, For the purposes of this discussion, I will remain neutral on the technical merits of DHAAD. However, I think it would be pretty unwelcome for the IETF to standardize protocol features, and then to remove them without strong cause. If I summarize the reasons to remove so far, we have: a) alternative mechanisms exist b) "no strong position on the issue, but simpler without" as opposed to the reasons to retain: - "used in NEMOv6 rfc3963" - "released products that support this feature" - previous consensus to retain I don't think that all votes should be counted equally in this debate. But there is one other alternative to be mentioned. DHAAD "could" be separated out into another document. I don't know why two documents would be better than one, but anyway it might satisfy more people. Vendors could claim compliance to _more_ standards. Simplifications could be had. I could have _more_ work to do. _More_ alternatives could be available (oops, those last two are negatives). Just a thought. Regards, Charlie P. Sri Gundavelli wrote: > Hi Marcelo, > > Not sure, why we are running a consensus call on this issue. We already > discussed this in March IETF and clearly the general input from the > group was to retain DHAAD support in Mobile IPv6 specification. That > is a feature that exists in MIP6 implementations today, in released > products. Its used in NEMO spec and all Mobile Routers support this. > So, we (Cisco) have two released products that support this feature. > > We cannot take out features in this random fashion and after a quick > 2 week consensus call. This is a big decision as there is impact on > released products. Also, the input from our Area Director in > meeting during March IETF was to retain this in the spec. > > Bottom line, I strongly disagree taking DHAAD out. > > Regards > Sri > > > > > On Fri, 7 Nov 2008, Alexandru Petrescu wrote: > >> marcelo bagnulo braun wrote: >>> Hi, >>> >>> There has been a very long debate on whether we should keep or remove >>> dhaad from rfc3775bis. We would like to ask people to express >>> whether they want to keep dhaad or remove it from rfc3775bis at this >>> point. Please send your opinion before the 14 of november. >> >> DHAAD has been implemented and tested for interoperability, and is used >> by NEMOv6 rfc3963 as well - keep it in rfc3775bis. >> >> Alex >> >>> >>> (we are going to consider for this poll only the opinions sent as >>> reply to this email, so even if you think your opinion is well known, >>> reply to this email stating it again, so it can be considered as part >>> of this poll) >>> >>> Regards, marcelo >>> >>> _______________________________________________ MEXT mailing list >>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >>> >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> _______________________________________________ _______________________ >> _______________________________________________ MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 15:38:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778E43A6B96; Fri, 7 Nov 2008 15:38:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA0773A6B96 for ; Fri, 7 Nov 2008 15:38:15 -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 4Q4vExEI14p1 for ; Fri, 7 Nov 2008 15:38:15 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id B1DBC3A6801 for ; Fri, 7 Nov 2008 15:38:14 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mA7Nc2b23862; Fri, 7 Nov 2008 23:38:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Nov 2008 17:37:58 -0600 Message-ID: In-Reply-To: <4914CEF6.5040509@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] consensus call on dhaad Thread-Index: AclBMH4Sl+GZn4cVS9SkJqvfejpzDAAANYsQ References: <491400A0.50700@it.uc3m.es> <49141B0F.1080806@gmail.com> <4914CEF6.5040509@earthlink.net> From: "Ahmad Muhanna" To: "Charles E. Perkins" , "mext" Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I agree with Charlie. Although, I understand the pain that many people have with maintaining DHAAD, but on the other hand, I do not think it is wise to remove it and ignore those who trusted this standard body documents and already implemented this feature in their product. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Charles E. Perkins > Sent: Friday, November 07, 2008 5:28 PM > To: mext > Subject: Re: [MEXT] consensus call on dhaad > > > Hello folks, > > For the purposes of this discussion, I will remain neutral on > the technical merits of DHAAD. However, I think it would be > pretty unwelcome for the IETF to standardize protocol > features, and then to remove them without strong cause. > > If I summarize the reasons to remove so far, we have: > a) alternative mechanisms exist > b) "no strong position on the issue, but simpler without" > > as opposed to the reasons to retain: > - "used in NEMOv6 rfc3963" > - "released products that support this feature" > - previous consensus to retain > > > I don't think that all votes should be counted equally in > this debate. But there is one other alternative to be > mentioned. DHAAD "could" > be separated out into another document. I don't know why two > documents would be better than one, but anyway it might > satisfy more people. > Vendors could claim compliance to _more_ standards. > Simplifications could be had. I could have _more_ work to > do. _More_ alternatives could be available (oops, those last > two are negatives). > > Just a thought. > > Regards, > Charlie P. > > > > > Sri Gundavelli wrote: > > Hi Marcelo, > > > > Not sure, why we are running a consensus call on this issue. We > > already discussed this in March IETF and clearly the general input > > from the group was to retain DHAAD support in Mobile IPv6 > > specification. That is a feature that exists in MIP6 > implementations > > today, in released products. Its used in NEMO spec and all > Mobile Routers support this. > > So, we (Cisco) have two released products that support this feature. > > > > We cannot take out features in this random fashion and after a quick > > 2 week consensus call. This is a big decision as there is impact on > > released products. Also, the input from our Area Director > in meeting > > during March IETF was to retain this in the spec. > > > > Bottom line, I strongly disagree taking DHAAD out. > > > > Regards > > Sri > > > > > > > > > > On Fri, 7 Nov 2008, Alexandru Petrescu wrote: > > > >> marcelo bagnulo braun wrote: > >>> Hi, > >>> > >>> There has been a very long debate on whether we should keep or > >>> remove dhaad from rfc3775bis. We would like to ask people to > >>> express whether they want to keep dhaad or remove it from > >>> rfc3775bis at this point. Please send your opinion > before the 14 of november. > >> > >> DHAAD has been implemented and tested for interoperability, and is > >> used by NEMOv6 rfc3963 as well - keep it in rfc3775bis. > >> > >> Alex > >> > >>> > >>> (we are going to consider for this poll only the > opinions sent as > >>> reply to this email, so even if you think your opinion is well > >>> known, reply to this email stating it again, so it can be > >>> considered as part of this poll) > >>> > >>> Regards, marcelo > >>> > >>> _______________________________________________ MEXT > mailing list > >>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > >>> > >> > >> > >> > _____________________________________________________________________ > >> _ This email has been scanned by the MessageLabs Email Security > >> System. > >> For more information please visit http://www.messagelabs.com/email > >> _______________________________________________ > >> _______________________ > >> _______________________________________________ MEXT mailing list > >> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > >> > >> > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 16:44:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778803A68AC; Fri, 7 Nov 2008 16:44:05 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B53B3A68AC for ; Fri, 7 Nov 2008 16:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, 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 gbDfnsyNBGRW for ; Fri, 7 Nov 2008 16:44:04 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 492B93A684E for ; Fri, 7 Nov 2008 16:44:03 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1Kybva-0005lf-2k; Sat, 08 Nov 2008 11:43:50 +1100 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Sat, 08 Nov 2008 11:43:44 +1100 From: Hesham Soliman To: marcelo bagnulo braun , mext Message-ID: Thread-Topic: [MEXT] consensus call on dhaad Thread-Index: AclBOw1fIYXF0gQclkSjkTLJF85yLw== In-Reply-To: <491400A0.50700@it.uc3m.es> Mime-version: 1.0 Cc: Julien Laganier Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, Julien I'm fairly neutral on this issue but he are some thoughts. I don't think it's terribly useful now that we defined ways for dynamic home address config. DHAAD almost always assumes manual config. Or, said differently, it assumes that the MN knows its home address but doesn't know its HA. I'm not sure that's realistic outside manual config cases. Manual config obviously has its problems and its benefits are not clear to me. One can always allocate a static HoA dynamically, so no need for manual config at all. I don't think it's harmful really, I just think it's not all that useful. It sounded good at the time but I won't be losing sleep if we remove it from the spec. I don't actively call for it to be removed because I'm just a bit conservative when it comes to removing stuff that isn't broken, but I don't think it's all that useful now. Hesham On 7/11/08 7:47 PM, "marcelo bagnulo braun" wrote: > Hi, > > There has been a very long debate on whether we should keep or remove > dhaad from rfc3775bis. > We would like to ask people to express whether they want to keep dhaad > or remove it from rfc3775bis at this point. > Please send your opinion before the 14 of november. > > (we are going to consider for this poll only the opinions sent as reply > to this email, so even if you think your opinion is well known, reply to > this email stating it again, so it can be considered as part of this poll) > > Regards, marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 19:35:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 125D43A68D4; Fri, 7 Nov 2008 19:35:25 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E313A68F4 for ; Fri, 7 Nov 2008 19:35:23 -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 xtAbsRHDw7q1 for ; Fri, 7 Nov 2008 19:35:22 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id 70A8D3A67A8 for ; Fri, 7 Nov 2008 19:35:22 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id a6so785335tib.25 for ; Fri, 07 Nov 2008 19:35:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:cc :subject:in-reply-to:references:user-agent:organization:mime-version :content-type; bh=PRa5xhqTeXi16ToGAylsKWzxf4iMtoTATeq5CvVbuYg=; b=FqTRikaKRw2/Towfs3u2Ne4ypoviTDJ5KzZlrRMd+yn5BoKjityddrmDrCxdJDfbkf QSmCjT9mGytu1XLqEIZbFM8TziUt5lbhLz4KTrEZwBy8XyzXH5zM1t2yQ5NQPiAZ6uzE 0f7z2tLf58ctw9dWQTHMvGgWN6YKZpPCIToPE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:organization:mime-version:content-type; b=hDoaOj5vFs/GZHKHJZwPUydDrVxcKyL1Bs+pqFT9ctGES3+IRfqeHtFscYUeoFnZDY OyFb4s3yCB9BT2ENTtP02UAYzFYD6DV0/AJQ0DrQEujdtIXLVuKnBx5T+GzYap1L567e +HAVZGL5qS/rQ65BzsYpUSWuH29U0Od4t99MM= Received: by 10.110.68.10 with SMTP id q10mr4574565tia.47.1226115317967; Fri, 07 Nov 2008 19:35:17 -0800 (PST) Received: from ryuji-wakikawa-no-macbook-pro.local.sfc.wide.ad.jp (h219-110-64-013.catv02.itscom.jp [219.110.64.13]) by mx.google.com with ESMTPS id w12sm3313867tib.10.2008.11.07.19.35.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Nov 2008 19:35:15 -0800 (PST) Date: Sat, 08 Nov 2008 12:35:10 +0900 Message-ID: From: Ryuji Wakikawa To: marcelo bagnulo braun In-Reply-To: <491400A0.50700@it.uc3m.es> References: <491400A0.50700@it.uc3m.es> User-Agent: Wanderlust/2.14.1 (Bad Medicine-pre) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin9) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: Julien Laganier , mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo and Julien, I am very neutral on this. However, I have one question. If we remove DHAAD completely from the spec, shall we also remove the - managing HA List (used for DHAAD) - exchanging RA with HA information list for the HA list These two functionalities are coupled with DHAAD. regards, ryuji At Fri, 07 Nov 2008 09:47:28 +0100, marcelo bagnulo braun wrote: > > Hi, > > There has been a very long debate on whether we should keep or remove > dhaad from rfc3775bis. > We would like to ask people to express whether they want to keep dhaad > or remove it from rfc3775bis at this point. > Please send your opinion before the 14 of november. > > (we are going to consider for this poll only the opinions sent as reply > to this email, so even if you think your opinion is well known, reply to > this email stating it again, so it can be considered as part of this poll) > > Regards, marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 19:43:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 907123A69A3; Fri, 7 Nov 2008 19:43:00 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93C7C3A69A3 for ; Fri, 7 Nov 2008 19:42:58 -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 feTb34KkdfVI for ; Fri, 7 Nov 2008 19:42:57 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189]) by core3.amsl.com (Postfix) with ESMTP id 63E653A67A8 for ; Fri, 7 Nov 2008 19:42:57 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id a6so786492tib.25 for ; Fri, 07 Nov 2008 19:42:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:cc :subject:in-reply-to:references:user-agent:organization:mime-version :content-type:content-transfer-encoding; bh=FJegufIT08RMgRVWIhe+IHY/9IzFmghqmt3WFqWSXyc=; b=A2gs948HQK3OyGPBBDXvFuFqliggiaHiODp6i82iT3+Ehaww0f49FSN1wr1pu6Z9jb axjs0VMW3juRNSJH2vP3BcMj3Yi/CW8pkgcWhpm9A7PrTfTLeCp7GbYIfrC+ZLQ8UTOA ic3GqiY1IgknN0VNas8rTaPgMaAuZWBQ1jTaY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:organization:mime-version:content-type :content-transfer-encoding; b=M+ANKTaW8UibOH5vWcLPR09GJNreFu03rSncmipwtJnD73wbltgj3yrCtFC1Jha/7A q/SSdUzHJpH7snL95EdJ/utWqMQjuh3sPs4/rXGVCckeVjSM4+ZBKhKndYms34wu6AZB 2g/1ulm6JLzrFu2uR8++nsUxfAZkObe31DGV8= Received: by 10.110.16.6 with SMTP id 6mr4600183tip.41.1226115773761; Fri, 07 Nov 2008 19:42:53 -0800 (PST) Received: from ryuji-wakikawa-no-macbook-pro.local.sfc.wide.ad.jp (h219-110-64-013.catv02.itscom.jp [219.110.64.13]) by mx.google.com with ESMTPS id u12sm2858399tia.3.2008.11.07.19.42.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Nov 2008 19:42:52 -0800 (PST) Date: Sat, 08 Nov 2008 12:42:49 +0900 Message-ID: From: Ryuji Wakikawa To: "Francisco J. Galera Cuesta" In-Reply-To: <4911D476.6040303@dif.um.es> References: <4911D476.6040303@dif.um.es> User-Agent: Wanderlust/2.14.1 (Bad Medicine-pre) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin9) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: mext@ietf.org Subject: Re: [MEXT] Question about draft-ietf-monami6-multiplecoa-10.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Francisco, = In some implementation, HoA is assigned to a virtual "interface" and CoAs can be assigned to physical interfaces. It depends on implementations. I don't think we break the RFC2373. thanks, ryuji At Wed, 05 Nov 2008 18:14:30 +0100, Francisco J. Galera Cuesta wrote: > = > Hello all, > = > I have a doubt in draft-ietf-monami6-multiplecoa-10.txt, but also = > related to draft-ietf-monami6-mipv6-analysis-05 and = > draft-ietf-monami6-multihoming-motivation-scenario-03.txt > = > I'm considering a scenario such as the one specified in subsection 5.3. = > ((1,n): 1 HoA, n CoAs) of draft-ietf-monami6-mipv6-analysis-05: My = > scenario consists on a multihoming mobile node with several interfaces = > of multiple types of access technologies. The node configures one CoA in = > each interface, but it only has one HoA. The node may be moving and = > changing its CoAs, but it needs ubiquitous access to the Internet, = > maintaining communications when it is moving out of the coverage area of = > a specific technology. > = > My doubt is how a HoA can be binded to several interfaces? This issue is = > commented in subsection 6.3.3 (Binding HoA to interface) of = > draft-ietf-monami6-mipv6-analysis-05, but it is no clear for me. Is not = > there a contradiction with RFC 2373 (IP Version 6 Addressing = > Architecture) and especially with the following paragraph? > = > "IPv6 addresses of all types are assigned to interfaces, not nodes. > An IPv6 unicast address refers to a single interface. Since each > interface belongs to a single node, any of that node's interfaces' > unicast addresses may be used as an identifier for the node." > = > Thanks in advance! > = > = > = > -- = > ---------------------------------------------------------- > Francisco J. Galera Cuesta > Dpto. Ingenier=EDa de la Informaci=F3n y las Comunicaciones > Facultad de Inform=E1tica > Universidad de Murcia > 30100 Murcia (Spain) > Tlf: +34 968 364644 > ---------------------------------------------------------- > = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 19:47:20 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38E083A69AD; Fri, 7 Nov 2008 19:47:20 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D78E3A69AD for ; Fri, 7 Nov 2008 19:47:18 -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 ea0My9+JA8i1 for ; Fri, 7 Nov 2008 19:47:17 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by core3.amsl.com (Postfix) with ESMTP id 760183A69A3 for ; Fri, 7 Nov 2008 19:47:17 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id a6so787162tib.25 for ; Fri, 07 Nov 2008 19:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:cc :subject:in-reply-to:references:user-agent:organization:mime-version :content-type:content-transfer-encoding; bh=2E5o0ur3fvqL86LC0pWlqVkr5WaSiEkinQERzyd2qhs=; b=ZemRMYeREnGvPqynirpkb7Q2LLdCoNmdchpCIJxaHElRzN9zMgNNOI73ljCM8WksUA 6cE1LIYK4QSPuWQfNF/9OAmCo0QpGXRK8vcBaGyccTESY14S1mHHkLngumrH96PMqE3T 2bPZjSomiIDDzCuC3TwesjVfm/uLiDw5dZE5k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:organization:mime-version:content-type :content-transfer-encoding; b=N8IvR+UYVNa0RX74xDPA6GJwrmKeTuRsFxUIBdChYlUqnh9GxW/2M1S/s1ZRseu3wt MpsHiTFMVsV4/7d4QAeULTjEZWcDl+R31R4j6dn6oXaXzDsp8JuZ0zJJTvczKQn9S9Mm AbPakED/Ud94EMDxOntB3F8qDGMcR/2GLCNn0= Received: by 10.110.41.20 with SMTP id o20mr4600882tio.20.1226116034315; Fri, 07 Nov 2008 19:47:14 -0800 (PST) Received: from ryuji-wakikawa-no-macbook-pro.local.sfc.wide.ad.jp (h219-110-64-013.catv02.itscom.jp [219.110.64.13]) by mx.google.com with ESMTPS id u12sm2927387tia.3.2008.11.07.19.47.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Nov 2008 19:47:13 -0800 (PST) Date: Sat, 08 Nov 2008 12:47:09 +0900 Message-ID: From: Ryuji Wakikawa To: marcelo bagnulo braun In-Reply-To: <49131CE6.3080609@it.uc3m.es> References: <491039B9.6090400@it.uc3m.es> <49131CE6.3080609@it.uc3m.es> User-Agent: Wanderlust/2.14.1 (Bad Medicine-pre) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin9) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: Julien Laganier , mext Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, I agree with Vijay and Raj. = We had similar discussion for MCoA. We decided not to have DHAAD extension to discover MCoA capable HA. regards, ryuji At Thu, 06 Nov 2008 17:35:50 +0100, marcelo bagnulo braun wrote: > = > Anyone else has an opinion on whether we should cover DHAAD on this = > document or not? > = > regards, marcelo > = > = > Vijay Devarapalli escribi=F3: > > Hi Marcelo, > > > > We should remove the extensions to DHAAD from this document. IMO, it's a > > bad idea to keep extending DHAAD every time we add an extension to > > MIPv6. > > > > We could extend DNS-based HA lookup for discovering a home agent that is > > capable of NEMO prefix delegation. But I think this is also unnecessary. > > The mobile router can always try the next home agent in the list of the > > home agents if the first one does not respond to DHCPv6 messages. If > > none of the home agents are capable of prefix delegation, then there is > > nothing the mobile router can do about it, maybe use some static mobile > > network prefixes. = > > > > We had a discussion at the last IETF and on the mailing list before on > > this, but there was no conclusion. > > > > Vijay > > > > = > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On = > >> Behalf Of marcelo bagnulo braun > >> Sent: Tuesday, November 04, 2008 4:02 AM > >> To: mext; Julien Laganier; Ralph Droms > >> Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt > >> > >> Hi, > >> > >> We now start the WGLC for: > >> > >> DHCPv6 Prefix Delegation for NEMO > >> draft-ietf-mext-nemo-pd-01.txt > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt > >> > >> > >> Please send comments about the draft till the November 19. > >> > >> Regards, Julien and marcelo > >> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > >> = > > > > = > = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 19:47:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B8F3A69D4; Fri, 7 Nov 2008 19:47:54 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB283A69C0 for ; Fri, 7 Nov 2008 19:47:52 -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=[AWL=0.000, 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 pUfl5M2dPpcT for ; Fri, 7 Nov 2008 19:47:51 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D9FCB3A69A3 for ; Fri, 7 Nov 2008 19:47:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,567,1220227200"; d="scan'208";a="190817806" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 08 Nov 2008 03:47:49 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id mA83lnqQ018973; Fri, 7 Nov 2008 19:47:49 -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 mA83ln7A010098; Sat, 8 Nov 2008 03:47:49 GMT Date: Fri, 7 Nov 2008 19:47:49 -0800 (PST) From: Sri Gundavelli To: Ryuji Wakikawa In-Reply-To: Message-ID: References: <491400A0.50700@it.uc3m.es> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1548; t=1226116069; x=1226980069; 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]=20consensus=20call=20on=20dhaad |Sender:=20; bh=bXLHrFgG2tc2IFQcXRnIML5OySmqYSXTi/157M65l/I=; b=L2Wgy8IAXbuBAGpHFaU86+a4k96jg5fpahLDh1KYEpMkcMvCoTKATHLjqb kjXEJUENpdxCBA0CFL76l67X7XG92jIchxxOfthB4Dar24LPNlDF9NS89w9z 23ZSOVjR47; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Julien Laganier , mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Right. There is no purpose of HA list any more. It will have impact on the following: RFC-3963 RFC-4295 (MIB objects) Home Agent List maintanance by HA Home Agent Informaiton option DHAAD Discovery related text ... Sri On Sat, 8 Nov 2008, Ryuji Wakikawa wrote: > > Hi Marcelo and Julien, > > I am very neutral on this. > > However, I have one question. > If we remove DHAAD completely from the spec, shall we also remove the > - managing HA List (used for DHAAD) > - exchanging RA with HA information list for the HA list > > These two functionalities are coupled with DHAAD. > > regards, > ryuji > > > At Fri, 07 Nov 2008 09:47:28 +0100, > marcelo bagnulo braun wrote: >> >> Hi, >> >> There has been a very long debate on whether we should keep or remove >> dhaad from rfc3775bis. >> We would like to ask people to express whether they want to keep dhaad >> or remove it from rfc3775bis at this point. >> Please send your opinion before the 14 of november. >> >> (we are going to consider for this poll only the opinions sent as reply >> to this email, so even if you think your opinion is well known, reply to >> this email stating it again, so it can be considered as part of this poll) >> >> Regards, marcelo >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 20:21:08 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1B33A67A8; Fri, 7 Nov 2008 20:21:08 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB1643A67A8 for ; Fri, 7 Nov 2008 20:21:06 -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 Bm7J8uYP4W6L for ; Fri, 7 Nov 2008 20:21:06 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.188]) by core3.amsl.com (Postfix) with ESMTP id B47EC3A63EC for ; Fri, 7 Nov 2008 20:21:05 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id a6so792401tib.25 for ; Fri, 07 Nov 2008 20:20:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:cc :subject:in-reply-to:references:user-agent:organization:mime-version :content-type; bh=/v0KE+BZkPVPNRyZAgY5fPDsQEbb1D9UICamyHl4q4Q=; b=DnzivMKUbDxuXTUV+Kv/rNzcwTCd0fwET6e5djeZ27FmZfil/7N/f7M9HRdWsxudMr 2CWVh5q4vJU0+gh4VRGM+QwymUvp+p+T7LUoGq5lstnfrSKOzvc7Kh+/lR+TM0d34Khc gSy2Wl3lQqt3lYSG0Aa8F9B1KQLE5GT04f2y8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:organization:mime-version:content-type; b=xD0QdlRtTOEoijK4ufec1FgK6cY6CA+mJqHTfzclrD4LjW6AXDO1symXVnypvZ7jwb bDfovBk9Bf77YLe7HxpY2g4IPvqx67k1qzD4TTioAqXLTRQ50R1NbZ7tMJMz8nWryTww 9GPhjzeivzZUYw4B6w10QnRl/Q4/n94qnVIZ8= Received: by 10.110.42.1 with SMTP id p1mr833285tip.34.1226118007715; Fri, 07 Nov 2008 20:20:07 -0800 (PST) Received: from ryuji-wakikawa-no-macbook-pro.local.sfc.wide.ad.jp (h219-110-64-013.catv02.itscom.jp [219.110.64.13]) by mx.google.com with ESMTPS id w5sm2620706tib.14.2008.11.07.20.20.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Nov 2008 20:20:06 -0800 (PST) Date: Sat, 08 Nov 2008 13:20:03 +0900 Message-ID: From: Ryuji Wakikawa To: "Vijay Devarapalli" In-Reply-To: References: <4900BB68.6090806@trajano.us.es> User-Agent: Wanderlust/2.14.1 (Bad Medicine-pre) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin9) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: "Juan A. Ternero" , mext@ietf.org Subject: Re: [MEXT] A comment on draft-ietf-monami6-multiplecoa-09.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Juan, Thanks for your review. We will fix your point in the next revision. thanks ryuji At Wed, 5 Nov 2008 14:24:22 -0500, Vijay Devarapalli wrote: > > Hi Juan, > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of Juan A. Ternero > > Sent: Thursday, October 23, 2008 10:59 AM > > To: mext@ietf.org > > Subject: [MEXT] A comment on draft-ietf-monami6-multiplecoa-09.txt > > > > Dear members: > > Length field in Binding Identifier Mobility Option is explained > > as follows: > > "Length > > > > 8-bit unsigned integer. Length of the option, in octets, > > excluding the Type and Length fields. It MUST be set to either 4, > > 12, or 20 depending on the care-of address field. When the > > care-of address is not carried by this option, the length value > > MUST be set to 4. If the IPv4 care-of address is stored in the > > care-of address field, the length MUST be 12. Otherwise, the > > Length value MUST be set to 20 for IPv6 care-of address." > > > > According to that, possible values of length field are only 4-12-20 > > (4=No_CoA, 12=IPv4_CoA, 20=IPv6_CoA). > > > > I have read last versions of the draft and I have detected that > > possible values of this field changed from 4-8-20 in version 06 > > to 4-12-20 in version 07. > > I think the correct ones are 4-8-20, because an IPv4 address only > > adds 4 bytes to the option. > > > > In that case, alignment should be modified from: > > > > "The Binding Identifier Mobility Option has an alignment requirement > > of 2n if the Care-of Address field is not present. Otherwise, it has > > the alignment requirement of 8n + 2." > > > > to > > > > "The Binding Identifier Mobility Option has an alignment requirement > > of 2n if the Care-of Address field is not present, 4n+2 if the Care-of > > Address field stores an IPv4 address, an 8n+2 if the Care-of Address > > field stores an IPv6 address." > > Thanks for catching this. Will be fixed in the next version. > > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 20:21:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30E828C16B; Fri, 7 Nov 2008 20:21:35 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27CE428C16B for ; Fri, 7 Nov 2008 20:21:34 -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 Ser8nsN4CAM3 for ; Fri, 7 Nov 2008 20:21:33 -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 4161D3A63EC for ; Fri, 7 Nov 2008 20:21:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,567,1220227200"; d="scan'208";a="101926178" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 08 Nov 2008 04:20:54 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mA84Ks99005318; Fri, 7 Nov 2008 20:20:54 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mA84Ksvi017557; Sat, 8 Nov 2008 04:20:54 GMT Date: Fri, 7 Nov 2008 20:20:54 -0800 (PST) From: Sri Gundavelli To: Hesham Soliman In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=907; t=1226118054; x=1226982054; c=relaxed/simple; s=sjdkim1004; 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]=20consensus=20call=20on=20dhaad |Sender:=20; bh=kEzoCIanmCxFEBTWfkTE0RoBV++yIgkZRneCJ/OZuz8=; b=KcN3hCGDoIoB0qo937fbySncDchj2QfvwXk96tj2pg/sDaudlA/YBuhMMi d37eKpiIpT/sEGYgugDvMeGNgxXN4wR5JvTswgnJXfBEuD1w0lJWhCtWevQO bKxnykZVI6FLRQRCAXjPaMS/1o6Y+M0Al7sVX0t/TspPq0s9H8bcA=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Julien Laganier , mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Sat, 8 Nov 2008, Hesham Soliman wrote: > I don't think it's terribly useful now that we defined ways for dynamic home > address config. Its bit debatable if DNS based discovery mechanism is better than the current DHAAD appraoch. There are pros and cons in both the approaches and one can argue either way. There are certain useful aspects such as the ability for the Home Agent to adjust its preference on the fly and based on the binding count, gives some simple load balancing capability. Runtime discovery vs depending on a static DNS configuration with potentially stale data. There are no predictable service labels in DNS SRV records that can be used by clients to locate nearest Home Agents. All of these cannot be ignored. Bottom line, the feature is modelled into the design and has dependency on other specs and other features, so it has to survive. Regards Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 20:49:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 757A83A67A8; Fri, 7 Nov 2008 20:49:03 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 245023A67A8 for ; Fri, 7 Nov 2008 20:49:03 -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 NwwmfcoiFVy9 for ; Fri, 7 Nov 2008 20:49:02 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id 95D223A63EC for ; Fri, 7 Nov 2008 20:49:01 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id a6so796938tib.25 for ; Fri, 07 Nov 2008 20:48:57 -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=hg6+rB3ybU2xCn6WxFDMRf6MJV6GY0Aw8jgXlyU7LLI=; b=toXpwtq/tSP6hk0P0CaR3/+RFb5VHA4H1GYPXo0lOXjW1sX0E1a9+IxZ1RA9c6DUgg k2v2YvsecZNBCVv38uGieb+7GkcEyEbBvboUvjvEMWhIurbYpDv+BXEogtS7i1xXOnq7 ReQzSksDhSQS4FOBLFJ1n+leshhOFbcdI2EZ8= 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=SXUhYfBBaKGAvMMgj06Fp3lcZQUDcufxqln/wrBBfYsiH2Swk5GcwOrv3uP262y5D1 byLGGgm6l0iRm3vhJwobpD+AQp6YXIjFvZ4egWNvXWsCM4usx25u4/sihNqr2heY7yNH +ZY+hZoNpz2m7aCmGG6ZBCSJVEs9FB9ggX3w4= Received: by 10.110.90.9 with SMTP id n9mr4643150tib.57.1226119737459; Fri, 07 Nov 2008 20:48:57 -0800 (PST) Received: from ?10.0.1.195? (h219-110-64-013.catv02.itscom.jp [219.110.64.13]) by mx.google.com with ESMTPS id a14sm2700054tia.12.2008.11.07.20.48.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Nov 2008 20:48:56 -0800 (PST) From: Ryuji Wakikawa To: Vijay Devarapalli In-Reply-To: References: <48E3C678.5060509@earthlink.net> Message-Id: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 8 Nov 2008 13:48:53 +0900 X-Mailer: Apple Mail (2.929.2) Cc: mext@ietf.org Subject: Re: [MEXT] 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Charlie and VIjay, If MN knows that HA no longer holds the binding for MN, there is no reason to send deregistration BU. Two examples. - MN returns home after its binding is expired. - MN bootstraps from the home link. If the above two cases are not equivalent to "returning home", I am fine with your text. thanks, ryuji On 2008/11/01, at 7:56, Vijay Devarapalli wrote: > Hi Charlie, > > In the previous discussions on this issue (July 2008), we had almost > concluded on the following text. > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > 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 a de-registration > Binding Update, it will not be able to send and receive packets > using its home address from the home link. The home agent will > continue to intercept all packets sent to the mobile's home address > and tunnel to the previously registered care-of address. > > Only Sri had an objection to this text. He was objecting to the last > two > sentences. > > Until the mobile node sends a de-registration > Binding Update, it will not be able to send and receive packets > using its home address from the home link. The home agent will > continue to intercept all packets sent to the mobile's home address > and tunnel to the previously registered care-of address. > > For the last sentences, we can replace the text with what you proposed > in your email. So the final text would be > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > 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. > > Is this acceptable? > > Vijay > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Charles E. Perkins >> Sent: Wednesday, October 01, 2008 11:51 AM >> To: mext@ietf.org >> Subject: [MEXT] Issue #11: De-registration when returning home >> >> >> Hello folks, >> >> Perhaps this issue is ready to be closed. >> >> I suggest we use the text offered by George >> Tsirtsis, but with one additional change: >> >> >> >> OLD Text: >> >> 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). >> The mobile >> node SHOULD then send a Binding Update to its home agent, >> to instruct >> its home agent to no longer intercept or tunnel packets for it. >> >> >> >> George's Text: >> >> 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. >> The mobile node SHOULD then send a Binding Update to its >> home agent, >> to instruct its home agent to no longer intercept or tunnel packets >> for it. Until the mobile node sends a de-registration >> Binding Update, >> it will not be able to send and receive packets using its >> home address >> from the home link. The home agent will continue to intercept all >> packets sent to the mobile's home address and tunnel to >> the previously >> registered care-of address. >> >> >> >> A slightly amended version of George's Text: >> >> 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. >> The mobile node SHOULD then send a Binding Update to its >> home agent, >> to instruct its home agent to no longer intercept or tunnel packets >> for it. Until the mobile node sends 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. >> >> ================================================== >> >> Regards, >> Charlie P. >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 21:15:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379113A6825; Fri, 7 Nov 2008 21:15:39 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74833A6853 for ; Fri, 7 Nov 2008 21:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.582 X-Spam-Level: X-Spam-Status: No, score=-103.582 tagged_above=-999 required=5 tests=[AWL=-0.983, 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 X1Hc-tO4lc00 for ; Fri, 7 Nov 2008 21:15:32 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id BAB983A63EC for ; Fri, 7 Nov 2008 21:15:32 -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=1226121330; x=1257657330; 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=20Vijay=20Devarapalli=0D=0A=09|CC:=20"mext@ietf.org"=20|Date:=20Fri,=207=20Nov=202008=2021:13:23=20-0800 |Subject:=20RE:=20[MEXT]=20Issue=20#11:=20De-registration =20when=20returning=20home|Thread-Topic:=20[MEXT]=20Issue =20#11:=20De-registration=20when=20returning=20home |Thread-Index:=20AclBXVXFRpVZpB8WSLqrNN1EjvhS3AAA2Mne |Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3D6CC34C5@ NASANEXMB08.na.qualcomm.com>|References:=20<48E3C678.5060 509@earthlink.net>=0D=0A=09,|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-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5427"=3B=20a=3D"12260820"; bh=PQrbHF/rpF9djxirZCyWG0e+WZ/4wDt1TpqjkHW0X34=; b=o61Kc1QisO6nNan84AFvOe0vwGaYsHll1qtXd03RtAJtmQ6/rY1v/Y2X 1xskdaLwqMBch8eoPQW41BhSqYIBj9FScmSr7gQ6KndjJuga58EIRiAuP o5b90ZmODFGjM2OiLMd0kNAoWebSfa0c39pz22R0xYSM7HUBNbQh2pWwi g=; X-IronPort-AV: E=McAfee;i="5100,188,5427"; a="12260820" 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; 07 Nov 2008 21:15:05 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mA85F4jn015208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Nov 2008 21:15:05 -0800 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 mA85F44K008919 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Nov 2008 21:15:04 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.132]) by nasanexhub01.na.qualcomm.com ([10.46.93.121]) with mapi; Fri, 7 Nov 2008 21:15:04 -0800 From: "Giaretta, Gerardo" To: Ryuji Wakikawa , Vijay Devarapalli Date: Fri, 7 Nov 2008 21:13:23 -0800 Thread-Topic: [MEXT] Issue #11: De-registration when returning home Thread-Index: AclBXVXFRpVZpB8WSLqrNN1EjvhS3AAA2Mne Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D6CC34C5@NASANEXMB08.na.qualcomm.com> References: <48E3C678.5060509@earthlink.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ryuji, I agree with you on the points below but I think those scenarios are not part of the case described in this section. In the first case there is no entry in the BUL of the MN so the MN has no state to clear at the HA. The second case implies a home link detection procedure of the MN which is different from a returning home scenario Thanks Gerardo ________________________________________ From: mext-bounces@ietf.org [mext-bounces@ietf.org] On Behalf Of Ryuji Wakikawa [ryuji.wakikawa@gmail.com] Sent: Friday, November 07, 2008 8:48 PM To: Vijay Devarapalli Cc: mext@ietf.org Subject: Re: [MEXT] Issue #11: De-registration when returning home Hi Charlie and VIjay, If MN knows that HA no longer holds the binding for MN, there is no reason to send deregistration BU. Two examples. - MN returns home after its binding is expired. - MN bootstraps from the home link. If the above two cases are not equivalent to "returning home", I am fine with your text. thanks, ryuji On 2008/11/01, at 7:56, Vijay Devarapalli wrote: > Hi Charlie, > > In the previous discussions on this issue (July 2008), we had almost > concluded on the following text. > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > 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 a de-registration > Binding Update, it will not be able to send and receive packets > using its home address from the home link. The home agent will > continue to intercept all packets sent to the mobile's home address > and tunnel to the previously registered care-of address. > > Only Sri had an objection to this text. He was objecting to the last > two > sentences. > > Until the mobile node sends a de-registration > Binding Update, it will not be able to send and receive packets > using its home address from the home link. The home agent will > continue to intercept all packets sent to the mobile's home address > and tunnel to the previously registered care-of address. > > For the last sentences, we can replace the text with what you proposed > in your email. So the final text would be > > A mobile node detects that it has returned to its home link through > the movement detection algorithm in use (Section 11.5.1), when the > mobile node detects that its home subnet prefix is again on-link. > 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. > > Is this acceptable? > > Vijay > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Charles E. Perkins >> Sent: Wednesday, October 01, 2008 11:51 AM >> To: mext@ietf.org >> Subject: [MEXT] Issue #11: De-registration when returning home >> >> >> Hello folks, >> >> Perhaps this issue is ready to be closed. >> >> I suggest we use the text offered by George >> Tsirtsis, but with one additional change: >> >> >> >> OLD Text: >> >> 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). >> The mobile >> node SHOULD then send a Binding Update to its home agent, >> to instruct >> its home agent to no longer intercept or tunnel packets for it. >> >> >> >> George's Text: >> >> 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. >> The mobile node SHOULD then send a Binding Update to its >> home agent, >> to instruct its home agent to no longer intercept or tunnel packets >> for it. Until the mobile node sends a de-registration >> Binding Update, >> it will not be able to send and receive packets using its >> home address >> from the home link. The home agent will continue to intercept all >> packets sent to the mobile's home address and tunnel to >> the previously >> registered care-of address. >> >> >> >> A slightly amended version of George's Text: >> >> 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. >> The mobile node SHOULD then send a Binding Update to its >> home agent, >> to instruct its home agent to no longer intercept or tunnel packets >> for it. Until the mobile node sends 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. >> >> ================================================== >> >> Regards, >> Charlie P. >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 7 23:56:32 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE6A13A69AC; Fri, 7 Nov 2008 23:56:32 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750DD3A69AC for ; Fri, 7 Nov 2008 23:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.75 X-Spam-Level: X-Spam-Status: No, score=-3.75 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 G0BnvFmLLFSj for ; Fri, 7 Nov 2008 23:56:30 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 083D73A6403 for ; Fri, 7 Nov 2008 23:56:28 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (104.pool85-53-136.dynamic.orange.es [85.53.136.104])by smtp03.uc3m.es (Postfix) with ESMTP id 717646AF8AB; Sat, 8 Nov 2008 08:52:04 +0100 (CET) Message-ID: <49154523.1020306@it.uc3m.es> Date: Sat, 08 Nov 2008 08:52:03 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Sri Gundavelli References: <491400A0.50700@it.uc3m.es> <49141B0F.1080806@gmail.com> In-Reply-To: X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-35.9445 TC:1F TRN:61 TV:5.5.1026(16266.005) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier , mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Sri, I will only be addressing the procedural issues you bring in this email = and will not comment on the dhaad issue per se. Sri Gundavelli escribi=F3: > Hi Marcelo, > > Not sure, why we are running a consensus call on this issue. cause we need to define what to do with it > We already > discussed this in March IETF = right and we have disucssed before that as well > and clearly the general input from the > group was to retain DHAAD support in Mobile IPv6 specification. = this is not my reading of the consensus In my opinion there was no consensus and we are trying to reach one > That > is a feature that exists in MIP6 implementations today, in released > products. Its used in NEMO spec and all Mobile Routers support this > > So, we (Cisco) have two released products that support this feature. > So, having this feature out of the rfc3775 bis does not means your = products are no longer compliant to with the rfc, right? I mean doing = more than what is n the rfc doesn't imply that you don't comply with it. > We cannot take out features in this random fashion please provide a DETAILED explanation to me about what is random about this We have been disucssing this issue for a long time now People have expressed their arguments in the ml and in the meetings It is my opinion that now everyobody understand the arguments of the = others and have their own opinion So, it seems the right moment to have a consensus poll and try to make a = decision We need to wrap up with rfc3775 bis there are some issues where the consensus has been reached, but this is = not one of them Since we would like to close these issue by next ietf, we need to do = this now > and after a quick > 2 week consensus call. 2 weeks seems a reasonable time to do a consensus call, how long do you = think we need for a consensus poll? > This is a big decision as there is impact on > released products. Right, that is why we are taking all the stpes needed to take a good = decision, Long disucssion period, disucssion in the meetings and then a = formal consensus poll with a cosndierable time so that everybody = expresses their final opinion Do you think there something in the process that can be improved > Also, the input from our Area Director in > meeting during March IETF was to retain this in the spec. > FWIW this process and in particular this consensus poll was agreed with = the AD. If you have any comments in this respect please feel free to con = contact him > Bottom line, I strongly disagree taking DHAAD out. > goo, that is what i was asking, thanks for the input Regards, marcelo > Regards > Sri > > > > > On Fri, 7 Nov 2008, Alexandru Petrescu wrote: > >> marcelo bagnulo braun wrote: >>> Hi, >>> >>> There has been a very long debate on whether we should keep or remove >>> dhaad from rfc3775bis. We would like to ask people to express >>> whether they want to keep dhaad or remove it from rfc3775bis at this >>> point. Please send your opinion before the 14 of november. >> >> DHAAD has been implemented and tested for interoperability, and is used >> by NEMOv6 rfc3963 as well - keep it in rfc3775bis. >> >> Alex >> >>> >>> (we are going to consider for this poll only the opinions sent as >>> reply to this email, so even if you think your opinion is well known, >>> reply to this email stating it again, so it can be considered as part >>> of this poll) >>> >>> Regards, marcelo >>> >>> _______________________________________________ MEXT mailing list >>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >>> >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email = >> _______________________________________________ _______________________ >> _______________________________________________ MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 8 00:18:21 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0E323A6800; Sat, 8 Nov 2008 00:18:21 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230C63A6911 for ; Sat, 8 Nov 2008 00:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.75 X-Spam-Level: X-Spam-Status: No, score=-3.75 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 xwKnWuGI1SRE for ; Sat, 8 Nov 2008 00:18:20 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 0A0BF3A6800 for ; Sat, 8 Nov 2008 00:18:19 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (104.pool85-53-136.dynamic.orange.es [85.53.136.104])by smtp03.uc3m.es (Postfix) with ESMTP id A6C2A6AF795; Sat, 8 Nov 2008 09:18:14 +0100 (CET) Message-ID: <49154B46.5080309@it.uc3m.es> Date: Sat, 08 Nov 2008 09:18:14 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Sri Gundavelli References: In-Reply-To: X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-44.1825 TC:1F TRN:51 TV:5.5.1026(16266.005) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: jari.arkko@piuha.net, mext@ietf.org Subject: Re: [MEXT] consensus call on dhaad (fwd) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org With respect to the scope of the change, i think that this change is in = the limit of what we can do with the charter. So, because of this, we have discussed this with our AD and he approved = to try this. However, the bar for removing dhaad at this point is high i.e. we need = more than rough consensus but some strong consensus to take this decision. This is the goal of this poll. Understand how strong is the consensus in = this issue. Now, concerning Charlie's comments, i do agree with Charlie that if = people are _using_ it, it is an importnat issue to be considered. That = is different from being implemented (which is hat you brought up in you = last email) If there is any people that are using this feature, please provide feedback. Regards, marcelo Sri Gundavelli escribi=F3: > > (resend, fixing the subject line) > > On Fri, 7 Nov 2008, Sri Gundavelli wrote: > >> >> Charlie's response on DHAAD deprecation issue. >> Also, the purpose of 3775-bis is primarily to fix some >> bugs and not a major rewrite of the spec. In that sense, >> we dont have the ability or charter to make such a >> fundamental change. >> >> Sri >> >> ---------- Forwarded message ---------- >> Date: Fri, 07 Nov 2008 14:58:59 -0800 >> From: Charles E. Perkins >> To: Sri Gundavelli >> Subject: Re: [OFFLIST] consensus call on dhaad (fwd) >> >> >> Hello Sri, >> >> Actually, I am neutral on this point. I don't think >> it matters whether or not it's in the spec, unless >> people are using it. And, I think that if there are >> people using it, that will present a very strong >> reason for retaining it. If, on the other hand, no >> one is using it or wants to use it, then we should take >> it out or perhaps republish it as a separate document. >> >> My previous argument for leaving it in, was just >> that taking it out would exceed the original >> purpose that was proposed for rfc3775bis. >> >> You can forward this to the list if you see fit, >> or to Jari. >> >> Regards, >> Charlie P. >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 8 00:27:24 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B0BB3A6911; Sat, 8 Nov 2008 00:27:24 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B251D28C0F4 for ; Sat, 8 Nov 2008 00:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.751 X-Spam-Level: X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 DYf+Z1R15bFT for ; Sat, 8 Nov 2008 00:27:21 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 758CA3A690E for ; Sat, 8 Nov 2008 00:27:21 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (104.pool85-53-136.dynamic.orange.es [85.53.136.104])by smtp03.uc3m.es (Postfix) with ESMTP id F37796AF786; Sat, 8 Nov 2008 09:27:16 +0100 (CET) Message-ID: <49154D64.5050507@it.uc3m.es> Date: Sat, 08 Nov 2008 09:27:16 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: "Charles E. Perkins" References: <491400A0.50700@it.uc3m.es> <49141B0F.1080806@gmail.com> <4914CEF6.5040509@earthlink.net> In-Reply-To: <4914CEF6.5040509@earthlink.net> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-38.8732 TC:1F TRN:70 TV:5.5.1026(16266.005) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Charlie, some comments about this Charles E. Perkins escribi=F3: > > Hello folks, > > For the purposes of this discussion, I will remain neutral > on the technical merits of DHAAD. However, I think it > would be pretty unwelcome for the IETF to standardize > protocol features, and then to remove them without > strong cause. I agree with this indeed So, as i mentioned in the previous email, we need a strong consensus to = remove this > > If I summarize the reasons to remove so far, we have: > a) alternative mechanisms exist > b) "no strong position on the issue, but simpler without" > > as opposed to the reasons to retain: > - "used in NEMOv6 rfc3963" > - "released products that support this feature" > - previous consensus to retain > not commenting on the technical issues, but just the last one Actually, so far, i think the consensus can have been read in different = ways, throughout the discussion. I mean, to me sometimes it felt people wanted to remove this and some = other times it felt they didn't That is why, i think that having this final poll would help us to close = this issue. So, i don't take into account the last argument, since i think it can be = interpreted either way depeding in the point in time you read the consensus. > > I don't think that all votes should be counted > equally in this debate. But there is one other > alternative to be mentioned. DHAAD "could" > be separated out into another document. I don't > know why two documents would be better than > one, but anyway it might satisfy more people. > Vendors could claim compliance to _more_ > standards. Simplifications could be had. I could > have _more_ work to do. _More_ alternatives > could be available (oops, those last two are negatives). > this last option could be a possible way forward. good input Now, i think we should finish this consensus poll and see where we are = standing (don't think chaning the consensus poll at this point is a good = idea) and if there is no clear outcome, we can try this option Regards, marcelo > Just a thought. > > Regards, > Charlie P. > > > > > Sri Gundavelli wrote: >> Hi Marcelo, >> >> Not sure, why we are running a consensus call on this issue. We already >> discussed this in March IETF and clearly the general input from the >> group was to retain DHAAD support in Mobile IPv6 specification. That >> is a feature that exists in MIP6 implementations today, in released >> products. Its used in NEMO spec and all Mobile Routers support this. >> So, we (Cisco) have two released products that support this feature. >> >> We cannot take out features in this random fashion and after a quick >> 2 week consensus call. This is a big decision as there is impact on >> released products. Also, the input from our Area Director in >> meeting during March IETF was to retain this in the spec. >> >> Bottom line, I strongly disagree taking DHAAD out. >> >> Regards >> Sri >> >> >> >> >> On Fri, 7 Nov 2008, Alexandru Petrescu wrote: >> >>> marcelo bagnulo braun wrote: >>>> Hi, >>>> >>>> There has been a very long debate on whether we should keep or remove >>>> dhaad from rfc3775bis. We would like to ask people to express >>>> whether they want to keep dhaad or remove it from rfc3775bis at this >>>> point. Please send your opinion before the 14 of november. >>> >>> DHAAD has been implemented and tested for interoperability, and is used >>> by NEMOv6 rfc3963 as well - keep it in rfc3775bis. >>> >>> Alex >>> >>>> >>>> (we are going to consider for this poll only the opinions sent as >>>> reply to this email, so even if you think your opinion is well known, >>>> reply to this email stating it again, so it can be considered as part >>>> of this poll) >>>> >>>> Regards, marcelo >>>> >>>> _______________________________________________ MEXT mailing list >>>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >>>> >>> >>> >>> ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security System. >>> For more information please visit http://www.messagelabs.com/email = >>> _______________________________________________ _______________________ >>> _______________________________________________ MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 8 00:30:09 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84DC28C170; Sat, 8 Nov 2008 00:30:09 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A28828C0F4 for ; Sat, 8 Nov 2008 00:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.751 X-Spam-Level: X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 N1WZmwE3YTuU for ; Sat, 8 Nov 2008 00:30:07 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 3BB8C3A690E for ; Sat, 8 Nov 2008 00:30:07 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.136.104])by smtp01.uc3m.es (Postfix) with ESMTP id 59BC8ACABFD; Sat, 8 Nov 2008 09:28:53 +0100 (CET) Message-ID: <49154DC4.20908@it.uc3m.es> Date: Sat, 08 Nov 2008 09:28:52 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Ahmad Muhanna References: <491400A0.50700@it.uc3m.es> <49141B0F.1080806@gmail.com><4914CEF6.5040509@earthlink.net> In-Reply-To: X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-33.9166 TC:1F TRN:72 TV:5.5.1026(16266.005) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, So, are you saying we should keep it? Regards, marcelo Ahmad Muhanna escribi=F3: > I agree with Charlie. > > Although, I understand the pain that many people have with maintaining > DHAAD, but on the other hand, I do not think it is wise to remove it and > ignore those who trusted this standard body documents and already > implemented this feature in their product. > > Regards, > Ahmad > = > > = >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On = >> Behalf Of Charles E. Perkins >> Sent: Friday, November 07, 2008 5:28 PM >> To: mext >> Subject: Re: [MEXT] consensus call on dhaad >> >> >> Hello folks, >> >> For the purposes of this discussion, I will remain neutral on = >> the technical merits of DHAAD. However, I think it would be = >> pretty unwelcome for the IETF to standardize protocol = >> features, and then to remove them without strong cause. >> >> If I summarize the reasons to remove so far, we have: >> a) alternative mechanisms exist >> b) "no strong position on the issue, but simpler without" >> >> as opposed to the reasons to retain: >> - "used in NEMOv6 rfc3963" >> - "released products that support this feature" >> - previous consensus to retain >> >> >> I don't think that all votes should be counted equally in = >> this debate. But there is one other alternative to be = >> mentioned. DHAAD "could" >> be separated out into another document. I don't know why two = >> documents would be better than one, but anyway it might = >> satisfy more people. >> Vendors could claim compliance to _more_ standards. = >> Simplifications could be had. I could have _more_ work to = >> do. _More_ alternatives could be available (oops, those last = >> two are negatives). >> >> Just a thought. >> >> Regards, >> Charlie P. >> >> >> >> >> Sri Gundavelli wrote: >> = >>> Hi Marcelo, >>> >>> Not sure, why we are running a consensus call on this issue. We = >>> already discussed this in March IETF and clearly the general input = >>> from the group was to retain DHAAD support in Mobile IPv6 = >>> specification. That is a feature that exists in MIP6 = >>> = >> implementations = >> = >>> today, in released products. Its used in NEMO spec and all = >>> = >> Mobile Routers support this. >> = >>> So, we (Cisco) have two released products that support this feature. >>> >>> We cannot take out features in this random fashion and after a quick >>> 2 week consensus call. This is a big decision as there is impact on = >>> released products. Also, the input from our Area Director = >>> = >> in meeting = >> = >>> during March IETF was to retain this in the spec. >>> >>> Bottom line, I strongly disagree taking DHAAD out. >>> >>> Regards >>> Sri >>> >>> >>> >>> >>> On Fri, 7 Nov 2008, Alexandru Petrescu wrote: >>> >>> = >>>> marcelo bagnulo braun wrote: >>>> = >>>>> Hi, >>>>> >>>>> There has been a very long debate on whether we should keep or = >>>>> remove dhaad from rfc3775bis. We would like to ask people to = >>>>> express whether they want to keep dhaad or remove it from = >>>>> rfc3775bis at this point. Please send your opinion = >>>>> = >> before the 14 of november. >> = >>>> DHAAD has been implemented and tested for interoperability, and is = >>>> used by NEMOv6 rfc3963 as well - keep it in rfc3775bis. >>>> >>>> Alex >>>> >>>> = >>>>> (we are going to consider for this poll only the = >>>>> = >> opinions sent as = >> = >>>>> reply to this email, so even if you think your opinion is well = >>>>> known, reply to this email stating it again, so it can be = >>>>> considered as part of this poll) >>>>> >>>>> Regards, marcelo >>>>> >>>>> _______________________________________________ MEXT = >>>>> = >> mailing list = >> = >>>>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> = >>>> >>>> = >> _____________________________________________________________________ >> = >>>> _ This email has been scanned by the MessageLabs Email Security = >>>> System. >>>> For more information please visit http://www.messagelabs.com/email = >>>> _______________________________________________ = >>>> _______________________ = >>>> _______________________________________________ MEXT mailing list = >>>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>>> = >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> = >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 8 02:10:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E22873A67E9; Sat, 8 Nov 2008 02:10:00 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96CB33A67E9 for ; Sat, 8 Nov 2008 02:09:59 -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 nlc5fbAE00Ri for ; Sat, 8 Nov 2008 02:09:58 -0800 (PST) Received: from xenon1.um.es (xenon1.um.es [155.54.212.161]) by core3.amsl.com (Postfix) with ESMTP id 2FAEB3A676A for ; Sat, 8 Nov 2008 02:09:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon1.um.es (Postfix) with ESMTP id 93F8D104221; Sat, 8 Nov 2008 11:09:54 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at xenon1.telemat.um.es Received: from xenon1.um.es ([127.0.0.1]) by localhost (xenon1.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25cp8eegphgz; Sat, 8 Nov 2008 11:09:51 +0100 (CET) Received: from goodie-2.local (115.Red-88-22-139.staticIP.rima-tde.net [88.22.139.115]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pedrom) by xenon1.um.es (Postfix) with ESMTP id 7C85B10423C; Sat, 8 Nov 2008 11:09:27 +0100 (CET) Message-ID: <4915654E.3090503@dif.um.es> Date: Sat, 08 Nov 2008 11:09:18 +0100 From: "Pedro M. Ruiz" User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Ryuji Wakikawa References: <4911D476.6040303@dif.um.es> In-Reply-To: Cc: "Francisco J. Galera Cuesta" , mext@ietf.org Subject: Re: [MEXT] Question about draft-ietf-monami6-multiplecoa-10.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ryuji, This idea of the virtual interface sounds very good to me. I think the = single HoA multiple CoA's approach is interesting in many scenarios. Do = you have a pointer to any of those implementations? Thanks, --Pedro Ryuji Wakikawa escribi=F3: > Hi Francisco, = > > In some implementation, HoA is assigned to a virtual "interface" and > CoAs can be assigned to physical interfaces. > It depends on implementations. I don't think we break the RFC2373. > > thanks, > ryuji > > > > > At Wed, 05 Nov 2008 18:14:30 +0100, > Francisco J. Galera Cuesta wrote: > = >> Hello all, >> >> I have a doubt in draft-ietf-monami6-multiplecoa-10.txt, but also = >> related to draft-ietf-monami6-mipv6-analysis-05 and = >> draft-ietf-monami6-multihoming-motivation-scenario-03.txt >> >> I'm considering a scenario such as the one specified in subsection 5.3. = >> ((1,n): 1 HoA, n CoAs) of draft-ietf-monami6-mipv6-analysis-05: My = >> scenario consists on a multihoming mobile node with several interfaces = >> of multiple types of access technologies. The node configures one CoA in = >> each interface, but it only has one HoA. The node may be moving and = >> changing its CoAs, but it needs ubiquitous access to the Internet, = >> maintaining communications when it is moving out of the coverage area of = >> a specific technology. >> >> My doubt is how a HoA can be binded to several interfaces? This issue is = >> commented in subsection 6.3.3 (Binding HoA to interface) of = >> draft-ietf-monami6-mipv6-analysis-05, but it is no clear for me. Is not = >> there a contradiction with RFC 2373 (IP Version 6 Addressing = >> Architecture) and especially with the following paragraph? >> >> "IPv6 addresses of all types are assigned to interfaces, not nodes. >> An IPv6 unicast address refers to a single interface. Since each >> interface belongs to a single node, any of that node's interfaces' >> unicast addresses may be used as an identifier for the node." >> >> Thanks in advance! >> >> >> >> -- = >> ---------------------------------------------------------- >> Francisco J. Galera Cuesta >> Dpto. Ingenier=EDa de la Informaci=F3n y las Comunicaciones >> Facultad de Inform=E1tica >> Universidad de Murcia >> 30100 Murcia (Spain) >> Tlf: +34 968 364644 >> ---------------------------------------------------------- >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > = -- = --------------------------------------------------------------------- Pedro M. Ruiz, Ph.D, MIEEE, MACM. E-mail: pedrom@dif.um.es Fac. Informatica, Univ. of Murcia Phone: +34968364335 Campus de Espinardo s/n Fax: +34968364151 E-30100, Espinardo, Murcia http://ants.dif.um.es/~pedrom/ SPAIN --------------------------------------------------------------------- _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 8 02:16:59 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2E173A6945; Sat, 8 Nov 2008 02:16:59 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37D33A6935 for ; Sat, 8 Nov 2008 02:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 eTgcVPh4KXM6 for ; Sat, 8 Nov 2008 02:16:57 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id C085A3A676A for ; Sat, 8 Nov 2008 02:16:56 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1Kyks1-0005Xk-Hn; Sat, 08 Nov 2008 21:16:45 +1100 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Sat, 08 Nov 2008 21:16:39 +1100 From: Hesham Soliman To: Sri Gundavelli Message-ID: Thread-Topic: [MEXT] consensus call on dhaad Thread-Index: AclBixZ4P4txhfQoXUWhnagknSL1UA== In-Reply-To: Mime-version: 1.0 Cc: Julien Laganier , mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > > On Sat, 8 Nov 2008, Hesham Soliman wrote: > >> I don't think it's terribly useful now that we defined ways for dynamic home >> address config. > > Its bit debatable if DNS based discovery mechanism is better than the > current DHAAD appraoch. There are pros and cons in both the approaches > and one can argue either way. => I wasn't comparing DNS-based approaches to DHAAD. That's comparing apples and oranges because DHAAD assumes that the MN already knows its HoA. Hesham > > There are certain useful aspects such as the ability for the Home Agent to > adjust its preference on the fly and based on the binding count, gives > some simple load balancing capability. Runtime discovery vs depending on > a static DNS configuration with potentially stale data. There are no > predictable service labels in DNS SRV records that can be used by clients > to locate nearest Home Agents. All of these cannot be ignored. > > Bottom line, the feature is modelled into the design and has dependency > on other specs and other features, so it has to survive. > > Regards > Sri > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 9 09:30:41 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3FC33A681A; Sun, 9 Nov 2008 09:30:41 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2FFA3A681A for ; Sun, 9 Nov 2008 09:30:40 -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 HhkO3xpYHXDH for ; Sun, 9 Nov 2008 09:30:39 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id B5DB33A6816 for ; Sun, 9 Nov 2008 09:30:39 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 9 Nov 2008 12:30:32 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] consensus call on dhaad Thread-Index: AclBUwy/VzzV4oUOQ4aZxNiy6XTFIgBPVWEg References: <491400A0.50700@it.uc3m.es> From: "Vijay Devarapalli" To: "Ryuji Wakikawa" , "marcelo bagnulo braun" Cc: Julien Laganier , mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ryuji, The mobile node being able to construct the home agent list by listening to the router advertisements on the home link can exist independently of DHAAD. I don't see why they should get coupled with DHAAD. Even if DHAAD gets removed, it might be useful to keep the HA list feature. It could be used for HA reliability. Each home agent would know about the other home agents on the home link without manual configuration. Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Ryuji Wakikawa > Sent: Friday, November 07, 2008 7:35 PM > To: marcelo bagnulo braun > Cc: Julien Laganier; mext > Subject: Re: [MEXT] consensus call on dhaad > > > Hi Marcelo and Julien, > > I am very neutral on this. > > However, I have one question. > If we remove DHAAD completely from the spec, shall we also remove the > - managing HA List (used for DHAAD) > - exchanging RA with HA information list for the HA list > > These two functionalities are coupled with DHAAD. > > regards, > ryuji > > > At Fri, 07 Nov 2008 09:47:28 +0100, > marcelo bagnulo braun wrote: > > > > Hi, > > > > There has been a very long debate on whether we should keep > or remove > > dhaad from rfc3775bis. > > We would like to ask people to express whether they want to > keep dhaad > > or remove it from rfc3775bis at this point. > > Please send your opinion before the 14 of november. > > > > (we are going to consider for this poll only the opinions > sent as reply > > to this email, so even if you think your opinion is well > known, reply to > > this email stating it again, so it can be considered as > part of this poll) > > > > Regards, marcelo > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 9 09:44:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747703A6905; Sun, 9 Nov 2008 09:44:03 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57123A6905 for ; Sun, 9 Nov 2008 09:44:02 -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 gyFF2jI-nf2l for ; Sun, 9 Nov 2008 09:44:02 -0800 (PST) Received: from syd-iport-1.cisco.com (syd-iport-1.cisco.com [64.104.193.196]) by core3.amsl.com (Postfix) with ESMTP id 964D73A6805 for ; Sun, 9 Nov 2008 09:44:01 -0800 (PST) Received: from syd-dkim-1.cisco.com ([64.104.193.116]) by syd-iport-1.cisco.com with ESMTP; 09 Nov 2008 17:43:57 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by syd-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mA9Hhuqi031481; Mon, 10 Nov 2008 04:43:56 +1100 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 mA9Hhu4Q025857; Sun, 9 Nov 2008 17:43:56 GMT Date: Sun, 9 Nov 2008 09:43:55 -0800 (PST) From: Sri Gundavelli To: Vijay Devarapalli In-Reply-To: Message-ID: References: <491400A0.50700@it.uc3m.es> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2363; t=1226252637; x=1227116637; c=relaxed/simple; s=syddkim1002; 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]=20consensus=20call=20on=20dhaad |Sender:=20; bh=xlB8+BT0KMuHbymsZGVZLX59pNNUHa+dJYB46BHy7O0=; b=KBrtMjozK/TZp/JBBXnenUaz/hdEW6sxPPnTIMZGZosS8MaXBjnVYRfl1P R7pfa8Ig8MWR3AqG8SijYgQsI45qQ22OxJm+enfZxkxYSQMQwMTUcTe4+tFX RxaAvQI689Fjjp2VDwV0jRNK9TNtEm112ASgbHqh1jkOrE7e45aRY=; Authentication-Results: syd-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/syddkim1002 verified; ); Cc: Julien Laganier , mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, How would you use the HA list within the scope of RFC-3775 or RFC-3963 ? Sri On Sun, 9 Nov 2008, Vijay Devarapalli wrote: > Hi Ryuji, > > The mobile node being able to construct the home agent list by listening > to the router advertisements on the home link can exist independently of > DHAAD. I don't see why they should get coupled with DHAAD. Even if DHAAD > gets removed, it might be useful to keep the HA list feature. It could > be used for HA reliability. Each home agent would know about the other > home agents on the home link without manual configuration. > > Vijay > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Ryuji Wakikawa >> Sent: Friday, November 07, 2008 7:35 PM >> To: marcelo bagnulo braun >> Cc: Julien Laganier; mext >> Subject: Re: [MEXT] consensus call on dhaad >> >> >> Hi Marcelo and Julien, >> >> I am very neutral on this. >> >> However, I have one question. >> If we remove DHAAD completely from the spec, shall we also remove the >> - managing HA List (used for DHAAD) >> - exchanging RA with HA information list for the HA list >> >> These two functionalities are coupled with DHAAD. >> >> regards, >> ryuji >> >> >> At Fri, 07 Nov 2008 09:47:28 +0100, >> marcelo bagnulo braun wrote: >>> >>> Hi, >>> >>> There has been a very long debate on whether we should keep >> or remove >>> dhaad from rfc3775bis. >>> We would like to ask people to express whether they want to >> keep dhaad >>> or remove it from rfc3775bis at this point. >>> Please send your opinion before the 14 of november. >>> >>> (we are going to consider for this poll only the opinions >> sent as reply >>> to this email, so even if you think your opinion is well >> known, reply to >>> this email stating it again, so it can be considered as >> part of this poll) >>> >>> Regards, marcelo >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 9 11:03:32 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9D913A6920; Sun, 9 Nov 2008 11:03:31 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEA493A6834 for ; Sun, 9 Nov 2008 11:03:30 -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=[AWL=0.000, 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 E8qaHjPOuad0 for ; Sun, 9 Nov 2008 11:03:29 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C6CBB3A6920 for ; Sun, 9 Nov 2008 11:03:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,569,1220227200"; d="scan'208";a="191377558" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Nov 2008 19:03:27 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mA9J3QgN030906; Sun, 9 Nov 2008 11:03:26 -0800 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 mA9J3QUf018803; Sun, 9 Nov 2008 19:03:26 GMT Date: Sun, 9 Nov 2008 11:03:26 -0800 (PST) From: Sri Gundavelli To: marcelo bagnulo braun In-Reply-To: <49154523.1020306@it.uc3m.es> Message-ID: References: <491400A0.50700@it.uc3m.es> <49141B0F.1080806@gmail.com> <49154523.1020306@it.uc3m.es> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1804928587-1226257406=:12241" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5414; t=1226257407; x=1227121407; c=relaxed/simple; s=sjdkim1004; 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]=20consensus=20call=20on=20dhaad |Sender:=20; bh=Ljn68+KWysVYj0SAZXV70GOLRpQNxmt9zI8n3dP+9Ow=; b=JSw0viszx7T3RQVaqUEhQfVrMPrgsBHmivpTrrjhLnoKWoo2UISEnFhaXk 8bnAMgN9pb4wvw7SlhX6JhV9v+dtgfwbDufFdut1lyVdzXAEqe57/HIRX4RV V0bPVoVOmK4JwZquT18wLxtPB+mJLQXWIyNr9XPKJ+dbTishkIq0I=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Julien Laganier , mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1804928587-1226257406=:12241 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Marcelo, Please see inline. On Sat, 8 Nov 2008, marcelo bagnulo braun wrote: > Hi Sri, > > I will only be addressing the procedural issues you bring in this email a= nd=20 > will not comment on the dhaad issue per se. > > Sri Gundavelli escribi=F3: >> Hi Marcelo, >> >> Not sure, why we are running a consensus call on this issue. > cause we need to define what to do with it > >> We already >> discussed this in March IETF=20 > right and we have disucssed before that as well > >> and clearly the general input from the >> group was to retain DHAAD support in Mobile IPv6 specification.=20 > > this is not my reading of the consensus > In my opinion there was no consensus and we are trying to reach one > >> That >> is a feature that exists in MIP6 implementations today, in released >> products. Its used in NEMO spec and all Mobile Routers support this >> >> So, we (Cisco) have two released products that support this feature. >>=20 > So, having this feature out of the rfc3775 bis does not means your produc= ts=20 > are no longer compliant to with the rfc, right? I mean doing more than wh= at=20 > is n the rfc doesn't imply that you don't comply with it. > There is a cost of building a product to a standard, getting compliance to that standard and for having that architecture modeled into a product. We can absolutely remove any features and still be compliant, this applies to all IETF specs. But, the impact is much more. Vendor-1 is first in the market, implemens feature-A, Vendor-2 who has no product in the market and no skin in the game till then, would love to take feature-A out from the specs. So, we have to look at this type of changes in a bit different perspective. >> We cannot take out features in this random fashion > > please provide a DETAILED explanation to me about what is random about th= is > As I see it, features are to deleted from specs when a given approach or a feature has major problems and after analysing the impact on the all the specs and after determining the overall plan. In this specific case, its not clear there is a better alternative to DHAAD that can be used. That analysis has not been done and there is no spec that identifies the impact on other specs. If we say DNS-based discovery scheme is better, its debatable, as Hesham says, DHAAD-based discovery and DNS-based discovery when compared are like comparing apples to oranges. In that sense, I said, this is bit like in random. > We have been disucssing this issue for a long time now > People have expressed their arguments in the ml and in the meetings > It is my opinion that now everyobody understand the arguments of the othe= rs=20 > and have their own opinion > So, it seems the right moment to have a consensus poll and try to make a= =20 > decision > We need to wrap up with rfc3775 bis > there are some issues where the consensus has been reached, but this is n= ot=20 > one of them > Since we would like to close these issue by next ietf, we need to do thi= s=20 > now >> and after a quick >> 2 week consensus call. > 2 weeks seems a reasonable time to do a consensus call, how long do you t= hink=20 > we need for a consensus poll? > My problem with the two week notice. Generally from my experience, any WG discussions are followed closely by 5 to 10 people. It does not mean others have no interest. There are many MIP implementations from open source to commercial, even in chipsets there are client implementations, there has to be much more participation and input before fundamental architectural changes are executed. But, I see that you already said, the bar is high and good to know that. >> This is a big decision as there is impact on >> released products. > Right, that is why we are taking all the stpes needed to take a good=20 > decision, Long disucssion period, disucssion in the meetings and then a= =20 > formal consensus poll with a cosndierable time so that everybody expresse= s=20 > their final opinion > Do you think there something in the process that can be improved > Thanks for asking this. I think, there has to be a plan. First its not clear DHAAD based scheme is really bad as perceived by some. That debate has to happen. Second, its not clear there is a better solution within the parameters of the problem scope and one that is a comparable approach. Third, if decided, we need plan to revise other specs, as this change cannot be done in isolation. > >> Also, the input from our Area Director in >> meeting during March IETF was to retain this in the spec. >>=20 > FWIW this process and in particular this consensus poll was agreed with t= he=20 > AD. If you have any comments in this respect please feel free to con cont= act=20 > him > No, thats fine. AD is listening. Thanks Sri >> Bottom line, I strongly disagree taking DHAAD out. >>=20 > goo, that is what i was asking, thanks for the input > > Regards, marcelo > > >> Regards >> Sri >>=20 >> ---559023410-1804928587-1226257406=:12241 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ---559023410-1804928587-1226257406=:12241-- From mext-bounces@ietf.org Sun Nov 9 11:04:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7010D3A6969; Sun, 9 Nov 2008 11:04:03 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 513D93A6969 for ; Sun, 9 Nov 2008 11:04:02 -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 5qppMgPTa2En for ; Sun, 9 Nov 2008 11:04:01 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8865A3A67DD for ; Sun, 9 Nov 2008 11:04:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,569,1220227200"; d="scan'208";a="191377749" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 09 Nov 2008 19:03:58 +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 mA9J3wFX014725; Sun, 9 Nov 2008 11:03:58 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mA9J3wSj004146; Sun, 9 Nov 2008 19:03:58 GMT Date: Sun, 9 Nov 2008 11:03:58 -0800 (PST) From: Sri Gundavelli To: marcelo bagnulo braun In-Reply-To: <49154B46.5080309@it.uc3m.es> Message-ID: References: <49154B46.5080309@it.uc3m.es> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1569; t=1226257438; x=1227121438; 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]=20consensus=20call=20on=20dhaad= 20(fwd) |Sender:=20; bh=0b8aJOSSGm12V9U2WLaTeOo2LG/Gsy4+5VagfkgWjUw=; b=MiqAC81XHJMT+JAyTnaEz18VbUz/QNEJtoqbaLoZrcsLTUjnL0OPNDKSgL 6cxHXJ1Wj8rDsNnXbqwO+dCOrmWu6vlG7oSjerXSziI1G98VKTmzAHaP8RkF HNpdaYSMLD; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: jari.arkko@piuha.net, mext@ietf.org Subject: Re: [MEXT] consensus call on dhaad (fwd) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, On Sat, 8 Nov 2008, marcelo bagnulo braun wrote: > With respect to the scope of the change, i think that this change is in the > limit of what we can do with the charter. > So, because of this, we have discussed this with our AD and he approved to > try this. > However, the bar for removing dhaad at this point is high i.e. we need more > than rough consensus but some strong consensus to take this decision. > This is the goal of this poll. Understand how strong is the consensus in this > issue. > Now, concerning Charlie's comments, i do agree with Charlie that if people > are _using_ it, it is an importnat issue to be considered. That is different > from being implemented (which is hat you brought up in you last email) > If there is any people that are using this feature, please provide feedback. > 3775-bis was added to the charter primarily with the note that there are some minor bugs that were identified and should be fixed. It never appeared to me *atleast* that this is for making functional/architectural changes. Case and point, this specific change has impact on other features within the draft, also on RFC-3963 and RFC-4295. Without plans to update the other specs, the change of this magnitude cannot be within the scope of 3775-bis. W.r.t your comments on how many customers are using that feature, we have released product over 3 years and that supports that feature. We have this is in use for certain Govt/Military applications and trials in many places. So, its in use. Regards Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 9 11:41:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F8FC3A6859; Sun, 9 Nov 2008 11:41:25 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9FE43A6859 for ; Sun, 9 Nov 2008 11:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=-1.251, BAYES_00=-2.599, FRT_SLUT=2.522, RCVD_BAD_ID=2.837, 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 uXeZsxKnNgNv for ; Sun, 9 Nov 2008 11:41:22 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 367DC3A6834 for ; Sun, 9 Nov 2008 11:41:21 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (104.pool85-53-136.dynamic.orange.es [85.53.136.104])by smtp03.uc3m.es (Postfix) with ESMTP id 56DB56AF445; Sun, 9 Nov 2008 20:41:14 +0100 (CET) Message-ID: <49173CD9.2000609@it.uc3m.es> Date: Sun, 09 Nov 2008 20:41:13 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Sri Gundavelli References: <491400A0.50700@it.uc3m.es> <49141B0F.1080806@gmail.com> <49154523.1020306@it.uc3m.es> In-Reply-To: X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-38.1525 TC:1F TRN:93 TV:5.5.1026(16270.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier , mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Sri Gundavelli escribi=F3: > Hi Marcelo, > > Please see inline. > > > On Sat, 8 Nov 2008, marcelo bagnulo braun wrote: > >> Hi Sri, >> >> I will only be addressing the procedural issues you bring in this = >> email and will not comment on the dhaad issue per se. >> >> Sri Gundavelli escribi=F3: >>> Hi Marcelo, >>> >>> Not sure, why we are running a consensus call on this issue. >> cause we need to define what to do with it >> >>> We already >>> discussed this in March IETF = >> right and we have disucssed before that as well >> >>> and clearly the general input from the >>> group was to retain DHAAD support in Mobile IPv6 specification. = >> >> this is not my reading of the consensus >> In my opinion there was no consensus and we are trying to reach one >> >>> That >>> is a feature that exists in MIP6 implementations today, in released >>> products. Its used in NEMO spec and all Mobile Routers support this >>> >>> So, we (Cisco) have two released products that support this feature. >>> >> So, having this feature out of the rfc3775 bis does not means your = >> products are no longer compliant to with the rfc, right? I mean doing = >> more than what is n the rfc doesn't imply that you don't comply with it. >> > > > There is a cost of building a product to a standard, getting compliance > to that standard and for having that architecture modeled into a product. > We can absolutely remove any features and still be compliant, this > applies to all IETF specs. But, the impact is much more. Vendor-1 is > first in the market, implemens feature-A, Vendor-2 who has no product in > the market and no skin in the game till then, would love to take = > feature-A > out from the specs. So, we have to look at this type of changes in a > bit different perspective. > Right, i agree that removing features from an rfc is to be considered = seriously, hence, we have a higher bar to do this. > >>> We cannot take out features in this random fashion >> >> please provide a DETAILED explanation to me about what is random = >> about this >> > > > As I see it, features are to deleted from specs when a given approach or > a feature has major problems Well, that is indeed a good reason to do that, But there may be other reasons, like for instance that the considered = feature has been superseeded by alternative mechanisms, or becuse the = particular feature is no longer relevant or for other multiple reasons. = Moreover, in order tp progress from proposed standard to draft std, it = is feasible to remove those features that no one has implemented. So, = the siutation is definitly as simple as you seem to describe Moreover, in general, i would say that as any technical decision in the = ietf, a certain feature is removed, if the wg considers that need to be = removed. (the process is the usual, we discuss and we reach some form of = concensus). > and after analysing the impact on the > all the specs well, that is a process First we decide to remove the feature and then we update the rest of the = specs so they reflect that. There is certianly no need to update all = specs at once. See for instance the deprectation of the site local = addresses. There are plenty of specs that still have the site local in = tere. there is no problem. when the other specs are updated, they = reflect this change. no big deal here. > and after determining the overall plan. = overall plan?? what do you mean? Here we have a disucssion about this particular feature whether it is = useful or not and whether we keep it or not. Not sure what is the overall plan that you are referring to > In this specific > case, its not clear there is a better alternative to DHAAD that can be > used. That analysis has not been done and there is no spec that = > identifies > the impact on other specs. If we say DNS-based discovery scheme is > better, its debatable, as Hesham says, DHAAD-based discovery and = > DNS-based > discovery when compared are like comparing apples to oranges. In that > sense, I said, this is bit like in random. > that is part of the technical disucssion that the wg needs to agree on If the WG thinks that this feature has been superseeded by alternative = ones, then so be it. As i said this is up to the wg to decide So, i come back to randomness that you mentioned before, there is = absolutelly nothing random in this consesus call. It is not like i woke = up today and randomly selected one feature of rfc3775 that i would make = a consensu call on whehter it should stay or not. The WG has been disucssing this issue for a LONG time now. there has been plenty of time to disucss the reasons to keep it and to = remove it. We have tried to reach a concensus through discussion in the = ml and in the meetings. At some point we need to wrap up and move on. = this is now. So i hope you do agree that there is nothing random about making this = consensus call > >> We have been disucssing this issue for a long time now >> People have expressed their arguments in the ml and in the meetings >> It is my opinion that now everyobody understand the arguments of the = >> others and have their own opinion >> So, it seems the right moment to have a consensus poll and try to = >> make a decision >> We need to wrap up with rfc3775 bis >> there are some issues where the consensus has been reached, but this = >> is not one of them >> Since we would like to close these issue by next ietf, we need to do = >> this now >>> and after a quick >>> 2 week consensus call. >> 2 weeks seems a reasonable time to do a consensus call, how long do = >> you think we need for a consensus poll? >> > > My problem with the two week notice. what timeframe do you think it is reasonable???? I mean, two weeks for a consensu call seems the usual tiemframe. If = people are not participating in te disucssion, then this is plenty of = time to get up to date and express their opinion... what would you = suggest, 2 months to make a consensus call? > Generally from my experience, any > WG discussions are followed closely by 5 to 10 people. right, but i have sent an email with the subject "consensus call on = dhaad" which should be clearly and easily to idenify to anyone who cares = about the subject. what would you suggest me to do in order to attract all the interested = people that should be replying to the call? Really, i am not really understanding your points about the process here > It does not > mean others have no interest. There are many MIP implementations from > open source to commercial, even in chipsets there are client > implementations, there has to be much more participation and input before > fundamental architectural changes are executed. But, I see that you > already said, the bar is high and good to know that. > > >>> This is a big decision as there is impact on >>> released products. >> Right, that is why we are taking all the stpes needed to take a good = >> decision, Long disucssion period, disucssion in the meetings and then = >> a formal consensus poll with a cosndierable time so that everybody = >> expresses their final opinion >> Do you think there something in the process that can be improved >> > > > Thanks for asking this. I think, there has to be a plan. First its not > clear DHAAD based scheme is really bad as perceived by some. That > debate has to happen. Second, its not clear there is a better solution > within the parameters of the problem scope and one that is a comparable > approach. Third, if decided, we need plan to revise other specs, as this > change cannot be done in isolation. I think i have addressed all the issues above, but just in case: - in terms of the technical merit or need for dhaad, it is up to the wg = to decide (my task is to read the consensus) - in terms of the procedure, we have been disucssing this issue for a = long time now (probably over 9 months since the first proposal to remove = dhaad was proposed)) I think that people have had enough time to ask the = relevant questions and provide answers. At some point we need to move = on. We cannot spent forever recurrently disucssing whether we keep dhaad = or not. - in terms of the other specs, once we make a decision on dhaad, if we = decide to remvoe it, we can deal with the rest of the specs when they = are updated. this is the usal procedure, i don't see any problem with that Regards, marcelo > > >> >>> Also, the input from our Area Director in >>> meeting during March IETF was to retain this in the spec. >>> >> FWIW this process and in particular this consensus poll was agreed = >> with the AD. If you have any comments in this respect please feel = >> free to con contact him >> > > No, thats fine. AD is listening. > > > Thanks > Sri > > >>> Bottom line, I strongly disagree taking DHAAD out. >>> >> goo, that is what i was asking, thanks for the input >> >> Regards, marcelo >> >> >>> Regards >>> Sri >>> >>> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 9 11:46:20 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA49E3A68FC; Sun, 9 Nov 2008 11:46:19 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A2FC3A692D for ; Sun, 9 Nov 2008 11:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.719 X-Spam-Level: X-Spam-Status: No, score=-3.719 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 ntmZUxDn4n74 for ; Sun, 9 Nov 2008 11:46:17 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 44AFB3A6964 for ; Sun, 9 Nov 2008 11:45:38 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (104.pool85-53-136.dynamic.orange.es [85.53.136.104])by smtp02.uc3m.es (Postfix) with ESMTP id C79515CB170; Sun, 9 Nov 2008 20:45:33 +0100 (CET) Message-ID: <49173DDC.9040707@it.uc3m.es> Date: Sun, 09 Nov 2008 20:45:32 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Sri Gundavelli References: <49154B46.5080309@it.uc3m.es> In-Reply-To: X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-25.1633 TC:1F TRN:50 TV:5.5.1026(16270.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: jari.arkko@piuha.net, mext@ietf.org Subject: Re: [MEXT] consensus call on dhaad (fwd) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Sri Gundavelli escribi=F3: > Hi Marcelo, > > > On Sat, 8 Nov 2008, marcelo bagnulo braun wrote: > >> With respect to the scope of the change, i think that this change is = >> in the limit of what we can do with the charter. >> So, because of this, we have discussed this with our AD and he = >> approved to try this. >> However, the bar for removing dhaad at this point is high i.e. we = >> need more than rough consensus but some strong consensus to take this = >> decision. >> This is the goal of this poll. Understand how strong is the consensus = >> in this issue. >> Now, concerning Charlie's comments, i do agree with Charlie that if = >> people are _using_ it, it is an importnat issue to be considered. = >> That is different from being implemented (which is hat you brought up = >> in you last email) >> If there is any people that are using this feature, please provide = >> feedback. >> > > 3775-bis was added to the charter primarily with the note that there > are some minor bugs that were identified and should be fixed. It never > appeared to me *atleast* that this is for making functional/architectural > changes. Case and point, this specific change has impact on other > features within the draft, also on RFC-3963 and RFC-4295. Without plans > to update the other specs, the change of this magnitude cannot be within > the scope of 3775-bis. I have addressed this issue already, but here we go again The scope fo the work of rfc3775 bis is minor changes indeed. This particular issue can be considered border line for this, so for = this reason we have consulted our AD and he agreed we can have this = disucssion. I am not sure what else do you need. With respect to the rest of the specs, as i mentioned already, this is a = process. If we decide to remove one feature, when the other specs are = updated, they need to reflect that 8see the case of the deprecation of = site local addresses, it had an impact in many rrfcs which are still = being updated) > > W.r.t your comments on how many customers are using that feature, we > have released product over 3 years and that supports that feature. > We have this is in use for certain Govt/Military applications and > trials in many places. So, its in use. > right, any deployment that i can mention to all the people that ask me = where mip is being widely used? Regards, marcelo > Regards > Sri > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 9 16:47:28 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14D43A699F; Sun, 9 Nov 2008 16:47:28 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF8733A699F for ; Sun, 9 Nov 2008 16:47:26 -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=[AWL=0.000, 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 dP-DI9SI+Z3Z for ; Sun, 9 Nov 2008 16:47:25 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 9236A3A6817 for ; Sun, 9 Nov 2008 16:47:25 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mAA0lFx10427; Mon, 10 Nov 2008 00:47:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 9 Nov 2008 18:47:08 -0600 Message-ID: In-Reply-To: <49154DC4.20908@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] consensus call on dhaad Thread-Index: AclBfDZbHqDoqr6HQleK9ve1fzULBwBTANfw References: <491400A0.50700@it.uc3m.es> <49141B0F.1080806@gmail.com><4914CEF6.5040509@earthlink.net> <49154DC4.20908@it.uc3m.es> From: "Ahmad Muhanna" To: "marcelo bagnulo braun" Cc: mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, Sorry for not replying back on time; been on a very long flight:( As I said I had two concerns: 1. keeping DHAAD in RFC3775bis has a painful consequence, IMO. 2. I believe that people who implemented this feature did so based on the t= rust they had in MEXT or MIP6 wg and IETF in general. To me it is quite ver= y important NOT to break this trust and those who implemented this feature = deserve careful consideration before making such a decision. So apparently, I chose the safest approach by leaning towards keeping DHAAD= rather than taking it out. In other words, enduring the painful consequenc= es rather than loosing the confidence of those who trusted the wg standard. However, I have been thinking of the topic inline with other IETF experienc= es as follows: 1. A very relevant example is IKE. IKEv2 deprecate IKEv1 and actually IKEv2= is NOT backward compatible with IKEv1. However, some SDOs still like IKEv2= and actually allow both in their network. 2. Your explanation that a device which support DHAAD will still be complia= nt with RFC3775bis (assuming removal of DHAAD from RFC3775bis). As you said= having more features than what in RFC3775bis is not a violation. After carefully taking the above two examples in consideration, I am more c= omfortable to support the option of REMOVING DHAAD from RFC3775bis than kee= ping it. Sorry for the long answer but I felt it is quite important to explain the b= ackground. Regards, Ahmad = > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] = > Sent: Saturday, November 08, 2008 5:29 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Charles E. Perkins; mext > Subject: Re: [MEXT] consensus call on dhaad > = > Hi Ahmad, > = > So, are you saying we should keep it? > Regards, marcelo > = > Ahmad Muhanna escribi=F3: > > I agree with Charlie. > > > > Although, I understand the pain that many people have with = > maintaining = > > DHAAD, but on the other hand, I do not think it is wise to = > remove it = > > and ignore those who trusted this standard body documents = > and already = > > implemented this feature in their product. > > > > Regards, > > Ahmad > > = > > > > = > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] = > On Behalf = > >> Of Charles E. Perkins > >> Sent: Friday, November 07, 2008 5:28 PM > >> To: mext > >> Subject: Re: [MEXT] consensus call on dhaad > >> > >> > >> Hello folks, > >> > >> For the purposes of this discussion, I will remain neutral on the = > >> technical merits of DHAAD. However, I think it would be pretty = > >> unwelcome for the IETF to standardize protocol features, = > and then to = > >> remove them without strong cause. > >> > >> If I summarize the reasons to remove so far, we have: > >> a) alternative mechanisms exist > >> b) "no strong position on the issue, but simpler without" > >> > >> as opposed to the reasons to retain: > >> - "used in NEMOv6 rfc3963" > >> - "released products that support this feature" > >> - previous consensus to retain > >> > >> > >> I don't think that all votes should be counted equally in this = > >> debate. But there is one other alternative to be = > mentioned. DHAAD = > >> "could" > >> be separated out into another document. I don't know why two = > >> documents would be better than one, but anyway it might = > satisfy more = > >> people. > >> Vendors could claim compliance to _more_ standards. = > >> Simplifications could be had. I could have _more_ work to do. = > >> _More_ alternatives could be available (oops, those last two are = > >> negatives). > >> > >> Just a thought. > >> > >> Regards, > >> Charlie P. > >> > >> > >> > >> > >> Sri Gundavelli wrote: > >> = > >>> Hi Marcelo, > >>> > >>> Not sure, why we are running a consensus call on this issue. We = > >>> already discussed this in March IETF and clearly the = > general input = > >>> from the group was to retain DHAAD support in Mobile IPv6 = > >>> specification. That is a feature that exists in MIP6 > >>> = > >> implementations > >> = > >>> today, in released products. Its used in NEMO spec and all > >>> = > >> Mobile Routers support this. > >> = > >>> So, we (Cisco) have two released products that support = > this feature. > >>> > >>> We cannot take out features in this random fashion and = > after a quick > >>> 2 week consensus call. This is a big decision as there is = > impact on = > >>> released products. Also, the input from our Area Director > >>> = > >> in meeting > >> = > >>> during March IETF was to retain this in the spec. > >>> > >>> Bottom line, I strongly disagree taking DHAAD out. > >>> > >>> Regards > >>> Sri > >>> > >>> > >>> > >>> > >>> On Fri, 7 Nov 2008, Alexandru Petrescu wrote: > >>> > >>> = > >>>> marcelo bagnulo braun wrote: > >>>> = > >>>>> Hi, > >>>>> > >>>>> There has been a very long debate on whether we should keep or = > >>>>> remove dhaad from rfc3775bis. We would like to ask people to = > >>>>> express whether they want to keep dhaad or remove it from = > >>>>> rfc3775bis at this point. Please send your opinion > >>>>> = > >> before the 14 of november. > >> = > >>>> DHAAD has been implemented and tested for = > interoperability, and is = > >>>> used by NEMOv6 rfc3963 as well - keep it in rfc3775bis. > >>>> > >>>> Alex > >>>> > >>>> = > >>>>> (we are going to consider for this poll only the > >>>>> = > >> opinions sent as > >> = > >>>>> reply to this email, so even if you think your opinion is well = > >>>>> known, reply to this email stating it again, so it can be = > >>>>> considered as part of this poll) > >>>>> > >>>>> Regards, marcelo > >>>>> > >>>>> _______________________________________________ MEXT > >>>>> = > >> mailing list > >> = > >>>>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > >>>>> > >>>>> = > >>>> > >>>> = > >> = > _____________________________________________________________________ > >> = > >>>> _ This email has been scanned by the MessageLabs Email Security = > >>>> System. > >>>> For more information please visit = > http://www.messagelabs.com/email = > >>>> _______________________________________________ > >>>> _______________________ > >>>> _______________________________________________ MEXT = > mailing list = > >>>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > >>>> > >>>> > >>>> = > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >>> > >>> > >>> = > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > >> = > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > = > = > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 9 16:59:37 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B54753A69A1; Sun, 9 Nov 2008 16:59:37 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A44E3A6782 for ; Sun, 9 Nov 2008 16:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 YU80RCEehqsE for ; Sun, 9 Nov 2008 16:59:35 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 865303A69A1 for ; Sun, 9 Nov 2008 16:59:34 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1KzL7p-000095-Or for ; Mon, 10 Nov 2008 11:59:30 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Mon, 10 Nov 2008 11:59:28 +1100 From: Hesham Soliman To: mext Message-ID: Thread-Topic: DHAAD concensus Thread-Index: AclCz5TdkravbN8xvkGH3fND7n9muw== Mime-version: 1.0 Subject: [MEXT] DHAAD concensus X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, Like I said I'm neutral on the subject but I feel compelled to make one point. There are several comments that seem to be saying removing DHAAD breaks specs, trust in IETF, vendor implementations ....etc. Frankly, I find this line of thought scary. There is *nothing* new here when it comes to removing features from specs. IETF does this ALL the time for DEPLOYED protocols. In IPv6 alone, and in the recent past we: - Deprecated site local addresses - Removed IPsec support from ND - Deprecated A6 records ....etc I hope this reasoning is not used to argue against removing anything. This is a standard procedure and there is nothing new here if DHAAD is removed. There are no interoperability or backward compatibility issues, and that's all we need to care about. Competitor advantage and other "market" issues are not in our charter... Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 9 17:13:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D4B23A6813; Sun, 9 Nov 2008 17:13:05 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CA453A6813 for ; Sun, 9 Nov 2008 17:13:03 -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 te+dR4qFpp9K for ; Sun, 9 Nov 2008 17:13:02 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id A310E3A6782 for ; Sun, 9 Nov 2008 17:13:02 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mAA1Cux11182; Mon, 10 Nov 2008 01:12:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 9 Nov 2008 19:12:50 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] DHAAD concensus Thread-Index: AclCz5TdkravbN8xvkGH3fND7n9muwAAQ2UA References: From: "Ahmad Muhanna" To: "Hesham Soliman" , "mext" Subject: Re: [MEXT] DHAAD concensus X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, Ideally, I agree with you completely. However, in the real world we live in, I would say, almost always, when people make their views on certain issues they have other than pure technical reasons in their minds. You do not want me to give examples here, right? See you in Minneapolis! Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Hesham Soliman > Sent: Monday, November 10, 2008 9:59 AM > To: mext > Subject: [MEXT] DHAAD concensus > > Folks, > > Like I said I'm neutral on the subject but I feel compelled > to make one point. There are several comments that seem to be > saying removing DHAAD breaks specs, trust in IETF, vendor > implementations ....etc. > > Frankly, I find this line of thought scary. There is > *nothing* new here when it comes to removing features from > specs. IETF does this ALL the time for DEPLOYED protocols. In > IPv6 alone, and in the recent past we: > - Deprecated site local addresses > - Removed IPsec support from ND > - Deprecated A6 records > ....etc > > I hope this reasoning is not used to argue against removing > anything. This is a standard procedure and there is nothing > new here if DHAAD is removed. > There are no interoperability or backward compatibility > issues, and that's all we need to care about. Competitor > advantage and other "market" issues are not in our charter... > > Hesham > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 9 17:47:32 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A2DA3A68FC; Sun, 9 Nov 2008 17:47:32 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22F423A68FC for ; Sun, 9 Nov 2008 17:47:31 -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 iBpngmEFrmso for ; Sun, 9 Nov 2008 17:47:30 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 1F3543A680D for ; Sun, 9 Nov 2008 17:47:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,571,1220227200"; d="scan'208";a="103111414" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 10 Nov 2008 01:47:27 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id mAA1lRjH006949; Sun, 9 Nov 2008 17:47:27 -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 mAA1lR7G004762; Mon, 10 Nov 2008 01:47:27 GMT Date: Sun, 9 Nov 2008 17:47:27 -0800 (PST) From: Sri Gundavelli To: Hesham Soliman In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2649; t=1226281647; x=1227145647; 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]=20DHAAD=20concensus |Sender:=20; bh=04oot4/ASdNMDqUpCDju6+lvnxLixML/c4T1U5TP5QA=; b=Cqd1Q6TGD6CVNfI+NJUki3aIJ2Zh1fkj4FeiJYTHQo4P1BY27LnJ+4jeXj 7Au/N0GlIZOA3iyAvAJnBd2ZTLeSHTsmEZieoiCemLjBmA8lAe5fgMkyRZ/K GFRfNcbkL7; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: mext Subject: Re: [MEXT] DHAAD concensus X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Mon, 10 Nov 2008, Hesham Soliman wrote: > Folks, > > Like I said I'm neutral on the subject but I feel compelled to make one > point. There are several comments that seem to be saying removing DHAAD > breaks specs, trust in IETF, vendor implementations ....etc. > > Frankly, I find this line of thought scary. There is *nothing* new here when > it comes to removing features from specs. IETF does this ALL the time for > DEPLOYED protocols. In IPv6 alone, and in the recent past we: IETF has the absolute power to deprecate things, when there is a need to do so. No disagreement there. But, let there be a very very good reason. Not a light statement, that some other approach is probably better than this approach. Because, there is a cost of development. The pain for the vendor who has that implementation is much higher than to the vendor who does not have that implementation. IETF has the burden to ensure, standards are not deprecated very easily, but the process itself should be much harder than the process of standardization. I may ask, in the context of DHAAD discussion, is there new data that was not there during the 3775 standardization. Did we discover some startling issues after the protocol is specd out. If I review DNS-based discovery, the use of SRV records was there before year 2000, in the form of RFC 2052 or RFC 2782. So, there is a burden on the IETF body to present a strong case, implicitly in the form of process, before a given standard is taken out. The discussion of deprecating Site Local Addresses started atleast many years before it was finally done. Its a very long process and the motivation was very strong. Some how I dont believe DHAAD falls within that scope. To some it may not be so useful, but its not harmful either as you said. May be all of this discussion is not needed, the moment the chairs said, the bar is much higher. But, for the sake of completion and on the general discussion on *deprecation*. Regards Sri > - Deprecated site local addresses > - Removed IPsec support from ND > - Deprecated A6 records > ....etc > > I hope this reasoning is not used to argue against removing anything. This > is a standard procedure and there is nothing new here if DHAAD is removed. > There are no interoperability or backward compatibility issues, and that's > all we need to care about. Competitor advantage and other "market" issues > are not in our charter... > > Hesham > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 9 18:18:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E273A68C6; Sun, 9 Nov 2008 18:18:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE593A68C6 for ; Sun, 9 Nov 2008 18:18:47 -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 OEjohOniUYlG for ; Sun, 9 Nov 2008 18:18:46 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E119D3A680D for ; Sun, 9 Nov 2008 18:18:46 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,572,1220227200"; d="scan'208";a="191485219" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 10 Nov 2008 02:18:44 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id mAA2Ii3G029268; Sun, 9 Nov 2008 18:18:44 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAA2IioX005021; Mon, 10 Nov 2008 02:18:44 GMT Date: Sun, 9 Nov 2008 18:18:43 -0800 (PST) From: Sri Gundavelli To: marcelo bagnulo braun In-Reply-To: <49173CD9.2000609@it.uc3m.es> Message-ID: References: <491400A0.50700@it.uc3m.es> <49141B0F.1080806@gmail.com> <49154523.1020306@it.uc3m.es> <49173CD9.2000609@it.uc3m.es> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1176; t=1226283524; x=1227147524; 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]=20consensus=20call=20on=20dhaad |Sender:=20; bh=hUUD0D39TPD5PnvyRU5lzNrSXueFtKGvtcPF0USPyO4=; b=TZ2SZ45oiYaLSoKJJprg7VGrNC8Y/Ejs4+QjCs0DeY0S7g77Ic8UA5ai9v GFhCdkoEf/TW6wuwubtI7uNDpfylNI/+dZ6x25EXuf/IqK4jSPm3AhAGHqKr 8i49Irz4MS; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Julien Laganier , mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, On Sun, 9 Nov 2008, marcelo bagnulo braun wrote: >> > Right, i agree that removing features from an rfc is to be considered > seriously, hence, we have a higher bar to do this. > Ok. >> > that is part of the technical disucssion that the wg needs to agree on > If the WG thinks that this feature has been superseeded by alternative ones, > then so be it. As i said this is up to the wg to decide > > So, i come back to randomness that you mentioned before, there is absolutelly > nothing random in this consesus call. It is not like i woke up today and > randomly selected one feature of rfc3775 that i would make a consensu call on > whehter it should stay or not. > > The WG has been disucssing this issue for a LONG time now. > there has been plenty of time to disucss the reasons to keep it and to remove > it. We have tried to reach a concensus through discussion in the ml and in > the meetings. At some point we need to wrap up and move on. this is now. > So i hope you do agree that there is nothing random about making this > consensus call >> Ok. Fair enough. I take that word back. Regards Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 10 00:45:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928293A69B4; Mon, 10 Nov 2008 00:45:48 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1BE73A69B4 for ; Mon, 10 Nov 2008 00:45:47 -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 He-8DARLT6qq for ; Mon, 10 Nov 2008 00:45:46 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id C24323A69A6 for ; Mon, 10 Nov 2008 00:45:46 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2527420wfd.31 for ; Mon, 10 Nov 2008 00:45:43 -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=DtU5/b1VujvpD2v8mi7SElyIJxZ2/uogQaoH3DxIe2U=; b=fhp1THytQh2akgJgng7eLBBNbDbuOfLfENccYZt8BPiRc5HFwI8xFjc2AkM+Pj5DvI F0WvqL3Xz7juXnh+jiCQQrNB56LtvhleU0b6sX+KAD2JnuGmvWs+hlOQGi2zd6ctz/qW ShxXswaqVBDdaYuoyzQh8eagH4WOQbpa/3PDk= 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=JIribtXIgvQggHPtsMWPr1ojkYi87tFf5tf4YYZyXx3Ik5FgeQPb+e9rNjWMI7Ksvz Xki1hw8s6Lbzc+FBFRVfrs/IgGoqcI20iZ/FtzSqJA66eaM1ZZuOPDNG6rk0Zro8BEoL lKF+5G6hX82TkqNaEcos4b/JS/pH7BjAUFoDM= Received: by 10.142.126.17 with SMTP id y17mr2278650wfc.33.1226306741109; Mon, 10 Nov 2008 00:45:41 -0800 (PST) Received: from ?172.17.105.52? (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 31sm10266021wff.16.2008.11.10.00.45.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Nov 2008 00:45:40 -0800 (PST) From: Ryuji Wakikawa To: Vijay Devarapalli In-Reply-To: References: <491400A0.50700@it.uc3m.es> Message-Id: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 10 Nov 2008 17:45:36 +0900 X-Mailer: Apple Mail (2.929.2) Cc: Julien Laganier , mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, RFC3775 said so. Fo example in section "10.5.1. Receiving Router Advertisement Messages" "For each link on which a router provides service as a home agent, the router maintains a Home Agents List recording information about all other home agents on that link. This list is used in the dynamic home agent address discovery mechanism, described in Section 10.5." HA reliability is not provided by RFC3775. regards, ryuji On 2008/11/10, at 2:30, Vijay Devarapalli wrote: > Hi Ryuji, > > The mobile node being able to construct the home agent list by > listening > to the router advertisements on the home link can exist > independently of > DHAAD. I don't see why they should get coupled with DHAAD. Even if > DHAAD > gets removed, it might be useful to keep the HA list feature. It could > be used for HA reliability. Each home agent would know about the other > home agents on the home link without manual configuration. > > Vijay > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Ryuji Wakikawa >> Sent: Friday, November 07, 2008 7:35 PM >> To: marcelo bagnulo braun >> Cc: Julien Laganier; mext >> Subject: Re: [MEXT] consensus call on dhaad >> >> >> Hi Marcelo and Julien, >> >> I am very neutral on this. >> >> However, I have one question. >> If we remove DHAAD completely from the spec, shall we also remove the >> - managing HA List (used for DHAAD) >> - exchanging RA with HA information list for the HA list >> >> These two functionalities are coupled with DHAAD. >> >> regards, >> ryuji >> >> >> At Fri, 07 Nov 2008 09:47:28 +0100, >> marcelo bagnulo braun wrote: >>> >>> Hi, >>> >>> There has been a very long debate on whether we should keep >> or remove >>> dhaad from rfc3775bis. >>> We would like to ask people to express whether they want to >> keep dhaad >>> or remove it from rfc3775bis at this point. >>> Please send your opinion before the 14 of november. >>> >>> (we are going to consider for this poll only the opinions >> sent as reply >>> to this email, so even if you think your opinion is well >> known, reply to >>> this email stating it again, so it can be considered as >> part of this poll) >>> >>> Regards, marcelo >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 10 00:51:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B5E33A692F; Mon, 10 Nov 2008 00:51:48 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36A763A692F for ; Mon, 10 Nov 2008 00:51:47 -0800 (PST) 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=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-bJec1mMYnz for ; Mon, 10 Nov 2008 00:51:46 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 255383A6904 for ; Mon, 10 Nov 2008 00:51:46 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2317785rvf.49 for ; Mon, 10 Nov 2008 00:51:42 -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=VtvZ6eIZJJiLBylwjh14x4UtddULEpJiG9ody4Q9bo0=; b=bPNeLzTtEkZmNGPK58knYbjqqlpJhEGxlw8nXk6lvfmIfK96dGwfCOPZCyFv9mVQEZ dajhYke0dY1V31SQuwqoGVACiULtmK575sqfjIpeqUYn+CABo6547cmPwjQg1B06Zr9w 7qn53tNAyMMJZCEwxPGB97C9Ox3QZowvY240E= 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=L5I2rfIL/aEtP7Iz6VgltNz03n+2CyNHBHFxhmUCk9EtMa+Tp6CGj+vVtI6gLFfb0p HhX+/QaX1MFBFY3pUVUHUFPHG/ZKWAvMil4T04HNcGb4t00ccDiHvDw1AHNbQjioMnSl opSEu9xXFFeU/+M7G7hGDm1mkEiWZaTSrv0BM= Received: by 10.142.153.8 with SMTP id a8mr2273722wfe.83.1226307102240; Mon, 10 Nov 2008 00:51:42 -0800 (PST) Received: from ?172.17.105.52? (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 22sm10227396wfd.7.2008.11.10.00.51.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Nov 2008 00:51:41 -0800 (PST) From: Ryuji Wakikawa To: Pedro M. Ruiz In-Reply-To: <4915654E.3090503@dif.um.es> References: <4911D476.6040303@dif.um.es> <4915654E.3090503@dif.um.es> Message-Id: <575C0DBC-01FE-470E-A3D7-E30E5A7C9FEF@gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 10 Nov 2008 17:51:38 +0900 X-Mailer: Apple Mail (2.929.2) Cc: "Francisco J. Galera Cuesta" , mext@ietf.org Subject: Re: [MEXT] Question about draft-ietf-monami6-multiplecoa-10.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Pedro, AFAIK, LINUX and BSD implementations use the approach of virtual = interface. When a MN is away from home, HoA is assigned to a virtual interface = and CoA(s) is assigned to physical interface(s). http://www.linux-ipv6.org/ http://www.kame.net/newsletter/20041211/ BSD-based implementation is not actively developed these days. thanks ryuji On 2008/11/08, at 19:09, Pedro M. Ruiz wrote: > Hi Ryuji, > > This idea of the virtual interface sounds very good to me. I think = > the single HoA multiple CoA's approach is interesting in many = > scenarios. Do you have a pointer to any of those implementations? > > Thanks, > > --Pedro > > Ryuji Wakikawa escribi=F3: >> Hi Francisco, >> In some implementation, HoA is assigned to a virtual "interface" and >> CoAs can be assigned to physical interfaces. >> It depends on implementations. I don't think we break the RFC2373. >> >> thanks, >> ryuji >> >> >> >> >> At Wed, 05 Nov 2008 18:14:30 +0100, >> Francisco J. Galera Cuesta wrote: >> >>> Hello all, >>> >>> I have a doubt in draft-ietf-monami6-multiplecoa-10.txt, but also = >>> related to draft-ietf-monami6-mipv6-analysis-05 and draft-ietf- = >>> monami6-multihoming-motivation-scenario-03.txt >>> >>> I'm considering a scenario such as the one specified in subsection = >>> 5.3. ((1,n): 1 HoA, n CoAs) of draft-ietf-monami6-mipv6- = >>> analysis-05: My scenario consists on a multihoming mobile node = >>> with several interfaces of multiple types of access technologies. = >>> The node configures one CoA in each interface, but it only has one = >>> HoA. The node may be moving and changing its CoAs, but it needs = >>> ubiquitous access to the Internet, maintaining communications when = >>> it is moving out of the coverage area of a specific technology. >>> >>> My doubt is how a HoA can be binded to several interfaces? This = >>> issue is commented in subsection 6.3.3 (Binding HoA to interface) = >>> of draft-ietf-monami6-mipv6-analysis-05, but it is no clear for = >>> me. Is not there a contradiction with RFC 2373 (IP Version 6 = >>> Addressing Architecture) and especially with the following = >>> paragraph? >>> >>> "IPv6 addresses of all types are assigned to interfaces, not nodes. >>> An IPv6 unicast address refers to a single interface. Since each >>> interface belongs to a single node, any of that node's interfaces' >>> unicast addresses may be used as an identifier for the node." >>> >>> Thanks in advance! >>> >>> >>> >>> -- = >>> ---------------------------------------------------------- >>> Francisco J. Galera Cuesta >>> Dpto. Ingenier=EDa de la Informaci=F3n y las Comunicaciones >>> Facultad de Inform=E1tica >>> Universidad de Murcia >>> 30100 Murcia (Spain) >>> Tlf: +34 968 364644 >>> ---------------------------------------------------------- >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > > -- = > --------------------------------------------------------------------- > Pedro M. Ruiz, Ph.D, MIEEE, MACM. E-mail: pedrom@dif.um.es > Fac. Informatica, Univ. of Murcia Phone: +34968364335 > Campus de Espinardo s/n Fax: +34968364151 > E-30100, Espinardo, Murcia http://ants.dif.um.es/~pedrom/ > SPAIN > --------------------------------------------------------------------- > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 10 00:54:28 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10E0A3A692F; Mon, 10 Nov 2008 00:54:28 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9963A692F for ; Mon, 10 Nov 2008 00:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 II4ZjLGU3a74 for ; Mon, 10 Nov 2008 00:54:25 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 2DBF33A6904 for ; Mon, 10 Nov 2008 00:54:25 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2530836wfd.31 for ; Mon, 10 Nov 2008 00:54:22 -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=dL8c+9SjdmtkGWv2g7qLJeBlfqSmlzpdQXsd7TVw6FQ=; b=EEoHgUqYIw/ix4z4e1v0toecqSuFdBaJV8zXxwNX3iYkWMqgdVxKQLNpRxUDYyK0vS s/zsYn+geL48ScUDAsIPTMNZ3hpPFcuexI/DuhwE9pi2S+GJdEHKiMdfn40LabhLKvDt kyGiso1t6QLGf1qWqOOFmkqnUyj7/WCibHMG8= 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=uJ7ioqSaRkS0Aykm8jY9kCDAEhGZqdM89Py3Wcmlyc/RlZ7uO8dYcjoJVbxeGpyJor d7LNsoBjgo+Ws75X/ppdvxA1LNA+dxH5ApRNd5L4/DztZAH3VZdXtnoGF7jz447zrzFS dE9G1qYl88HxF/oGFeDpQz8AZkzQAvkVyj5jI= Received: by 10.142.230.9 with SMTP id c9mr2273542wfh.101.1226307262169; Mon, 10 Nov 2008 00:54:22 -0800 (PST) Received: from ?172.17.105.52? (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 28sm10236135wfd.4.2008.11.10.00.54.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Nov 2008 00:54:21 -0800 (PST) From: Ryuji Wakikawa To: "Giaretta, Gerardo" In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D6CC34C5@NASANEXMB08.na.qualcomm.com> References: <48E3C678.5060509@earthlink.net> , <057632CE4CE10D45A1A3D6D19206C3A3D6CC34C5@NASANEXMB08.na.qualcomm.com> Message-Id: <410202A2-36F8-47E5-9B5F-1AD3444091E7@gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 10 Nov 2008 17:54:17 +0900 X-Mailer: Apple Mail (2.929.2) Cc: "mext@ietf.org" Subject: Re: [MEXT] 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Gerardo, Thanks for clarification :-) ryuji On 2008/11/08, at 14:13, Giaretta, Gerardo wrote: > Hi Ryuji, > > I agree with you on the points below but I think those scenarios are > not part of the case described in this section. > In the first case there is no entry in the BUL of the MN so the MN > has no state to clear at the HA. > The second case implies a home link detection procedure of the MN > which is different from a returning home scenario > > Thanks > Gerardo > ________________________________________ > From: mext-bounces@ietf.org [mext-bounces@ietf.org] On Behalf Of > Ryuji Wakikawa [ryuji.wakikawa@gmail.com] > Sent: Friday, November 07, 2008 8:48 PM > To: Vijay Devarapalli > Cc: mext@ietf.org > Subject: Re: [MEXT] Issue #11: De-registration when returning home > > Hi Charlie and VIjay, > > If MN knows that HA no longer holds the binding for MN, > there is no reason to send deregistration BU. > Two examples. > - MN returns home after its binding is expired. > - MN bootstraps from the home link. > > If the above two cases are not equivalent to "returning home", > I am fine with your text. > > thanks, > ryuji > > > > On 2008/11/01, at 7:56, Vijay Devarapalli wrote: > >> Hi Charlie, >> >> In the previous discussions on this issue (July 2008), we had almost >> concluded on the following text. >> >> A mobile node detects that it has returned to its home link through >> the movement detection algorithm in use (Section 11.5.1), when the >> mobile node detects that its home subnet prefix is again on-link. >> 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 a de-registration >> Binding Update, it will not be able to send and receive packets >> using its home address from the home link. The home agent will >> continue to intercept all packets sent to the mobile's home address >> and tunnel to the previously registered care-of address. >> >> Only Sri had an objection to this text. He was objecting to the last >> two >> sentences. >> >> Until the mobile node sends a de-registration >> Binding Update, it will not be able to send and receive packets >> using its home address from the home link. The home agent will >> continue to intercept all packets sent to the mobile's home address >> and tunnel to the previously registered care-of address. >> >> For the last sentences, we can replace the text with what you >> proposed >> in your email. So the final text would be >> >> A mobile node detects that it has returned to its home link through >> the movement detection algorithm in use (Section 11.5.1), when the >> mobile node detects that its home subnet prefix is again on-link. >> 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. >> >> Is this acceptable? >> >> Vijay >> >>> -----Original Message----- >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>> Behalf Of Charles E. Perkins >>> Sent: Wednesday, October 01, 2008 11:51 AM >>> To: mext@ietf.org >>> Subject: [MEXT] Issue #11: De-registration when returning home >>> >>> >>> Hello folks, >>> >>> Perhaps this issue is ready to be closed. >>> >>> I suggest we use the text offered by George >>> Tsirtsis, but with one additional change: >>> >>> >>> >>> OLD Text: >>> >>> 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). >>> The mobile >>> node SHOULD then send a Binding Update to its home agent, >>> to instruct >>> its home agent to no longer intercept or tunnel packets for it. >>> >>> >>> >>> George's Text: >>> >>> 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. >>> The mobile node SHOULD then send a Binding Update to its >>> home agent, >>> to instruct its home agent to no longer intercept or tunnel packets >>> for it. Until the mobile node sends a de-registration >>> Binding Update, >>> it will not be able to send and receive packets using its >>> home address >>> from the home link. The home agent will continue to intercept all >>> packets sent to the mobile's home address and tunnel to >>> the previously >>> registered care-of address. >>> >>> >>> >>> A slightly amended version of George's Text: >>> >>> 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. >>> The mobile node SHOULD then send a Binding Update to its >>> home agent, >>> to instruct its home agent to no longer intercept or tunnel packets >>> for it. Until the mobile node sends 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. >>> >>> ================================================== >>> >>> Regards, >>> Charlie P. >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 10 01:22:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BCC73A6A1F; Mon, 10 Nov 2008 01:22:15 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7BA3A6A1F for ; Mon, 10 Nov 2008 01:22:13 -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 JjMpYzs95mcn for ; Mon, 10 Nov 2008 01:22:12 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id BD15B3A69EF for ; Mon, 10 Nov 2008 01:22:12 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1226308928!4189854!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 22025 invoked from network); 10 Nov 2008 09:22:08 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-128.messagelabs.com with SMTP; 10 Nov 2008 09:22:08 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mAA9M8HM004105; Mon, 10 Nov 2008 02:22:08 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id mAA9M73v022026; Mon, 10 Nov 2008 03:22:07 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id mAA9M6eh022023; Mon, 10 Nov 2008 03:22:07 -0600 (CST) Message-ID: <4917FD3E.9020902@gmail.com> Date: Mon, 10 Nov 2008 10:22:06 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: marcelo bagnulo braun References: <49154B46.5080309@it.uc3m.es> In-Reply-To: <49154B46.5080309@it.uc3m.es> X-Antivirus: avast! (VPS 081108-0, 08/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] on DHAAD being used by people (was: consensus call on dhaad (fwd)) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org marcelo bagnulo braun wrote: > Now, concerning Charlie's comments, i do agree with Charlie that if > people are _using_ it, it is an important issue to be considered. > That is different from being implemented (which is hat you brought up > in you last email) If there is any people that are using this > feature, please provide feedback. Marcelo, may I ask you to clarify what do you mean by the distinction between a feature being implemented and being used by some people? And as a matter of example, can we qualify a feature as being used if it's specified by other SDO? Or by another RFC? Or by people in the street discovery their Home Agents? As a matter of example, if we say that feature X is used by SDO - does it mean it's used by people? And if we say that feature Y is used by RFC z - does it mean it's used by people? I _think_ DHAAD is not used by 3gpp-related SDOs, and in that sense we could, probably, say DHAAD is not used by people. DHAAD _is_ used by rfc3963 and in that sense we may say it is used by people. DHAAD is not used by people in the streets to discover their HAs in that final sense we may say it is not used by people. I'm just trying to understand what you mean, thank you, Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 10 01:27:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CFD43A69EF; Mon, 10 Nov 2008 01:27:39 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11C3B3A69EF for ; Mon, 10 Nov 2008 01:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.065 X-Spam-Level: X-Spam-Status: No, score=-4.065 tagged_above=-999 required=5 tests=[AWL=-1.466, 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 QF7kMexMNt1L for ; Mon, 10 Nov 2008 01:27:37 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with SMTP id 7583A3A6A21 for ; Mon, 10 Nov 2008 01:27:35 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1226309250!36500237!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 24126 invoked from network); 10 Nov 2008 09:27:31 -0000 Received: from unknown (HELO motgate5.mot.com) (136.182.1.15) by server-4.tower-119.messagelabs.com with SMTP; 10 Nov 2008 09:27:31 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id mAA9RUD7005186; Mon, 10 Nov 2008 02:27:30 -0700 (MST) Received: from il27vts01 (il27vts01.cig.mot.com [10.17.196.85]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id mAA9RUI6001004; Mon, 10 Nov 2008 03:27:30 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id mAA9RTCw000954; Mon, 10 Nov 2008 03:27:29 -0600 (CST) Message-ID: <4917FE7C.70006@gmail.com> Date: Mon, 10 Nov 2008 10:27:24 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: X-Antivirus: avast! (VPS 081108-0, 08/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext Subject: Re: [MEXT] DHAAD concensus X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hesham Soliman wrote: > Folks, > > Like I said I'm neutral on the subject but I feel compelled to make one > point. There are several comments that seem to be saying removing DHAAD > breaks specs, trust in IETF, vendor implementations ....etc. > > Frankly, I find this line of thought scary. There is *nothing* new here when > it comes to removing features from specs. IETF does this ALL the time for > DEPLOYED protocols. In IPv6 alone, and in the recent past we: > - Deprecated site local addresses > - Removed IPsec support from ND > - Deprecated A6 records > ....etc I wanted to say the same thing, it's usual to remove stuff from specs, and the above examples are relevant. However, removing stuff from MIP6 spec has been proposed in the past and it was argued against it, with valid reasons as well: keep a coherent spec, etc. Alex > I hope this reasoning is not used to argue against removing anything. This > is a standard procedure and there is nothing new here if DHAAD is removed. > There are no interoperability or backward compatibility issues, and that's > all we need to care about. Competitor advantage and other "market" issues > are not in our charter... > > Hesham > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 10 01:48:28 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF3843A69E9; Mon, 10 Nov 2008 01:48:28 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CCB53A69E9 for ; Mon, 10 Nov 2008 01:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.72 X-Spam-Level: X-Spam-Status: No, score=-3.72 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 KGFXpO4sGP3O for ; Mon, 10 Nov 2008 01:48:26 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id A2CB73A6906 for ; Mon, 10 Nov 2008 01:48:25 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (4.pool85-53-135.dynamic.orange.es [85.53.135.4])by smtp02.uc3m.es (Postfix) with ESMTP id E8CC45CA8F6; Mon, 10 Nov 2008 10:48:20 +0100 (CET) Message-ID: <49180364.3020206@it.uc3m.es> Date: Mon, 10 Nov 2008 10:48:20 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Alexandru Petrescu References: <49154B46.5080309@it.uc3m.es> <4917FD3E.9020902@gmail.com> In-Reply-To: <4917FD3E.9020902@gmail.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-20.7960 TC:1F TRN:42 TV:5.5.1026(16270.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: mext@ietf.org Subject: Re: [MEXT] on DHAAD being used by people X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alex, Alexandru Petrescu escribi=F3: > marcelo bagnulo braun wrote: >> Now, concerning Charlie's comments, i do agree with Charlie that if = >> people are _using_ it, it is an important issue to be considered. = >> That is different from being implemented (which is hat you brought up >> in you last email) If there is any people that are using this = >> feature, please provide feedback. > > Marcelo, may I ask you to clarify what do you mean by the distinction > between a feature being implemented and being used by some people? sure Implemented is that code exists Used by is that you actually people out there that they are using it = (for example the IPv4 protocol, SMTP protoocol, POP3 protocol, IMAP) > And > as a matter of example, can we qualify a feature as being used if it's > specified by other SDO? no, that is not what i called used by. (if the standards defined by = these other SDOs are deployed and used by people, then yes, but this is = different) If we have another SDO that has defined a std based on a = feature defiend in a rfc, but noone is using that in any case, this is = not what i call used by someone. However, i do agree that if another sdos relies in a feature that we are = considering to deprecate, we should take that into account as well (but = not in the used by someone category) > Or by another RFC? No, i guess it applies to the same case than below, only that this is = much more transaprent, cause we can easily grasp that > Or by people in the street > discovery their Home Agents? > right! > As a matter of example, if we say that feature X is used by SDO - does > it mean it's used by people? And if we say that feature Y is used by > RFC z - does it mean it's used by people? > > I _think_ DHAAD is not used by 3gpp-related SDOs, and in that sense we > could, probably, say DHAAD is not used by people. DHAAD _is_ used by > rfc3963 and in that sense we may say it is used by people. DHAAD is not > used by people in the streets to discover their HAs in that final sense > we may say it is not used by people. > > I'm just trying to understand what you mean, thank you, > bottom line is that if a feature, like the IPv4 protocol, is used by a = bunch of people this is very strong signal that the feature is useful. hope this is clear now regards, marcelo > Alex > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email = > ______________________________________________________________________ > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 10 07:10:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9263A6A3A; Mon, 10 Nov 2008 07:10:39 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6E23A6A3A for ; Mon, 10 Nov 2008 07:10:38 -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 kpt0LGGFXpJI for ; Mon, 10 Nov 2008 07:10:37 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 9761D3A68BA for ; Mon, 10 Nov 2008 07:10:37 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2491218rvf.49 for ; Mon, 10 Nov 2008 07:10:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=5m1T5rH+bltjkCQUdMU66CXmXPknSxqXQDp7Icsn9Hs=; b=MfC5cMAlHBi0wHvGX1dECvakua7VfJR0ADYJVznuKC+IFB1TZr7IDYCd2UdCa2ZjY3 lARo/JG8k2OhzfcwWn8BqljHwDf29VUv9Mr0LqLp143zaOIEwTZmlaFNMkRfs2z3pPqh oMhNZm3Cx/h9MK+24EM06W5Qb1RxGIobYOz1Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ZU5UhVc5wIsC6ymQJI69L3vip/VgXbhLrhauGz5ZBvs5oQDeZry37ckZNZ8hJqqymt gb9sQNbB3Y4bG1YZcPcvlfwDenOv97ZtISxbocqWD4XNJgSpEilm9WVFgAWUmdQzeq50 16ZljiVrBP8F0oj8UnHrDEI2C87CoOd5E4xaA= Received: by 10.141.164.13 with SMTP id r13mr3641471rvo.33.1226329834577; Mon, 10 Nov 2008 07:10:34 -0800 (PST) Received: by 10.141.129.3 with HTTP; Mon, 10 Nov 2008 07:10:34 -0800 (PST) Message-ID: <729b68be0811100710v60d4e8a2yfc9b124cdd5d422d@mail.gmail.com> Date: Mon, 10 Nov 2008 16:10:34 +0100 From: "Jean-Michel Combes" To: "marcelo bagnulo braun" In-Reply-To: <491400A0.50700@it.uc3m.es> MIME-Version: 1.0 Content-Disposition: inline References: <491400A0.50700@it.uc3m.es> Cc: Julien Laganier , mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, For security reasons (cf. DHAAD Harmful draft), I am in favor to remove DHAAD mechanism from rfc3775bis. Best regards. JMC. 2008/11/7 marcelo bagnulo braun : > Hi, > > There has been a very long debate on whether we should keep or remove dhaad > from rfc3775bis. > We would like to ask people to express whether they want to keep dhaad or > remove it from rfc3775bis at this point. > Please send your opinion before the 14 of november. > > (we are going to consider for this poll only the opinions sent as reply to > this email, so even if you think your opinion is well known, reply to this > email stating it again, so it can be considered as part of this poll) > > Regards, marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 10 07:51:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C985D3A6A0C; Mon, 10 Nov 2008 07:51:53 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD523A6A0C for ; Mon, 10 Nov 2008 07:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 pIn8ofwZHA7e for ; Mon, 10 Nov 2008 07:51:50 -0800 (PST) Received: from g5t0007.atlanta.hp.com (g5t0007.atlanta.hp.com [15.192.0.44]) by core3.amsl.com (Postfix) with ESMTP id 7CCE83A69B7 for ; Mon, 10 Nov 2008 07:51:50 -0800 (PST) Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45]) by g5t0007.atlanta.hp.com (Postfix) with ESMTP id 5D0B11449F; Mon, 10 Nov 2008 15:51:46 +0000 (UTC) Received: from [192.168.1.101] (squirrel.fc.hp.com [15.11.146.57]) by g1t0039.austin.hp.com (Postfix) with ESMTP id 9DE753405C; Mon, 10 Nov 2008 15:51:45 +0000 (UTC) Message-ID: <49185890.6080804@hp.com> Date: Mon, 10 Nov 2008 10:51:44 -0500 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: marcelo bagnulo braun References: <491400A0.50700@it.uc3m.es> <49141B0F.1080806@gmail.com> In-Reply-To: <49141B0F.1080806@gmail.com> Cc: Julien Laganier , mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alexandru Petrescu wrote: > marcelo bagnulo braun wrote: >> Hi, >> >> There has been a very long debate on whether we should keep or remove >> dhaad from rfc3775bis. We would like to ask people to express >> whether they want to keep dhaad or remove it from rfc3775bis at this >> point. Please send your opinion before the 14 of november. > > DHAAD has been implemented and tested for interoperability, and is used > by NEMOv6 rfc3963 as well - keep it in rfc3775bis. +1 for keeping DHAAD. -Brian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 10 08:18:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36443A686C; Mon, 10 Nov 2008 08:18:38 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFA7B3A686C for ; Mon, 10 Nov 2008 08:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 wTAj48TVYojv for ; Mon, 10 Nov 2008 08:18:34 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id AA0543A683E for ; Mon, 10 Nov 2008 08:18:33 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so953898eyd.31 for ; Mon, 10 Nov 2008 08:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=RXQUcFXGEGxNxBRxPNFfNbq2rHIrpOiEc7Pp6DSni6w=; b=aG28mkhPFHU44AurGLj8xBO6JNoCVfNeVIU/CG3vq1gT2KrdAq3mdu1VxsHqTgNY9U Jau+NXYveq+SXAMXrT8V8c5WgJ9ut6e2Qt9BmQ8YK7TWMRi0i3wAREQNlXN7098Zwhls V52QsP2dPYpvrrvNYIEApG86aVxUmSDngpLVM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=fNg83MTf3uRRZcNSa5Qf35PfeqGCtr00jXMl9gfw21p0nvllxn4JMHbG9ABIkDOJUK RYKkEEHar9LCW4dNhO/nYOY1ihg5QtluszBVQSa6/XHX/Mwr8TLQCqQa414sBlhu1NYH n1yyfrqOZm+ISo1AIRAMilsxIKp8uSPQp+liI= Received: by 10.210.87.14 with SMTP id k14mr7806026ebb.159.1226333908987; Mon, 10 Nov 2008 08:18:28 -0800 (PST) Received: by 10.210.109.14 with HTTP; Mon, 10 Nov 2008 08:18:28 -0800 (PST) Message-ID: <1d38a3350811100818y16fdccd2p3d397588fbc07761@mail.gmail.com> Date: Tue, 11 Nov 2008 00:18:28 +0800 From: "Hui Deng" To: "marcelo bagnulo braun" In-Reply-To: <491400A0.50700@it.uc3m.es> MIME-Version: 1.0 References: <491400A0.50700@it.uc3m.es> Cc: Julien Laganier , mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2135296360==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============2135296360== Content-Type: multipart/alternative; boundary="----=_Part_69245_4397347.1226333908998" ------=_Part_69245_4397347.1226333908998 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline some vendor use it and feel useful, so let's keep it. -Hui 2008/11/7 marcelo bagnulo braun > Hi, > > There has been a very long debate on whether we should keep or remove dhaad > from rfc3775bis. > We would like to ask people to express whether they want to keep dhaad or > remove it from rfc3775bis at this point. > Please send your opinion before the 14 of november. > > (we are going to consider for this poll only the opinions sent as reply to > this email, so even if you think your opinion is well known, reply to this > email stating it again, so it can be considered as part of this poll) > > Regards, marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > ------=_Part_69245_4397347.1226333908998 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
some vendor use it and feel useful, so let's keep it.
 
-Hui

2008/11/7 marcelo bagnulo braun <marcelo@it.uc3m.es>
Hi,

There has been a very long debate on whether we should keep or remove dhaad from rfc3775bis.
We would like to ask people to express whether they want to keep dhaad or remove it from rfc3775bis at this point.
Please send your opinion before the 14 of november.

(we are going to consider for this poll only the opinions sent as reply to this email, so even if you think your opinion is well known, reply to this email stating it again, so it can be considered as part of this poll)

Regards, marcelo

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

------=_Part_69245_4397347.1226333908998-- --===============2135296360== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============2135296360==-- From mext-bounces@ietf.org Mon Nov 10 14:03:36 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90DAE3A6833; Mon, 10 Nov 2008 14:03:36 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3B83A6833 for ; Mon, 10 Nov 2008 14:03:35 -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 PfGT2hqMmuzT for ; Mon, 10 Nov 2008 14:03:34 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id B45BA3A67A1 for ; Mon, 10 Nov 2008 14:03:34 -0800 (PST) Received: from [10.166.254.86] ([75.26.137.116]) by outbound.mse15.exchange.ms with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Nov 2008 17:03:27 -0500 Message-ID: <4918AFAA.1080504@wichorus.com> Date: Mon, 10 Nov 2008 14:03:22 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Ryuji Wakikawa , Sri Gundavelli References: <491400A0.50700@it.uc3m.es> In-Reply-To: X-OriginalArrivalTime: 10 Nov 2008 22:03:27.0213 (UTC) FILETIME=[288F61D0:01C94380] Cc: Julien Laganier , mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ryuji, Sri, Ryuji Wakikawa wrote: > Hi Vijay, > > RFC3775 said so. Fo example in section "10.5.1. Receiving Router > Advertisement Messages" > > "For each link on which a router provides service as a home agent, the > router maintains a Home Agents List recording information about all > other home agents on that link. This list is used in the dynamic > home agent address discovery mechanism, described in Section 10.5." > > HA reliability is not provided by RFC3775. Sri Gundavelli wrote: > Hi Vijay, > > How would you use the HA list within the scope of RFC-3775 or > RFC-3963 ? Please let me re-phrase what I wrote in my earlier email. The ability to construct of a list of home agents serving a home link dynamically is a useful feature to have. IMO, it does not have to tied to DHAAD. I suggest keeping it in 3775bis even if we decide to remove DHAAD. I would also be fine with removing the home agents list function from 3775bis and adding it to the HA reliability document. Vijay > On 2008/11/10, at 2:30, Vijay Devarapalli wrote: > >> Hi Ryuji, >> >> The mobile node being able to construct the home agent list by listening >> to the router advertisements on the home link can exist independently of >> DHAAD. I don't see why they should get coupled with DHAAD. Even if DHAAD >> gets removed, it might be useful to keep the HA list feature. It could >> be used for HA reliability. Each home agent would know about the other >> home agents on the home link without manual configuration. >> >> Vijay >> >>> -----Original Message----- >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>> Behalf Of Ryuji Wakikawa >>> Sent: Friday, November 07, 2008 7:35 PM >>> To: marcelo bagnulo braun >>> Cc: Julien Laganier; mext >>> Subject: Re: [MEXT] consensus call on dhaad >>> >>> >>> Hi Marcelo and Julien, >>> >>> I am very neutral on this. >>> >>> However, I have one question. >>> If we remove DHAAD completely from the spec, shall we also remove the >>> - managing HA List (used for DHAAD) >>> - exchanging RA with HA information list for the HA list >>> >>> These two functionalities are coupled with DHAAD. >>> >>> regards, >>> ryuji >>> >>> >>> At Fri, 07 Nov 2008 09:47:28 +0100, >>> marcelo bagnulo braun wrote: >>>> >>>> Hi, >>>> >>>> There has been a very long debate on whether we should keep >>> or remove >>>> dhaad from rfc3775bis. >>>> We would like to ask people to express whether they want to >>> keep dhaad >>>> or remove it from rfc3775bis at this point. >>>> Please send your opinion before the 14 of november. >>>> >>>> (we are going to consider for this poll only the opinions >>> sent as reply >>>> to this email, so even if you think your opinion is well >>> known, reply to >>>> this email stating it again, so it can be considered as >>> part of this poll) >>>> >>>> Regards, marcelo >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 11 07:17:28 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE7443A6840; Tue, 11 Nov 2008 07:17:28 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855A03A6B15 for ; Tue, 11 Nov 2008 07:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 iAgqb-QItO2o for ; Tue, 11 Nov 2008 07:17:26 -0800 (PST) Received: from web38804.mail.mud.yahoo.com (web38804.mail.mud.yahoo.com [209.191.125.95]) by core3.amsl.com (Postfix) with SMTP id A026F3A6B2A for ; Tue, 11 Nov 2008 07:17:26 -0800 (PST) Received: (qmail 28817 invoked by uid 60001); 11 Nov 2008 15:17:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=NiYQT69JttdWLC+XOSLD563bR7+Q8TSvL+/DL7qnGNyrguhZnZLRVCYZ3/rkYFw8wQs7Y/1tQRHXKTUPTGf3EMn5bdG3tZpn3kRvZWxlkaPL62idiJ5EQChZAVpBe80+QIWpOCjum7vWrr19xS2OLla1Q2krSbAdADIo66G8PpI=; X-YMail-OSG: eMZJEPcVM1kja5LsufgsG6TD6EiqK4kprS0W.RoZ2beKQaqiHd4GJ9ftfFLVHwDlrR.q6MaV3HO35Nofk_PM_dvBsBYW0aIELnQ_Is5SWuzQzMVlfjEgkgIvy58iidN3jdySOKifpnNtzGkVOPjww_mUWrJutsPoj0bwIdxMLo3j2nA- Received: from [206.16.17.212] by web38804.mail.mud.yahoo.com via HTTP; Tue, 11 Nov 2008 07:17:26 PST X-Mailer: YahooMailRC/1155.20 YahooMailWebService/0.7.260.1 References: <491400A0.50700@it.uc3m.es> <4918AFAA.1080504@wichorus.com> Date: Tue, 11 Nov 2008 07:17:26 -0800 (PST) From: Behcet Sarikaya To: mext MIME-Version: 1.0 Message-ID: <738529.28459.qm@web38804.mail.mud.yahoo.com> Cc: Julien Laganier Subject: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1030451767==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1030451767== Content-Type: multipart/alternative; boundary="0-248011442-1226416646=:28459" --0-248011442-1226416646=:28459 Content-Type: text/plain; charset=us-ascii Hi Marcelo, can you please clarify that DHAAD is a feature unique in MIPv6 and there is no corresponding feature in MIPv4? For example DHAAD uses anycast addresses which do not exist in IPv4. Regards, Behcet >>> At Fri, 07 Nov 2008 09:47:28 +0100, >>> marcelo bagnulo braun wrote: >>>> >>>> Hi, >>>> >>>> There has been a very long debate on whether we should keep >>> or remove >>>> dhaad from rfc3775bis. >>>> We would like to ask people to express whether they want to >>> keep dhaad >>>> or remove it from rfc3775bis at this point. >>>> Please send your opinion before the 14 of november. >>>> >>>> (we are going to consider for this poll only the opinions >>> sent as reply >>>> to this email, so even if you think your opinion is well >>> known, reply to >>>> this email stating it again, so it can be considered as >>> part of this poll) >>>> >>>> Regards, marcelo >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-248011442-1226416646=:28459 Content-Type: text/html; charset=us-ascii

Hi Marcelo, can you please clarify that DHAAD is a feature unique in MIPv6 and there is no corresponding feature in MIPv4? For example DHAAD uses anycast addresses which do not exist in IPv4.

Regards,

Behcet

>>> At Fri, 07 Nov 2008 09:47:28 +0100,
>>> marcelo bagnulo braun wrote:
>>>>
>>>> Hi,
>>>>
>>>> There has been a very long debate on whether we should keep
>>> or remove
>>>> dhaad from rfc3775bis.
>>>> We would like to ask people to express whether they want to
>>> keep dhaad
>>>> or remove it from rfc3775bis at this point.
>>>> Please send your opinion before the 14 of november.
>>>>
>>>> (we are going to consider for this poll only the opinions
>>> sent as reply
>>>> to this email, so even if you think your opinion is well
>>> known, reply to
>>>> this email stating it again, so it can be considered as
>>> part of this poll)
>>>>
>>>> Regards, marcelo
>>>>
>>>> _______________________________________________
>>>> MEXT mailing list
>>>> MEXT@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mext
>>> _______________________________________________
>>> MEXT mailing list
>>> MEXT@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mext
>>>
>

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

--0-248011442-1226416646=:28459-- --===============1030451767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1030451767==-- From mext-bounces@ietf.org Wed Nov 12 03:30:28 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA1DC3A68CC; Wed, 12 Nov 2008 03:30:28 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3B423A67AE for ; Wed, 12 Nov 2008 03:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsBzPPQowVVM for ; Wed, 12 Nov 2008 03:30:26 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id 856183A6784 for ; Wed, 12 Nov 2008 03:30:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,589,1220220000"; d="vcf'?scan'208,223";a="17124684" Received: from dhcp-rocq-185.inria.fr ([128.93.62.185]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Nov 2008 12:30:25 +0100 Message-ID: <491ABE4F.3070401@inria.fr> Date: Wed, 12 Nov 2008 12:30:23 +0100 From: Thierry Ernst Organization: INRIA User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: "Charles E. Perkins" References: <491400A0.50700@it.uc3m.es> <49141B0F.1080806@gmail.com> <4914CEF6.5040509@earthlink.net> In-Reply-To: <4914CEF6.5040509@earthlink.net> Content-Type: multipart/mixed; boundary="------------080802010609050400090109" Cc: mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------080802010609050400090109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From MIPv6's perspective I'm neutral on removing DHAAD. From NEMO's perspective, DHAAD should be kept. This makes me come to Charlie's wondering about separating specs. Instead of separating DHAAD (this is a good suggestion, indeed), I've always wonder if we shouldn't have a spec for HA, on for NEMO-MR, and one for MIP6-MH (and may be yet another one for packet format). This would a significant work, but in the end it may prove useful to implementers and archictural work but other bodies using IETF specs. Thierry Charles E. Perkins wrote: > > Hello folks, > > For the purposes of this discussion, I will remain neutral > on the technical merits of DHAAD. However, I think it > would be pretty unwelcome for the IETF to standardize > protocol features, and then to remove them without > strong cause. > > If I summarize the reasons to remove so far, we have: > a) alternative mechanisms exist > b) "no strong position on the issue, but simpler without" > > as opposed to the reasons to retain: > - "used in NEMOv6 rfc3963" > - "released products that support this feature" > - previous consensus to retain > > > I don't think that all votes should be counted > equally in this debate. But there is one other > alternative to be mentioned. DHAAD "could" > be separated out into another document. I don't > know why two documents would be better than > one, but anyway it might satisfy more people. > Vendors could claim compliance to _more_ > standards. Simplifications could be had. I could > have _more_ work to do. _More_ alternatives > could be available (oops, those last two are negatives). > > Just a thought. > > Regards, > Charlie P. > > > > > Sri Gundavelli wrote: >> Hi Marcelo, >> >> Not sure, why we are running a consensus call on this issue. We already >> discussed this in March IETF and clearly the general input from the >> group was to retain DHAAD support in Mobile IPv6 specification. That >> is a feature that exists in MIP6 implementations today, in released >> products. Its used in NEMO spec and all Mobile Routers support this. >> So, we (Cisco) have two released products that support this feature. >> >> We cannot take out features in this random fashion and after a quick >> 2 week consensus call. This is a big decision as there is impact on >> released products. Also, the input from our Area Director in >> meeting during March IETF was to retain this in the spec. >> >> Bottom line, I strongly disagree taking DHAAD out. >> >> Regards >> Sri >> >> >> >> >> On Fri, 7 Nov 2008, Alexandru Petrescu wrote: >> >>> marcelo bagnulo braun wrote: >>>> Hi, >>>> >>>> There has been a very long debate on whether we should keep or remove >>>> dhaad from rfc3775bis. We would like to ask people to express >>>> whether they want to keep dhaad or remove it from rfc3775bis at this >>>> point. Please send your opinion before the 14 of november. >>> >>> DHAAD has been implemented and tested for interoperability, and is used >>> by NEMOv6 rfc3963 as well - keep it in rfc3775bis. >>> >>> Alex >>> >>>> >>>> (we are going to consider for this poll only the opinions sent as >>>> reply to this email, so even if you think your opinion is well known, >>>> reply to this email stating it again, so it can be considered as part >>>> of this poll) >>>> >>>> Regards, marcelo >>>> >>>> _______________________________________________ MEXT mailing list >>>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >>>> >>> >>> >>> ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security System. >>> For more information please visit http://www.messagelabs.com/email >>> _______________________________________________ _______________________ >>> _______________________________________________ MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext --------------080802010609050400090109 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA Rocquencourt;IMARA - LARA adr:;;;;;;France tel;work:+33 1 39 63 59 30 tel;fax:+33 1 39 63 54 91 tel;cell:+33 6 76 56 25 96 url:http://www.lara.prd.fr version:2.1 end:vcard --------------080802010609050400090109 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --------------080802010609050400090109-- From mext-bounces@ietf.org Wed Nov 12 19:58:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F87D3A6807; Wed, 12 Nov 2008 19:58:04 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1BA93A6807 for ; Wed, 12 Nov 2008 19:58:03 -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 CFzQrjTUAk7E for ; Wed, 12 Nov 2008 19:58:03 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 07EAE3A6782 for ; Wed, 12 Nov 2008 19:58:02 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so544390ywj.49 for ; Wed, 12 Nov 2008 19:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=mY9Gqng3UKbTClxMhSnTfuZduF6gVMS59mbdxmHtX2o=; b=YSIV2fmJmOeFpL3MOsB8AbGFusMehmKnDvKCMaAzSvWCg2nmziwUwXMlpVo5wpOoHJ U8Og5P1CbKDhM/AbCysueOpocMmbB3YoPf8fI01jAe8ysnYQ0yWqntGGE5gdZlk/ar4p dSLVwTH7l83zkPd7wtN6HD8Xj0BosaNno5pog= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=cIspAw2RCyWv9R4+W3yzJ5R1vQTl0s2FQwMvB24VC+VpkKTxSRkD8NR4rOQL82+nLm aGmPJZcN20RmnUyiE3OuktqFU/jTcMQpf6ANSwMHbkZWNjAxDenYQeZ/zl/sFeFiBV03 /23XpUwsDb3JZJ4kdYpwvS5yGKy7Vr/O0Ah6g= Received: by 10.151.47.7 with SMTP id z7mr4703554ybj.172.1226548683051; Wed, 12 Nov 2008 19:58:03 -0800 (PST) Received: by 10.150.206.20 with HTTP; Wed, 12 Nov 2008 19:58:02 -0800 (PST) Message-ID: <5e2406980811121958l627f1a2l4399d704e04cd3c6@mail.gmail.com> Date: Thu, 13 Nov 2008 04:58:02 +0100 From: "Julien Bournelle" To: mext@ietf.org, draft-ietf-mip6-nemo-v4traversal@tools.ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [MEXT] Concerning DSMIP6 section 2.3.2.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Regarding the section 2.3.2.2, we have the following explanation: "After accepting the binding update, the home agent MUST create a new binding cache entry for the mobile node's IPv6 home address. If an IPv4 home address option were included, the home agent MUST create another entry for that address. All entries MUST point to the mobile node's IPv4 care-of address included in the binding update message. In addition, the tunnel used MUST indicate UDP encapsulation for NAT traversal. Hence, all packets addressed to the mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in UDP then encapsulated in an IPv4 header that includes the home agent's IPv4 address in the source address field and the mobile node's IPv4 care- of address in the destination address field." My understanding is that the IPv4 CoA is the private address, thus I don't think it will work if the HA sends UDP-encapsulated IPv4 packets to the IPv4 CoA. It should send them to the IPv4 address received in the source address field of the IPv4 packet containing the binding update (as stated later in the document in section 4.5.1). . I guess this should be corrected. Regards, Julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 13 07:31:10 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC57D3A6846; Thu, 13 Nov 2008 07:31:10 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 789E43A6846 for ; Thu, 13 Nov 2008 07:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.148, 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 9qKm5D3X6Bah for ; Thu, 13 Nov 2008 07:31:08 -0800 (PST) Received: from web38804.mail.mud.yahoo.com (web38804.mail.mud.yahoo.com [209.191.125.95]) by core3.amsl.com (Postfix) with SMTP id A64B33A6826 for ; Thu, 13 Nov 2008 07:31:08 -0800 (PST) Received: (qmail 21743 invoked by uid 60001); 13 Nov 2008 15:31:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=tKOteoLA3zv+lczDZ2bSi+CHsoukrXdvkHIQkheiiozZ6rYYWp7Dpw0Lczfjx64bZ+a7MCtDElYewEVvI9IC0CpIgXJHt8+4W+fcLYNgERmgHiDQHT/wy3DdK/I0u/o2s50Mlpege75za/igaKy0L4Y79+XaAMtKEyQDO2x5X38=; X-YMail-OSG: rvWhUtIVM1kDF0oB3NjWIcHT4MAgya3sVzS7yrksU6dsKrRO5O.6wOfMTiYop87oo0XiVDrcu.4XiBHsFOCGHbgUVA2ceDFYse98iXlPtog_O9yNzM4TvCeFISWQ_3nQInhyg6wqNpdJrpXCLL9j4B7.8G7UgqEughQAxi1E Received: from [206.16.17.212] by web38804.mail.mud.yahoo.com via HTTP; Thu, 13 Nov 2008 07:31:08 PST X-Mailer: YahooMailRC/1155.20 YahooMailWebService/0.7.260.1 Date: Thu, 13 Nov 2008 07:31:08 -0800 (PST) From: Behcet Sarikaya To: mext@ietf.org MIME-Version: 1.0 Message-ID: <587650.21289.qm@web38804.mail.mud.yahoo.com> Subject: [MEXT] draft-ng-intarea-tunnel-loop X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0342381772==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0342381772== Content-Type: multipart/alternative; boundary="0-705161801-1226590268=:21289" --0-705161801-1226590268=:21289 Content-Type: text/plain; charset=us-ascii Dear all, This draft will be presented in Mext next week. Although the solution is int-area issue but the PS belongs to mext. Two example scenarios are presented in Sec. 1.2 which make up the problem statement. In the first scenario, there is the issue of two HAs simultaneously serving MN and MN sending BUs at the home link. In the second scenario, the issue is MN sending BU at the home link. MIPv6 and DSMIPv6 are not designed to handle multiple HAs serving simultaneously. RFC 5142 handles MN switching HAs sequentially. MCoA draft also assumes a single HA serving all interfaces. MN should not send BUs at the home link. The problem here is how does MN know it is at the home link? I think this was discussed when mext was first formed. I don't remember the conclusion. I found a typo: D in PDN and PDG should stand for Data. Regards, Behcet --0-705161801-1226590268=:21289 Content-Type: text/html; charset=us-ascii
Dear all,
  This draft will be presented in Mext next week. Although the solution is int-area issue but the PS belongs to mext.
  Two example scenarios are presented in Sec. 1.2 which make up the problem statement. In the first scenario, there is the issue of two HAs simultaneously serving MN and MN sending BUs at the home link. In the second scenario, the issue is MN sending BU at the home link.
  MIPv6 and DSMIPv6 are not designed to handle multiple HAs serving simultaneously. RFC 5142 handles MN switching  HAs sequentially. MCoA draft also assumes a single HA serving all interfaces.
  MN should not send BUs at the home link. The problem here is how does MN know it is at the home link? I think this was discussed when mext was first formed. I don't remember the conclusion.
  I found a typo: D in PDN and PDG should stand for Data.

Regards,

Behcet

--0-705161801-1226590268=:21289-- --===============0342381772== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0342381772==-- From mext-bounces@ietf.org Thu Nov 13 09:48:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18AAF3A67AA; Thu, 13 Nov 2008 09:48:47 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 162023A67AA for ; Thu, 13 Nov 2008 09:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0i0K7zH93HM for ; Thu, 13 Nov 2008 09:48:45 -0800 (PST) Received: from mailhost.u-strasbg.fr (mailhost.u-strasbg.fr [130.79.200.158]) by core3.amsl.com (Postfix) with ESMTP id 9F3053A6358 for ; Thu, 13 Nov 2008 09:48:44 -0800 (PST) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id mADCx8Yg084960 ; Thu, 13 Nov 2008 13:59:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 5C5C3657DA4; Thu, 13 Nov 2008 13:59:08 +0100 (CET) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4r3ShqPrec0; Thu, 13 Nov 2008 13:59:07 +0100 (CET) Received: from wifi-default-199-225.u-strasbg.fr (wifi-default-199-225.u-strasbg.fr [130.79.199.225]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kuntz) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 02EFF657D95; Thu, 13 Nov 2008 13:59:07 +0100 (CET) Message-Id: From: Romain KUNTZ To: marcelo bagnulo braun In-Reply-To: <49131CE6.3080609@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 13 Nov 2008 13:59:06 +0100 References: <491039B9.6090400@it.uc3m.es> <49131CE6.3080609@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.u-strasbg.fr [130.79.200.158]); Thu, 13 Nov 2008 13:59:08 +0100 (CET) X-Virus-Scanned: ClamAV 0.94/8627/Thu Nov 13 10:42:40 2008 on mr8.u-strasbg.fr X-Virus-Status: Clean Cc: Julien Laganier , mext Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I would also be in favour of removing the DHAAD extension from this = document. DHCPv6-PD would most likely be used with other bootstrapping = mechanisms that are based on DNS SRV for HA lookup, which makes this = DHAAD extenstion useless. If a HA discovery mechanism should be included in the document, I = would prefer the definition of a new DNS SRV request. Regards, -- = Romain KUNTZ kuntz@lsiit.u-strasbg.fr LSIIT - Networks and Protocols Team http://clarinet.u-strasbg.fr/~kuntz/ On 2008/11/06, at 17:35, marcelo bagnulo braun wrote: > Anyone else has an opinion on whether we should cover DHAAD on this = > document or not? > > regards, marcelo > > > Vijay Devarapalli escribi=F3: >> Hi Marcelo, >> >> We should remove the extensions to DHAAD from this document. IMO, = >> it's a >> bad idea to keep extending DHAAD every time we add an extension to >> MIPv6. >> >> We could extend DNS-based HA lookup for discovering a home agent = >> that is >> capable of NEMO prefix delegation. But I think this is also = >> unnecessary. >> The mobile router can always try the next home agent in the list of = >> the >> home agents if the first one does not respond to DHCPv6 messages. If >> none of the home agents are capable of prefix delegation, then = >> there is >> nothing the mobile router can do about it, maybe use some static = >> mobile >> network prefixes. >> We had a discussion at the last IETF and on the mailing list before = >> on >> this, but there was no conclusion. >> >> Vijay >> >> >>> -----Original Message----- >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On = >>> Behalf Of marcelo bagnulo braun >>> Sent: Tuesday, November 04, 2008 4:02 AM >>> To: mext; Julien Laganier; Ralph Droms >>> Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt >>> >>> Hi, >>> >>> We now start the WGLC for: >>> >>> DHCPv6 Prefix Delegation for NEMO >>> draft-ietf-mext-nemo-pd-01.txt >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt >>> >>> >>> Please send comments about the draft till the November 19. >>> >>> Regards, Julien and marcelo >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 13 19:07:14 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51EE3A6880; Thu, 13 Nov 2008 19:07:14 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 692E93A6880 for ; Thu, 13 Nov 2008 19:07:13 -0800 (PST) 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.001, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 OIExLyfEwzr3 for ; Thu, 13 Nov 2008 19:07:12 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 574753A657C for ; Thu, 13 Nov 2008 19:07:12 -0800 (PST) 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 mAE37Bh6009795 for ; Fri, 14 Nov 2008 12:07:11 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb2) with ESMTP id mAE37Bb04402 for ; Fri, 14 Nov 2008 12:07:11 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili04) with ESMTP id mAE37BM20280 for ; Fri, 14 Nov 2008 12:07:11 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 14 Nov 2008 11:05:31 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD02FB647D@pslexc01.psl.local> In-Reply-To: <587650.21289.qm@web38804.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] draft-ng-intarea-tunnel-loop Thread-Index: AclFpN62FNm1PX4/SsS2U1eRx7JpnAAYAtew References: <587650.21289.qm@web38804.mail.mud.yahoo.com> From: "Mohana Jeyatharan" To: "Behcet Sarikaya" , Subject: Re: [MEXT] draft-ng-intarea-tunnel-loop X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2117411432==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============2117411432== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C94606.14E5A03A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C94606.14E5A03A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Behcet, =20 Thanks for reading draft. Please see reply in-line. =20 BR, Mohana ________________________________ From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Thursday, November 13, 2008 11:31 PM To: mext@ietf.org Subject: [MEXT] draft-ng-intarea-tunnel-loop =09 =09 Dear all, This draft will be presented in Mext next week. Although the solution is int-area issue but the PS belongs to mext. Two example scenarios are presented in Sec. 1.2 which make up the problem statement. In the first scenario, there is the issue of two HAs simultaneously serving MN and MN sending BUs at the home link. In the second scenario, the issue is MN sending BU at the home link.=20 In both the scenarios decsribed in the draft, the MN is not attached to its home link. If it is attached to home-link then it will not send binding updates. In the first scenario the tunnel loop is created betwee two of its HAs and in the second scenario, more of a 3GPP scenario where tunnel loop is created between ePDG and P-GW/HA. =20 MIPv6 and DSMIPv6 are not designed to handle multiple HAs serving simultaneously. RFC 5142 handles MN switching HAs sequentially. MCoA draft also assumes a single HA serving all interfaces. MN should not send BUs at the home link. The problem here is how does MN know it is at the home link?=20 I am not sure why you want to verify that this is home-link. The UE sees an address that is not its home address. Thus, it will know that=20 this is not home-link and can send BU.=20 I think this was discussed when mext was first formed. I don't remember the conclusion. I found a typo: D in PDN and PDG should stand for Data.=20 Thanks for pointing out. Yes we will make the relevant changes in future revisions.=20 =09 Regards, =09 Behcet =09 ------_=_NextPart_001_01C94606.14E5A03A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Behcet,
 
Thanks for reading draft. Please see reply=20 in-line.
 
BR,
Mohana

From: mext-bounces@ietf.org=20 [mailto:mext-bounces@ietf.org] On Behalf Of Behcet=20 Sarikaya
Sent: Thursday, November 13, 2008 11:31 = PM
To:=20 mext@ietf.org
Subject: [MEXT]=20 draft-ng-intarea-tunnel-loop

Dear all,
  This draft will be presented in Mext next = week.=20 Although the solution is int-area issue but the PS belongs to = mext.
 =20 Two example scenarios are presented in Sec. 1.2 which make up the = problem=20 statement. In the first scenario, there is the issue of two HAs = simultaneously=20 serving MN and MN sending BUs at the home link. In the second = scenario, the=20 issue is MN sending BU at the home link. 
In=20 both the scenarios decsribed in the draft, the MN is not attached to = its home=20 link. If it is attached to home-link then it will not send = binding=20 updates. In the first scenario the tunnel loop is created betwee=20 two of its HAs and in the second scenario, more of a 3GPP=20 scenario
where tunnel loop is created between ePDG and P-GW/HA.=20  
  MIPv6 and DSMIPv6 are not designed to = handle=20 multiple HAs serving simultaneously. RFC 5142 handles MN = switching  HAs=20 sequentially. MCoA draft also assumes a single HA serving all=20 interfaces.
  MN should not send BUs at the home link. The = problem=20 here is how does MN know it is at the home link? 
  I am not sure why you want to verify that this is = home-link. The=20 UE sees an address that is not its home address. Thus, it will know = that=20
this=20 is not home-link and can send BU.
  I think this was = discussed=20 when mext was first formed. I don't remember the conclusion.
  = I found=20 a typo: D in PDN and PDG should stand for Data. 
Thanks for pointing out. Yes we will make the relevant = changes in=20 future=20 = revisions. 

Regards,

Behcet

------_=_NextPart_001_01C94606.14E5A03A-- --===============2117411432== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============2117411432==-- From mext-bounces@ietf.org Fri Nov 14 00:15:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6598B3A6A3F; Fri, 14 Nov 2008 00:15:00 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05EBD3A6A39 for ; Fri, 14 Nov 2008 00:15:00 -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 woI38zUIAejc for ; Fri, 14 Nov 2008 00:14:59 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 2C6033A67E6 for ; Fri, 14 Nov 2008 00:14:58 -0800 (PST) Received: from [24.239.163.227] (helo=[192.168.1.102]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1L0tpP-0008ML-Ow; Fri, 14 Nov 2008 19:14:56 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Fri, 14 Nov 2008 19:14:48 +1100 From: Hesham Soliman To: Julien Bournelle , , Message-ID: Thread-Topic: [MEXT] Concerning DSMIP6 section 2.3.2.2 Thread-Index: AclGMQ9AtlWc5q/CikS8yRvw7BklHQ== In-Reply-To: <5e2406980811121958l627f1a2l4399d704e04cd3c6@mail.gmail.com> Mime-version: 1.0 Subject: Re: [MEXT] Concerning DSMIP6 section 2.3.2.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org We just need to make it clear that it is the CoA as seen by the HA. I.e. The src address in the v4 header. Hesham On 13/11/08 2:58 PM, "Julien Bournelle" wrote: > Hi, > > Regarding the section 2.3.2.2, we have the following explanation: > > "After accepting the binding update, the home agent MUST create a new > binding cache entry for the mobile node's IPv6 home address. If an > IPv4 home address option were included, the home agent MUST create > another entry for that address. All entries MUST point to the mobile > node's IPv4 care-of address included in the binding update message. > In addition, the tunnel used MUST indicate UDP encapsulation for NAT > traversal. Hence, all packets addressed to the mobile node's home > address(es) (IPv4 or IPv6) will be encapsulated in UDP then > encapsulated in an IPv4 header that includes the home agent's IPv4 > address in the source address field and the mobile node's IPv4 care- > of address in the destination address field." > > My understanding is that the IPv4 CoA is the private address, thus I > don't think it will work if the HA sends UDP-encapsulated IPv4 packets > to the IPv4 CoA. It should send them to the IPv4 address received in > the source > address field of the IPv4 packet containing the binding update (as > stated later in the document in section 4.5.1). > . > I guess this should be corrected. > > Regards, > > Julien > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 14 06:53:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B17128C103; Fri, 14 Nov 2008 06:53:25 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90FA428C103 for ; Fri, 14 Nov 2008 06:53:23 -0800 (PST) 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_DE=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 LRSzpGqXPmLy for ; Fri, 14 Nov 2008 06:53:22 -0800 (PST) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by core3.amsl.com (Postfix) with ESMTP id B776C28C0F3 for ; Fri, 14 Nov 2008 06:53:22 -0800 (PST) Received: from [134.102.155.235] (unknown [134.102.155.235]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTP id 6511F24EDFE for ; Fri, 14 Nov 2008 15:53:22 +0100 (CET) Message-ID: <491D90E0.7090401@comnets.uni-bremen.de> Date: Fri, 14 Nov 2008 15:53:20 +0100 From: Umar Toseef User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: mext@ietf.org Subject: [MEXT] draft-ietf-mext-flow-binding-00.txt - comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Everybody, I just went through the draft-ietf-mext-flow-binding-00.txt while previously I implemented the basic functionaliy of draft-soliman-monami6-flow-binding. It's good to see that based on the demands of reviewers authors have excluded the flow description part from the flow binding mechanism. Of course it offers more flexibility to those who want to use flow bindings with their custom way of flow description. However I have two comments on this draft. First of all, while implementing draft-soliman-monami6-flow-binding I realized that prioritizing flow bindings creates a lot of complexity when it comes to managing the flows. For example sender has to determine the overlaps and specify correct priority of each flow binding and similarly the receiver will also be taking care of priorities while installing the filters. This situation gets worse as number of flow bindings grows. In my opinion leaving priority out and using chronological order of filters at the receiving end will make things more simple and easy for practical use. Secondly, I am not a fan of n-casting option. Such mechanisms of diversity work better at lower layers therefore when lower layers are already making use of diversity then redoing it at network layer does seems very attractive to me. However these are just opinions from my side and i invite other working group members to comment on it. Have a nice weekend, Kind Regards, -- ----------------------------------------------------------------- Umar Toseef IKOM/ComNets -- FB 1 Research Engineer University of Bremen Tel: +49 421 218-8665 Otto-Hahn-Allee 1 Fax: +49 421 218-3601 28359 Bremen _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 14 07:28:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80563A67C0; Fri, 14 Nov 2008 07:28:26 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C30E23A67C0 for ; Fri, 14 Nov 2008 07:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.045, 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 MGBdCXgksxfq for ; Fri, 14 Nov 2008 07:28:23 -0800 (PST) Received: from web111411.mail.gq1.yahoo.com (web111411.mail.gq1.yahoo.com [67.195.15.192]) by core3.amsl.com (Postfix) with SMTP id D482E3A677C for ; Fri, 14 Nov 2008 07:28:23 -0800 (PST) Received: (qmail 89915 invoked by uid 60001); 14 Nov 2008 15:28:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=dRIbfCtqwzJI4fnY0iJO5vSA9lfClX/ZIOQQ9RxPHpxPxJSe2f8NeAk1mr/rrBCyuTYG7X4dTySxLDZCMqBAHvotZHepuJVC06+LFqrMLZ1DbN1onExgtkZolKe11boloxAAkI8dtyKQPACWZQdJN0iC9T07frsNgmlFlu0/x94=; X-YMail-OSG: ZMLWGB0VM1kVXivsDknaAKW5lv1WEOHJu.J6uwMzXgvR2gmYIYNUoZ_0aQIJlP.uGULjUwKTo0jSJup9_5NgPkQXI9yusjMrNFvFAZbUl.fvhQOyy1WIQ3lQCS9DBOHioREWjnZjOdr2aGKsu31sfh4IC43tHr4Z2b_3RZMOcmhELUc- Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Fri, 14 Nov 2008 07:28:23 PST X-Mailer: YahooMailRC/1155.32 YahooMailWebService/0.7.260.1 References: <587650.21289.qm@web38804.mail.mud.yahoo.com> <5F09D220B62F79418461A978CA0921BD02FB647C@pslexc01.psl.local> Date: Fri, 14 Nov 2008 07:28:23 -0800 (PST) From: Behcet Sarikaya To: Mohana Jeyatharan MIME-Version: 1.0 Message-ID: <788858.89221.qm@web111411.mail.gq1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] draft-ng-intarea-tunnel-loop X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1055671358==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1055671358== Content-Type: multipart/alternative; boundary="0-1205352472-1226676503=:89221" --0-1205352472-1226676503=:89221 Content-Type: text/plain; charset=us-ascii Hi Mohana, Please see inline. Regards, Behcet ________________________________ From: Mohana Jeyatharan To: Behcet Sarikaya ; mext@ietf.org Sent: Thursday, November 13, 2008 9:05:31 PM Subject: RE: [MEXT] draft-ng-intarea-tunnel-loop Hi Behcet, Thanks for reading draft. Please see reply in-line. BR, Mohana ________________________________ From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Thursday, November 13, 2008 11:31 PM To: mext@ietf.org Subject: [MEXT] draft-ng-intarea-tunnel-loop Dear all, This draft will be presented in Mext next week. Although the solution is int-area issue but the PS belongs to mext. Two example scenarios are presented in Sec. 1.2 which make up the problem statement. In the first scenario, there is the issue of two HAs simultaneously serving MN and MN sending BUs at the home link. In the second scenario, the issue is MN sending BU at the home link. In both the scenarios decsribed in the draft, the MN is not attached to its home link. If it is attached to home-link then it will not send binding updates. In the first scenario the tunnel loop is created betwee two of its HAs and in the second scenario, more of a 3GPP scenario where tunnel loop is created between ePDG and P-GW/HA. MIPv6 and DSMIPv6 are not designed to handle multiple HAs serving simultaneously. RFC 5142 handles MN switching HAs sequentially. MCoA draft also assumes a single HA serving all interfaces. MN should not send BUs at the home link. The problem here is how does MN know it is at the home link? I am not sure why you want to verify that this is home-link. The UE sees an address that is not its home address. Thus, it will know that this is not home-link and can send BU. [behcet] Yes UE sees an address and this address is from the new PDN if you are talking about multiple PDN connectivity. And this new PDN is supposed to be acting as another HA and therefore UE is at its home-link with the new HA. I think this was discussed when mext was first formed. I don't remember the conclusion. I found a typo: D in PDN and PDG should stand for Data. Thanks for pointing out. Yes we will make the relevant changes in future revisions. Regards, Behcet --0-1205352472-1226676503=:89221 Content-Type: text/html; charset=us-ascii
Hi Mohana,
  Please see inline.

Regards,

Behcet
From: Mohana Jeyatharan <Mohana.Jeyatharan@sg.panasonic.com>
To: Behcet Sarikaya <sarikaya@ieee.org>; mext@ietf.org
Sent: Thursday, November 13, 2008 9:05:31 PM
Subject: RE: [MEXT] draft-ng-intarea-tunnel-loop

Hi Behcet,
 
Thanks for reading draft. Please see reply in-line.
 
BR,
Mohana

From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Thursday, November 13, 2008 11:31 PM
To: mext@ietf.org
Subject: [MEXT] draft-ng-intarea-tunnel-loop

Dear all,
  This draft will be presented in Mext next week. Although the solution is int-area issue but the PS belongs to mext.
  Two example scenarios are presented in Sec. 1.2 which make up the problem statement. In the first scenario, there is the issue of two HAs simultaneously serving MN and MN sending BUs at the home link. In the second scenario, the issue is MN sending BU at the home link. 
In both the scenarios decsribed in the draft, the MN is not attached to its home link. If it is attached to home-link then it will not send binding updates. In the first scenario the tunnel loop is created betwee two of its HAs and in the second scenario, more of a 3GPP scenario
where tunnel loop is created between ePDG and P-GW/HA.  
  MIPv6 and DSMIPv6 are not designed to handle multiple HAs serving simultaneously. RFC 5142 handles MN switching  HAs sequentially. MCoA draft also assumes a single HA serving all interfaces.
  MN should not send BUs at the home link. The problem here is how does MN know it is at the home link? 
  I am not sure why you want to verify that this is home-link. The UE sees an address that is not its home address. Thus, it will know that
this is not home-link and can send BU.

[behcet] Yes UE sees an address and this address is from the new PDN if you are talking about multiple PDN connectivity. And this new PDN is supposed to be acting as another HA and therefore UE is at its home-link with the new HA.

  I think this was discussed when mext was first formed. I don't remember the conclusion.
  I found a typo: D in PDN and PDG should stand for Data. 
Thanks for pointing out. Yes we will make the relevant changes in future revisions. 

Regards,

Behcet


--0-1205352472-1226676503=:89221-- --===============1055671358== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1055671358==-- From mext-bounces@ietf.org Fri Nov 14 14:03:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75C7F3A69E3; Fri, 14 Nov 2008 14:03:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AA443A69E3 for ; Fri, 14 Nov 2008 14:03:15 -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 G-3EtI-K8Qv3 for ; Fri, 14 Nov 2008 14:03:14 -0800 (PST) Received: from mail.critical.com (mail.critical.com [64.246.137.41]) by core3.amsl.com (Postfix) with ESMTP id 3E88E3A6919 for ; Fri, 14 Nov 2008 14:03:14 -0800 (PST) Received: by mail.critical.com (Postfix, from userid 48) id 713CA3BC0E6; Fri, 14 Nov 2008 17:03:14 -0500 (EST) Received: from 64.246.137.89 (SquirrelMail authenticated user cardsw) by www.critical.com with HTTP; Fri, 14 Nov 2008 17:03:14 -0500 (EST) Message-ID: <55189.64.246.137.89.1226700194.squirrel@www.critical.com> Date: Fri, 14 Nov 2008 17:03:14 -0500 (EST) From: "Stuart W. Card" To: In-Reply-To: <491D90E0.7090401@comnets.uni-bremen.de> References: <491D90E0.7090401@comnets.uni-bremen.de> X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.10) MIME-Version: 1.0 Cc: dave.schroeder@critical.com Subject: Re: [MEXT] draft-ietf-mext-flow-binding-00.txt - comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stu.card@critical.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Umar Toseef wrote -- > ... draft-ietf-mext-flow-binding-00.txt... > I am not a fan of n-casting option. > Such mechanisms of diversity work better at lower layers > ... redoing it at network layer... Lower layers can only do it if we are balancing/coding across _links_. It is necessary to do it in the Network or Transport layer if we are balancing/coding across _paths_. The latter is more general and subsumes the former. It is central to my team's work. We are hoping that the flow binding work will give us a standards based mechanism for some elements of this. Thanks! -- Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 www.critical.com _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 14 14:55:24 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAF7F3A6A9D; Fri, 14 Nov 2008 14:55:24 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AF8C3A6A9D for ; Fri, 14 Nov 2008 14:55:23 -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 Bnd2IKTOQJ3l for ; Fri, 14 Nov 2008 14:55: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 A82453A677E for ; Fri, 14 Nov 2008 14:55:21 -0800 (PST) Received: from [24.239.163.227] (helo=[192.168.1.102]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1L17ZO-0000o3-Br; Sat, 15 Nov 2008 09:55:19 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Sat, 15 Nov 2008 09:55:08 +1100 From: Hesham Soliman To: Umar Toseef , Message-ID: Thread-Topic: [MEXT] draft-ietf-mext-flow-binding-00.txt - comments Thread-Index: AclGrApsE3huE+zyJ0+wfgho/TPLog== In-Reply-To: <491D90E0.7090401@comnets.uni-bremen.de> Mime-version: 1.0 Subject: Re: [MEXT] draft-ietf-mext-flow-binding-00.txt - comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Thanks for the review. A comment below. > I just went through the draft-ietf-mext-flow-binding-00.txt while > previously I implemented the basic functionaliy of > draft-soliman-monami6-flow-binding. It's good to see that based on the > demands of reviewers authors have excluded the flow description part > from the flow binding mechanism. Of course it offers more flexibility to > those who want to use flow bindings with their custom way of flow > description. However I have two comments on this draft. First of all, > while implementing draft-soliman-monami6-flow-binding I realized that > prioritizing flow bindings creates a lot of complexity when it comes to > managing the flows. For example sender has to determine the overlaps and > specify correct priority of each flow binding and similarly the receiver > will also be taking care of priorities while installing the filters. > This situation gets worse as number of flow bindings grows. In my > opinion leaving priority out and using chronological order of filters at > the receiving end will make things more simple and easy for practical use. => I think we need to be careful when we discuss features in terms of "simple" and "complex". You need to look at what you lose to make it simple to implement. In this case you lose a major function that handles overlaps. This is fundamental to any filtering. It's ok to have complex algorithms, it's not like the user will know anything. If we didn't have complex features there would be no google :). > Secondly, I am not a fan of n-casting option. Such mechanisms of > diversity work better at lower layers therefore when lower layers are > already making use of diversity then redoing it at network layer does > seems very attractive to me. > However these are just opinions from my side and i invite other working > group members to comment on it. => I have to agree with Stuart's comment here. Lower layers have nothing to do with this. This is an e2e feature. Hesham > Have a nice weekend, > Kind Regards, _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 14 22:11:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C30E3A68D3; Fri, 14 Nov 2008 22:11:31 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BF0E3A67EF for ; Fri, 14 Nov 2008 22:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.089 X-Spam-Level: X-Spam-Status: No, score=-0.089 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 aOz9lWvDC+MM for ; Fri, 14 Nov 2008 22:11:29 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id C96DE3A68D3 for ; Fri, 14 Nov 2008 22:11:26 -0800 (PST) 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 mAF6BG8Z026491; Sat, 15 Nov 2008 15:11:16 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id mAF6BHr21947; Sat, 15 Nov 2008 15:11:17 +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 mAF6BGN05809; Sat, 15 Nov 2008 15:11:16 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 15 Nov 2008 14:11:15 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD02FB662A@pslexc01.psl.local> In-Reply-To: <788858.89221.qm@web111411.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] draft-ng-intarea-tunnel-loop Thread-Index: AclGbaTINVEAgPlbSiSaLaCJbUF0gwAeod/A References: <587650.21289.qm@web38804.mail.mud.yahoo.com> <5F09D220B62F79418461A978CA0921BD02FB647C@pslexc01.psl.local> <788858.89221.qm@web111411.mail.gq1.yahoo.com> From: "Mohana Jeyatharan" To: "Behcet Sarikaya" Cc: mext@ietf.org Subject: Re: [MEXT] draft-ng-intarea-tunnel-loop X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1554538364==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1554538364== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C946E8.F5C6D7C0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C946E8.F5C6D7C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Behcet, =20 Please see reply in-line. =20 BR, Mohana ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Friday, November 14, 2008 11:28 PM To: Mohana Jeyatharan Cc: mext@ietf.org Subject: Re: [MEXT] draft-ng-intarea-tunnel-loop =09 =09 Hi Mohana, =09 Please see inline. =09 Regards, =09 Behcet =09 =09 ________________________________ From: Mohana Jeyatharan To: Behcet Sarikaya ; mext@ietf.org Sent: Thursday, November 13, 2008 9:05:31 PM Subject: RE: [MEXT] draft-ng-intarea-tunnel-loop =09 =09 Hi Behcet, =20 Thanks for reading draft. Please see reply in-line. =20 BR, Mohana ________________________________ From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Thursday, November 13, 2008 11:31 PM To: mext@ietf.org Subject: [MEXT] draft-ng-intarea-tunnel-loop =09 =09 Dear all, This draft will be presented in Mext next week. Although the solution is int-area issue but the PS belongs to mext. Two example scenarios are presented in Sec. 1.2 which make up the problem statement. In the first scenario, there is the issue of two HAs simultaneously serving MN and MN sending BUs at the home link. In the second scenario, the issue is MN sending BU at the home link.=20 In both the scenarios decsribed in the draft, the MN is not attached to its home link. If it is attached to home-link then it will not send binding updates. In the first scenario the tunnel loop is created betwee two of its HAs and in the second scenario, more of a 3GPP scenario where tunnel loop is created between ePDG and P-GW/HA. =20 MIPv6 and DSMIPv6 are not designed to handle multiple HAs serving simultaneously. RFC 5142 handles MN switching HAs sequentially. MCoA draft also assumes a single HA serving all interfaces. MN should not send BUs at the home link. The problem here is how does MN know it is at the home link?=20 I am not sure why you want to verify that this is home-link. The UE sees an address that is not its home address. Thus, it will know that=20 this is not home-link and can send BU. =09 [behcet] Yes UE sees an address and this address is from the new PDN if you are talking about multiple PDN connectivity. And this new PDN is supposed to be acting as another HA and therefore UE is at its home-link with the new HA. [Mohana] UE has configured two home addresses from two different P-GW/HAs. HoA1 from HA1/P-GW1 and HoA2/P-GW2. Now the address UE sees is from the local access network and not the home address from HA2 for example. Again it depends on the type of access network. If it is assigned by the e-PDG, then this address with be the DSMIPv6 CoA. It will not see the home address given by the second HA. Here the assumption is, that this is a malicious UE and it knows its home addresses obtained from different HAs and it is deliberately creating loop. Hope this helps! =09 I think this was discussed when mext was first formed. I don't remember the conclusion. I found a typo: D in PDN and PDG should stand for Data.=20 Thanks for pointing out. Yes we will make the relevant changes in future revisions.=20 =09 Regards, =09 Behcet =09 ------_=_NextPart_001_01C946E8.F5C6D7C0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Behcet,
 
Please see reply in-line.
 
BR,
Mohana

From: Behcet Sarikaya=20 [mailto:behcetsarikaya@yahoo.com]
Sent: Friday, November = 14, 2008=20 11:28 PM
To: Mohana Jeyatharan
Cc:=20 mext@ietf.org
Subject: Re: [MEXT]=20 draft-ng-intarea-tunnel-loop

Hi Mohana,
 =20 Please see inline.

Regards,

Behcet
From: Mohana = Jeyatharan=20 <Mohana.Jeyatharan@sg.panasonic.com>
To: Behcet Sarikaya=20 <sarikaya@ieee.org>; mext@ietf.org
Sent: Thursday, November 13, = 2008 9:05:31=20 PM
Subject: RE: = [MEXT]=20 draft-ng-intarea-tunnel-loop

Hi Behcet,
 
Thanks for reading draft. Please see reply=20 in-line.
 
BR,
Mohana

From: mext-bounces@ietf.org=20 [mailto:mext-bounces@ietf.org] On Behalf Of Behcet=20 Sarikaya
Sent: Thursday, November 13, 2008 11:31 = PM
To:=20 mext@ietf.org
Subject: [MEXT]=20 draft-ng-intarea-tunnel-loop

Dear all,
  This draft will be presented in Mext next = week.=20 Although the solution is int-area issue but the PS belongs to=20 mext.
  Two example scenarios are presented in Sec. 1.2 = which make=20 up the problem statement. In the first scenario, there is the issue = of two=20 HAs simultaneously serving MN and MN sending BUs at the home link. = In the=20 second scenario, the issue is MN sending BU at the home link. 
In=20 both the scenarios decsribed in the draft, the MN is not attached to = its=20 home link. If it is attached to home-link then it will = not send=20 binding updates. In the first scenario the tunnel loop is = created=20 betwee two of its HAs and in the second scenario, more of a = 3GPP=20 scenario
where tunnel loop is created between ePDG and P-GW/HA. =  
  MIPv6 and DSMIPv6 are not designed to = handle=20 multiple HAs serving simultaneously. RFC 5142 handles MN = switching  HAs=20 sequentially. MCoA draft also assumes a single HA serving all=20 interfaces.
  MN should not send BUs at the home link. The = problem=20 here is how does MN know it is at the home link? 
  I am not sure why you want to verify that this is = home-link.=20 The UE sees an address that is not its home address. Thus, it will = know that=20
this is not home-link and can send BU.

[behcet] = Yes UE sees=20 an address and this address is from the new PDN if you are talking = about=20 multiple PDN connectivity. And this new PDN is supposed to be acting = as=20 another HA and therefore UE is at its home-link with the new = HA.
 [Mohana] UE = has=20 configured two home addresses from two different P-GW/HAs. HoA1 from = HA1/P-GW1 and HoA2/P-GW2. Now the address UE sees is from the local = access=20 network and not the home address from HA2 for example. Again it = depends=20 on the type of access network. If it is assigned by the e-PDG, = then=20 this address with be the DSMIPv6=20 CoA.
 It will not = see the home=20 address given by the second HA. Here the assumption is, that this is = a=20 malicious UE and it knows its home addresses obtained from different = HAs and=20 it is deliberately creating loop. Hope this=20 helps!
  I think this was = discussed=20 when mext was first formed. I don't remember the = conclusion.
  I=20 found a typo: D in PDN and PDG should stand for Data. 
Thanks for pointing out. Yes we will make the relevant = changes in=20 future=20 = revisions. 

Regards,

Behcet


------_=_NextPart_001_01C946E8.F5C6D7C0-- --===============1554538364== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1554538364==-- From mext-bounces@ietf.org Sun Nov 16 10:22:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4FF3A697D; Sun, 16 Nov 2008 10:22:04 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310063A697D for ; Sun, 16 Nov 2008 10:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUKCnIMSVc0S for ; Sun, 16 Nov 2008 10:22:01 -0800 (PST) Received: from mailhost.u-strasbg.fr (mailhost.u-strasbg.fr [130.79.200.156]) by core3.amsl.com (Postfix) with ESMTP id 815B43A686C for ; Sun, 16 Nov 2008 10:22:01 -0800 (PST) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id mAFFq48m028712 for ; Sat, 15 Nov 2008 16:52:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id B4A03667F54 for ; Sat, 15 Nov 2008 16:52:04 +0100 (CET) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZTL1cMn6QKH for ; Sat, 15 Nov 2008 16:52:03 +0100 (CET) Received: from [192.168.0.3] (lns-bzn-52-82-65-70-135.adsl.proxad.net [82.65.70.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kuntz) by clarinet.u-strasbg.fr (Postfix) with ESMTP id B5218667F45 for ; Sat, 15 Nov 2008 16:52:03 +0100 (CET) Message-Id: <7F6E15BB-4EB8-4AEE-B462-D20E5C7FF761@lsiit.u-strasbg.fr> From: Romain KUNTZ To: mext Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 15 Nov 2008 16:52:02 +0100 X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.u-strasbg.fr [130.79.200.156]); Sat, 15 Nov 2008 16:52:06 +0100 (CET) X-Virus-Scanned: ClamAV 0.94/8636/Sat Nov 15 06:05:47 2008 on mr6.u-strasbg.fr X-Virus-Status: Clean Subject: [MEXT] UMIP, an open-source Mobile IPv6 stack for Linux X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Dear all, Let me quickly advertise UMIP, an open-source Mobile IPv6 stack for Linux. A new website has been setup at http://umip.linux-ipv6.org and contains the necessary resources and documentation to setup a Mobile IPv6 environment. It also gather pointers to various contributions that enables NEMO BS or DSMIPv6 on UMIP. Regards, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr LSIIT - Networks and Protocols Team http://clarinet.u-strasbg.fr/~kuntz/ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From n06112008@gmail.com Sun Nov 16 11:09:59 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFD3A3A6AA4; Sun, 16 Nov 2008 11:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.613 X-Spam-Level: ** X-Spam-Status: No, score=2.613 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, RAZOR2_CHECK=0.5, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a32HcAJNC4HM; Sun, 16 Nov 2008 11:09:59 -0800 (PST) Received: from maildcarg4.dc-host.net.ar (maildcarg4.dc-host.net.ar [200.55.6.135]) by core3.amsl.com (Postfix) with ESMTP id 7BB9D3A6A9D; Sun, 16 Nov 2008 11:09:59 -0800 (PST) Received: from localhost ([190.189.118.49]) by maildcarg4.dc-host.net.ar (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0KAF004GOX7CZN10@maildcarg4.dc-host.net.ar>; Sun, 16 Nov 2008 16:09:14 -0300 (ART) Received: from f3t ([127.0.0.1]) by localhost with SMTP (Code-Crafters Ability Mail Server 2.61); Sun, 16 Nov 2008 17:07:41 +0100 Date: Sun, 16 Nov 2008 17:07:41 +0100 From: "n06112008@gmail.com" Subject: SOLO POR HOY To: solo por hoy Message-id: <383-220081101616741343@f3t> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable SOLO POR HOY NOTEBOOKS con GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALLITO - CAPITAL = FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS EMail: n06112008@gmail=2Ecom CEL: 15-3197-5821 NOTEBOOKS CON DISPONIBILIDAD INMEDIATA DELL VOSTRO 1000 Procesador AMD Turion TL-60 2=2E0GHz Memoria 2GB DDR2 at 667MHz Disco Rigido 120GB SATA Hard Drive (5400RPM) Regrabadora de DVD+/-RW Pantalla 15=2E4 pulgadas WXGA Wireless WIFI Windows Vista Home en Espa=F1ol Color Negro Teclado en Espa=F1ol Precio: $2650 Hewlett Packard Pavilion dv2910us Pantalla 14=2E1" Widescreen Procesador Intel Core 2 Duo T5550 Disco Rigido 250GB Memoria 3GB DDR2 Regrabadora de DVDs and CDs Built-in wireless 802=2E11agn, Built-in webcam=20 Precio: $3500 Toshiba Satellite M305D-S4829 Pantalla 14=2E1" Widescreen CPU AMD Turion 64 DUAL CORE X2 RM-70 2GHz x 2 NUCLEOS Memoria 4GB DDR2 Disco de 250GB Regrabadora de DVDs and CDs Built-in 802=2E11bgn wireless, Built-in webcam y microfono Precio: $3500 From mext-bounces@ietf.org Mon Nov 17 00:32:59 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F289C3A69EA; Mon, 17 Nov 2008 00:32:58 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46A8B3A698A; Mon, 17 Nov 2008 00:32:58 -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 0BiSduYjrQE8; Mon, 17 Nov 2008 00:32:57 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 4388A3A696C; Mon, 17 Nov 2008 00:32:57 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1L1zXG-0006cY-98; Mon, 17 Nov 2008 09:32:42 +0100 X-Hashcash: 1:20:081117:mext@ietf.org::uS+ElyPx6d1zShNw:00002aX9 X-Hashcash: 1:20:081117:mobopts@irtf.org::rBHPMCBm0o28YDvh:00gRY X-Hashcash: 1:20:081117:ipsec@ietf.org::rW2BcA47NML8k/be:000EcwZ From: arno@natisbad.org (Arnaud Ebalard) To: IETF MEXT WG ML X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 Date: Mon, 17 Nov 2008 00:30:57 -0800 Message-ID: <87d4guwy7y.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: IPsec IETF WG ML , Mobopts IRTF WG ML Subject: [MEXT] MIPv6 IPsec Route Optimization (IRO) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Sorry for crossposting but the topic discussed in the draft may be of interest for people of the 3 lists. > IETF I-D Submission Tool writes: > > A new version of I-D, draft-ebalard-mext-ipsec-ro-00.txt has been > successfuly submitted by Arnaud Ebalard and posted to the IETF > repository. > > Filename: draft-ebalard-mext-ipsec-ro > Revision: 00 > Title: Mobile IPv6 IPsec Route Optimization (IRO) > Creation_date: 2008-11-17 > WG ID: Independent Submission > Number_of_pages: 44 > > Abstract: > > This memo specifies an improved alternate route optimization procedure > for Mobile IPv6 designed specifically for environments where IPsec is > used between peers (most probably with IKE). The replacement of the > complex Return Routability procedure for a simple mechanism and the > removal of HAO and RH2 extensions from exchanged packets result in > performance and security improvements. I have just submitted a new I-D [1] which certainly requires an introduction (and disclaimer): it specifies a MIPv6 Route Optimization procedure *dedicated* to environments where IPsec/IKE is used between peers (MN-HA, MN-CN, MN-MN) for protecting both signaling and data traffic. Some of the improvements provided by this "IPsec Route Optimization" mechanism (IRO) are also proposed for the IPsec communications between the MN and its HA. Among the features provided by IRO (introduction of the document as a more accurate list): * Complete removal of RH2 and HAO (resulting in simplified packet handling on both sides and possibly better compatibility with filtering implemented in the network), * Per packet MTU gains between 24 and 48 bytes in comparison with equivalent uses of IPsec in standard RO context, * Improved and more generic proof of address ownership mechanism, * Safe by default behavior avoiding direct unprotected traffic flows, * No additionnal changes to IPsec or IKE protocols and limited changes to MIPv6 via four simple messages and a single option. Next steps is to gather some initial feedback from interested people of the WG. Then, I intend to spend some time implementing it (under Linux) to challenge the ideas provided in the draft. Comments are welcome. Note that this is a -00 which implies that some parts are still quite raw and might deserve additional comments/work. Cheers, a+ [1]: http://www.ietf.org/internet-drafts/draft-ebalard-mext-ipsec-ro-00.txt _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 02:13:43 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 103913A687A; Mon, 17 Nov 2008 02:13:43 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14E053A687A for ; Mon, 17 Nov 2008 02:13:42 -0800 (PST) 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_DE=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 BJ1Rd0srvVdB for ; Mon, 17 Nov 2008 02:13:41 -0800 (PST) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by core3.amsl.com (Postfix) with ESMTP id DA0473A686A for ; Mon, 17 Nov 2008 02:13:40 -0800 (PST) Received: from HPNX6320 (unknown [134.102.155.223]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTP id 15B0224EE06; Mon, 17 Nov 2008 11:13:40 +0100 (CET) From: "Asanga Udugama" To: "'Hesham Soliman'" , "'Umar Toseef'" , References: <491D90E0.7090401@comnets.uni-bremen.de> Date: Mon, 17 Nov 2008 11:13:59 +0100 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3311 Thread-index: AclGrApsE3huE+zyJ0+wfgho/TPLogB5ZEAg Subject: Re: [MEXT] draft-ietf-mext-flow-binding-00.txt - comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello all, I too have a lot of experience in using the implementation done by Umar of the draft-soliman-monami6-flow-binding. In my opinion, I believe that this is a very clear and a simple draft, which follows the KISS principle. Some time back, I too implemented a similar flow management draft on MIPv4. It was done on the Sun Labs MIPv4 and it was called NOMAD. Similar to Umar's implementation, it too used the packet marking and multiple routing table features available in Linux. When I did this implementation, there were other simple features that were present in it compared to this draft. I would like to ask the authors, why these have been removed. Was there any reason to leave these out? 2 of these are, 1) Splitting flows - Meaning that the packets of a single flow are placed on different attachments. I know that TCP would perform adversely but some UDP based applications may perform better. Further, the draft that I implemented also allowed the specification of the packet distribution ration, which I found very interesting as then, the ratio can be optimally decided to cater to the different characteristics of the network attachments 2) Free-form filters - Meaning that we could set filters based on any part of the packet, rather than only the headers. I know that this may not be possible when the payload is encrypted. But still there maybe instances when pattern matching maybe done on the payload to identify a flow. Kind regards, Asanga > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Hesham Soliman > Sent: 14 November 2008 23:55 > To: Umar Toseef; mext@ietf.org > Subject: Re: [MEXT] draft-ietf-mext-flow-binding-00.txt - comments > > Thanks for the review. A comment below. > > > I just went through the draft-ietf-mext-flow-binding-00.txt while > > previously I implemented the basic functionaliy of > > draft-soliman-monami6-flow-binding. It's good to see that based on the > > demands of reviewers authors have excluded the flow description part > > from the flow binding mechanism. Of course it offers more flexibility to > > those who want to use flow bindings with their custom way of flow > > description. However I have two comments on this draft. First of all, > > while implementing draft-soliman-monami6-flow-binding I realized that > > prioritizing flow bindings creates a lot of complexity when it comes to > > managing the flows. For example sender has to determine the overlaps and > > specify correct priority of each flow binding and similarly the receiver > > will also be taking care of priorities while installing the filters. > > This situation gets worse as number of flow bindings grows. In my > > opinion leaving priority out and using chronological order of filters at > > the receiving end will make things more simple and easy for practical > use. > > => I think we need to be careful when we discuss features in terms of > "simple" and "complex". You need to look at what you lose to make it > simple > to implement. In this case you lose a major function that handles > overlaps. > This is fundamental to any filtering. It's ok to have complex algorithms, > it's not like the user will know anything. If we didn't have complex > features there would be no google :). > > > Secondly, I am not a fan of n-casting option. Such mechanisms of > > diversity work better at lower layers therefore when lower layers are > > already making use of diversity then redoing it at network layer does > > seems very attractive to me. > > However these are just opinions from my side and i invite other working > > group members to comment on it. > > => I have to agree with Stuart's comment here. Lower layers have nothing > to > do with this. This is an e2e feature. > > Hesham > > > Have a nice weekend, > > Kind Regards, > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 09:05:13 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5DBF28C1C3; Mon, 17 Nov 2008 09:05:13 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580493A6928 for ; Mon, 17 Nov 2008 09:05: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 usNAe27ZjkJx for ; Mon, 17 Nov 2008 09:05:11 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id 37B1A28C1C3 for ; Mon, 17 Nov 2008 09:05:11 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2493283rvf.49 for ; Mon, 17 Nov 2008 09:05:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=svxkYM5Hv01WEIsqwmi/vPLFbkVaq4O48wX9gI7s+og=; b=E3N7ZRm98+QQ45iWvKTMeukkEKW2qB49PBVtEFc5N/fUM4FMtlBYOUf4fIBDRGpICa cUyNovjk0cDX4SvJ/XsY65GgkAxGGC3jNPmfhWeJ9ZsjSkh04gma3e7p5t1LRKfILelR FoOrAaejcIoioIcG1Ui62HavjLRSFBXuIFuPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=L5R7DImJzJlcs7Z/qdQi5x5GqpLz6RCZ+smWd3DR4m4+kLqwKaiMjMwDiqcvY/JcGc aC3f3I+MILbeNzwv74pQE3IkeJ9XMygD7AlveIhUBluzIjBJg/U3fxrK3AkNdYqUv68B n3VO8k1sgH62lcEJIezMkHp5CEBxrMBVc3wHk= Received: by 10.141.114.15 with SMTP id r15mr2348186rvm.179.1226941510202; Mon, 17 Nov 2008 09:05:10 -0800 (PST) Received: from ?130.129.78.44? ([130.129.78.44]) by mx.google.com with ESMTPS id f21sm10155480rvb.5.2008.11.17.09.05.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 Nov 2008 09:05:09 -0800 (PST) Message-Id: From: Ryuji Wakikawa To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 17 Nov 2008 11:05:06 -0600 X-Mailer: Apple Mail (2.929.2) Subject: [MEXT] comments to draft-bernardos-mext-aero-nemo-ro-sol-analysis-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Carlos and Marcelo, Thanks for writing this document. It summarizes the list of right questions to aviation industry. Unfortunately, I don't have answers to any of them :-) Some comments In section 3.1, o if a craft attached to an ANSP access network is communicating with a CN attached to the same ANSP, is it required for the NEMO RO solution to survive when the link of the ANSP to its gACSP goes down? or put in a different way, would it be OK for such a communication to be broken? It should be noted that the default MRHA path used by the NEMO Basic Support protocol would likely fail in this scenario. Are you sure we need to consider the scenario of gACSP failure? gACSP failure seems very critical errors and MUST NOT be happened... In section 3.2, entities belong to the same administrative domain. However, this does not mean that this scenario is excluded from having trust issues, since a particular solution might require to inject routes in some parts of the network (e.g., RO entities owned by an airline and placed in networks not managed by the airline, anycast routing, etc.), and this could require additional trust relationships. This additional trust relationships are not always required to be dynamic one. It might be just business agreements, isn't it? I think we need more information from aviation industry such as - How many CNs does each MR communicates with? - How many ANSPs does each MR communicate with? - The least HOPs path is not always the shortest latency path. It depends on the topology (L1-L3) of gACSP and ANSPs. Since the aviation network is somehow closed network and designed by themselves, we need more detailed information of topology information. regards, ryuji _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 09:36:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 449C03A69CC; Mon, 17 Nov 2008 09:36:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68FEB28C1BC for ; Mon, 17 Nov 2008 09:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, 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 fqEQmJ7SogNl for ; Mon, 17 Nov 2008 09:36:13 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 906463A677D for ; Mon, 17 Nov 2008 09:35:38 -0800 (PST) Received: from [130.129.63.219] (unknown [130.129.63.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id BAA8F5CBBDC; Mon, 17 Nov 2008 18:35:35 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Ryuji Wakikawa In-Reply-To: References: Organization: Universidad Carlos III de Madrid Date: Mon, 17 Nov 2008 18:35:33 +0100 Message-Id: <1226943333.4512.75.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: mext@ietf.org Subject: Re: [MEXT] comments todraft-bernardos-mext-aero-nemo-ro-sol-analysis-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1341375509==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1341375509== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-LjHTPLf0mHntLzcXwWMY" --=-LjHTPLf0mHntLzcXwWMY Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Ryuji, El lun, 17-11-2008 a las 11:05 -0600, Ryuji Wakikawa escribi=F3: > Hi Carlos and Marcelo, >=20 > Thanks for writing this document. > It summarizes the list of right questions to aviation industry. > Unfortunately, I don't have answers to any of them :-) Thanks for reading the draft and for your comments. Some in line comments below... >=20 > Some comments >=20 > In section 3.1, > o if a craft attached to an ANSP access network is communicating > with a CN attached to the same ANSP, is it required for the NEMO > RO solution to survive when the link of the ANSP to its gACSP =20 > goes > down? or put in a different way, would it be OK for such a > communication to be broken? It should be noted that the default > MRHA path used by the NEMO Basic Support protocol would likely > fail in this scenario. >=20 > Are you sure we need to consider the scenario of gACSP failure? > gACSP failure seems very critical errors and MUST NOT be happened... The point is that we don't know if this should be considered or not, we just pointed out that this is a possible situation (we don't know if this is likely to happen). This is something that the aviation people should let us know... >=20 >=20 > In section 3.2, > entities belong to the same administrative domain. However, this > does not mean that this scenario is excluded from having trust > issues, since a particular solution might require to inject routes =20 > in > some parts of the network (e.g., RO entities owned by an airline and > placed in networks not managed by the airline, anycast routing, > etc.), and this could require additional trust relationships. >=20 > This additional trust relationships are not always required to be =20 > dynamic one. > It might be just business agreements, isn't it? They might be, yes, but they are required, right?. The point is that we don't know whether these trust relationships/business agreements can be assumed in the aviation scenario or not. >=20 > I think we need more information from aviation industry such as > - How many CNs does each MR communicates with? > - How many ANSPs does each MR communicate with? > - The least HOPs path is not always the shortest latency path. > It depends on the topology (L1-L3) of gACSP and ANSPs. > Since the aviation network is somehow closed network and designed =20 > by themselves, > we need more detailed information of topology information. >=20 I agree this information would be also useful for the solution design. Thanks, Carlos > regards, > ryuji >=20 >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2009: 2nd Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-LjHTPLf0mHntLzcXwWMY Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkkhq2UACgkQNdy6TdFwT2cdxwCfUgsL/j29MxRTq5PpFOCQeEAm JjsAoJGQ3XtzDCxhYtQ+Uxvm7dIWi+Pc =eMhO -----END PGP SIGNATURE----- --=-LjHTPLf0mHntLzcXwWMY-- --===============1341375509== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1341375509==-- From mext-bounces@ietf.org Mon Nov 17 09:39:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6710C3A69C0; Mon, 17 Nov 2008 09:39:46 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3943A69C0 for ; Mon, 17 Nov 2008 09:39:45 -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 IyzCiMuaTZ1H for ; Mon, 17 Nov 2008 09:39:44 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 1B49B3A699A for ; Mon, 17 Nov 2008 09:39:43 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2505539rvf.49 for ; Mon, 17 Nov 2008 09:39:43 -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=WsSi0qd6yJWKizHCceupsr1eKP45xjMGyTsT3WUxS9s=; b=joLA8El9i7qqvhz42yM2iLbeRPD5tjwtE/d9Q+T0iRhjeQTy0QWUCf9MdSsIEMxsCs hMaghGXv5O+xCvO0ZqywraruOJEcW/qHsr/FTQBuj7gU2AMQoeFqdZryhH/ajHua45vl g4y89olLKS0cYLll3/7IpEbGGlxezj6ugeU3o= 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=dgNvanPf2Edi7d8aGZDLkAhVkihAW4g7DBLC4jaxM1wpqiDNozVmeEbTNsr1W6Y6+T MvwkfR5uFDgQHKQH0a8bbfXfz2qSdkIjDxpBNhqh8pYk/hrHr8TeyY60JxIUIdJiaSTo n9gzTn+LJX0B5fi6PLs3J3B1Z6QWpt4N/hOq4= Received: by 10.140.166.21 with SMTP id o21mr2379825rve.20.1226943582968; Mon, 17 Nov 2008 09:39:42 -0800 (PST) Received: from ?130.129.78.44? ([130.129.78.44]) by mx.google.com with ESMTPS id b8sm10190487rvf.3.2008.11.17.09.39.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 Nov 2008 09:39:42 -0800 (PST) From: Ryuji Wakikawa To: Basavaraj Patil In-Reply-To: References: Message-Id: <92E747DC-8AE9-4A6F-92D6-9EBCFB051F8C@gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 17 Nov 2008 11:39:39 -0600 X-Mailer: Apple Mail (2.929.2) Cc: "mext@ietf.org" Subject: Re: [MEXT] FW: New Version Notification for draft-patil-mext-mip6issueswithipsec-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Raj, I went through the draft and have following comments. (3) A MIP6 home agent is one end of the IPsec SA in a many-to-one relationship. A MIP6 HA may support a very large of mobile nodes which could number in the hundreds of thousands to millions. The ability to terminate a large number of IPsec SAs (millions) requires signifiant hardware and platform capability. The cost issues of such an HA are detrimental and hence act as a barrier to deployment. I partially agree, but the protection of data traffic must be mandated in some scenarios. Therefore, I would say using IPsec for protecting signaling might be problematic, but not for data packets. (4) The implementation complexity of Mobile IPv6 is greatly increased because of the interaction with IPsec and IKEv2. A standalone MIP6 protocol is easier to implement and deploy (such as MIP4 [RFC3344]). The complexity of the protocol implementation is even more so in the case of [DSMIP6]. True, IPsec/IKE are painful part when implementing Mobile IPv6. There is another reason that is supporting the feature of returning home. We need a lot of special codes for returning home (including SAD/SPD parts). (9) The way that the IPsec code sits in the usual kernel, and the access mechanisms for the SA database, are not very convenient for use by straightforward implementations of Mobile IPv6. Unusual calling sequences and parameter passing seems to be required on many platforms. I repeated this several time, but we should have informational RFC something like http://tools.ietf.org/html/draft-sugimoto-mip6-pfkey-migrate-04 This is very useful document for implementators. I have another concern. Whenever MN moves, MN needs IKE signaling if the feature of K-bit is not supported. We have to consider the movement latency including IKE/MIP signaling exchange. We do not optimize the IKE part. As a result, MN may not do fast handover... thanks, ryuji On 2008/10/27, at 12:27, Basavaraj Patil wrote: > > FYI, > > ------ Forwarded Message > From: ext IETF I-D Submission Tool > Date: Mon, 27 Oct 2008 09:55:13 -0700 (PDT) > To: Basavaraj Patil > Cc: Charles Perkins , > > Subject: New Version Notification for > draft-patil-mext-mip6issueswithipsec-00 > > > A new version of I-D, draft-patil-mext-mip6issueswithipsec-00.txt > has been > successfuly submitted by Basavaraj Patil and posted to the IETF > repository. > > Filename: draft-patil-mext-mip6issueswithipsec > Revision: 00 > Title: Issues related to the design choice of IPsec for Mobile IPv6 > security > Creation_date: 2008-10-27 > WG ID: Independent Submission > Number_of_pages: 15 > > Abstract: > Mobile IPv6 as specified in RFC3775 relies on IPsec for security. An > IPsec SA between the mobile node and the home agent provides security > for the mobility signaling. Use of IPsec for securing the data > traffic between the mobile node and home agent is optional. This > document analyses the implications of the design decision to mandate > IPsec as the default security protocol for Mobile IPv6 and recommends > revisiting this decision in view of the experience gained from > implementation and adoption in other standards bodies. > > > > The IETF Secretariat. > > > > ------ End of Forwarded Message > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 09:40:13 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E656028C183; Mon, 17 Nov 2008 09:40:12 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A031028C183 for ; Mon, 17 Nov 2008 09:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 NRfku+RVUDmI for ; Mon, 17 Nov 2008 09:40:07 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 07A6C28C108 for ; Mon, 17 Nov 2008 09:40:07 -0800 (PST) Received: from localhost ([127.0.0.1]:60388 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L284v-0005ds-E2; Mon, 17 Nov 2008 18:40:01 +0100 MIME-Version: 1.0 From: "Mext Issue Tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: charliep@computer.org, julien.ietf@laposte.net X-Trac-Project: mext Date: Mon, 17 Nov 2008 17:40:01 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mext/trac/ticket/4#comment:2 Message-ID: <074.19568a753a6ec747303d45d71b661f4d@tools.ietf.org> References: <065.1f7010cc7fe6a13ec11344bf7562afde@tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <065.1f7010cc7fe6a13ec11344bf7562afde@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, julien.ietf@laposte.net, mext@ietf.org, marcelo@it.uc3m.es, tsirtsis@googlemail.com X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #4: Remove references to site-local addresses [George Tsirtsis ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org #4: Remove references to site-local addresses [George Tsirtsis ] ----------------------------------------+----------------------------------- Reporter: julien.ietf@laposte.net | Owner: charliep@computer.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: | Resolution: fixed Keywords: | ----------------------------------------+----------------------------------- Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 09:42:56 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C094D3A6914; Mon, 17 Nov 2008 09:42:56 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5BA83A699A for ; Mon, 17 Nov 2008 09:42:54 -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_21=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 3am0lV81YSEz for ; Mon, 17 Nov 2008 09:42:54 -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 09A153A677C for ; Mon, 17 Nov 2008 09:42:54 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2506719rvf.49 for ; Mon, 17 Nov 2008 09:42:53 -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=lQh4EC5FrPU30zhhMg+hHNUiwDDCNdTtKrWIMVhl2U0=; b=D5DggreNtN7YORluGVOy8aTRxGelnSPU9a4okC80JIo4+Nhx0jxK/qQJzmkMq2pR3e a2uLZnQux2yWAfYT9FjYk1ipL/i8DDw7tE+LrV8N07p4u+kZHu8Y0yvjJyewUkwv3758 ZvmBew1wsBR65d2n0RNNYaIfBsRBjxdOwnuyU= 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=oaNW4hDHfSImT5jRysPOb1cbh8XCnVRfgFm1j+HmBn/UiYA4L97+PaONxWzzuZDNzH q1n8J1OFL0TQraVd55vOzdq14Eiu6ZqPfpvtaWJZ1BwHk1BrIM9RLADkXqqwmolCb/cA pc24seRD0Bj0qPnnZxCAOurSIuzu5cIuZc+X0= Received: by 10.141.203.2 with SMTP id f2mr817979rvq.97.1226943773125; Mon, 17 Nov 2008 09:42:53 -0800 (PST) Received: from ?130.129.78.44? ([130.129.78.44]) by mx.google.com with ESMTPS id k2sm10289433rvb.1.2008.11.17.09.42.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 Nov 2008 09:42:52 -0800 (PST) From: Ryuji Wakikawa To: cjbc@it.uc3m.es In-Reply-To: <1226943333.4512.75.camel@localhost> References: <1226943333.4512.75.camel@localhost> Message-Id: <1AFB82CA-B7A4-4CD8-B551-932C4D6A5160@gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 17 Nov 2008 11:42:50 -0600 X-Mailer: Apple Mail (2.929.2) Cc: mext@ietf.org Subject: Re: [MEXT] comments todraft-bernardos-mext-aero-nemo-ro-sol-analysis-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org SGkgQ2FybG9zLAoKCk9uIDIwMDgvMTEvMTcsIGF0IDExOjM1LCBDYXJsb3MgSmVzw7pzIEJlcm5h cmRvcyBDYW5vIHdyb3RlOgoKPiBIaSBSeXVqaSwKPgo+IEVsIGx1biwgMTctMTEtMjAwOCBhIGxh cyAxMTowNSAtMDYwMCwgUnl1amkgV2FraWthd2EgZXNjcmliacOzOgo+PiBIaSBDYXJsb3MgYW5k IE1hcmNlbG8sCj4+Cj4+IFRoYW5rcyBmb3Igd3JpdGluZyB0aGlzIGRvY3VtZW50Lgo+PiBJdCBz dW1tYXJpemVzIHRoZSBsaXN0IG9mIHJpZ2h0IHF1ZXN0aW9ucyB0byBhdmlhdGlvbiBpbmR1c3Ry eS4KPj4gVW5mb3J0dW5hdGVseSwgSSBkb24ndCBoYXZlIGFuc3dlcnMgdG8gYW55IG9mIHRoZW0g Oi0pCj4KPiBUaGFua3MgZm9yIHJlYWRpbmcgdGhlIGRyYWZ0IGFuZCBmb3IgeW91ciBjb21tZW50 cy4KPgo+IFNvbWUgaW4gbGluZSBjb21tZW50cyBiZWxvdy4uLgo+Cj4+Cj4+IFNvbWUgY29tbWVu dHMKPj4KPj4gSW4gc2VjdGlvbiAzLjEsCj4+ICAgIG8gIGlmIGEgY3JhZnQgYXR0YWNoZWQgdG8g YW4gQU5TUCBhY2Nlc3MgbmV0d29yayBpcyBjb21tdW5pY2F0aW5nCj4+ICAgICAgIHdpdGggYSBD TiBhdHRhY2hlZCB0byB0aGUgc2FtZSBBTlNQLCBpcyBpdCByZXF1aXJlZCBmb3IgdGhlICAKPj4g TkVNTwo+PiAgICAgICBSTyBzb2x1dGlvbiB0byBzdXJ2aXZlIHdoZW4gdGhlIGxpbmsgb2YgdGhl IEFOU1AgdG8gaXRzIGdBQ1NQCj4+IGdvZXMKPj4gICAgICAgZG93bj8gb3IgcHV0IGluIGEgZGlm ZmVyZW50IHdheSwgd291bGQgaXQgYmUgT0sgZm9yIHN1Y2ggYQo+PiAgICAgICBjb21tdW5pY2F0 aW9uIHRvIGJlIGJyb2tlbj8gIEl0IHNob3VsZCBiZSBub3RlZCB0aGF0IHRoZSAgCj4+IGRlZmF1 bHQKPj4gICAgICAgTVJIQSBwYXRoIHVzZWQgYnkgdGhlIE5FTU8gQmFzaWMgU3VwcG9ydCBwcm90 b2NvbCB3b3VsZCBsaWtlbHkKPj4gICAgICAgZmFpbCBpbiB0aGlzIHNjZW5hcmlvLgo+Pgo+PiBB cmUgeW91IHN1cmUgd2UgbmVlZCB0byBjb25zaWRlciB0aGUgc2NlbmFyaW8gb2YgZ0FDU1AgZmFp bHVyZT8KPj4gZ0FDU1AgZmFpbHVyZSBzZWVtcyB2ZXJ5IGNyaXRpY2FsIGVycm9ycyBhbmQgTVVT VCBOT1QgYmUgaGFwcGVuZWQuLi4KPgo+IFRoZSBwb2ludCBpcyB0aGF0IHdlIGRvbid0IGtub3cg aWYgdGhpcyBzaG91bGQgYmUgY29uc2lkZXJlZCBvciBub3QsICAKPiB3ZQo+IGp1c3QgcG9pbnRl ZCBvdXQgdGhhdCB0aGlzIGlzIGEgcG9zc2libGUgc2l0dWF0aW9uICh3ZSBkb24ndCBrbm93IGlm Cj4gdGhpcyBpcyBsaWtlbHkgdG8gaGFwcGVuKS4gVGhpcyBpcyBzb21ldGhpbmcgdGhhdCB0aGUg YXZpYXRpb24gcGVvcGxlCj4gc2hvdWxkIGxldCB1cyBrbm93Li4uCgpSaWdodC4KSXMgZ0FTUCBm YWlsdXJlIGVxdWFsIHRvIHRoZSBCR1AgREZaIGZhaWx1cmUgb24gdGhlIEludGVybmV0LCBubz8K Cj4+Cj4+Cj4+IEluIHNlY3Rpb24gMy4yLAo+PiAgICBlbnRpdGllcyBiZWxvbmcgdG8gdGhlIHNh bWUgYWRtaW5pc3RyYXRpdmUgZG9tYWluLiAgSG93ZXZlciwgdGhpcwo+PiAgICBkb2VzIG5vdCBt ZWFuIHRoYXQgdGhpcyBzY2VuYXJpbyBpcyBleGNsdWRlZCBmcm9tIGhhdmluZyB0cnVzdAo+PiAg ICBpc3N1ZXMsIHNpbmNlIGEgcGFydGljdWxhciBzb2x1dGlvbiBtaWdodCByZXF1aXJlIHRvIGlu amVjdCByb3V0ZXMKPj4gaW4KPj4gICAgc29tZSBwYXJ0cyBvZiB0aGUgbmV0d29yayAoZS5nLiwg Uk8gZW50aXRpZXMgb3duZWQgYnkgYW4gYWlybGluZSAgCj4+IGFuZAo+PiAgICBwbGFjZWQgaW4g bmV0d29ya3Mgbm90IG1hbmFnZWQgYnkgdGhlIGFpcmxpbmUsIGFueWNhc3Qgcm91dGluZywKPj4g ICAgZXRjLiksIGFuZCB0aGlzIGNvdWxkIHJlcXVpcmUgYWRkaXRpb25hbCB0cnVzdCByZWxhdGlv bnNoaXBzLgo+Pgo+PiBUaGlzIGFkZGl0aW9uYWwgdHJ1c3QgcmVsYXRpb25zaGlwcyBhcmUgbm90 IGFsd2F5cyByZXF1aXJlZCB0byBiZQo+PiBkeW5hbWljIG9uZS4KPj4gSXQgbWlnaHQgYmUganVz dCBidXNpbmVzcyBhZ3JlZW1lbnRzLCBpc24ndCBpdD8KPgo+IFRoZXkgbWlnaHQgYmUsIHllcywg YnV0IHRoZXkgYXJlIHJlcXVpcmVkLCByaWdodD8uIFRoZSBwb2ludCBpcyB0aGF0ICAKPiB3ZQo+ IGRvbid0IGtub3cgd2hldGhlciB0aGVzZSB0cnVzdCByZWxhdGlvbnNoaXBzL2J1c2luZXNzIGFn cmVlbWVudHMgY2FuICAKPiBiZQo+IGFzc3VtZWQgaW4gdGhlIGF2aWF0aW9uIHNjZW5hcmlvIG9y IG5vdC4KCk15IHBvaW50IHdhcyB0aGF0CnRoaXMgdHJ1c3QgcmVsYXRpb25zaGlwIGlzc3VlIGlz IG5vdCBhbHdheXMgdGVjaG5pY2FsIG9uZSwgYnV0ICAKcG9saXRpY2FsIG9uZS4KCnRoYW5rcywK cnl1amkKCj4KPgo+Pgo+PiBJIHRoaW5rIHdlIG5lZWQgbW9yZSBpbmZvcm1hdGlvbiBmcm9tIGF2 aWF0aW9uIGluZHVzdHJ5IHN1Y2ggYXMKPj4gLSBIb3cgbWFueSBDTnMgZG9lcyBlYWNoIE1SIGNv bW11bmljYXRlcyB3aXRoPwo+PiAtIEhvdyBtYW55IEFOU1BzIGRvZXMgZWFjaCBNUiBjb21tdW5p Y2F0ZSB3aXRoPwo+PiAtIFRoZSBsZWFzdCBIT1BzIHBhdGggaXMgbm90IGFsd2F5cyB0aGUgc2hv cnRlc3QgbGF0ZW5jeSBwYXRoLgo+PiAgIEl0IGRlcGVuZHMgb24gdGhlIHRvcG9sb2d5IChMMS1M Mykgb2YgZ0FDU1AgYW5kIEFOU1BzLgo+PiAgIFNpbmNlIHRoZSBhdmlhdGlvbiBuZXR3b3JrIGlz IHNvbWVob3cgY2xvc2VkIG5ldHdvcmsgYW5kIGRlc2lnbmVkCj4+IGJ5IHRoZW1zZWx2ZXMsCj4+ ICAgd2UgbmVlZCBtb3JlIGRldGFpbGVkIGluZm9ybWF0aW9uIG9mIHRvcG9sb2d5IGluZm9ybWF0 aW9uLgo+Pgo+Cj4gCUkgYWdyZWUgdGhpcyBpbmZvcm1hdGlvbiB3b3VsZCBiZSBhbHNvIHVzZWZ1 bCBmb3IgdGhlIHNvbHV0aW9uICAKPiBkZXNpZ24uCj4KPiAJVGhhbmtzLAo+Cj4gCUNhcmxvcwo+ Cj4+IHJlZ2FyZHMsCj4+IHJ5dWppCj4+Cj4+Cj4+Cj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCj4+IE1FWFQgbWFpbGluZyBsaXN0Cj4+IE1FWFRAaWV0 Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZXh0Cj4gLS0g Cj4gQ2FybG9zIEplc8O6cyBCZXJuYXJkb3MgQ2FubyAgICAgaHR0cDovL3d3dy5uZXRjb21zLm5l dAo+IEdQRyBGUDogRDI5QiAwQTZBIDYzOUEgQTU2MSA5M0NBICA0RDU1IDM1REMgQkE0RCBEMTcw IDRGNjcKPiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysKPiAgV0VFREVWIDIwMDk6IDJuZCBXb3Jrc2hvcCBvbiBFeHBlcmltZW50YWwg RXZhbHVhdGlvbiBhbmQKPiAgICAgICAgRGVwbG95bWVudCBFeHBlcmllbmNlcyBvbiBWZWhpY3Vs YXIgbmV0d29ya3MKPiAgICAgICAgICAgICAgICAgIGh0dHA6Ly93d3cud2VlZGV2Lm9yZy8KPiAr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk1FWFQg bWFpbGluZyBsaXN0Ck1FWFRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tZXh0Cg== From mext-bounces@ietf.org Mon Nov 17 09:59:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41AE83A6831; Mon, 17 Nov 2008 09:59:46 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9FF13A6831 for ; Mon, 17 Nov 2008 09:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 6N430M0Ev6LO for ; Mon, 17 Nov 2008 09:59:44 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id E666A3A67AF for ; Mon, 17 Nov 2008 09:59:43 -0800 (PST) Received: from localhost ([127.0.0.1]:38023 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L28Nw-00015R-GT; Mon, 17 Nov 2008 18:59:40 +0100 MIME-Version: 1.0 From: "Mext Issue Tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: charliep@computer.org, julien.ietf@laposte.net X-Trac-Project: mext Date: Mon, 17 Nov 2008 17:59:40 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mext/trac/ticket/1#comment:4 Message-ID: <074.9aed9538d8e898bd2ed9653f1d0c4b65@tools.ietf.org> References: <065.2ae99a08058bb69e889aa8f753aa0831@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <065.2ae99a08058bb69e889aa8f753aa0831@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, julien.ietf@laposte.net, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #1: Last Accepted SQN [Ahmad Muhanna ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org #1: Last Accepted SQN [Ahmad Muhanna ] ----------------------------------------+----------------------------------- Reporter: julien.ietf@laposte.net | Owner: charliep@computer.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: | Resolution: Keywords: | ----------------------------------------+----------------------------------- Comment(by charliep@computer.org): I have made the revisions to resolve and close Issue #1. The intention in RFC 3775 was pretty clearly to allow the mobile node to update its record for the sequence number. An authenticated Binding Acknowledgement is clearly useful for this purpose. The discussion up until now was sticking on the need for a new protocol element, which Ahmad specified as an extension. Since I'm in the process of collecting mailing-list inputs and trying to make recommendations according to the discussion so far, I thought I'd like to at least suggest a text revision for rfc3775bis that (a) allows the original intention of RFC 3775 but (b) does not require a new protocol element. ======================================================================== OLD TEXT: o The Sequence Number field matches the Sequence Number sent by the mobile node to this destination address in an outstanding Binding Update. ======================================================================== NEW TEXT: o The Sequence Number field matches the Sequence Number sent by the mobile node to this destination address in an outstanding Binding Update, and the Status field is not 135. ... and, just before the bulleted text for Status field #1 (currently on pg. 139): o Additionally, if the Binding Acknowledgement correctly passes authentication and the Status field value is 135 (Sequence Number out of window), then the mobile node MUST update its binding sequence number appropriately to match the sequence number given in the Binding Acknowledgement. Otherwise, if the Status field value is 135 but the Binding Acknowledgement does not pass authentication, the message MUST be silently ignored. ======================================================================== -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 10:00:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1741F3A69DC; Mon, 17 Nov 2008 10:00:18 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56CC43A6A03 for ; Mon, 17 Nov 2008 10:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 WbSAAtm5yJZf for ; Mon, 17 Nov 2008 10:00:16 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 6A7203A6A09 for ; Mon, 17 Nov 2008 10:00:16 -0800 (PST) Received: from localhost ([127.0.0.1]:38038 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L28OS-0001BM-QO; Mon, 17 Nov 2008 19:00:12 +0100 MIME-Version: 1.0 From: "Mext Issue Tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: charliep@computer.org, julien.ietf@laposte.net X-Trac-Project: mext Date: Mon, 17 Nov 2008 18:00:12 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mext/trac/ticket/1#comment:5 Message-ID: <074.7e341a6cc2ce5fdab2b5f21554bc8fc6@tools.ietf.org> References: <065.2ae99a08058bb69e889aa8f753aa0831@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <065.2ae99a08058bb69e889aa8f753aa0831@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, julien.ietf@laposte.net, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #1: Last Accepted SQN [Ahmad Muhanna ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org #1: Last Accepted SQN [Ahmad Muhanna ] ----------------------------------------+----------------------------------- Reporter: julien.ietf@laposte.net | Owner: charliep@computer.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: | Resolution: fixed Keywords: | ----------------------------------------+----------------------------------- Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 10:10:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 662FC3A699A; Mon, 17 Nov 2008 10:10:12 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA1233A699A for ; Mon, 17 Nov 2008 10:10:10 -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 yRoEiEqJwRHp for ; Mon, 17 Nov 2008 10:10:10 -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 1D4CA3A692D for ; Mon, 17 Nov 2008 10:10:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ihEKhXI3wNZAu+7st8i0A+gzHOnDA4rHbmvOJ6Mt5Imvpk6/MzmIRnR7WUMQAPW7; 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 [130.129.78.128] by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L28Y5-0006A1-I0 for mext@ietf.org; Mon, 17 Nov 2008 13:10:09 -0500 Message-ID: <4921B381.7020209@earthlink.net> Date: Mon, 17 Nov 2008 10:10:09 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: mext X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f525f1717a6026d76eacae34d225a118ff6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.78.128 Subject: [MEXT] Resolving Issue#8 (Application using the care-of address) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, Issue #8 has been resolved for a while now, and the revised text is included in the current revision of rfc3344bis. Strangely, I seem to have neglected to post the notification to the list for this issue. The issue involved a straightforward update to the document to cite RFC 5014. The discussion is at the following URL: http://trac.tools.ietf.org/wg/mext/trac/ticket/8 I am going ahead to close the issue now. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 10:10:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02E883A6906; Mon, 17 Nov 2008 10:10:50 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646C83A6948 for ; Mon, 17 Nov 2008 10:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 lS1ERvQragSv for ; Mon, 17 Nov 2008 10:10:46 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id C17AF3A6906 for ; Mon, 17 Nov 2008 10:10:40 -0800 (PST) Received: from localhost ([127.0.0.1]:40195 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L28YW-00019E-LB; Mon, 17 Nov 2008 19:10:36 +0100 MIME-Version: 1.0 From: "Mext Issue Tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: charliep@computer.org, julien.ietf@laposte.net X-Trac-Project: mext Date: Mon, 17 Nov 2008 18:10:36 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mext/trac/ticket/8#comment:3 Message-ID: <072.418ee9d9831453fd23948220ea8e891e@tools.ietf.org> References: <063.7622031672aced0787b70d358cb06abb@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <063.7622031672aced0787b70d358cb06abb@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, julien.ietf@laposte.net, julien.IETF@laposte.net, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: julien.IETF@laposte.net, mext@ietf.org Subject: [MEXT] "Re: [mext] #8: Application using the care-of address " X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org #8: Application using the care-of address ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: enhancement | Status: closed Priority: minor | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ----------------------------------------+----------------------------------- Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 10:27:27 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2293A6861; Mon, 17 Nov 2008 10:27:27 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D73D53A6861 for ; Mon, 17 Nov 2008 10:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 bwklFOzQYl-2 for ; Mon, 17 Nov 2008 10:27:26 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 03F6A3A6835 for ; Mon, 17 Nov 2008 10:27:26 -0800 (PST) Received: from localhost ([127.0.0.1]:48883 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L28ol-0001zJ-2V; Mon, 17 Nov 2008 19:27:23 +0100 MIME-Version: 1.0 From: "Mext Issue Tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Mon, 17 Nov 2008 18:27:22 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mext/trac/ticket/11#comment:1 Message-ID: <072.2a006cea944e0a760b8aec7309e3b549@tools.ietf.org> References: <063.5678bdd45e5096c3dfbccfcf1ef43af5@tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <063.5678bdd45e5096c3dfbccfcf1ef43af5@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #11: De-registration when returning home [Vijay Devarapalli ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org #11: De-registration when returning home [Vijay Devarapalli ] ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: Active WG Document | Resolution: Keywords: | ----------------------------------------+----------------------------------- Comment(by charliep@computer.org): The following text has been proposed to resolve Issue #8, and no objections have been raised: ======================================================================== A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. 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. ======================================================================== It is proposed to include this text in the next revision and close the issue. -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 10:35:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95143A6835; Mon, 17 Nov 2008 10:35:39 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EB9B3A67A6 for ; Mon, 17 Nov 2008 10:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 iso-zTzepVuz for ; Mon, 17 Nov 2008 10:35:37 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 4C5073A6835 for ; Mon, 17 Nov 2008 10:35:37 -0800 (PST) Received: from localhost ([127.0.0.1]:44789 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L28wf-0002xF-Nk; Mon, 17 Nov 2008 19:35:33 +0100 MIME-Version: 1.0 From: "Mext Issue Tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Mon, 17 Nov 2008 18:35:33 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mext/trac/ticket/12#comment:1 Message-ID: <072.a2e4d052b32ec8ff64aa0142f8184383@tools.ietf.org> References: <063.d3e980d28cd819f0dd4dda19a3d0a981@tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <063.d3e980d28cd819f0dd4dda19a3d0a981@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #12: BErr sent by HA too, not only by CN [Alexandru Petrescu ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org #12: BErr sent by HA too, not only by CN [Alexandru Petrescu ] ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: Active WG Document | Resolution: fixed Keywords: Binding Error | ----------------------------------------+----------------------------------- Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 10:41:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA2A3A6813; Mon, 17 Nov 2008 10:41:26 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 287A73A6813 for ; Mon, 17 Nov 2008 10:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 h7j0lo0TAMWl for ; Mon, 17 Nov 2008 10:41:24 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 3E7583A6A48 for ; Mon, 17 Nov 2008 10:41:18 -0800 (PST) Received: from localhost ([127.0.0.1]:51573 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L292A-000391-Ai; Mon, 17 Nov 2008 19:41:14 +0100 MIME-Version: 1.0 From: "Mext Issue Tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Mon, 17 Nov 2008 18:41:14 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mext/trac/ticket/13#comment:1 Message-ID: <072.280593bed76e5af2f27ff92f4c5c7d3a@tools.ietf.org> References: <063.44d72bbd38b42b8497376e892521c1fd@tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <063.44d72bbd38b42b8497376e892521c1fd@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, suresh.krishnan@ericsson.com, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #13: Home Link Detection [Suresh Krishnan ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org #13: Home Link Detection [Suresh Krishnan ] ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: Active WG Document | Resolution: fixed Keywords: Home Link Detection | ----------------------------------------+----------------------------------- Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 10:49:56 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2908128C0FD; Mon, 17 Nov 2008 10:49:56 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7114D28C0DB for ; Mon, 17 Nov 2008 10:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 7AlJOqKWVZ9L for ; Mon, 17 Nov 2008 10:49:51 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 99E2428C0D7 for ; Mon, 17 Nov 2008 10:49:51 -0800 (PST) Received: from localhost ([127.0.0.1]:53028 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L29AP-0003RF-Mj; Mon, 17 Nov 2008 19:49:45 +0100 MIME-Version: 1.0 From: "Mext Issue Tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Mon, 17 Nov 2008 18:49:45 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mext/trac/ticket/14#comment:2 Message-ID: <072.2c303f1bde572d61628765f9f402435f@tools.ietf.org> References: <063.855a73e684e87d802316d9c50d015af5@tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <063.855a73e684e87d802316d9c50d015af5@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, vijay@wichorus.com, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #14: References to Bootstrapping [Vijay Devarapalli ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org #14: References to Bootstrapping [Vijay Devarapalli ] ----------------------------------------+----------------------------------- Reporter: charliep@computer.org | Owner: charliep@computer.org Type: enhancement | Status: closed Priority: minor | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: 2.0 Severity: Active WG Document | Resolution: fixed Keywords: bootstrapping | ----------------------------------------+----------------------------------- Changes (by charliep@computer.org): * status: new => closed * resolution: => fixed -- Ticket URL: mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 11:42:02 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E18293A698B; Mon, 17 Nov 2008 11:42:01 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5017E3A698B for ; Mon, 17 Nov 2008 11:42:00 -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 Px175ClX-g36 for ; Mon, 17 Nov 2008 11:41:59 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 2DB613A6939 for ; Mon, 17 Nov 2008 11:41:59 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1L29yt-00027c-2U; Mon, 17 Nov 2008 20:41:56 +0100 From: arno@natisbad.org (Arnaud Ebalard) To: Ryuji Wakikawa References: <92E747DC-8AE9-4A6F-92D6-9EBCFB051F8C@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:081117:ryuji.wakikawa@gmail.com::fOLMovSHO7lAWxKM:000000000000000000000000000000000000039qd X-Hashcash: 1:20:081117:basavaraj.patil@nokia.com::621tO76/b1xVCuHD:00000000000000000000000000000000000071sq X-Hashcash: 1:20:081117:mext@ietf.org::SEZlCkmv3N+5fH6j:0000MxGQ Date: Mon, 17 Nov 2008 11:39:38 -0800 In-Reply-To: <92E747DC-8AE9-4A6F-92D6-9EBCFB051F8C@gmail.com> (Ryuji Wakikawa's message of "Mon, 17 Nov 2008 11:39:39 -0600") Message-ID: <87iqqmp2f9.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: "mext@ietf.org" , Basavaraj Patil Subject: Re: [MEXT] FW: New Version Notification for draft-patil-mext-mip6issueswithipsec-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Ryuji Wakikawa writes: > True, IPsec/IKE are painful part when implementing Mobile IPv6. > There is another reason that is supporting the feature of returning > home. > We need a lot of special codes for returning home (including SAD/SPD > parts). > > (9) The way that the IPsec code sits in the usual kernel, and the > access mechanisms for the SA database, are not very convenient > for use by straightforward implementations of Mobile IPv6. > Unusual calling sequences and parameter passing seems to be > required on many platforms. > > I repeated this several time, but we should have informational RFC > something like > http://tools.ietf.org/html/draft-sugimoto-mip6-pfkey-migrate-04 > This is very useful document for implementators. Linux 2.6.28 will be fully compliant with a followup document I wrote (SADB_X_EXT_PACKET part removed and replaced by KMADDRESS extension, a more simple and efficient mechanism). Those changes have been merged mainline: http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00 I am currently handling integration of associated patches in racoon (for MIGRATE/KMADDRESS support). I also have interactions w/ people from strongSwan project which are currently implementing what is specified in my draft for Charon, the IKEv2 daemon. Patches for UMIP (will see that w/ Sugimoto-san) are also available. Information is available on http://natisbad.org/MIPv6/ Comments appreciated if you have some time to review those pages and the draft. > I have another concern. > Whenever MN moves, MN needs IKE signaling if the feature of K-bit is > not supported. > We have to consider the movement latency including IKE/MIP signaling > exchange. > We do not optimize the IKE part. As a result, MN may not do fast > handover... When using IKE, an *unmodified* IKE daemon is not able to negotiate the initial transport mode SA so K-bit does not make sense in the end. You need to have a MIPv6-modified IKE implementation to bootstrap. Please, take a look at previous draft. I have already raised the issue (Sebastien Decugis has even written a draft on the topic.) Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 11:49:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64E33A6A2A; Mon, 17 Nov 2008 11:49:48 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1768E3A6A2A for ; Mon, 17 Nov 2008 11:49:47 -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 iyMhWeGo-gEi for ; Mon, 17 Nov 2008 11:49:46 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id 5C4893A6939 for ; Mon, 17 Nov 2008 11:49:46 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2550198rvf.49 for ; Mon, 17 Nov 2008 11:49:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:user-agent :mime-version:to:subject:content-type:content-transfer-encoding:from; bh=v4Kv4VZtGdkKAxjIHVxcJOpI3DaBNUAb0CYm4wG1WS8=; b=m1FPD6ar8ggbO5qPMFryfZEhdHvx++II1zSiwBfBxo5zITa4IYHoE5+PkhChQACazA S8Fv2LmUkDMdw5BR19FIagkHl+4t8sgNmWphgnFp3e/tftuf87eVLPaFLCLnf9ZnNxWo QrCg6q7OkxY5XYPnw6SU4culKeliG8L6iLueo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:user-agent:mime-version:to:subject:content-type :content-transfer-encoding:from; b=usRs91Dk/jp4qMSW0yGwTuLYqtTRlazOSuS9g/uQZT6adXnPrltIsxptgl5ofaBUr4 bjphBpymlt0mbvzVFN+cWC2Kg1+e4vOyOFgk73wqIHrVpmKVJLF8q0MIrA5MsiLn9hWt 6AMQWmKUMQLUxT2OWiHF6bypEpmu4e2KzlonQ= Received: by 10.141.128.9 with SMTP id f9mr2442759rvn.159.1226951385829; Mon, 17 Nov 2008 11:49:45 -0800 (PST) Received: from ?130.129.29.123? ([130.129.29.123]) by mx.google.com with ESMTPS id b8sm10494678rvf.3.2008.11.17.11.49.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 Nov 2008 11:49:45 -0800 (PST) Message-ID: <4921CAE3.8020104@googlemail.com> Date: Mon, 17 Nov 2008 20:49:55 +0100 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: mext@ietf.org, marcelo bagnulo braun From: Julien Laganier Subject: [MEXT] Note takers and scribes X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, We'd be very happy if we could find volunteer note takers and scribes prior to today's session at 17:40 so that we can start the meeting on time rather than spend ten minutes in search of those. Appreciate your support. --julien & marcelo, MEXT chairs _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 12:16:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D99D928C0DB; Mon, 17 Nov 2008 12:16:51 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A06D73A6A62 for ; Mon, 17 Nov 2008 12:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 BHg42iOGjKyb for ; Mon, 17 Nov 2008 12:16:49 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 1067628C129 for ; Mon, 17 Nov 2008 12:16:29 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2559399rvf.49 for ; Mon, 17 Nov 2008 12:16:28 -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=tk9W7HW/w3cIU7coWhlPOwRwKHFTilYyGUkTWN2N+oI=; b=r/KRKR45AS/upC0bpMavK3VUQK0zvm8Yj67/RfTt4kQligiwWf4wQ5uXu7sNg3noUY GhQi+pzD5cwzYg9+kZaXOaOuSdhzQhaJ38OdWNEM/WqDzek2jtY7qCTbJyjbuy90HB9i yxZuJLYb3pIoFRr/IvouORWG9saTiY6UM6Hy8= 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=nbWhuO3m1Mjr2b8g1UCrYVYvEAGYKaoAsmdllXYNLVRBMPxdKdl0PBWg3nAcfkMpAT nynt444a8AEG73p6aW162ravGKxZk20a/auezktG0P3nXvVrIO9ZMtwZyzEvVvUYCdhE 0KkEZVeSLnN7ifstHxkVDy8w7gwd5zQdtLJDE= Received: by 10.141.168.2 with SMTP id v2mr2452392rvo.207.1226952987810; Mon, 17 Nov 2008 12:16:27 -0800 (PST) Received: from ?130.129.94.239? ([130.129.94.239]) by mx.google.com with ESMTPS id l31sm10603445rvb.2.2008.11.17.12.16.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 Nov 2008 12:16:27 -0800 (PST) From: Ryuji Wakikawa To: arno@natisbad.org (Arnaud Ebalard) In-Reply-To: <87iqqmp2f9.fsf@natisbad.org> References: <92E747DC-8AE9-4A6F-92D6-9EBCFB051F8C@gmail.com> <87iqqmp2f9.fsf@natisbad.org> Message-Id: <3D0C64B1-565B-4EDF-A7D6-BF7B5F183009@gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 17 Nov 2008 14:16:25 -0600 X-Mailer: Apple Mail (2.929.2) Cc: "mext@ietf.org" , Basavaraj Patil Subject: Re: [MEXT] FW: New Version Notification for draft-patil-mext-mip6issueswithipsec-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi On 2008/11/17, at 13:39, Arnaud Ebalard wrote: > Hi, > > Ryuji Wakikawa writes: > >> True, IPsec/IKE are painful part when implementing Mobile IPv6. >> There is another reason that is supporting the feature of returning >> home. >> We need a lot of special codes for returning home (including SAD/SPD >> parts). >> >> (9) The way that the IPsec code sits in the usual kernel, and the >> access mechanisms for the SA database, are not very convenient >> for use by straightforward implementations of Mobile IPv6. >> Unusual calling sequences and parameter passing seems to be >> required on many platforms. >> >> I repeated this several time, but we should have informational RFC >> something like >> http://tools.ietf.org/html/draft-sugimoto-mip6-pfkey-migrate-04 >> This is very useful document for implementators. > > Linux 2.6.28 will be fully compliant with a followup document I wrote > (SADB_X_EXT_PACKET part removed and replaced by KMADDRESS extension, a > more simple and efficient mechanism). Those changes have been merged > mainline: > > http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced- > migrate-00 > > I am currently handling integration of associated patches in racoon > (for MIGRATE/KMADDRESS support). I also have interactions w/ people > from > strongSwan project which are currently implementing what is > specified in > my draft for Charon, the IKEv2 daemon. > > Patches for UMIP (will see that w/ Sugimoto-san) are also > available. Information is available on http://natisbad.org/MIPv6/ > > Comments appreciated if you have some time to review those pages and > the > draft. good to know there are progresses on the spec and impl. Shinta sent us a patch of PF_KEY modification for SHISA (BSD-MIP implementation) a long time ago. I don't remember if we merge the patch or not.. Keiichi may answer this. >> I have another concern. >> Whenever MN moves, MN needs IKE signaling if the feature of K-bit is >> not supported. >> We have to consider the movement latency including IKE/MIP signaling >> exchange. >> We do not optimize the IKE part. As a result, MN may not do fast >> handover... > > When using IKE, an *unmodified* IKE daemon is not able to negotiate > the > initial transport mode SA so K-bit does not make sense in the end. You > need to have a MIPv6-modified IKE implementation to bootstrap. Please, > take a look at previous draft. I have already raised the issue > (Sebastien Decugis has even written a draft on the topic.) I personally don't care if IKE is modified or not for MIP. My personal comment is that "it's better to mandate K-bit always set to 1." regards, ryuji regards, ryuji > > > Cheers, > > a+ > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 12:46:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5423A6A3F; Mon, 17 Nov 2008 12:46:18 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28323A6A1F for ; Mon, 17 Nov 2008 12:46:17 -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 A2f4OdMCPmd0 for ; Mon, 17 Nov 2008 12:46:16 -0800 (PST) Received: from mail.critical.com (mail.critical.com [64.246.137.41]) by core3.amsl.com (Postfix) with ESMTP id 5CADA3A6876 for ; Mon, 17 Nov 2008 12:46:16 -0800 (PST) Received: by mail.critical.com (Postfix, from userid 99) id E90463BC0E8; Mon, 17 Nov 2008 15:46:19 -0500 (EST) Received: from [64.246.137.89] (ip-89.critical.com [64.246.137.89]) by mail.critical.com (Postfix) with ESMTP id 896323BC0E6; Mon, 17 Nov 2008 15:46:02 -0500 (EST) Message-ID: <4921D7F6.1040809@critical.com> Date: Mon, 17 Nov 2008 15:45:42 -0500 From: "Stuart W. Card" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Asanga Udugama References: <491D90E0.7090401@comnets.uni-bremen.de> In-Reply-To: Cc: mext@ietf.org Subject: Re: [MEXT] draft-ietf-mext-flow-binding-00.txt - comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Asanga Udugama wrote: > ... > 1) Splitting flows - Meaning that the packets of a single flow are placed on > different attachments. I know that TCP would perform adversely but some UDP > based applications may perform better. Further, the draft that I implemented > also allowed the specification of the packet distribution ration, which I > found very interesting as then, the ratio can be optimally decided to cater > to the different characteristics of the network attachments... There are interoperable, standards-compliant, extended TCP variants that can handle this just fine. We use the Space Communications Protocol Standards - Transport Protocol (SCPS-TP). Because it uses Selective Negative Acknowledgments (SNACKs), it can handle out-of-order delivery. Admittedly, we had to suggest a SNACK timer extension to the CCSDS (which they standardized). We have successfully load-balanced a single TCP flow over 2 paths with an 8:1 bandwidth ratio. We could probably handle higher ratios but haven't felt it worthwhile (little additional performance). We have also successfully balanced over 3 or more (can't remember how many) concurrent paths. This has not only been extensively tested in our and independent 3rd party labs -- it is also in mission-critical field use by a U.S. military service for whom we integrated it. It would be prudent to have control over which flows get what kind of load balancing: some application and transport protocols can handle (and benefit from) packet-by-packet; most can handle (and benefit from) flow-by-flow; others neither (these last are rare). This control isn't really a MEXT issue: it can be handled with DiffServ, for instance. A Hybrid Type II ARQ/FEC transport protocol should perform even better -- stay tuned! :-) -- Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 www.critical.com _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 12:52:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9D9E3A6A55; Mon, 17 Nov 2008 12:52:15 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D708E3A6A55 for ; Mon, 17 Nov 2008 12:52:14 -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 OO6HvsYFdYq4 for ; Mon, 17 Nov 2008 12:52:14 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 02AD43A6876 for ; Mon, 17 Nov 2008 12:52:14 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1L2B4s-0003If-6M; Mon, 17 Nov 2008 21:52:10 +0100 From: arno@natisbad.org (Arnaud Ebalard) To: Ryuji Wakikawa References: <92E747DC-8AE9-4A6F-92D6-9EBCFB051F8C@gmail.com> <87iqqmp2f9.fsf@natisbad.org> <3D0C64B1-565B-4EDF-A7D6-BF7B5F183009@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:081117:mext@ietf.org::ScADqTgUEu2It4LF:000008Hq X-Hashcash: 1:20:081117:basavaraj.patil@nokia.com::U+RtXORnuYnN/dAI:0000000000000000000000000000000000002wyA X-Hashcash: 1:20:081117:ryuji.wakikawa@gmail.com::P4ltAonuwqP67OvV:00000000000000000000000000000000000005Zd+ Date: Mon, 17 Nov 2008 12:50:27 -0800 In-Reply-To: <3D0C64B1-565B-4EDF-A7D6-BF7B5F183009@gmail.com> (Ryuji Wakikawa's message of "Mon, 17 Nov 2008 14:16:25 -0600") Message-ID: <871vxakrfw.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: "mext@ietf.org" , Basavaraj Patil Subject: Re: [MEXT] FW: New Version Notification for draft-patil-mext-mip6issueswithipsec-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ryuji Wakikawa writes: > good to know there are progresses on the spec and impl. > > Shinta sent us a patch of PF_KEY modification for SHISA (BSD-MIP > implementation) a long time ago. > I don't remember if we merge the patch or not.. Keiichi may answer this. ack. > I personally don't care if IKE is modified or not for MIP. It just needs to. And this is required to have things working. > My personal comment is that "it's better to mandate K-bit always set > to 1." a big +1 a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 12:57:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1E4E3A68C5; Mon, 17 Nov 2008 12:57:28 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062B83A6A4C for ; Mon, 17 Nov 2008 12:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[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 mczvFR7Lv5vb for ; Mon, 17 Nov 2008 12:57:26 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id B65943A6876 for ; Mon, 17 Nov 2008 12:57:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=whaddad@qualcomm.com; q=dns/txt; s=qcdkim; t=1226955446; x=1258491446; h=from:to:cc:date:subject:thread-topic:thread-index: message-id: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"Haddad,=20Wassim=20Michel"=20|To:=20Arnaud=20Ebalard=20,=20IETF =20MEXT=20WG=20ML=20|CC:=20Mobopts=20IRTF =20WG=20ML=20,=0D=0A=20=20=20=20=20=20 =20=20"Haddad,=20Wassim=20Michel"=0D=0A=09|Date:=20Mon,=2017=20Nov=202008=2012:57:23=20-0800 |Subject:=20Re:=20[Mobopts]=20MIPv6=20IPsec=20Route=20Opt imization=20(IRO)|Thread-Topic:=20[Mobopts]=20MIPv6=20IPs ec=20Route=20Optimization=20(IRO)|Thread-Index:=20AclIjx3 hkebhNUm7Qh6vLV5ld4PmOwAZ/i2x|Message-ID:=20|In-Reply-To:=20<87d4guwy7y.fsf@na tisbad.org>|Accept-Language:=20en-US|Content-Language:=20 en|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_C54744E36A58whaddadqualcommcom_" |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5436"=3B=20a=3D"13206048"; bh=xt+AoEUMr2bXaDVnTlDyZNuE+/l837GhX72IOLuQ8KE=; b=DPWTTPsJo8iZkwA8Pzmv/Rm94KX65gaDWPL88qRQBMjkdCYulPx+1QCM lT2hKIJ1bcC6RJ+uN9ce4j4eoyRVVl9nAA8Iv5wm+OPITc98qmdLm944v hNNUR92sk1cpl/Djh1ypURkpH5KxytOXc9zCkUGxp1uQULDD9B1HBDhIk M=; X-IronPort-AV: E=McAfee;i="5100,188,5436"; a="13206048" 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; 17 Nov 2008 12:57:26 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAHKvPBY028493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 17 Nov 2008 12:57:26 -0800 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAHKvPfs011627 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 17 Nov 2008 12:57:25 -0800 Received: from NASANEXMB01.na.qualcomm.com ([129.46.50.85]) by nasanexhub04.na.qualcomm.com ([129.46.134.222]) with mapi; Mon, 17 Nov 2008 12:57:24 -0800 From: "Haddad, Wassim Michel" To: Arnaud Ebalard , IETF MEXT WG ML Date: Mon, 17 Nov 2008 12:57:23 -0800 Thread-Topic: [Mobopts] MIPv6 IPsec Route Optimization (IRO) Thread-Index: AclIjx3hkebhNUm7Qh6vLV5ld4PmOwAZ/i2x Message-ID: In-Reply-To: <87d4guwy7y.fsf@natisbad.org> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Mobopts IRTF WG ML Subject: Re: [MEXT] [Mobopts] MIPv6 IPsec Route Optimization (IRO) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1426650434==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1426650434== Content-Language: en Content-Type: multipart/alternative; boundary="_000_C54744E36A58whaddadqualcommcom_" --_000_C54744E36A58whaddadqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 11/17/08 3:30 AM, "Arnaud Ebalard" wrote: Hi, Sorry for crossposting but the topic discussed in the draft may be of interest for people of the 3 lists. > IETF I-D Submission Tool writes: > > A new version of I-D, draft-ebalard-mext-ipsec-ro-00.txt has been > successfuly submitted by Arnaud Ebalard and posted to the IETF > repository. > > Filename: draft-ebalard-mext-ipsec-ro > Revision: 00 > Title: Mobile IPv6 IPsec Route Optimization (IRO) > Creation_date: 2008-11-17 > WG ID: Independent Submission > Number_of_pages: 44 > > Abstract: > > This memo specifies an improved alternate route optimization procedure > for Mobile IPv6 designed specifically for environments where IPsec is > used between peers (most probably with IKE). The replacement of the > complex Return Routability procedure for a simple mechanism and the > removal of HAO and RH2 extensions from exchanged packets result in > performance and security improvements. I have just submitted a new I-D [1] which certainly requires an introduction (and disclaimer): it specifies a MIPv6 Route Optimization procedure *dedicated* to environments where IPsec/IKE is used between peers (MN-HA, MN-CN, MN-MN) for protecting both signaling and data traffic. Some of the improvements provided by this "IPsec Route Optimization" mechanism (IRO) are also proposed for the IPsec communications between the MN and its HA. Among the features provided by IRO (introduction of the document as a more accurate list): * Complete removal of RH2 and HAO (resulting in simplified packet handling on both sides and possibly better compatibility with filtering implemented in the network), =3D> You can have complete removal of both options without introducing a ne= w RO mode. Please check http://www.ietf.org/internet-drafts/draft-haddad-mipshop-tunne= ling-optimization-01.txt Regards, Wassim H. --_000_C54744E36A58whaddadqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Mobopts] MIPv6 IPsec Route Optimization (IRO) On 11/17/08 3:30 AM, "Arnaud Ebalard" <arno@natisbad.org> wrote:

Hi,

Sorry for crossposting but the topic discussed in the draft may be of
interest for people of the 3 lists.

> IETF I-D Submission Tool <idsubmi= ssion@ietf.org> writes:
>
> A new version of I-D, draft-ebalard-mext-ipsec-ro-00.txt has been
> successfuly submitted by Arnaud Ebalard and posted to the IETF
> repository.
>
> Filename:      draft-ebalard-mext-ipsec-ro > Revision:      00
> Title:         Mobile IPv6 IPs= ec Route Optimization (IRO)
> Creation_date: 2008-11-17
> WG ID:         Independent Sub= mission
> Number_of_pages: 44
>
> Abstract:
>
> This memo specifies an improved alternate route optimization procedure=
> for Mobile IPv6 designed specifically for environments where IPsec is<= BR> > used between peers (most probably with IKE). The replacement of the > complex Return Routability procedure for a simple mechanism and the > removal of HAO and RH2 extensions from exchanged packets result in
> performance and security improvements.

I have just submitted a new I-D [1] which certainly requires an
introduction (and disclaimer): it specifies a MIPv6 Route Optimization
procedure *dedicated* to environments where IPsec/IKE is used between
peers (MN-HA, MN-CN, MN-MN) for protecting both signaling and data
traffic.

Some of the improvements provided by this "IPsec Route Optimization&qu= ot;
mechanism (IRO) are also proposed for the IPsec communications between
the MN and its HA.

Among the features provided by IRO (introduction of the document as
a more accurate list):

  * Complete removal of RH2 and HAO (resulting in simplified pack= et
    handling on both sides and possibly better compatib= ility with
    filtering implemented in the network),

=3D> You can have complete removal of both options without introducing a= new RO mode.
Please check http://www.ietf.org/internet-drafts/dr= aft-haddad-mipshop-tunneling-optimization-01.txt


Regards,

Wassim H.


X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F02928C18A; Mon, 17 Nov 2008 14:47:45 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B61028C172; Mon, 17 Nov 2008 14:47:43 -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 SJI4rkdTvP01; Mon, 17 Nov 2008 14:47:42 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 80B713A6922; Mon, 17 Nov 2008 14:47:42 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1L2Csc-0003LC-9N; Mon, 17 Nov 2008 23:47:38 +0100 X-Hashcash: 1:20:081117:ipsec@ietf.org::5nr40BJfxY5+aE/9:0000k6B From: arno@natisbad.org (Arnaud Ebalard) To: "Haddad\, Wassim Michel" References: 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:081117:mext@ietf.org::vI8uGZGwHWmdiCo8:00000+50 X-Hashcash: 1:20:081117:mobopts@irtf.org::6F9PKFB227oVUlps:030T6 X-Hashcash: 1:20:081117:whaddad@qualcomm.com::1904AmG5DqwOftse:000000000000000000000000000000000000000005ymi Date: Mon, 17 Nov 2008 14:45:54 -0800 In-Reply-To: (Wassim Michel Haddad's message of "Mon, 17 Nov 2008 12:57:23 -0800") Message-ID: <87r65adl99.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: IPsec IETF WG ML , Mobopts IRTF WG ML , IETF MEXT WG ML Subject: Re: [MEXT] [Mobopts] MIPv6 IPsec Route Optimization (IRO) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, "Haddad, Wassim Michel" writes: > I have just submitted a new I-D [1] which certainly requires an > introduction (and disclaimer): it specifies a MIPv6 Route Optimization > procedure *dedicated* to environments where IPsec/IKE is used between > peers (MN-HA, MN-CN, MN-MN) for protecting both signaling and data > traffic. > > Some of the improvements provided by this "IPsec Route Optimization" > mechanism (IRO) are also proposed for the IPsec communications between > the MN and its HA. > > Among the features provided by IRO (introduction of the document as > a more accurate list): > > * Complete removal of RH2 and HAO (resulting in simplified packet > handling on both sides and possibly better compatibility with > filtering implemented in the network), > > => You can have complete removal of both options without introducing a > new RO mode. Sure. But there are additional reasons (and advantages, as provided in my previous list) to introduce a new RO mode. IMHO, those advantages are worth the introduction. But I am interested on feedback about those specific parts of my I-D. > Please check > http://www.ietf.org/internet-drafts/draft-haddad-mipshop-tunneling-optimization-01.txt I already read version -00. I basically took a look at all I-D and reference documents associated with tunneling optimizations and MIPv6 RO (always in an IPsec context): ERO, BEET, RO design history, your draft ... Your proposal may have an interest for the common RO case if one intend to keep the RRP. I just don't. I am convinced that removing the duplicated states and exchanges when IPsec/IKE are used in a MIPv6 context can provide a far better solution. >From my perspective, I just don't feel the need to introduce additional states and exchanges (the PaT) because those are already available locally (and synchronized over time) on the IPsec/MIPv6 entities (SA/Bindings). Obviously, this is only true for IPsec entities, which are (as presented before) my targets. Thanks for your comments. Cheers, a+ ps: note that my -00 lacks pictures to ease the understanding of what happens. That's on the todo list for -01. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 16:57:32 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1013A6A8A; Mon, 17 Nov 2008 16:57:32 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012363A6A8A for ; Mon, 17 Nov 2008 16:57:31 -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 z4rMbyGAz1IJ for ; Mon, 17 Nov 2008 16:57:30 -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 2228B3A6897 for ; Mon, 17 Nov 2008 16:57:30 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2653566rvf.49 for ; Mon, 17 Nov 2008 16:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:user-agent :mime-version:to:cc:subject:content-type:content-transfer-encoding :from; bh=gOrZawp8WHbh7FsaQ+7+26JSAWRZihIhuelT3AhzXiY=; b=jpdBWzI8WaLybPuDgVwEmCUol6htLgIU46t15J4mCJBkXRwwJcpvMLXT5XMiULSP5t RD8598P6mPOWm/YG6QBPVaLckO/MEXwqUMiNzF0vLxFTcm/cat2oDFl0bBf9xJHoOKke JmfLjewubDPbwQ09zXFCdnzWtY3YdS7Cbss44= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:user-agent:mime-version:to:cc:subject:content-type :content-transfer-encoding:from; b=t+o0lVn0pUedZpp2fxWLDpcMvaEuRW2BfYB8seUGwjW0M0kijzqNvaJMwD6XwZeS9D 3NqG0LiukVpNXDJ0kFHRpHBIOX+zm9SK3mOuvrEQedLkKfqO+W54E4jHuq4S8g/VutB1 El3cWn0G3qkHHTOigllg//2JjrtAHZDXxLgOU= Received: by 10.141.206.13 with SMTP id i13mr2590518rvq.76.1226969849111; Mon, 17 Nov 2008 16:57:29 -0800 (PST) Received: from ?130.129.29.123? ([130.129.29.123]) by mx.google.com with ESMTPS id b8sm11172102rvf.3.2008.11.17.16.57.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 Nov 2008 16:57:28 -0800 (PST) Message-ID: <49221303.9000807@googlemail.com> Date: Tue, 18 Nov 2008 01:57:39 +0100 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: mext@ietf.org From: Julien Laganier Subject: [MEXT] Slides for 2nd MEXT session X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Dear 2nd MEXT session presenters, For the sake of making your talks more attractive to remote attendees, we're kindly requesting you to send us your slides for the 2nd MEXT session before Thursday 11:00 AM so that we can upload them on the meeting material server before the meeting starts. We appreciate your support. --julien & marcelo, MEXT chairs. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 20:58:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8FE328C144; Mon, 17 Nov 2008 20:58:35 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9DA3A6A8B for ; Mon, 17 Nov 2008 20:58:34 -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 j6Lmo0dzGqNX for ; Mon, 17 Nov 2008 20:58:33 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 6E3873A6909 for ; Mon, 17 Nov 2008 20:58:32 -0800 (PST) Received: from [12.167.162.5] (helo=[172.17.199.160]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1L2IfU-0005H0-1K; Tue, 18 Nov 2008 15:58:29 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Tue, 18 Nov 2008 15:58:17 +1100 From: Hesham Soliman To: Asanga Udugama , 'Umar Toseef' , Message-ID: Thread-Topic: [MEXT] draft-ietf-mext-flow-binding-00.txt - comments Thread-Index: AclGrApsE3huE+zyJ0+wfgho/TPLogB5ZEAgACoqX6Y= In-Reply-To: Mime-version: 1.0 Subject: Re: [MEXT] draft-ietf-mext-flow-binding-00.txt - comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > I too have a lot of experience in using the implementation done by Umar of > the draft-soliman-monami6-flow-binding. In my opinion, I believe that this > is a very clear and a simple draft, which follows the KISS principle. => great. > > Some time back, I too implemented a similar flow management draft on MIPv4. > It was done on the Sun Labs MIPv4 and it was called NOMAD. Similar to Umar's > implementation, it too used the packet marking and multiple routing table > features available in Linux. When I did this implementation, there were > other simple features that were present in it compared to this draft. I > would like to ask the authors, why these have been removed. Was there any > reason to leave these out? 2 of these are, => We didn't remove anything from our draft, perhaps you're asking why we didn't include some of the features in nomad. > > 1) Splitting flows - Meaning that the packets of a single flow are placed on > different attachments. I know that TCP would perform adversely but some UDP > based applications may perform better. Further, the draft that I implemented > also allowed the specification of the packet distribution ration, which I > found very interesting as then, the ratio can be optimally decided to cater > to the different characteristics of the network attachments => We felt that this is not a good idea for multiple reasons: - As you said, most TCP implementations deployed would struggle with this and it can have negative impacts. In fact, there are several recommendations by traffic engineers to avoid this sort of thing. - the paths can be very diverse in terms of delays. - Secure traffic would fail in this scenario. In many cases you don't know if the traffic will be secure or not. This applies to UDP traffic too. > > 2) Free-form filters - Meaning that we could set filters based on any part > of the packet, rather than only the headers. I know that this may not be > possible when the payload is encrypted. But still there maybe instances when > pattern matching maybe done on the payload to identify a flow. => Filters are not included in this draft at all. The WG decided to do this in a separate draft. Hesham > > Kind regards, > Asanga > > > > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of >> Hesham Soliman >> Sent: 14 November 2008 23:55 >> To: Umar Toseef; mext@ietf.org >> Subject: Re: [MEXT] draft-ietf-mext-flow-binding-00.txt - comments >> >> Thanks for the review. A comment below. >> >>> I just went through the draft-ietf-mext-flow-binding-00.txt while >>> previously I implemented the basic functionaliy of >>> draft-soliman-monami6-flow-binding. It's good to see that based on the >>> demands of reviewers authors have excluded the flow description part >>> from the flow binding mechanism. Of course it offers more flexibility to >>> those who want to use flow bindings with their custom way of flow >>> description. However I have two comments on this draft. First of all, >>> while implementing draft-soliman-monami6-flow-binding I realized that >>> prioritizing flow bindings creates a lot of complexity when it comes to >>> managing the flows. For example sender has to determine the overlaps and >>> specify correct priority of each flow binding and similarly the receiver >>> will also be taking care of priorities while installing the filters. >>> This situation gets worse as number of flow bindings grows. In my >>> opinion leaving priority out and using chronological order of filters at >>> the receiving end will make things more simple and easy for practical >> use. >> >> => I think we need to be careful when we discuss features in terms of >> "simple" and "complex". You need to look at what you lose to make it >> simple >> to implement. In this case you lose a major function that handles >> overlaps. >> This is fundamental to any filtering. It's ok to have complex algorithms, >> it's not like the user will know anything. If we didn't have complex >> features there would be no google :). >> >>> Secondly, I am not a fan of n-casting option. Such mechanisms of >>> diversity work better at lower layers therefore when lower layers are >>> already making use of diversity then redoing it at network layer does >>> seems very attractive to me. >>> However these are just opinions from my side and i invite other working >>> group members to comment on it. >> >> => I have to agree with Stuart's comment here. Lower layers have nothing >> to >> do with this. This is an e2e feature. >> >> Hesham >> >>> Have a nice weekend, >>> Kind Regards, >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 17 22:50:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CE2A28C1E6; Mon, 17 Nov 2008 22:50:44 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DEB028C1E6 for ; Mon, 17 Nov 2008 22:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.324 X-Spam-Level: ** X-Spam-Status: No, score=2.324 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 t+O7ukeWkzjY for ; Mon, 17 Nov 2008 22:50:42 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by core3.amsl.com (Postfix) with ESMTP id 4859928C1D7 for ; Mon, 17 Nov 2008 22:50:42 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.195]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id mAI6oeIi005623 for ; Tue, 18 Nov 2008 15:50:40 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id mAI6oeC09871 for mext@ietf.org; Tue, 18 Nov 2008 15:50:40 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id mAI6oe8T015820 for ; Tue, 18 Nov 2008 15:50:40 +0900 (JST) Received: from matabe.jp.nec.com ([10.26.220.20] [10.26.220.20]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-34476; Tue, 18 Nov 2008 15:49:02 +0900 Received: from [10.62.69.165] ([10.62.69.165] [10.62.69.165]) by mail.jp.nec.com with ESMTP; Tue, 18 Nov 2008 15:49:01 +0900 Message-ID: <4922655C.5000701@az.jp.nec.com> Date: Tue, 18 Nov 2008 15:49:00 +0900 From: Jun AWANO User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: mext@ietf.org Subject: [MEXT] some questions for revocation draft-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi all, I've read revocation draft-01 and had some questions. The 6th item of draft-01 section 10.1.1 says: " If the Revocation Trigger field in the received BRI message is set to "Inter-MAG - Unknown Handoff", the MAG use the mobility option(s) included in the BRI message to identify the mobile node binding and MUST validate that the mobile node is no longer attached to the MAG before sending a successful BRA message and deleting the resources associated with the mobile node binding." How the MAG should do? in case the MN is still attaching the MAG. I guess the MAG does nothing by receiving BRI. The MAG may send PBU with lifetime set to zero after it by detaching MN as per section 6.9.1.4 of RFC5213, though. Right? A relation between a value of Revocation Trigger Field and a value of Handoff Indicator Option included in the (last received?) PBU is a little bit unclear. I think some values of Revocation Trigger are supposed to refer to the Handoff Indicator to work well. BR, Jun. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 18 03:33:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA7BB3A6A9F; Tue, 18 Nov 2008 03:33:46 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C2D3A6A9F for ; Tue, 18 Nov 2008 03:33:45 -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 kGuKPM54-6xQ for ; Tue, 18 Nov 2008 03:33:43 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 63C3F3A6A28 for ; Tue, 18 Nov 2008 03:33:43 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mAIBXbq20807; Tue, 18 Nov 2008 11:33:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 05:33:05 -0600 Message-ID: In-Reply-To: <4922655C.5000701@az.jp.nec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] some questions for revocation draft-01 Thread-Index: AclJSgS/W1ZycFLYSxGQI1T7Gf3OrwAJYo2A References: <4922655C.5000701@az.jp.nec.com> From: "Ahmad Muhanna" To: "Jun AWANO" , Subject: Re: [MEXT] some questions for revocation draft-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Jun, Please see comments inline. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Jun AWANO > Sent: Tuesday, November 18, 2008 12:49 AM > To: mext@ietf.org > Subject: [MEXT] some questions for revocation draft-01 > > Hi all, > > I've read revocation draft-01 and had some questions. > > The 6th item of draft-01 section 10.1.1 says: > " If the Revocation Trigger field in the received BRI message is set > to "Inter-MAG - Unknown Handoff", the MAG use the mobility > option(s) included in the BRI message to identify the mobile node > binding and MUST validate that the mobile node is no longer > attached to the MAG before sending a successful BRA message and > deleting the resources associated with the mobile node binding." > > How the MAG should do? in case the MN is still attaching the MAG. > I guess the MAG does nothing by receiving BRI. [Ahmad] When the MAG receives the BRI message and finds out the MN is still attached to the MAG, the MAG should send a BRA with status "6 Revocation Failed, MN is Attached". > The MAG may send PBU with lifetime set to zero after it by > detaching MN as per section 6.9.1.4 of RFC5213, though. > Right? [Ahmad] I do not understand what you mean here? If the MAG would send a PBU with lifetime zero, why just NOT send a successful BRA. Any how, if the MAG sends a PBU with lifetime zero in response to the BRI with R. Trigger is set to "Inter-MAG - Unknown Handoff", the LMA should consider this PBU as a successful response to the BRI. > > A relation between a value of Revocation Trigger Field and a > value of Handoff Indicator Option included in the (last > received?) PBU is a little bit unclear. [Ahmad] What is NOT clear. I believe it is inline of RFC5213. > I think some values of Revocation Trigger are supposed to > refer to the Handoff Indicator to work well. > > BR, > Jun. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 18 03:39:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1B6B3A6AD3; Tue, 18 Nov 2008 03:39:04 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5FC23A6AD3 for ; Tue, 18 Nov 2008 03:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.024 X-Spam-Level: X-Spam-Status: No, score=-10.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fCETbKw9UmV for ; Tue, 18 Nov 2008 03:38:59 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 950D93A68D5 for ; Tue, 18 Nov 2008 03:38:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,624,1220227200"; d="scan'208";a="25979703" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2008 11:38:52 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAIBcqxc007469; Tue, 18 Nov 2008 12:38:52 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAIBcqYm022057; Tue, 18 Nov 2008 11:38:52 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 12:38:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 12:38:45 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC068EACA5@xmb-ams-337.emea.cisco.com> In-Reply-To: <4914CEF6.5040509@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] consensus call on dhaad Thread-Index: AclBMH6N8I6Y+rbNScGHOKL/DTS9KgIQFEZA References: <491400A0.50700@it.uc3m.es> <49141B0F.1080806@gmail.com> <4914CEF6.5040509@earthlink.net> From: "Pascal Thubert (pthubert)" To: "Charles E. Perkins" , "mext" X-OriginalArrivalTime: 18 Nov 2008 11:38:52.0792 (UTC) FILETIME=[3B5E8780:01C94972] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4727; t=1227008332; x=1227872332; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[MEXT]=20consensus=20call=20on=20dhaad |Sender:=20; bh=ArBSw4pgPTOL9OmovAdMT0qUJtehp9Eq+0ZXf8WoZQg=; b=j/H3RaXr1Md9H+t8szOf88D68lwbANnMYWzX7IdZj8Smz+YvAXL/JyKJpX 1H+62IdgbAvMezVSYYjR39za+SZ7stkKsuCt4C1+f0KvHEOQ/PmWgmccOxEv G7CBMjahog; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "Frederic Detienne \(fdetienn\)" Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Charlie: I find your arguments perfectly reasonable. There's another dimension that I'd wish more emphasized here: the interest of the users. At the last Mext meeting, Frederic Detienne gave us a very interesting analogy (paraphrasing, Fred, please correct me if I'm wrong): What we found deploying DMVPN (that has both a DNS-type and a DHAAD-type functionality) is that the users pretty much split in half, each side favoring one approach and not ready to migrate to the other. MIP6 and NEMO have similar properties with DMVPN. The analogy would indicate us that once mobility technologies reach acceptance and larger deployments, users will also equally like both approaches. Removing DHAAD is just taking a deployment option away from them. Pascal >-----Original Message----- >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Charles E. Perkins >Sent: samedi 8 novembre 2008 00:28 >To: mext >Subject: Re: [MEXT] consensus call on dhaad > > >Hello folks, > >For the purposes of this discussion, I will remain neutral >on the technical merits of DHAAD. However, I think it >would be pretty unwelcome for the IETF to standardize >protocol features, and then to remove them without >strong cause. > >If I summarize the reasons to remove so far, we have: >a) alternative mechanisms exist >b) "no strong position on the issue, but simpler without" > >as opposed to the reasons to retain: >- "used in NEMOv6 rfc3963" >- "released products that support this feature" >- previous consensus to retain > > >I don't think that all votes should be counted >equally in this debate. But there is one other >alternative to be mentioned. DHAAD "could" >be separated out into another document. I don't >know why two documents would be better than >one, but anyway it might satisfy more people. >Vendors could claim compliance to _more_ >standards. Simplifications could be had. I could >have _more_ work to do. _More_ alternatives >could be available (oops, those last two are negatives). > >Just a thought. > >Regards, >Charlie P. > > > > >Sri Gundavelli wrote: >> Hi Marcelo, >> >> Not sure, why we are running a consensus call on this issue. We already >> discussed this in March IETF and clearly the general input from the >> group was to retain DHAAD support in Mobile IPv6 specification. That >> is a feature that exists in MIP6 implementations today, in released >> products. Its used in NEMO spec and all Mobile Routers support this. >> So, we (Cisco) have two released products that support this feature. >> >> We cannot take out features in this random fashion and after a quick >> 2 week consensus call. This is a big decision as there is impact on >> released products. Also, the input from our Area Director in >> meeting during March IETF was to retain this in the spec. >> >> Bottom line, I strongly disagree taking DHAAD out. >> >> Regards >> Sri >> >> >> >> >> On Fri, 7 Nov 2008, Alexandru Petrescu wrote: >> >>> marcelo bagnulo braun wrote: >>>> Hi, >>>> >>>> There has been a very long debate on whether we should keep or remove >>>> dhaad from rfc3775bis. We would like to ask people to express >>>> whether they want to keep dhaad or remove it from rfc3775bis at this >>>> point. Please send your opinion before the 14 of november. >>> >>> DHAAD has been implemented and tested for interoperability, and is used >>> by NEMOv6 rfc3963 as well - keep it in rfc3775bis. >>> >>> Alex >>> >>>> >>>> (we are going to consider for this poll only the opinions sent as >>>> reply to this email, so even if you think your opinion is well known, >>>> reply to this email stating it again, so it can be considered as part >>>> of this poll) >>>> >>>> Regards, marcelo >>>> >>>> _______________________________________________ MEXT mailing list >>>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >>>> >>> >>> >>> ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security System. >>> For more information please visit http://www.messagelabs.com/email >>> _______________________________________________ _______________________ >>> _______________________________________________ MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 18 03:44:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 459B63A6A28; Tue, 18 Nov 2008 03:44:07 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A6553A687C for ; Tue, 18 Nov 2008 03:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.216 X-Spam-Level: X-Spam-Status: No, score=-10.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGlrIs1-h6dO for ; Tue, 18 Nov 2008 03:44:05 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D953F3A6A28 for ; Tue, 18 Nov 2008 03:44:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,624,1220227200"; d="scan'208";a="25980450" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2008 11:44:03 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAIBi3ti008260; Tue, 18 Nov 2008 12:44:03 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAIBi3Tw023904; Tue, 18 Nov 2008 11:44:03 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 12:44:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 12:43:56 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC068EACAD@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt Thread-Index: Ack+dVcmbdMFOgZjR/yrViXknMazigAOh8xAArDQFSA= References: <491039B9.6090400@it.uc3m.es> From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "marcelo bagnulo braun" , "mext" , "Julien Laganier" , "Ralph Droms (rdroms)" X-OriginalArrivalTime: 18 Nov 2008 11:44:03.0081 (UTC) FILETIME=[F450DF90:01C94972] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2188; t=1227008643; x=1227872643; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[MEXT]=20WGLC=20for=20draft-ietf-mext-n emo-pd-01.txt |Sender:=20; bh=YkDBYVbEgNugMMXuVoOfuto5bgk/kenbc3CU3IKmNJg=; b=Xdr4p7pdIQlP9Z5MvUz7IKdggZt/MjYz3fqIaR+OlWiquPqkKnDU/CifgW wMHi417uR0Y/FqldPzsqefcJNGFQt3WMbOVdmjKLtSxuymuxxOVNc1n6NTt8 pVVZKFVxXF; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay: Same old discussion. My position is still the same. Either we deprecate DHAAD fully (from 3775bis), or we need to extend it when it makes sense. The draft-ietf-mext-nemo-pd draft is not the right place for making this decision. Pascal >-----Original Message----- >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Vijay Devarapalli >Sent: mardi 4 novembre 2008 20:03 >To: marcelo bagnulo braun; mext; Julien Laganier; Ralph Droms (rdroms) >Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt > >Hi Marcelo, > >We should remove the extensions to DHAAD from this document. IMO, it's a >bad idea to keep extending DHAAD every time we add an extension to >MIPv6. > >We could extend DNS-based HA lookup for discovering a home agent that is >capable of NEMO prefix delegation. But I think this is also unnecessary. >The mobile router can always try the next home agent in the list of the >home agents if the first one does not respond to DHCPv6 messages. If >none of the home agents are capable of prefix delegation, then there is >nothing the mobile router can do about it, maybe use some static mobile >network prefixes. > >We had a discussion at the last IETF and on the mailing list before on >this, but there was no conclusion. > >Vijay > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of marcelo bagnulo braun >> Sent: Tuesday, November 04, 2008 4:02 AM >> To: mext; Julien Laganier; Ralph Droms >> Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt >> >> Hi, >> >> We now start the WGLC for: >> >> DHCPv6 Prefix Delegation for NEMO >> draft-ietf-mext-nemo-pd-01.txt >> >> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt >> >> >> Please send comments about the draft till the November 19. >> >> Regards, Julien and marcelo >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 18 07:25:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9DA63A68E5; Tue, 18 Nov 2008 07:25:47 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C57B3A68A4 for ; Tue, 18 Nov 2008 07:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 lSPvQQvaogL0 for ; Tue, 18 Nov 2008 07:25:46 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 029B53A695A for ; Tue, 18 Nov 2008 07:25:45 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2938630rvf.49 for ; Tue, 18 Nov 2008 07:25:44 -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=rD5iDM2WcitZ+EvPp6PPfOdlRTqvzxVOmQ6a5XZxkjI=; b=vOUc0R19wzTMlNKYRqpUkB4uLSQajFRwRq4gzFTDQ8HAAp8aNTbKtWM27rrWvfMOT6 G9KDPqJt4s/03l+TymqyIO9/sEBlqkRYdNcN777kNccerVNm0WvSy+x9P6E/67a/b4qT A9SgIAWeryCX7/wkeetAOxcLDW3T7zpYsCldo= 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=FJ1aBtIoiPV6obR/XHCknk63F1PqeMerqIZ49/5GzfDHV2UFl/LDckryCQU7owxSp3 9+2RaduXW/L7h2fcStqB1PziJyZ9nNOy0TuKEVxtENmJgYc/plZzvvx2U4NgnDG2M6D9 qbg0Qk8BUyAcdwol6ngkLh79/EJBnCo73Esnc= Received: by 10.140.191.14 with SMTP id o14mr668rvf.3.1227021944885; Tue, 18 Nov 2008 07:25:44 -0800 (PST) Received: from ?130.129.94.239? ([130.129.94.239]) by mx.google.com with ESMTPS id l31sm12984161rvb.2.2008.11.18.07.25.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Nov 2008 07:25:44 -0800 (PST) From: Ryuji Wakikawa To: Thierry Ernst In-Reply-To: <491ABE4F.3070401@inria.fr> References: <491400A0.50700@it.uc3m.es> <49141B0F.1080806@gmail.com> <4914CEF6.5040509@earthlink.net> <491ABE4F.3070401@inria.fr> Message-Id: <02E81189-CA8C-4FFA-9914-8C57DD308588@gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 18 Nov 2008 09:25:41 -0600 X-Mailer: Apple Mail (2.929.2) Cc: mext Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Thierry, On 2008/11/12, at 5:30, Thierry Ernst wrote: > > From MIPv6's perspective I'm neutral on removing DHAAD. > > From NEMO's perspective, DHAAD should be kept. Can you explain why? When MR boots up, it follows one of the bootstrapping mechanism and starts DHCP-PD after the binding registration. DHAAD is not used in the sequence of the MR's bootstrap. regards, ryuji > > > This makes me come to Charlie's wondering about separating specs. > Instead of separating DHAAD (this is a good suggestion, indeed), > I've always wonder if we shouldn't have a spec for HA, on for NEMO- > MR, and one for MIP6-MH (and may be yet another one for packet > format). This would a significant work, but in the end it may prove > useful to implementers and archictural work but other bodies using > IETF specs. > > Thierry > > > > Charles E. Perkins wrote: >> >> Hello folks, >> >> For the purposes of this discussion, I will remain neutral >> on the technical merits of DHAAD. However, I think it >> would be pretty unwelcome for the IETF to standardize >> protocol features, and then to remove them without >> strong cause. >> >> If I summarize the reasons to remove so far, we have: >> a) alternative mechanisms exist >> b) "no strong position on the issue, but simpler without" >> >> as opposed to the reasons to retain: >> - "used in NEMOv6 rfc3963" >> - "released products that support this feature" >> - previous consensus to retain >> >> >> I don't think that all votes should be counted >> equally in this debate. But there is one other >> alternative to be mentioned. DHAAD "could" >> be separated out into another document. I don't >> know why two documents would be better than >> one, but anyway it might satisfy more people. >> Vendors could claim compliance to _more_ >> standards. Simplifications could be had. I could >> have _more_ work to do. _More_ alternatives >> could be available (oops, those last two are negatives). >> >> Just a thought. >> >> Regards, >> Charlie P. >> >> >> >> >> Sri Gundavelli wrote: >>> Hi Marcelo, >>> >>> Not sure, why we are running a consensus call on this issue. We >>> already >>> discussed this in March IETF and clearly the general input from the >>> group was to retain DHAAD support in Mobile IPv6 specification. That >>> is a feature that exists in MIP6 implementations today, in released >>> products. Its used in NEMO spec and all Mobile Routers support this. >>> So, we (Cisco) have two released products that support this feature. >>> >>> We cannot take out features in this random fashion and after a quick >>> 2 week consensus call. This is a big decision as there is impact on >>> released products. Also, the input from our Area Director in >>> meeting during March IETF was to retain this in the spec. >>> >>> Bottom line, I strongly disagree taking DHAAD out. >>> >>> Regards >>> Sri >>> >>> >>> >>> >>> On Fri, 7 Nov 2008, Alexandru Petrescu wrote: >>> >>>> marcelo bagnulo braun wrote: >>>>> Hi, >>>>> >>>>> There has been a very long debate on whether we should keep or >>>>> remove >>>>> dhaad from rfc3775bis. We would like to ask people to express >>>>> whether they want to keep dhaad or remove it from rfc3775bis at >>>>> this >>>>> point. Please send your opinion before the 14 of november. >>>> >>>> DHAAD has been implemented and tested for interoperability, and >>>> is used >>>> by NEMOv6 rfc3963 as well - keep it in rfc3775bis. >>>> >>>> Alex >>>> >>>>> >>>>> (we are going to consider for this poll only the opinions sent as >>>>> reply to this email, so even if you think your opinion is well >>>>> known, >>>>> reply to this email stating it again, so it can be considered as >>>>> part >>>>> of this poll) >>>>> >>>>> Regards, marcelo >>>>> >>>>> _______________________________________________ MEXT mailing list >>>>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >>>>> >>>> >>>> >>>> ______________________________________________________________________ >>>> This email has been scanned by the MessageLabs Email Security >>>> System. >>>> For more information please visit http://www.messagelabs.com/ >>>> email _______________________________________________ >>>> _______________________ >>>> _______________________________________________ MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 18 09:09:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1220528C21F; Tue, 18 Nov 2008 09:09:46 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEE5728C21E for ; Tue, 18 Nov 2008 09:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 eaAmMaEjXnf0 for ; Tue, 18 Nov 2008 09:09:43 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 124D828C20E for ; Tue, 18 Nov 2008 09:09:42 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mAIH9As6020760; Tue, 18 Nov 2008 19:09:21 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 19:09:20 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 19:09:20 +0200 Received: from 10.241.58.230 ([10.241.58.230]) by daebe104.NOE.Nokia.com ([10.241.36.13]) with Microsoft Exchange Server HTTP-DAV ; Tue, 18 Nov 2008 17:09:18 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Tue, 18 Nov 2008 11:09:20 -0600 From: Basavaraj Patil To: "ext Pascal Thubert (pthubert)" , Charles Perkins , mext Message-ID: Thread-Topic: [MEXT] consensus call on dhaad Thread-Index: AclBMH6N8I6Y+rbNScGHOKL/DTS9KgIQFEZAAAvlauk= In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC068EACA5@xmb-ams-337.emea.cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 18 Nov 2008 17:09:20.0089 (UTC) FILETIME=[655BF490:01C949A0] X-Nokia-AV: Clean Cc: "Frederic Detienne \(fdetienn\)" Subject: Re: [MEXT] consensus call on dhaad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Pascal, On 11/18/08 5:38 AM, "ext Pascal Thubert (pthubert)" wrote: > Hi Charlie: > > I find your arguments perfectly reasonable. > > There's another dimension that I'd wish more emphasized here: the > interest of the users. And can you elaborate why there is specific interest in using DHAAD vs any of the other bootstrapping mechanisms? > > At the last Mext meeting, Frederic Detienne gave us a very interesting > analogy (paraphrasing, Fred, please correct me if I'm wrong): > > What we found deploying DMVPN (that has both a DNS-type and a DHAAD-type > functionality) is that the users pretty much split in half, each side > favoring one approach and not ready to migrate to the other. > > MIP6 and NEMO have similar properties with DMVPN. The analogy would > indicate us that once mobility technologies reach acceptance and larger > deployments, users will also equally like both approaches. Removing > DHAAD is just taking a deployment option away from them. I think this is highly speculative. DHAAD as currently specified has little use in any real deployment given some of the issues that have been discussed. The only claim that I have heard so far is from Sri saying that there is an existing implementation of this feature today. However the question still would be if it is actually used. Having it in an implemenation is one thing vs whether it serves any useful purpose. -Raj > > Pascal > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Charles E. Perkins >> Sent: samedi 8 novembre 2008 00:28 >> To: mext >> Subject: Re: [MEXT] consensus call on dhaad >> >> >> Hello folks, >> >> For the purposes of this discussion, I will remain neutral >> on the technical merits of DHAAD. However, I think it >> would be pretty unwelcome for the IETF to standardize >> protocol features, and then to remove them without >> strong cause. >> >> If I summarize the reasons to remove so far, we have: >> a) alternative mechanisms exist >> b) "no strong position on the issue, but simpler without" >> >> as opposed to the reasons to retain: >> - "used in NEMOv6 rfc3963" >> - "released products that support this feature" >> - previous consensus to retain >> >> >> I don't think that all votes should be counted >> equally in this debate. But there is one other >> alternative to be mentioned. DHAAD "could" >> be separated out into another document. I don't >> know why two documents would be better than >> one, but anyway it might satisfy more people. >> Vendors could claim compliance to _more_ >> standards. Simplifications could be had. I could >> have _more_ work to do. _More_ alternatives >> could be available (oops, those last two are negatives). >> >> Just a thought. >> >> Regards, >> Charlie P. >> >> >> >> >> Sri Gundavelli wrote: >>> Hi Marcelo, >>> >>> Not sure, why we are running a consensus call on this issue. We > already >>> discussed this in March IETF and clearly the general input from the >>> group was to retain DHAAD support in Mobile IPv6 specification. That >>> is a feature that exists in MIP6 implementations today, in released >>> products. Its used in NEMO spec and all Mobile Routers support this. >>> So, we (Cisco) have two released products that support this feature. >>> >>> We cannot take out features in this random fashion and after a quick >>> 2 week consensus call. This is a big decision as there is impact on >>> released products. Also, the input from our Area Director in >>> meeting during March IETF was to retain this in the spec. >>> >>> Bottom line, I strongly disagree taking DHAAD out. >>> >>> Regards >>> Sri >>> >>> >>> >>> >>> On Fri, 7 Nov 2008, Alexandru Petrescu wrote: >>> >>>> marcelo bagnulo braun wrote: >>>>> Hi, >>>>> >>>>> There has been a very long debate on whether we should keep or > remove >>>>> dhaad from rfc3775bis. We would like to ask people to express >>>>> whether they want to keep dhaad or remove it from rfc3775bis at > this >>>>> point. Please send your opinion before the 14 of november. >>>> >>>> DHAAD has been implemented and tested for interoperability, and is > used >>>> by NEMOv6 rfc3963 as well - keep it in rfc3775bis. >>>> >>>> Alex >>>> >>>>> >>>>> (we are going to consider for this poll only the opinions sent as >>>>> reply to this email, so even if you think your opinion is well > known, >>>>> reply to this email stating it again, so it can be considered as > part >>>>> of this poll) >>>>> >>>>> Regards, marcelo >>>>> >>>>> _______________________________________________ MEXT mailing list >>>>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >>>>> >>>> >>>> >>>> > ______________________________________________________________________ >>>> This email has been scanned by the MessageLabs Email Security > System. >>>> For more information please visit http://www.messagelabs.com/email >>>> _______________________________________________ > _______________________ >>>> _______________________________________________ MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 18 11:27:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 862AC3A6B15; Tue, 18 Nov 2008 11:27:12 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D8C13A6B15 for ; Tue, 18 Nov 2008 11:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 x7znYI7QEV9e for ; Tue, 18 Nov 2008 11:27:10 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EE45D3A6808 for ; Tue, 18 Nov 2008 11:27:09 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 48C9A211D2; Tue, 18 Nov 2008 20:27:08 +0100 (CET) X-AuditID: c1b4fb3e-ab77fbb00000537b-7f-4923170c45ba Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0D45C2119D; Tue, 18 Nov 2008 20:27:08 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 20:27:07 +0100 Received: from [127.0.0.1] ([153.88.45.207]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 20:27:06 +0100 Message-ID: <49231705.9020406@ericsson.com> Date: Tue, 18 Nov 2008 13:27:01 -0600 From: Conny Larsson User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Hesham Soliman , Asanga Udugama References: In-Reply-To: X-OriginalArrivalTime: 18 Nov 2008 19:27:06.0984 (UTC) FILETIME=[A4D00680:01C949B3] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] draft-ietf-mext-flow-binding-00.txt - comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0485889051==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0485889051== Content-Type: multipart/alternative; boundary="------------000400060109080807080508" This is a multi-part message in MIME format. --------------000400060109080807080508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Asanga, Hesham Soliman wrote: [snip] >> 2) Free-form filters - Meaning that we could set filters based on any part >> of the packet, rather than only the headers. I know that this may not be >> possible when the payload is encrypted. But still there maybe instances when >> pattern matching maybe done on the payload to identify a flow. >> > > => Filters are not included in this draft at all. The WG decided to do this > in a separate draft. > And the draft describing how this can be done is http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rules-01.txt Regards Conny > Hesham > > > >> Kind regards, >> Asanga >> >> >> >> >> >>> -----Original Message----- >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of >>> Hesham Soliman >>> Sent: 14 November 2008 23:55 >>> To: Umar Toseef; mext@ietf.org >>> Subject: Re: [MEXT] draft-ietf-mext-flow-binding-00.txt - comments >>> >>> Thanks for the review. A comment below. >>> >>> >>>> I just went through the draft-ietf-mext-flow-binding-00.txt while >>>> previously I implemented the basic functionaliy of >>>> draft-soliman-monami6-flow-binding. It's good to see that based on the >>>> demands of reviewers authors have excluded the flow description part >>>> from the flow binding mechanism. Of course it offers more flexibility to >>>> those who want to use flow bindings with their custom way of flow >>>> description. However I have two comments on this draft. First of all, >>>> while implementing draft-soliman-monami6-flow-binding I realized that >>>> prioritizing flow bindings creates a lot of complexity when it comes to >>>> managing the flows. For example sender has to determine the overlaps and >>>> specify correct priority of each flow binding and similarly the receiver >>>> will also be taking care of priorities while installing the filters. >>>> This situation gets worse as number of flow bindings grows. In my >>>> opinion leaving priority out and using chronological order of filters at >>>> the receiving end will make things more simple and easy for practical >>>> >>> use. >>> >>> => I think we need to be careful when we discuss features in terms of >>> "simple" and "complex". You need to look at what you lose to make it >>> simple >>> to implement. In this case you lose a major function that handles >>> overlaps. >>> This is fundamental to any filtering. It's ok to have complex algorithms, >>> it's not like the user will know anything. If we didn't have complex >>> features there would be no google :). >>> >>> >>>> Secondly, I am not a fan of n-casting option. Such mechanisms of >>>> diversity work better at lower layers therefore when lower layers are >>>> already making use of diversity then redoing it at network layer does >>>> seems very attractive to me. >>>> However these are just opinions from my side and i invite other working >>>> group members to comment on it. >>>> >>> => I have to agree with Stuart's comment here. Lower layers have nothing >>> to >>> do with this. This is an e2e feature. >>> >>> Hesham >>> >>> >>>> Have a nice weekend, >>>> Kind Regards, >>>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > --------------000400060109080807080508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Asanga,

Hesham Soliman wrote:
[snip]
2) Free-form filters - Meaning that we could set filters based on any part
of the packet, rather than only the headers. I know that this may not be
possible when the payload is encrypted. But still there maybe instances when
pattern matching maybe done on the payload to identify a flow.
    

=> Filters are not included in this draft at all. The WG decided to do this
in a separate draft.
And the draft describing how this can be done is http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rules-01.txt

Regards
Conny
Hesham


  
Kind regards,
Asanga




    
-----Original Message-----
From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of
Hesham Soliman
Sent: 14 November 2008 23:55
To: Umar Toseef; mext@ietf.org
Subject: Re: [MEXT] draft-ietf-mext-flow-binding-00.txt - comments

Thanks for the review. A comment below.

      
I just went through the draft-ietf-mext-flow-binding-00.txt while
previously I implemented the basic functionaliy of
draft-soliman-monami6-flow-binding. It's good to see that based on the
demands of reviewers authors have excluded the flow description part
from the flow binding mechanism. Of course it offers more flexibility to
those who want to use flow bindings with their custom way of flow
description. However I have two comments on this draft. First of all,
while implementing draft-soliman-monami6-flow-binding I realized that
prioritizing flow bindings creates a lot of complexity when it comes to
managing the flows. For example sender has to determine the overlaps and
specify correct priority of each flow binding and similarly the receiver
will also be taking care of priorities while installing the filters.
This situation gets worse as number of flow bindings grows. In my
opinion leaving priority out and using chronological order of filters at
the receiving end will make things more simple and easy for practical
        
use.

=> I think we need to be careful when we discuss features in terms of
"simple" and "complex". You need to look at what you lose to make it
simple
to implement. In this case you lose a major function that handles
overlaps.
This is fundamental to any filtering. It's ok to have complex algorithms,
it's not like the user will know anything. If we didn't have complex
features there would be no google :).

      
Secondly, I am not a fan  of n-casting option. Such mechanisms of
diversity work better at lower layers therefore when lower layers are
already making use of diversity then redoing it at network layer does
seems very attractive to me.
However these are just opinions from my side and i invite other working
group members to comment on it.
        
=> I have to  agree with Stuart's comment here. Lower layers have nothing
to
do with this. This is an e2e feature.

Hesham

      
Have a nice weekend,
Kind Regards,
        
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
      


_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
--------------000400060109080807080508-- --===============0485889051== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0485889051==-- From mext-bounces@ietf.org Tue Nov 18 11:28:32 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130953A6B0B; Tue, 18 Nov 2008 11:28:32 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDB743A6B0B for ; Tue, 18 Nov 2008 11:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.608 X-Spam-Level: X-Spam-Status: No, score=-104.608 tagged_above=-999 required=5 tests=[AWL=1.992, BAYES_00=-2.599, 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 5bNwDk8EsMEz for ; Tue, 18 Nov 2008 11:28:29 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id BFECB3A6808 for ; Tue, 18 Nov 2008 11:28:29 -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=1227036509; x=1258572509; 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"Giaretta,=20Gerardo"=20 |To:=20Hesham=20Soliman=20,=20" mext@ietf.org"=20|Date:=20Tue,=2018=20Nov =202008=2011:28:18=20-0800|Subject:=20Review=20of=20draft -ietf-mext-flow-binding-00|Thread-Topic:=20Review=20of=20 draft-ietf-mext-flow-binding-00|Thread-Index:=20AclJs89bc BiRkrJjTv2LlTc6LF1dLA=3D=3D|Message-ID:=20<057632CE4CE10D 45A1A3D6D19206C3A3D6CA01D2@NASANEXMB08.na.qualcomm.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"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5437"=3B=20a=3D"13269303"; bh=Ml1Q8V0+RQ/rjDBnF1JypZ0ZjFkGVqwtTZcdY3y7rAQ=; b=BMWGtqUzygMNJRyoUqU+78KlF66/BEe8pwOA4OUHOG1BYppP8MZgcUhQ WNUTtd8u2qb6AizaFROkyF1LixCT4pGsK6Sr+JSQmAHCIce3l8LEJWsuv DO9/LwrprN02kGIOy6zmETEK59ZJ3KRxi7XDaN9+0hMEv4ZswOmS8IpP2 Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5437"; a="13269303" 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; 18 Nov 2008 11:28:29 -0800 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAIJSSvd010973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Nov 2008 11:28:28 -0800 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAIJSSJ7007059 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 18 Nov 2008 11:28:28 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.132]) by nasanexhub06.na.qualcomm.com ([129.46.134.254]) with mapi; Tue, 18 Nov 2008 11:28:28 -0800 From: "Giaretta, Gerardo" To: Hesham Soliman , "mext@ietf.org" Date: Tue, 18 Nov 2008 11:28:18 -0800 Thread-Topic: Review of draft-ietf-mext-flow-binding-00 Thread-Index: AclJs89bcBiRkrJjTv2LlTc6LF1dLA== Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D6CA01D2@NASANEXMB08.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [MEXT] Review of draft-ietf-mext-flow-binding-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, All, I went through draft-ietf-mext-flow-binding-00. I think the draft is very well written and quite stable to be a 00 version. However there are some issues that need to be resolved in particular based on the latest version of the MCoA draft. First issue is that the draft has expired :-) 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 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 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 which 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 grouped 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 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 binding with match-all filters 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 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 also 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 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 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 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 - 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 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From irs@irs.gov Tue Nov 18 12:45:04 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 232613A6895; Tue, 18 Nov 2008 12:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -65.16 X-Spam-Level: X-Spam-Status: No, score=-65.16 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_99=3.5, FORGED_MUA_OUTLOOK=3.116, FORGED_OUTLOOK_HTML=0.001, FORGED_OUTLOOK_TAGS=0.001, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, MSOE_MID_WRONG_CASE=0.82, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_BLACK=20, URIBL_PH_SURBL=1.787, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mB806BJAW+Lp; Tue, 18 Nov 2008 12:45:03 -0800 (PST) Received: from IM.nrgnetworks.com (mail.barefootcontessa.com [204.13.26.251]) by core3.amsl.com (Postfix) with ESMTP id 0DD8E3A677C; Tue, 18 Nov 2008 12:45:01 -0800 (PST) Received: from User [213.195.77.112] by barefootcontessa.com with ESMTP (SMTPD-10.01) id A9350294; Tue, 18 Nov 2008 15:44:37 -0500 Reply-To: From: "Internal Revenue Service" Subject: Please submit your Stimulus Payment online form Date: Tue, 18 Nov 2008 13:44:41 -0700 MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <200811181544975.SM05816@User> X-Declude-Sender: irs@irs.gov [213.195.77.112] X-Declude-Spoolname: D293100da0000ab1f.smd X-Declude-Note: Scanned by Declude 3.1.3 for spam. "http://www.declude.com/x-note.htm" X-Declude-Scan: Score [0] at 15:44:45 on 18 Nov 2008 X-Declude-Fail: None X-Country-Chain: To: undisclosed-recipients:; From mext-bounces@ietf.org Tue Nov 18 13:26:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBA5B3A6A24; Tue, 18 Nov 2008 13:26:03 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99D893A6A24 for ; Tue, 18 Nov 2008 13:26:02 -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 MCw8QuTox4UC for ; Tue, 18 Nov 2008 13:26:01 -0800 (PST) Received: from mail.critical.com (mail.critical.com [64.246.137.41]) by core3.amsl.com (Postfix) with ESMTP id 677633A6809 for ; Tue, 18 Nov 2008 13:26:01 -0800 (PST) Received: by mail.critical.com (Postfix, from userid 48) id 926993BC0E7; Tue, 18 Nov 2008 16:26:04 -0500 (EST) Received: from 128.230.32.38 (SquirrelMail authenticated user cardsw) by www.critical.com with HTTP; Tue, 18 Nov 2008 16:26:04 -0500 (EST) Message-ID: <17492.128.230.32.38.1227043564.squirrel@www.critical.com> Date: Tue, 18 Nov 2008 16:26:04 -0500 (EST) From: "Stuart W. Card" To: In-Reply-To: <49231705.9020406@ericsson.com> References: <49231705.9020406@ericsson.com> X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.10) MIME-Version: 1.0 Cc: mext@ietf.org Subject: [MEXT] draft-larsson-mext-flow-distribution-rules-01.txt comments (was: draft-ietf-mext-flow-binding-00.txt - comments) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stu.card@critical.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org hesham@elevatemobile.com wrote -- >> => Filters are not included in this draft at all. The WG decided to do >> this in a separate draft. conny.larsson@ericsson.com wrote -- > And the draft describing how this can be done is > http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rules-01.txt I hadn't reviewed the latter draft before. Thank you for pointing it out. It looks like it may become very useful in my team's work. My comments follow. >From that draft: > 5.4. Conditional Rule-Sets > > For some scenarios, it is useful to install or transmit a collection > of rule-sets at the same time, and select which one to use depending > on what PIDs are available. How the set of available PIDs is > determined is outside the scope of this document. and: > 5.14. Round-robin > > For load-sharing purposes, round-robin transmission is supported. To > use round-robin, a list of PIDs is given instead of just one: > > udp peer 2001:db8:1c32::/48 port 44100 on 4, 4, 5 > > Here, UDP traffic from port 44100 at any node in prefix 2001:db8: > 1c32::/48 will be sent on PIDs 4 and 5. Two out of three packets > will go on PID 4, which presumably has twice the bandwidth of PID 5. These specs make sense iff: a PID is either available, or not; and coarse granularity in bandwidth allocation is adequate. However, a path may be 'available', but currently degraded. Or paths may simply have bandwidth that is highly variable. Likewise different paths may have slightly different bandwidths. In bandwidth constrained mobile wireless environments, I don't want to fail to use a path at all, just because it is degraded somewhat at the moment; but neither can I pump its full normal load of packets. What is needed is recognition that a path may be neither simply 'up' nor simply 'down', but in between (see IEEE 802.21 work, which starts to recognize this). Conditionals need to be able to consider quantitative thresholds. It would be even nicer if rules could be fuzzy, with grades of predicate truth and consequent rule firing activity, but that may be asking too much at this stage. Likewise variables that can pass capability information are needed. Then if I have PID 1 and PID 2, each of which is nominally 10 Mbps: if both are performing nominally, I want to balance 50%:50%; if PID 2 is completely down, I want to balance 100%:0%; and if PID 1 is running half its normal rate, I want to balance 33%:67%. Does anyone else out there have an interest in such subtle variations: between capabilities of different paths at the same time; and of the capabilities of a single path over time? We have actually been doing this for some time, but in a proprietary way; I would like to generalize it and base it on open standards. Thanks all! -- Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 www.critical.com _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 18 15:21:21 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB74728C19B; Tue, 18 Nov 2008 15:21:21 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFD5E3A6945 for ; Tue, 18 Nov 2008 15:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.117 X-Spam-Level: * X-Spam-Status: No, score=1.117 tagged_above=-999 required=5 tests=[AWL=1.207, 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 wXpXLYKV7LVM for ; Tue, 18 Nov 2008 15:21:19 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by core3.amsl.com (Postfix) with ESMTP id BFAAC3A6B2A for ; Tue, 18 Nov 2008 15:21:18 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.195]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id mAINLHke002111 for ; Wed, 19 Nov 2008 08:21:17 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id mAINLHm17041 for mext@ietf.org; Wed, 19 Nov 2008 08:21:17 +0900 (JST) Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id mAINLGSK026477 for ; Wed, 19 Nov 2008 08:21:16 +0900 (JST) Received: from matabe.jp.nec.com ([10.26.220.20] [10.26.220.20]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-43157; Wed, 19 Nov 2008 08:20:04 +0900 Received: from [10.62.69.165] ([10.62.69.165] [10.62.69.165]) by mail.jp.nec.com with ESMTP; Wed, 19 Nov 2008 08:20:01 +0900 Message-ID: <49234D9F.6050707@az.jp.nec.com> Date: Wed, 19 Nov 2008 08:19:59 +0900 From: Jun AWANO User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: mext@ietf.org References: <4922655C.5000701@az.jp.nec.com> In-Reply-To: Subject: Re: [MEXT] some questions for revocation draft-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad and Guo, Thanks for your replies, I was able to understand. As Ahmad said, I can see PBA status, "6 Revocation Failed, MN is Attached" in the draft. However, the draft doesn't have the line to explain the case in which the status code should be used. I think adding the line to the draft could be useful for readers. As for the relation between R.Trigger Field and Handoff Indicator, Guo's mail also helped my understanding. Guo's mail said, IMHO, value of revocation trigger and value of handoff indicator may be mapped as following: Inter-MAG handoff - same Access Types<--> HI=3 Inter-MAG handoff - different Access Types<--> HI=2 Inter-MAG - Unknown Handoff <--> HI=4 About HI=1/5, there is no need to release resources. I appreciate your description. But I think mapping above might not always be correct. In case of HI=2(Handoff between two different interfaces of the mobile node), it could be R.Trigger=3(Inter-MAG handoff - same Access Types). In my understanding so far, anyway LMA can set R.Trigger appropriately according to its judgment by using ATT, HI and other conditions as per RFC5213. An additional question. Is the BRI sender required backoff upon retransmission? Or it it depending on implementation? BR, Jun Ahmad Muhanna wrote: > Hi Jun, > Please see comments inline. > > Regards, > Ahmad > > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Jun AWANO >> Sent: Tuesday, November 18, 2008 12:49 AM >> To: mext@ietf.org >> Subject: [MEXT] some questions for revocation draft-01 >> >> Hi all, >> >> I've read revocation draft-01 and had some questions. >> >> The 6th item of draft-01 section 10.1.1 says: >> " If the Revocation Trigger field in the received BRI message is set >> to "Inter-MAG - Unknown Handoff", the MAG use the mobility >> option(s) included in the BRI message to identify the mobile node >> binding and MUST validate that the mobile node is no longer >> attached to the MAG before sending a successful BRA message and >> deleting the resources associated with the mobile node binding." >> >> How the MAG should do? in case the MN is still attaching the MAG. >> I guess the MAG does nothing by receiving BRI. > [Ahmad] > When the MAG receives the BRI message and finds out the MN is still > attached to the MAG, the MAG should send a BRA with status "6 > Revocation Failed, MN is Attached". > >> The MAG may send PBU with lifetime set to zero after it by >> detaching MN as per section 6.9.1.4 of RFC5213, though. >> Right? > > [Ahmad] > I do not understand what you mean here? > If the MAG would send a PBU with lifetime zero, why just NOT send a > successful BRA. Any how, if the MAG sends a PBU with lifetime zero in > response to the BRI with R. Trigger is set to "Inter-MAG - Unknown > Handoff", the LMA should consider this PBU as a successful response to > the BRI. > >> A relation between a value of Revocation Trigger Field and a >> value of Handoff Indicator Option included in the (last >> received?) PBU is a little bit unclear. > [Ahmad] > What is NOT clear. I believe it is inline of RFC5213. > >> I think some values of Revocation Trigger are supposed to >> refer to the Handoff Indicator to work well. >> >> BR, >> Jun. >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 18 22:27:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF0B73A6951; Tue, 18 Nov 2008 22:27:26 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F32D93A63EC for ; Tue, 18 Nov 2008 22:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.603 X-Spam-Level: X-Spam-Status: No, score=-103.603 tagged_above=-999 required=5 tests=[AWL=-1.004, 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 cDopeHnKwlsb for ; Tue, 18 Nov 2008 22:27:25 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 08D3A3A6951 for ; Tue, 18 Nov 2008 22:27:24 -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=1227076044; x=1258612044; 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"Giaretta,=20Gerardo"=20 |To:=20"mext@ietf.org"=20|Date:=20Tue,=201 8=20Nov=202008=2022:27:23=20-0800|Subject:=20Flow=20descr iption=20in=20draft-ietf-mext-flow-binding|Thread-Topic: =20Flow=20description=20in=20draft-ietf-mext-flow-binding |Thread-Index:=20AQHJSg6bRgu8tmci+kmsgfy2lC8uCQ=3D=3D |Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3D6CC34D4@ NASANEXMB08.na.qualcomm.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"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5438"=3B=20a=3D"13261975"; bh=dWjDfzDoq+KfXGGyUtz/CUs6GSI9MQimY1LXlNUAxWo=; b=yu2GLwJLRioY+U3X+PC93dpna+JnHhgS9WxbPVcIE/SmbB53L9iG2JIc 2HFhFPG5+fIl08j9CnjEGvhsDdPc4PQDYGyriD+kUcjleHso6U96Wav4A uPypnMWu4S9KwKwpXZWb+9OveYpfRioil+E5rs9VRcdWCaTC8f9dWGsWT g=; X-IronPort-AV: E=McAfee;i="5100,188,5438"; a="13261975" 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 Nov 2008 22:27:24 -0800 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 mAJ6RNtA010146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 18 Nov 2008 22:27:24 -0800 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 mAJ6RNTk024974 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 18 Nov 2008 22:27:23 -0800 (PST) Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.132]) by nasanexhub04.na.qualcomm.com ([129.46.134.222]) with mapi; Tue, 18 Nov 2008 22:27:23 -0800 From: "Giaretta, Gerardo" To: "mext@ietf.org" Date: Tue, 18 Nov 2008 22:27:23 -0800 Thread-Topic: Flow description in draft-ietf-mext-flow-binding Thread-Index: AQHJSg6bRgu8tmci+kmsgfy2lC8uCQ== Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D6CC34D4@NASANEXMB08.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [MEXT] Flow description in draft-ietf-mext-flow-binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi all, the current version of draft-ietf-mext-flow-binding does not specify any type of flow description and leaves to other documents how to specify the filters which are installed by the UE at the HA. I think we should add a basic version of the Flow Description in this draft to support filters in binary form (5-tuples). We have already one draft for MCoA and one for Flow Binding which will very often be used together and are part of the same multihoming solution; adding yet another separate draft will have bad impacts on the readability of the specifications. Moreover the flow binding draft was scheduled to be sent to IESG October 2008 but we have not gone through the WGLC yet. This is the right time to add the Flow Description in this draft without adding much delay; waiting for another draft to be published may delay the work too much. I think the support of binary description of the filters is pretty straighforward and very well known in IETF. This seems to be also the most reasonable solution in cellular networks where we may want to save bandwidth. Obviously the FID optoin will still be Flow Description agnostic and other more sophisticated Filter Description can be defined in separate documents. What do people think? Chairs? Thanks Gerardo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Nov 19 10:25:11 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 191B83A6BB0; Wed, 19 Nov 2008 10:25:11 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2E883A6BB2 for ; Wed, 19 Nov 2008 10:25:08 -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 8OqlIE7a+rqb for ; Wed, 19 Nov 2008 10:25:05 -0800 (PST) Received: from mail.critical.com (mail.critical.com [64.246.137.41]) by core3.amsl.com (Postfix) with ESMTP id A68BE3A6AA7 for ; Wed, 19 Nov 2008 10:25:05 -0800 (PST) Received: by mail.critical.com (Postfix, from userid 48) id 9C6143BC0E6; Wed, 19 Nov 2008 13:25:07 -0500 (EST) Received: from 128.230.32.38 (SquirrelMail authenticated user cardsw) by www.critical.com with HTTP; Wed, 19 Nov 2008 13:25:07 -0500 (EST) Message-ID: <17871.128.230.32.38.1227119107.squirrel@www.critical.com> Date: Wed, 19 Nov 2008 13:25:07 -0500 (EST) From: "Stuart W. Card" To: In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D6CC34D4@NASANEXMB08.na.qualcomm.com> References: <057632CE4CE10D45A1A3D6D19206C3A3D6CC34D4@NASANEXMB08.na.qualcomm.com> X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.10) MIME-Version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stu.card@critical.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > ... > I think the support of binary description of the filters is pretty > straighforward and very well known in IETF. This seems to be also the > most reasonable solution in cellular networks where we may want to save > bandwidth... I often have to deal with _really_ slow media (2400 bps, half-duplex, with > 250 mS receive-transmit turnaround). So I have a great appreciation for efficient encodings. That said, I believe that generality, flexibility and extensibility are more important to overall efficiency than are the few dozen or even couple hundred bytes that are saved every few seconds or minutes by encoding flow descriptions in binary. So my point is, if we are confident that we can specify a general, flexible, extensible, binary flow description language, great... but I'd rather stick with inefficient ASCII encodings if aren't yet to the maturity level in our understanding of this problem that we can retain those essential characteristics in a binary encoding. Sorry to bore you all with fuzzy philosophical ramblings but I think the long- versus short-term efficiency tradeoff is point that should not be forgotten. Thanks! -- Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 www.critical.com _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Nov 19 10:48:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776D03A6BBD; Wed, 19 Nov 2008 10:48:51 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95C253A6BBD for ; Wed, 19 Nov 2008 10:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ylx0SIZa0d93 for ; Wed, 19 Nov 2008 10:48:48 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 811E53A6B8A for ; Wed, 19 Nov 2008 10:48:48 -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=1227120528; x=1258656528; 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:=20"stu.card@critical.com"=20 |CC:=20"mext@ietf.org"=20|Date:=20Wed,=201 9=20Nov=202008=2010:48:44=20-0800|Subject:=20RE:=20[MEXT] =20Flow=20description=20in=20draft-ietf-mext-flow-binding |Thread-Topic:=20[MEXT]=20Flow=20description=20in=20draft -ietf-mext-flow-binding|Thread-Index:=20AclKdDgkCnDV7615T Ge3b9Y7oNjlfgAApU7A|Message-ID:=20<057632CE4CE10D45A1A3D6 D19206C3A3D6CA02FD@NASANEXMB08.na.qualcomm.com> |References:=20<057632CE4CE10D45A1A3D6D19206C3A3D6CC34D4@ NASANEXMB08.na.qualcomm.com>=0D=0A=20<17871.128.230.32.38 .1227119107.squirrel@www.critical.com>|In-Reply-To:=20<17 871.128.230.32.38.1227119107.squirrel@www.critical.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"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5439"=3B=20a=3D"13303221"; bh=WQoxkKqM6HGEUIGkFv96PoVIIgwdL1pxQXanqyg4fOc=; b=CNpkmvwIkOhwmU+yW/QSLZetzHbrvXVu2Kwuag0NWjDK1ASmWFbSw0fX EAUUr5rdnrMBtyT3Ki6+K5Q/AiTPgTyFOqpo3S/2gH40+P1XhwPA2msSj zofxHwHxkZRp+tH9tK/xsnv4np9rNE2lQ1uWVFcxUzX/HsajgSo8PaWc+ 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5439"; a="13303221" 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; 19 Nov 2008 10:48:47 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAJImlZV031041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Nov 2008 10:48:47 -0800 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 mAJImkTV014926 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Nov 2008 10:48:47 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.132]) by nasanexhub01.na.qualcomm.com ([10.46.93.121]) with mapi; Wed, 19 Nov 2008 10:48:46 -0800 From: "Giaretta, Gerardo" To: "stu.card@critical.com" Date: Wed, 19 Nov 2008 10:48:44 -0800 Thread-Topic: [MEXT] Flow description in draft-ietf-mext-flow-binding Thread-Index: AclKdDgkCnDV7615TGe3b9Y7oNjlfgAApU7A Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D6CA02FD@NASANEXMB08.na.qualcomm.com> References: <057632CE4CE10D45A1A3D6D19206C3A3D6CC34D4@NASANEXMB08.na.qualcomm.com> <17871.128.230.32.38.1227119107.squirrel@www.critical.com> In-Reply-To: <17871.128.230.32.38.1227119107.squirrel@www.critical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I definitely agree with you on the importance of long term and flexible solutions. My point is that there are probably different scenarios with different requirements and in some of them it makes sense to use binary encoding (which is less flexible but more efficient) and in some other it makes sense to use ASCII-based encoding. What I would like to avoid is to not have any of those in the current draft. At least one of these should be specified in the base draft in order to have a complete solution. I think we should go for the binary solution (which was originally part of the I-D indeed) as it requires less work and can be seen as the basic solution. In the meanwhile we can focus on an ASCII-based solution which is more flexible but would require some more work. Gerardo > -----Original Message----- > From: Stuart W. Card [mailto:stu.card@critical.com] > Sent: Wednesday, November 19, 2008 10:25 AM > To: Giaretta, Gerardo > Cc: mext@ietf.org > Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding > > > > ... > > I think the support of binary description of the filters is pretty > > straighforward and very well known in IETF. This seems to be also the > > most reasonable solution in cellular networks where we may want to save > > bandwidth... > > I often have to deal with _really_ slow media (2400 bps, > half-duplex, with > 250 mS receive-transmit turnaround). > So I have a great appreciation for efficient encodings. > > That said, I believe that generality, flexibility and > extensibility are more important to overall efficiency > than are the few dozen or even couple hundred bytes that > are saved every few seconds or minutes by encoding > flow descriptions in binary. > > So my point is, if we are confident that we can specify > a general, flexible, extensible, binary flow description > language, great... but I'd rather stick with inefficient > ASCII encodings if aren't yet to the maturity level in > our understanding of this problem that we can retain > those essential characteristics in a binary encoding. > > Sorry to bore you all with fuzzy philosophical ramblings > but I think the long- versus short-term efficiency tradeoff > is point that should not be forgotten. Thanks! > > -- > Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. > * Creativity * Diversity * Expertise * Flexibility * Integrity * > Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 > 315-793-0248 x141 FAX -9710 www.critical.com > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Nov 19 11:00:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BD7E28C0CE; Wed, 19 Nov 2008 11:00:18 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357B928C0CE for ; Wed, 19 Nov 2008 11:00:17 -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 g2DXSINevZVF for ; Wed, 19 Nov 2008 11:00:16 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 58F133A6782 for ; Wed, 19 Nov 2008 11:00:15 -0800 (PST) Received: from [12.167.162.5] (helo=[172.17.199.160]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1L2sHb-0007Pa-Fg; Thu, 20 Nov 2008 06:00:12 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Thu, 20 Nov 2008 06:00:05 +1100 From: Hesham Soliman To: "Giaretta, Gerardo" , "mext@ietf.org" Message-ID: Thread-Topic: [MEXT] Flow description in draft-ietf-mext-flow-binding Thread-Index: AQHJSg6bRgu8tmci+kmsgfy2lC8uCY8CXfOv In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D6CC34D4@NASANEXMB08.na.qualcomm.com> Mime-version: 1.0 Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I don't have a problem adding it Gerardo if people are happy with that. Hesham On 19/11/08 5:27 PM, "Giaretta, Gerardo" wrote: > Hi all, > > the current version of draft-ietf-mext-flow-binding does not specify any type > of flow description and leaves to other documents how to specify the filters > which are installed by the UE at the HA. > > I think we should add a basic version of the Flow Description in this draft to > support filters in binary form (5-tuples). We have already one draft for MCoA > and one for Flow Binding which will very often be used together and are part > of the same multihoming solution; adding yet another separate draft will have > bad impacts on the readability of the specifications. > > Moreover the flow binding draft was scheduled to be sent to IESG October 2008 > but we have not gone through the WGLC yet. This is the right time to add the > Flow Description in this draft without adding much delay; waiting for another > draft to be published may delay the work too much. > > I think the support of binary description of the filters is pretty > straighforward and very well known in IETF. This seems to be also the most > reasonable solution in cellular networks where we may want to save bandwidth. > Obviously the FID optoin will still be Flow Description agnostic and other > more sophisticated Filter Description can be defined in separate documents. > > What do people think? Chairs? > > Thanks > Gerardo > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Nov 19 11:25:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A23383A6997; Wed, 19 Nov 2008 11:25:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F7B73A69B5 for ; Wed, 19 Nov 2008 11:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 V0vXPv8tKPCh for ; Wed, 19 Nov 2008 11:25:46 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 594BA3A6912 for ; Wed, 19 Nov 2008 11:25:46 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 66BAD217A5; Wed, 19 Nov 2008 20:25:44 +0100 (CET) X-AuditID: c1b4fb3e-af787bb00000537b-2d-49246838c1f7 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 378CA21181; Wed, 19 Nov 2008 20:25:44 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 20:25:43 +0100 Received: from [127.0.0.1] ([153.88.44.149]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 20:25:42 +0100 Message-ID: <49246832.30701@ericsson.com> Date: Wed, 19 Nov 2008 13:25:38 -0600 From: Conny Larsson User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: <057632CE4CE10D45A1A3D6D19206C3A3D6CC34D4@NASANEXMB08.na.qualcomm.com> <17871.128.230.32.38.1227119107.squirrel@www.critical.com> <057632CE4CE10D45A1A3D6D19206C3A3D6CA02FD@NASANEXMB08.na.qualcomm.com> In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D6CA02FD@NASANEXMB08.na.qualcomm.com> X-OriginalArrivalTime: 19 Nov 2008 19:25:42.0926 (UTC) FILETIME=[9D1F8AE0:01C94A7C] X-Brightmail-Tracker: AAAAAA== Cc: "mext@ietf.org" Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1502143440==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1502143440== Content-Type: multipart/alternative; boundary="------------060700060903020306050306" This is a multi-part message in MIME format. --------------060700060903020306050306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Gerardo, I have difficulties to comment on your flexibility/efficiency statement since I have not implemented any of the solutions (binary encoding/ASCII-based encoding). However, one of my colleagues has made an implementation of the ASCII-based solution, as specified in http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rules-01.txt, and according to him it was easy to implement and caused no major problems. We even have a prototype on Linux up and running and it works perfectly well for distributing flows simultaneously among three different interfaces. You are saying "What I would like to avoid is to not have any of those in the current draft. At least one of these should be specified in the base draft in order to have a complete solution.". Could you please elaborate a little bit more why you think draft-larsson-mext-flow-distribution-rules would not do the work sufficiently? My proposal is of course to specify a reference to draft-larsson and get a flexible solution from the beginning. Regards Conny Giaretta, Gerardo wrote: > I definitely agree with you on the importance of long term and flexible solutions. My point is that there are probably different scenarios with different requirements and in some of them it makes sense to use binary encoding (which is less flexible but more efficient) and in some other it makes sense to use ASCII-based encoding. > > What I would like to avoid is to not have any of those in the current draft. At least one of these should be specified in the base draft in order to have a complete solution. I think we should go for the binary solution (which was originally part of the I-D indeed) as it requires less work and can be seen as the basic solution. In the meanwhile we can focus on an ASCII-based solution which is more flexible but would require some more work. > > Gerardo > > >> -----Original Message----- >> From: Stuart W. Card [mailto:stu.card@critical.com] >> Sent: Wednesday, November 19, 2008 10:25 AM >> To: Giaretta, Gerardo >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding >> >> >> >>> ... >>> I think the support of binary description of the filters is pretty >>> straighforward and very well known in IETF. This seems to be also the >>> most reasonable solution in cellular networks where we may want to save >>> bandwidth... >>> >> I often have to deal with _really_ slow media (2400 bps, >> half-duplex, with > 250 mS receive-transmit turnaround). >> So I have a great appreciation for efficient encodings. >> >> That said, I believe that generality, flexibility and >> extensibility are more important to overall efficiency >> than are the few dozen or even couple hundred bytes that >> are saved every few seconds or minutes by encoding >> flow descriptions in binary. >> >> So my point is, if we are confident that we can specify >> a general, flexible, extensible, binary flow description >> language, great... but I'd rather stick with inefficient >> ASCII encodings if aren't yet to the maturity level in >> our understanding of this problem that we can retain >> those essential characteristics in a binary encoding. >> >> Sorry to bore you all with fuzzy philosophical ramblings >> but I think the long- versus short-term efficiency tradeoff >> is point that should not be forgotten. Thanks! >> >> -- >> Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. >> * Creativity * Diversity * Expertise * Flexibility * Integrity * >> Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 >> 315-793-0248 x141 FAX -9710 www.critical.com >> >> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > --------------060700060903020306050306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Gerardo,

I have difficulties to comment on your flexibility/efficiency statement since I have not implemented any of the solutions (binary encoding/ASCII-based encoding). However, one of my colleagues has made an implementation of the ASCII-based solution, as specified in http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rules-01.txt, and according to him it was easy to implement and caused no major problems. We even have a prototype on Linux up and running and it works perfectly well for distributing flows simultaneously among three different interfaces.

You are saying "What I would like to avoid is to not have any of those in the current draft. At least one of these should be specified in the base draft in order to have a complete solution.". Could you please elaborate a little bit more why you think draft-larsson-mext-flow-distribution-rules would not do the work sufficiently?

My proposal is of course to specify a reference to draft-larsson and get a flexible solution from the beginning.

Regards
Conny


Giaretta, Gerardo wrote: 
I definitely agree with you on the importance of long term and flexible solutions. My point is that there are probably different scenarios with different requirements and in some of them it makes sense to use binary encoding (which is less flexible but more efficient) and in some other it makes sense to use ASCII-based encoding. 

What I would like to avoid is to not have any of those in the current draft. At least one of these should be specified in the base draft in order to have a complete solution. I think we should go for the binary solution (which was originally part of the I-D indeed) as it requires less work and can be seen as the basic solution. In the meanwhile we can focus on an ASCII-based solution which is more flexible but would require some more work.

Gerardo

  
-----Original Message-----
From: Stuart W. Card [mailto:stu.card@critical.com]
Sent: Wednesday, November 19, 2008 10:25 AM
To: Giaretta, Gerardo
Cc: mext@ietf.org
Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding


    
...
I think the support of binary description of the filters is pretty
straighforward and very well known in IETF. This seems to be also the
most reasonable solution in cellular networks where we may want to save
bandwidth...
      
I often have to deal with _really_ slow media (2400 bps,
half-duplex, with > 250 mS receive-transmit turnaround).
So I have a great appreciation for efficient encodings.

That said, I believe that generality, flexibility and
extensibility are more important to overall efficiency
than are the few dozen or even couple hundred bytes that
are saved every few seconds or minutes by encoding
flow descriptions in binary.

So my point is, if we are confident that we can specify
a general, flexible, extensible, binary flow description
language, great... but I'd rather stick with inefficient
ASCII encodings if aren't yet to the maturity level in
our understanding of this problem that we can retain
those essential characteristics in a binary encoding.

Sorry to bore you all with fuzzy philosophical ramblings
but I think the long- versus short-term efficiency tradeoff
is point that should not be forgotten. Thanks!

--
Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc.
* Creativity * Diversity * Expertise * Flexibility * Integrity *
Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501
315-793-0248 x141 FAX -9710 <Stu.Card@critical.com> www.critical.com


    

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
--------------060700060903020306050306-- --===============1502143440== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1502143440==-- From mext-bounces@ietf.org Wed Nov 19 12:44:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CF483A6959; Wed, 19 Nov 2008 12:44:03 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B74C3A6959 for ; Wed, 19 Nov 2008 12:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-85sToWj7kF for ; Wed, 19 Nov 2008 12:43:57 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id CBBD33A6782 for ; Wed, 19 Nov 2008 12:43:57 -0800 (PST) Received: from LENOVO ([130.129.94.244]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1L2ttv1e3X-0001QD; Wed, 19 Nov 2008 15:43:56 -0500 From: "Alper Yegin" To: , Date: Wed, 19 Nov 2008 22:43:51 +0200 Message-ID: <025e01c94a87$8ab61940$a0224bc0$@yegin@yegin.org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclKh4ar6kmSW8MBSYKezX5nrEU97w== Content-Language: en-us X-Provags-ID: V01U2FsdGVkX18oQUv+7eO421nrzztVGtBaHjuUTTtjDbjoMAg PDnM069hZl375wwp+pdHHoAXZRNSVNW7I8aO+3lJUOqn4DOCtF PUG04tPIsYCRNOb6GVJ1g== Subject: [MEXT] issue 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: , Content-Type: multipart/mixed; boundary="===============1826997678==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multipart message in MIME format. --===============1826997678== Content-Type: multipart/alternative; boundary="----=_NextPart_000_025F_01C94A98.4E3EE940" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_025F_01C94A98.4E3EE940 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Following the discussions we had on the reflector, I think the RFC 3775bis needs improvement for use of Alt-CoA option and BA destination address. The spec clearly states that the BA is sent back to the source IP address of the BU (not to CoA, which may be different when Alt CoA is used): If the Source Address field of the IPv6 header that carried the Binding Update does not contain a unicast address, the Binding Acknowledgement MUST NOT be sent and the Binding Update packet MUST be silently discarded. Otherwise, the acknowledgement MUST be sent to the Source Address. I'm not sure if this deserves additional clarification/specification text. Vijay believes there is an issue in the absence of further text that talks about how HA stores the source IP address of the last received BU. I agree that is needed for revocation spec and it can be specified there as one option. Any thoughts? Is there anything we need to do in RFC 3775bis? Alper ------=_NextPart_000_025F_01C94A98.4E3EE940 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Following the discussions we had on the reflector, = I think the RFC 3775bis needs improvement for use of Alt-CoA option and BA = destination address.

 

 

The spec clearly states that the BA is sent back to = the source IP address of the BU (not to CoA, which may be different when Alt = CoA is used):

 

   If the Source Address field of the IPv6 header that carried = the

   Binding Update does not contain a unicast address, the = Binding

   Acknowledgement MUST NOT be sent and the Binding Update packet = MUST

   be silently discarded.  Otherwise, the acknowledgement MUST be = sent

   to the Source Address.

 

 

I’m not sure if this deserves additional clarification/specification text. Vijay believes there is an issue in = the absence of further text that talks about how HA stores the source IP = address of the last received BU. I agree that is needed for revocation spec and it = can be specified there as one option.

 

Any thoughts? Is there anything we need to do in = RFC 3775bis?

 


Alper

 

 

 

 

 

 

------=_NextPart_000_025F_01C94A98.4E3EE940-- --===============1826997678== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1826997678==-- From mext-bounces@ietf.org Wed Nov 19 13:15:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AD633A6824; Wed, 19 Nov 2008 13:15:52 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293863A6824 for ; Wed, 19 Nov 2008 13:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 mbnOFYvhvOfm for ; Wed, 19 Nov 2008 13:15:43 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 3CE003A67D6 for ; Wed, 19 Nov 2008 13:15:43 -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=1227129341; x=1258665341; 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: x-cr-puzzleid:x-cr-hashedpuzzle:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Conny=20Larsson=20|CC: =20"stu.card@critical.com"=20,=0D =0A=20=20=20=20=20=20=20=20"mext@ietf.org"=0D=0A=09|Date:=20Wed,=2019=20Nov=202008=2013:15:17=20-08 00|Subject:=20RE:=20[MEXT]=20Flow=20description=20in=20dr aft-ietf-mext-flow-binding|Thread-Topic:=20[MEXT]=20Flow =20description=20in=20draft-ietf-mext-flow-binding |Thread-Index:=20AclKfKZuTwzaPdpiTpWgXcJ7w8CorgADvReQ |Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3D6CA0338@ NASANEXMB08.na.qualcomm.com>|References:=20<057632CE4CE10 D45A1A3D6D19206C3A3D6CC34D4@NASANEXMB08.na.qualcomm.com> =0D=0A=09<17871.128.230.32.38.1227119107.squirrel@www.cri tical.com>=0D=0A=20<057632CE4CE10D45A1A3D6D19206C3A3D6CA0 2FD@NASANEXMB08.na.qualcomm.com>=0D=0A=20<49246832.30701@ ericsson.com>|In-Reply-To:=20<49246832.30701@ericsson.com >|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|x-cr-puzzleid:=20 {17D20671-DD85-4FCA-A1C6-E53B8E40883B}|x-cr-hashedpuzzle: =20L2U=3D=20FzoM=20H/35=20KW5u=20MrP5=20NHvZ=20NYax=20NyQ l=20OC9h=20OsbA=20PX5E=0D=0A=20Pzgn=20RXJj=20Rxam=20WnYD =0D=0A=20kfXn=3B3=3BYwBvAG4AbgB5AC4AbABhAHIAcwBzAG8AbgBAA GUAcgBpAGMAcwBzAG8AbgAuAGMAbwBtADsAbQBlAHgAdABAAGkAZQB0AG YALgBvAHIAZwA7AHMAdAB1AC4AYwBhAHIAZABAAGMAcgBpAHQAaQBjAGE AbAAuAGMAbwBtAA=3D=3D=3BSosha1_v1=3B7=3B{17D20671-DD85-4F CA-A1C6-E53B8E40883B}=3BZwBlAHIAYQByAGQAbwBnAEAAcQB1AGEAb ABjAG8AbQBtAC4AYwBvAG0A=3BWed,=0D=0A=2019=20Nov=202008=20 21:15:17=0D=0A=20GMT=3BUgBFADoAIABbAE0ARQBYAFQAXQAgAEYAbA BvAHcAIABkAGUAcwBjAHIAaQBwAHQAaQBvAG4AIABpAG4AIABkAHIAYQB mAHQALQBpAGUAdABmAC0AbQBlAHgAdAAtAGYAbABvAHcALQBiAGkAbgBk AGkAbgBnAA=3D=3D|acceptlanguage:=20en-US|Content-Type:=20 multipart/alternative=3B=0D=0A=09boundary=3D"_000_057632C E4CE10D45A1A3D6D19206C3A3D6CA0338NASANEXMB08naqu_" |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5439"=3B=20a=3D"13308784"; bh=7f9TROfE+IuB/96RMp8jLzjFFSoDv0oPdl4XLxbgKck=; b=WiOIJibpH7g1NTkomPfCwbTaa7npnxVvI/OPdOqMrJgdH0A9cupv9rab QofeVVZjGkdGeYvAd1X7orSkM/mg+vJcbg3XUrg4a5dftgq/5/KXVMz8o /u9+ozRsysYYXrsLTWWPIXZ8mZBxIfNS+anMHiutkNnLefaxgKjvUtBML Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5439"; a="13308784" 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; 19 Nov 2008 13:15:41 -0800 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 mAJLFfLr030118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Nov 2008 13:15:41 -0800 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 mAJLFTHO015924 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Nov 2008 13:15:41 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.132]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Wed, 19 Nov 2008 13:15:28 -0800 From: "Giaretta, Gerardo" To: Conny Larsson Date: Wed, 19 Nov 2008 13:15:17 -0800 Thread-Topic: [MEXT] Flow description in draft-ietf-mext-flow-binding Thread-Index: AclKfKZuTwzaPdpiTpWgXcJ7w8CorgADvReQ Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D6CA0338@NASANEXMB08.na.qualcomm.com> References: <057632CE4CE10D45A1A3D6D19206C3A3D6CC34D4@NASANEXMB08.na.qualcomm.com> <17871.128.230.32.38.1227119107.squirrel@www.critical.com> <057632CE4CE10D45A1A3D6D19206C3A3D6CA02FD@NASANEXMB08.na.qualcomm.com> <49246832.30701@ericsson.com> In-Reply-To: <49246832.30701@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {17D20671-DD85-4FCA-A1C6-E53B8E40883B} x-cr-hashedpuzzle: L2U= FzoM H/35 KW5u MrP5 NHvZ NYax NyQl OC9h OsbA PX5E Pzgn RXJj Rxam WnYD kfXn; 3; YwBvAG4AbgB5AC4AbABhAHIAcwBzAG8AbgBAAGUAcgBpAGMAcwBzAG8AbgAuAGMAbwBtADsAbQBlAHgAdABAAGkAZQB0AGYALgBvAHIAZwA7AHMAdAB1AC4AYwBhAHIAZABAAGMAcgBpAHQAaQBjAGEAbAAuAGMAbwBtAA==; Sosha1_v1; 7; {17D20671-DD85-4FCA-A1C6-E53B8E40883B}; ZwBlAHIAYQByAGQAbwBnAEAAcQB1AGEAbABjAG8AbQBtAC4AYwBvAG0A; Wed, 19 Nov 2008 21:15:17 GMT; UgBFADoAIABbAE0ARQBYAFQAXQAgAEYAbABvAHcAIABkAGUAcwBjAHIAaQBwAHQAaQBvAG4AIABpAG4AIABkAHIAYQBmAHQALQBpAGUAdABmAC0AbQBlAHgAdAAtAGYAbABvAHcALQBiAGkAbgBkAGkAbgBnAA== acceptlanguage: en-US MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1513387359==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1513387359== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_057632CE4CE10D45A1A3D6D19206C3A3D6CA0338NASANEXMB08naqu_" --_000_057632CE4CE10D45A1A3D6D19206C3A3D6CA0338NASANEXMB08naqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Conny, I think the point is that binary encoding is more bandwidth efficient. If w= e consider 3GPP as an example, the binary encoding is used for QoS reservat= ions and requests. In my view we could use a similar binary encoding also f= or flow mobility and document that in the basic draft. I see the argument of flexibility but this comes to a cost. Pointing to dra= ft-larsson for more flexible encoding is fine to me but I don't think that = should be the basic model. Cheers Gerardo From: Conny Larsson [mailto:conny.larsson@ericsson.com] Sent: Wednesday, November 19, 2008 11:26 AM To: Giaretta, Gerardo Cc: stu.card@critical.com; mext@ietf.org Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding Hi Gerardo, I have difficulties to comment on your flexibility/efficiency statement sin= ce I have not implemented any of the solutions (binary encoding/ASCII-based= encoding). However, one of my colleagues has made an implementation of the= ASCII-based solution, as specified in http://tools.ietf.org/id/draft-larss= on-mext-flow-distribution-rules-01.txt, and according to him it was easy to= implement and caused no major problems. We even have a prototype on Linux = up and running and it works perfectly well for distributing flows simultane= ously among three different interfaces. You are saying "What I would like to avoid is to not have any of those in t= he current draft. At least one of these should be specified in the base dra= ft in order to have a complete solution.". Could you please elaborate a lit= tle bit more why you think draft-larsson-mext-flow-distribution-rules would= not do the work sufficiently? My proposal is of course to specify a reference to draft-larsson and get a = flexible solution from the beginning. Regards Conny Giaretta, Gerardo wrote: I definitely agree with you on the importance of long term and flexible sol= utions. My point is that there are probably different scenarios with differ= ent requirements and in some of them it makes sense to use binary encoding = (which is less flexible but more efficient) and in some other it makes sens= e to use ASCII-based encoding. What I would like to avoid is to not have any of those in the current draft= . At least one of these should be specified in the base draft in order to h= ave a complete solution. I think we should go for the binary solution (whic= h was originally part of the I-D indeed) as it requires less work and can b= e seen as the basic solution. In the meanwhile we can focus on an ASCII-bas= ed solution which is more flexible but would require some more work. Gerardo -----Original Message----- From: Stuart W. Card [mailto:stu.card@critical.com] Sent: Wednesday, November 19, 2008 10:25 AM To: Giaretta, Gerardo Cc: mext@ietf.org Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding ... I think the support of binary description of the filters is pretty straighforward and very well known in IETF. This seems to be also the most reasonable solution in cellular networks where we may want to save bandwidth... I often have to deal with _really_ slow media (2400 bps, half-duplex, with > 250 mS receive-transmit turnaround). So I have a great appreciation for efficient encodings. That said, I believe that generality, flexibility and extensibility are more important to overall efficiency than are the few dozen or even couple hundred bytes that are saved every few seconds or minutes by encoding flow descriptions in binary. So my point is, if we are confident that we can specify a general, flexible, extensible, binary flow description language, great... but I'd rather stick with inefficient ASCII encodings if aren't yet to the maturity level in our understanding of this problem that we can retain those essential characteristics in a binary encoding. Sorry to bore you all with fuzzy philosophical ramblings but I think the long- versus short-term efficiency tradeoff is point that should not be forgotten. Thanks! -- Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 www.critical.com _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --_000_057632CE4CE10D45A1A3D6D19206C3A3D6CA0338NASANEXMB08naqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Conny,

 

I think the point is that binary encoding is more bandwidth = efficient. If we consider 3GPP as an example, the binary encoding is used for QoS reservations and requests. In my view we could use a similar binary encodin= g also for flow mobility and document that in the basic draft.

 

I see the argument of flexibility but this comes to a cost. Pointing to draft-larsson for more flexible encoding is fine to me but I do= n’t think that should be the basic model.

 

Cheers

Gerardo

 

From: Conny Larsson [mailto:conny.larsson@ericsson.com]
Sent: Wednesday, November 19, 2008 11:26 AM
To: Giaretta, Gerardo
Cc: stu.card@critical.com; mext@ietf.org
Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding=

 

Hi Gerardo,

I have difficulties to comment on your flexibility/efficiency statement sin= ce I have not implemented any of the solutions (binary encoding/ASCII-based encoding). However, one of my colleagues has made an implementation of the ASCII-based solution, as specified in http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rule= s-01.txt, and according to him it was easy to implement and caused no major problems.= We even have a prototype on Linux up and running and it works perfectly well f= or distributing flows simultaneously among three different interfaces.

You are saying "What I would like to avoid is to not have any of those= in the current draft. At least one of these should be specified in the base dr= aft in order to have a complete solution.". Could you please elaborate a little bit more why you think draft-larsson-mext-flow-distribution-rules wo= uld not do the work sufficiently?

My proposal is of course to specify a reference to draft-larsson and get a flexible solution from the beginning.

Regards
Conny


Giaretta, Gerardo wrote: 

I definitely agree with you on the importance of long term and flexibl=
e solutions. My point is that there are probably different scenarios with d=
ifferent requirements and in some of them it makes sense to use binary enco=
ding (which is less flexible but more efficient) and in some other it makes=
 sense to use ASCII-based encoding. 
 =

What I would like to avoid is to not have any of those in the cu=
rrent draft. At least one of these should be specified in the base draft in=
 order to have a complete solution. I think we should go for the binary sol=
ution (which was originally part of the I-D indeed) as it requires less wor=
k and can be seen as the basic solution. In the meanwhile we can focus on a=
n ASCII-based solution which is more flexible but would require some more w=
ork.
 
Gerardo
 
  



-----Origin=
al Message-----
From: Stuart W. Card [mailto:stu.card@critical.com]
Sent: Wednesday, November 19, 2008 10:25 AM
To: Giaretta, Gerardo
Cc: mext@ietf.org
Subjec=
t: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding
 
 
 &nbs=
p;  



...
I think the support of binary description of the filters is p=
retty
straighforward and very well known in IETF. This=
 seems to be also the
most reasonable solution in cell=
ular networks where we may want to save
bandwidth...
      



I often have to deal with _really_ slow media (2400 bps,
half-duplex, with > 250 mS receive-transmit turnaround).
So I have a great appreciation for efficient encodings.<=
/o:p>
 
That said, I believe that gener=
ality, flexibility and
extensibility are more importan=
t to overall efficiency
than are the few dozen or even=
 couple hundred bytes that
are saved every few seconds=
 or minutes by encoding
flow descriptions in binary.
 
So my point is, if we are c=
onfident that we can specify
a general, flexible, exte=
nsible, binary flow description
language, great... but=
 I'd rather stick with inefficient
ASCII encodings if =
aren't yet to the maturity level in
our understanding =
of this problem that we can retain
those essential cha=
racteristics in a binary encoding.
 
Sorry to bore you all with fuzzy philosophical ramblings
but I think the long- versus short-term efficiency tradeoff
is point that should not be forgotten. Thanks!=

 
--
Stuart W. Ca=
rd, Chief Scientist & VP, Critical Technologies Inc.
* Creativity * Diversity * Expertise * Flexibility * Integrity *
Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica N=
Y 13501
315-793-0248 x141 FAX -9710 <Stu.Card@critical.com> www.critical.com
=
 
 
    =




 
__________________________________________=
_____
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/mext
 
--_000_057632CE4CE10D45A1A3D6D19206C3A3D6CA0338NASANEXMB08naqu_-- --===============1513387359== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1513387359==-- From mext-bounces@ietf.org Wed Nov 19 13:22:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2CB3A6883; Wed, 19 Nov 2008 13:22:50 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EF303A687E for ; Wed, 19 Nov 2008 13:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 pGbXmwTbOGaE for ; Wed, 19 Nov 2008 13:22:36 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id DB5E63A687F for ; Wed, 19 Nov 2008 13:22:35 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mAJLMTLQ008200; Wed, 19 Nov 2008 23:22:32 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Nov 2008 23:22:05 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Nov 2008 23:22:05 +0200 Received: from 10.162.252.7 ([10.162.252.7]) by daebe104.NOE.Nokia.com ([10.241.36.13]) with Microsoft Exchange Server HTTP-DAV ; Wed, 19 Nov 2008 21:21:54 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Wed, 19 Nov 2008 15:21:56 -0600 From: Basavaraj Patil To: Giaretta Gerardo , Conny Larsson Message-ID: Thread-Topic: [MEXT] Flow description in draft-ietf-mext-flow-binding Thread-Index: AclKfKZuTwzaPdpiTpWgXcJ7w8CorgADvReQAABPp0k= In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D6CA0338@NASANEXMB08.na.qualcomm.com> Mime-version: 1.0 X-OriginalArrivalTime: 19 Nov 2008 21:22:05.0466 (UTC) FILETIME=[DF0A97A0:01C94A8C] X-Nokia-AV: Clean Cc: "mext@ietf.org" Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0641293781==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0641293781== Content-type: multipart/alternative; boundary="B_3309952917_7150820" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3309952917_7150820 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Gerardo, The bandwidth efficiency of binary encoding is true in general. However if you look at SIP for example, why did they choose to not specify it with binary encoding? There is value with the Ascii encoding model. I just don=B9t know if there is a need to be highly optimized here to choose the binary encoding format as the default. -Raj On 11/19/08 3:15 PM, "Giaretta Gerardo" wrote: > Hi Conny, > =20 > I think the point is that binary encoding is more bandwidth efficient. If= we > consider 3GPP as an example, the binary encoding is used for QoS reservat= ions > and requests. In my view we could use a similar binary encoding also for = flow > mobility and document that in the basic draft. > =20 > I see the argument of flexibility but this comes to a cost. Pointing to > draft-larsson for more flexible encoding is fine to me but I don=B9t think = that > should be the basic model. > =20 > Cheers > Gerardo > =20 >=20 > From: Conny Larsson [mailto:conny.larsson@ericsson.com] > Sent: Wednesday, November 19, 2008 11:26 AM > To: Giaretta, Gerardo > Cc: stu.card@critical.com; mext@ietf.org > Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding > =20 > Hi Gerardo, >=20 > I have difficulties to comment on your flexibility/efficiency statement s= ince > I have not implemented any of the solutions (binary encoding/ASCII-based > encoding). However, one of my colleagues has made an implementation of th= e > ASCII-based solution, as specified in > http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rules-01.tx= t, > and according to him it was easy to implement and caused no major problem= s. We > even have a prototype on Linux up and running and it works perfectly well= for > distributing flows simultaneously among three different interfaces. >=20 > You are saying "What I would like to avoid is to not have any of those in= the > current draft. At least one of these should be specified in the base draf= t in > order to have a complete solution.". Could you please elaborate a little = bit > more why you think draft-larsson-mext-flow-distribution-rules would not d= o the > work sufficiently? >=20 > My proposal is of course to specify a reference to draft-larsson and get = a > flexible solution from the beginning. >=20 > Regards > Conny >=20 >=20 > Giaretta, Gerardo wrote: > I definitely agree with you on the importance of long term and flexible > solutions. My point is that there are probably different scenarios with > different requirements and in some of them it makes sense to use binary > encoding (which is less flexible but more efficient) and in some other it > makes sense to use ASCII-based encoding. > =20 > What I would like to avoid is to not have any of those in the current dra= ft. > At least one of these should be specified in the base draft in order to h= ave a > complete solution. I think we should go for the binary solution (which wa= s > originally part of the I-D indeed) as it requires less work and can be se= en as > the basic solution. In the meanwhile we can focus on an ASCII-based solut= ion > which is more flexible but would require some more work. > =20 > Gerardo > =20 > =20 >> -----Original Message----- >> From: Stuart W. Card [mailto:stu.card@critical.com] >> Sent: Wednesday, November 19, 2008 10:25 AM >> To: Giaretta, Gerardo >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding >> =20 >> =20 >> =20 >>> ... >>> I think the support of binary description of the filters is pretty >>> straighforward and very well known in IETF. This seems to be also the >>> most reasonable solution in cellular networks where we may want to save >>> bandwidth... >>> =20 >> I often have to deal with _really_ slow media (2400 bps, >> half-duplex, with > 250 mS receive-transmit turnaround). >> So I have a great appreciation for efficient encodings. >> =20 >> That said, I believe that generality, flexibility and >> extensibility are more important to overall efficiency >> than are the few dozen or even couple hundred bytes that >> are saved every few seconds or minutes by encoding >> flow descriptions in binary. >> =20 >> So my point is, if we are confident that we can specify >> a general, flexible, extensible, binary flow description >> language, great... but I'd rather stick with inefficient >> ASCII encodings if aren't yet to the maturity level in >> our understanding of this problem that we can retain >> those essential characteristics in a binary encoding. >> =20 >> Sorry to bore you all with fuzzy philosophical ramblings >> but I think the long- versus short-term efficiency tradeoff >> is point that should not be forgotten. Thanks! >> =20 >> -- >> Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. >> * Creativity * Diversity * Expertise * Flexibility * Integrity * >> Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 >> 315-793-0248 x141 FAX -9710 >> www.critical.com >> =20 >> =20 >> =20 > =20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > =20 >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext --B_3309952917_7150820 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [MEXT] Flow description in draft-ietf-mext-flow-binding
Hi Gerardo,

The bandwidth efficiency of binary encoding is true in general.
However if you look at SIP for example, why did they choose to not specify = it with binary encoding?

There is value with the Ascii encoding model. I just don’t know if th= ere is a need to be highly optimized here to choose the binary encoding form= at as the default.

-Raj


On 11/19/08 3:15 PM, "Giaretta Gerardo" <gerardog@qualcomm.com> wrote:

Hi Conny,  
I think the point is that binary encoding is more bandwidth efficient. If w= e consider 3GPP as an example, the binary encoding is used for QoS reservati= ons and requests. In my view we could use a similar binary encoding also for= flow mobility and document that in the basic draft.
 
I see the argument of flexibility but this comes to a cost. Pointing to dra= ft-larsson for more flexible encoding is fine to me but I don’t think = that should be the basic model.
 
Cheers
Gerardo
 

From: Conny Larsson [mailto:conny.larsson@ericsson.com]
Sent: Wednesday, November 19, 2008 11:26 AM
To: Giaretta, Gerardo
Cc: stu.card@critical.com; mext@ietf.org
Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding=

Hi Gerardo,

I have difficulties to comment on your flexibility/efficiency statement sin= ce I have not implemented any of the solutions (binary encoding/ASCII-based = encoding). However, one of my colleagues has made an implementation of the A= SCII-based solution, as specified in http://tools.ietf.org/id/draft= -larsson-mext-flow-distribution-rules-01.txt, and according to him it wa= s easy to implement and caused no major problems. We even have a prototype o= n Linux up and running and it works perfectly well for distributing flows si= multaneously among three different interfaces.

You are saying "What I would like to avoid is to not have any of those= in the current draft. At least one of these should be specified in the base= draft in order to have a complete solution.". Could you please elabora= te a little bit more why you think draft-larsson-mext-flow-distribution-rule= s would not do the work sufficiently?

My proposal is of course to specify a reference to draft-larsson and get a = flexible solution from the beginning.

Regards
Conny


Giaretta, Gerardo wrote:
I definitely agree with you on the importance of long term and= flexible solutions. My point is that there are probably different scenarios= with different requirements and in some of them it makes sense to use binar= y encoding (which is less flexible but more efficient) and in some other it = makes sense to use ASCII-based encoding.
 
What I would like to avoid is to not have any of those in the current draft= . At least one of these should be specified in the base draft in order to ha= ve a complete solution. I think we should go for the binary solution (which = was originally part of the I-D indeed) as it requires less work and can be s= een as the basic solution. In the meanwhile we can focus on an ASCII-based s= olution which is more flexible but would require some more work.
 
Gerardo
 
  
-----Original Message-----
From: Stuart W. Card [mailto:stu.car= d@critical.com]
Sent: Wednesday, November 19, 2008 10:25 AM
To: Giaretta, Gerardo
Cc: mext@ietf.org
Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding
 
 
    
...
I think the support of binary description of the filters is pretty
straighforward and very well known in IETF. This seems to be also the
most reasonable solution in cellular networks where we may want to save
bandwidth...
      
I often have to deal with _really_ slow media (2400 bps,=
half-duplex, with > 250 mS receive-transmit turnaround).
So I have a great appreciation for efficient encodings.
 
That said, I believe that generality, flexibility and
extensibility are more important to overall efficiency
than are the few dozen or even couple hundred bytes that
are saved every few seconds or minutes by encoding
flow descriptions in binary.
 
So my point is, if we are confident that we can specify
a general, flexible, extensible, binary flow description
language, great... but I'd rather stick with inefficient
ASCII encodings if aren't yet to the maturity level in
our understanding of this problem that we can retain
those essential characteristics in a binary encoding.
 
Sorry to bore you all with fuzzy philosophical ramblings
but I think the long- versus short-term efficiency tradeoff
is point that should not be forgotten. Thanks!
 
--
Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc.
* Creativity * Diversity * Expertise * Flexibility * Integrity *
Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501
315-793-0248 x141 FAX -9710 <Stu.Card@cr= itical.com> <mailto:Stu.Car= d@critical.com>  www.critical.com <http://www.critical.com>
 
 
    

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/m= ailman/listinfo/mext
  

_____________________________________= __________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/m= ailman/listinfo/mext
--B_3309952917_7150820-- --===============0641293781== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0641293781==-- From mext-bounces@ietf.org Wed Nov 19 13:27:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108F83A687F; Wed, 19 Nov 2008 13:27:52 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 181803A67D6 for ; Wed, 19 Nov 2008 13:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.598 X-Spam-Level: X-Spam-Status: No, score=-104.598 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 inyJZmPjODjh for ; Wed, 19 Nov 2008 13:27:44 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 8DCA63A683E for ; Wed, 19 Nov 2008 13:27:44 -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=1227130063; x=1258666063; 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: x-cr-puzzleid:x-cr-hashedpuzzle:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Basavaraj=20Patil=20, =0D=0A=20=20=20=20=20=20=20=20Conny=20Larsson=0D=0A=09|CC:=20"mext@ietf.org"=20|Date:=20Wed,=2019=20Nov=202008=2013:27:32=20-080 0|Subject:=20RE:=20[MEXT]=20Flow=20description=20in=20dra ft-ietf-mext-flow-binding|Thread-Topic:=20[MEXT]=20Flow =20description=20in=20draft-ietf-mext-flow-binding |Thread-Index:=20AclKfKZuTwzaPdpiTpWgXcJ7w8CorgADvReQAABP p0kAAA1JgA=3D=3D|Message-ID:=20<057632CE4CE10D45A1A3D6D19 206C3A3D6CA033D@NASANEXMB08.na.qualcomm.com>|References: =20<057632CE4CE10D45A1A3D6D19206C3A3D6CA0338@NASANEXMB08. na.qualcomm.com>=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20 en-US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |x-cr-puzzleid:=20{C3586C71-88A2-486A-AD5B-046B4485A4BD} |x-cr-hashedpuzzle:=20Dn+O=20D3j0=20HZOC=20KRHV=20K6v2=20 MZqQ=20MaOT=20OE1n=20PtaY=20TfPR=20daiU=0D=0A=20ddF7=20fS gV=20gvhy=20g8av=0D=0A=20iUYs=3B3=3BYgBhAHMAYQB2AGEAcgBhA GoALgBwAGEAdABpAGwAQABuAG8AawBpAGEALgBjAG8AbQA7AGMAbwBuAG 4AeQAuAGwAYQByAHMAcwBvAG4AQABlAHIAaQBjAHMAcwBvAG4ALgBjAG8 AbQA7AG0AZQB4AHQAQABpAGUAdABmAC4AbwByAGcA=3BSosha1_v1=3B7 =3B{C3586C71-88A2-486A-AD5B-046B4485A4BD}=3BZwBlAHIAYQByA GQAbwBnAEAAcQB1AGEAbABjAG8AbQBtAC4AYwBvAG0A=3BWed,=0D=0A =2019=20Nov=202008=2021:27:32=0D=0A=20GMT=3BUgBFADoAIABbA E0ARQBYAFQAXQAgAEYAbABvAHcAIABkAGUAcwBjAHIAaQBwAHQAaQBvAG 4AIABpAG4AIABkAHIAYQBmAHQALQBpAGUAdABmAC0AbQBlAHgAdAAtAGY AbABvAHcALQBiAGkAbgBkAGkAbgBnAA=3D=3D|acceptlanguage:=20e n-US|Content-Type:=20multipart/alternative=3B=0D=0A=09bou ndary=3D"_000_057632CE4CE10D45A1A3D6D19206C3A3D6CA033DNAS ANEXMB08naqu_"|MIME-Version:=201.0|X-IronPort-AV:=20E=3DM cAfee=3Bi=3D"5100,188,5439"=3B=20a=3D"13283603"; bh=a4EMSlNTpb6Bz0vrb8wQUB6Ey8g7+uWk/geZ5didM08=; b=CnIWPVdDYCUBZJsKOfM5yx3K48t8WuNsoUH3EINyhJ6wB3qCSwyi6Lim pGaIzMmo0HsmDDGv1YBZkd5RyDysXj1NEikPa1M9aGwaMoobagyHep6X2 LMdmtHyPWZp8Hed+pfMjXRAk1n13tBjCpzAYpn5ShceDIJLsujlgyudV4 I=; X-IronPort-AV: E=McAfee;i="5100,188,5439"; a="13283603" 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; 19 Nov 2008 13:27:43 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAJLRhmM025749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Nov 2008 13:27:43 -0800 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAJLRg8D028354 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Nov 2008 13:27:42 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.132]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Wed, 19 Nov 2008 13:27:42 -0800 From: "Giaretta, Gerardo" To: Basavaraj Patil , Conny Larsson Date: Wed, 19 Nov 2008 13:27:32 -0800 Thread-Topic: [MEXT] Flow description in draft-ietf-mext-flow-binding Thread-Index: AclKfKZuTwzaPdpiTpWgXcJ7w8CorgADvReQAABPp0kAAA1JgA== Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D6CA033D@NASANEXMB08.na.qualcomm.com> References: <057632CE4CE10D45A1A3D6D19206C3A3D6CA0338@NASANEXMB08.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {C3586C71-88A2-486A-AD5B-046B4485A4BD} x-cr-hashedpuzzle: Dn+O D3j0 HZOC KRHV K6v2 MZqQ MaOT OE1n PtaY TfPR daiU ddF7 fSgV gvhy g8av iUYs; 3; YgBhAHMAYQB2AGEAcgBhAGoALgBwAGEAdABpAGwAQABuAG8AawBpAGEALgBjAG8AbQA7AGMAbwBuAG4AeQAuAGwAYQByAHMAcwBvAG4AQABlAHIAaQBjAHMAcwBvAG4ALgBjAG8AbQA7AG0AZQB4AHQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {C3586C71-88A2-486A-AD5B-046B4485A4BD}; ZwBlAHIAYQByAGQAbwBnAEAAcQB1AGEAbABjAG8AbQBtAC4AYwBvAG0A; Wed, 19 Nov 2008 21:27:32 GMT; UgBFADoAIABbAE0ARQBYAFQAXQAgAEYAbABvAHcAIABkAGUAcwBjAHIAaQBwAHQAaQBvAG4AIABpAG4AIABkAHIAYQBmAHQALQBpAGUAdABmAC0AbQBlAHgAdAAtAGYAbABvAHcALQBiAGkAbgBkAGkAbgBnAA== acceptlanguage: en-US MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0394191094==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0394191094== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_057632CE4CE10D45A1A3D6D19206C3A3D6CA033DNASANEXMB08naqu_" --_000_057632CE4CE10D45A1A3D6D19206C3A3D6CA033DNASANEXMB08naqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Raj, The point is that in some scenarios what the MN needs to communicate to the= HA are simple 5-tuples, most of them may even contain wild-carded values. = The amount and the details of information carried over SIP is different. I am not proposing the binary encoding should be the default. I am saying i= t is simple enough to document it in the basic draft (we basically need one= mobility option). I am fine if we move forward also draft-larsson at the s= ame time and we include references in the flow binding draft. Gerardo From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] Sent: Wednesday, November 19, 2008 1:22 PM To: Giaretta, Gerardo; Conny Larsson Cc: mext@ietf.org Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding Hi Gerardo, The bandwidth efficiency of binary encoding is true in general. However if you look at SIP for example, why did they choose to not specify = it with binary encoding? There is value with the Ascii encoding model. I just don't know if there is= a need to be highly optimized here to choose the binary encoding format as= the default. -Raj On 11/19/08 3:15 PM, "Giaretta Gerardo" wrote: Hi Conny, I think the point is that binary encoding is more bandwidth efficient. If w= e consider 3GPP as an example, the binary encoding is used for QoS reservat= ions and requests. In my view we could use a similar binary encoding also f= or flow mobility and document that in the basic draft. I see the argument of flexibility but this comes to a cost. Pointing to dra= ft-larsson for more flexible encoding is fine to me but I don't think that = should be the basic model. Cheers Gerardo From: Conny Larsson [mailto:conny.larsson@ericsson.com] Sent: Wednesday, November 19, 2008 11:26 AM To: Giaretta, Gerardo Cc: stu.card@critical.com; mext@ietf.org Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding Hi Gerardo, I have difficulties to comment on your flexibility/efficiency statement sin= ce I have not implemented any of the solutions (binary encoding/ASCII-based= encoding). However, one of my colleagues has made an implementation of the= ASCII-based solution, as specified in http://tools.ietf.org/id/draft-larss= on-mext-flow-distribution-rules-01.txt, and according to him it was easy to= implement and caused no major problems. We even have a prototype on Linux = up and running and it works perfectly well for distributing flows simultane= ously among three different interfaces. You are saying "What I would like to avoid is to not have any of those in t= he current draft. At least one of these should be specified in the base dra= ft in order to have a complete solution.". Could you please elaborate a lit= tle bit more why you think draft-larsson-mext-flow-distribution-rules would= not do the work sufficiently? My proposal is of course to specify a reference to draft-larsson and get a = flexible solution from the beginning. Regards Conny Giaretta, Gerardo wrote: I definitely agree with you on the importance of long term and flexible sol= utions. My point is that there are probably different scenarios with differ= ent requirements and in some of them it makes sense to use binary encoding = (which is less flexible but more efficient) and in some other it makes sens= e to use ASCII-based encoding. What I would like to avoid is to not have any of those in the current draft= . At least one of these should be specified in the base draft in order to h= ave a complete solution. I think we should go for the binary solution (whic= h was originally part of the I-D indeed) as it requires less work and can b= e seen as the basic solution. In the meanwhile we can focus on an ASCII-bas= ed solution which is more flexible but would require some more work. Gerardo -----Original Message----- From: Stuart W. Card [mailto:stu.card@critical.com] Sent: Wednesday, November 19, 2008 10:25 AM To: Giaretta, Gerardo Cc: mext@ietf.org Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding ... I think the support of binary description of the filters is pretty straighforward and very well known in IETF. This seems to be also the most reasonable solution in cellular networks where we may want to save bandwidth... I often have to deal with _really_ slow media (2400 bps, half-duplex, with > 250 mS receive-transmit turnaround). So I have a great appreciation for efficient encodings. That said, I believe that generality, flexibility and extensibility are more important to overall efficiency than are the few dozen or even couple hundred bytes that are saved every few seconds or minutes by encoding flow descriptions in binary. So my point is, if we are confident that we can specify a general, flexible, extensible, binary flow description language, great... but I'd rather stick with inefficient ASCII encodings if aren't yet to the maturity level in our understanding of this problem that we can retain those essential characteristics in a binary encoding. Sorry to bore you all with fuzzy philosophical ramblings but I think the long- versus short-term efficiency tradeoff is point that should not be forgotten. Thanks! -- Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 www.critical.com _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --_000_057632CE4CE10D45A1A3D6D19206C3A3D6CA033DNASANEXMB08naqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [MEXT] Flow description in draft-ietf-mext-flow-binding

Hi Raj,

 

The point is that in some scenarios what the MN needs to communicate to the HA are simple 5-tuples, most of them may even contain wi= ld-carded values. The amount and the details of information carried over SIP is diffe= rent.

 

I am not proposing the binary encoding should be the default= . I am saying it is simple enough to document it in the basic draft (we basical= ly need one mobility option). I am fine if we move forward also draft-larsson = at the same time and we include references in the flow binding draft.

 

Gerardo

 

From: Basavaraj Pat= il [mailto:basavaraj.patil@nokia.com]
Sent: Wednesday, November 19, 2008 1:22 PM
To: Giaretta, Gerardo; Conny Larsson
Cc: mext@ietf.org
Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding=

 


Hi Gerardo,

The bandwidth efficiency of binary encoding is true in general.
However if you look at SIP for example, why did they choose to not specify = it with binary encoding?

There is value with the Ascii encoding model. I just don’t know if th= ere is a need to be highly optimized here to choose the binary encoding format = as the default.

-Raj


On 11/19/08 3:15 PM, "Giaretta Gerardo" <gerardog@qualcomm.com> wrote:<= o:p>

Hi Conny,
 
I think the point is that binary encoding is more bandwidth efficient. If w= e consider 3GPP as an example, the binary encoding is used for QoS reservatio= ns and requests. In my view we could use a similar binary encoding also for fl= ow mobility and document that in the basic draft.
 
I see the argument of flexibility but this comes to a cost. Pointing to draft-larsson for more flexible encoding is fine to me but I don’t th= ink that should be the basic model.
 
Cheers
Gerardo
 
=
From: Conny Larsson= [mailto:conny.larsson@ericsson.co= m]
Sent: Wednesday, November 19, 2008 11:26 AM
To: Giaretta, Gerardo
Cc: stu.card@critical.com; mext@ietf.org
Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding=

Hi Gerardo,

I have difficulties to comment on your flexibility/efficiency statement sin= ce I have not implemented any of the solutions (binary encoding/ASCII-based encoding). However, one of my colleagues has made an implementation of the ASCII-based solution, as specified in http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rule= s-01.txt, and according to him it was easy to implement and caused no major problems.= We even have a prototype on Linux up and running and it works perfectly well f= or distributing flows simultaneously among three different interfaces.

You are saying "What I would like to avoid is to not have any of those= in the current draft. At least one of these should be specified in the base dr= aft in order to have a complete solution.". Could you please elaborate a little bit more why you think draft-larsson-mext-flow-distribution-rules wo= uld not do the work sufficiently?

My proposal is of course to specify a reference to draft-larsson and get a flexible solution from the beginning.

Regards
Conny


Giaretta, Gerardo wrote:
I defin= itely agree with you on the importance of long term and flexible solutions. My po= int is that there are probably different scenarios with different requirements = and in some of them it makes sense to use binary encoding (which is less flexib= le but more efficient) and in some other it makes sense to use ASCII-based encoding.
 
What I would like to avoid is to not have any of those in the current draft= . At least one of these should be specified in the base draft in order to have a complete solution. I think we should go for the binary solution (which was originally part of the I-D indeed) as it requires less work and can be seen= as the basic solution. In the meanwhile we can focus on an ASCII-based solutio= n which is more flexible but would require some more work.
 
Gerardo
 
  

-----Original Message-----
From: Stuart W. Card [mailto:stu.c= ard@critical.com]
Sent: Wednesday, November 19, 2008 10:25 AM
To: Giaretta, Gerardo
Cc: mext@ietf.org
Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding
 
 
    

...
I think the support of binary description of the filters is pretty
straighforward and very well known in IETF. This seems to be also the
most reasonable solution in cellular networks where we may want to save
bandwidth...
      

I often have to deal with _really_ slow media (2400 bps,
half-duplex, with > 250 mS receive-transmit turnaround).
So I have a great appreciation for efficient encodings.
 
That said, I believe that generality, flexibility and
extensibility are more important to overall efficiency
than are the few dozen or even couple hundred bytes that
are saved every few seconds or minutes by encoding
flow descriptions in binary.
 
So my point is, if we are confident that we can specify
a general, flexible, extensible, binary flow description
language, great... but I'd rather stick with inefficient
ASCII encodings if aren't yet to the maturity level in
our understanding of this problem that we can retain
those essential characteristics in a binary encoding.
 
Sorry to bore you all with fuzzy philosophical ramblings
but I think the long- versus short-term efficiency tradeoff
is point that should not be forgotten. Thanks!
 
--
Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc.
* Creativity * Diversity * Expertise * Flexibility * Integrity *
Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501
315-793-0248 x141 FAX -9710 <Stu.Card@= critical.com> <mailto:Stu.Card@critical.com>  www.critical.com <http://www.c= ritical.com>
 
 
    


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

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

--_000_057632CE4CE10D45A1A3D6D19206C3A3D6CA033DNASANEXMB08naqu_-- --===============0394191094== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0394191094==-- From mext-bounces@ietf.org Wed Nov 19 18:15:14 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E4EF3A6918; Wed, 19 Nov 2008 18:15:14 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 558533A6918 for ; Wed, 19 Nov 2008 18:15: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 asyilNJzStU2 for ; Wed, 19 Nov 2008 18:15:11 -0800 (PST) Received: from mandala.kddilabs.jp (unknown [IPv6:2001:200:601:12:230:48ff:fe22:3a84]) by core3.amsl.com (Postfix) with ESMTP id EDFAF3A6778 for ; Wed, 19 Nov 2008 18:15:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 2DA10EC846; Thu, 20 Nov 2008 11:15:05 +0900 (JST) Received: from spears.ast.kddilabs.jp (unknown [2001:200:601:800::168]) by mandala.kddilabs.jp (Postfix) with ESMTP id AD7E1EC833; Thu, 20 Nov 2008 11:15:03 +0900 (JST) Received: from [127.0.0.1] (c024.vpn.kddilabs.jp [172.19.87.24]) by spears.ast.kddilabs.jp (Postfix) with ESMTP id 8B268690636; Thu, 20 Nov 2008 11:14:59 +0900 (JST) Message-ID: <4924C84D.8060405@kddilabs.jp> Date: Thu, 20 Nov 2008 11:15:41 +0900 From: Kazuyuki Tasaka User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: <057632CE4CE10D45A1A3D6D19206C3A3D6CA0338@NASANEXMB08.na.qualcomm.com> <057632CE4CE10D45A1A3D6D19206C3A3D6CA033D@NASANEXMB08.na.qualcomm.com> In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D6CA033D@NASANEXMB08.na.qualcomm.com> X-Virus-Scanned: by amavisd-new Cc: "mext@ietf.org" , Basavaraj Patil Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Gerardo, My understanding is that your point is use of simple 5-tuples as flow description and transportation of binary encoded them for saving bandwidth. I think that this is one basic example for QoS reservations and requests and is very simple. But this is not generic. So, I propose to describe it in both documents (Flow binding and Flow distribution) as one example for QoS reservations and requests. For example, in flow binding document, we include that flow description SHOULD be used binary encoded 5-tuples in case of QoS reservations and resuests. On the other hand, in flow destribution document, we define more generic routing rules and include that the number of routing rules SHOULD be minimize (e.g. 5-tuples) in case of it. Now, in flow destribution document, it is described that routing rules could be stored in a file system in the ASCII form, but they could also be stored in, e.g., in-core (binary) data structures. What do you think this? Regards, Kazuyuki. Giaretta, Gerardo Wrote: > Hi Raj, > > The point is that in some scenarios what the MN needs to communicate to the HA are simple 5-tuples, most of them may even contain wild-carded values. The amount and the details of information carried over SIP is different. > > I am not proposing the binary encoding should be the default. I am saying it is simple enough to document it in the basic draft (we basically need one mobility option). I am fine if we move forward also draft-larsson at the same time and we include references in the flow binding draft. > > Gerardo > > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > Sent: Wednesday, November 19, 2008 1:22 PM > To: Giaretta, Gerardo; Conny Larsson > Cc: mext@ietf.org > Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding > > > Hi Gerardo, > > The bandwidth efficiency of binary encoding is true in general. > However if you look at SIP for example, why did they choose to not specify it with binary encoding? > > There is value with the Ascii encoding model. I just don't know if there is a need to be highly optimized here to choose the binary encoding format as the default. > > -Raj > > > On 11/19/08 3:15 PM, "Giaretta Gerardo" wrote: > Hi Conny, > > I think the point is that binary encoding is more bandwidth efficient. If we consider 3GPP as an example, the binary encoding is used for QoS reservations and requests. In my view we could use a similar binary encoding also for flow mobility and document that in the basic draft. > > I see the argument of flexibility but this comes to a cost. Pointing to draft-larsson for more flexible encoding is fine to me but I don't think that should be the basic model. > > Cheers > Gerardo > > > From: Conny Larsson [mailto:conny.larsson@ericsson.com] > Sent: Wednesday, November 19, 2008 11:26 AM > To: Giaretta, Gerardo > Cc: stu.card@critical.com; mext@ietf.org > Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding > > Hi Gerardo, > > I have difficulties to comment on your flexibility/efficiency statement since I have not implemented any of the solutions (binary encoding/ASCII-based encoding). However, one of my colleagues has made an implementation of the ASCII-based solution, as specified in http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rules-01.txt, and according to him it was easy to implement and caused no major problems. We even have a prototype on Linux up and running and it works perfectly well for distributing flows simultaneously among three different interfaces. > > You are saying "What I would like to avoid is to not have any of those in the current draft. At least one of these should be specified in the base draft in order to have a complete solution.". Could you please elaborate a little bit more why you think draft-larsson-mext-flow-distribution-rules would not do the work sufficiently? > > My proposal is of course to specify a reference to draft-larsson and get a flexible solution from the beginning. > > Regards > Conny > > > Giaretta, Gerardo wrote: > I definitely agree with you on the importance of long term and flexible solutions. My point is that there are probably different scenarios with different requirements and in some of them it makes sense to use binary encoding (which is less flexible but more efficient) and in some other it makes sense to use ASCII-based encoding. > > What I would like to avoid is to not have any of those in the current draft. At least one of these should be specified in the base draft in order to have a complete solution. I think we should go for the binary solution (which was originally part of the I-D indeed) as it requires less work and can be seen as the basic solution. In the meanwhile we can focus on an ASCII-based solution which is more flexible but would require some more work. > > Gerardo > > > -----Original Message----- > From: Stuart W. Card [mailto:stu.card@critical.com] > Sent: Wednesday, November 19, 2008 10:25 AM > To: Giaretta, Gerardo > Cc: mext@ietf.org > Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding > > > > ... > I think the support of binary description of the filters is pretty > straighforward and very well known in IETF. This seems to be also the > most reasonable solution in cellular networks where we may want to save > bandwidth... > > I often have to deal with _really_ slow media (2400 bps, > half-duplex, with > 250 mS receive-transmit turnaround). > So I have a great appreciation for efficient encodings. > > That said, I believe that generality, flexibility and > extensibility are more important to overall efficiency > than are the few dozen or even couple hundred bytes that > are saved every few seconds or minutes by encoding > flow descriptions in binary. > > So my point is, if we are confident that we can specify > a general, flexible, extensible, binary flow description > language, great... but I'd rather stick with inefficient > ASCII encodings if aren't yet to the maturity level in > our understanding of this problem that we can retain > those essential characteristics in a binary encoding. > > Sorry to bore you all with fuzzy philosophical ramblings > but I think the long- versus short-term efficiency tradeoff > is point that should not be forgotten. Thanks! > > -- > Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. > * Creativity * Diversity * Expertise * Flexibility * Integrity * > Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 > 315-793-0248 x141 FAX -9710 www.critical.com > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > ________________________________ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > > ------------------------------------------------------------------------ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Nov 19 21:50:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20CDA3A6955; Wed, 19 Nov 2008 21:50:15 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8073A3A6955 for ; Wed, 19 Nov 2008 21:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.932 X-Spam-Level: X-Spam-Status: No, score=-105.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, 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 Xx7fSGE6Tvbs for ; Wed, 19 Nov 2008 21:50:10 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 3E9C23A691F for ; Wed, 19 Nov 2008 21:50:10 -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=1227160209; x=1258696209; 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:=20Kazuyuki=20Tasaka=20|CC:=20 Basavaraj=20Patil=20,=0D=0A=20 =20=20=20=20=20=20=20Conny=20Larsson=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"mext@ietf .org"=20|Date:=20Wed,=2019=20Nov=202008=20 21:50:01=20-0800|Subject:=20RE:=20[MEXT]=20Flow=20descrip tion=20in=20draft-ietf-mext-flow-binding|Thread-Topic:=20 [MEXT]=20Flow=20description=20in=20draft-ietf-mext-flow-b inding|Thread-Index:=20AclKtefnRw8ATkrcQX6q9p56G5d+CgAHGX 5G|Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3D6CC34D C@NASANEXMB08.na.qualcomm.com>|References:=20<057632CE4CE 10D45A1A3D6D19206C3A3D6CA0338@NASANEXMB08.na.qualcomm.com >=0D=0A=09=0D =0A=20<057632CE4CE10D45A1A3D6D19206C3A3D6CA033D@NASANEXMB 08.na.qualcomm.com>,<4924C84D.8060405@kddilabs.jp> |In-Reply-To:=20<4924C84D.8060405@kddilabs.jp> |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,5439"=3B=20a=3D"13322558"; bh=0g7BhDER3M6w9yE7Ku8TxbC3ZEGPDavcDoYKVnSP6l0=; b=Znt6iRlyplqVVLdCUeBN4VNNZiTZbC5THY8zMW1Sg4igESN7cuJ1DA0Y 7pXhxSBpy1nqyf31FmwpSmR8rs9lYP0/41rZ4Cz3vm80duSeNYtnd3ud7 57MjXucG4Zs/xsdiSVoYGB7KBpSnSCqnNj1Y3Quvw08az6lCpBfPeW7WY 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5439"; a="13322558" 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; 19 Nov 2008 21:50:09 -0800 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 mAK5o8th023780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Nov 2008 21:50:09 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAK5o3CN017195 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Nov 2008 21:50:08 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.132]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Wed, 19 Nov 2008 21:50:03 -0800 From: "Giaretta, Gerardo" To: Kazuyuki Tasaka Date: Wed, 19 Nov 2008 21:50:01 -0800 Thread-Topic: [MEXT] Flow description in draft-ietf-mext-flow-binding Thread-Index: AclKtefnRw8ATkrcQX6q9p56G5d+CgAHGX5G Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D6CC34DC@NASANEXMB08.na.qualcomm.com> References: <057632CE4CE10D45A1A3D6D19206C3A3D6CA0338@NASANEXMB08.na.qualcomm.com> <057632CE4CE10D45A1A3D6D19206C3A3D6CA033D@NASANEXMB08.na.qualcomm.com>, <4924C84D.8060405@kddilabs.jp> In-Reply-To: <4924C84D.8060405@kddilabs.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "mext@ietf.org" , Basavaraj Patil Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Kazuyuki, I don't fully understand your proposal. I don't think we should mention QoS requests in the document; I used that as an example of how binary encoding is used in other SDO. My proposal would be to specify a simple mobility option for binary encoding in draft-ietf-mext-flow-binding. The draft will state something like the following: "The MN MAY use this binary encoding specified in this draft as Flow Description. Alternatively the MN MAY use the encoding specified in draft-larsson." In this way we capture both solutions and we don't prioritize any of them. Would that be acceptable? Thanks Gerardo ________________________________________ From: Kazuyuki Tasaka [ka-tasaka@kddilabs.jp] Sent: Wednesday, November 19, 2008 6:15 PM To: Giaretta, Gerardo Cc: Basavaraj Patil; Conny Larsson; mext@ietf.org Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding Hi Gerardo, My understanding is that your point is use of simple 5-tuples as flow description and transportation of binary encoded them for saving bandwidth. I think that this is one basic example for QoS reservations and requests and is very simple. But this is not generic. So, I propose to describe it in both documents (Flow binding and Flow distribution) as one example for QoS reservations and requests. For example, in flow binding document, we include that flow description SHOULD be used binary encoded 5-tuples in case of QoS reservations and resuests. On the other hand, in flow destribution document, we define more generic routing rules and include that the number of routing rules SHOULD be minimize (e.g. 5-tuples) in case of it. Now, in flow destribution document, it is described that routing rules could be stored in a file system in the ASCII form, but they could also be stored in, e.g., in-core (binary) data structures. What do you think this? Regards, Kazuyuki. Giaretta, Gerardo Wrote: > Hi Raj, > > The point is that in some scenarios what the MN needs to communicate to the HA are simple 5-tuples, most of them may even contain wild-carded values. The amount and the details of information carried over SIP is different. > > I am not proposing the binary encoding should be the default. I am saying it is simple enough to document it in the basic draft (we basically need one mobility option). I am fine if we move forward also draft-larsson at the same time and we include references in the flow binding draft. > > Gerardo > > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > Sent: Wednesday, November 19, 2008 1:22 PM > To: Giaretta, Gerardo; Conny Larsson > Cc: mext@ietf.org > Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding > > > Hi Gerardo, > > The bandwidth efficiency of binary encoding is true in general. > However if you look at SIP for example, why did they choose to not specify it with binary encoding? > > There is value with the Ascii encoding model. I just don't know if there is a need to be highly optimized here to choose the binary encoding format as the default. > > -Raj > > > On 11/19/08 3:15 PM, "Giaretta Gerardo" wrote: > Hi Conny, > > I think the point is that binary encoding is more bandwidth efficient. If we consider 3GPP as an example, the binary encoding is used for QoS reservations and requests. In my view we could use a similar binary encoding also for flow mobility and document that in the basic draft. > > I see the argument of flexibility but this comes to a cost. Pointing to draft-larsson for more flexible encoding is fine to me but I don't think that should be the basic model. > > Cheers > Gerardo > > > From: Conny Larsson [mailto:conny.larsson@ericsson.com] > Sent: Wednesday, November 19, 2008 11:26 AM > To: Giaretta, Gerardo > Cc: stu.card@critical.com; mext@ietf.org > Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding > > Hi Gerardo, > > I have difficulties to comment on your flexibility/efficiency statement since I have not implemented any of the solutions (binary encoding/ASCII-based encoding). However, one of my colleagues has made an implementation of the ASCII-based solution, as specified in http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rules-01.txt, and according to him it was easy to implement and caused no major problems. We even have a prototype on Linux up and running and it works perfectly well for distributing flows simultaneously among three different interfaces. > > You are saying "What I would like to avoid is to not have any of those in the current draft. At least one of these should be specified in the base draft in order to have a complete solution.". Could you please elaborate a little bit more why you think draft-larsson-mext-flow-distribution-rules would not do the work sufficiently? > > My proposal is of course to specify a reference to draft-larsson and get a flexible solution from the beginning. > > Regards > Conny > > > Giaretta, Gerardo wrote: > I definitely agree with you on the importance of long term and flexible solutions. My point is that there are probably different scenarios with different requirements and in some of them it makes sense to use binary encoding (which is less flexible but more efficient) and in some other it makes sense to use ASCII-based encoding. > > What I would like to avoid is to not have any of those in the current draft. At least one of these should be specified in the base draft in order to have a complete solution. I think we should go for the binary solution (which was originally part of the I-D indeed) as it requires less work and can be seen as the basic solution. In the meanwhile we can focus on an ASCII-based solution which is more flexible but would require some more work. > > Gerardo > > > -----Original Message----- > From: Stuart W. Card [mailto:stu.card@critical.com] > Sent: Wednesday, November 19, 2008 10:25 AM > To: Giaretta, Gerardo > Cc: mext@ietf.org > Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding > > > > ... > I think the support of binary description of the filters is pretty > straighforward and very well known in IETF. This seems to be also the > most reasonable solution in cellular networks where we may want to save > bandwidth... > > I often have to deal with _really_ slow media (2400 bps, > half-duplex, with > 250 mS receive-transmit turnaround). > So I have a great appreciation for efficient encodings. > > That said, I believe that generality, flexibility and > extensibility are more important to overall efficiency > than are the few dozen or even couple hundred bytes that > are saved every few seconds or minutes by encoding > flow descriptions in binary. > > So my point is, if we are confident that we can specify > a general, flexible, extensible, binary flow description > language, great... but I'd rather stick with inefficient > ASCII encodings if aren't yet to the maturity level in > our understanding of this problem that we can retain > those essential characteristics in a binary encoding. > > Sorry to bore you all with fuzzy philosophical ramblings > but I think the long- versus short-term efficiency tradeoff > is point that should not be forgotten. Thanks! > > -- > Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. > * Creativity * Diversity * Expertise * Flexibility * Integrity * > Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 > 315-793-0248 x141 FAX -9710 www.critical.com > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > ________________________________ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > > ------------------------------------------------------------------------ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 20 01:51:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4297A28C193; Thu, 20 Nov 2008 01:51:23 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4847928C18E for ; Thu, 20 Nov 2008 01:51:21 -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 csD+CUmYsr1L for ; Thu, 20 Nov 2008 01:51:20 -0800 (PST) Received: from mandala.kddilabs.jp (unknown [IPv6:2001:200:601:12:230:48ff:fe22:3a84]) by core3.amsl.com (Postfix) with ESMTP id 214FB28C193 for ; Thu, 20 Nov 2008 01:51:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 3620DEC87B; Thu, 20 Nov 2008 18:51:16 +0900 (JST) Received: from spears.ast.kddilabs.jp (unknown [2001:200:601:800::168]) by mandala.kddilabs.jp (Postfix) with ESMTP id D3C50EC878; Thu, 20 Nov 2008 18:51:14 +0900 (JST) Received: from [127.0.0.1] (c015.vpn.kddilabs.jp [172.19.87.15]) by spears.ast.kddilabs.jp (Postfix) with ESMTP id B3B7F1B0085; Thu, 20 Nov 2008 18:51:10 +0900 (JST) Message-ID: <49253338.4030905@kddilabs.jp> Date: Thu, 20 Nov 2008 18:51:52 +0900 From: Kazuyuki Tasaka User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: <057632CE4CE10D45A1A3D6D19206C3A3D6CA0338@NASANEXMB08.na.qualcomm.com> <057632CE4CE10D45A1A3D6D19206C3A3D6CA033D@NASANEXMB08.na.qualcomm.com>, <4924C84D.8060405@kddilabs.jp> <057632CE4CE10D45A1A3D6D19206C3A3D6CC34DC@NASANEXMB08.na.qualcomm.com> In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D6CC34DC@NASANEXMB08.na.qualcomm.com> X-Virus-Scanned: by amavisd-new Cc: "mext@ietf.org" , Basavaraj Patil Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Gerardo, I think that the flow description should be defined in another document(e.g. draft-larsson). This is the WG decision. On the other hand, I agree to specify one reference example (e.g. example for binary encoding) in flow-binding. So, "The MN MAY use the encoding specified in draft-larsson as flow description. At this time, the MN MAY handle not only data stored in the ASCII form but also data stored in binary data structures for saving bandwidth. In this case, MN SHULD use a mobility option for binary encoding". Regards, Kazuyuki. Giaretta, Gerardo Wrote: > Hi Kazuyuki, > > I don't fully understand your proposal. I don't think we should mention QoS requests in the document; I used that as an example of how binary encoding is used in other SDO. > > My proposal would be to specify a simple mobility option for binary encoding in draft-ietf-mext-flow-binding. The draft will state something like the following: > > "The MN MAY use this binary encoding specified in this draft as Flow Description. Alternatively the MN MAY use the encoding specified in draft-larsson." > > In this way we capture both solutions and we don't prioritize any of them. > > Would that be acceptable? > > Thanks > Gerardo > > ________________________________________ > From: Kazuyuki Tasaka [ka-tasaka@kddilabs.jp] > Sent: Wednesday, November 19, 2008 6:15 PM > To: Giaretta, Gerardo > Cc: Basavaraj Patil; Conny Larsson; mext@ietf.org > Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding > > Hi Gerardo, > > My understanding is that your point is use of simple 5-tuples as > flow description and transportation of binary encoded them for > saving bandwidth. > > I think that this is one basic example for QoS reservations and > requests and is very simple. But this is not generic. > > So, I propose to describe it in both documents (Flow binding and > Flow distribution) as one example for QoS reservations and requests. > > For example, in flow binding document, we include that flow description > SHOULD be used binary encoded 5-tuples in case of QoS reservations and > resuests. > On the other hand, in flow destribution document, we define more generic > routing rules and include that the number of routing rules SHOULD be > minimize (e.g. 5-tuples) in case of it. > Now, in flow destribution document, it is described that routing rules > could be stored in a file system in the ASCII form, but they could also > be stored in, e.g., in-core (binary) data structures. > > What do you think this? > > Regards, > Kazuyuki. > > Giaretta, Gerardo Wrote: >> Hi Raj, >> >> The point is that in some scenarios what the MN needs to communicate to the HA are simple 5-tuples, most of them may even contain wild-carded values. The amount and the details of information carried over SIP is different. >> >> I am not proposing the binary encoding should be the default. I am saying it is simple enough to document it in the basic draft (we basically need one mobility option). I am fine if we move forward also draft-larsson at the same time and we include references in the flow binding draft. >> >> Gerardo >> >> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] >> Sent: Wednesday, November 19, 2008 1:22 PM >> To: Giaretta, Gerardo; Conny Larsson >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding >> >> >> Hi Gerardo, >> >> The bandwidth efficiency of binary encoding is true in general. >> However if you look at SIP for example, why did they choose to not specify it with binary encoding? >> >> There is value with the Ascii encoding model. I just don't know if there is a need to be highly optimized here to choose the binary encoding format as the default. >> >> -Raj >> >> >> On 11/19/08 3:15 PM, "Giaretta Gerardo" wrote: >> Hi Conny, >> >> I think the point is that binary encoding is more bandwidth efficient. If we consider 3GPP as an example, the binary encoding is used for QoS reservations and requests. In my view we could use a similar binary encoding also for flow mobility and document that in the basic draft. >> >> I see the argument of flexibility but this comes to a cost. Pointing to draft-larsson for more flexible encoding is fine to me but I don't think that should be the basic model. >> >> Cheers >> Gerardo >> >> >> From: Conny Larsson [mailto:conny.larsson@ericsson.com] >> Sent: Wednesday, November 19, 2008 11:26 AM >> To: Giaretta, Gerardo >> Cc: stu.card@critical.com; mext@ietf.org >> Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding >> >> Hi Gerardo, >> >> I have difficulties to comment on your flexibility/efficiency statement since I have not implemented any of the solutions (binary encoding/ASCII-based encoding). However, one of my colleagues has made an implementation of the ASCII-based solution, as specified in http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rules-01.txt, and according to him it was easy to implement and caused no major problems. We even have a prototype on Linux up and running and it works perfectly well for distributing flows simultaneously among three different interfaces. >> >> You are saying "What I would like to avoid is to not have any of those in the current draft. At least one of these should be specified in the base draft in order to have a complete solution.". Could you please elaborate a little bit more why you think draft-larsson-mext-flow-distribution-rules would not do the work sufficiently? >> >> My proposal is of course to specify a reference to draft-larsson and get a flexible solution from the beginning. >> >> Regards >> Conny >> >> >> Giaretta, Gerardo wrote: >> I definitely agree with you on the importance of long term and flexible solutions. My point is that there are probably different scenarios with different requirements and in some of them it makes sense to use binary encoding (which is less flexible but more efficient) and in some other it makes sense to use ASCII-based encoding. >> >> What I would like to avoid is to not have any of those in the current draft. At least one of these should be specified in the base draft in order to have a complete solution. I think we should go for the binary solution (which was originally part of the I-D indeed) as it requires less work and can be seen as the basic solution. In the meanwhile we can focus on an ASCII-based solution which is more flexible but would require some more work. >> >> Gerardo >> >> >> -----Original Message----- >> From: Stuart W. Card [mailto:stu.card@critical.com] >> Sent: Wednesday, November 19, 2008 10:25 AM >> To: Giaretta, Gerardo >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding >> >> >> >> ... >> I think the support of binary description of the filters is pretty >> straighforward and very well known in IETF. This seems to be also the >> most reasonable solution in cellular networks where we may want to save >> bandwidth... >> >> I often have to deal with _really_ slow media (2400 bps, >> half-duplex, with > 250 mS receive-transmit turnaround). >> So I have a great appreciation for efficient encodings. >> >> That said, I believe that generality, flexibility and >> extensibility are more important to overall efficiency >> than are the few dozen or even couple hundred bytes that >> are saved every few seconds or minutes by encoding >> flow descriptions in binary. >> >> So my point is, if we are confident that we can specify >> a general, flexible, extensible, binary flow description >> language, great... but I'd rather stick with inefficient >> ASCII encodings if aren't yet to the maturity level in >> our understanding of this problem that we can retain >> those essential characteristics in a binary encoding. >> >> Sorry to bore you all with fuzzy philosophical ramblings >> but I think the long- versus short-term efficiency tradeoff >> is point that should not be forgotten. Thanks! >> >> -- >> Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. >> * Creativity * Diversity * Expertise * Flexibility * Integrity * >> Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 >> 315-793-0248 x141 FAX -9710 www.critical.com >> >> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> ________________________________ >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 20 08:00:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 931293A6A05; Thu, 20 Nov 2008 08:00:03 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1350828C111; Thu, 20 Nov 2008 08:00:02 -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: <20081120160002.1350828C111@core3.amsl.com> Date: Thu, 20 Nov 2008 08:00:02 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-mib-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: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : NEMO Management Information Base Author(s) : S. Gundavelli, et al. Filename : draft-ietf-mext-nemo-mib-02.txt Pages : 45 Date : 2008-11-20 This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a Mobile IPv6 node with NEMO functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-mib-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-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-20075341.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Thu Nov 20 09:02:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40AF23A6A3A; Thu, 20 Nov 2008 09:02:31 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0A3428C186 for ; Thu, 20 Nov 2008 09:02:29 -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 wFOBDmF7RAN5 for ; Thu, 20 Nov 2008 09:02:28 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 8532F3A6A2E for ; Thu, 20 Nov 2008 09:02:28 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so526017rvf.49 for ; Thu, 20 Nov 2008 09:02:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:user-agent :mime-version:to:subject:content-type:content-transfer-encoding:from; bh=ofIbbenzO11c+9MDgrmJL5EVDHndQFxuP8PNgaLlq3M=; b=cq8t+RXHTzbxVch7FHMRv/wEKZCWovODQ0rj0wJ9k4dXYesXXymlxhwUznL4/5e4NX ht/wO8JPHakHkGNa6AEwluzv0jLl7zLxr7gSD7lR6yU3dQ/B0hrzw+8oippyqTIcA58U Az1dPcGGwYJVET+YVfU+r6U+BrvuPM9Qf9p64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:user-agent:mime-version:to:subject:content-type :content-transfer-encoding:from; b=dKvSWSYl0I+LbfmTDktbrTPvBScdU15khn4cNu1if8FsFFff/+iWINrbv7kxC1G4v7 SYy7wjKA/3mx8oWiSyBou8kPiOrtINrfi13QQYMavVsR6tqgKAH8FUWd/utBYD+VMNOe tzGS5kFG1bSHLqDB1WbyN+XrZJQIq81el1PV0= Received: by 10.141.48.10 with SMTP id a10mr1320927rvk.266.1227200547235; Thu, 20 Nov 2008 09:02:27 -0800 (PST) Received: from ?130.129.29.123? ([130.129.29.123]) by mx.google.com with ESMTPS id b39sm1612985rvf.0.2008.11.20.09.02.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 20 Nov 2008 09:02:26 -0800 (PST) Message-ID: <4925982F.6010807@googlemail.com> Date: Thu, 20 Nov 2008 18:02:39 +0100 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: mext@ietf.org, marcelo bagnulo braun From: Julien Laganier Subject: [MEXT] Note takers and scribes X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, We'd be very happy if we could find volunteer note takers and scribes prior to today's session at 13:00 so that we can start the meeting on time rather than spend ten minutes in search of those. Appreciate your support. --julien & marcelo, MEXT chairs _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 20 09:30:17 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2C428C219; Thu, 20 Nov 2008 09:30:17 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57F4B3A6943 for ; Thu, 20 Nov 2008 09:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, 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 NAl2Ii4Jk+HM for ; Thu, 20 Nov 2008 09:30:14 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 98DC33A6A27 for ; Thu, 20 Nov 2008 09:30:14 -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=1227202213; x=1258738213; 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:=20Kazuyuki=20Tasaka=20|CC:=20 Basavaraj=20Patil=20,=0D=0A=20 =20=20=20=20=20=20=20Conny=20Larsson=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"mext@ietf .org"=20|Date:=20Thu,=2020=20Nov=202008=20 09:29:58=20-0800|Subject:=20RE:=20[MEXT]=20Flow=20descrip tion=20in=20draft-ietf-mext-flow-binding|Thread-Topic:=20 [MEXT]=20Flow=20description=20in=20draft-ietf-mext-flow-b inding|Thread-Index:=20AclK9Yvzn/jbsmDnQQiPmfpgsSjG1QAP6z 5w|Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3D6CA040 2@NASANEXMB08.na.qualcomm.com>|References:=20<057632CE4CE 10D45A1A3D6D19206C3A3D6CA0338@NASANEXMB08.na.qualcomm.com >=0D=0A=09=0D =0A=20<057632CE4CE10D45A1A3D6D19206C3A3D6CA033D@NASANEXMB 08.na.qualcomm.com>,<4924C84D.8060405@kddilabs.jp>=0D=0A =20<057632CE4CE10D45A1A3D6D19206C3A3D6CC34DC@NASANEXMB08. na.qualcomm.com>=0D=0A=20<49253338.4030905@kddilabs.jp> |In-Reply-To:=20<49253338.4030905@kddilabs.jp> |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,5439"=3B=20a=3D"13335509"; bh=ivLrmjwYmQW/bM2QnADYQc0rjRh0p9LcvTccGzKRH1U=; b=oN8Juvy3O65VECvHyZaWjbtFlaTS4bcxRGw79CZTkQ5l557Idrzp0wSt 3NEdrWR/QEiL4Q3PKbRJ9fMZHgqEk/Pf3XCIDv7Ij1rc5aD8orgvdM0hh I2dAnBuglg9LPioOizfBpgrFATuhjv1toudD+9EREMQMAjuF/y4GVy+Bu s=; X-IronPort-AV: E=McAfee;i="5300,2777,5439"; a="13335509" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2008 09:30:13 -0800 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 mAKHUDK5004111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Nov 2008 09:30:13 -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 mAKHU0Nr013479 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Nov 2008 09:30:12 -0800 (PST) Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.132]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Thu, 20 Nov 2008 09:29:59 -0800 From: "Giaretta, Gerardo" To: Kazuyuki Tasaka Date: Thu, 20 Nov 2008 09:29:58 -0800 Thread-Topic: [MEXT] Flow description in draft-ietf-mext-flow-binding Thread-Index: AclK9Yvzn/jbsmDnQQiPmfpgsSjG1QAP6z5w Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D6CA0402@NASANEXMB08.na.qualcomm.com> References: <057632CE4CE10D45A1A3D6D19206C3A3D6CA0338@NASANEXMB08.na.qualcomm.com> <057632CE4CE10D45A1A3D6D19206C3A3D6CA033D@NASANEXMB08.na.qualcomm.com>, <4924C84D.8060405@kddilabs.jp> <057632CE4CE10D45A1A3D6D19206C3A3D6CC34DC@NASANEXMB08.na.qualcomm.com> <49253338.4030905@kddilabs.jp> In-Reply-To: <49253338.4030905@kddilabs.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "mext@ietf.org" , Basavaraj Patil Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Kazuyuki, I think what you are proposing is exactly the opposite of what I was proposing so I am not sure I can agree :-) Let's see if others have any opinion. As I mentioned, I am fine documenting both scheme and make them optional, i.e. leave to the deployment which scheme to use. This may end up with some interop issues but it is also true that different deployments have different requirements. My point was just to document the binary scheme in the basic draft as it seems quite straightforward and easy to add to the draft (it was already there indeed). However I am also fine having a separate draft also for the binary scheme if this is what the WG prefers. Gerardo > -----Original Message----- > From: Kazuyuki Tasaka [mailto:ka-tasaka@kddilabs.jp] > Sent: Thursday, November 20, 2008 1:52 AM > To: Giaretta, Gerardo > Cc: Basavaraj Patil; Conny Larsson; mext@ietf.org > Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding > > Hi Gerardo, > > I think that the flow description should be defined in another > document(e.g. draft-larsson). This is the WG decision. > On the other hand, I agree to specify one reference example > (e.g. example for binary encoding) in flow-binding. > > So, "The MN MAY use the encoding specified in draft-larsson as flow > description. At this time, the MN MAY handle not only data stored in > the ASCII form but also data stored in binary data structures for > saving bandwidth. In this case, MN SHULD use a mobility option for > binary encoding". > > Regards, > Kazuyuki. > > Giaretta, Gerardo Wrote: > > Hi Kazuyuki, > > > > I don't fully understand your proposal. I don't think we should mention QoS > requests in the document; I used that as an example of how binary encoding is > used in other SDO. > > > > My proposal would be to specify a simple mobility option for binary encoding > in draft-ietf-mext-flow-binding. The draft will state something like the > following: > > > > "The MN MAY use this binary encoding specified in this draft as Flow > Description. Alternatively the MN MAY use the encoding specified in draft- > larsson." > > > > In this way we capture both solutions and we don't prioritize any of them. > > > > Would that be acceptable? > > > > Thanks > > Gerardo > > > > ________________________________________ > > From: Kazuyuki Tasaka [ka-tasaka@kddilabs.jp] > > Sent: Wednesday, November 19, 2008 6:15 PM > > To: Giaretta, Gerardo > > Cc: Basavaraj Patil; Conny Larsson; mext@ietf.org > > Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding > > > > Hi Gerardo, > > > > My understanding is that your point is use of simple 5-tuples as > > flow description and transportation of binary encoded them for > > saving bandwidth. > > > > I think that this is one basic example for QoS reservations and > > requests and is very simple. But this is not generic. > > > > So, I propose to describe it in both documents (Flow binding and > > Flow distribution) as one example for QoS reservations and requests. > > > > For example, in flow binding document, we include that flow description > > SHOULD be used binary encoded 5-tuples in case of QoS reservations and > > resuests. > > On the other hand, in flow destribution document, we define more generic > > routing rules and include that the number of routing rules SHOULD be > > minimize (e.g. 5-tuples) in case of it. > > Now, in flow destribution document, it is described that routing rules > > could be stored in a file system in the ASCII form, but they could also > > be stored in, e.g., in-core (binary) data structures. > > > > What do you think this? > > > > Regards, > > Kazuyuki. > > > > Giaretta, Gerardo Wrote: > >> Hi Raj, > >> > >> The point is that in some scenarios what the MN needs to communicate to the > HA are simple 5-tuples, most of them may even contain wild-carded values. The > amount and the details of information carried over SIP is different. > >> > >> I am not proposing the binary encoding should be the default. I am saying > it is simple enough to document it in the basic draft (we basically need one > mobility option). I am fine if we move forward also draft-larsson at the same > time and we include references in the flow binding draft. > >> > >> Gerardo > >> > >> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > >> Sent: Wednesday, November 19, 2008 1:22 PM > >> To: Giaretta, Gerardo; Conny Larsson > >> Cc: mext@ietf.org > >> Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding > >> > >> > >> Hi Gerardo, > >> > >> The bandwidth efficiency of binary encoding is true in general. > >> However if you look at SIP for example, why did they choose to not specify > it with binary encoding? > >> > >> There is value with the Ascii encoding model. I just don't know if there is > a need to be highly optimized here to choose the binary encoding format as the > default. > >> > >> -Raj > >> > >> > >> On 11/19/08 3:15 PM, "Giaretta Gerardo" wrote: > >> Hi Conny, > >> > >> I think the point is that binary encoding is more bandwidth efficient. If > we consider 3GPP as an example, the binary encoding is used for QoS > reservations and requests. In my view we could use a similar binary encoding > also for flow mobility and document that in the basic draft. > >> > >> I see the argument of flexibility but this comes to a cost. Pointing to > draft-larsson for more flexible encoding is fine to me but I don't think that > should be the basic model. > >> > >> Cheers > >> Gerardo > >> > >> > >> From: Conny Larsson [mailto:conny.larsson@ericsson.com] > >> Sent: Wednesday, November 19, 2008 11:26 AM > >> To: Giaretta, Gerardo > >> Cc: stu.card@critical.com; mext@ietf.org > >> Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding > >> > >> Hi Gerardo, > >> > >> I have difficulties to comment on your flexibility/efficiency statement > since I have not implemented any of the solutions (binary encoding/ASCII-based > encoding). However, one of my colleagues has made an implementation of the > ASCII-based solution, as specified in http://tools.ietf.org/id/draft-larsson- > mext-flow-distribution-rules-01.txt, and according to him it was easy to > implement and caused no major problems. We even have a prototype on Linux up > and running and it works perfectly well for distributing flows simultaneously > among three different interfaces. > >> > >> You are saying "What I would like to avoid is to not have any of those in > the current draft. At least one of these should be specified in the base draft > in order to have a complete solution.". Could you please elaborate a little > bit more why you think draft-larsson-mext-flow-distribution-rules would not do > the work sufficiently? > >> > >> My proposal is of course to specify a reference to draft-larsson and get a > flexible solution from the beginning. > >> > >> Regards > >> Conny > >> > >> > >> Giaretta, Gerardo wrote: > >> I definitely agree with you on the importance of long term and flexible > solutions. My point is that there are probably different scenarios with > different requirements and in some of them it makes sense to use binary > encoding (which is less flexible but more efficient) and in some other it > makes sense to use ASCII-based encoding. > >> > >> What I would like to avoid is to not have any of those in the current > draft. At least one of these should be specified in the base draft in order to > have a complete solution. I think we should go for the binary solution (which > was originally part of the I-D indeed) as it requires less work and can be > seen as the basic solution. In the meanwhile we can focus on an ASCII-based > solution which is more flexible but would require some more work. > >> > >> Gerardo > >> > >> > >> -----Original Message----- > >> From: Stuart W. Card [mailto:stu.card@critical.com] > >> Sent: Wednesday, November 19, 2008 10:25 AM > >> To: Giaretta, Gerardo > >> Cc: mext@ietf.org > >> Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding > >> > >> > >> > >> ... > >> I think the support of binary description of the filters is pretty > >> straighforward and very well known in IETF. This seems to be also the > >> most reasonable solution in cellular networks where we may want to save > >> bandwidth... > >> > >> I often have to deal with _really_ slow media (2400 bps, > >> half-duplex, with > 250 mS receive-transmit turnaround). > >> So I have a great appreciation for efficient encodings. > >> > >> That said, I believe that generality, flexibility and > >> extensibility are more important to overall efficiency > >> than are the few dozen or even couple hundred bytes that > >> are saved every few seconds or minutes by encoding > >> flow descriptions in binary. > >> > >> So my point is, if we are confident that we can specify > >> a general, flexible, extensible, binary flow description > >> language, great... but I'd rather stick with inefficient > >> ASCII encodings if aren't yet to the maturity level in > >> our understanding of this problem that we can retain > >> those essential characteristics in a binary encoding. > >> > >> Sorry to bore you all with fuzzy philosophical ramblings > >> but I think the long- versus short-term efficiency tradeoff > >> is point that should not be forgotten. Thanks! > >> > >> -- > >> Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. > >> * Creativity * Diversity * Expertise * Flexibility * Integrity * > >> Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 > >> 315-793-0248 x141 FAX -9710 > www.critical.com > >> > >> > >> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > >> ________________________________ > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > >> > >> > >> ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 20 09:42:11 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EB533A68BE; Thu, 20 Nov 2008 09:42:11 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DEE03A68BE for ; Thu, 20 Nov 2008 09:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 ZoscMPY7mBFF for ; Thu, 20 Nov 2008 09:42:07 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 940573A6852 for ; Thu, 20 Nov 2008 09:42:06 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1E34121D98; Thu, 20 Nov 2008 18:42:04 +0100 (CET) X-AuditID: c1b4fb3e-aff88bb00000537b-09-4925a16b3e12 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C32182241A; Thu, 20 Nov 2008 18:42:03 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 18:42:02 +0100 Received: from [127.0.0.1] ([153.88.48.108]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 18:42:00 +0100 Message-ID: <4925A164.3050004@ericsson.com> Date: Thu, 20 Nov 2008 18:41:56 +0100 From: Conny Larsson User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: <057632CE4CE10D45A1A3D6D19206C3A3D6CA0338@NASANEXMB08.na.qualcomm.com> <057632CE4CE10D45A1A3D6D19206C3A3D6CA033D@NASANEXMB08.na.qualcomm.com>, <4924C84D.8060405@kddilabs.jp> <057632CE4CE10D45A1A3D6D19206C3A3D6CC34DC@NASANEXMB08.na.qualcomm.com> <49253338.4030905@kddilabs.jp> <057632CE4CE10D45A1A3D6D19206C3A3D6CA0402@NASANEXMB08.na.qualcomm.com> In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D6CA0402@NASANEXMB08.na.qualcomm.com> X-OriginalArrivalTime: 20 Nov 2008 17:42:01.0002 (UTC) FILETIME=[4AFB08A0:01C94B37] X-Brightmail-Tracker: AAAAAA== Cc: "mext@ietf.org" , Basavaraj Patil Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0096093725==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0096093725== Content-Type: multipart/alternative; boundary="------------000602000908010300000404" This is a multi-part message in MIME format. --------------000602000908010300000404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Gerardo, I'm in favour of having the flow description in separate documents. That's actually the reason for removing what was originally in Hesham's draft and making it a pure protocol for transferring those flow descriptions. The drawback with having two schemes is of course that you have to agree upon which one to use and in the case you don't support it you need to inform the other side of the shortcomings. But this can probably be solved quite easy in Hesham's draft. Regards Conny Giaretta, Gerardo wrote: > Hi Kazuyuki, > > I think what you are proposing is exactly the opposite of what I was proposing so I am not sure I can agree :-) > > Let's see if others have any opinion. As I mentioned, I am fine documenting both scheme and make them optional, i.e. leave to the deployment which scheme to use. This may end up with some interop issues but it is also true that different deployments have different requirements. > > My point was just to document the binary scheme in the basic draft as it seems quite straightforward and easy to add to the draft (it was already there indeed). However I am also fine having a separate draft also for the binary scheme if this is what the WG prefers. > > Gerardo > > >> -----Original Message----- >> From: Kazuyuki Tasaka [mailto:ka-tasaka@kddilabs.jp] >> Sent: Thursday, November 20, 2008 1:52 AM >> To: Giaretta, Gerardo >> Cc: Basavaraj Patil; Conny Larsson; mext@ietf.org >> Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding >> >> Hi Gerardo, >> >> I think that the flow description should be defined in another >> document(e.g. draft-larsson). This is the WG decision. >> On the other hand, I agree to specify one reference example >> (e.g. example for binary encoding) in flow-binding. >> >> So, "The MN MAY use the encoding specified in draft-larsson as flow >> description. At this time, the MN MAY handle not only data stored in >> the ASCII form but also data stored in binary data structures for >> saving bandwidth. In this case, MN SHULD use a mobility option for >> binary encoding". >> >> Regards, >> Kazuyuki. >> >> Giaretta, Gerardo Wrote: >> >>> Hi Kazuyuki, >>> >>> I don't fully understand your proposal. I don't think we should mention QoS >>> >> requests in the document; I used that as an example of how binary encoding is >> used in other SDO. >> >>> My proposal would be to specify a simple mobility option for binary encoding >>> >> in draft-ietf-mext-flow-binding. The draft will state something like the >> following: >> >>> "The MN MAY use this binary encoding specified in this draft as Flow >>> >> Description. Alternatively the MN MAY use the encoding specified in draft- >> larsson." >> >>> In this way we capture both solutions and we don't prioritize any of them. >>> >>> Would that be acceptable? >>> >>> Thanks >>> Gerardo >>> >>> ________________________________________ >>> From: Kazuyuki Tasaka [ka-tasaka@kddilabs.jp] >>> Sent: Wednesday, November 19, 2008 6:15 PM >>> To: Giaretta, Gerardo >>> Cc: Basavaraj Patil; Conny Larsson; mext@ietf.org >>> Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding >>> >>> Hi Gerardo, >>> >>> My understanding is that your point is use of simple 5-tuples as >>> flow description and transportation of binary encoded them for >>> saving bandwidth. >>> >>> I think that this is one basic example for QoS reservations and >>> requests and is very simple. But this is not generic. >>> >>> So, I propose to describe it in both documents (Flow binding and >>> Flow distribution) as one example for QoS reservations and requests. >>> >>> For example, in flow binding document, we include that flow description >>> SHOULD be used binary encoded 5-tuples in case of QoS reservations and >>> resuests. >>> On the other hand, in flow destribution document, we define more generic >>> routing rules and include that the number of routing rules SHOULD be >>> minimize (e.g. 5-tuples) in case of it. >>> Now, in flow destribution document, it is described that routing rules >>> could be stored in a file system in the ASCII form, but they could also >>> be stored in, e.g., in-core (binary) data structures. >>> >>> What do you think this? >>> >>> Regards, >>> Kazuyuki. >>> >>> Giaretta, Gerardo Wrote: >>> >>>> Hi Raj, >>>> >>>> The point is that in some scenarios what the MN needs to communicate to the >>>> >> HA are simple 5-tuples, most of them may even contain wild-carded values. The >> amount and the details of information carried over SIP is different. >> >>>> I am not proposing the binary encoding should be the default. I am saying >>>> >> it is simple enough to document it in the basic draft (we basically need one >> mobility option). I am fine if we move forward also draft-larsson at the same >> time and we include references in the flow binding draft. >> >>>> Gerardo >>>> >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] >>>> Sent: Wednesday, November 19, 2008 1:22 PM >>>> To: Giaretta, Gerardo; Conny Larsson >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding >>>> >>>> >>>> Hi Gerardo, >>>> >>>> The bandwidth efficiency of binary encoding is true in general. >>>> However if you look at SIP for example, why did they choose to not specify >>>> >> it with binary encoding? >> >>>> There is value with the Ascii encoding model. I just don't know if there is >>>> >> a need to be highly optimized here to choose the binary encoding format as the >> default. >> >>>> -Raj >>>> >>>> >>>> On 11/19/08 3:15 PM, "Giaretta Gerardo" wrote: >>>> Hi Conny, >>>> >>>> I think the point is that binary encoding is more bandwidth efficient. If >>>> >> we consider 3GPP as an example, the binary encoding is used for QoS >> reservations and requests. In my view we could use a similar binary encoding >> also for flow mobility and document that in the basic draft. >> >>>> I see the argument of flexibility but this comes to a cost. Pointing to >>>> >> draft-larsson for more flexible encoding is fine to me but I don't think that >> should be the basic model. >> >>>> Cheers >>>> Gerardo >>>> >>>> >>>> From: Conny Larsson [mailto:conny.larsson@ericsson.com] >>>> Sent: Wednesday, November 19, 2008 11:26 AM >>>> To: Giaretta, Gerardo >>>> Cc: stu.card@critical.com; mext@ietf.org >>>> Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding >>>> >>>> Hi Gerardo, >>>> >>>> I have difficulties to comment on your flexibility/efficiency statement >>>> >> since I have not implemented any of the solutions (binary encoding/ASCII-based >> encoding). However, one of my colleagues has made an implementation of the >> ASCII-based solution, as specified in http://tools.ietf.org/id/draft-larsson- >> mext-flow-distribution-rules-01.txt, and according to him it was easy to >> implement and caused no major problems. We even have a prototype on Linux up >> and running and it works perfectly well for distributing flows simultaneously >> among three different interfaces. >> >>>> You are saying "What I would like to avoid is to not have any of those in >>>> >> the current draft. At least one of these should be specified in the base draft >> in order to have a complete solution.". Could you please elaborate a little >> bit more why you think draft-larsson-mext-flow-distribution-rules would not do >> the work sufficiently? >> >>>> My proposal is of course to specify a reference to draft-larsson and get a >>>> >> flexible solution from the beginning. >> >>>> Regards >>>> Conny >>>> >>>> >>>> Giaretta, Gerardo wrote: >>>> I definitely agree with you on the importance of long term and flexible >>>> >> solutions. My point is that there are probably different scenarios with >> different requirements and in some of them it makes sense to use binary >> encoding (which is less flexible but more efficient) and in some other it >> makes sense to use ASCII-based encoding. >> >>>> What I would like to avoid is to not have any of those in the current >>>> >> draft. At least one of these should be specified in the base draft in order to >> have a complete solution. I think we should go for the binary solution (which >> was originally part of the I-D indeed) as it requires less work and can be >> seen as the basic solution. In the meanwhile we can focus on an ASCII-based >> solution which is more flexible but would require some more work. >> >>>> Gerardo >>>> >>>> >>>> -----Original Message----- >>>> From: Stuart W. Card [mailto:stu.card@critical.com] >>>> Sent: Wednesday, November 19, 2008 10:25 AM >>>> To: Giaretta, Gerardo >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding >>>> >>>> >>>> >>>> ... >>>> I think the support of binary description of the filters is pretty >>>> straighforward and very well known in IETF. This seems to be also the >>>> most reasonable solution in cellular networks where we may want to save >>>> bandwidth... >>>> >>>> I often have to deal with _really_ slow media (2400 bps, >>>> half-duplex, with > 250 mS receive-transmit turnaround). >>>> So I have a great appreciation for efficient encodings. >>>> >>>> That said, I believe that generality, flexibility and >>>> extensibility are more important to overall efficiency >>>> than are the few dozen or even couple hundred bytes that >>>> are saved every few seconds or minutes by encoding >>>> flow descriptions in binary. >>>> >>>> So my point is, if we are confident that we can specify >>>> a general, flexible, extensible, binary flow description >>>> language, great... but I'd rather stick with inefficient >>>> ASCII encodings if aren't yet to the maturity level in >>>> our understanding of this problem that we can retain >>>> those essential characteristics in a binary encoding. >>>> >>>> Sorry to bore you all with fuzzy philosophical ramblings >>>> but I think the long- versus short-term efficiency tradeoff >>>> is point that should not be forgotten. Thanks! >>>> >>>> -- >>>> Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. >>>> * Creativity * Diversity * Expertise * Flexibility * Integrity * >>>> Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 >>>> 315-793-0248 x141 FAX -9710 >>>> >> www.critical.com >> >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> 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 >>>> > > --------------000602000908010300000404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Gerardo,

I'm in favour of having the flow description in separate documents. That's actually the reason for removing what was originally in Hesham's draft and making it a pure protocol for transferring those flow descriptions.

The drawback with having two schemes is of course that you have to agree upon which one to use and in the case you don't support it you need to inform the other side of the shortcomings. But this can probably be solved quite easy in Hesham's draft.

Regards
Conny

Giaretta, Gerardo wrote: 
Hi Kazuyuki,

I think what you are proposing is exactly the opposite of what I was proposing so I am not sure I can agree :-)

Let's see if others have any opinion. As I mentioned, I am fine documenting both scheme and make them optional, i.e. leave to the deployment which scheme to use. This may end up with some interop issues but it is also true that different deployments have different requirements. 

My point was just to document the binary scheme in the basic draft as it seems quite straightforward and easy to add to the draft (it was already there indeed). However I am also fine having a separate draft also for the binary scheme if this is what the WG prefers. 

Gerardo

  
-----Original Message-----
From: Kazuyuki Tasaka [mailto:ka-tasaka@kddilabs.jp]
Sent: Thursday, November 20, 2008 1:52 AM
To: Giaretta, Gerardo
Cc: Basavaraj Patil; Conny Larsson; mext@ietf.org
Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding

Hi Gerardo,

I think that the flow description should be defined in another
document(e.g. draft-larsson). This is the WG decision.
On the other hand, I agree to specify one reference example
(e.g. example for binary encoding) in flow-binding.

So, "The MN MAY use the encoding specified in draft-larsson as flow
description. At this time, the MN MAY handle not only data stored in
the ASCII form but also data stored in binary data structures for
saving bandwidth. In this case, MN SHULD use a mobility option for
binary encoding".

Regards,
Kazuyuki.

Giaretta, Gerardo Wrote:
    
Hi Kazuyuki,

I don't fully understand your proposal. I don't think we should mention QoS
      
requests in the document; I used that as an example of how binary encoding is
used in other SDO.
    
My proposal would be to specify a simple mobility option for binary encoding
      
in draft-ietf-mext-flow-binding. The draft will state something like the
following:
    
"The MN MAY use this binary encoding specified in this draft as Flow
      
Description. Alternatively the MN MAY use the encoding specified in draft-
larsson."
    
In this way we capture both solutions and we don't prioritize any of them.

Would that be acceptable?

Thanks
Gerardo

________________________________________
From: Kazuyuki Tasaka [ka-tasaka@kddilabs.jp]
Sent: Wednesday, November 19, 2008 6:15 PM
To: Giaretta, Gerardo
Cc: Basavaraj Patil; Conny Larsson; mext@ietf.org
Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding

Hi Gerardo,

My understanding is that your point is use of simple 5-tuples as
flow description and transportation of binary encoded them for
saving bandwidth.

I think that this is one basic example for QoS reservations and
requests and is very simple. But this is not generic.

So, I propose to describe it in both documents (Flow binding and
Flow distribution) as one example for QoS reservations and requests.

For example, in flow binding document, we include that flow description
SHOULD be used binary encoded 5-tuples in case of QoS reservations and
resuests.
On the other hand, in flow destribution document, we define more generic
  routing rules and include that the number of routing rules SHOULD be
minimize (e.g. 5-tuples) in case of it.
Now, in flow destribution document, it is described that routing rules
could be stored in a file system in the ASCII form, but they could also
be stored in, e.g., in-core (binary) data structures.

What do you think this?

Regards,
Kazuyuki.

Giaretta, Gerardo Wrote:
      
Hi Raj,

The point is that in some scenarios what the MN needs to communicate to the
        
HA are simple 5-tuples, most of them may even contain wild-carded values. The
amount and the details of information carried over SIP is different.
    
I am not proposing the binary encoding should be the default. I am saying
        
it is simple enough to document it in the basic draft (we basically need one
mobility option). I am fine if we move forward also draft-larsson at the same
time and we include references in the flow binding draft.
    
Gerardo

From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com]
Sent: Wednesday, November 19, 2008 1:22 PM
To: Giaretta, Gerardo; Conny Larsson
Cc: mext@ietf.org
Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding


Hi Gerardo,

The bandwidth efficiency of binary encoding is true in general.
However if you look at SIP for example, why did they choose to not specify
        
it with binary encoding?
    
There is value with the Ascii encoding model. I just don't know if there is
        
a need to be highly optimized here to choose the binary encoding format as the
default.
    
-Raj


On 11/19/08 3:15 PM, "Giaretta Gerardo" <gerardog@qualcomm.com> wrote:
Hi Conny,

I think the point is that binary encoding is more bandwidth efficient. If
        
we consider 3GPP as an example, the binary encoding is used for QoS
reservations and requests. In my view we could use a similar binary encoding
also for flow mobility and document that in the basic draft.
    
I see the argument of flexibility but this comes to a cost. Pointing to
        
draft-larsson for more flexible encoding is fine to me but I don't think that
should be the basic model.
    
Cheers
Gerardo


From: Conny Larsson [mailto:conny.larsson@ericsson.com]
Sent: Wednesday, November 19, 2008 11:26 AM
To: Giaretta, Gerardo
Cc: stu.card@critical.com; mext@ietf.org
Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding

Hi Gerardo,

I have difficulties to comment on your flexibility/efficiency statement
        
since I have not implemented any of the solutions (binary encoding/ASCII-based
encoding). However, one of my colleagues has made an implementation of the
ASCII-based solution, as specified in http://tools.ietf.org/id/draft-larsson-
mext-flow-distribution-rules-01.txt, and according to him it was easy to
implement and caused no major problems. We even have a prototype on Linux up
and running and it works perfectly well for distributing flows simultaneously
among three different interfaces.
    
You are saying "What I would like to avoid is to not have any of those in
        
the current draft. At least one of these should be specified in the base draft
in order to have a complete solution.". Could you please elaborate a little
bit more why you think draft-larsson-mext-flow-distribution-rules would not do
the work sufficiently?
    
My proposal is of course to specify a reference to draft-larsson and get a
        
flexible solution from the beginning.
    
Regards
Conny


Giaretta, Gerardo wrote:
I definitely agree with you on the importance of long term and flexible
        
solutions. My point is that there are probably different scenarios with
different requirements and in some of them it makes sense to use binary
encoding (which is less flexible but more efficient) and in some other it
makes sense to use ASCII-based encoding.
    
What I would like to avoid is to not have any of those in the current
        
draft. At least one of these should be specified in the base draft in order to
have a complete solution. I think we should go for the binary solution (which
was originally part of the I-D indeed) as it requires less work and can be
seen as the basic solution. In the meanwhile we can focus on an ASCII-based
solution which is more flexible but would require some more work.
    
Gerardo


-----Original Message-----
From: Stuart W. Card [mailto:stu.card@critical.com]
Sent: Wednesday, November 19, 2008 10:25 AM
To: Giaretta, Gerardo
Cc: mext@ietf.org
Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding



...
I think the support of binary description of the filters is pretty
straighforward and very well known in IETF. This seems to be also the
most reasonable solution in cellular networks where we may want to save
bandwidth...

I often have to deal with _really_ slow media (2400 bps,
half-duplex, with > 250 mS receive-transmit turnaround).
So I have a great appreciation for efficient encodings.

That said, I believe that generality, flexibility and
extensibility are more important to overall efficiency
than are the few dozen or even couple hundred bytes that
are saved every few seconds or minutes by encoding
flow descriptions in binary.

So my point is, if we are confident that we can specify
a general, flexible, extensible, binary flow description
language, great... but I'd rather stick with inefficient
ASCII encodings if aren't yet to the maturity level in
our understanding of this problem that we can retain
those essential characteristics in a binary encoding.

Sorry to bore you all with fuzzy philosophical ramblings
but I think the long- versus short-term efficiency tradeoff
is point that should not be forgotten. Thanks!

--
Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc.
* Creativity * Diversity * Expertise * Flexibility * Integrity *
Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501
315-793-0248 x141 FAX -9710 <Stu.Card@critical.com>
        
<mailto:Stu.Card@critical.com>  www.critical.com <http://www.critical.com>
    


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

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



------------------------------------------------------------------------

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
--------------000602000908010300000404-- --===============0096093725== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0096093725==-- From mext-bounces@ietf.org Thu Nov 20 11:35:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66D063A6996; Thu, 20 Nov 2008 11:35:04 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5FD13A6996 for ; Thu, 20 Nov 2008 11:35:02 -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 ShHMyL04HE+N for ; Thu, 20 Nov 2008 11:35:02 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id D5DA23A6992 for ; Thu, 20 Nov 2008 11:35:01 -0800 (PST) Received: from [10.166.254.150] ([75.26.137.116]) by outbound.mse15.exchange.ms with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 14:34:56 -0500 Message-ID: <4925BBDC.1000603@wichorus.com> Date: Thu, 20 Nov 2008 11:34:52 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Alper Yegin References: <025e01c94a87$8ab61940$a0224bc0$@yegin@yegin.org> In-Reply-To: <025e01c94a87$8ab61940$a0224bc0$@yegin@yegin.org> X-OriginalArrivalTime: 20 Nov 2008 19:34:56.0617 (UTC) FILETIME=[118FD590:01C94B47] Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] issue 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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Alper, It is not really a bug in RFC 3775. RFC 3775 never considered separation = of control and data plane for the mobile node and the home agent. You = are asking for the HA to store both the source address of the BU and the = address in the AltCoA option in the binding cache entry if the two = happen to be different. And further you want all signaling messages to = be sent to the source address in the BU and the data packets sent to the = address in the AltCoA option. IMO, this would be a new feature in RFC = 3775, not a bug fix. :) Vijay Alper Yegin wrote: > Following the discussions we had on the reflector, I think the RFC = > 3775bis needs improvement for use of Alt-CoA option and BA destination = > address. > = > = > = > = > = > The spec clearly states that the BA is sent back to the source IP = > address of the BU (not to CoA, which may be different when Alt CoA is use= d): > = > = > = > If the Source Address field of the IPv6 header that carried the > = > Binding Update does not contain a unicast address, the Binding > = > Acknowledgement MUST NOT be sent and the Binding Update packet MUST > = > be silently discarded. Otherwise, the acknowledgement MUST be sent > = > to the Source Address. > = > = > = > = > = > I=92m not sure if this deserves additional clarification/specification = > text. Vijay believes there is an issue in the absence of further text = > that talks about how HA stores the source IP address of the last = > received BU. I agree that is needed for revocation spec and it can be = > specified there as one option. > = > = > = > Any thoughts? Is there anything we need to do in RFC 3775bis? > = > = > = > = > Alper > = > = > = > = > = > = > = > = > = > = > = > = > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 20 11:40:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23B5928C212; Thu, 20 Nov 2008 11:40:55 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C604B28C114 for ; Thu, 20 Nov 2008 11:40:53 -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 wnLMyOqONKK9 for ; Thu, 20 Nov 2008 11:40:52 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 5269728C212 for ; Thu, 20 Nov 2008 11:40:52 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 14:40:50 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Separation of Control and Data Plane for PMIPv6 Thread-Index: Ack5K6Ua8u8nN5EBQzWFyoMhfjU/XQSHAeTg From: "Vijay Devarapalli" To: "Sri Gundavelli" Cc: mext Subject: [MEXT] FW: [netlmm] Separation of Control and Data Plane for PMIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Sri, You did not respond to the following email. The text in RFC 5213 is not sufficient for separation of control and data plane using altCoA option. Vijay -----Original Message----- From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On Behalf Of Vijay Devarapalli Sent: Tuesday, October 28, 2008 11:33 AM To: Sri Gundavelli Cc: netlmm@ietf.org Subject: Re: [netlmm] Separation of Control and Data Plane for PMIPv6 Hi Sri, Sri Gundavelli wrote: > Hi Vijay, > > >>> >>> The primary purpose of Alt-CoA option is the control/data plane >>> seperation. >> >> Where is this explained in RFC 3775? I repeat, separation of control and >> data plane for a Mobile IPv6 mobile node does not make sense. >> > > Its not about the presence of the phrase "Control Plane/Data Plane > seperation". The option can be used that way and cant see why it > wont work. This is actually a mis-use of the AltCoA option. It was not intended for supporting the separation of control and data plane. Even if you do want to use the AltCoA option for this purpose, the specifications are missing. More below. > If not, why is the use of Alt-CoA even made it to 5213 ? RFC 5213 does not specify the separation of control and data plane. For instance, see the following text fragments from 5213. Section 5.3.6 o The Destination Address field in the IPv6 header of the message MUST be set to the source address of the received Proxy Binding Update message. When there is no Alternate Care-of Address option present in the request, the destination address is the same as the Proxy-CoA; otherwise, the address may not be the same as the Proxy-CoA. What does "may not be the same" mean? If you had intended to use this for control and data plane separation, the above paragraph should have said, if there is an alternate care-of address option present and if the address in the option is different from the source address of the received PBU, then the destination address on the PBACK MUST be set to the source address of the received PBU. Otherwise it is not guaranteed to work. It becomes LMA implementation specific. Section 6.9.1.5 o The Source Address field in the IPv6 header of the message MUST be set to the global address configured on the egress interface of the mobile access gateway. When there is no Alternate Care-of Address option present in the request, this address will be considered as the Proxy-CoA for this Proxy Binding Update message. However, when there is an Alternate Care-of Address option present in the request, this address will be not be considered as the Proxy-CoA, but the address in the Alternate Care-of Address option will be considered as the Proxy-CoA. The above paragraph tells me that the contents of the AltCoA option should be stored as the Proxy CoA. When the LMA needs to send a binding revocation message, where would it send the message to? There is no guarantee that the LMA will store the source address of the original PBU, since none of the specifications told the LMA to do this. Another example is the HA/LMA Switch Message [RFC 5142]. Where would this message be sent to? IMO, it is not possible to implement separation of control and data plane using RFC 5213 and the alternate CoA option. You have to make a lot of assumptions. Perhaps you had it figured out how to implement this, but it is not specified in the document. One option is to revise RFC 5213 and describe clearly how to use the AltCoA option to separate control and data plane. Another option is to develop a clean solution to separate the concepts of Proxy CoA and Data Plane Address. The Proxy CoA would be used for all control plane signaling and the Data Plane address would be used for tunneling data traffic. I of course prefer the cleaner solution. > Again, refer to discussions from Anand Bedekar and others. The mailing list or the off line discussions? We had a lot of discussions on the separation of control and data plane when PMIPv6 was being adopted by the NETLMM WG. We decided to come back to this later after specifying the basic PMIPv6 protocol assuming the control and data plane end-points are co-located. And thats what we did. Do you remember something different? Vijay > > >>> > Second, the missing parameter that you suggest is actually quite >>> > significant. Neither RFC 5213 or 3775 mention that the HA/LMA should >>> > store the source address of the original BU/PBU if the altCoA >>> option is >>> > present. Only the contents of the altCoA is stored in the binding >>> cache >>> > entry. DS-MIPv6, OTOH, says that if the source address on the >>> outer IPv4 >>> > header is different from the IPv4 care-of address option (the >>> equivalent >>> > of the AltCoA option), then in fact the source address on the >>> outer IPv4 >>> > header should be stored as the CoA. The IPv4 care-of address option >>> > contents are not stored. Therefore, at any time, there is only one >>> > address stored in the binding cache entry. A MAG or a mobile node >>> cannot >>> > be sure that the LMA/HA did store two different addresses. So the >>> > separation of control and data plane will not work. >>> > >>> >>> What is stored and what is not stored is an implementation issue. >> >> It is not. Unless the MAG knows that the LMA did store both addresses, >> the MAG cannot be sure the LMA does support this. >> > > If the option is present, the LMA must preserve it, else its a software > defect. When there is Alt-CoA option in the BU request, if the client > does not store it, where is the BA message being sent ? > > >> From >>> the perspective of protocol interoperability, we require a given >>> message >>> to be sent to a specific address. If that address that is obtained in >>> the prior state of the protocol is cached or not, is not a protocol >>> issue, its an implementation issue. The conceptual data structure is a >>> general recommendation/aid to implementations, its presence/absence has >>> no bearing on the wire protocol messages. Many protocols dont have this >>> conceptual structure at all, its a good practice to provide that in the >>> specs. >>> >>> >>> > Third, any message that is initiated by the HA/LMA will be sent to >>> the >>> > CoA or Proxy CoA. Not to the source address of the original >>> BU/PBU. Even >>> > the BACK/PBACK is not guaranteed to be sent to the source address >>> on the >>> > original BU/PBU. Implementations have done it differently, i.e., used >>> > the contents of the binding cache entry to construct the BACK/PBACK. >>> > >>> >>> When the BU/PBU that triggered the registration has an Alt-CoA option, >>> any explicit signaling messages should be sent to the source address >>> and >>> not to the CoA/Proxy-CoA. >> >> Where is this specified? >> > > Again, where is BA message sent when this option is present ? > > >>> > Finally, fixing this in 3775-bis does not make sense to me, since I >>> > don't believe a mobile node will ever use this feature. It is not >>> > required for Mobile IPv6. >>> > >>> >>> Alt-CoA option is specified in 3775 and the related parameters have to >>> added to that spec and even if its not used by a mobile node. >> >> This defies logic. :) >> > > The option that is defined in 3775 is the sole reason why the source > and CoA addresses would be different and so it must be defined there. > Where else ? > > > Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www.ietf.org/mailman/listinfo/netlmm _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 20 11:52:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB7B3A6813; Thu, 20 Nov 2008 11:52:01 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 484C93A6813 for ; Thu, 20 Nov 2008 11:52:00 -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 pNkeC9G1EXlp for ; Thu, 20 Nov 2008 11:51:59 -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 8F2B03A677D for ; Thu, 20 Nov 2008 11:51:59 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so584816rvf.49 for ; Thu, 20 Nov 2008 11:51:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=WUQsX4V38RLBV9XcvEYfAdWmPslic6Rl60D4bmJJBoE=; b=ltlFICuGto1fAf6CgmRi8K7mbvjHTRopw2tUVymXLqa8JfYEfib5N2JIA0syNgo0me 8ozL+69MEMO4Ln+q0QVCEy+7VF+J0fo/+SEI3yPy/yXdjKyhQWUVMiB5RdQEeGKDljEV l8HiKhyIdRlFdCe7Ii4xef8FyDl6lKqWAbigE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=IiRsEyNgv4aENW49Ow2H132XAteKvypLpujzFG7BrpwPzRtg+/j6h24SBlTOHb/wTx AaNxc8iQIrKicg1dWLL5N8/VyB2Y9uTQhFK7zBz4Izz8O8YA5r3vXANzCu07rGcjxpwM kClfqvPspLADrGUK4gX7sX69I8ETHCqq+toh8= Received: by 10.141.36.10 with SMTP id o10mr1401862rvj.258.1227210718363; Thu, 20 Nov 2008 11:51:58 -0800 (PST) Received: from ?130.129.94.239? ([130.129.94.239]) by mx.google.com with ESMTPS id f42sm1845096rvb.6.2008.11.20.11.51.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 20 Nov 2008 11:51:57 -0800 (PST) Message-Id: From: Ryuji Wakikawa To: mext Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 21 Nov 2008 04:51:56 +0900 X-Mailer: Apple Mail (2.929.2) Subject: [MEXT] BRI packet dest address X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, What is the status of this document? http://tools.ietf.org/html/draft-arkko-mext-rfc3775-altcoa-check-01 Is the proposed modification applied to 3775-bis? If yes, source address of BU and CoA must be same all the time. regards, ryuji _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 20 11:55:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A12728C1D0; Thu, 20 Nov 2008 11:55:39 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E491D28C23B for ; Thu, 20 Nov 2008 11:55:37 -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 gOPRYYdDditP for ; Thu, 20 Nov 2008 11:55:37 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 0AEF028C1D0 for ; Thu, 20 Nov 2008 11:55:36 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [130.129.31.6])by smtp03.uc3m.es (Postfix) with ESMTP id 7FCF26AFA0Afor ; Thu, 20 Nov 2008 20:55:33 +0100 (CET) Message-ID: <4925C0B4.4010408@it.uc3m.es> Date: Thu, 20 Nov 2008 13:55:32 -0600 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: mext X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-1.3189 TC:1F TRN:7 TV:5.5.1026(16292.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [MEXT] Deadline for accetping 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, We are closing the rfc3775bis process. We are accepting new issues for rfc3775bis until dec 5 2008. Issues brought later than this will not be considered for this round of changes in rfc3775. Regards, Julien and marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 20 11:58:36 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61EDD3A6946; Thu, 20 Nov 2008 11:58:36 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF2183A6946 for ; Thu, 20 Nov 2008 11:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZB9vSM2n9jwO for ; Thu, 20 Nov 2008 11:58:34 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by core3.amsl.com (Postfix) with ESMTP id E50993A677D for ; Thu, 20 Nov 2008 11:58:33 -0800 (PST) Received: from LENOVO ([130.129.94.244]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1L3FfY1RlG-0006gS; Thu, 20 Nov 2008 14:58:31 -0500 From: "Alper Yegin" To: "'Vijay Devarapalli'" References: <025e01c94a87$8ab61940$a0224bc0$@yegin@yegin.org> <4925BBDC.1000603@wichorus.com> In-Reply-To: <4925BBDC.1000603@wichorus.com> Date: Thu, 20 Nov 2008 21:58:28 +0200 Message-ID: <006101c94b4a$5d6b5c70$18421550$@yegin@yegin.org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLRxHKG6Zq6tcKSmaXIcgjIyCq9AAAiaJA Content-Language: en-us X-Provags-ID: V01U2FsdGVkX18I6iB0ntpK/1Ht89Cqsu5yYzvIPVT5Jdln5Rr 2PkldRuVtzcs2II98Id6eIwkD7iN7ImxVYbtc6EVZJrPQAG0A8 raR8YvFDaE2R39IG6ES3g== Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] issue 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay, > It is not really a bug in RFC 3775. RFC 3775 never considered > separation > of control and data plane for the mobile node and the home agent. You are saying that because you don't see a section titled "Separation of Control and Data Plane" in the RFC :) If being able to send MIP signaling between IP1 and HA_IP, and getting the IP packets tunneled between IP2 and HA_IP (as this scenario is enabled by Alt-CoA today!) is not called "separation of control and data plane" in your mind, I wonder what is? > You > are asking for the HA to store both the source address of the BU and > the > address in the AltCoA option in the binding cache entry if the two > happen to be different. And further you want all signaling messages to > be sent to the source address in the BU and the data packets sent to > the > address in the AltCoA option. IMO, this would be a new feature in RFC > 3775, not a bug fix. :) Really? It's all in the RFC 3775: If the Source Address field of the IPv6 header that carried the Binding Update does not contain a unicast address, the Binding Acknowledgement MUST NOT be sent and the Binding Update packet MUST be silently discarded. Otherwise, the acknowledgement MUST be sent to the Source Address. I hope some other folks join the discussion, as this is my second pass on the same arguments with Vijay :) Alper > > Vijay > > Alper Yegin wrote: > > > Following the discussions we had on the reflector, I think the RFC > > 3775bis needs improvement for use of Alt-CoA option and BA > destination > > address. > > > > > > > > > > > > The spec clearly states that the BA is sent back to the source IP > > address of the BU (not to CoA, which may be different when Alt CoA is > used): > > > > > > > > If the Source Address field of the IPv6 header that carried the > > > > Binding Update does not contain a unicast address, the Binding > > > > Acknowledgement MUST NOT be sent and the Binding Update packet > MUST > > > > be silently discarded. Otherwise, the acknowledgement MUST be > sent > > > > to the Source Address. > > > > > > > > > > > > I'm not sure if this deserves additional clarification/specification > > text. Vijay believes there is an issue in the absence of further text > > that talks about how HA stores the source IP address of the last > > received BU. I agree that is needed for revocation spec and it can be > > specified there as one option. > > > > > > > > Any thoughts? Is there anything we need to do in RFC 3775bis? > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 20 12:04:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89463A696D; Thu, 20 Nov 2008 12:04:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30763A696D for ; Thu, 20 Nov 2008 12:04:48 -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 9da1o2DCrysP for ; Thu, 20 Nov 2008 12:04:47 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id A240E3A677D for ; Thu, 20 Nov 2008 12:04:47 -0800 (PST) Received: from [10.166.254.150] ([75.26.137.116]) by outbound.mse15.exchange.ms with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 15:04:46 -0500 Message-ID: <4925C2DB.1060701@wichorus.com> Date: Thu, 20 Nov 2008 12:04:43 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Alper Yegin References: <025e01c94a87$8ab61940$a0224bc0$@yegin@yegin.org> <4925BBDC.1000603@wichorus.com> <006101c94b4a$5d6b5c70$18421550$@yegin@yegin.org> In-Reply-To: <006101c94b4a$5d6b5c70$18421550$@yegin@yegin.org> X-OriginalArrivalTime: 20 Nov 2008 20:04:46.0518 (UTC) FILETIME=[3C6D0D60:01C94B4B] Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] issue 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alper, Well, the fact is that you need significant changes to RFC 3775 to explicitly support separation of control and data plane using the AltCoA option. You can't claim it is a "bug fix" and modify some text. :) Vijay Alper Yegin wrote: > Vijay, > > >> It is not really a bug in RFC 3775. RFC 3775 never considered >> separation >> of control and data plane for the mobile node and the home agent. > > You are saying that because you don't see a section titled "Separation of > Control and Data Plane" in the RFC :) > If being able to send MIP signaling between IP1 and HA_IP, and getting the > IP packets tunneled between IP2 and HA_IP (as this scenario is enabled by > Alt-CoA today!) is not called "separation of control and data plane" in your > mind, I wonder what is? > >> You >> are asking for the HA to store both the source address of the BU and >> the >> address in the AltCoA option in the binding cache entry if the two >> happen to be different. And further you want all signaling messages to >> be sent to the source address in the BU and the data packets sent to >> the >> address in the AltCoA option. IMO, this would be a new feature in RFC >> 3775, not a bug fix. :) > > Really? It's all in the RFC 3775: > > If the Source Address field of the IPv6 header that carried the > Binding Update does not contain a unicast address, the Binding > Acknowledgement MUST NOT be sent and the Binding Update packet MUST > be silently discarded. Otherwise, the acknowledgement MUST be sent > to the Source Address. > > > I hope some other folks join the discussion, as this is my second pass on > the same arguments with Vijay :) > > Alper > > > > > > > > > >> Vijay >> >> Alper Yegin wrote: >> >>> Following the discussions we had on the reflector, I think the RFC >>> 3775bis needs improvement for use of Alt-CoA option and BA >> destination >>> address. >>> >>> >>> >>> >>> >>> The spec clearly states that the BA is sent back to the source IP >>> address of the BU (not to CoA, which may be different when Alt CoA is >> used): >>> >>> >>> If the Source Address field of the IPv6 header that carried the >>> >>> Binding Update does not contain a unicast address, the Binding >>> >>> Acknowledgement MUST NOT be sent and the Binding Update packet >> MUST >>> be silently discarded. Otherwise, the acknowledgement MUST be >> sent >>> to the Source Address. >>> >>> >>> >>> >>> >>> I'm not sure if this deserves additional clarification/specification >>> text. Vijay believes there is an issue in the absence of further text >>> that talks about how HA stores the source IP address of the last >>> received BU. I agree that is needed for revocation spec and it can be >>> specified there as one option. >>> >>> >>> >>> Any thoughts? Is there anything we need to do in RFC 3775bis? >>> >>> >>> >>> >>> Alper >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 20 12:18:30 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89C3D3A6A22; Thu, 20 Nov 2008 12:18:30 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45D783A6A22 for ; Thu, 20 Nov 2008 12:18:29 -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 jsqquOgSMqTC for ; Thu, 20 Nov 2008 12:18:28 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 3107C3A6A09 for ; Thu, 20 Nov 2008 12:18:28 -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 mAKKINj00220; Thu, 20 Nov 2008 20:18:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 14:17:46 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] BRI packet dest address Thread-Index: AclLSXkndsoqQa/NTtev0ns/sHLQlwAAVF8g References: From: "Ahmad Muhanna" To: "Ryuji Wakikawa" , "mext" Subject: Re: [MEXT] BRI packet dest address X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ryuji, I do not know what the status of this draft. But, as I said I am okay either way:) Let us hope that we can close this issue quickly. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Ryuji Wakikawa > Sent: Thursday, November 20, 2008 1:52 PM > To: mext > Subject: [MEXT] BRI packet dest address > > Hi Ahmad, > > What is the status of this document? > http://tools.ietf.org/html/draft-arkko-mext-rfc3775-altcoa-check-01 > > Is the proposed modification applied to 3775-bis? > If yes, source address of BU and CoA must be same all the time. > > regards, > ryuji > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 20 12:20:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A4FA3A69E0; Thu, 20 Nov 2008 12:20:05 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7F13A69E0 for ; Thu, 20 Nov 2008 12:20:03 -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 MRt+6rnzugAR for ; Thu, 20 Nov 2008 12:20:02 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B3F0D3A69D8 for ; Thu, 20 Nov 2008 12:20:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208";a="107380153" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 20 Nov 2008 20:20:01 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAKKK1hl028761; Thu, 20 Nov 2008 12:20:01 -0800 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 mAKKK18n027709; Thu, 20 Nov 2008 20:20:01 GMT Date: Thu, 20 Nov 2008 12:20:01 -0800 (PST) From: Sri Gundavelli To: Vijay Devarapalli In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4383; t=1227212401; x=1228076401; c=relaxed/simple; s=sjdkim1004; 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=20FW=3A=20[netlmm]=20Separation=20of=20Co ntrol=20and=20Data=20Plane=20for=20PMIPv6 |Sender:=20; bh=YR1W3nO6OEL/1AfCWv9O5wZxOHsIMmShJu9i2ZPTCB0=; b=ltxoDVO/0VyZi8456/w5QGDSdbwazJNrHa9UES0rBDFwv+Umtqq9Ldk7nU tzI82weehmKnGLMqdqStqjT52Jg8Iecxh3icNMEYXbeEGLKb0DRm2qTYRc6o T2+zjrSp5MM5MxWi+4qyuscvGszgSC5ef4Enc/UF/0pWgho30rT6g=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: mext Subject: Re: [MEXT] FW: [netlmm] Separation of Control and Data Plane for PMIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay, On Thu, 20 Nov 2008, Vijay Devarapalli wrote: > Sri, > > You did not respond to the following email. > > The text in RFC 5213 is not sufficient for separation of control and > data plane using altCoA option. > > Vijay > > -----Original Message----- > From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On Behalf > Of Vijay Devarapalli > Sent: Tuesday, October 28, 2008 11:33 AM > To: Sri Gundavelli > Cc: netlmm@ietf.org > Subject: Re: [netlmm] Separation of Control and Data Plane for PMIPv6 > > Hi Sri, > > Sri Gundavelli wrote: >> Hi Vijay, >> >> >>>> >>>> The primary purpose of Alt-CoA option is the control/data plane >>>> seperation. >>> >>> Where is this explained in RFC 3775? I repeat, separation of control > and >>> data plane for a Mobile IPv6 mobile node does not make sense. >>> >> >> Its not about the presence of the phrase "Control Plane/Data Plane >> seperation". The option can be used that way and cant see why it >> wont work. > > This is actually a mis-use of the AltCoA option. It was not intended for > > supporting the separation of control and data plane. Even if you do > want to use the AltCoA option for this purpose, the specifications are > missing. More below. > 3775 or 5213 clearly do not use the word CP/DP seperation. But, the hook that they provided in the form of Alt-CoA option allows PBA/BA to be received on an address which is different from the tunnel end point. There can be more than one scenario in which this option can be used. >> If not, why is the use of Alt-CoA even made it to 5213 ? > > RFC 5213 does not specify the separation of control and data plane. For > instance, see the following text fragments from 5213. > > Section 5.3.6 > > o The Destination Address field in the IPv6 header of the message > MUST be set to the source address of the received Proxy Binding > Update message. When there is no Alternate Care-of Address > option > present in the request, the destination address is the same as > the > Proxy-CoA; otherwise, the address may not be the same as the > Proxy-CoA. > > What does "may not be the same" mean? If you had intended to use this > for control and data plane separation, the above paragraph should have > said, if there is an alternate care-of address option present and if the > > address in the option is different from the source address of the > received PBU, then the destination address on the PBACK MUST be set to > the source address of the received PBU. Otherwise it is not guaranteed > to work. It becomes LMA implementation specific. > Where is the confusion. The text says the destination is always the src address of the PBU. While PCoA is the address in Alt-CoA option. When that option is not there, both src and pcoa are same. Why this does not work ? > Section 6.9.1.5 > > o The Source Address field in the IPv6 header of the message MUST > be > set to the global address configured on the egress interface of > the mobile access gateway. When there is no Alternate Care-of > Address option present in the request, this address will be > considered as the Proxy-CoA for this Proxy Binding Update > message. > However, when there is an Alternate Care-of Address option > present > in the request, this address will be not be considered as the > Proxy-CoA, but the address in the Alternate Care-of Address > option > will be considered as the Proxy-CoA. > > The above paragraph tells me that the contents of the AltCoA option > should be stored as the Proxy CoA. When the LMA needs to send a binding > revocation message, where would it send the message to? There is no > guarantee that the LMA will store the source address of the original > PBU, since none of the specifications told the LMA to do this. Another > example is the HA/LMA Switch Message [RFC 5142]. Where would this > message be sent to? > Conceptual data structures do not define protocol behaviour. IMO, no implementation would loose the src address of the BU, else the BA will not make it. Any ways, the topic of CP/DP seperation should not prevent Binding revocation draft from sending the Bind Rev ack's to the src address when Alt-CoA option is present. Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 20 12:22:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B58DD3A6A36; Thu, 20 Nov 2008 12:22:53 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64863A6A36 for ; Thu, 20 Nov 2008 12:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3yrQ+YliwlY for ; Thu, 20 Nov 2008 12:22:51 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by core3.amsl.com (Postfix) with ESMTP id B211D3A6A09 for ; Thu, 20 Nov 2008 12:22:51 -0800 (PST) Received: from LENOVO ([130.129.94.244]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1L3G2y119Y-00012k; Thu, 20 Nov 2008 15:22:43 -0500 From: "Alper Yegin" To: "'Vijay Devarapalli'" References: <025e01c94a87$8ab61940$a0224bc0$@yegin@yegin.org> <4925BBDC.1000603@wichorus.com> <006101c94b4a$5d6b5c70$18421550$@yegin@yegin.org> <4925C2DB.1060701@wichorus.com> In-Reply-To: <4925C2DB.1060701@wichorus.com> Date: Thu, 20 Nov 2008 22:22:40 +0200 Message-ID: <006901c94b4d$bee0fa70$3ca2ef50$@yegin@yegin.org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLSzy2CjtI13v7SQqQB8Ps1K7vHwAAYjpQ Content-Language: en-us X-Provags-ID: V01U2FsdGVkX1+vOnsjSbbX22EY0Ni+uNBbcRpxaj+xSVqoUTs 95GdcrbSC7erGOe1mTNDtSXOpbNmo/U1wi0BLBFVMSekC9VgUI 2hdUWWLq8TvQQDEV9JLBw== Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] issue 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > Alper, > > Well, the fact is that you need significant changes to RFC 3775 to > explicitly support separation of control and data plane using the > AltCoA > option. You can't claim it is a "bug fix" and modify some text. :) > > Vijay No.... you need NO change on the base spec. As I quoted earlier, spec is very clear. I don't know what you think is missing in RFC 3775. Now, the question is: where does the HA pull the source address of the last received BU if it is generating a BRI? We can address that in the Binding Revocation draft by adding that piece of information to the binding cache entry. [IMHO, we can also add that to the base spec, but I see people are uncomfortable with doing that] Alper > > Alper Yegin wrote: > > Vijay, > > > > > >> It is not really a bug in RFC 3775. RFC 3775 never considered > >> separation > >> of control and data plane for the mobile node and the home agent. > > > > You are saying that because you don't see a section titled > "Separation of > > Control and Data Plane" in the RFC :) > > If being able to send MIP signaling between IP1 and HA_IP, and > getting the > > IP packets tunneled between IP2 and HA_IP (as this scenario is > enabled by > > Alt-CoA today!) is not called "separation of control and data plane" > in your > > mind, I wonder what is? > > > >> You > >> are asking for the HA to store both the source address of the BU and > >> the > >> address in the AltCoA option in the binding cache entry if the two > >> happen to be different. And further you want all signaling messages > to > >> be sent to the source address in the BU and the data packets sent to > >> the > >> address in the AltCoA option. IMO, this would be a new feature in > RFC > >> 3775, not a bug fix. :) > > > > Really? It's all in the RFC 3775: > > > > If the Source Address field of the IPv6 header that carried the > > Binding Update does not contain a unicast address, the Binding > > Acknowledgement MUST NOT be sent and the Binding Update packet > MUST > > be silently discarded. Otherwise, the acknowledgement MUST be > sent > > to the Source Address. > > > > > > I hope some other folks join the discussion, as this is my second > pass on > > the same arguments with Vijay :) > > > > Alper > > > > > > > > > > > > > > > > > > > >> Vijay > >> > >> Alper Yegin wrote: > >> > >>> Following the discussions we had on the reflector, I think the RFC > >>> 3775bis needs improvement for use of Alt-CoA option and BA > >> destination > >>> address. > >>> > >>> > >>> > >>> > >>> > >>> The spec clearly states that the BA is sent back to the source IP > >>> address of the BU (not to CoA, which may be different when Alt CoA > is > >> used): > >>> > >>> > >>> If the Source Address field of the IPv6 header that carried the > >>> > >>> Binding Update does not contain a unicast address, the Binding > >>> > >>> Acknowledgement MUST NOT be sent and the Binding Update packet > >> MUST > >>> be silently discarded. Otherwise, the acknowledgement MUST be > >> sent > >>> to the Source Address. > >>> > >>> > >>> > >>> > >>> > >>> I'm not sure if this deserves additional > clarification/specification > >>> text. Vijay believes there is an issue in the absence of further > text > >>> that talks about how HA stores the source IP address of the last > >>> received BU. I agree that is needed for revocation spec and it can > be > >>> specified there as one option. > >>> > >>> > >>> > >>> Any thoughts? Is there anything we need to do in RFC 3775bis? > >>> > >>> > >>> > >>> > >>> Alper > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 20 13:15:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76AB728C0E9; Thu, 20 Nov 2008 13:15:40 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBCE628C0E9 for ; Thu, 20 Nov 2008 13:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 aZ3A1RVOEVmC for ; Thu, 20 Nov 2008 13:15:39 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id DA4FB3A6A48 for ; Thu, 20 Nov 2008 13:15:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1227215738; x=1258751738; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding:x-ironport-av; z=Message-ID:=20<4925D37B.7@qualcomm.com>|Date:=20Thu,=202 0=20Nov=202008=2013:15:39=20-0800|From:=20Lakshminath=20D ondeti=20|User-Agent:=20Thunderbir d=202.0.0.18=20(Windows/20081105)|MIME-Version:=201.0|To: =20mext@ietf.org|Subject:=20Security=20protocols=20for=20 MobileIPv6|Content-Type:=20text/plain=3B=20charset=3DISO- 8859-15=3B=20format=3Dflowed|Content-Transfer-Encoding: =207bit|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,5440" =3B=20a=3D"13318174"; bh=qeni7GlxiCMoe/lNrBPRXtej7pHKK/RBWc1Eya1V5lg=; b=l9LKm4gggG/Apw1u5mBwcf73IsOdzShpqTbkyAtJ0yKGIviUMO5RudXV eRwAqdsoG+sP2eMMpz2Y7qa9UXQCDlyoDjsjlb3GLgQP9W2hT8cknWIU6 wkrgjjPHlKwPb5znBvwm0uHXgtbVaxncdXHHY3MkCZtNiBH0i1lAz4SP3 8=; X-IronPort-AV: E=McAfee;i="5100,188,5440"; a="13318174" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2008 13:15:36 -0800 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 mAKLFa8T009489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 Nov 2008 13:15:36 -0800 Received: from [10.50.76.146] (qconnect-10-50-76-146.qualcomm.com [10.50.76.146]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAKLFZta017221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 20 Nov 2008 13:15:36 -0800 (PST) Message-ID: <4925D37B.7@qualcomm.com> Date: Thu, 20 Nov 2008 13:15:39 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: mext@ietf.org Subject: [MEXT] Security protocols for MobileIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, I have seen time and again efforts to build a "better" key management protocol as MSEC contributor and co-chair over the years. We worked on GDOI, GSAKMP, GSAKMP-Lite, Many MIKEY modes (a high single digit number), GKDP to name a few. If we are to actually work toward the security requirements (15.1 of 3775), and if the goal is interoperability* we are going to end up with a protocol that looks a lot like IKEv2. Reuse of protocols is sometimes inconvenient. If you think I am somewhat of an IPsec nut (I am not, but I am a reuse advocate however), please see the things DTLS needed to do for its reuse as a key management protocol for SRTP. Is that convenient? Not really, but the reuse is still beneficial than not. Now, if the purpose of this effort is to stamp 'standards track' on 4285bis, or something close to that, then we are talking about diluting the security requirements based on perceived inconveniences. best, Lakshminath * I hope Charlie's comment about everyone using what they like was an oversight. I presume we are all here at the IETF to achieve interoperability and interworking. For interoperability, we need another protocol to negotiate the use of the key management protocol and one that protects against downgrade attacks and believe me when I say this, that's not going to be a picnic. We can of course say goodbye to interworking. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 20 13:17:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3413A6A47; Thu, 20 Nov 2008 13:17:06 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5761D3A6A47; Thu, 20 Nov 2008 13:17:05 -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_31=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 NBiaic9Y5Kht; Thu, 20 Nov 2008 13:17:04 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 7149A3A6986; Thu, 20 Nov 2008 13:17:04 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1L3GtY-0006l8-2O; Thu, 20 Nov 2008 22:17:00 +0100 X-Hashcash: 1:20:081120:mext@ietf.org::LM4XO25YDRtCGlFq:00001l4R X-Hashcash: 1:20:081120:ipsec@ietf.org::oMfs5dZ6DKltxeRW:0000eOQ From: arno@natisbad.org (Arnaud Ebalard) To: IETF MEXT WG ML , IPsec IETF WG ML References: <4924C0CD.4030705@strongswan.org> 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, 20 Nov 2008 13:15:17 -0800 In-Reply-To: <4924C0CD.4030705@strongswan.org> (Andreas Steffen's message of "Thu, 20 Nov 2008 02:43:41 +0100") Message-ID: <87y6ze14m2.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Subject: [MEXT] MIGRATE/KMADDRESS support available in strongSwan X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, just a quick note for those interested by the topic. Andreas Steffen and Martin Willi have added support for MIGRATE/KMADDRESS in strongSwan IKEv2 daemon (Charon) as specified in [1]. > - Mobile IPv6 support > ------------------- > > Basic Mobile IPv6 support has been introduced, securing Binding Update > messages as well as tunneled traffic between Mobile Node and Home > Agent. The installpolicy=no option allows peaceful cooperation with > a dominant mip6d daemon and the new type=transport_proxy implements > the special MIPv6 IPsec transport proxy mode where the IKEv2 daemon > uses the Care-of-Address but the IPsec SA is set up for the Home > Address. > > http://wiki.strongswan.org/wiki/MobileIPv6 > > Fully supports migration of Mobile IPv6 connections making use of the > KMADDRESS field contained in XFRM_MSG_MIGRATE messages sent by the > mip6d daemon via the Linux 2.6.28 (or appropriately patched) kernel. Addition of support in racoon (IKEv1) daemon is ongoing. I will post a quick note on the list when it is completed. Cheers, a+ [1] http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 20 13:24:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF3F63A6986; Thu, 20 Nov 2008 13:24:51 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501113A6986 for ; Thu, 20 Nov 2008 13:24:51 -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 6Ak2R+QyR+vM for ; Thu, 20 Nov 2008 13:24:49 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 7CD443A68C5 for ; Thu, 20 Nov 2008 13:24:49 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so617162rvf.49 for ; Thu, 20 Nov 2008 13:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:user-agent :mime-version:to:cc:subject:content-type:from; bh=iu6ZPns7jV2q3uHTZrvxaWtimEBmz25cPnH9KHAe6NE=; b=EME7LFyHnLkN8B2WnXWyN24dmDix5J8o1z9kXrgZsJiQWv9TxL/n4xYODN9zPIkM/j J39cqqKH8HztZN8n5DBu6hgBk1HPt8KsUclVobp3YAqmam/NuPHNqZdQOGL10IUD8eEp yHHBAFRZmKg2mWonq0Bi16hgCupcveKU6XHjo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:user-agent:mime-version:to:cc:subject:content-type :from; b=NYk8EDJuyzWxbNMFLPg9KRuNo8U8mmc+QyKDY4dWRP/ajalLIQG0GBZ3h9Vlc5MlsA hiWZtOoB+mtZIKgZauQu9lL54I/3Q74cSVxJIp2vhe81eLHw3BFj7AMHXY5bznMKT6Ky 96RroRlIsER+zFHht1143H0+elOt95h6lXXgs= Received: by 10.140.163.12 with SMTP id l12mr1462458rve.41.1227216287286; Thu, 20 Nov 2008 13:24:47 -0800 (PST) Received: from ?130.129.29.123? ([130.129.29.123]) by mx.google.com with ESMTPS id l31sm3304059rvb.2.2008.11.20.13.24.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 20 Nov 2008 13:24:46 -0800 (PST) Message-ID: <4925D5AC.5060001@googlemail.com> Date: Thu, 20 Nov 2008 22:25:00 +0100 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: mext@ietf.org Content-Type: multipart/mixed; boundary="------------010305040802040602030304" From: Julien Laganier Cc: charliep@computer.org, cmadson@cisco.com Subject: [MEXT] IPv6 Configuration for IKEv2 [Was:Fwd: I-D Action:draft-ietf-ipsecme-ikev2-ipv6-config-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: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------010305040802040602030304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, FYI -- This is the draft on IPv6 support for IKEv2 that Cheryl mentionned during this session. --julien --------------010305040802040602030304 Content-Type: message/rfc822; name="I-D Action:draft-ietf-ipsecme-ikev2-ipv6-config-00.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="I-D Action:draft-ietf-ipsecme-ikev2-ipv6-config-00.txt.eml" Delivered-To: julien.laganier.ietf@gmail.com Received: by 10.142.216.8 with SMTP id o8cs235884wfg; Tue, 18 Nov 2008 11:17:19 -0800 (PST) Received: by 10.214.25.7 with SMTP id 7mr317988qay.263.1227035839362; Tue, 18 Nov 2008 11:17:19 -0800 (PST) Return-Path: Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx.google.com with ESMTP id 9si6909349ywf.2.2008.11.18.11.17.17; Tue, 18 Nov 2008 11:17:19 -0800 (PST) Received-SPF: pass (google.com: domain of i-d-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) client-ip=64.170.98.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of i-d-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) smtp.mail=i-d-announce-bounces@ietf.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755463A6B07; Tue, 18 Nov 2008 11:15:04 -0800 (PST) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EE07F3A6407; Tue, 18 Nov 2008 11:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-ipsecme-ikev2-ipv6-config-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081118191501.EE07F3A6407@core3.amsl.com> Date: Tue, 18 Nov 2008 11:15:01 -0800 (PST) Cc: ipsec@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IPv6 Configuration in IKEv2 Author(s) : P. Eronen, et al. Filename : draft-ietf-ipsecme-ikev2-ipv6-config-00.txt Pages : 36 Date : 2008-11-18 When IKEv2 is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4, but make it difficult to use certain features of IPv6. This document describes the limitations of current IKEv2 configuration payloads for IPv6, and explores possible solutions that would allow IKEv2 to set up full- featured virtual IPv6 interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-ipv6-config-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-ipv6-config-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-18111154.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --------------010305040802040602030304 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --------------010305040802040602030304-- From mext-bounces@ietf.org Thu Nov 20 14:16:13 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70DB23A68D4; Thu, 20 Nov 2008 14:16:13 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A77623A6A1A for ; Thu, 20 Nov 2008 14:16:11 -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 9z2qZ5a32JL6 for ; Thu, 20 Nov 2008 14:16:10 -0800 (PST) Received: from mandala.kddilabs.jp (unknown [IPv6:2001:200:601:12:230:48ff:fe22:3a84]) by core3.amsl.com (Postfix) with ESMTP id C8F5C28C26D for ; Thu, 20 Nov 2008 14:15:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 8D99CEC85D; Fri, 21 Nov 2008 07:15:37 +0900 (JST) Received: from spears.ast.kddilabs.jp (unknown [2001:200:601:800::168]) by mandala.kddilabs.jp (Postfix) with ESMTP id EF0ECEC852; Fri, 21 Nov 2008 07:15:35 +0900 (JST) Received: from [127.0.0.1] (c015.vpn.kddilabs.jp [172.19.87.15]) by spears.ast.kddilabs.jp (Postfix) with ESMTP id 67DD2690662; Fri, 21 Nov 2008 07:15:31 +0900 (JST) Message-ID: <4925E1AB.2070902@kddilabs.jp> Date: Fri, 21 Nov 2008 07:16:11 +0900 From: Kazuyuki Tasaka User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: <057632CE4CE10D45A1A3D6D19206C3A3D6CA0338@NASANEXMB08.na.qualcomm.com> <057632CE4CE10D45A1A3D6D19206C3A3D6CA033D@NASANEXMB08.na.qualcomm.com>, <4924C84D.8060405@kddilabs.jp> <057632CE4CE10D45A1A3D6D19206C3A3D6CC34DC@NASANEXMB08.na.qualcomm.com> <49253338.4030905@kddilabs.jp> <057632CE4CE10D45A1A3D6D19206C3A3D6CA0402@NASANEXMB08.na.qualcomm.com> In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D6CA0402@NASANEXMB08.na.qualcomm.com> X-Virus-Scanned: by amavisd-new Cc: "mext@ietf.org" , Basavaraj Patil Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Gerardo, Giaretta, Gerardo Wrote: > Hi Kazuyuki, > > I think what you are proposing is exactly the opposite of what I was proposing so I am not sure I can agree :-) I think so :-) > Let's see if others have any opinion. As I mentioned, I am fine documenting both scheme and make them optional, i.e. leave to the deployment which scheme to use. This may end up with some interop issues but it is also true that different deployments have different requirements. > > My point was just to document the binary scheme in the basic draft as it seems quite straightforward and easy to add to the draft (it was already there indeed). However I am also fine having a separate draft also for the binary scheme if this is what the WG prefers. OK, let's see if others have any opinion. By the result, I think we can make a final decision: - We should have the flow description in separate documents. In this case, we will specify pure protocol for transferring flow descriptions in flow-binding document and flow descriptions in draft-larsson document as has been discussed in WG. or - We should have flow-binding document newly specified a basic binary encoding and a simple mobility option for it and draft-larsson document specifed routing rules as more generic flow descriptions. or - other opinion? Regards, Kazuyuki > Gerardo > >> -----Original Message----- >> From: Kazuyuki Tasaka [mailto:ka-tasaka@kddilabs.jp] >> Sent: Thursday, November 20, 2008 1:52 AM >> To: Giaretta, Gerardo >> Cc: Basavaraj Patil; Conny Larsson; mext@ietf.org >> Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding >> >> Hi Gerardo, >> >> I think that the flow description should be defined in another >> document(e.g. draft-larsson). This is the WG decision. >> On the other hand, I agree to specify one reference example >> (e.g. example for binary encoding) in flow-binding. >> >> So, "The MN MAY use the encoding specified in draft-larsson as flow >> description. At this time, the MN MAY handle not only data stored in >> the ASCII form but also data stored in binary data structures for >> saving bandwidth. In this case, MN SHULD use a mobility option for >> binary encoding". >> >> Regards, >> Kazuyuki. >> >> Giaretta, Gerardo Wrote: >>> Hi Kazuyuki, >>> >>> I don't fully understand your proposal. I don't think we should mention QoS >> requests in the document; I used that as an example of how binary encoding is >> used in other SDO. >>> My proposal would be to specify a simple mobility option for binary encoding >> in draft-ietf-mext-flow-binding. The draft will state something like the >> following: >>> "The MN MAY use this binary encoding specified in this draft as Flow >> Description. Alternatively the MN MAY use the encoding specified in draft- >> larsson." >>> In this way we capture both solutions and we don't prioritize any of them. >>> >>> Would that be acceptable? >>> >>> Thanks >>> Gerardo >>> >>> ________________________________________ >>> From: Kazuyuki Tasaka [ka-tasaka@kddilabs.jp] >>> Sent: Wednesday, November 19, 2008 6:15 PM >>> To: Giaretta, Gerardo >>> Cc: Basavaraj Patil; Conny Larsson; mext@ietf.org >>> Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding >>> >>> Hi Gerardo, >>> >>> My understanding is that your point is use of simple 5-tuples as >>> flow description and transportation of binary encoded them for >>> saving bandwidth. >>> >>> I think that this is one basic example for QoS reservations and >>> requests and is very simple. But this is not generic. >>> >>> So, I propose to describe it in both documents (Flow binding and >>> Flow distribution) as one example for QoS reservations and requests. >>> >>> For example, in flow binding document, we include that flow description >>> SHOULD be used binary encoded 5-tuples in case of QoS reservations and >>> resuests. >>> On the other hand, in flow destribution document, we define more generic >>> routing rules and include that the number of routing rules SHOULD be >>> minimize (e.g. 5-tuples) in case of it. >>> Now, in flow destribution document, it is described that routing rules >>> could be stored in a file system in the ASCII form, but they could also >>> be stored in, e.g., in-core (binary) data structures. >>> >>> What do you think this? >>> >>> Regards, >>> Kazuyuki. >>> >>> Giaretta, Gerardo Wrote: >>>> Hi Raj, >>>> >>>> The point is that in some scenarios what the MN needs to communicate to the >> HA are simple 5-tuples, most of them may even contain wild-carded values. The >> amount and the details of information carried over SIP is different. >>>> I am not proposing the binary encoding should be the default. I am saying >> it is simple enough to document it in the basic draft (we basically need one >> mobility option). I am fine if we move forward also draft-larsson at the same >> time and we include references in the flow binding draft. >>>> Gerardo >>>> >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] >>>> Sent: Wednesday, November 19, 2008 1:22 PM >>>> To: Giaretta, Gerardo; Conny Larsson >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding >>>> >>>> >>>> Hi Gerardo, >>>> >>>> The bandwidth efficiency of binary encoding is true in general. >>>> However if you look at SIP for example, why did they choose to not specify >> it with binary encoding? >>>> There is value with the Ascii encoding model. I just don't know if there is >> a need to be highly optimized here to choose the binary encoding format as the >> default. >>>> -Raj >>>> >>>> >>>> On 11/19/08 3:15 PM, "Giaretta Gerardo" wrote: >>>> Hi Conny, >>>> >>>> I think the point is that binary encoding is more bandwidth efficient. If >> we consider 3GPP as an example, the binary encoding is used for QoS >> reservations and requests. In my view we could use a similar binary encoding >> also for flow mobility and document that in the basic draft. >>>> I see the argument of flexibility but this comes to a cost. Pointing to >> draft-larsson for more flexible encoding is fine to me but I don't think that >> should be the basic model. >>>> Cheers >>>> Gerardo >>>> >>>> >>>> From: Conny Larsson [mailto:conny.larsson@ericsson.com] >>>> Sent: Wednesday, November 19, 2008 11:26 AM >>>> To: Giaretta, Gerardo >>>> Cc: stu.card@critical.com; mext@ietf.org >>>> Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding >>>> >>>> Hi Gerardo, >>>> >>>> I have difficulties to comment on your flexibility/efficiency statement >> since I have not implemented any of the solutions (binary encoding/ASCII-based >> encoding). However, one of my colleagues has made an implementation of the >> ASCII-based solution, as specified in http://tools.ietf.org/id/draft-larsson- >> mext-flow-distribution-rules-01.txt, and according to him it was easy to >> implement and caused no major problems. We even have a prototype on Linux up >> and running and it works perfectly well for distributing flows simultaneously >> among three different interfaces. >>>> You are saying "What I would like to avoid is to not have any of those in >> the current draft. At least one of these should be specified in the base draft >> in order to have a complete solution.". Could you please elaborate a little >> bit more why you think draft-larsson-mext-flow-distribution-rules would not do >> the work sufficiently? >>>> My proposal is of course to specify a reference to draft-larsson and get a >> flexible solution from the beginning. >>>> Regards >>>> Conny >>>> >>>> >>>> Giaretta, Gerardo wrote: >>>> I definitely agree with you on the importance of long term and flexible >> solutions. My point is that there are probably different scenarios with >> different requirements and in some of them it makes sense to use binary >> encoding (which is less flexible but more efficient) and in some other it >> makes sense to use ASCII-based encoding. >>>> What I would like to avoid is to not have any of those in the current >> draft. At least one of these should be specified in the base draft in order to >> have a complete solution. I think we should go for the binary solution (which >> was originally part of the I-D indeed) as it requires less work and can be >> seen as the basic solution. In the meanwhile we can focus on an ASCII-based >> solution which is more flexible but would require some more work. >>>> Gerardo >>>> >>>> >>>> -----Original Message----- >>>> From: Stuart W. Card [mailto:stu.card@critical.com] >>>> Sent: Wednesday, November 19, 2008 10:25 AM >>>> To: Giaretta, Gerardo >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding >>>> >>>> >>>> >>>> ... >>>> I think the support of binary description of the filters is pretty >>>> straighforward and very well known in IETF. This seems to be also the >>>> most reasonable solution in cellular networks where we may want to save >>>> bandwidth... >>>> >>>> I often have to deal with _really_ slow media (2400 bps, >>>> half-duplex, with > 250 mS receive-transmit turnaround). >>>> So I have a great appreciation for efficient encodings. >>>> >>>> That said, I believe that generality, flexibility and >>>> extensibility are more important to overall efficiency >>>> than are the few dozen or even couple hundred bytes that >>>> are saved every few seconds or minutes by encoding >>>> flow descriptions in binary. >>>> >>>> So my point is, if we are confident that we can specify >>>> a general, flexible, extensible, binary flow description >>>> language, great... but I'd rather stick with inefficient >>>> ASCII encodings if aren't yet to the maturity level in >>>> our understanding of this problem that we can retain >>>> those essential characteristics in a binary encoding. >>>> >>>> Sorry to bore you all with fuzzy philosophical ramblings >>>> but I think the long- versus short-term efficiency tradeoff >>>> is point that should not be forgotten. Thanks! >>>> >>>> -- >>>> Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. >>>> * Creativity * Diversity * Expertise * Flexibility * Integrity * >>>> Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 >>>> 315-793-0248 x141 FAX -9710 >> www.critical.com >>>> >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> ________________________________ >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 20 19:59:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFE7B3A69BD; Thu, 20 Nov 2008 19:59:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5943A635F for ; Thu, 20 Nov 2008 19:59:48 -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 RgN01i0Ng2jl for ; Thu, 20 Nov 2008 19:59:47 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 6F2913A6820 for ; Thu, 20 Nov 2008 19:59:47 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so161559qwe.31 for ; Thu, 20 Nov 2008 19:59:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=XLYqUxQCLQQclwzBx32csrXzTwIFp/dUB9x3tbVO5cQ=; b=Aobr1KNMYlAnX0F+FAzEF+wBIrOplgQrEO0n1oVGNxt2a30pBl0n1cLkfHIAe99ch7 LP8fdrh0tMUCEigULwIjIqJwr1WYs7fki3R8DzdmyiZCCA+AN/tUpwExFy1B4rznlyji mmZTT/drPy+ALtAjuR8KSv++kQFEJ6n7J9QFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=aI0gTyHagPBh3cKjNiYlUOMFpXCcvviXIvK0IyUEE11Q/gNXErg+vAs7RT65DSbK1K PNpGr4Fbs1uYN+c0XBBp2kr9KsandMIsTM6JL62vY2nIpv0x+CWtWEfJino9wARwbiFj T2azXNjvvq6FpzJPW87M5/g92jBs2eIpvXYbc= Received: by 10.215.14.7 with SMTP id r7mr45650qai.27.1227239985349; Thu, 20 Nov 2008 19:59:45 -0800 (PST) Received: by 10.214.116.19 with HTTP; Thu, 20 Nov 2008 19:59:45 -0800 (PST) Message-ID: Date: Thu, 20 Nov 2008 19:59:45 -0800 From: "fan zhao" To: mext@ietf.org MIME-Version: 1.0 Content-Disposition: inline Cc: netlmm@ietf.org Subject: [MEXT] question on the DHCP-PD X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Below is the question regarding the DHCP based prefix delegation I had on the today's mext meeting. I also cc to the netlmm mailing list. My question is when the MN connects to a source access network using PMIP (or other type of network based mobility protocol), it obtains a home network prefix. Then the MN handovers to a target access network (i.e. the foreign link for the MN) using the Mobile IPv6. The handover procedure is as follows. 1) The MN obtains a care-of address from the target access network. 2) The MN discovers the home agent if it does not know. 3) The MN sets up the IPsec SA with the HA if it does not have the SA with the HA before. 4) During the step 3), the MN requests the HNP allocated from the HA based on RFC 4877/5026. 5) The MN realizes it is on the foreign link, then it needs to send the BU to the HA. Since the Mobile IPv6 BU can only register the binding between the CoA and one single home address, in order to register the binding between the HNP and the CoA, the MN needs to use the NEMO extensions, for example, by setting up the 'R' bit and using the implicit mode. Therefore the HNP is also used as the mobile network prefix based on the NEMO protocol. However, the home agent does not know the same prefix is used as the mobile network prefix in addition to the home network prefix. Therefore, in order for the home agent to have the information and set up states regarding the mobile network prefix, the prefix delegation procedure needs to be performed. With the DHCP based prefix delegation, the MN requests the same HNP in the DHCP request; however, since the HNP is already allocated to the MN during bootstrapping, such request may be rejected. Note that the HA can contact a DHCP server for both HNP and MNP assignment. It seems to me this issue is related to the separation between the prefix delegation and the HNP allocation. It is not clear to me how the DHCP-PD handles the case where the HNP is the same as the MNP. Do I miss something? Thanks. Sincerely, fan _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 21 06:03:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B05923A6A14; Fri, 21 Nov 2008 06:03:23 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68C893A6A14 for ; Fri, 21 Nov 2008 06:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPq9x5nRolnB for ; Fri, 21 Nov 2008 06:03:20 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by core3.amsl.com (Postfix) with ESMTP id EEBBA3A6917 for ; Fri, 21 Nov 2008 06:03:19 -0800 (PST) Received: from LENOVO ([130.129.79.40]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1L3WbC3T2x-0006g1; Fri, 21 Nov 2008 09:03:18 -0500 From: "Alper Yegin" To: Date: Fri, 21 Nov 2008 16:03:04 +0200 Message-ID: <015001c94be1$e250a2f0$a6f1e8d0$@yegin@yegin.org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclL4doQXNBYI238Ta2gso/8ZEZ8aQ== Content-Language: en-us x-cr-puzzleid: {6F34BFC8-209C-45BE-8E8A-439B78E969AD} x-cr-hashedpuzzle: Xx4= AWJM BUVM CIHz DF7E DKzf DMiU D7Wh E/Be FIxn GDum GTkc Gzec HrPN H3Qa Jabo; 1; bQBlAHgAdABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {6F34BFC8-209C-45BE-8E8A-439B78E969AD}; YQBsAHAAZQByAC4AeQBlAGcAaQBuAEAAeQBlAGcAaQBuAC4AbwByAGcA; Fri, 21 Nov 2008 14:02:55 GMT; SQBQAHMAZQBjACAAZgBvAHIAIABNAEkAUAB2ADYA X-Provags-ID: V01U2FsdGVkX18HE3vwplmTIxdrqnPluwOc8DeXci2jNrKEbjJ C4aCFp2eCunMTsxabVOFT8UY0fydUA9YmPuEYrnymb6tWi/7Td DCVsIZq0NWWgHLs2v/oFQ== Subject: [MEXT] IPsec for MIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1085341731==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multipart message in MIME format. --===============1085341731== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0151_01C94BF2.A5D972F0" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0151_01C94BF2.A5D972F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I was really puzzled about the pushback on Charlie's presentation. Comments supporting sufficiency of IPsec for MIP6 seemed to ignore the facts that: - RFC 4285 existed - SDOs adopted it - Vendors implemented it How can anyone say IPsec is the best solution for MIP6 security and industry does not need anything else. Alper ------=_NextPart_000_0151_01C94BF2.A5D972F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was really puzzled about the pushback on = Charlie’s presentation.

 

Comments supporting sufficiency of IPsec for MIP6 = seemed to ignore the facts that:

-          RFC 4285 existed

-          SDOs adopted it

-          Vendors implemented it

 

How can anyone say IPsec is the best solution for = MIP6 security and industry does not need anything else…

 

Alper

 

 

 

 

------=_NextPart_000_0151_01C94BF2.A5D972F0-- --===============1085341731== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1085341731==-- From mext-bounces@ietf.org Fri Nov 21 06:11:20 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B16153A6917; Fri, 21 Nov 2008 06:11:20 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89B283A68C8 for ; Fri, 21 Nov 2008 06:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 RIySnBG-E+jr for ; Fri, 21 Nov 2008 06:04:30 -0800 (PST) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id 9A34C3A687D for ; Fri, 21 Nov 2008 06:04:30 -0800 (PST) Received: by kafka.verkstad.net (Postfix, from userid 20078) id B747E710ACC; Fri, 21 Nov 2008 15:04:27 +0100 (CET) Date: Fri, 21 Nov 2008 15:04:27 +0100 From: Michael Eriksson To: "Giaretta, Gerardo" Message-ID: <20081121140427.GA26200@kafka.verkstad.net> References: <057632CE4CE10D45A1A3D6D19206C3A3D6CC34D4@NASANEXMB08.na.qualcomm.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D6CC34D4@NASANEXMB08.na.qualcomm.com> Cc: mext@ietf.org Subject: Re: [MEXT] Flow description in draft-ietf-mext-flow-binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Tue, Nov 18, 2008 at 22:27:23 -0800, Giaretta, Gerardo wrote: > the current version of draft-ietf-mext-flow-binding does not specify > any type of flow description and leaves to other documents how to > specify the filters which are installed by the UE at the HA. > > I think we should add a basic version of the Flow Description in > this draft to support filters in binary form (5-tuples). We have > already one draft for MCoA and one for Flow Binding which will very > often be used together and are part of the same multihoming > solution; adding yet another separate draft will have bad impacts on > the readability of the specifications. > > Moreover the flow binding draft was scheduled to be sent to IESG > October 2008 but we have not gone through the WGLC yet. This is the > right time to add the Flow Description in this draft without adding > much delay; waiting for another draft to be published may delay the > work too much. > > I think the support of binary description of the filters is pretty > straighforward and very well known in IETF. This seems to be also > the most reasonable solution in cellular networks where we may want > to save bandwidth. Obviously the FID optoin will still be Flow > Description agnostic and other more sophisticated Filter Description > can be defined in separate documents. I think that we should only use a free text (i.e., ASCII) format: - It is much easier to generate (think printf). - It is much easier to debug. - It is probably also easier to parse; a binary format with optional fields (to save bytes) is prone to errors. - In some cases, the rules will be static. Rules in text format can be written in a regular text editor and stored for later use. Storing binary rules are cumbersome at best. - It is easier to make future extensions to a text format. Having both a binary and a text format should be avoided, as it will lead to interoperability problems and more implementation work. We have already suggested a free text rule language, see draft-larsson-mext-flow-distribution-rules. I suggest you read that, and see if it doesn't solve your problems. Any feedback on the draft is of course very welcome. /Micke _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 21 06:13:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFE933A687D; Fri, 21 Nov 2008 06:13:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DCD43A687D for ; Fri, 21 Nov 2008 06:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 Rxsh8swlCVxF for ; Fri, 21 Nov 2008 06:13:48 -0800 (PST) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id 003C53A67ED for ; Fri, 21 Nov 2008 06:13:47 -0800 (PST) Received: by kafka.verkstad.net (Postfix, from userid 20078) id 5B599710B17; Fri, 21 Nov 2008 15:13:46 +0100 (CET) Date: Fri, 21 Nov 2008 15:13:46 +0100 From: Michael Eriksson To: "Stuart W. Card" Message-ID: <20081121141346.GB26200@kafka.verkstad.net> References: <49231705.9020406@ericsson.com> <17492.128.230.32.38.1227043564.squirrel@www.critical.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <17492.128.230.32.38.1227043564.squirrel@www.critical.com> Cc: mext@ietf.org Subject: Re: [MEXT] draft-larsson-mext-flow-distribution-rules-01.txt comments (was: draft-ietf-mext-flow-binding-00.txt - comments) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Tue, Nov 18, 2008 at 16:26:04 -0500, Stuart W. Card wrote: > conny.larsson@ericsson.com wrote -- > > > And the draft describing how this can be done is > > http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rules-01.txt > > I hadn't reviewed the latter draft before. > Thank you for pointing it out. > It looks like it may become very useful in my team's work. > My comments follow. > > From that draft: > > > 5.4. Conditional Rule-Sets > > > > For some scenarios, it is useful to install or transmit a collection > > of rule-sets at the same time, and select which one to use depending > > on what PIDs are available. How the set of available PIDs is > > determined is outside the scope of this document. > > and: > > > 5.14. Round-robin > > > > For load-sharing purposes, round-robin transmission is supported. To > > use round-robin, a list of PIDs is given instead of just one: > > > > udp peer 2001:db8:1c32::/48 port 44100 on 4, 4, 5 > > > > Here, UDP traffic from port 44100 at any node in prefix 2001:db8: > > 1c32::/48 will be sent on PIDs 4 and 5. Two out of three packets > > will go on PID 4, which presumably has twice the bandwidth of PID 5. > > These specs make sense iff: > a PID is either available, or not; and > coarse granularity in bandwidth allocation is adequate. > > However, a path may be 'available', but currently degraded. > Or paths may simply have bandwidth that is highly variable. > Likewise different paths may have slightly different bandwidths. At the Home Agent, a path can only be "available" or "not available", as it is determined by if a particular BID is bound or not (draft-larsson PIDs map directly to MIPv6 BIDs). If the availability is "fuzzy" (sometimes degraded), that would have to be handled by some outside party that updates the flow rules at the HA (and MN) according to the conditions of each path. BR, Michael _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 21 06:18:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1ED73A6A31; Fri, 21 Nov 2008 06:18:04 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F6693A6A31 for ; Fri, 21 Nov 2008 06:18:03 -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 R6yaTiIlLMKj for ; Fri, 21 Nov 2008 06:18:02 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 345DE3A6A2E for ; Fri, 21 Nov 2008 06:18:02 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so402307ywj.49 for ; Fri, 21 Nov 2008 06:18:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=mP0j6zj/7LekensNBe/fU3KzA63nE7grxQPvrrHSt0A=; b=Hu/+czY8BQuw91VaZlt6neqk1QDQW26ojlrhnCkGD9KtOxRyiPBU5Me5vjNhKFaqUy VqWb3BFtWzPbDz5q9TFgAa6cS+EeabUmmRowUjM0+W4gAWsrq7ZtL9TRDT66203ffs8i HNrSWRONGUszZA+ZrPVZmFIuIA1WyDKFFZ9gM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=eOitpplOvaxPVePyFn+lpv/o0HQoHpPdtaPK4OBwrgKDGPy0ute3fXZ2uvC0l3zUnP mUmJ9geQS/e+rIbw3FQmRaQJ2hHyGBHq5LkvNhvAO9lbQ8FoR4+D4Q4l2LwJkKJzWzv1 dAIS0R2i7AfKle1lqo0OnMfmHHrC0CW0OkopQ= Received: by 10.142.169.4 with SMTP id r4mr306228wfe.105.1227277080313; Fri, 21 Nov 2008 06:18:00 -0800 (PST) Received: by 10.142.211.4 with HTTP; Fri, 21 Nov 2008 06:18:00 -0800 (PST) Message-ID: <4c5c7a6d0811210618q74bb3fa4u5cd61159f56236e1@mail.gmail.com> Date: Fri, 21 Nov 2008 22:18:00 +0800 From: "Peny Yang" To: "Alper Yegin" In-Reply-To: <-3048856853835898372@unknownmsgid> MIME-Version: 1.0 Content-Disposition: inline References: <-3048856853835898372@unknownmsgid> Cc: mext@ietf.org Subject: Re: [MEXT] IPsec for MIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alper: Maybe it's not simply pushback. :-p Basically, I don't think IPsec is the best for MIPv6. However, do we really need to adopt a different security solution for MIPv6 instead of making IKev2/IPsec more efficient? In this sense, we need to achieve the consensus on the issues of IKEv2/IPsec for MIPv6 and pros/cons of new solution. Then, we can proceed to make a decision on the question above. BRG Peny On Fri, Nov 21, 2008 at 10:03 PM, Alper Yegin wrote: > I was really puzzled about the pushback on Charlie's presentation. > > > > Comments supporting sufficiency of IPsec for MIP6 seemed to ignore the fa= cts > that: > > - RFC 4285 existed > > - SDOs adopted it > > - Vendors implemented it > > > > How can anyone say IPsec is the best solution for MIP6 security and indus= try > does not need anything else=85 > > > > Alper > > > > > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 21 07:10:11 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C02133A68D3; Fri, 21 Nov 2008 07:10:11 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28C813A69F5 for ; Fri, 21 Nov 2008 07:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAO5dxE3VaEo for ; Fri, 21 Nov 2008 07:10:09 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 4C3D43A68D3 for ; Fri, 21 Nov 2008 07:10:09 -0800 (PST) Received: from LENOVO ([130.129.94.244]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1L3Xe01cPM-0006TA; Fri, 21 Nov 2008 10:10:06 -0500 From: "Alper Yegin" To: "'Peny Yang'" References: <-3048856853835898372@unknownmsgid> <4c5c7a6d0811210618q74bb3fa4u5cd61159f56236e1@mail.gmail.com> In-Reply-To: <4c5c7a6d0811210618q74bb3fa4u5cd61159f56236e1@mail.gmail.com> Date: Fri, 21 Nov 2008 17:10:04 +0200 Message-ID: <016101c94beb$3d4464e0$b7cd2ea0$@yegin@yegin.org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclL4/XIvvsinAitSjyFl/yIIATXEAABvkuQ Content-Language: en-us X-Provags-ID: V01U2FsdGVkX1/WlWsArFcF9kzpdQPc0N913Oz4pLPvFKIcOlS n2Fy/Pn+5tPDAKB/KUYeLMuFRrHq1+hq9OsmmAa0eljNPE1McW QwuiaaQuvBvEbVS/zK2zg== Cc: mext@ietf.org Subject: Re: [MEXT] IPsec for MIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Peny, See, this is my confusion. Your email would make sense to me if it were sent in pre-RFC4285 era (3+ years ago). Yesterday's discussion felt like travelling back in time to me :) Alper > -----Original Message----- > From: Peny Yang [mailto:peng.yang.chn@gmail.com] > Sent: Friday, November 21, 2008 4:18 PM > To: Alper Yegin > Cc: mext@ietf.org > Subject: Re: [MEXT] IPsec for MIPv6 > > Alper: > > Maybe it's not simply pushback. :-p > Basically, I don't think IPsec is the best for MIPv6. However, do we > really need to adopt a different security solution for MIPv6 instead > of making IKev2/IPsec more efficient? > > In this sense, we need to achieve the consensus on the issues of > IKEv2/IPsec for MIPv6 and pros/cons of new solution. Then, we can > proceed to make a decision on the question above. > > BRG > Peny > > On Fri, Nov 21, 2008 at 10:03 PM, Alper Yegin > wrote: > > I was really puzzled about the pushback on Charlie's presentation. > > > > > > > > Comments supporting sufficiency of IPsec for MIP6 seemed to ignore > the facts > > that: > > > > - RFC 4285 existed > > > > - SDOs adopted it > > > > - Vendors implemented it > > > > > > > > How can anyone say IPsec is the best solution for MIP6 security and > industry > > does not need anything else. > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 21 08:04:19 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B920A3A69D4; Fri, 21 Nov 2008 08:04:19 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 858C13A69D4 for ; Fri, 21 Nov 2008 08:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZHbjpGkXzvg for ; Fri, 21 Nov 2008 08:04:15 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by core3.amsl.com (Postfix) with ESMTP id 098E73A679C for ; Fri, 21 Nov 2008 08:04:15 -0800 (PST) Received: from LENOVO ([130.129.94.244]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1L3YUM3ADX-0006VD; Fri, 21 Nov 2008 11:04:13 -0500 From: "Alper Yegin" To: Date: Fri, 21 Nov 2008 18:04:10 +0200 Message-ID: <016901c94bf2$cc3abc60$64b03520$@yegin@yegin.org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclL8smtIrrpxdU/Q46quta3RWgR4g== Content-Language: en-us X-Provags-ID: V01U2FsdGVkX18e/ybSGl3F7RIyDnhlsMkEwlckCPyK02DGdFA JJOJjCMTF3t/HBg5cAzDCnqtJ8izKAfotAROyqlMVhZzainAib tuGbT03saY/mFuZK1C7NA== Cc: mext@ietf.org Subject: [MEXT] RFC 3775bis: mandate on the use of IPsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0195847475==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multipart message in MIME format. --===============0195847475== Content-Type: multipart/alternative; boundary="----=_NextPart_000_016A_01C94C03.8FC38C60" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_016A_01C94C03.8FC38C60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Another issue with RFC 3775 is with the following text: The mobile node and the home agent MUST use an IPsec security association to protect the integrity and authenticity of the Binding Updates and Acknowledgements. Given the presence of RFC 4285 (and its adoption) it does not make sense to mandate "use of IPsec." It's not like we expect RFC 4285 users to run it on top of IPsec because RFC 3775 mandates use of IPsec J Note that we already took care of this with RFC 5213 which says: The mobile access gateway and the local mobility anchor MUST implement IPsec for protecting the Proxy Mobile IPv6 signaling messages [RFC4301]. IPsec is a mandatory-to-implement security mechanism. However, additional documents may specify alternative mechanisms and the mobility entities can enable a specific mechanism for securing Proxy Mobile IPv6 signaling messages, based on either a static configuration or after a dynamic negotiation using any standard security negotiation protocols. Alper ------=_NextPart_000_016A_01C94C03.8FC38C60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Another issue with RFC 3775 is with the following = text:

 

   The mobile node and the home agent MUST use an IPsec = security

   association to protect the integrity and authenticity of the = Binding

   Updates and Acknowledgements.

 

 

Given the presence of RFC 4285 (and its adoption) = it does not make sense to mandate “use of IPsec.” It’s not = like we expect RFC 4285 users to run it on top of IPsec because RFC 3775 = mandates use of IPsec J

 

Note that we already took care of this with RFC = 5213 which says:

 

   The mobile access gateway and the local mobility =
anchor MUST
   implement IPsec for =
protecting the Proxy Mobile IPv6 =
signaling
   messages [RFC4301].  =
IPsec is a mandatory-to-implement =
security
   mechanism.  However, =
additional documents may specify =
alternative
   mechanisms and the =
mobility entities can enable a specific =
mechanism
   for securing Proxy Mobile =
IPv6 signaling messages, based on either =
a
   static configuration or after a =
dynamic negotiation using any
   standard =
security negotiation protocols.

 

Alper

 

 

 

 

 

 

------=_NextPart_000_016A_01C94C03.8FC38C60-- --===============0195847475== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0195847475==-- From mext-bounces@ietf.org Fri Nov 21 08:30:41 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDA563A6A40; Fri, 21 Nov 2008 08:30:40 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 721203A6A40 for ; Fri, 21 Nov 2008 08:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, 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 CCV5v0e6OLtl for ; Fri, 21 Nov 2008 08:30:38 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 682B53A6A2E for ; Fri, 21 Nov 2008 08:30:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1227285037; x=1258821037; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<4926E224.5070402@qualcomm.com>|Date:=20Fr i,=2021=20Nov=202008=2008:30:28=20-0800|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.18=20(Windows/20081105)|MIME-Version:=201 .0|To:=20Alper=20Yegin=20|CC:=20me xt@ietf.org|Subject:=20Re:=20[MEXT]=20IPsec=20for=20MIPv6 |References:=20<015001c94be1$e250a2f0$a6f1e8d0$@yegin@yeg in.org>|In-Reply-To:=20<015001c94be1$e250a2f0$a6f1e8d0$@y egin@yegin.org>|Content-Type:=20text/plain=3B=20charset =3DUTF-8=3B=20format=3Dflowed|Content-Transfer-Encoding: =208bit|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5440 "=3B=20a=3D"13366544"; bh=xZvisryuqVguRV5ZuUO/kfBOi6JExh7I2rIHYURmAl8=; b=jcai1HBud63k20sVXZbMfp+6CuuuAQS1FNGkOOQVm6QGwGGU3xqKxaea ZVCCDXUmxQiXlWQWYPeL92dlbNPKpEESc8XqXO1XetZIsAV/uS4VtfnYN HOGQVVHL+AsATihLd7Ygp/iCYuFRLXjzWI+1009/zzH2Bk7qJrDDPwKH+ k=; X-IronPort-AV: E=McAfee;i="5300,2777,5440"; a="13366544" 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; 21 Nov 2008 08:30:37 -0800 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 mALGUa27013238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Nov 2008 08:30:37 -0800 Received: from [10.50.76.57] (qconnect-10-50-76-57.qualcomm.com [10.50.76.57]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mALGUZUA031217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Nov 2008 08:30:36 -0800 Message-ID: <4926E224.5070402@qualcomm.com> Date: Fri, 21 Nov 2008 08:30:28 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Alper Yegin References: <015001c94be1$e250a2f0$a6f1e8d0$@yegin@yegin.org> In-Reply-To: <015001c94be1$e250a2f0$a6f1e8d0$@yegin@yegin.org> Cc: mext@ietf.org Subject: Re: [MEXT] IPsec for MIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org SGkgQWxwZXIsCgpJUHNlYyBleGlzdHMuCjM3NzUgUmVxdWlyZXMgaXQuClZlbmRvcnMgaW1wbGVt ZW50ZWQgaXQuCgo6KQoKU28sIGp1c3QgbGlrZSB0aGUgcHJlc2VudGF0aW9uLCB0aGF0IGxpbmUg b2YgYXJndW1lbnQgcmVhbGx5IGlzIAp1bmNvbnZpbmNpbmcuCgpJbiB0aGUgbWVhbndoaWxlIDQy ODUgaGFzIGFuIElFU0cgbm90ZSBhdCB0aGUgYmVnaW5uaW5nIHRoYXQgc2F5cywgdGhlIApmb2xs b3dpbmcgaXMgYSBib2d1cyBwcm90b2NvbCwgcGxlYXNlIGRvbid0IHVzZSBpdC4gIFRoZSBmaXJz dCBzdGVwIG1heSAKYmUgdG8gbWFrZSA0Mjg1IHN0YW5kYXJkcyB0cmFjayBhbmQgd2UgY2FuIGhh dmUgdGhpcyBkaXNjdXNzaW9uLgoKV2hpbGUgZG9pbmcgc28sIGl0IG1pZ2h0IGJlIHdvcnRod2hp bGUgdG8gdGhpbmsgYWJvdXQgd2hhdCBJIHdyb3RlIAplYXJsaWVyIGFib3V0IGludGVyb3BlcmFi aWxpdHkgYW5kIGludGVyd29ya2luZyB3aXRoIHR3byBkaWZmZXJlbnQga2V5IAptYW5hZ2VtZW50 IGFuZCBlbmNhcHN1bGF0aW9uIHByb3RvY29scy4KCnRoYW5rcywKTGFrc2htaW5hdGgKCk9uIDEx LzIxLzIwMDggNjowMyBBTSwgQWxwZXIgWWVnaW4gd3JvdGU6Cj4gSSB3YXMgcmVhbGx5IHB1enps ZWQgYWJvdXQgdGhlIHB1c2hiYWNrIG9uIENoYXJsaWXigJlzIHByZXNlbnRhdGlvbi4KPiAKPiAg Cj4gCj4gQ29tbWVudHMgc3VwcG9ydGluZyBzdWZmaWNpZW5jeSBvZiBJUHNlYyBmb3IgTUlQNiBz ZWVtZWQgdG8gaWdub3JlIHRoZSAKPiBmYWN0cyB0aGF0Ogo+IAo+IC0gICAgICAgICAgUkZDIDQy ODUgZXhpc3RlZAo+IAo+IC0gICAgICAgICAgU0RPcyBhZG9wdGVkIGl0Cj4gCj4gLSAgICAgICAg ICBWZW5kb3JzIGltcGxlbWVudGVkIGl0Cj4gCj4gIAo+IAo+IEhvdyBjYW4gYW55b25lIHNheSBJ UHNlYyBpcyB0aGUgYmVzdCBzb2x1dGlvbiBmb3IgTUlQNiBzZWN1cml0eSBhbmQgCj4gaW5kdXN0 cnkgZG9lcyBub3QgbmVlZCBhbnl0aGluZyBlbHNl4oCmCj4gCj4gIAo+IAo+IEFscGVyCj4gCj4g IAo+IAo+ICAKPiAKPiAgCj4gCj4gIAo+IAo+IAo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IAo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gTUVYVCBtYWlsaW5n IGxpc3QKPiBNRVhUQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tZXh0Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Ck1FWFQgbWFpbGluZyBsaXN0Ck1FWFRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tZXh0Cg== From mext-bounces@ietf.org Fri Nov 21 08:50:56 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 723A13A6921; Fri, 21 Nov 2008 08:50:56 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FFB53A6921 for ; Fri, 21 Nov 2008 08:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIvt4lAueZr0 for ; Fri, 21 Nov 2008 08:50:54 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 5A4203A6919 for ; Fri, 21 Nov 2008 08:50:54 -0800 (PST) Received: from LENOVO ([130.129.94.244]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1L3ZDW0p8O-000166; Fri, 21 Nov 2008 11:50:52 -0500 From: "Alper Yegin" To: "'Lakshminath Dondeti'" References: <015001c94be1$e250a2f0$a6f1e8d0$@yegin@yegin.org> <4926E224.5070402@qualcomm.com> In-Reply-To: <4926E224.5070402@qualcomm.com> Date: Fri, 21 Nov 2008 18:50:50 +0200 Message-ID: <017c01c94bf9$50acc690$f20653b0$@yegin@yegin.org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclL9nyGXmqe1QjoQ7qz3W7GpT2PugAANihA Content-Language: en-us X-Provags-ID: V01U2FsdGVkX1+FF3llhpNxApxUAkCzLANjWvpqUGmWPAaPlkK +7lOE5Msaf+pnCxhepacI/7cQiRNtBwctEUNo7CHY4y61qU8vX SYX063+1ZWKfdV+dhqqqg== Cc: mext@ietf.org Subject: Re: [MEXT] IPsec for MIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org CkhpIExha3NobWluYXRoLAoKPiBJUHNlYyBleGlzdHMuCj4gMzc3NSBSZXF1aXJlcyBpdC4KPiBW ZW5kb3JzIGltcGxlbWVudGVkIGl0LgoKSW5kZWVkLiBOb2JvZHkgZGlzcHV0ZWQgdGhhdC4gTWF5 YmUgeW91IG1pc3VuZGVyc3Rvb2QgeWVzdGVyZGF5J3MgZGlzY3Vzc2lvbiwgaXQgd2FzIG5vdCBh Ym91dCBlcmFkaWNhdGluZyBJUHNlYyBmcm9tIHRoZSB3b3JsZC4KCj4gOikKPiAKPiBTbywganVz dCBsaWtlIHRoZSBwcmVzZW50YXRpb24sIHRoYXQgbGluZSBvZiBhcmd1bWVudCByZWFsbHkgaXMK PiB1bmNvbnZpbmNpbmcuCj4gCj4gSW4gdGhlIG1lYW53aGlsZSA0Mjg1IGhhcyBhbiBJRVNHIG5v dGUgYXQgdGhlIGJlZ2lubmluZyB0aGF0IHNheXMsIHRoZQo+IGZvbGxvd2luZyBpcyBhIGJvZ3Vz IHByb3RvY29sLCBwbGVhc2UgZG9uJ3QgdXNlIGl0LiAgCgoKOikgaXQgZG9lcyBub3Qgc2F5IHRo YXQuIFlvdSBhcmUgbWlzcmVhZGluZyBpdCwgdG8gc2F5IHRoZSBsZWFzdC4gCgpJZiB5b3Ugd2Fu dCB0byBSRkMgdG8gc2F5IHRoYXQsIG9yIHRvIGVyYWRpY2F0ZSB0aGF0IFJGQywgdGhlbiB5b3Ug bmVlZCB0byB3cml0ZSBhbiBJLUQgIlJGQyA0Mjg1IGNvbnNpZGVyZWQgaGFybWZ1bCIgYW5kIGdl dCBJRVRGIHRvIHB1Ymxpc2ggaXQuIE9ubHkgYWZ0ZXIgdGhhbiBpdCBtYWtlcyBzZW5zZSBmb3Ig cGVvcGxlIHRvIGlnbm9yZSBSRkMgNDI4NS4KCkFscGVyCgoKCj4gVGhlIGZpcnN0IHN0ZXAgbWF5 Cj4gYmUgdG8gbWFrZSA0Mjg1IHN0YW5kYXJkcyB0cmFjayBhbmQgd2UgY2FuIGhhdmUgdGhpcyBk aXNjdXNzaW9uLgoKCgoKCj4gCj4gV2hpbGUgZG9pbmcgc28sIGl0IG1pZ2h0IGJlIHdvcnRod2hp bGUgdG8gdGhpbmsgYWJvdXQgd2hhdCBJIHdyb3RlCj4gZWFybGllciBhYm91dCBpbnRlcm9wZXJh YmlsaXR5IGFuZCBpbnRlcndvcmtpbmcgd2l0aCB0d28gZGlmZmVyZW50IGtleQo+IG1hbmFnZW1l bnQgYW5kIGVuY2Fwc3VsYXRpb24gcHJvdG9jb2xzLgo+IAo+IHRoYW5rcywKPiBMYWtzaG1pbmF0 aAo+IAo+IE9uIDExLzIxLzIwMDggNjowMyBBTSwgQWxwZXIgWWVnaW4gd3JvdGU6Cj4gPiBJIHdh cyByZWFsbHkgcHV6emxlZCBhYm91dCB0aGUgcHVzaGJhY2sgb24gQ2hhcmxpZeKAmXMgcHJlc2Vu dGF0aW9uLgo+ID4KPiA+Cj4gPgo+ID4gQ29tbWVudHMgc3VwcG9ydGluZyBzdWZmaWNpZW5jeSBv ZiBJUHNlYyBmb3IgTUlQNiBzZWVtZWQgdG8gaWdub3JlCj4gdGhlCj4gPiBmYWN0cyB0aGF0Ogo+ ID4KPiA+IC0gICAgICAgICAgUkZDIDQyODUgZXhpc3RlZAo+ID4KPiA+IC0gICAgICAgICAgU0RP cyBhZG9wdGVkIGl0Cj4gPgo+ID4gLSAgICAgICAgICBWZW5kb3JzIGltcGxlbWVudGVkIGl0Cj4g Pgo+ID4KPiA+Cj4gPiBIb3cgY2FuIGFueW9uZSBzYXkgSVBzZWMgaXMgdGhlIGJlc3Qgc29sdXRp b24gZm9yIE1JUDYgc2VjdXJpdHkgYW5kCj4gPiBpbmR1c3RyeSBkb2VzIG5vdCBuZWVkIGFueXRo aW5nIGVsc2XigKYKPiA+Cj4gPgo+ID4KPiA+IEFscGVyCj4gPgo+ID4KPiA+Cj4gPgo+ID4KPiA+ Cj4gPgo+ID4KPiA+Cj4gPgo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gLS0tCj4gPgo+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiA+IE1FWFQgbWFpbGluZyBs aXN0Cj4gPiBNRVhUQGlldGYub3JnCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21leHQKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCk1FWFQgbWFpbGluZyBsaXN0Ck1FWFRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tZXh0Cg== From mext-bounces@ietf.org Fri Nov 21 08:51:59 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 160F028C0EA; Fri, 21 Nov 2008 08:51:59 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72E8128C0EB for ; Fri, 21 Nov 2008 08:51:57 -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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miypHK+mysag for ; Fri, 21 Nov 2008 08:51:56 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 67D193A6A60 for ; Fri, 21 Nov 2008 08:51:56 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1L3ZES-0000PK-Va; Fri, 21 Nov 2008 17:51:49 +0100 From: arno@natisbad.org (Arnaud Ebalard) To: "Alper Yegin" References: <016901c94bf2$cc3abc60$64b03520$@yegin@yegin.org> 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:081121:alper.yegin@yegin.org::6gkaIvZkT989CHa6:00000000000000000000000000000000000000000XA9 X-Hashcash: 1:20:081121:mext@ietf.org::8shrOMBKi+madXW3:00001gSo X-Hashcash: 1:20:081121:charliep@computer.org::8wwHTGKjLjl5WOWG:00000000000000000000000000000000000000001XrM Date: Fri, 21 Nov 2008 08:50:03 -0800 In-Reply-To: <016901c94bf2$cc3abc60$64b03520$@yegin@yegin.org> (Alper Yegin's message of "Fri, 21 Nov 2008 18:04:10 +0200") Message-ID: <877i6xm3b8.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] RFC 3775bis: mandate on the use of IPsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org "Alper Yegin" writes: > Another issue with RFC 3775 is with the following text: > > The mobile node and the home agent MUST use an IPsec security > association to protect the integrity and authenticity of the Binding > Updates and Acknowledgements. > > Given the presence of RFC 4285 (and its adoption) it does not make sense to > mandate "use of IPsec." It's not like we expect RFC 4285 users to run it on > top of IPsec because RFC 3775 mandates use of IPsec J > > Note that we already took care of this with RFC 5213 which says: > > The mobile access gateway and the local mobility anchor MUST > implement IPsec for protecting the Proxy Mobile IPv6 signaling > messages [RFC4301]. IPsec is a mandatory-to-implement security > mechanism. However, additional documents may specify alternative > mechanisms and the mobility entities can enable a specific mechanism > for securing Proxy Mobile IPv6 signaling messages, based on either a > static configuration or after a dynamic negotiation using any > standard security negotiation protocols. IPsec has been chosen as the solution to protect MIPv6 signaling and data (3775, 3776, 4877, ...). One good argument (IMHO) was that IPv6 node are all expected to implement IPsec. Maybe we can argue on this IPv6 requirement for constrained devices but mext is not the place to do that. AFAICT, afterwhile, some specific captive environments with security at the link level and specific habits felt the need to have a lighter, possibly less powerful (in term of evolution and security wise) solution. [whyauth] explains that perfectly, IMHO. 4285 is a *specific* solution dedicated to a specific set of environments. MIPv6 security mechanisms (based IPsec/IKE) probably have their own drawbacks (requiring availability and integration between those components) but it covers most cases and generic networks. For instance, w/ a RFC4285-only based MIPv6 (no IPsec), which L3 security mechanism would be available to protect the communications between MN and HA? BTW, arguing against IPsec as the MIPv6 security protocol in the context of 3775bis does not make sense. Cheers, a+ [whyauth] : http://tools.ietf.org/html/draft-ietf-mip6-whyauthdataoption-07.html _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 21 08:59:20 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F48328C0EB; Fri, 21 Nov 2008 08:59:20 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7BE53A6A64 for ; Fri, 21 Nov 2008 08:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3MsdsIa+qGs for ; Fri, 21 Nov 2008 08:59:18 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 0D4F73A6A5E for ; Fri, 21 Nov 2008 08:59:18 -0800 (PST) Received: from LENOVO ([130.129.94.244]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1L3ZLY3LCx-0006bt; Fri, 21 Nov 2008 11:59:12 -0500 From: "Alper Yegin" To: "'Arnaud Ebalard'" References: <016901c94bf2$cc3abc60$64b03520$@yegin@yegin.org> <877i6xm3b8.fsf@natisbad.org> In-Reply-To: <877i6xm3b8.fsf@natisbad.org> Date: Fri, 21 Nov 2008 18:59:08 +0200 Message-ID: <017e01c94bfa$7a9fa5c0$6fdef140$@yegin@yegin.org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclL+Xw798VNpuyjR/6uYDcLp5LF9AAAMqeg Content-Language: en-us X-Provags-ID: V01U2FsdGVkX1+xaYezTvY/paeVNr+y8bpDv35m5TPyWiYsWYA wG/KXp4WT4ELBhC6gYQ127kfOR1HsahOthPJ3MUySf8ZKvwRPu s4C+Ke0vjbijDO3z0CGZQ== Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] RFC 3775bis: mandate on the use of IPsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org If IPsec was so good to MIP and RFC 4285-type solution was so insufficient, we would have seen IPsec support defined for MIPv4.... Alper > -----Original Message----- > From: Arnaud Ebalard [mailto:arno@natisbad.org] > Sent: Friday, November 21, 2008 6:50 PM > To: Alper Yegin > Cc: charliep@computer.org; mext@ietf.org > Subject: Re: [MEXT] RFC 3775bis: mandate on the use of IPsec > > > "Alper Yegin" writes: > > > Another issue with RFC 3775 is with the following text: > > > > The mobile node and the home agent MUST use an IPsec security > > association to protect the integrity and authenticity of the > Binding > > Updates and Acknowledgements. > > > > Given the presence of RFC 4285 (and its adoption) it does not make > sense to > > mandate "use of IPsec." It's not like we expect RFC 4285 users to run > it on > > top of IPsec because RFC 3775 mandates use of IPsec J > > > > Note that we already took care of this with RFC 5213 which says: > > > > The mobile access gateway and the local mobility anchor MUST > > implement IPsec for protecting the Proxy Mobile IPv6 signaling > > messages [RFC4301]. IPsec is a mandatory-to-implement security > > mechanism. However, additional documents may specify alternative > > mechanisms and the mobility entities can enable a specific > mechanism > > for securing Proxy Mobile IPv6 signaling messages, based on either > a > > static configuration or after a dynamic negotiation using any > > standard security negotiation protocols. > > IPsec has been chosen as the solution to protect MIPv6 signaling and > data (3775, 3776, 4877, ...). One good argument (IMHO) was that IPv6 > node are all expected to implement IPsec. Maybe we can argue on this > IPv6 requirement for constrained devices but mext is not the place to > do > that. > > AFAICT, afterwhile, some specific captive environments with security at > the link level and specific habits felt the need to have a lighter, > possibly less powerful (in term of evolution and security wise) > solution. [whyauth] explains that perfectly, IMHO. 4285 is a *specific* > solution dedicated to a specific set of environments. > > MIPv6 security mechanisms (based IPsec/IKE) probably have their own > drawbacks (requiring availability and integration between those > components) but it covers most cases and generic networks. For > instance, > w/ a RFC4285-only based MIPv6 (no IPsec), which L3 security mechanism > would be available to protect the communications between MN and HA? > > BTW, arguing against IPsec as the MIPv6 security protocol in the > context > of 3775bis does not make sense. > > Cheers, > > a+ > > [whyauth] : http://tools.ietf.org/html/draft-ietf-mip6- > whyauthdataoption-07.html _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 21 09:09:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EA9B3A6A53; Fri, 21 Nov 2008 09:09:03 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47ADA3A6A53 for ; Fri, 21 Nov 2008 09:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.999 X-Spam-Level: X-Spam-Status: No, score=-104.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, 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 knxKQZcnTbPW for ; Fri, 21 Nov 2008 09:09:01 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 16D933A697F for ; Fri, 21 Nov 2008 09:09:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1227287340; x=1258823340; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<4926EB1D.5090303@qualcomm.com>|Date:=20Fr i,=2021=20Nov=202008=2009:08:45=20-0800|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.18=20(Windows/20081105)|MIME-Version:=201 .0|To:=20Alper=20Yegin=20|CC:=20me xt@ietf.org|Subject:=20Re:=20[MEXT]=20IPsec=20for=20MIPv6 |References:=20<015001c94be1$e250a2f0$a6f1e8d0$@yegin@yeg in.org>=20<4926E224.5070402@qualcomm.com>=20<017c01c94bf9 $50acc690$f20653b0$@yegin@yegin.org>|In-Reply-To:=20<017c 01c94bf9$50acc690$f20653b0$@yegin@yegin.org> |Content-Type:=20text/plain=3B=20charset=3DUTF-8=3B=20for mat=3Dflowed|Content-Transfer-Encoding:=208bit |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5440"=3B=20 a=3D"13367928"; bh=AxEUr+4Bd3cIlDdNxxUAY7dcmFiipPF6Nv00wEY9F+w=; b=ifWsEPjg/Uaqh6S/5Lsvpy5nYr5WF/2uqbjRmPK1ayddN2vrTOnvwjeX DFH4IF+qhhTgcE/0tEo8SZ0ma1v2bpx3mNy89qK8nF0ElBragBPqgsl8c lWjUNe+uQQvDxIStOp27hN5FJYNaby6psUXPJfqM+XB6A6ZHz705LNqf9 A=; X-IronPort-AV: E=McAfee;i="5300,2777,5440"; a="13367928" 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; 21 Nov 2008 09:08:59 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mALH8xjf015977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Nov 2008 09:08:59 -0800 Received: from [10.50.76.57] (qconnect-10-50-76-57.qualcomm.com [10.50.76.57]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mALH8v7B027462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Nov 2008 09:08:58 -0800 Message-ID: <4926EB1D.5090303@qualcomm.com> Date: Fri, 21 Nov 2008 09:08:45 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Alper Yegin References: <015001c94be1$e250a2f0$a6f1e8d0$@yegin@yegin.org> <4926E224.5070402@qualcomm.com> <017c01c94bf9$50acc690$f20653b0$@yegin@yegin.org> In-Reply-To: <017c01c94bf9$50acc690$f20653b0$@yegin@yegin.org> Cc: mext@ietf.org Subject: Re: [MEXT] IPsec for MIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org CgpPbiAxMS8yMS8yMDA4IDg6NTAgQU0sIEFscGVyIFllZ2luIHdyb3RlOgo+IEhpIExha3NobWlu YXRoLAo+Cj4gICAKPj4gSVBzZWMgZXhpc3RzLgo+PiAzNzc1IFJlcXVpcmVzIGl0Lgo+PiBWZW5k b3JzIGltcGxlbWVudGVkIGl0Lgo+PiAgICAgCj4KPiBJbmRlZWQuIE5vYm9keSBkaXNwdXRlZCB0 aGF0LiBNYXliZSB5b3UgbWlzdW5kZXJzdG9vZCB5ZXN0ZXJkYXkncyBkaXNjdXNzaW9uLCBpdCB3 YXMgbm90IGFib3V0IGVyYWRpY2F0aW5nIElQc2VjIGZyb20gdGhlIHdvcmxkLgo+Cj4gICAKPj4g OikKPj4KPj4gU28sIGp1c3QgbGlrZSB0aGUgcHJlc2VudGF0aW9uLCB0aGF0IGxpbmUgb2YgYXJn dW1lbnQgcmVhbGx5IGlzCj4+IHVuY29udmluY2luZy4KPj4KPj4gSW4gdGhlIG1lYW53aGlsZSA0 Mjg1IGhhcyBhbiBJRVNHIG5vdGUgYXQgdGhlIGJlZ2lubmluZyB0aGF0IHNheXMsIHRoZQo+PiBm b2xsb3dpbmcgaXMgYSBib2d1cyBwcm90b2NvbCwgcGxlYXNlIGRvbid0IHVzZSBpdC4gIAo+PiAg ICAgCj4KPgo+IDopIGl0IGRvZXMgbm90IHNheSB0aGF0LiBZb3UgYXJlIG1pc3JlYWRpbmcgaXQs IHRvIHNheSB0aGUgbGVhc3QuIAo+Cj4gSWYgeW91IHdhbnQgdG8gUkZDIHRvIHNheSB0aGF0LCBv ciB0byBlcmFkaWNhdGUgdGhhdCBSRkMsIHRoZW4geW91IG5lZWQgdG8gd3JpdGUgYW4gSS1EICJS RkMgNDI4NSBjb25zaWRlcmVkIGhhcm1mdWwiIGFuZCBnZXQgSUVURiB0byBwdWJsaXNoIGl0LiBP bmx5IGFmdGVyIHRoYW4gaXQgbWFrZXMgc2Vuc2UgZm9yIHBlb3BsZSB0byBpZ25vcmUgUkZDIDQy ODUuCj4gICAKSGkgQWxwZXIsCgpGb3Igd2hhdCBpdCdzIHdvcnRoIHdlIGRvbid0IGhhdmUgc3Vj aCBhIHByb2Nlc3Mgc3BlY2lmaWVkIGFueXdoZXJlLiAKNDI4NSBpcyBpbmZvcm1hdGlvbmFsIGFu ZCBoYXMgdGhlIGZvbGxvd2luZyBzdGF0dXMqLiBJZiB3ZSBhcmUgdG8gc2F5IAp0aGF0IGl0IGhh cyBlcXVpdmFsZW50IHN0YXR1cywgdGhlcmUgbmVlZHMgdG8gYmUgYW4gaW50ZXJtZWRpYXRlIHN0 ZXAgdG8gCm1ha2UgaXQgc3RhbmRhcmRzIHRyYWNrLiBUaGF0J3Mgb3VyIHByb2Nlc3MuCgoqIDIw MjY6CgpBbiAiSW5mb3JtYXRpb25hbCIgc3BlY2lmaWNhdGlvbiBpcyBwdWJsaXNoZWQgZm9yIHRo ZSBnZW5lcmFsCiAgIGluZm9ybWF0aW9uIG9mIHRoZSBJbnRlcm5ldCBjb21tdW5pdHksIGFuZCBk b2VzIG5vdCByZXByZXNlbnQgYW4KICAgSW50ZXJuZXQgY29tbXVuaXR5IGNvbnNlbnN1cyBvciBy ZWNvbW1lbmRhdGlvbi4KClNvLCByZWFsbHkgd2UgaGF2ZSBhIGZldyBpbnRlcm1lZGlhdGUgb3B0 aW9ucyB0byBnZXQgdGhlcmUgZnJvbSBoZXJlOgoxIEJlZ2luIHB1YmxpY2F0aW9uIHByb2Nlc3Mg b2YgNDI4NSBjb250ZW50cyBpbiBzdGFuZGFyZHMgdHJhY2suCjIgY2hhbmdlIDIwMjYncyBkZWZp bml0aW9uIG9mICJJbmZvcm1hdGlvbmFsIgoKWW91IG1heSBoYXZlIGFuIGVhc2llciB0aW1lIHdp dGggdGhlIGZpcnN0IG9wdGlvbiA6KS4KCmJlc3QsCkxha3NobWluYXRoCj4gQWxwZXIKPgo+Cj4K PiAgIAo+PiBUaGUgZmlyc3Qgc3RlcCBtYXkKPj4gYmUgdG8gbWFrZSA0Mjg1IHN0YW5kYXJkcyB0 cmFjayBhbmQgd2UgY2FuIGhhdmUgdGhpcyBkaXNjdXNzaW9uLgo+PiAgICAgCj4KPgo+Cj4KPgo+ ICAgCj4+IFdoaWxlIGRvaW5nIHNvLCBpdCBtaWdodCBiZSB3b3J0aHdoaWxlIHRvIHRoaW5rIGFi b3V0IHdoYXQgSSB3cm90ZQo+PiBlYXJsaWVyIGFib3V0IGludGVyb3BlcmFiaWxpdHkgYW5kIGlu dGVyd29ya2luZyB3aXRoIHR3byBkaWZmZXJlbnQga2V5Cj4+IG1hbmFnZW1lbnQgYW5kIGVuY2Fw c3VsYXRpb24gcHJvdG9jb2xzLgo+Pgo+PiB0aGFua3MsCj4+IExha3NobWluYXRoCj4+Cj4+IE9u IDExLzIxLzIwMDggNjowMyBBTSwgQWxwZXIgWWVnaW4gd3JvdGU6Cj4+ICAgICAKPj4+IEkgd2Fz IHJlYWxseSBwdXp6bGVkIGFib3V0IHRoZSBwdXNoYmFjayBvbiBDaGFybGllw6Lvv73vv71zIHBy ZXNlbnRhdGlvbi4KPj4+Cj4+Pgo+Pj4KPj4+IENvbW1lbnRzIHN1cHBvcnRpbmcgc3VmZmljaWVu Y3kgb2YgSVBzZWMgZm9yIE1JUDYgc2VlbWVkIHRvIGlnbm9yZQo+Pj4gICAgICAgCj4+IHRoZQo+ PiAgICAgCj4+PiBmYWN0cyB0aGF0Ogo+Pj4KPj4+IC0gICAgICAgICAgUkZDIDQyODUgZXhpc3Rl ZAo+Pj4KPj4+IC0gICAgICAgICAgU0RPcyBhZG9wdGVkIGl0Cj4+Pgo+Pj4gLSAgICAgICAgICBW ZW5kb3JzIGltcGxlbWVudGVkIGl0Cj4+Pgo+Pj4KPj4+Cj4+PiBIb3cgY2FuIGFueW9uZSBzYXkg SVBzZWMgaXMgdGhlIGJlc3Qgc29sdXRpb24gZm9yIE1JUDYgc2VjdXJpdHkgYW5kCj4+PiBpbmR1 c3RyeSBkb2VzIG5vdCBuZWVkIGFueXRoaW5nIGVsc2XDou+/vcWgCj4+Pgo+Pj4KPj4+Cj4+PiBB bHBlcgo+Pj4KPj4+Cj4+Pgo+Pj4KPj4+Cj4+Pgo+Pj4KPj4+Cj4+Pgo+Pj4KPj4+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQo+Pj4gICAgICAgCj4+IC0tLQo+PiAgICAgCj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4gTUVYVCBtYWlsaW5nIGxpc3QKPj4+IE1FWFRA aWV0Zi5vcmcKPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4dAo+ Pj4gICAgICAgCj4KPgo+ICAgCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCk1FWFQgbWFpbGluZyBsaXN0Ck1FWFRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZXh0Cg== From mext-bounces@ietf.org Fri Nov 21 10:30:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4825C3A68E7; Fri, 21 Nov 2008 10:30:12 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9703A68E7 for ; Fri, 21 Nov 2008 10:30:11 -0800 (PST) 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 SutNLXcd4Zsg for ; Fri, 21 Nov 2008 10:30:11 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id D11033A6452 for ; Fri, 21 Nov 2008 10:30:10 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1L3alW-0002K8-Tn; Fri, 21 Nov 2008 19:30:03 +0100 From: arno@natisbad.org (Arnaud Ebalard) To: "Alper Yegin" References: <016901c94bf2$cc3abc60$64b03520$@yegin@yegin.org> <877i6xm3b8.fsf@natisbad.org> <017e01c94bfa$7a9fa5c0$6fdef140$@yegin@yegin.org> 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:081121:mext@ietf.org::e7NJkukdiyBiOCms:000026vu X-Hashcash: 1:20:081121:charliep@computer.org::FQlJ9zwgAffLYU5N:00000000000000000000000000000000000000002WoW X-Hashcash: 1:20:081121:alper.yegin@yegin.org::c0S7S3tEnIcemyYg:0000000000000000000000000000000000000000595V Date: Fri, 21 Nov 2008 10:28:18 -0800 In-Reply-To: <017e01c94bfa$7a9fa5c0$6fdef140$@yegin@yegin.org> (Alper Yegin's message of "Fri, 21 Nov 2008 18:59:08 +0200") Message-ID: <87vduh0w8t.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] RFC 3775bis: mandate on the use of IPsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org "Alper Yegin" writes: > If IPsec was so good to MIP and RFC 4285-type solution was so insufficient, > we would have seen IPsec support defined for MIPv4.... Maybe the lack of security in MIPv4 and the inability to *simply* couple the protocol w/ IPsec/IKE is one of the reason you don't see it deployed in the wild (meaning in corporate networks, home networks, internet, ...). Maybe the tighter integration with IPsec/IKE we have in MIPv6 will help *deploying* the protocol outside closed domains. What do you think? Note that I could have answered the following way: MIPv4 had FA too, but those have not been kept in MIPv6. It is another sign of the changes brought by IPv6 networks and an example of the differences in the design of MIPv4 and MIPv6. MIPv6 has been designed with the new ability brought by IPv6 (flat networks, no NAT, i.e. E2E) and in order to allow a deployment on *common* networks. RFC 4285 probably simplifies (from your point of view) what is proposed by 3775, 3776, 4877, ... but it limits the protocol in its possible deployment to those specific networks. Note that I am not arguing against 4285. I just consider that it is best suited for networks with specific hypothesis (closed domains, with link layer security). Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 21 11:59:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2792D3A68FF; Fri, 21 Nov 2008 11:59:15 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76EAF3A68FF for ; Fri, 21 Nov 2008 11:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Y+iA+rCzbobP for ; Fri, 21 Nov 2008 11:59:13 -0800 (PST) Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by core3.amsl.com (Postfix) with ESMTP id 85BE43A67F4 for ; Fri, 21 Nov 2008 11:59:13 -0800 (PST) Received: from smtp2.fc.hp.com (smtp2.fc.hp.com [15.11.136.114]) by g4t0015.houston.hp.com (Postfix) with ESMTP id 9B95B8373; Fri, 21 Nov 2008 19:59:11 +0000 (UTC) Received: from wrx.usa.hp.com (wrx.usa.hp.com [16.118.120.215]) by smtp2.fc.hp.com (Postfix) with ESMTP id 50E6D295233; Fri, 21 Nov 2008 19:43:54 +0000 (UTC) Message-ID: <4927130C.9030602@hp.com> Date: Fri, 21 Nov 2008 14:59:08 -0500 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Alper Yegin References: <025e01c94a87$8ab61940$a0224bc0$@yegin@yegin.org> <4925BBDC.1000603@wichorus.com> <006101c94b4a$5d6b5c70$18421550$@yegin@yegin.org> In-Reply-To: <006101c94b4a$5d6b5c70$18421550$@yegin@yegin.org> Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] issue 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org >> You >> are asking for the HA to store both the source address of the BU and >> the >> address in the AltCoA option in the binding cache entry if the two >> happen to be different. And further you want all signaling messages to >> be sent to the source address in the BU and the data packets sent to >> the >> address in the AltCoA option. IMO, this would be a new feature in RFC >> 3775, not a bug fix. :) Most implementations probably *are* storing the original source address, since sending the BAck sometimes requires waiting for DAD to complete, so the info is there. > I hope some other folks join the discussion, as this is my second pass on > the same arguments with Vijay :) I guess you're talking about me? :) >> Well, the fact is that you need significant changes to RFC 3775 to >> > explicitly support separation of control and data plane using the >> > AltCoA >> > option. You can't claim it is a "bug fix" and modify some text. :) >> > >> > Vijay > > > No.... you need NO change on the base spec. As I quoted earlier, spec is > very clear. I don't know what you think is missing in RFC 3775. > > > Now, the question is: where does the HA pull the source address of the last > received BU if it is generating a BRI? We can address that in the Binding > Revocation draft by adding that piece of information to the binding cache > entry. > > [IMHO, we can also add that to the base spec, but I see people are > uncomfortable with doing that] So the issue is "where do we send future packets for this MN ?". I think the preferred way would be to the Alt-CoA since that's the remote tunnel endpoint, and we know packets can get there. But in reality we should be able to send it to either. Do we need to clarify that in the base spec? -Brian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From 2008colo2011@gmail.com Fri Nov 21 12:17:04 2008 Return-Path: <2008colo2011@gmail.com> X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40623A688B; Fri, 21 Nov 2008 12:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.501 X-Spam-Level: ** X-Spam-Status: No, score=2.501 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfYnFf4oPa1G; Fri, 21 Nov 2008 12:17:04 -0800 (PST) Received: from maildcarg4.dc-host.net.ar (maildcarg4.dc-host.net.ar [200.55.6.135]) by core3.amsl.com (Postfix) with ESMTP id D783A3A6814; Fri, 21 Nov 2008 12:17:03 -0800 (PST) Received: from coloso ([200.122.92.50]) by maildcarg4.dc-host.net.ar (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0KAP007P09NYTDI0@maildcarg4.dc-host.net.ar>; Fri, 21 Nov 2008 17:16:46 -0300 (ART) Date: Fri, 21 Nov 2008 17:19:23 -0300 From: "2008colo2011@gmail.com" <2008colo2011@gmail.com> Subject: COMPUTADORA CORE 2 DUO E7200 + Monitor Samsung LCD 19" To: CORE2DUO <2008colo2011@gmail.com> Message-id: <385-2200811521201923850@coloso> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable COMPUTADORAS con 1 A=D1O DE GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALL= ITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS TAMBIEN DISPONIBLES PARA EL INTERIO= R=2E CONSULTE FACTURA A o B CEL: 15-3197-5821 EMail: 2008colo2011@gmail=2Ecom -Modelo: CORE 2 DUO -Procesador: E7200 CORE DUO 2=2E53 3MB cache 775 BOX 3 a=F1os de garantia -Motherboard: Asus P5GC-MX Socket 775 BOX=20 -Memoria: DDR2 2GB 667MHZ -Placa de video: PCI-E 512MB NX8400GS-TD256E MSI -Disco r=EDgido: 250GB SATA 2 -Medio optico: ReGrabadora de DVD PHILIPS 20X -Placa de red: 10/100 integrada -Placa de sonido: 6 canales -Puertos: 2USB frontales y 4USB traseros -Gabinete: SENTEY ATX c2 coolers fuente 500W -Teclado multimedia, Mouse optico, Parlantes y Diskettera 3 1/2 -Garantia equipo 12 meses -Sistema operativo instalado y funcionando FULL, todos los programas y uti= lidades -Monitor: LCD 19" Samsung 943NWX 3 a=F1os de garantia -PRECIO $2649 FINAL (IVA inc) Consulte otras configuraciones a medida, notebooks, camaras digitales y mu= cho mas From 2008note2111@gmail.com Fri Nov 21 23:54:34 2008 Return-Path: <2008note2111@gmail.com> X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14443A6944; Fri, 21 Nov 2008 23:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.358 X-Spam-Level: ** X-Spam-Status: No, score=2.358 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_50=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F959dufN295s; Fri, 21 Nov 2008 23:54:34 -0800 (PST) Received: from maildcarg4.dc-host.net.ar (maildcarg4.dc-host.net.ar [200.55.6.135]) by core3.amsl.com (Postfix) with ESMTP id 7B46D3A692B; Fri, 21 Nov 2008 23:54:34 -0800 (PST) Received: from localhost ([190.245.9.133]) by maildcarg4.dc-host.net.ar (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0KAQ00CI65YH48A0@maildcarg4.dc-host.net.ar>; Sat, 22 Nov 2008 04:54:19 -0300 (ART) Received: from f3t ([127.0.0.1]) by localhost with SMTP (Code-Crafters Ability Mail Server 2.61); Sat, 22 Nov 2008 05:54:26 +0100 Date: Sat, 22 Nov 2008 05:54:26 +0100 From: "2008note2111@gmail.com" <2008note2111@gmail.com> Subject: COMPUTADORA ATHLON COMPLETA UNICA! ATHLON 5000+ GeForce 6100 To: ATHLON <2008note2111@gmail.com> Message-id: <380-220081162245426593@f3t> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable COMPUTADORAS con 1 A=D1O DE GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALL= ITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS TAMBIEN DISPONIBLES PARA EL INTERIO= R=2E CONSULTE FACTURA A o B EMail: 2008note2111@gmail=2Ecom CEL: 15-3197-5821 -Modelo: ATHLON FIRE -Procesador: AMD ATHLON 64 DUAL CORE 5000+ Socket AM2 BOX -Motherboard: MSI K9N6GM-V chipset nVidia nForce 430 -Memoria: 1GB DDR2 667 -Placa de video: nVIDIA GeForce 6100GS 256MB -Disco r=EDgido: 160 GB SATA2 -Medio optico: ReGrabadora de DVD Hewlett Packard 20X -Placa de red: 10/100 on board -Placa de sonido: 8 canales -Puertos: 2USB frontales + 4USB traseros -Gabinete: KIT CIRKUIT PLANET 9024 -Teclado multimedia, Mouse optico, Parlantes y Diskettera 3 =BD=2E -Garantia 12 meses -Sistema operativo instalado y funcionando FULL, todos los programa y util= idades=2E Microsoft Windows XP SP3 -PRECIO $999 FINAL From mext-bounces@ietf.org Sat Nov 22 10:00:06 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 360BF3A6A78; Sat, 22 Nov 2008 10:00:06 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D24EF3A6A5B; Sat, 22 Nov 2008 10:00:03 -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: <20081122180003.D24EF3A6A5B@core3.amsl.com> Date: Sat, 22 Nov 2008 10:00:03 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-mib-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: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : NEMO Management Information Base Author(s) : S. Gundavelli, et al. Filename : draft-ietf-mext-nemo-mib-03.txt Pages : 45 Date : 2008-11-22 This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a Mobile IPv6 node with NEMO functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-mib-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-nemo-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-22095445.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Sat Nov 22 11:45:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D3A13A6997; Sat, 22 Nov 2008 11:45:18 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62FF43A6997 for ; Sat, 22 Nov 2008 11:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=0.699, 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 ZKFLul0q-IzQ for ; Sat, 22 Nov 2008 11:45:15 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 8E2363A6866 for ; Sat, 22 Nov 2008 11:45:15 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mAMJj8Lk005746; Sat, 22 Nov 2008 13:45:11 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Nov 2008 21:45:09 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Nov 2008 21:45:09 +0200 Received: from 10.241.58.209 ([10.241.58.209]) by daebe104.NOE.Nokia.com ([10.241.36.13]) with Microsoft Exchange Server HTTP-DAV ; Sat, 22 Nov 2008 19:45:07 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Sat, 22 Nov 2008 13:45:11 -0600 From: Basavaraj Patil To: ext Lakshminath Dondeti , Alper Yegin Message-ID: Thread-Topic: [MEXT] IPsec for MIPv6 Thread-Index: AclM2tSWFHBiQD6fz0OULBDRB7S+BA== In-Reply-To: <4926E224.5070402@qualcomm.com> Mime-version: 1.0 X-OriginalArrivalTime: 22 Nov 2008 19:45:09.0958 (UTC) FILETIME=[D3F7BE60:01C94CDA] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] IPsec for MIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vendors might be a bit of a stretch here. If you can name any other vendor other than yourself, I would believe the plurality. Of course there is the open source UMIP implementation. I hope you are not including that in your statement. But in terms of vendors, please indicate who else besides your company has an implementation. The other point is that IPsec exists. But IPsec use today beyond VPN connectivity for hosts to enterprises is the only thing. And IPsec is not a component in every host that has an IP stack today. 3775 is headed towards becoming a protocol of academic interest only if we do not correct course and build stuff that people would actually want to implement and use. -Raj > > >Hi Alper, > >IPsec exists. >3775 Requires it. >Vendors implemented it. > >:) > >So, just like the presentation, that line of argument really is >unconvincing. > >In the meanwhile 4285 has an IESG note at the beginning that says, the >following is a bogus protocol, please don't use it. The first step may >be to make 4285 standards track and we can have this discussion. > >While doing so, it might be worthwhile to think about what I wrote >earlier about interoperability and interworking with two different key >management and encapsulation protocols. > >thanks, >Lakshminath > >On 11/21/2008 6:03 AM, Alper Yegin wrote: >> I was really puzzled about the pushback on Charlie=B9s presentation. >> = >> = >> = >> Comments supporting sufficiency of IPsec for MIP6 seemed to ignore the >> facts that: >> = >> - RFC 4285 existed >> = >> - SDOs adopted it >> = >> - Vendors implemented it >> = >> = >> = >> How can anyone say IPsec is the best solution for MIP6 security and >> industry does not need anything else=8A >> = >> = >> = >> Alper >> = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 22 15:33:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4DF73A692D; Sat, 22 Nov 2008 15:33:53 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A137B3A692D for ; Sat, 22 Nov 2008 15:33:52 -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 FNuHhTW0HC11 for ; Sat, 22 Nov 2008 15:33:51 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id C098F3A6814 for ; Sat, 22 Nov 2008 15:33:50 -0800 (PST) Received: from [24.239.163.227] (helo=[192.168.1.102]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1L41yx-00036e-Bi; Sun, 23 Nov 2008 10:33:44 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Sun, 23 Nov 2008 10:33:30 +1100 From: Hesham Soliman To: Alper Yegin , Message-ID: Thread-Topic: [MEXT] RFC 3775bis: mandate on the use of IPsec Thread-Index: AclL8smtIrrpxdU/Q46quta3RWgR4gBB/AmK In-Reply-To: <016901c94bf2$cc3abc60$64b03520$@yegin@yegin.org> Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] RFC 3775bis: mandate on the use of IPsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alper, We can't remove the mandate for using IPsec. Not only is it too late, there is currently no better alternative. Please don't compare with 4285. I'm not against having something else and was a strong advocate of CGA-based schemes but 4285, is not a credible alternative for a PS. Other options can be added later and SDOs may choose to mandate it for their networks. I don't even know if that will be a good idea for interoperability but it's certainly much more doable than removing the mandate. In the meantime, there are other things that can be done to remove the interaction between MIP6 and IPsec implementations, like for instance not using IP in IP encapsulation for the BU.. Until there is a credible alternative to be compared, we can't really discuss lowering the mandate for IPsec. Currently there is no credible PS document. Hesham On 22/11/08 3:04 AM, "Alper Yegin" wrote: > Another issue with RFC 3775 is with the following text: > > > > The mobile node and the home agent MUST use an IPsec security > > association to protect the integrity and authenticity of the Binding > > Updates and Acknowledgements. > > > > > > Given the presence of RFC 4285 (and its adoption) it does not make sense to > mandate "use of IPsec." It's not like we expect RFC 4285 users to run it on > top of IPsec because RFC 3775 mandates use of IPsec J > > > > Note that we already took care of this with RFC 5213 which says: > > > > The mobile access gateway and the local mobility anchor MUST > implement IPsec for protecting the Proxy Mobile IPv6 signaling > messages [RFC4301]. IPsec is a mandatory-to-implement security > mechanism. However, additional documents may specify alternative > mechanisms and the mobility entities can enable a specific mechanism > for securing Proxy Mobile IPv6 signaling messages, based on either a > static configuration or after a dynamic negotiation using any > standard security negotiation protocols. > > > > Alper > > > > > > > > > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 22 17:11:57 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36BA53A6B05; Sat, 22 Nov 2008 17:11:57 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36CFF3A6B05 for ; Sat, 22 Nov 2008 17:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.266 X-Spam-Level: X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, 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 LJ-0RMho-FU5 for ; Sat, 22 Nov 2008 17:11:54 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 29B273A6A32 for ; Sat, 22 Nov 2008 17:11:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1227402712; x=1258938712; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<4928ADD6.7010702@qualcomm.com>|Date:=20Sa t,=2022=20Nov=202008=2017:11:50=20-0800|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.18=20(Windows/20081105)|MIME-Version:=201 .0|To:=20Basavaraj=20Patil=20 |CC:=20Alper=20Yegin=20,=20mext@ie tf.org|Subject:=20Re:=20[MEXT]=20IPsec=20for=20MIPv6 |References:=20 |In-Reply-To:=20|Content-Type:=20text/plain=3B=20charset=3DUTF-8=3B=20fo rmat=3Dflowed|Content-Transfer-Encoding:=208bit |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5442"=3B=20 a=3D"13394942"; bh=w7jCN58MtDahximtTtYr2yE5Y8PotIO7WJceUSORRVg=; b=XhtK9VXRbzO3e5Ic9b5bOFZQJqmSoW0XQB2sEBWoCzfHcd/YDjW45bYU ue3d9YG/bIPfBFMXXKVs015ATpYBCmt3yzrI8BCKkdIkQqtkR2NCorKNX oQGZN5R/lnNg2iSiJNlFVIBNUqInfrJpVsgP6snG5wWGH0n0ejvwxozWO 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5442"; a="13394942" 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; 22 Nov 2008 17:11:52 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAN1BqAc013256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 22 Nov 2008 17:11:52 -0800 Received: from [10.50.64.134] (qconnect-10-50-64-134.qualcomm.com [10.50.64.134]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAN1BpCg024865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 22 Nov 2008 17:11:51 -0800 Message-ID: <4928ADD6.7010702@qualcomm.com> Date: Sat, 22 Nov 2008 17:11:50 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: Cc: mext@ietf.org Subject: Re: [MEXT] IPsec for MIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org T24gMTEvMjIvMjAwOCAxMTo0NSBBTSwgQmFzYXZhcmFqIFBhdGlsIHdyb3RlOgo+IFZlbmRvcnMg bWlnaHQgYmUgYSBiaXQgb2YgYSBzdHJldGNoIGhlcmUuIElmIHlvdSBjYW4gbmFtZSBhbnkKPiBv dGhlciB2ZW5kb3Igb3RoZXIgdGhhbiB5b3Vyc2VsZiwgSSB3b3VsZCBiZWxpZXZlIHRoZSBwbHVy YWxpdHkuCj4gT2YgY291cnNlIHRoZXJlIGlzIHRoZSBvcGVuIHNvdXJjZSBVTUlQIGltcGxlbWVu dGF0aW9uLiBJIGhvcGUgeW91Cj4gYXJlIG5vdCBpbmNsdWRpbmcgdGhhdCBpbiB5b3VyIHN0YXRl bWVudC4KPiBCdXQgaW4gdGVybXMgb2YgdmVuZG9ycywgcGxlYXNlIGluZGljYXRlIHdobyBlbHNl IGJlc2lkZXMgeW91cgo+IGNvbXBhbnkgaGFzIGFuIGltcGxlbWVudGF0aW9uLgo+IAo+IFRoZSBv dGhlciBwb2ludCBpcyB0aGF0IElQc2VjIGV4aXN0cy4gQnV0IElQc2VjIHVzZSB0b2RheQo+IGJl eW9uZCBWUE4gY29ubmVjdGl2aXR5IGZvciBob3N0cyB0byBlbnRlcnByaXNlcyBpcyB0aGUgb25s eSB0aGluZy4KPiBBbmQgSVBzZWMgaXMgbm90IGEgY29tcG9uZW50IGluIGV2ZXJ5IGhvc3QgdGhh dCBoYXMgYW4gSVAgc3RhY2sgdG9kYXkuCj4gCj4gMzc3NSBpcyBoZWFkZWQgdG93YXJkcyBiZWNv bWluZyBhIHByb3RvY29sIG9mIGFjYWRlbWljIGludGVyZXN0IG9ubHkKPiBpZiB3ZSBkbyBub3Qg Y29ycmVjdCBjb3Vyc2UgYW5kIGJ1aWxkIHN0dWZmIHRoYXQgcGVvcGxlIHdvdWxkIGFjdHVhbGx5 Cj4gd2FudCB0byBpbXBsZW1lbnQgYW5kIHVzZS4KCkhpIFJhaiwKClRoZXJlIGFyZSBhbHdheXMg cGVvcGxlIHdobyB3YW50IHRvIGFkdm9jYXRlIGZvciBhIGxpdHRsZSBiaXQgb2YgCnNlY3VyaXR5 OyB3ZSBvbmx5IGhhdmUgdG8gbG9vayBhdCBXRVAsIFdQQSBhZHZvY2F0ZXMsIGltcGxlbWVudGVy cyBhbmQgCnVzZXJzIGZvciByZWNlbnQgcHJvb2YuICBFYWNoIHRpbWUsIHNpbWlsYXIgYXJndW1l bnRzIGFzIHlvdSB1c2UgYWJvdmUgCndlcmUgdXNlZCB0byBzdGFuZGFyZGl6ZSB0aG9zZS4gIFBl cmhhcHMgd2UgbmVlZCB0byBlZHVjYXRlIGFuZCBjb252aW5jZSAKcHJvZHVjdCBtYW5hZ2VycyBh cyB0byB3aGF0IGlzIHRoZSByaWdodCB0aGluZyB0byBkbywgcmF0aGVyIHRoYW4gdGFraW5nIAp0 aGUgcm91dGUgb2YgV0VQIGFuZCBXUEEsIHlldCBhZ2Fpbi4KCmJlc3QsCkxha3NobWluYXRoCgoK PiAKPiAtUmFqCj4gCj4gCj4+Cj4+IEhpIEFscGVyLAo+Pgo+PiBJUHNlYyBleGlzdHMuCj4+IDM3 NzUgUmVxdWlyZXMgaXQuCj4+IFZlbmRvcnMgaW1wbGVtZW50ZWQgaXQuCj4+Cj4+IDopCj4+Cj4+ IFNvLCBqdXN0IGxpa2UgdGhlIHByZXNlbnRhdGlvbiwgdGhhdCBsaW5lIG9mIGFyZ3VtZW50IHJl YWxseSBpcwo+PiB1bmNvbnZpbmNpbmcuCj4+Cj4+IEluIHRoZSBtZWFud2hpbGUgNDI4NSBoYXMg YW4gSUVTRyBub3RlIGF0IHRoZSBiZWdpbm5pbmcgdGhhdCBzYXlzLCB0aGUKPj4gZm9sbG93aW5n IGlzIGEgYm9ndXMgcHJvdG9jb2wsIHBsZWFzZSBkb24ndCB1c2UgaXQuICBUaGUgZmlyc3Qgc3Rl cCBtYXkKPj4gYmUgdG8gbWFrZSA0Mjg1IHN0YW5kYXJkcyB0cmFjayBhbmQgd2UgY2FuIGhhdmUg dGhpcyBkaXNjdXNzaW9uLgo+Pgo+PiBXaGlsZSBkb2luZyBzbywgaXQgbWlnaHQgYmUgd29ydGh3 aGlsZSB0byB0aGluayBhYm91dCB3aGF0IEkgd3JvdGUKPj4gZWFybGllciBhYm91dCBpbnRlcm9w ZXJhYmlsaXR5IGFuZCBpbnRlcndvcmtpbmcgd2l0aCB0d28gZGlmZmVyZW50IGtleQo+PiBtYW5h Z2VtZW50IGFuZCBlbmNhcHN1bGF0aW9uIHByb3RvY29scy4KPj4KPj4gdGhhbmtzLAo+PiBMYWtz aG1pbmF0aAo+Pgo+PiBPbiAxMS8yMS8yMDA4IDY6MDMgQU0sIEFscGVyIFllZ2luIHdyb3RlOgo+ Pj4gSSB3YXMgcmVhbGx5IHB1enpsZWQgYWJvdXQgdGhlIHB1c2hiYWNrIG9uIENoYXJsaWXCuXMg cHJlc2VudGF0aW9uLgo+Pj4KPj4+ICAKPj4+Cj4+PiBDb21tZW50cyBzdXBwb3J0aW5nIHN1ZmZp Y2llbmN5IG9mIElQc2VjIGZvciBNSVA2IHNlZW1lZCB0byBpZ25vcmUgdGhlCj4+PiBmYWN0cyB0 aGF0Ogo+Pj4KPj4+IC0gICAgICAgICAgUkZDIDQyODUgZXhpc3RlZAo+Pj4KPj4+IC0gICAgICAg ICAgU0RPcyBhZG9wdGVkIGl0Cj4+Pgo+Pj4gLSAgICAgICAgICBWZW5kb3JzIGltcGxlbWVudGVk IGl0Cj4+Pgo+Pj4gIAo+Pj4KPj4+IEhvdyBjYW4gYW55b25lIHNheSBJUHNlYyBpcyB0aGUgYmVz dCBzb2x1dGlvbiBmb3IgTUlQNiBzZWN1cml0eSBhbmQKPj4+IGluZHVzdHJ5IGRvZXMgbm90IG5l ZWQgYW55dGhpbmcgZWxzZe+/vQo+Pj4KPj4+ICAKPj4+Cj4+PiBBbHBlcgo+Pj4KPiAKPiAKPiAK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTUVYVCBtYWls aW5nIGxpc3QKTUVYVEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21leHQK From mext-bounces@ietf.org Sat Nov 22 21:01:56 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71B343A686C; Sat, 22 Nov 2008 21:01:56 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F5373A686C; Sat, 22 Nov 2008 21:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D165Yo-hE7QP; Sat, 22 Nov 2008 21:01:54 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0A1EF3A6405; Sat, 22 Nov 2008 21:01:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,653,1220227200"; d="scan'208";a="26525353" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 23 Nov 2008 05:01:51 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAN51pct017612; Sun, 23 Nov 2008 06:01:51 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAN51pBp020009; Sun, 23 Nov 2008 05:01:51 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Nov 2008 06:01:50 +0100 Received: from sgundavewxp ([10.32.246.214]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Nov 2008 06:01:49 +0100 From: "Sri Gundavelli" To: "'fan zhao'" , References: Date: Sat, 22 Nov 2008 21:01:46 -0800 Message-ID: <012801c94d28$97f44b10$d6f6200a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: AclLjZk6puLyNMS2TK+mAjLE/jvTYgBmMSpg X-OriginalArrivalTime: 23 Nov 2008 05:01:50.0237 (UTC) FILETIME=[9815DCD0:01C94D28] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3763; t=1227416511; x=1228280511; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20question=20on=20the=20DHCP-P D |Sender:=20; bh=uLi/OxxoDlaovpNp1d1QeK80mS0YqsipEL4SxXZE/xk=; b=TaRmRsnMGG+PoMqa+K57HKdiaMKWLTM0/KOhEMRfLrnlv4HG+nTyV7cQGQ HefF5Pr9f/SvI5pOxdgbRWOfoQGjyEr5qs5G3ueP2p2uZIQEbnBOfYU2fJqc 79Laq+3Ioe; Authentication-Results: ams-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: netlmm@ietf.org Subject: Re: [MEXT] [netlmm] question on the DHCP-PD X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > Below is the question regarding the DHCP based prefix delegation I had > on the today's mext meeting. > I also cc to the netlmm mailing list. Hi Fan, The home network prefix in Proxy Mobile IPv6 is a hosted prefix on the MN-AR link. It is NOT a delegated prefix to the mobile node such as in NEMO. It is a prefix owned by the mobile access gateway that is hosting that prefix. The Proxy Mobile IPv6 protocol may be allocating a unique prefix for each mobile, per the chosen addressing model, but the mobile still needs to obtain one or more IPv6 addresses from that prefix, each individually, based on the enabled address configuration procedure. It does not by default have full prefix range of addresses for its consumption, as in NEMO. In the context of this handoff scenario, the mobile will be able to send BU for the individual address(es) that it configured in the Proxy Mobile IPv6 domain. So, the NEMO extensions that you are referring to are not applicable here. The mobile just needs to defend these addresses individually and not request routing for the whole prefix. This scenario is covered in PMIP/CMIP interactions document. Sri > -----Original Message----- > From: netlmm-bounces@ietf.org > [mailto:netlmm-bounces@ietf.org] On Behalf Of fan zhao > Sent: Thursday, November 20, 2008 8:00 PM > To: mext@ietf.org > Cc: netlmm@ietf.org > Subject: [netlmm] question on the DHCP-PD > > Hi, > > Below is the question regarding the DHCP based prefix delegation I had > on the today's mext meeting. > I also cc to the netlmm mailing list. > > My question is when the MN connects to a source access network using > PMIP (or other type of network > based mobility protocol), it obtains a home network prefix. Then the > MN handovers to a target access > network (i.e. the foreign link for the MN) using the Mobile IPv6. The > handover procedure is as follows. > > 1) The MN obtains a care-of address from the target access network. > 2) The MN discovers the home agent if it does not know. > 3) The MN sets up the IPsec SA with the HA if it does not have the SA > with the HA before. > 4) During the step 3), the MN requests the HNP allocated from the HA > based on RFC 4877/5026. > 5) The MN realizes it is on the foreign link, then it needs to send > the BU to the HA. > Since the Mobile IPv6 BU can only register the binding between the CoA > and one single home address, > in order to register the binding between the HNP and the CoA, the MN > needs to use > the NEMO extensions, for example, by setting up the 'R' bit and using > the implicit mode. > Therefore the HNP is also used as the mobile network prefix based on > the NEMO protocol. > However, the home agent does not know the same prefix is used as the > mobile network prefix > in addition to the home network prefix. Therefore, in order for the > home agent to have the > information and set up states regarding the mobile network prefix, the > prefix delegation procedure > needs to be performed. With the DHCP based prefix delegation, the MN > requests the same HNP > in the DHCP request; however, since the HNP is already allocated to > the MN during > bootstrapping, such request may be rejected. Note that the HA can > contact a DHCP server for both > HNP and MNP assignment. > > It seems to me this issue is related to the separation between the > prefix delegation and the HNP allocation. > It is not clear to me how the DHCP-PD handles the case where the HNP > is the same as the MNP. > Do I miss something? Thanks. > > Sincerely, > fan > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 22 21:45:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B601A3A6961; Sat, 22 Nov 2008 21:45:51 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8F53A6961 for ; Sat, 22 Nov 2008 21:45:50 -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 pEfzfzVa+wYF for ; Sat, 22 Nov 2008 21:45:49 -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 B62FA3A6936 for ; Sat, 22 Nov 2008 21:45:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=VV1r2vyD1VaekrdeNiIXCCUJBIcbdF811uUHMq4AOR/xmnJ1DbvWwyWeTnRPP/3f; 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.74.16] (helo=[192.168.1.65]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L47mw-0002zJ-PH; Sun, 23 Nov 2008 00:45:42 -0500 Message-ID: <4928EE06.2020700@earthlink.net> Date: Sat, 22 Nov 2008 21:45:42 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Lakshminath Dondeti References: <4928ADD6.7010702@qualcomm.com> In-Reply-To: <4928ADD6.7010702@qualcomm.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f529ab4701236166330110c4989fc8ca10f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: mext@ietf.org, Basavaraj Patil Subject: Re: [MEXT] IPsec for MIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Lakshminath, Nowhere in the presentation was it stated that we were promoting a scheme with reduced security. Our emphasis remains on enabling alternative security mechanisms to be used when appropriate. Regards, Charlie P. Lakshminath Dondeti wrote: > > There are always people who want to advocate for a little bit of > security; we only have to look at WEP, WPA advocates, implementers and > users for recent proof. Each time, similar arguments as you use above > were used to standardize those. Perhaps we need to educate and > convince product managers as to what is the right thing to do, rather > than taking the route of WEP and WPA, yet again. > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 23 00:34:57 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4653A6942; Sun, 23 Nov 2008 00:34:57 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE0AC3A6942 for ; Sun, 23 Nov 2008 00:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.456 X-Spam-Level: X-Spam-Status: No, score=-103.456 tagged_above=-999 required=5 tests=[AWL=-0.857, 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 DWjgR5Gof6S9 for ; Sun, 23 Nov 2008 00:34:55 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id F1D8F3A67AC for ; Sun, 23 Nov 2008 00:34:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1227429293; x=1258965293; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<492915AA.8050308@qualcomm.com>|Date:=20Su n,=2023=20Nov=202008=2000:34:50=20-0800|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.18=20(Windows/20081105)|MIME-Version:=201 .0|To:=20"Charles=20E.=20Perkins"=20|CC:=20Basavaraj=20Patil=20,=20mext@ietf.org|Subject:=20Re:=20[MEXT]=20IPsec =20for=20MIPv6|References:=20=20<4928ADD6.7010702@qualcomm.com>=20<4928E E06.2020700@earthlink.net>|In-Reply-To:=20<4928EE06.20207 00@earthlink.net>|Content-Type:=20text/plain=3B=20charset =3DISO-8859-15=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-IronPort-AV:=20E=3DM cAfee=3Bi=3D"5100,188,5442"=3B=20a=3D"13372538"; bh=kXSha3o0EKm8RTa/tHkQ/D2yEtzhzyvdsJvWNyt605E=; b=YrCFyCdFacoNrPxSCM29WFv16t/f2gow1v+UoZaK1rTLlFyXnjgmEoRC 3CKtJAS3nJvWgpLHmvHqgsLFsl5HgDlLv9u/uOYypPNPFEBVoFUv1XBaQ k8+g0mbniTELEuVbWv8ixQjDWGHQh/0xsdkfy5Lmo/eqPe0anIZuGhN9L 0=; X-IronPort-AV: E=McAfee;i="5100,188,5442"; a="13372538" 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; 23 Nov 2008 00:34:53 -0800 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 mAN8Yq9T014758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 23 Nov 2008 00:34:53 -0800 Received: from [10.50.65.107] (qconnect-10-50-65-107.qualcomm.com [10.50.65.107]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAN8YpIJ001158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 23 Nov 2008 00:34:52 -0800 Message-ID: <492915AA.8050308@qualcomm.com> Date: Sun, 23 Nov 2008 00:34:50 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4928ADD6.7010702@qualcomm.com> <4928EE06.2020700@earthlink.net> In-Reply-To: <4928EE06.2020700@earthlink.net> Cc: mext@ietf.org, Basavaraj Patil Subject: Re: [MEXT] IPsec for MIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Charlie, Many thanks for the clarification. I presume then that you do not support 4285 as the alternative mechanism. regards, Lakshminath On 11/22/2008 9:45 PM, Charles E. Perkins wrote: > > Hello Lakshminath, > > Nowhere in the presentation was it stated that we were > promoting a scheme with reduced security. Our emphasis > remains on enabling alternative security mechanisms to > be used when appropriate. > > Regards, > Charlie P. > > > Lakshminath Dondeti wrote: >> >> There are always people who want to advocate for a little bit of >> security; we only have to look at WEP, WPA advocates, implementers and >> users for recent proof. Each time, similar arguments as you use above >> were used to standardize those. Perhaps we need to educate and >> convince product managers as to what is the right thing to do, rather >> than taking the route of WEP and WPA, yet again. >> > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 23 05:36:37 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C136A3A68C2; Sun, 23 Nov 2008 05:36:37 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B221F3A68C2 for ; Sun, 23 Nov 2008 05:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOu-8otYHc1x for ; Sun, 23 Nov 2008 05:36:36 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by core3.amsl.com (Postfix) with ESMTP id D9E753A6846 for ; Sun, 23 Nov 2008 05:36:35 -0800 (PST) Received: from LENOVO (dsl88-247-34287.ttnet.net.tr [88.247.133.239]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1L4F8U0Nj8-0001Hy; Sun, 23 Nov 2008 08:36:30 -0500 From: "Alper Yegin" To: "'Lakshminath Dondeti'" References: <015001c94be1$e250a2f0$a6f1e8d0$@yegin@yegin.org> <4926E224.5070402@qualcomm.com> <017c01c94bf9$50acc690$f20653b0$@yegin@yegin.org> <4926EB1D.5090303@qualcomm.com> In-Reply-To: <4926EB1D.5090303@qualcomm.com> Date: Sun, 23 Nov 2008 15:36:23 +0200 Message-ID: <022901c94d70$7ea18400$7be48c00$@yegin@yegin.org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclL+9ifkvgTWZiDTz2ujmGVQiELpwBdFuaA Content-Language: en-us X-Provags-ID: V01U2FsdGVkX19GgGVwZsnpNAPoem/2HwR9nD1qublH6J8e2vD 1+Z1L7Z2CWGgFNjm03Ytmztp8di92TaUy5nWyWyYjMymVQw2c+ 9uXHhI1EOK7ayGpSF5LJw== Cc: mext@ietf.org Subject: Re: [MEXT] IPsec for MIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org TGFrc2htaW5hdGgsCgpOb3doZXJlIGluIG15IGRpc2N1c3Npb25zIEkgc2FpZCBpbmZvcm1hdGlv bmFsIFJGQ3MgaGF2ZSB0aGUgc2FtZSBzdGF0dXMgYXMgc3RhbmRhcmQgUkZDcywgb3IgUkZDIDQy ODUgc2hhbGwgYmUgdXBncmFkZWQgdG8gc3RhbmRhcmRzIHRyYWNrLiBJZiB0aGVzZSB3ZXJlIHlv dXIgY29uY2VybnMsIHRoZW4gZG9uJ3Qgd29ycnkuCgpBbHBlcgoKCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0KPiBGcm9tOiBMYWtzaG1pbmF0aCBEb25kZXRpIFttYWlsdG86bGRvbmRldGlA cXVhbGNvbW0uY29tXQo+IFNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMjEsIDIwMDggNzowOSBQTQo+ IFRvOiBBbHBlciBZZWdpbgo+IENjOiBtZXh0QGlldGYub3JnCj4gU3ViamVjdDogUmU6IFtNRVhU XSBJUHNlYyBmb3IgTUlQdjYKPiAKPiAKPiAKPiBPbiAxMS8yMS8yMDA4IDg6NTAgQU0sIEFscGVy IFllZ2luIHdyb3RlOgo+ID4gSGkgTGFrc2htaW5hdGgsCj4gPgo+ID4KPiA+PiBJUHNlYyBleGlz dHMuCj4gPj4gMzc3NSBSZXF1aXJlcyBpdC4KPiA+PiBWZW5kb3JzIGltcGxlbWVudGVkIGl0Lgo+ ID4+Cj4gPgo+ID4gSW5kZWVkLiBOb2JvZHkgZGlzcHV0ZWQgdGhhdC4gTWF5YmUgeW91IG1pc3Vu ZGVyc3Rvb2QgeWVzdGVyZGF5J3MKPiBkaXNjdXNzaW9uLCBpdCB3YXMgbm90IGFib3V0IGVyYWRp Y2F0aW5nIElQc2VjIGZyb20gdGhlIHdvcmxkLgo+ID4KPiA+Cj4gPj4gOikKPiA+Pgo+ID4+IFNv LCBqdXN0IGxpa2UgdGhlIHByZXNlbnRhdGlvbiwgdGhhdCBsaW5lIG9mIGFyZ3VtZW50IHJlYWxs eSBpcwo+ID4+IHVuY29udmluY2luZy4KPiA+Pgo+ID4+IEluIHRoZSBtZWFud2hpbGUgNDI4NSBo YXMgYW4gSUVTRyBub3RlIGF0IHRoZSBiZWdpbm5pbmcgdGhhdCBzYXlzLAo+IHRoZQo+ID4+IGZv bGxvd2luZyBpcyBhIGJvZ3VzIHByb3RvY29sLCBwbGVhc2UgZG9uJ3QgdXNlIGl0Lgo+ID4+Cj4g Pgo+ID4KPiA+IDopIGl0IGRvZXMgbm90IHNheSB0aGF0LiBZb3UgYXJlIG1pc3JlYWRpbmcgaXQs IHRvIHNheSB0aGUgbGVhc3QuCj4gPgo+ID4gSWYgeW91IHdhbnQgdG8gUkZDIHRvIHNheSB0aGF0 LCBvciB0byBlcmFkaWNhdGUgdGhhdCBSRkMsIHRoZW4geW91Cj4gbmVlZCB0byB3cml0ZSBhbiBJ LUQgIlJGQyA0Mjg1IGNvbnNpZGVyZWQgaGFybWZ1bCIgYW5kIGdldCBJRVRGIHRvCj4gcHVibGlz aCBpdC4gT25seSBhZnRlciB0aGFuIGl0IG1ha2VzIHNlbnNlIGZvciBwZW9wbGUgdG8gaWdub3Jl IFJGQwo+IDQyODUuCj4gPgo+IEhpIEFscGVyLAo+IAo+IEZvciB3aGF0IGl0J3Mgd29ydGggd2Ug ZG9uJ3QgaGF2ZSBzdWNoIGEgcHJvY2VzcyBzcGVjaWZpZWQgYW55d2hlcmUuCj4gNDI4NSBpcyBp bmZvcm1hdGlvbmFsIGFuZCBoYXMgdGhlIGZvbGxvd2luZyBzdGF0dXMqLiBJZiB3ZSBhcmUgdG8g c2F5Cj4gdGhhdCBpdCBoYXMgZXF1aXZhbGVudCBzdGF0dXMsIHRoZXJlIG5lZWRzIHRvIGJlIGFu IGludGVybWVkaWF0ZSBzdGVwCj4gdG8KPiBtYWtlIGl0IHN0YW5kYXJkcyB0cmFjay4gVGhhdCdz IG91ciBwcm9jZXNzLgo+IAo+ICogMjAyNjoKPiAKPiBBbiAiSW5mb3JtYXRpb25hbCIgc3BlY2lm aWNhdGlvbiBpcyBwdWJsaXNoZWQgZm9yIHRoZSBnZW5lcmFsCj4gICAgaW5mb3JtYXRpb24gb2Yg dGhlIEludGVybmV0IGNvbW11bml0eSwgYW5kIGRvZXMgbm90IHJlcHJlc2VudCBhbgo+ICAgIElu dGVybmV0IGNvbW11bml0eSBjb25zZW5zdXMgb3IgcmVjb21tZW5kYXRpb24uCj4gCj4gU28sIHJl YWxseSB3ZSBoYXZlIGEgZmV3IGludGVybWVkaWF0ZSBvcHRpb25zIHRvIGdldCB0aGVyZSBmcm9t IGhlcmU6Cj4gMSBCZWdpbiBwdWJsaWNhdGlvbiBwcm9jZXNzIG9mIDQyODUgY29udGVudHMgaW4g c3RhbmRhcmRzIHRyYWNrLgo+IDIgY2hhbmdlIDIwMjYncyBkZWZpbml0aW9uIG9mICJJbmZvcm1h dGlvbmFsIgo+IAo+IFlvdSBtYXkgaGF2ZSBhbiBlYXNpZXIgdGltZSB3aXRoIHRoZSBmaXJzdCBv cHRpb24gOikuCj4gCj4gYmVzdCwKPiBMYWtzaG1pbmF0aAo+ID4gQWxwZXIKPiA+Cj4gPgo+ID4K PiA+Cj4gPj4gVGhlIGZpcnN0IHN0ZXAgbWF5Cj4gPj4gYmUgdG8gbWFrZSA0Mjg1IHN0YW5kYXJk cyB0cmFjayBhbmQgd2UgY2FuIGhhdmUgdGhpcyBkaXNjdXNzaW9uLgo+ID4+Cj4gPgo+ID4KPiA+ Cj4gPgo+ID4KPiA+Cj4gPj4gV2hpbGUgZG9pbmcgc28sIGl0IG1pZ2h0IGJlIHdvcnRod2hpbGUg dG8gdGhpbmsgYWJvdXQgd2hhdCBJIHdyb3RlCj4gPj4gZWFybGllciBhYm91dCBpbnRlcm9wZXJh YmlsaXR5IGFuZCBpbnRlcndvcmtpbmcgd2l0aCB0d28gZGlmZmVyZW50Cj4ga2V5Cj4gPj4gbWFu YWdlbWVudCBhbmQgZW5jYXBzdWxhdGlvbiBwcm90b2NvbHMuCj4gPj4KPiA+PiB0aGFua3MsCj4g Pj4gTGFrc2htaW5hdGgKPiA+Pgo+ID4+IE9uIDExLzIxLzIwMDggNjowMyBBTSwgQWxwZXIgWWVn aW4gd3JvdGU6Cj4gPj4KPiA+Pj4gSSB3YXMgcmVhbGx5IHB1enpsZWQgYWJvdXQgdGhlIHB1c2hi YWNrIG9uIENoYXJsaWXDou+/ve+/vXMKPiBwcmVzZW50YXRpb24uCj4gPj4+Cj4gPj4+Cj4gPj4+ Cj4gPj4+IENvbW1lbnRzIHN1cHBvcnRpbmcgc3VmZmljaWVuY3kgb2YgSVBzZWMgZm9yIE1JUDYg c2VlbWVkIHRvIGlnbm9yZQo+ID4+Pgo+ID4+IHRoZQo+ID4+Cj4gPj4+IGZhY3RzIHRoYXQ6Cj4g Pj4+Cj4gPj4+IC0gICAgICAgICAgUkZDIDQyODUgZXhpc3RlZAo+ID4+Pgo+ID4+PiAtICAgICAg ICAgIFNET3MgYWRvcHRlZCBpdAo+ID4+Pgo+ID4+PiAtICAgICAgICAgIFZlbmRvcnMgaW1wbGVt ZW50ZWQgaXQKPiA+Pj4KPiA+Pj4KPiA+Pj4KPiA+Pj4gSG93IGNhbiBhbnlvbmUgc2F5IElQc2Vj IGlzIHRoZSBiZXN0IHNvbHV0aW9uIGZvciBNSVA2IHNlY3VyaXR5IGFuZAo+ID4+PiBpbmR1c3Ry eSBkb2VzIG5vdCBuZWVkIGFueXRoaW5nIGVsc2XDou+/vcWgCj4gPj4+Cj4gPj4+Cj4gPj4+Cj4g Pj4+IEFscGVyCj4gPj4+Cj4gPj4+Cj4gPj4+Cj4gPj4+Cj4gPj4+Cj4gPj4+Cj4gPj4+Cj4gPj4+ Cj4gPj4+Cj4gPj4+Cj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiAtLQo+ID4+Pgo+ID4+IC0tLQo+ID4+Cj4g Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPj4+ IE1FWFQgbWFpbGluZyBsaXN0Cj4gPj4+IE1FWFRAaWV0Zi5vcmcKPiA+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZXh0Cj4gPj4+Cj4gPgo+ID4KPiA+CgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNRVhUIG1haWxpbmcgbGlz dApNRVhUQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4 dAo= From mext-bounces@ietf.org Sun Nov 23 05:49:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B03E53A68C2; Sun, 23 Nov 2008 05:49:53 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E73003A68C2 for ; Sun, 23 Nov 2008 05:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hoNohQg+qcU for ; Sun, 23 Nov 2008 05:49:52 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by core3.amsl.com (Postfix) with ESMTP id 116C63A63D2 for ; Sun, 23 Nov 2008 05:49:52 -0800 (PST) Received: from LENOVO (dsl88-247-34287.ttnet.net.tr [88.247.133.239]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1L4FLL3xJd-0006Pj; Sun, 23 Nov 2008 08:49:50 -0500 From: "Alper Yegin" To: "'Hesham Soliman'" , References: <016901c94bf2$cc3abc60$64b03520$@yegin@yegin.org> In-Reply-To: Date: Sun, 23 Nov 2008 15:49:42 +0200 Message-ID: <022d01c94d72$5b117110$11345330$@yegin@yegin.org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclL8smtIrrpxdU/Q46quta3RWgR4gBB/AmKAB116CA= Content-Language: en-us X-Provags-ID: V01U2FsdGVkX1+q5ZQPxGbtL4zaihh1woxMGLheNsfWJXCQWKw 0DjZjwa8h2Dda6DA8AaxCubYpPfHYjaCVHurJGMq5j0F0Qw1pv nlhNK5dJjIw9p5wTNSObQ== Cc: mext@ietf.org Subject: Re: [MEXT] RFC 3775bis: mandate on the use of IPsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hesham, "mandatory to implement" is fine. "mandatory to use" is not fine. And that was not mean that RFC 4285 shall be upgraded to standards track. I hope this brief clarification helps. Alper > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Sunday, November 23, 2008 1:34 AM > To: Alper Yegin; charliep@computer.org > Cc: mext@ietf.org > Subject: Re: [MEXT] RFC 3775bis: mandate on the use of IPsec > > Alper, > > We can't remove the mandate for using IPsec. Not only is it too late, > there > is currently no better alternative. Please don't compare with 4285. I'm > not > against having something else and was a strong advocate of CGA-based > schemes > but 4285, is not a credible alternative for a PS. > Other options can be added later and SDOs may choose to mandate it for > their > networks. I don't even know if that will be a good idea for > interoperability > but it's certainly much more doable than removing the mandate. > > In the meantime, there are other things that can be done to remove the > interaction between MIP6 and IPsec implementations, like for instance > not > using IP in IP encapsulation for the BU.. > > Until there is a credible alternative to be compared, we can't really > discuss lowering the mandate for IPsec. Currently there is no credible > PS > document. > > > Hesham > > > On 22/11/08 3:04 AM, "Alper Yegin" wrote: > > > Another issue with RFC 3775 is with the following text: > > > > > > > > The mobile node and the home agent MUST use an IPsec security > > > > association to protect the integrity and authenticity of the > Binding > > > > Updates and Acknowledgements. > > > > > > > > > > > > Given the presence of RFC 4285 (and its adoption) it does not make > sense to > > mandate "use of IPsec." It's not like we expect RFC 4285 users to run > it on > > top of IPsec because RFC 3775 mandates use of IPsec J > > > > > > > > Note that we already took care of this with RFC 5213 which says: > > > > > > > > The mobile access gateway and the local mobility anchor MUST > > implement IPsec for protecting the Proxy Mobile IPv6 signaling > > messages [RFC4301]. IPsec is a mandatory-to-implement security > > mechanism. However, additional documents may specify alternative > > mechanisms and the mobility entities can enable a specific > mechanism > > for securing Proxy Mobile IPv6 signaling messages, based on either > a > > static configuration or after a dynamic negotiation using any > > standard security negotiation protocols. > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 23 15:12:17 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86F563A6809; Sun, 23 Nov 2008 15:12:17 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C61E73A6809 for ; Sun, 23 Nov 2008 15:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, 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 gmH4tk-witVC for ; Sun, 23 Nov 2008 15:12:15 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id B64723A6806 for ; Sun, 23 Nov 2008 15:12:14 -0800 (PST) Received: from [192.168.0.20] (bro67-5-88-177-196-175.fbx.proxad.net [88.177.196.175]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 26F264C0AB for ; Mon, 24 Nov 2008 08:12:05 +0900 (JST) Message-Id: From: Romain KUNTZ To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 24 Nov 2008 00:12:03 +0100 X-Mailer: Apple Mail (2.929.2) Subject: [MEXT] Comments on draft-ietf-mext-flow-binding-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0021203302==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0021203302== Content-Type: multipart/alternative; boundary=Apple-Mail-6-66620134 --Apple-Mail-6-66620134 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello, Here are some comments on draft-ietf-mext-flow-binding-00. On the protocol side, I don't see the motivation behind the "Refresh" operation. The document says (section 4.7): The refresh operation is included in this specification due to the nature of the BU message. The BU message updates existing bindings with new information. Hence, all information previously sent in the last BU message need to be resent in all new messages, otherwise such information will be lost. The flow bindings information are saved in the BCE, so as long as the BCE exists, the flow bindings remain, and when the BCE is deleted, the flow bindings are deleted. If I've read correctly, the draft never explicitly says that the flow bindings have to be deleted if they are not refreshed, and instead says that the flow bindings are deleted only when the BCE is deleted. So in the current state of the draft, refreshing seems useless. Besides, note that refreshing can be a costly operation: Mobile Routers may have hundreds of rules, e.g. depending on the number of clients they serve. Another concern is why another method to update a CoA is defined in this document (section 6.2)? First, I don't really see the motivations behind this, and if I understood correctly how n-casting is specified in the BC, one (HoA, FID) pair may reference multiple entries, which makes the CoA update impossible in case n-casting is used (see my other comment on that later). * Some more detailed comments: - Section 3.1, page 7, the Flow ID option shows a FID field of 16 bits but it is described as an "an 8-bit unsigned integer". - Page 9, it is said "If this value is used, one or more Binding Reference sub-options MUST exist.". Actually only a single Binding Reference sub-option is used but one or more BIDs must be indicated inside of it. - Section 3.2: The BID sub-option is 16 bits in the MCoA draft while here only 8 bits are used to specify a BID. - Some indication is needed on how this option (which can have a variable length) should be aligned and padded using the MIPv6 padding options - Section 4.2: "an entry is now identified by the pair (home address, FID)". This is true only when we want to update the flow bindings. To update a CoA (e.g. with a BU that only contains a BID option and no flow id options), the (HoA, BID) pair remains the key to lookup the BC/ BUL. Note also that the pair (HoA, FID) can refer to multiple entries when n-casting is used. - Section 4.5: what happens if the flow id option has the PRO field set to 1 (modify) and no flow description is present? Section 6.2 explains that it should be considered as a CoA update, but IMHO this should rather be considered as a request to modify the existing flow description in the BCE to a wild card request. - Section 6.1.1: "The FID field includes a value that does not already exist in the mobile node's binding update list.": [...] for that HA or MAP - "If the Binding Update sub-option includes only one BID," -> which sub-option, the Binding Reference sub-option? - Section 6.1.2: "the mobile node MUST NOT refresh or delete bindings associated with any care-of address other than the one included in the BU message." -> why? - Section 6.2: the "MODIFY" code is used but is never defined. It would be good to define the ADD/MODIFY/DELETE terms in section 3.1 and to use them through the document. - Section 6.3 states that n-casting is possible with the CN with some conditions, but section 7.1 simply forbids n-casting ("If the Action field indicates a request to n-cast the flow, the correspondent node MUST reject the option [...]") - Section 7.1: some notes on how the the flow binding is added to the binding cache should be written (existence of a BID sub-option in the BU, lookup in the BCE with that BID, ...). Same comment for section 8.1 - This section and section 8.1 do not say what to do when a request to delete a flow is received. - Section 8.1: "the home agent MUST check for the presence of the BID sub-option(s)." -> actually section 3.2 does not mandate the presence of the BID sub-options if the BID already exists in the BCE ("A BID sub-option is not necessarily included in the same BU [...]"). If the BID does not exist yet in the BCE or if no BID sub-options are present, then this is an error case. - "If one or more BIDs are present in the BID Reference sub-option" -> Binding Reference sub-option - The following procedure is too complex IMHO: If only one BID were included in the Binding Reference sub-option and it pointed to a different care-of address from the one included in the packet, then packets matching the flow would be bicast to those two addresses. Especially because the BU may be sent using another source address than the one expected for n-casting. Why not just forbid this case and explicitly ask for at least 2 BIDs in the binding reference sub-option? - I think it was already raised, but the document lacks some text on what status code should be used upon error (section 7.1, 8.1, ...) and how such error code should be treated on the receiver side. - Section 8.2: this section make me think that the section talking about the MN side does not say what should be done when the BAck is not received - Section 10: "associate some flows to an interface and other flows to another interface": I would replace "interface" with "CoA" * Some editorial comments: The document is inconsistent on how "Binding Update" / "Binding Acknowledgement" / "Flow Identification" / "Flow Binding" / "Flow Description" / "N-cast" are written (the first letter is sometimes lower case, sometimes upper case) Page 11: dsecription -> description Page 15: Acknwoledgement -> Acknowledgement Page 22: Correspondant -> Correspondent Page 23: authrozied -> authorized Cheers, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr LSIIT - Networks and Protocols Team http://clarinet.u-strasbg.fr/~kuntz/ --Apple-Mail-6-66620134 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Hello,

Here are some comments on = draft-ietf-mext-flow-binding-00.
On the protocol side, I don't see = the motivation behind the "Refresh" operation. The document says = (section 4.7):

  The refresh operation is included in = this specification due to the
  nature of the BU message. =  The BU message updates existing bindings
  with new = information.  Hence, all information previously sent in = the
  last BU message need to be resent in all new = messages, otherwise such
  information will be = lost.

The flow bindings information are saved in the BCE, so as = long as the BCE exists, the flow bindings remain, and when the BCE is = deleted, the flow bindings are deleted. If I've read correctly, the = draft never explicitly says that the flow bindings have to be deleted if = they are not refreshed, and instead says that the flow bindings are = deleted only when the BCE is deleted. So in the current state of the = draft, refreshing seems useless.

Besides, note that refreshing = can be a costly operation: Mobile Routers may have hundreds of rules, = e.g. depending on the number of clients they serve.


Another = concern is why another method to update a CoA is defined in this = document (section 6.2)? First, I don't really see the motivations behind = this, and if I understood correctly how n-casting is specified in the = BC, one (HoA, FID) pair may reference multiple entries, which makes the = CoA update impossible in case n-casting is used (see my other comment on = that later).


* Some more detailed comments:

- Section = 3.1, page 7, the Flow ID option shows a FID field of 16 bits but it is = described as an "an 8-bit unsigned integer".
- Page 9, it is said "If = this value is used, one or more Binding Reference sub-options MUST = exist.". Actually only a single Binding Reference sub-option is used but = one or more BIDs must be indicated inside of it.

- Section 3.2: = The BID sub-option is 16 bits in the MCoA draft while here only 8 bits = are used to specify a BID.
- Some indication is needed on how this = option (which can have a variable length) should be aligned and padded = using the MIPv6 padding options

- Section 4.2: "an entry is now = identified by the pair (home address, FID)". This is true only when we = want to update the flow bindings. To update a CoA (e.g. with a BU that = only contains a BID option and no flow id options), the (HoA, BID) pair = remains the key to lookup the BC/BUL. Note also that the pair (HoA, FID) = can refer to multiple entries when n-casting is used.

- Section = 4.5: what happens if the flow id option has the PRO field set to 1 = (modify) and no flow description is present? Section 6.2 explains that = it should be considered as a CoA update, but IMHO this should rather be = considered as a request to modify the existing flow description in the = BCE to a wild card request.

- Section 6.1.1: "The FID field = includes a value that does not already exist in the mobile node's = binding update list.": [...] for that HA or MAP
- "If the Binding = Update sub-option includes only one BID," -> which sub-option, the = Binding Reference sub-option?

- Section 6.1.2: "the mobile node = MUST NOT refresh or delete bindings associated with any care-of address = other than the one included in the BU message." -> why?

- Section = 6.2: the "MODIFY" code is used but is never defined. It would be good to = define the ADD/MODIFY/DELETE terms in section 3.1 and to use them = through the document.

- Section 6.3 states that n-casting is = possible with the CN with some conditions, but section 7.1 simply = forbids n-casting ("If the Action field indicates a request to n-cast = the flow, the correspondent node MUST reject the option [...]")

- = Section 7.1: some notes on how the the flow binding is added to the = binding cache should be written (existence of a BID sub-option in the = BU, lookup in the BCE with that BID, ...). Same comment for section = 8.1
- This section and section 8.1 do not say what to do when a = request to delete a flow is received.

- Section 8.1: "the home = agent MUST check for the presence of the BID sub-option(s)." -> actually = section 3.2 does not mandate the presence of the BID sub-options if the = BID already exists in the BCE ("A BID sub-option is not necessarily = included in the same BU [...]"). If the BID does not exist yet in the = BCE or if no BID sub-options are present, then this is an error = case.
- "If one or more BIDs are present in the BID Reference = sub-option" -> Binding Reference sub-option
- The following procedure = is too complex IMHO:

     If only one = BID were
     included in the Binding = Reference sub-option and it pointed to = a
     different care-of address from the = one included in the packet,
     then = packets matching the flow would be bicast to those = two
     addresses.

Especially = because the BU may be sent using another source address than the one = expected for n-casting. Why not just forbid this case and explicitly ask = for at least 2 BIDs in the binding reference sub-option?

- I = think it was already raised, but the document lacks some text on what = status code should be used upon error (section 7.1, 8.1, ...) and how = such error code should be treated on the receiver side.

- Section = 8.2: this section make me think that the section talking about the MN = side does not say what should be done when the BAck is not = received

- Section 10: "associate some flows to an interface and = other flows to another interface": I would replace "interface" with = "CoA"


* Some editorial comments:

The document is = inconsistent on how "Binding Update" / "Binding Acknowledgement" / "Flow = Identification" / "Flow Binding" / "Flow Description" / "N-cast" are = written (the first letter is sometimes lower case, sometimes upper = case)

Page 11: dsecription -> description
Page 15: = Acknwoledgement -> Acknowledgement
Page 22: Correspondant -> = Correspondent
Page 23: authrozied -> = authorized



Cheers,
-- 
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
L= SIIT - Networks and Protocols Team
http://clarinet.u-strasbg.fr= /~kuntz/
= --Apple-Mail-6-66620134-- --===============0021203302== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0021203302==-- From mext-bounces@ietf.org Mon Nov 24 03:04:41 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47EB93A68AF; Mon, 24 Nov 2008 03:04:41 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22C713A68AF for ; Mon, 24 Nov 2008 03:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.41 X-Spam-Level: X-Spam-Status: No, score=-0.41 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_12_24=2.189] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fdr1-68JRaZo for ; Mon, 24 Nov 2008 03:04:39 -0800 (PST) Received: from gw2.scei.a-star.edu.sg (gw2.scei.a-star.edu.sg [192.122.140.11]) by core3.amsl.com (Postfix) with ESMTP id E8A6E3A67B3 for ; Mon, 24 Nov 2008 03:04:38 -0800 (PST) Received: from mailfe01.teak.local.net (mailfe01.i2r.a-star.edu.sg [192.122.134.9] (may be forged)) by gw2.scei.a-star.edu.sg (8.14.1/8.14.1) with ESMTP id mAOB4PtR007843; Mon, 24 Nov 2008 03:04:25 -0800 Received: from t3400 ([10.217.141.230]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 18:58:37 +0800 Message-ID: <6AD333FB31504A738C781FAD246379A0@t3400> From: "QIU Ying" To: "Charles E. Perkins" , "Lakshminath Dondeti" , "Basavaraj Patil" , References: <4928ADD6.7010702@qualcomm.com> <4928EE06.2020700@earthlink.net> Date: Tue, 25 Nov 2008 18:56:49 +0800 MIME-Version: 1.0 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: 24 Nov 2008 10:58:37.0554 (UTC) FILETIME=[9A40F520:01C94E23] X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2008-11-24_06:2008-11-19, 2008-11-24, 2008-11-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-0811240026 Cc: mext@ietf.org Subject: Re: [MEXT] IPsec for MIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, I support to reconsider the use of IPSec in MIP6. Current RFC3775 uses ESP to protect the mobility signaling messages between MN and HA. Hence all of mobility flags in mobility signaling are invisible by ESP encapsulation. Since the mobility signaling messages are not so sensitive, it would not necessary to use ESP to encrypt these messages. Perhaps, it is satisfaction to just use IPSec AH mode to authenticate these signalings. In my opinion, the reason that MIP6 has been not widely employed currently is due to IPv6, not the overhead of IKE/IPSec. So far, who has heard a lot of the complaints on SSL overhead from the mobile users? :-) By the way, the overhead of establishing the security association would be ignored thanks to the quickly improvement of performance of mobile devices. For example, the performance of current mobile phones is already similar to the notebooks in 2000. Below is a simple comparison between ThinkPad X20, a popular notebook in 2000, and iPAQ900, a latest mobile phone: CPU: Intel Celeron 500Mhz vs. Intel PXA270 412MHz Memory: 64 MB vs. 128MB SDRAM Harddisk: 10GB vs 16GB SD card Connection: 10Mbps Ethernet vs 7.2 Mbps HSDPA I do not think WEP/WPA solutions would be suitable for MIP6 environments, because: 1) The connective range is much different: 300m LAN (WiFi) vs. global (MIP6) 2) The requested security strength is different: As roaming in global, MIP6 would not accept the concept of broadcasting the GTK (group temporal key). 3) In most cases, especially for accounting purpose, the HA needs to authenticate the mobile users' IDs. WEP/WPA omits the users' IDs 4) A flaw has been uncovered in the latest version of WAP2. Regards Qiu Ying ----- Original Message ----- From: "Charles E. Perkins" To: "Lakshminath Dondeti" Cc: ; "Basavaraj Patil" Sent: Sunday, November 23, 2008 1:45 PM Subject: Re: [MEXT] IPsec for MIPv6 > > Hello Lakshminath, > > Nowhere in the presentation was it stated that we were > promoting a scheme with reduced security. Our emphasis > remains on enabling alternative security mechanisms to > be used when appropriate. > > Regards, > Charlie P. > > > Lakshminath Dondeti wrote: >> >> There are always people who want to advocate for a little bit of >> security; we only have to look at WEP, WPA advocates, implementers and >> users for recent proof. Each time, similar arguments as you use above >> were used to standardize those. Perhaps we need to educate and convince >> product managers as to what is the right thing to do, rather than taking >> the route of WEP and WPA, yet again. >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext ********************** ANNOUNCEMENT ******************************** We have moved to Fusionopolis! Our official address is: Institute for Infocomm Research, 1 Fusionopolis Way, #21-01 Connexis, South Tower, Singapore 138632. Main line: +65 64082000. Main fax: +65 67761378 Please visit http://www.fusionopolis.a-star.edu.sg/ for more information on Fusionopolis. ****************************************************************** 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 mext-bounces@ietf.org Mon Nov 24 03:41:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4FD3A6923; Mon, 24 Nov 2008 03:41:26 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D869B3A6923 for ; Mon, 24 Nov 2008 03:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.441 X-Spam-Level: X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 ombz1LBZwyGa for ; Mon, 24 Nov 2008 03:41:24 -0800 (PST) Received: from ws000774.tietoenator.com (ws000774.tietoenator.com [193.12.181.129]) by core3.amsl.com (Postfix) with ESMTP id 869F83A67B4 for ; Mon, 24 Nov 2008 03:41:24 -0800 (PST) X-AuditID: c10cb581-000009a4000004d8-a8-492a92db34ea Received: from stingray.eu.tieto.com ([192.176.143.13]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Nov 2008 12:41:15 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 12:42:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Nov 2008 12:41:48 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] IPsec for MIPv6 Thread-Index: AclM2tSWFHBiQD6fz0OULBDRB7S+BABTbhwA References: <4926E224.5070402@qualcomm.com> From: To: , , X-OriginalArrivalTime: 24 Nov 2008 11:42:03.0896 (UTC) FILETIME=[ABC12F80:01C94E29] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] IPsec for MIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: base64 Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org SGksCgpQbGVhc2UgY291bnQgbXkgY29tcGFueSBpbiBhcyBhIFNXIHZlbmRvciBpbXBsZW1lbnRp bmcuCk1JUHY2LCBEU01JUHY2IHdpdGggMzc3NSBzZWN1cml0eSBzb2x1dGlvbiBiYXNlZCBvbiBJ UHNlYyBhbmQgSUtFdjIuCgpJIGNhbm5vdCBtZW50aW9uIHRoZSBwcm9kdWN0cyBvdXIgU1cgaXMg cGFydCBvZi4KCkJSLCBLYXJlbgoKKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKS2Fy ZW4gRWdlZGUgTmllbHNlbgpTeXN0ZW1zIERlc2lnbmVyLCBQaC5ELgoKVGlldG9FbmF0b3JBL1MK SVAgU29sdXRpb25zLCBUZWxlY29tICYgTWVkaWEKU2thbmRlcmJvcmd2ZWogMjMyLCA4MjYwIFZp YnkgSiwgREstRGVubWFyawpQaG9uZTogKzQ1IDg5Mzg1MTAwCkZheDogKzQ1IDg5Mzg1MTAxCkRp cmVjdCBQaG9uZSAvIE1vYmlsZSArNDUgMjUxMzQzMzYKRS1tYWlsOiBrYXJlbi5uaWVsc2VuQHRp ZXRvZW5hdG9yLmNvbQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgp3d3cudGlldG9l bmF0b3IuY29tICAKCgoKPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+IEZyb206IG1leHQt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1leHQtYm91bmNlc0BpZXRmLm9yZ10gT24gCj4gQmVo YWxmIE9mIEJhc2F2YXJhaiBQYXRpbAo+IFNlbnQ6IFNhdHVyZGF5LCBOb3ZlbWJlciAyMiwgMjAw OCA4OjQ1IFBNCj4gVG86IGV4dCBMYWtzaG1pbmF0aCBEb25kZXRpOyBBbHBlciBZZWdpbgo+IENj OiBtZXh0QGlldGYub3JnCj4gU3ViamVjdDogUmU6IFtNRVhUXSBJUHNlYyBmb3IgTUlQdjYKPiAK PiAKPiBWZW5kb3JzIG1pZ2h0IGJlIGEgYml0IG9mIGEgc3RyZXRjaCBoZXJlLiBJZiB5b3UgY2Fu IG5hbWUgYW55Cj4gb3RoZXIgdmVuZG9yIG90aGVyIHRoYW4geW91cnNlbGYsIEkgd291bGQgYmVs aWV2ZSB0aGUgcGx1cmFsaXR5Lgo+IE9mIGNvdXJzZSB0aGVyZSBpcyB0aGUgb3BlbiBzb3VyY2Ug VU1JUCBpbXBsZW1lbnRhdGlvbi4gSSBob3BlIHlvdQo+IGFyZSBub3QgaW5jbHVkaW5nIHRoYXQg aW4geW91ciBzdGF0ZW1lbnQuCj4gQnV0IGluIHRlcm1zIG9mIHZlbmRvcnMsIHBsZWFzZSBpbmRp Y2F0ZSB3aG8gZWxzZSBiZXNpZGVzIHlvdXIKPiBjb21wYW55IGhhcyBhbiBpbXBsZW1lbnRhdGlv bi4KPiAKPiBUaGUgb3RoZXIgcG9pbnQgaXMgdGhhdCBJUHNlYyBleGlzdHMuIEJ1dCBJUHNlYyB1 c2UgdG9kYXkKPiBiZXlvbmQgVlBOIGNvbm5lY3Rpdml0eSBmb3IgaG9zdHMgdG8gZW50ZXJwcmlz ZXMgaXMgdGhlIG9ubHkgdGhpbmcuCj4gQW5kIElQc2VjIGlzIG5vdCBhIGNvbXBvbmVudCBpbiBl dmVyeSBob3N0IHRoYXQgaGFzIGFuIElQIHN0YWNrIHRvZGF5Lgo+IAo+IDM3NzUgaXMgaGVhZGVk IHRvd2FyZHMgYmVjb21pbmcgYSBwcm90b2NvbCBvZiBhY2FkZW1pYyBpbnRlcmVzdCBvbmx5Cj4g aWYgd2UgZG8gbm90IGNvcnJlY3QgY291cnNlIGFuZCBidWlsZCBzdHVmZiB0aGF0IHBlb3BsZSB3 b3VsZCBhY3R1YWxseQo+IHdhbnQgdG8gaW1wbGVtZW50IGFuZCB1c2UuCj4gCj4gLVJhago+IAo+ IAo+ID4KPiA+Cj4gPkhpIEFscGVyLAo+ID4KPiA+SVBzZWMgZXhpc3RzLgo+ID4zNzc1IFJlcXVp cmVzIGl0Lgo+ID5WZW5kb3JzIGltcGxlbWVudGVkIGl0Lgo+ID4KPiA+OikKPiA+Cj4gPlNvLCBq dXN0IGxpa2UgdGhlIHByZXNlbnRhdGlvbiwgdGhhdCBsaW5lIG9mIGFyZ3VtZW50IHJlYWxseSBp cwo+ID51bmNvbnZpbmNpbmcuCj4gPgo+ID5JbiB0aGUgbWVhbndoaWxlIDQyODUgaGFzIGFuIElF U0cgbm90ZSBhdCB0aGUgYmVnaW5uaW5nIHRoYXQgCj4gc2F5cywgdGhlCj4gPmZvbGxvd2luZyBp cyBhIGJvZ3VzIHByb3RvY29sLCBwbGVhc2UgZG9uJ3QgdXNlIGl0LiAgVGhlIAo+IGZpcnN0IHN0 ZXAgbWF5Cj4gPmJlIHRvIG1ha2UgNDI4NSBzdGFuZGFyZHMgdHJhY2sgYW5kIHdlIGNhbiBoYXZl IHRoaXMgZGlzY3Vzc2lvbi4KPiA+Cj4gPldoaWxlIGRvaW5nIHNvLCBpdCBtaWdodCBiZSB3b3J0 aHdoaWxlIHRvIHRoaW5rIGFib3V0IHdoYXQgSSB3cm90ZQo+ID5lYXJsaWVyIGFib3V0IGludGVy b3BlcmFiaWxpdHkgYW5kIGludGVyd29ya2luZyB3aXRoIHR3byAKPiBkaWZmZXJlbnQga2V5Cj4g Pm1hbmFnZW1lbnQgYW5kIGVuY2Fwc3VsYXRpb24gcHJvdG9jb2xzLgo+ID4KPiA+dGhhbmtzLAo+ ID5MYWtzaG1pbmF0aAo+ID4KPiA+T24gMTEvMjEvMjAwOCA2OjAzIEFNLCBBbHBlciBZZWdpbiB3 cm90ZToKPiA+PiBJIHdhcyByZWFsbHkgcHV6emxlZCBhYm91dCB0aGUgcHVzaGJhY2sgb24gQ2hh cmxpZblzIHByZXNlbnRhdGlvbi4KPiA+PiAKPiA+PiAgCj4gPj4gCj4gPj4gQ29tbWVudHMgc3Vw cG9ydGluZyBzdWZmaWNpZW5jeSBvZiBJUHNlYyBmb3IgTUlQNiBzZWVtZWQgCj4gdG8gaWdub3Jl IHRoZQo+ID4+IGZhY3RzIHRoYXQ6Cj4gPj4gCj4gPj4gLSAgICAgICAgICBSRkMgNDI4NSBleGlz dGVkCj4gPj4gCj4gPj4gLSAgICAgICAgICBTRE9zIGFkb3B0ZWQgaXQKPiA+PiAKPiA+PiAtICAg ICAgICAgIFZlbmRvcnMgaW1wbGVtZW50ZWQgaXQKPiA+PiAKPiA+PiAgCj4gPj4gCj4gPj4gSG93 IGNhbiBhbnlvbmUgc2F5IElQc2VjIGlzIHRoZSBiZXN0IHNvbHV0aW9uIGZvciBNSVA2IHNlY3Vy aXR5IGFuZAo+ID4+IGluZHVzdHJ5IGRvZXMgbm90IG5lZWQgYW55dGhpbmcgZWxzZdAKPiA+PiAK PiA+PiAgCj4gPj4gCj4gPj4gQWxwZXIKPiA+PiAKPiAKPiAKPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IE1FWFQgbWFpbGluZyBsaXN0Cj4gTUVYVEBp ZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4dAo+IApf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNRVhUIG1haWxp bmcgbGlzdApNRVhUQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbWV4dAo= From mext-bounces@ietf.org Mon Nov 24 14:48:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606713A6B7D; Mon, 24 Nov 2008 14:48:12 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324913A6B7D for ; Mon, 24 Nov 2008 14:48:11 -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 6DwD7c455Syy for ; Mon, 24 Nov 2008 14:48:10 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id E7BFB3A6A6E for ; Mon, 24 Nov 2008 14:48:09 -0800 (PST) Received: by qyk4 with SMTP id 4so2013889qyk.13 for ; Mon, 24 Nov 2008 14:48:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=jUVeQG1nZhYpJMiAPfJg9GVOSchcEtwHZB5HcQsbCbo=; b=S/+LO2yPhW1B4jrk1adWiyviusVduTdeJmasd5nfD9OdBTRN9C4FpOx4FnUhMwQkQh PQl5da9T+s8KSmfNdlluLGOBCfq2ALu1MlL4Jy2i23ZEDk6QpxY1D0hTCpIBTRqmmooh /aB4RS5h90qxxCYbf8c80j6sZXYMc7lfLG1EU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Sv8DkHGXXOC58HO65GHrZDuBOS+4tyUU1mnBrnB2bBd2tppXujeaHD9ytent1rhiow LbCf8Ysu60SE/N9gUX7pRdKMmTY8ZcZ7PT2ltP0RzaJF353g7yQ/JhZy2yBaSJTSOkUS DFLqIaD5Jjg5Oqmv9/1Id/ezJuG3TLUmGItHY= Received: by 10.214.43.5 with SMTP id q5mr2891312qaq.205.1227566887171; Mon, 24 Nov 2008 14:48:07 -0800 (PST) Received: by 10.214.43.19 with HTTP; Mon, 24 Nov 2008 14:48:07 -0800 (PST) Message-ID: Date: Mon, 24 Nov 2008 14:48:07 -0800 From: "fan zhao" To: "Sri Gundavelli" In-Reply-To: <012801c94d28$97f44b10$d6f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <012801c94d28$97f44b10$d6f6200a@amer.cisco.com> Cc: netlmm@ietf.org, mext@ietf.org Subject: Re: [MEXT] [netlmm] question on the DHCP-PD X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Sri, Thanks for your reply. Please see below. On Sat, Nov 22, 2008 at 9:01 PM, Sri Gundavelli wrote: >> Below is the question regarding the DHCP based prefix delegation I had >> on the today's mext meeting. >> I also cc to the netlmm mailing list. > > Hi Fan, > > The home network prefix in Proxy Mobile IPv6 is a hosted > prefix on the MN-AR link. It is NOT a delegated prefix to > the mobile node such as in NEMO. It is a prefix owned by > the mobile access gateway that is hosting that prefix. The > Proxy Mobile IPv6 protocol may be allocating a unique prefix > for each mobile, per the chosen addressing model, but the > mobile still needs to obtain one or more IPv6 addresses from > that prefix, each individually, based on the enabled address > configuration procedure. It does not by default have full > prefix range of addresses for its consumption, as in NEMO. I agree with you that the home network prefix and the mobile network prefix are two different concepts. Here the issue is that the home network prefix may be the same as the mobile network prefix. Please see more on this below. > > In the context of this handoff scenario, the mobile will > be able to send BU for the individual address(es) that it > configured in the Proxy Mobile IPv6 domain. So, the NEMO > extensions that you are referring to are not applicable here. > The mobile just needs to defend these addresses individually > and not request routing for the whole prefix. This scenario > is covered in PMIP/CMIP interactions document. I agree that the MN can send separate BUs for each IP address configured from the home network prefix. Note that the MN may also need to set up IPsec SAs for each IP address since the IPsec SA may be associated with the IP address only, which results in delay during handover. In order to reduce delay, the home network prefix needs to be registered in the binding update with the 'R' bit set and the mobile network prefix option is not reuqired to be included assuming the implicit mode is used. Note that only one IPsec SA (associated with one home address) is needed to protect this BU. This is because different addressing models are used in PMIP and CMIP. Folks in 3GPP SA2 have discussed this issue and agreed that the whole home network prefix should be moved during handover. Furthermore, regardless whether the MN performs HO between PMIP and CMIP or not, I think this is a generic issue to the DHCP PD because the NEMO does allow the MN to have the same home network prefix and the mobile network prefix. I just want to know whether the DHCP PD can handle this case. Thanks. Sincerely, fan > > Sri > > > >> -----Original Message----- >> From: netlmm-bounces@ietf.org >> [mailto:netlmm-bounces@ietf.org] On Behalf Of fan zhao >> Sent: Thursday, November 20, 2008 8:00 PM >> To: mext@ietf.org >> Cc: netlmm@ietf.org >> Subject: [netlmm] question on the DHCP-PD >> >> Hi, >> >> Below is the question regarding the DHCP based prefix delegation I had >> on the today's mext meeting. >> I also cc to the netlmm mailing list. >> >> My question is when the MN connects to a source access network using >> PMIP (or other type of network >> based mobility protocol), it obtains a home network prefix. Then the >> MN handovers to a target access >> network (i.e. the foreign link for the MN) using the Mobile IPv6. The >> handover procedure is as follows. >> >> 1) The MN obtains a care-of address from the target access network. >> 2) The MN discovers the home agent if it does not know. >> 3) The MN sets up the IPsec SA with the HA if it does not have the SA >> with the HA before. >> 4) During the step 3), the MN requests the HNP allocated from the HA >> based on RFC 4877/5026. >> 5) The MN realizes it is on the foreign link, then it needs to send >> the BU to the HA. >> Since the Mobile IPv6 BU can only register the binding between the CoA >> and one single home address, >> in order to register the binding between the HNP and the CoA, the MN >> needs to use >> the NEMO extensions, for example, by setting up the 'R' bit and using >> the implicit mode. >> Therefore the HNP is also used as the mobile network prefix based on >> the NEMO protocol. >> However, the home agent does not know the same prefix is used as the >> mobile network prefix >> in addition to the home network prefix. Therefore, in order for the >> home agent to have the >> information and set up states regarding the mobile network prefix, the >> prefix delegation procedure >> needs to be performed. With the DHCP based prefix delegation, the MN >> requests the same HNP >> in the DHCP request; however, since the HNP is already allocated to >> the MN during >> bootstrapping, such request may be rejected. Note that the HA can >> contact a DHCP server for both >> HNP and MNP assignment. >> >> It seems to me this issue is related to the separation between the >> prefix delegation and the HNP allocation. >> It is not clear to me how the DHCP-PD handles the case where the HNP >> is the same as the MNP. >> Do I miss something? Thanks. >> >> Sincerely, >> fan >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 24 16:20:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C323A682C; Mon, 24 Nov 2008 16:20:52 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619983A682C for ; Mon, 24 Nov 2008 16:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.199 X-Spam-Level: X-Spam-Status: No, score=-105.199 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e37hAmuOO+JE for ; Mon, 24 Nov 2008 16:20:50 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 94E733A67FB for ; Mon, 24 Nov 2008 16:20:50 -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=1227572448; x=1259108448; 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:=20Romain=20KUNTZ=20,=20"me xt@ietf.org"=20|Date:=20Mon,=2024=20Nov=20 2008=2016:20:39=20-0800|Subject:=20RE:=20[MEXT]=20Comment s=20on=20draft-ietf-mext-flow-binding-00|Thread-Topic:=20 [MEXT]=20Comments=20on=20draft-ietf-mext-flow-binding-00 |Thread-Index:=20AclNwPF+Ww9Oz8LFRqacf5PZsk4Q7AAzvm+w |Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3D6CA06E9@ NASANEXMB08.na.qualcomm.com>|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"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5444"=3B=20a=3D"13415870"; bh=1EFh06AyRZ8MfsvJkHPPs3JaNKvSURmJxC0OSYGAyjk=; b=cXzDTuA6zkJAnYQ5Qox031fuum+4RerC+nJD/oR64eTW4hfDV94g+rcZ gz7s/SBmMqgD/SUQexDoOiaZRbYoyeoLM9Dt6D6hMn7tSjjh1fkg6qa/3 5C7Kk3DR3ZmolPlzP4T+pTLYFbbPciobGP2aaHPddQ35ssVHTWuNkEw+x M=; X-IronPort-AV: E=McAfee;i="5100,188,5444"; a="13415870" 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; 24 Nov 2008 16:20:48 -0800 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAP0KlOW022939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Nov 2008 16:20:47 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAP0Kf5M009105 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 24 Nov 2008 16:20:47 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.132]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Mon, 24 Nov 2008 16:20:42 -0800 From: "Giaretta, Gerardo" To: Romain KUNTZ , "mext@ietf.org" Date: Mon, 24 Nov 2008 16:20:39 -0800 Thread-Topic: [MEXT] Comments on draft-ietf-mext-flow-binding-00 Thread-Index: AclNwPF+Ww9Oz8LFRqacf5PZsk4Q7AAzvm+w Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D6CA06E9@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 MIME-Version: 1.0 Subject: Re: [MEXT] Comments on draft-ietf-mext-flow-binding-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Romain, Please find some comments inline (note that I am not an author so Hesham or= others may have a different opinion) > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of R= omain > KUNTZ > Sent: Sunday, November 23, 2008 3:12 PM > To: mext@ietf.org > Subject: [MEXT] Comments on draft-ietf-mext-flow-binding-00 > = > Hello, > = > Here are some comments on draft-ietf-mext-flow-binding-00. > On the protocol side, I don't see the motivation behind the "Refresh" > operation. The document says (section 4.7): > = > =A0=A0The refresh operation is included in this specification due to the > =A0=A0nature of the BU message. =A0The BU message updates existing bindin= gs > =A0=A0with new information. =A0Hence, all information previously sent in = the > =A0=A0last BU message need to be resent in all new messages, otherwise su= ch > =A0=A0information will be lost. > = > The flow bindings information are saved in the BCE, so as long as the BCE > exists, the flow bindings remain, and when the BCE is deleted, the flow > bindings are deleted. If I've read correctly, the draft never explicitly = says > that the flow bindings have to be deleted if they are not refreshed, and > instead says that the flow bindings are deleted only when the BCE is dele= ted. The point is that flow bindings do not have any lifetime information. The l= ifetime is bound to the main binding. This implies that if the binding expi= res, the flow bindings expire too (which makes sense). A refresh BU is not = different from any other BU so if you don't include any flow binding it wou= ld not be clear if the flow bindings are confirmed or not. I think this nee= ds a clarification. > So in the current state of the draft, refreshing seems useless. > = > Besides, note that refreshing can be a costly operation: Mobile Routers m= ay > have hundreds of rules, e.g. depending on the number of clients they serv= e. > = I see your concerns and I agree we should optimize this. = One way would be to add a new flag in the BU which indicates that flow bind= ings are also extended with the new lifetime. Note that BIDs also must alwa= ys be included in the BU as a BU without BID will overwrite all BIDs. = Another approach is to introduce the lifetime at the FID level but that is = not good in my opinion. = > = > Another concern is why another method to update a CoA is defined in this > document (section 6.2)? First, I don't really see the motivations behind = this, > and if I understood correctly how n-casting is specified in the BC, one (= HoA, > FID) pair may reference multiple entries, which makes the CoA update > impossible in case n-casting is used (see my other comment on that later). > = I don't fully understand your point here. Are you saying that a CoA change = should always be done as per the MCoA draft (i.e. via BID)? If this is the = intention, I agree - I don't see reasons why we should introduce the FIDs u= nless they need to be changed (e.g. added or removed). > = > * Some more detailed comments: > = > - Section 3.1, page 7, the Flow ID option shows a FID field of 16 bits bu= t it > is described as an "an 8-bit unsigned integer". > - Page 9, it is said "If this value is used, one or more Binding Reference > sub-options MUST exist.". Actually only a single Binding Reference sub-op= tion > is used but one or more BIDs must be indicated inside of it. > = I think both comments are correct > - Section 3.2: The BID sub-option is 16 bits in the MCoA draft while here= only > 8 bits are used to specify a BID. Better: the BID field in BID sub-option is 16 bits in the MCoA draft > - Some indication is needed on how this option (which can have a variable > length) should be aligned and padded using the MIPv6 padding options > = > - Section 4.2: "an entry is now identified by the pair (home address, FID= )". > This is true only when we want to update the flow bindings. To update a C= oA > (e.g. with a BU that only contains a BID option and no flow id options), = the > (HoA, BID) pair remains the key to lookup the BC/BUL. Note also that the = pair > (HoA, FID) can refer to multiple entries when n-casting is used. > = I think this is correct but also the text in the draft is correct. My under= standing is that the text in the draft deals with the processing of BUs whe= n they contain the FID option. If a BU only contains the BID option, the pr= ocessing of the MCoA draft applies. = > - Section 4.5: what happens if the flow id option has the PRO field set t= o 1 > (modify) and no flow description is present? Section 6.2 explains that it > should be considered as a CoA update, but IMHO this should rather be > considered as a request to modify the existing flow description in the BC= E to > a wild card request. > = More in general the draft should clarify how wild card request and default = bindings are supported. See my review a couple of days ago for details on w= hich are the issues in my view. > - Section 6.1.1: "The FID field includes a value that does not already ex= ist > in the mobile node's binding update list.": [...] for that HA or MAP > - "If the Binding Update sub-option includes only one BID," -> which sub- > option, the Binding Reference sub-option? > = > - Section 6.1.2: "the mobile node MUST NOT refresh or delete bindings > associated with any care-of address other than the one included in the BU > message." -> why? > = > - Section 6.2: the "MODIFY" code is used but is never defined. It would be > good to define the ADD/MODIFY/DELETE terms in section 3.1 and to use them > through the document. > = > - Section 6.3 states that n-casting is possible with the CN with some > conditions, but section 7.1 simply forbids n-casting ("If the Action field > indicates a request to n-cast the flow, the correspondent node MUST rejec= t the > option [...]") > = > - Section 7.1: some notes on how the the flow binding is added to the bin= ding > cache should be written (existence of a BID sub-option in the BU, lookup = in > the BCE with that BID, ...). Same comment for section 8.1 > - This section and section 8.1 do not say what to do when a request to de= lete > a flow is received. > = > - Section 8.1: "the home agent MUST check for the presence of the BID sub- > option(s)." -> actually section 3.2 does not mandate the presence of the = BID > sub-options if the BID already exists in the BCE ("A BID sub-option is not > necessarily included in the same BU [...]"). If the BID does not exist ye= t in > the BCE or if no BID sub-options are present, then this is an error case. > - "If one or more BIDs are present in the BID Reference sub-option" -> Bi= nding > Reference sub-option > - The following procedure is too complex IMHO: > = > =A0=A0=A0=A0=A0If only one BID were > =A0=A0=A0=A0=A0included in the Binding Reference sub-option and it pointe= d to a > =A0=A0=A0=A0=A0different care-of address from the one included in the pac= ket, > =A0=A0=A0=A0=A0then packets matching the flow would be bicast to those two > =A0=A0=A0=A0=A0addresses. > = > Especially because the BU may be sent using another source address than t= he > one expected for n-casting. Why not just forbid this case and explicitly = ask > for at least 2 BIDs in the binding reference sub-option? > = Agree on this as I mentioned in my review of the draft Gerardo > - I think it was already raised, but the document lacks some text on what > status code should be used upon error (section 7.1, 8.1, ...) and how such > error code should be treated on the receiver side. > = > - Section 8.2: this section make me think that the section talking about = the > MN side does not say what should be done when the BAck is not received > = > - Section 10: "associate some flows to an interface and other flows to an= other > interface": I would replace "interface" with "CoA" > = > = > * Some editorial comments: > = > The document is inconsistent on how "Binding Update" / "Binding > Acknowledgement" / "Flow Identification" / "Flow Binding" / "Flow Descrip= tion" > / "N-cast" are written (the first letter is sometimes lower case, sometim= es > upper case) > = > Page 11: dsecription -> description > Page 15: Acknwoledgement -> Acknowledgement Page 22: Correspondant -> > Correspondent Page 23: authrozied -> authorized > = > = > = > Cheers, > -- > Romain KUNTZ > kuntz@lsiit.u-strasbg.fr > LSIIT - Networks and Protocols Team > http://clarinet.u-strasbg.fr/~kuntz/ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 24 19:25:58 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDE673A67FB; Mon, 24 Nov 2008 19:25:58 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3D943A67FB for ; Mon, 24 Nov 2008 19:25:57 -0800 (PST) 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=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 oI82G8IjkoE4 for ; Mon, 24 Nov 2008 19:25:56 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id D22113A67E3 for ; Mon, 24 Nov 2008 19:25:55 -0800 (PST) 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 mAP3PqC5027119; Tue, 25 Nov 2008 12:25:52 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb2) with ESMTP id mAP3Pq614042; Tue, 25 Nov 2008 12:25:52 +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 mAP3PrJ03981; Tue, 25 Nov 2008 12:25:53 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 11:25:41 +0800 Message-ID: <492B7034.9020303@sg.panasonic.com> Date: Tue, 25 Nov 2008 11:25:40 +0800 From: Benjamin Lim User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Giaretta, Gerardo" References: <057632CE4CE10D45A1A3D6D19206C3A3D6CA06E9@NASANEXMB08.na.qualcomm.com> In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D6CA06E9@NASANEXMB08.na.qualcomm.com> X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 25 Nov 2008 03:25:41.0627 (UTC) FILETIME=[7E8D54B0:01C94EAD] 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 List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi all, Pls see inline for my comment. Giaretta, Gerardo wrote: > Hi Romain, > > Please find some comments inline (note that I am not an author so Hesham or others may have a different opinion) > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Romain >> KUNTZ >> Sent: Sunday, November 23, 2008 3:12 PM >> To: mext@ietf.org >> Subject: [MEXT] Comments on draft-ietf-mext-flow-binding-00 >> >> Hello, >> >> Here are some comments on draft-ietf-mext-flow-binding-00. >> On the protocol side, I don't see the motivation behind the "Refresh" >> operation. The document says (section 4.7): >> >> The refresh operation is included in this specification due to the >> nature of the BU message. The BU message updates existing bindings >> with new information. Hence, all information previously sent in the >> last BU message need to be resent in all new messages, otherwise such >> information will be lost. >> >> The flow bindings information are saved in the BCE, so as long as the BCE >> exists, the flow bindings remain, and when the BCE is deleted, the flow >> bindings are deleted. If I've read correctly, the draft never explicitly says >> that the flow bindings have to be deleted if they are not refreshed, and >> instead says that the flow bindings are deleted only when the BCE is deleted. > > The point is that flow bindings do not have any lifetime information. The > lifetime is bound to the main binding. This implies that if the binding > expires, the flow bindings expire too (which makes sense). A refresh BU is not > different from any other BU so if you don't include any flow binding it would > not be clear if the flow bindings are confirmed or not. I think this needs a > clarification. [Ben] In section 6.2 last paragraph, for optimization, you can send the BU with BID and without FID. Although this section is for change in CoA, can the same logic apply to a BU sent to extend the lifetime of a current CoA? If the MN wants to modify the flow binding (i.e. switch it to another entry in BCE), it sets PRO field to 'replace'. If MN wants to remove flow binding, it sets PRO field to 'remove'. If MN does not indicate anything, the flow binding stays with the current BCE. If my above understanding is correct, then I do not see the need for the refresh operation. Is my understanding correct? Regards, Benjamin Lim > >> So in the current state of the draft, refreshing seems useless. >> >> Besides, note that refreshing can be a costly operation: Mobile Routers may >> have hundreds of rules, e.g. depending on the number of clients they serve. >> > > I see your concerns and I agree we should optimize this. > > One way would be to add a new flag in the BU which indicates that flow bindings > are also extended with the new lifetime. Note that BIDs also must always be > included in the BU as a BU without BID will overwrite all BIDs. > > Another approach is to introduce the lifetime at the FID level but that is not > good in my opinion. > >> Another concern is why another method to update a CoA is defined in this >> document (section 6.2)? First, I don't really see the motivations behind this, >> and if I understood correctly how n-casting is specified in the BC, one (HoA, >> FID) pair may reference multiple entries, which makes the CoA update >> impossible in case n-casting is used (see my other comment on that later). >> > > I don't fully understand your point here. Are you saying that a CoA change should always be done as per the MCoA draft (i.e. via BID)? If this is the intention, I agree - I don't see reasons why we should introduce the FIDs unless they need to be changed (e.g. added or removed). > >> * Some more detailed comments: >> >> - Section 3.1, page 7, the Flow ID option shows a FID field of 16 bits but it >> is described as an "an 8-bit unsigned integer". >> - Page 9, it is said "If this value is used, one or more Binding Reference >> sub-options MUST exist.". Actually only a single Binding Reference sub-option >> is used but one or more BIDs must be indicated inside of it. >> > > I think both comments are correct > >> - Section 3.2: The BID sub-option is 16 bits in the MCoA draft while here only >> 8 bits are used to specify a BID. > > Better: the BID field in BID sub-option is 16 bits in the MCoA draft > >> - Some indication is needed on how this option (which can have a variable >> length) should be aligned and padded using the MIPv6 padding options >> >> - Section 4.2: "an entry is now identified by the pair (home address, FID)". >> This is true only when we want to update the flow bindings. To update a CoA >> (e.g. with a BU that only contains a BID option and no flow id options), the >> (HoA, BID) pair remains the key to lookup the BC/BUL. Note also that the pair >> (HoA, FID) can refer to multiple entries when n-casting is used. >> > > I think this is correct but also the text in the draft is correct. My understanding is that the text in the draft deals with the processing of BUs when they contain the FID option. If a BU only contains the BID option, the processing of the MCoA draft applies. > >> - Section 4.5: what happens if the flow id option has the PRO field set to 1 >> (modify) and no flow description is present? Section 6.2 explains that it >> should be considered as a CoA update, but IMHO this should rather be >> considered as a request to modify the existing flow description in the BCE to >> a wild card request. >> > > More in general the draft should clarify how wild card request and default bindings are supported. See my review a couple of days ago for details on which are the issues in my view. > >> - Section 6.1.1: "The FID field includes a value that does not already exist >> in the mobile node's binding update list.": [...] for that HA or MAP >> - "If the Binding Update sub-option includes only one BID," -> which sub- >> option, the Binding Reference sub-option? >> >> - Section 6.1.2: "the mobile node MUST NOT refresh or delete bindings >> associated with any care-of address other than the one included in the BU >> message." -> why? >> >> - Section 6.2: the "MODIFY" code is used but is never defined. It would be >> good to define the ADD/MODIFY/DELETE terms in section 3.1 and to use them >> through the document. >> >> - Section 6.3 states that n-casting is possible with the CN with some >> conditions, but section 7.1 simply forbids n-casting ("If the Action field >> indicates a request to n-cast the flow, the correspondent node MUST reject the >> option [...]") >> >> - Section 7.1: some notes on how the the flow binding is added to the binding >> cache should be written (existence of a BID sub-option in the BU, lookup in >> the BCE with that BID, ...). Same comment for section 8.1 >> - This section and section 8.1 do not say what to do when a request to delete >> a flow is received. >> >> - Section 8.1: "the home agent MUST check for the presence of the BID sub- >> option(s)." -> actually section 3.2 does not mandate the presence of the BID >> sub-options if the BID already exists in the BCE ("A BID sub-option is not >> necessarily included in the same BU [...]"). If the BID does not exist yet in >> the BCE or if no BID sub-options are present, then this is an error case. >> - "If one or more BIDs are present in the BID Reference sub-option" -> Binding >> Reference sub-option >> - The following procedure is too complex IMHO: >> >> If only one BID were >> included in the Binding Reference sub-option and it pointed to a >> different care-of address from the one included in the packet, >> then packets matching the flow would be bicast to those two >> addresses. >> >> Especially because the BU may be sent using another source address than the >> one expected for n-casting. Why not just forbid this case and explicitly ask >> for at least 2 BIDs in the binding reference sub-option? >> > > Agree on this as I mentioned in my review of the draft > > Gerardo > >> - I think it was already raised, but the document lacks some text on what >> status code should be used upon error (section 7.1, 8.1, ...) and how such >> error code should be treated on the receiver side. >> >> - Section 8.2: this section make me think that the section talking about the >> MN side does not say what should be done when the BAck is not received >> >> - Section 10: "associate some flows to an interface and other flows to another >> interface": I would replace "interface" with "CoA" >> >> >> * Some editorial comments: >> >> The document is inconsistent on how "Binding Update" / "Binding >> Acknowledgement" / "Flow Identification" / "Flow Binding" / "Flow Description" >> / "N-cast" are written (the first letter is sometimes lower case, sometimes >> upper case) >> >> Page 11: dsecription -> description >> Page 15: Acknwoledgement -> Acknowledgement Page 22: Correspondant -> >> Correspondent Page 23: authrozied -> authorized >> >> >> >> Cheers, >> -- >> Romain KUNTZ >> kuntz@lsiit.u-strasbg.fr >> LSIIT - Networks and Protocols Team >> http://clarinet.u-strasbg.fr/~kuntz/ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Nov 24 21:37:24 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4990E3A6A7F; Mon, 24 Nov 2008 21:37:24 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD8623A6A7F for ; Mon, 24 Nov 2008 21:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdENVZM03QHY for ; Mon, 24 Nov 2008 21:37:21 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 935BF3A6A57 for ; Mon, 24 Nov 2008 21:37:19 -0800 (PST) Received: from [74.2.154.202] (helo=[192.168.5.222]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1L4qbh-0005pL-Fl; Tue, 25 Nov 2008 16:37:07 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Tue, 25 Nov 2008 16:36:53 +1100 From: Hesham Soliman To: Benjamin Lim , "Giaretta, Gerardo" Message-ID: Thread-Topic: [MEXT] Comments on draft-ietf-mext-flow-binding-00 Thread-Index: AclOv9JB9wi2u1Q/qkGmNuSo03NZNg== In-Reply-To: <492B7034.9020303@sg.panasonic.com> Mime-version: 1.0 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 List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org One comment below: >>> Here are some comments on draft-ietf-mext-flow-binding-00. >>> On the protocol side, I don't see the motivation behind the "Refresh" >>> operation. The document says (section 4.7): >>> >>> The refresh operation is included in this specification due to the >>> nature of the BU message. The BU message updates existing bindings >>> with new information. Hence, all information previously sent in the >>> last BU message need to be resent in all new messages, otherwise such >>> information will be lost. >>> >>> The flow bindings information are saved in the BCE, so as long as the BCE >>> exists, the flow bindings remain, and when the BCE is deleted, the flow >>> bindings are deleted. If I've read correctly, the draft never explicitly >>> says >>> that the flow bindings have to be deleted if they are not refreshed, and >>> instead says that the flow bindings are deleted only when the BCE is >>> deleted. >> >> The point is that flow bindings do not have any lifetime information. The >> lifetime is bound to the main binding. This implies that if the binding >> expires, the flow bindings expire too (which makes sense). A refresh BU is >> not >> different from any other BU so if you don't include any flow binding it would >> not be clear if the flow bindings are confirmed or not. I think this needs a >> clarification. > [Ben] In section 6.2 last paragraph, for optimization, you can send the > BU with BID and without FID. Although this section is for change in > CoA, can the same logic apply to a BU sent to extend the lifetime of a > current CoA? > > If the MN wants to modify the flow binding (i.e. switch it to another > entry in BCE), it sets PRO field to 'replace'. If MN wants to remove > flow binding, it sets PRO field to 'remove'. If MN does not indicate > anything, the flow binding stays with the current BCE. > > If my above understanding is correct, then I do not see the need for the > refresh operation. > > Is my understanding correct? => I'll try to answer all of the above by simply stating the following: The way MIPv6 works is that one BU replaces another, there is no state differentials that are carried across between the old and new BCEs in an implicit manner. What this means is that if you want to refresh a state, you include that state in the BU. If we do the above, then we're simply removing the "big BU" to the remove operation. If a MN wants to remove all FIDs, it can simply send a BU with none of the FIDs included. Hence, removing all data is very efficient. If we make the assumption that refreshing all is more common that removing all (fair assumption I think) then we can try to optimise for that. Hesham > > Regards, > Benjamin Lim > >> >>> So in the current state of the draft, refreshing seems useless. >>> >>> Besides, note that refreshing can be a costly operation: Mobile Routers may >>> have hundreds of rules, e.g. depending on the number of clients they serve. >>> >> >> I see your concerns and I agree we should optimize this. >> >> One way would be to add a new flag in the BU which indicates that flow >> bindings >> are also extended with the new lifetime. Note that BIDs also must always be >> included in the BU as a BU without BID will overwrite all BIDs. >> >> Another approach is to introduce the lifetime at the FID level but that is >> not >> good in my opinion. >> >>> Another concern is why another method to update a CoA is defined in this >>> document (section 6.2)? First, I don't really see the motivations behind >>> this, >>> and if I understood correctly how n-casting is specified in the BC, one >>> (HoA, >>> FID) pair may reference multiple entries, which makes the CoA update >>> impossible in case n-casting is used (see my other comment on that later). >>> >> >> I don't fully understand your point here. Are you saying that a CoA change >> should always be done as per the MCoA draft (i.e. via BID)? If this is the >> intention, I agree - I don't see reasons why we should introduce the FIDs >> unless they need to be changed (e.g. added or removed). >> >>> * Some more detailed comments: >>> >>> - Section 3.1, page 7, the Flow ID option shows a FID field of 16 bits but >>> it >>> is described as an "an 8-bit unsigned integer". >>> - Page 9, it is said "If this value is used, one or more Binding Reference >>> sub-options MUST exist.". Actually only a single Binding Reference >>> sub-option >>> is used but one or more BIDs must be indicated inside of it. >>> >> >> I think both comments are correct >> >>> - Section 3.2: The BID sub-option is 16 bits in the MCoA draft while here >>> only >>> 8 bits are used to specify a BID. >> >> Better: the BID field in BID sub-option is 16 bits in the MCoA draft >> >>> - Some indication is needed on how this option (which can have a variable >>> length) should be aligned and padded using the MIPv6 padding options >>> >>> - Section 4.2: "an entry is now identified by the pair (home address, FID)". >>> This is true only when we want to update the flow bindings. To update a CoA >>> (e.g. with a BU that only contains a BID option and no flow id options), the >>> (HoA, BID) pair remains the key to lookup the BC/BUL. Note also that the >>> pair >>> (HoA, FID) can refer to multiple entries when n-casting is used. >>> >> >> I think this is correct but also the text in the draft is correct. My >> understanding is that the text in the draft deals with the processing of BUs >> when they contain the FID option. If a BU only contains the BID option, the >> processing of the MCoA draft applies. >> >>> - Section 4.5: what happens if the flow id option has the PRO field set to 1 >>> (modify) and no flow description is present? Section 6.2 explains that it >>> should be considered as a CoA update, but IMHO this should rather be >>> considered as a request to modify the existing flow description in the BCE >>> to >>> a wild card request. >>> >> >> More in general the draft should clarify how wild card request and default >> bindings are supported. See my review a couple of days ago for details on >> which are the issues in my view. >> >>> - Section 6.1.1: "The FID field includes a value that does not already exist >>> in the mobile node's binding update list.": [...] for that HA or MAP >>> - "If the Binding Update sub-option includes only one BID," -> which sub- >>> option, the Binding Reference sub-option? >>> >>> - Section 6.1.2: "the mobile node MUST NOT refresh or delete bindings >>> associated with any care-of address other than the one included in the BU >>> message." -> why? >>> >>> - Section 6.2: the "MODIFY" code is used but is never defined. It would be >>> good to define the ADD/MODIFY/DELETE terms in section 3.1 and to use them >>> through the document. >>> >>> - Section 6.3 states that n-casting is possible with the CN with some >>> conditions, but section 7.1 simply forbids n-casting ("If the Action field >>> indicates a request to n-cast the flow, the correspondent node MUST reject >>> the >>> option [...]") >>> >>> - Section 7.1: some notes on how the the flow binding is added to the >>> binding >>> cache should be written (existence of a BID sub-option in the BU, lookup in >>> the BCE with that BID, ...). Same comment for section 8.1 >>> - This section and section 8.1 do not say what to do when a request to >>> delete >>> a flow is received. >>> >>> - Section 8.1: "the home agent MUST check for the presence of the BID sub- >>> option(s)." -> actually section 3.2 does not mandate the presence of the BID >>> sub-options if the BID already exists in the BCE ("A BID sub-option is not >>> necessarily included in the same BU [...]"). If the BID does not exist yet >>> in >>> the BCE or if no BID sub-options are present, then this is an error case. >>> - "If one or more BIDs are present in the BID Reference sub-option" -> >>> Binding >>> Reference sub-option >>> - The following procedure is too complex IMHO: >>> >>> If only one BID were >>> included in the Binding Reference sub-option and it pointed to a >>> different care-of address from the one included in the packet, >>> then packets matching the flow would be bicast to those two >>> addresses. >>> >>> Especially because the BU may be sent using another source address than the >>> one expected for n-casting. Why not just forbid this case and explicitly ask >>> for at least 2 BIDs in the binding reference sub-option? >>> >> >> Agree on this as I mentioned in my review of the draft >> >> Gerardo >> >>> - I think it was already raised, but the document lacks some text on what >>> status code should be used upon error (section 7.1, 8.1, ...) and how such >>> error code should be treated on the receiver side. >>> >>> - Section 8.2: this section make me think that the section talking about the >>> MN side does not say what should be done when the BAck is not received >>> >>> - Section 10: "associate some flows to an interface and other flows to >>> another >>> interface": I would replace "interface" with "CoA" >>> >>> >>> * Some editorial comments: >>> >>> The document is inconsistent on how "Binding Update" / "Binding >>> Acknowledgement" / "Flow Identification" / "Flow Binding" / "Flow >>> Description" >>> / "N-cast" are written (the first letter is sometimes lower case, sometimes >>> upper case) >>> >>> Page 11: dsecription -> description >>> Page 15: Acknwoledgement -> Acknowledgement Page 22: Correspondant -> >>> Correspondent Page 23: authrozied -> authorized >>> >>> >>> >>> Cheers, >>> -- >>> Romain KUNTZ >>> kuntz@lsiit.u-strasbg.fr >>> LSIIT - Networks and Protocols Team >>> http://clarinet.u-strasbg.fr/~kuntz/ >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 25 03:37:24 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4835E28B56A; Tue, 25 Nov 2008 03:37:24 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2893A3A6A37 for ; Tue, 25 Nov 2008 03:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 yhLb2nWBJrC2 for ; Tue, 25 Nov 2008 03:37:22 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 5B80B3A67F5 for ; Tue, 25 Nov 2008 03:37:22 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 47EC8198715; Tue, 25 Nov 2008 13:37:19 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 114DA198646; Tue, 25 Nov 2008 13:37:19 +0200 (EET) Message-ID: <492BE35F.2040701@piuha.net> Date: Tue, 25 Nov 2008 13:37:03 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: draft-ietf-mext-nemo-mib@tools.ietf.org, "mext@ietf.org" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [MEXT] Re-AD review comments on the nemo mib document X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org So, due to the large changes in the new version, this is going back to a WGLC and is also going to require a few more reviews. In the meantime I have re-reviewed the new version and I have the following comments: Please remove the commented out parts of the MIB (e.g., "-- Counter64"). The object NemoBURequestRejectionCode says "The value of the status field in the BA ..." but lists values that are in the 1-4 range as opposed to the actual values in BAs. Please clarify which ones you actually want to use. The object nemoHaBindingAcksOtherError seems to have a similar problem. Otherwise the new document looks good. I do expect some additional reviews, however. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 25 03:54:56 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7C128C0DE; Tue, 25 Nov 2008 03:54:56 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21253A6A37 for ; Tue, 25 Nov 2008 03:54:55 -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 KpGO+xmsGd+R for ; Tue, 25 Nov 2008 03:54:54 -0800 (PST) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.180]) by core3.amsl.com (Postfix) with ESMTP id F0E873A67F5 for ; Tue, 25 Nov 2008 03:54:53 -0800 (PST) Received: by ik-out-1112.google.com with SMTP id c29so2021742ika.5 for ; Tue, 25 Nov 2008 03:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=vLyA2yS05NSjGLS6tTDOC4+NGm2e/W9LLgJoT21Iv9E=; b=BvV1zyv6bWLdGSbkW1i/P9RLaXnppXsbhZwZAdTMJdTyz00nmATX6m7eR3uWj701tH 11B9ZqYri8bzia83qgZlqX84yHB9I0/QyLDT0EuFckCxiPrFbukZwibZIjekJj9FFgYM NciypJjehTOQXY+fbrDSILvEeyIZZ0tjTcvBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:cc:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id:from; b=g82tFp5qHTHtn+2V8ndx43CD4vm0qtJxO8ORrHQVVhyFGINTYfGVoyuBOwJCtzUlfk hZt8azeT8WmiPCFCHtUybtSZ3m1GOQoN7JrMXvpOcEtoa/k05fozB7w6/ZHG0jU7I3sX XONXrhEYUu2nJEL/RFuyVqViGV2Nk/r8xAzxI= Received: by 10.210.121.8 with SMTP id t8mr4641211ebc.180.1227614090274; Tue, 25 Nov 2008 03:54:50 -0800 (PST) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id 34sm2682278nfu.24.2008.11.25.03.54.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 25 Nov 2008 03:54:49 -0800 (PST) To: netlmm@ietf.org Date: Tue, 25 Nov 2008 12:54:46 +0100 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200811251254.47129.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: mext@ietf.org Subject: Re: [MEXT] [netlmm] question on the DHCP-PD X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Fan, On Friday 21 November 2008, fan zhao wrote: > Hi, > > Below is the question regarding the DHCP based prefix delegation I > had on the today's mext meeting. > I also cc to the netlmm mailing list. > > My question is when the MN connects to a source access network using > PMIP (or other type of network > based mobility protocol), it obtains a home network prefix. Then the > MN handovers to a target access > network (i.e. the foreign link for the MN) using the Mobile IPv6. The > handover procedure is as follows. > > 1) The MN obtains a care-of address from the target access network. > 2) The MN discovers the home agent if it does not know. > 3) The MN sets up the IPsec SA with the HA if it does not have the SA > with the HA before. > 4) During the step 3), the MN requests the HNP allocated from the HA > based on RFC 4877/5026. > 5) The MN realizes it is on the foreign link, then it needs to send > the BU to the HA. > Since the Mobile IPv6 BU can only register the binding between the > CoA and one single home address, > in order to register the binding between the HNP and the CoA, the MN > needs to use > the NEMO extensions, for example, by setting up the 'R' bit and using > the implicit mode. There's no need to involve NEMO. You are confusing the notion of Home Network Prefix with that of a NEMO Mobile Network Prefix: The Home Network Prefix is a prefix advertized on the Home Link (by the HA or a router in MIPv6 case, or a MAG in PMIPv6 case), while a NEMO Mobile Network Prefix is a prefix delegated to a Mobile Router and advertised in the Mobile Network. These are different cases. As to your scenario above, the MN will simply register with the HA any of the Home Addresses it configured out of the PMIPv6 Home Network Prefix that was avertized to him. All of these registrations will contain the Care-of Address that the MN configured on the foreign link. I do not see any issues. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 25 08:41:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649F128C1A3; Tue, 25 Nov 2008 08:41:15 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E24D28C192 for ; Tue, 25 Nov 2008 08:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16Z59NJYLqli for ; Tue, 25 Nov 2008 08:41:13 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id D381B28C181 for ; Tue, 25 Nov 2008 08:41:12 -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=1227631270; x=1259167270; 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=20Benjamin=20Lim=0D=0A=09|CC:=20"mext@ietf.org"=20|Date:=20Tue,=2025=20Nov=202008=2008:41:03=20-08 00|Subject:=20RE:=20[MEXT]=20Comments=20on=20draft-ietf-m ext-flow-binding-00|Thread-Topic:=20[MEXT]=20Comments=20o n=20draft-ietf-mext-flow-binding-00|Thread-Index:=20AclOv 9JB9wi2u1Q/qkGmNuSo03NZNgAW1CIw|Message-ID:=20<057632CE4C E10D45A1A3D6D19206C3A3D6CA073E@NASANEXMB08.na.qualcomm.co m>|References:=20<492B7034.9020303@sg.panasonic.com>=0D =0A=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 100,188,5444"=3B=20a=3D"13439998"; bh=2C0UR69p/fPHo3I/QPZbJkhdXKuL/nVwK7Nn8MbXP4U=; b=S99xXjeA38sJXHR8S90OhfnXRs5b5M/Q0fqvvVNDUk/Ko0Zfdb648L81 OSUgCHIkmf6uU3nw7NTtk7/YfcbygOfBQ+7hNLZj4MaWoWeISmqni3uT/ I8DsqfieL/oblaFiob2Z7u396s950HO2XJlMXmQxt5/OPJ60zlVBvMUpB 4=; X-IronPort-AV: E=McAfee;i="5100,188,5444"; a="13439998" 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; 25 Nov 2008 08:41:10 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAPGfA6u016504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Nov 2008 08:41:10 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAPGf5ma002106 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Nov 2008 08:41:09 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.132]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Tue, 25 Nov 2008 08:41:04 -0800 From: "Giaretta, Gerardo" To: Hesham Soliman , Benjamin Lim Date: Tue, 25 Nov 2008 08:41:03 -0800 Thread-Topic: [MEXT] Comments on draft-ietf-mext-flow-binding-00 Thread-Index: AclOv9JB9wi2u1Q/qkGmNuSo03NZNgAW1CIw Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D6CA073E@NASANEXMB08.na.qualcomm.com> References: <492B7034.9020303@sg.panasonic.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 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 List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Monday, November 24, 2008 9:37 PM > To: Benjamin Lim; Giaretta, Gerardo > Cc: mext@ietf.org > Subject: Re: [MEXT] Comments on draft-ietf-mext-flow-binding-00 > > One comment below: > > >>> Here are some comments on draft-ietf-mext-flow-binding-00. > >>> On the protocol side, I don't see the motivation behind the "Refresh" > >>> operation. The document says (section 4.7): > >>> > >>> The refresh operation is included in this specification due to the > >>> nature of the BU message. The BU message updates existing bindings > >>> with new information. Hence, all information previously sent in the > >>> last BU message need to be resent in all new messages, otherwise such > >>> information will be lost. > >>> > >>> The flow bindings information are saved in the BCE, so as long as the BCE > >>> exists, the flow bindings remain, and when the BCE is deleted, the flow > >>> bindings are deleted. If I've read correctly, the draft never explicitly > >>> says > >>> that the flow bindings have to be deleted if they are not refreshed, and > >>> instead says that the flow bindings are deleted only when the BCE is > >>> deleted. > >> > >> The point is that flow bindings do not have any lifetime information. The > >> lifetime is bound to the main binding. This implies that if the binding > >> expires, the flow bindings expire too (which makes sense). A refresh BU is > >> not > >> different from any other BU so if you don't include any flow binding it > would > >> not be clear if the flow bindings are confirmed or not. I think this needs > a > >> clarification. > > [Ben] In section 6.2 last paragraph, for optimization, you can send the > > BU with BID and without FID. Although this section is for change in > > CoA, can the same logic apply to a BU sent to extend the lifetime of a > > current CoA? > > > > If the MN wants to modify the flow binding (i.e. switch it to another > > entry in BCE), it sets PRO field to 'replace'. If MN wants to remove > > flow binding, it sets PRO field to 'remove'. If MN does not indicate > > anything, the flow binding stays with the current BCE. > > > > If my above understanding is correct, then I do not see the need for the > > refresh operation. > > > > Is my understanding correct? > > => I'll try to answer all of the above by simply stating the following: > The way MIPv6 works is that one BU replaces another, there is no state > differentials that are carried across between the old and new BCEs in an > implicit manner. > What this means is that if you want to refresh a state, you include that > state in the BU. > If we do the above, then we're simply removing the "big BU" to the remove > operation. If a MN wants to remove all FIDs, it can simply send a BU with > none of the FIDs included. Hence, removing all data is very efficient. > > If we make the assumption that refreshing all is more common that removing > all (fair assumption I think) then we can try to optimise for that. > I think it is a fair assumption. I think the following should be the principles to implement: - add, replace, remove flow bindings require 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 specific BID are not changed in this case. - The lifetime of the flow binding is tied to the lifetime of the CoA binding. This implies 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 option overwrites all bindings including the flow binding The latter is used for example when the MN wants to go through MCoA mode to single CoA mode. Does it make sense? Gerardo > Hesham > > > > > > Regards, > > Benjamin Lim > > > >> > >>> So in the current state of the draft, refreshing seems useless. > >>> > >>> Besides, note that refreshing can be a costly operation: Mobile Routers > may > >>> have hundreds of rules, e.g. depending on the number of clients they > serve. > >>> > >> > >> I see your concerns and I agree we should optimize this. > >> > >> One way would be to add a new flag in the BU which indicates that flow > >> bindings > >> are also extended with the new lifetime. Note that BIDs also must always be > >> included in the BU as a BU without BID will overwrite all BIDs. > >> > >> Another approach is to introduce the lifetime at the FID level but that is > >> not > >> good in my opinion. > >> > >>> Another concern is why another method to update a CoA is defined in this > >>> document (section 6.2)? First, I don't really see the motivations behind > >>> this, > >>> and if I understood correctly how n-casting is specified in the BC, one > >>> (HoA, > >>> FID) pair may reference multiple entries, which makes the CoA update > >>> impossible in case n-casting is used (see my other comment on that later). > >>> > >> > >> I don't fully understand your point here. Are you saying that a CoA change > >> should always be done as per the MCoA draft (i.e. via BID)? If this is the > >> intention, I agree - I don't see reasons why we should introduce the FIDs > >> unless they need to be changed (e.g. added or removed). > >> > >>> * Some more detailed comments: > >>> > >>> - Section 3.1, page 7, the Flow ID option shows a FID field of 16 bits but > >>> it > >>> is described as an "an 8-bit unsigned integer". > >>> - Page 9, it is said "If this value is used, one or more Binding Reference > >>> sub-options MUST exist.". Actually only a single Binding Reference > >>> sub-option > >>> is used but one or more BIDs must be indicated inside of it. > >>> > >> > >> I think both comments are correct > >> > >>> - Section 3.2: The BID sub-option is 16 bits in the MCoA draft while here > >>> only > >>> 8 bits are used to specify a BID. > >> > >> Better: the BID field in BID sub-option is 16 bits in the MCoA draft > >> > >>> - Some indication is needed on how this option (which can have a variable > >>> length) should be aligned and padded using the MIPv6 padding options > >>> > >>> - Section 4.2: "an entry is now identified by the pair (home address, > FID)". > >>> This is true only when we want to update the flow bindings. To update a > CoA > >>> (e.g. with a BU that only contains a BID option and no flow id options), > the > >>> (HoA, BID) pair remains the key to lookup the BC/BUL. Note also that the > >>> pair > >>> (HoA, FID) can refer to multiple entries when n-casting is used. > >>> > >> > >> I think this is correct but also the text in the draft is correct. My > >> understanding is that the text in the draft deals with the processing of > BUs > >> when they contain the FID option. If a BU only contains the BID option, the > >> processing of the MCoA draft applies. > >> > >>> - Section 4.5: what happens if the flow id option has the PRO field set to > 1 > >>> (modify) and no flow description is present? Section 6.2 explains that it > >>> should be considered as a CoA update, but IMHO this should rather be > >>> considered as a request to modify the existing flow description in the BCE > >>> to > >>> a wild card request. > >>> > >> > >> More in general the draft should clarify how wild card request and default > >> bindings are supported. See my review a couple of days ago for details on > >> which are the issues in my view. > >> > >>> - Section 6.1.1: "The FID field includes a value that does not already > exist > >>> in the mobile node's binding update list.": [...] for that HA or MAP > >>> - "If the Binding Update sub-option includes only one BID," -> which sub- > >>> option, the Binding Reference sub-option? > >>> > >>> - Section 6.1.2: "the mobile node MUST NOT refresh or delete bindings > >>> associated with any care-of address other than the one included in the BU > >>> message." -> why? > >>> > >>> - Section 6.2: the "MODIFY" code is used but is never defined. It would be > >>> good to define the ADD/MODIFY/DELETE terms in section 3.1 and to use them > >>> through the document. > >>> > >>> - Section 6.3 states that n-casting is possible with the CN with some > >>> conditions, but section 7.1 simply forbids n-casting ("If the Action field > >>> indicates a request to n-cast the flow, the correspondent node MUST reject > >>> the > >>> option [...]") > >>> > >>> - Section 7.1: some notes on how the the flow binding is added to the > >>> binding > >>> cache should be written (existence of a BID sub-option in the BU, lookup > in > >>> the BCE with that BID, ...). Same comment for section 8.1 > >>> - This section and section 8.1 do not say what to do when a request to > >>> delete > >>> a flow is received. > >>> > >>> - Section 8.1: "the home agent MUST check for the presence of the BID sub- > >>> option(s)." -> actually section 3.2 does not mandate the presence of the > BID > >>> sub-options if the BID already exists in the BCE ("A BID sub-option is not > >>> necessarily included in the same BU [...]"). If the BID does not exist yet > >>> in > >>> the BCE or if no BID sub-options are present, then this is an error case. > >>> - "If one or more BIDs are present in the BID Reference sub-option" -> > >>> Binding > >>> Reference sub-option > >>> - The following procedure is too complex IMHO: > >>> > >>> If only one BID were > >>> included in the Binding Reference sub-option and it pointed to a > >>> different care-of address from the one included in the packet, > >>> then packets matching the flow would be bicast to those two > >>> addresses. > >>> > >>> Especially because the BU may be sent using another source address than > the > >>> one expected for n-casting. Why not just forbid this case and explicitly > ask > >>> for at least 2 BIDs in the binding reference sub-option? > >>> > >> > >> Agree on this as I mentioned in my review of the draft > >> > >> Gerardo > >> > >>> - I think it was already raised, but the document lacks some text on what > >>> status code should be used upon error (section 7.1, 8.1, ...) and how such > >>> error code should be treated on the receiver side. > >>> > >>> - Section 8.2: this section make me think that the section talking about > the > >>> MN side does not say what should be done when the BAck is not received > >>> > >>> - Section 10: "associate some flows to an interface and other flows to > >>> another > >>> interface": I would replace "interface" with "CoA" > >>> > >>> > >>> * Some editorial comments: > >>> > >>> The document is inconsistent on how "Binding Update" / "Binding > >>> Acknowledgement" / "Flow Identification" / "Flow Binding" / "Flow > >>> Description" > >>> / "N-cast" are written (the first letter is sometimes lower case, > sometimes > >>> upper case) > >>> > >>> Page 11: dsecription -> description > >>> Page 15: Acknwoledgement -> Acknowledgement Page 22: Correspondant -> > >>> Correspondent Page 23: authrozied -> authorized > >>> > >>> > >>> > >>> Cheers, > >>> -- > >>> Romain KUNTZ > >>> kuntz@lsiit.u-strasbg.fr > >>> LSIIT - Networks and Protocols Team > >>> http://clarinet.u-strasbg.fr/~kuntz/ > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > >> > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Nov 25 11:45:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD3328C0E4; Tue, 25 Nov 2008 11:45:02 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E5B713A6A9F; Tue, 25 Nov 2008 11:45: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: <20081125194501.E5B713A6A9F@core3.amsl.com> Date: Tue, 25 Nov 2008 11:45:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-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: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility 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-02.txt Pages : 34 Date : 2008-11-25 This document defines the revocation semantics for terminating a mobile node's mobility session and associated resources. These semantics are generic enough and can be used by mobility entities in the case of Client 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-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-binding-revocation-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-25113837.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Tue Nov 25 12:04:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ED7F28C1B7; Tue, 25 Nov 2008 12:04:38 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAD023A6C3E for ; Tue, 25 Nov 2008 12:04:36 -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 tlUL5IN7O2nH for ; Tue, 25 Nov 2008 12:04:36 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 9CFDE28C1BB for ; Tue, 25 Nov 2008 12:04:35 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mAPK4QY29620; Tue, 25 Nov 2008 20:04:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Nov 2008 14:03:40 -0600 Message-ID: In-Reply-To: <20081125194501.E5B713A6A9F@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-02.txt Thread-Index: AclPNlVv0xwRNfCpTkWaD+dI8cX4PAAAFoSw References: <20081125194501.E5B713A6A9F@core3.amsl.com> From: "Ahmad Muhanna" To: Cc: Julien Laganier Subject: Re: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello folks, Based on the 2nd MEXT meeting decision, the Rev 02 of Binding Revocation for IPv6 Mobility has been published with the following changes that have been discussed in the meeting: 1. Made sure that when BRI and BRA is used for revoking a Client MIP6 binding, the same rules in sending BU/BA is followed. In other words, HoA is included in the Type 2 header when sending BRI and HoA included in the Destination option when sending BRA. 2. Updated the requirement on including the HNP when the (P) bit is set as follows: " 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. " 3. Added the missing trigger "IPv4 HoA Binding ONLY" 4. Combined the following texts in one bullet. Maintained the same meaning and eliminated redundant text. o If the Revocation Trigger field in the received BRI message is set to "Inter-MAG - Unknown Handoff", the MAG use the mobility option(s) included in the BRI message to identify the mobile node binding and MUST validate that the mobile node is no longer attached to the MAG before sending a successful BRA message and deleting the resources associated with the mobile node binding. If the Revocation Trigger field value in the received Binding Revocation Indication message indicates an inter-MAG handover and the (A) bit is set, the mobile access gateway MAY validate that the mobile node is no longer attached to the mobile access gateway before sending a successful Binding Revocation Acknowledgement message to the LMA. However, if the Revocation Trigger field is set to "Inter- MAG - Unknown Handoff", the MAG MUST validate that the mobile node is no longer attached to the MAG before sending a successful BRA message and deleting the resources associated with the mobile node binding. NEW Text: o If the Revocation Trigger field value in the received Binding Revocation Indication message indicates an inter-MAG handover and the (A) bit is set, the MAG use the mobility option(s) included in the BRI message to identify the mobile node binding. The mobile access gateway MAY validate that the mobile node is no longer attached to the mobile access gateway before sending a successful Binding Revocation Acknowledgement message to the LMA. However, if the Revocation Trigger field is set to "Inter-MAG - Unknown Handoff", the MAG MUST validate that the mobile node is no longer attached to the MAG before sending a successful BRA message and deleting the resources associated with the mobile node binding. 5. Editorial change when the (G) bit is set under section 9.1.1. With respect to the destination IP address of the BRI message, the same text of rev 01 has been maintained without any change except correcting a typo where the "destination IP address" was referenced as "source IP address" ONLY this change was made. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Tuesday, November 25, 2008 1:45 PM > To: i-d-announce@ietf.org > Cc: mext@ietf.org > Subject: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-02.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-02.txt > Pages : 34 > Date : 2008-11-25 > > This document defines the revocation semantics for > terminating a mobile node's mobility session and associated > resources. These semantics are generic enough and can be > used by mobility entities in the case of Client 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-re vocation-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 mext-bounces@ietf.org Tue Nov 25 15:42:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D58B128C201; Tue, 25 Nov 2008 15:42:26 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6387C28C1D8 for ; Tue, 25 Nov 2008 15:42:25 -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 XAMN+ll9v0h3 for ; Tue, 25 Nov 2008 15:42:24 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 0ACA928C1CA for ; Tue, 25 Nov 2008 15:42:23 -0800 (PST) Received: by qyk4 with SMTP id 4so347323qyk.13 for ; Tue, 25 Nov 2008 15:42:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=BG+jvtUbIZ2ARILUVHESrPjKkeufczB2XPwAvFTz5SQ=; b=ncAzV+cOMhOHv3BMiy0dnavJwmIulS736vkNoCP9tH3e41pyPQQ0X+HX2F6M9s1Dvw raxPw7B+OIakFpB/Olg8f+lmv2TQOJqMqfGpY+gGGzUoWDmu62QdylO6Vh10cKsvdWAO mDcTYHiU3TuT03fBbGOAK4l548IZqdTybP8D4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=bCXtb9uFVAf8DiJlIy/dmGjVrRgZntaxXhmzQRpQmAqNalnfj+a49lo+r+1SNmA4y9 3oP5v18Cl3sTvQ/YqpH5uORs9uKL1676Gl0QXIjRdxkf2hnlbzHMj28NkjtfMUGZVDN6 DQJbx4sXI/x8IcF3tn3yYnQp0tfp0ujjeISL0= Received: by 10.214.115.11 with SMTP id n11mr4584756qac.64.1227656540884; Tue, 25 Nov 2008 15:42:20 -0800 (PST) Received: by 10.214.43.19 with HTTP; Tue, 25 Nov 2008 15:42:20 -0800 (PST) Message-ID: Date: Tue, 25 Nov 2008 15:42:20 -0800 From: "fan zhao" To: "Julien Laganier" In-Reply-To: <200811251254.47129.julien.laganier.IETF@googlemail.com> MIME-Version: 1.0 Content-Disposition: inline References: <200811251254.47129.julien.laganier.IETF@googlemail.com> Cc: netlmm@ietf.org, mext@ietf.org Subject: Re: [MEXT] [netlmm] question on the DHCP-PD X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, Thanks for your reply. Please see below. On Tue, Nov 25, 2008 at 3:54 AM, Julien Laganier wrote: > Hello Fan, > > On Friday 21 November 2008, fan zhao wrote: >> Hi, >> >> Below is the question regarding the DHCP based prefix delegation I >> had on the today's mext meeting. >> I also cc to the netlmm mailing list. >> >> My question is when the MN connects to a source access network using >> PMIP (or other type of network >> based mobility protocol), it obtains a home network prefix. Then the >> MN handovers to a target access >> network (i.e. the foreign link for the MN) using the Mobile IPv6. The >> handover procedure is as follows. >> >> 1) The MN obtains a care-of address from the target access network. >> 2) The MN discovers the home agent if it does not know. >> 3) The MN sets up the IPsec SA with the HA if it does not have the SA >> with the HA before. >> 4) During the step 3), the MN requests the HNP allocated from the HA >> based on RFC 4877/5026. >> 5) The MN realizes it is on the foreign link, then it needs to send >> the BU to the HA. >> Since the Mobile IPv6 BU can only register the binding between the >> CoA and one single home address, >> in order to register the binding between the HNP and the CoA, the MN >> needs to use >> the NEMO extensions, for example, by setting up the 'R' bit and using >> the implicit mode. > > There's no need to involve NEMO. You are confusing the notion of Home > Network Prefix with that of a NEMO Mobile Network Prefix: The Home > Network Prefix is a prefix advertized on the Home Link (by the HA or a > router in MIPv6 case, or a MAG in PMIPv6 case), while a NEMO Mobile > Network Prefix is a prefix delegated to a Mobile Router and advertised > in the Mobile Network. These are different cases. I completely agree with you on this. The home agent needs to know and set up the states for both the home network prefix and the mobile network prefix even though they may be the same. Currently this is done during the bootstrapping and prefix delegation procedure separately. I was not on the last SA2 meeting and I do not know much about discussion though the stage 2 description looks ok to me. Note that the only way currently defined to register a prefix during the BU is to use the NEMO extensions. > > As to your scenario above, the MN will simply register with the HA any > of the Home Addresses it configured out of the PMIPv6 Home Network > Prefix that was avertized to him. All of these registrations will > contain the Care-of Address that the MN configured on the foreign link. > > I do not see any issues. I agree that this works. However, the issue I concern about is how the DHCP-PD works when the home network prefix is the same as the mobile network prefix, or more generically, when the home network prefix is the part of the mobile network prefix. Both cases are allowed in the NEMO basic support protocol. Note that this issue is independent from whether the MN performs HO. When the MR powers up, e.g. on a foreign link, it performs the bootstrapping with the HA, and obtains the home network prefix from the HA during the IPSec SA establishement. Now the MR needs to perform the DHCP PD to obtain the mobile network prefix. Since the home network prefix is the same as or part of the mobile network prefix and is already allocated to the MR before, I am not sure whether the DHCP server will reject the request of the mobile network prefix in this case. Clarification on this issue is much appreciated. Thanks. Sincerely, fan > > --julien > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Nov 26 01:34:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CEE028C1B4; Wed, 26 Nov 2008 01:34:54 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C71BE28C1B4 for ; Wed, 26 Nov 2008 01:34:52 -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 E56fHRsnqlHv for ; Wed, 26 Nov 2008 01:34:51 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by core3.amsl.com (Postfix) with ESMTP id 78A0A3A6B48 for ; Wed, 26 Nov 2008 01:34:51 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b11so201728nfh.39 for ; Wed, 26 Nov 2008 01:34:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:from; bh=5QNObBjn7iFc3R6RfRK5f0Cd7YFFujMldDpqSqFVov8=; b=SvXP/TKkNrH81rWmEF5shLXLxyb2J4p9hpQU56Z8MfXteqAPFdATUhfwOLSjsTOkvU s2HZsX1EcUARwsayLJwvJX+3oDd/Wko23d0WhbbWjdNNcYBAYWbBfDRwIytP1OhtL74d MaEMGKW+C5lseTLiQp3/i0Winm7z8dH+mnXFo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:cc:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; b=icCy+X5/xLrQbyT+HiC3eqHtDMWXbV3jow7pspAlEpoN+vSmYaPAWdtk2XUiiDNudb 6r9SxV4NaB43zEKrIGBTXKX9/rCWVBFnZlfKPIylv1oW5sahSHj2yOHiqBKkU3xwO/4D GsVDoMpRN6qj+HPrF/i8b6OvwL+A8b3gJHXi0= Received: by 10.210.41.14 with SMTP id o14mr5748300ebo.171.1227692088231; Wed, 26 Nov 2008 01:34:48 -0800 (PST) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id 32sm1166999nfu.10.2008.11.26.01.34.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 26 Nov 2008 01:34:47 -0800 (PST) To: mext@ietf.org Date: Wed, 26 Nov 2008 10:34:50 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200811261034.50582.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: netlmm@ietf.org, Jari Arkko , netlmm-chairs@tools.ietf.org Subject: [MEXT] MEXT WGLC for draft-ietf-mext-binding-revocation-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, [ CC'ing NETLMM Mailing List as we agreed earlier that the work on ] [ Binding Revocation will be coordinated with the NETLMM WG. NETLMM ] [ participants, please reply to this MEXT WGLC to w/o ] [ CC'ing ] During IETF-73 we MEXT chairs explained that we planned to issue a WGLC for the Binding Revocation draft after the meeting. There's however one outstanding unresolved issue which is related to the semantic of the alternate care-of address as defined in RFC 3775. The alternate care-of address issue has been discussed in the NETLMM WG as well, and is considered as a possible MIPv6 generic issue to be addressed within RFC 3775bis. Given that some SDO have tight dependencies to the binding revocation, to get the binding revocation draft approved for publication as RFC faster, we've discussed with our AD and some of the people involved in discussing the issue, and we have come up with the following plan: - We are hereby issuing a WGLC for the Binding Revocation draft while making the specific alternate care-of address issue explicitely out of scope of this WGLC. That will allow us to proceed with submission to IESG, IETF Last Call, etc, in parallel with the resolution of the alternate care-of address issue of RFC 3775bis. - In parallel to that, the MEXT working group will work toward reaching consensus on the alternate care-of address issue. Once that happens, the Binding Revocation draft will be aligned with the WG consensus. We believe that this is most efficient way to complete the Binding Revocation deliverable. Please reply to this email to state whether or not you think this document is ready to be forwarded to IESG, with resolution of the alternate care-of address pending resolution of the generic alternate care-of address issue in RFC 3775. If you disagree with the proposed way forward (issuing WGLC with pending resolution of the alternate care-of address), please also reply to this email to say so (note that disagreeing with this way forward is equivalent to belief that the document is not ready to be forwarded to IESG as is.) The WGLC closes on 2008-12-10 (Wednesday). Thank you for your support. --julien & marcelo, MEXT chairs _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Nov 26 05:07:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2520028C1FC; Wed, 26 Nov 2008 05:07:01 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1188628C1F1 for ; Wed, 26 Nov 2008 05:07:00 -0800 (PST) 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 Dk-cdkvhB8Zw for ; Wed, 26 Nov 2008 05:06:59 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id C71DC28C171 for ; Wed, 26 Nov 2008 05:06:58 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so190277eyd.31 for ; Wed, 26 Nov 2008 05:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=Z5RQyDtNrRMB/PfqbapB2FJC9YSNC2WDVz6qosk6Eow=; b=WoBfaPWxm+xq8oYQQEIvktqO+WJSV8OEZpRnKOfHdoeOQLnKH3CrFWkWk+buTTI1IP 8n5seELMLLkA1QFYMP3HmU69UvwDG3o/xbk/beHNHOtBTdp7Q32HKbiI1loB7dIkdG/d phtNRtskGDrz8PX1ZkVTEOhtJ/bZLqT9fjETU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:cc:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id:from; b=fteNVjrFc/neXbuItrZgh7CwcTi2JAJD6rbbeFHF593+5WmqXEURbNCZ7tEuUFMHEQ KRMMTTnrYX7d9kmvc3WSPWmIfQ1DheGEAI2gNTUkWDmnJMX/9SJo+6EU+5bTnO43HaQS u0I0pD2AvFXdiFR2WTEc4D9Y848GHwc+fBewc= Received: by 10.210.68.17 with SMTP id q17mr5981899eba.50.1227704814914; Wed, 26 Nov 2008 05:06:54 -0800 (PST) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id k9sm660682nfh.23.2008.11.26.05.06.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 26 Nov 2008 05:06:54 -0800 (PST) To: "fan zhao" Date: Wed, 26 Nov 2008 14:06:56 +0100 User-Agent: KMail/1.9.10 References: <200811251254.47129.julien.laganier.IETF@googlemail.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200811261406.57408.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: netlmm@ietf.org, mext@ietf.org Subject: Re: [MEXT] [netlmm] question on the DHCP-PD X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Fan, On Wednesday 26 November 2008, fan zhao wrote: > wrote: > > On Friday 21 November 2008, fan zhao wrote: > >> > >> My question is when the MN connects to a source access network > >> using PMIP (or other type of network > >> based mobility protocol), it obtains a home network prefix. Then > >> the MN handovers to a target access > >> network (i.e. the foreign link for the MN) using the Mobile IPv6. > >> The handover procedure is as follows. > >> > >> 1) The MN obtains a care-of address from the target access > >> network. 2) The MN discovers the home agent if it does not know. > >> 3) The MN sets up the IPsec SA with the HA if it does not have the > >> SA with the HA before. > >> 4) During the step 3), the MN requests the HNP allocated from the > >> HA based on RFC 4877/5026. > >> 5) The MN realizes it is on the foreign link, then it needs to > >> send the BU to the HA. > >> Since the Mobile IPv6 BU can only register the binding between the > >> CoA and one single home address, > >> in order to register the binding between the HNP and the CoA, the > >> MN needs to use > >> the NEMO extensions, for example, by setting up the 'R' bit and > >> using the implicit mode. > > > > There's no need to involve NEMO. You are confusing the notion of > > Home Network Prefix with that of a NEMO Mobile Network Prefix: The > > Home Network Prefix is a prefix advertized on the Home Link (by the > > HA or a router in MIPv6 case, or a MAG in PMIPv6 case), while a > > NEMO Mobile Network Prefix is a prefix delegated to a Mobile Router > > and advertised in the Mobile Network. These are different cases. > > I completely agree with you on this. The home agent needs to know and > set up the states for both the home network prefix and the mobile > network prefix even though they may be the same. The whole point is: The case where the Home Network Prefix and the Mobile Network Prefix are the same doesn't make any sense in the context of NEMO. The Home Network Prefix is advertized and used on the point-to-point link between the MAG and the MN - or MR in the case we're discussing. If the Mobile Network Prefix is the same as the Home Network Prefix, it can't be advertized or used on a different link than the point-to-point link between the MAG and the MN/MR - otherwise you get what's called a multilink subnet and that is not allowed. Thus if the Mobile Network Prefix and the Home Network Prefix are the same, the Mobile Network Prefix must only be advertized and used on the point-to-point link bewteen MAG and MN/MR. Since the point-to-point link has only two nodes attached to it, the MAG and the MN/MR, given that MAG isn't mobile, you end up with a Mobile Network Prefix that is only advertized to and used by a single node, i.e. the MN/MR. In that situation you obviously don't need to use NEMO since MIPv6 & PMIPv6 handle quite well the mobility of a single node - the MN. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Nov 26 11:59:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A05E328C245; Wed, 26 Nov 2008 11:59:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2FC3A6C68 for ; Wed, 26 Nov 2008 11:59:15 -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 97BYAaWGHKC4 for ; Wed, 26 Nov 2008 11:59:14 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 991493A69CD for ; Wed, 26 Nov 2008 11:59:14 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so184964qwe.31 for ; Wed, 26 Nov 2008 11:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=nAt/w9+vZODX6ycaW36ogWhKGyLFm3uOanid720UzQ4=; b=keEx8X4DM3Jyb6RV2fB+l5d0+WqZbnwkzXyHK6HNh+mIVcrGG4I4IFFsD8bLFRp9dl GzeG1ayuZdN8aG3WTxbpiUF1NnRukddH4pprOen4CgqqjSEs1QbBAvLZSQDDjl3QuHGL P3nQjh/k7keMUaMxKi2conq2wWb9t4JJMFhxo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=n4DXXNo9GS4VQsYa8HyO2zQUdzq7BRrMNmWz4aR3OOrtzCmHDF7GTaKVtc1a6hJqcE hxngLVFBi/gmF95Fe8z6yDwYGy9I0cdzbPJsLfI2kGushz9YlUf86Kpy8nzXAFuPUpep 4m1wN5LlZfwRfSQwSbKLRpQCJmtE3E1RPBUPY= Received: by 10.214.26.7 with SMTP id 7mr5878865qaz.91.1227729550878; Wed, 26 Nov 2008 11:59:10 -0800 (PST) Received: by 10.214.43.19 with HTTP; Wed, 26 Nov 2008 11:59:10 -0800 (PST) Message-ID: Date: Wed, 26 Nov 2008 11:59:10 -0800 From: "fan zhao" To: "Julien Laganier" In-Reply-To: <200811261406.57408.julien.laganier.IETF@googlemail.com> MIME-Version: 1.0 Content-Disposition: inline References: <200811251254.47129.julien.laganier.IETF@googlemail.com> <200811261406.57408.julien.laganier.IETF@googlemail.com> Cc: netlmm@ietf.org, mext@ietf.org Subject: Re: [MEXT] [netlmm] question on the DHCP-PD X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, Thanks. Please see below. On Wed, Nov 26, 2008 at 5:06 AM, Julien Laganier wrote: > Hi Fan, > > On Wednesday 26 November 2008, fan zhao wrote: >> wrote: >> > On Friday 21 November 2008, fan zhao wrote: >> >> >> >> My question is when the MN connects to a source access network >> >> using PMIP (or other type of network >> >> based mobility protocol), it obtains a home network prefix. Then >> >> the MN handovers to a target access >> >> network (i.e. the foreign link for the MN) using the Mobile IPv6. >> >> The handover procedure is as follows. >> >> >> >> 1) The MN obtains a care-of address from the target access >> >> network. 2) The MN discovers the home agent if it does not know. >> >> 3) The MN sets up the IPsec SA with the HA if it does not have the >> >> SA with the HA before. >> >> 4) During the step 3), the MN requests the HNP allocated from the >> >> HA based on RFC 4877/5026. >> >> 5) The MN realizes it is on the foreign link, then it needs to >> >> send the BU to the HA. >> >> Since the Mobile IPv6 BU can only register the binding between the >> >> CoA and one single home address, >> >> in order to register the binding between the HNP and the CoA, the >> >> MN needs to use >> >> the NEMO extensions, for example, by setting up the 'R' bit and >> >> using the implicit mode. >> > >> > There's no need to involve NEMO. You are confusing the notion of >> > Home Network Prefix with that of a NEMO Mobile Network Prefix: The >> > Home Network Prefix is a prefix advertized on the Home Link (by the >> > HA or a router in MIPv6 case, or a MAG in PMIPv6 case), while a >> > NEMO Mobile Network Prefix is a prefix delegated to a Mobile Router >> > and advertised in the Mobile Network. These are different cases. >> >> I completely agree with you on this. The home agent needs to know and >> set up the states for both the home network prefix and the mobile >> network prefix even though they may be the same. > > The whole point is: The case where the Home Network Prefix and the > Mobile Network Prefix are the same doesn't make any sense in the > context of NEMO. > > The Home Network Prefix is advertized and used on the point-to-point > link between the MAG and the MN - or MR in the case we're discussing. That is correct in the PMIP domain. However, when the MN handovers to a foreign access network with the MIP used, the Home Network Prefix can be associated with the MN's logical/physical interface, right? Note that the case what I talked about is that a plain mobile IP terminal (not a MR) handovers between the PMIP and CMIP access network. > > If the Mobile Network Prefix is the same as the Home Network Prefix, it > can't be advertized or used on a different link than the point-to-point > link between the MAG and the MN/MR - otherwise you get what's called a > multilink subnet and that is not allowed. I agree that when the MN attaches to the PMIP domain, it cannot advertise the same prefix on another link. However, in the case we are discussing, the MN performs HO from the PMIP domain, the MAG detects that and stops advertising the Home network prefix on the P2P link, the MN configures a care-of address on one interface and continues to use the Home network prefix. I do not see any issue with that. > > Thus if the Mobile Network Prefix and the Home Network Prefix are the > same, the Mobile Network Prefix must only be advertized and used on the > point-to-point link bewteen MAG and MN/MR. I am not considering the case when the MR attaches to the PMIP domain. In fact, I do not think any NEMO extension is needed when the _MN_ attaches to the PMIP domain. What I concern is that the behavior of the MN when it handovers to the target access using MIP. I mentioned the PMIP in the example just because with the PMIP protocol, multiple IP addresses can be configured from the home network prefix therefore, there is a need to perserve the whole IP prefix during HO. The NEMO extension is the only way to register a prefix with the HA. Such prefix is the mobile network prefix and the prefix delegation needs to be performed. That is why I raised the problem regarding the DHCP PD. Another way to allow the whole prefix to be registered during BU is to use the Home Network Prefix option defined in 8.3 of RFC 5213. This can be documented in the RFC 3775bis. What do you think? With this approach, the NEMO extensions are not needed. However, the question regarding the DHCP PD still needs to be discussed. Let us consider the case of initial attach, not the handover. When the MR powers up on a foreign link, it performs the bootstrapping and obtains a home prefix (A:B:C:0::/64) based on rfc 5026 during the IKE and configures a home address from that home prefix. Based on the NEMO basic support protocol, the home address/prefix can be part of the mobile network prefix (e.g. A:B:C::/48). The MR then runs DHCP PD to request such mobile network prefix; however since the HA already allocates part of the mobile network prefix (A:B:C:0::/64) to the MR during bootstrapping, the DHCP server will reject such request, right? Do I understand correctly? What do you think? Thanks. Sincerely, fan > > Since the point-to-point link has only two nodes attached to it, the MAG > and the MN/MR, given that MAG isn't mobile, you end up with a Mobile > Network Prefix that is only advertized to and used by a single node, > i.e. the MN/MR. > > In that situation you obviously don't need to use NEMO since MIPv6 & > PMIPv6 handle quite well the mobility of a single node - the MN. > > --julien > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 27 02:44:58 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57623A6B9D; Thu, 27 Nov 2008 02:44:58 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 860C33A6B9D for ; Thu, 27 Nov 2008 02:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 AMYzIfwTplDA for ; Thu, 27 Nov 2008 02:44:56 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id BB4163A6B9B for ; Thu, 27 Nov 2008 02:44:56 -0800 (PST) Received: from [IPv6:2001:660:4701:1001:21b:63ff:fe94:5dc0] (unknown [IPv6:2001:660:4701:1001:21b:63ff:fe94:5dc0]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id CC1D04C051 for ; Thu, 27 Nov 2008 19:44:48 +0900 (JST) Message-Id: <6E84257D-DC83-4DB7-9174-2A2D2A6FEAF7@lsiit.u-strasbg.fr> From: Romain KUNTZ To: mext In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D6CA073E@NASANEXMB08.na.qualcomm.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 27 Nov 2008 11:44:45 +0100 References: <492B7034.9020303@sg.panasonic.com> <057632CE4CE10D45A1A3D6D19206C3A3D6CA073E@NASANEXMB08.na.qualcomm.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [MEXT] Comments on draft-ietf-mext-flow-binding-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello, On 2008/11/25, at 17:41, Giaretta, Gerardo wrote: >> If we make the assumption that refreshing all is more common that >> removing >> all (fair assumption I think) then we can try to optimise for that. >> > > I think it is a fair assumption. I think the following should be the > principles to implement: > > - add, replace, remove flow bindings require 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 specific BID are not changed in this > case. > - The lifetime of the flow binding is tied to the lifetime of the > CoA binding. This implies 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 option overwrites all bindings including the > flow binding > > The latter is used for example when the MN wants to go through MCoA > mode to single CoA mode. > > Does it make sense? I'm in favor with what Gerardo is proposing. This is also what I had in mind. Regards, romain _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 27 02:51:13 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130C528C13F; Thu, 27 Nov 2008 02:51:13 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7CE728C13F for ; Thu, 27 Nov 2008 02:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 mUVOnbSyHqxY for ; Thu, 27 Nov 2008 02:51:11 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 3A54A3A6907 for ; Thu, 27 Nov 2008 02:51:11 -0800 (PST) Received: from [IPv6:2001:660:4701:1001:21b:63ff:fe94:5dc0] (unknown [IPv6:2001:660:4701:1001:21b:63ff:fe94:5dc0]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id D6FA64C051 for ; Thu, 27 Nov 2008 19:51:04 +0900 (JST) Message-Id: <73993724-1109-4210-A6BD-009AA76CDC03@lsiit.u-strasbg.fr> From: Romain KUNTZ To: mext In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D6CA06E9@NASANEXMB08.na.qualcomm.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 27 Nov 2008 11:51:02 +0100 References: <057632CE4CE10D45A1A3D6D19206C3A3D6CA06E9@NASANEXMB08.na.qualcomm.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [MEXT] Comments on draft-ietf-mext-flow-binding-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Gerardo, On 2008/11/25, at 1:20, Giaretta, Gerardo wrote: >> Another concern is why another method to update a CoA is defined in >> this >> document (section 6.2)? First, I don't really see the motivations >> behind this, >> and if I understood correctly how n-casting is specified in the BC, >> one (HoA, >> FID) pair may reference multiple entries, which makes the CoA update >> impossible in case n-casting is used (see my other comment on that >> later). >> > > I don't fully understand your point here. Are you saying that a CoA > change should always be done as per the MCoA draft (i.e. via BID)? > If this is the intention, I agree - I don't see reasons why we > should introduce the FIDs unless they need to be changed (e.g. added > or removed). Yes that was exactly my point. I think you take it into account in your other mail where you propose an algorithm to process the BU. >> - Section 3.2: The BID sub-option is 16 bits in the MCoA draft >> while here only >> 8 bits are used to specify a BID. > > Better: the BID field in BID sub-option is 16 bits in the MCoA draft Yes, this is what I meant. Thanks, romain _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 27 02:54:43 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B01428C15D; Thu, 27 Nov 2008 02:54:43 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E67828C15D for ; Thu, 27 Nov 2008 02:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qtb9AbCKzqkX for ; Thu, 27 Nov 2008 02:54:40 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 6FDAC3A6407 for ; Thu, 27 Nov 2008 02:54:39 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1L5eVx-0001hR-Kw; Thu, 27 Nov 2008 21:54:31 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Thu, 27 Nov 2008 21:54:22 +1100 From: Hesham Soliman To: "Giaretta, Gerardo" , Benjamin Lim Message-ID: Thread-Topic: [MEXT] Comments on draft-ietf-mext-flow-binding-00 Thread-Index: AclOv9JB9wi2u1Q/qkGmNuSo03NZNgAW1CIwAFjXmKI= In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D6CA073E@NASANEXMB08.na.qualcomm.com> Mime-version: 1.0 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 List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Gerardo, >> => I'll try to answer all of the above by simply stating the following: >> The way MIPv6 works is that one BU replaces another, there is no state >> differentials that are carried across between the old and new BCEs in an >> implicit manner. >> What this means is that if you want to refresh a state, you include that >> state in the BU. >> If we do the above, then we're simply removing the "big BU" to the remove >> operation. If a MN wants to remove all FIDs, it can simply send a BU with >> none of the FIDs included. Hence, removing all data is very efficient. >> >> If we make the assumption that refreshing all is more common that removing >> all (fair assumption I think) then we can try to optimise for that. >> > > I think it is a fair assumption. I think the following should be the > principles to implement: > > - add, replace, remove flow bindings require 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 specific BID are not changed in this case. > - The lifetime of the flow binding is tied to the lifetime of the CoA binding. > This implies 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 option overwrites all bindings including the flow > binding > > The latter is used for example when the MN wants to go through MCoA mode to > single CoA mode. > > Does it make sense? => Mostly yes. But I think we need to be explicit to some extent about the refresh. For example, what happens if you want to modify one or more FIDs while keeping the others unchanged? I think if we change things to the way you propose we have to have an explicit option that says "refresh everything except for the FIDs included in this BU, they need to be treated on a per-FID basis" Otherwise, the mixed operations become quite messy. There might be a simple way of doing this if we reserve one FID to indicate "All". For instance, the all 1s FID can be used to say the above statement. Hesham Hesham > > Gerardo > >> Hesham >> >> >>> >>> Regards, >>> Benjamin Lim >>> >>>> >>>>> So in the current state of the draft, refreshing seems useless. >>>>> >>>>> Besides, note that refreshing can be a costly operation: Mobile Routers >> may >>>>> have hundreds of rules, e.g. depending on the number of clients they >> serve. >>>>> >>>> >>>> I see your concerns and I agree we should optimize this. >>>> >>>> One way would be to add a new flag in the BU which indicates that flow >>>> bindings >>>> are also extended with the new lifetime. Note that BIDs also must always be >>>> included in the BU as a BU without BID will overwrite all BIDs. >>>> >>>> Another approach is to introduce the lifetime at the FID level but that is >>>> not >>>> good in my opinion. >>>> >>>>> Another concern is why another method to update a CoA is defined in this >>>>> document (section 6.2)? First, I don't really see the motivations behind >>>>> this, >>>>> and if I understood correctly how n-casting is specified in the BC, one >>>>> (HoA, >>>>> FID) pair may reference multiple entries, which makes the CoA update >>>>> impossible in case n-casting is used (see my other comment on that later). >>>>> >>>> >>>> I don't fully understand your point here. Are you saying that a CoA change >>>> should always be done as per the MCoA draft (i.e. via BID)? If this is the >>>> intention, I agree - I don't see reasons why we should introduce the FIDs >>>> unless they need to be changed (e.g. added or removed). >>>> >>>>> * Some more detailed comments: >>>>> >>>>> - Section 3.1, page 7, the Flow ID option shows a FID field of 16 bits but >>>>> it >>>>> is described as an "an 8-bit unsigned integer". >>>>> - Page 9, it is said "If this value is used, one or more Binding Reference >>>>> sub-options MUST exist.". Actually only a single Binding Reference >>>>> sub-option >>>>> is used but one or more BIDs must be indicated inside of it. >>>>> >>>> >>>> I think both comments are correct >>>> >>>>> - Section 3.2: The BID sub-option is 16 bits in the MCoA draft while here >>>>> only >>>>> 8 bits are used to specify a BID. >>>> >>>> Better: the BID field in BID sub-option is 16 bits in the MCoA draft >>>> >>>>> - Some indication is needed on how this option (which can have a variable >>>>> length) should be aligned and padded using the MIPv6 padding options >>>>> >>>>> - Section 4.2: "an entry is now identified by the pair (home address, >> FID)". >>>>> This is true only when we want to update the flow bindings. To update a >> CoA >>>>> (e.g. with a BU that only contains a BID option and no flow id options), >> the >>>>> (HoA, BID) pair remains the key to lookup the BC/BUL. Note also that the >>>>> pair >>>>> (HoA, FID) can refer to multiple entries when n-casting is used. >>>>> >>>> >>>> I think this is correct but also the text in the draft is correct. My >>>> understanding is that the text in the draft deals with the processing of >> BUs >>>> when they contain the FID option. If a BU only contains the BID option, the >>>> processing of the MCoA draft applies. >>>> >>>>> - Section 4.5: what happens if the flow id option has the PRO field set to >> 1 >>>>> (modify) and no flow description is present? Section 6.2 explains that it >>>>> should be considered as a CoA update, but IMHO this should rather be >>>>> considered as a request to modify the existing flow description in the BCE >>>>> to >>>>> a wild card request. >>>>> >>>> >>>> More in general the draft should clarify how wild card request and default >>>> bindings are supported. See my review a couple of days ago for details on >>>> which are the issues in my view. >>>> >>>>> - Section 6.1.1: "The FID field includes a value that does not already >> exist >>>>> in the mobile node's binding update list.": [...] for that HA or MAP >>>>> - "If the Binding Update sub-option includes only one BID," -> which sub- >>>>> option, the Binding Reference sub-option? >>>>> >>>>> - Section 6.1.2: "the mobile node MUST NOT refresh or delete bindings >>>>> associated with any care-of address other than the one included in the BU >>>>> message." -> why? >>>>> >>>>> - Section 6.2: the "MODIFY" code is used but is never defined. It would be >>>>> good to define the ADD/MODIFY/DELETE terms in section 3.1 and to use them >>>>> through the document. >>>>> >>>>> - Section 6.3 states that n-casting is possible with the CN with some >>>>> conditions, but section 7.1 simply forbids n-casting ("If the Action field >>>>> indicates a request to n-cast the flow, the correspondent node MUST reject >>>>> the >>>>> option [...]") >>>>> >>>>> - Section 7.1: some notes on how the the flow binding is added to the >>>>> binding >>>>> cache should be written (existence of a BID sub-option in the BU, lookup >> in >>>>> the BCE with that BID, ...). Same comment for section 8.1 >>>>> - This section and section 8.1 do not say what to do when a request to >>>>> delete >>>>> a flow is received. >>>>> >>>>> - Section 8.1: "the home agent MUST check for the presence of the BID sub- >>>>> option(s)." -> actually section 3.2 does not mandate the presence of the >> BID >>>>> sub-options if the BID already exists in the BCE ("A BID sub-option is not >>>>> necessarily included in the same BU [...]"). If the BID does not exist yet >>>>> in >>>>> the BCE or if no BID sub-options are present, then this is an error case. >>>>> - "If one or more BIDs are present in the BID Reference sub-option" -> >>>>> Binding >>>>> Reference sub-option >>>>> - The following procedure is too complex IMHO: >>>>> >>>>> If only one BID were >>>>> included in the Binding Reference sub-option and it pointed to a >>>>> different care-of address from the one included in the packet, >>>>> then packets matching the flow would be bicast to those two >>>>> addresses. >>>>> >>>>> Especially because the BU may be sent using another source address than >> the >>>>> one expected for n-casting. Why not just forbid this case and explicitly >> ask >>>>> for at least 2 BIDs in the binding reference sub-option? >>>>> >>>> >>>> Agree on this as I mentioned in my review of the draft >>>> >>>> Gerardo >>>> >>>>> - I think it was already raised, but the document lacks some text on what >>>>> status code should be used upon error (section 7.1, 8.1, ...) and how such >>>>> error code should be treated on the receiver side. >>>>> >>>>> - Section 8.2: this section make me think that the section talking about >> the >>>>> MN side does not say what should be done when the BAck is not received >>>>> >>>>> - Section 10: "associate some flows to an interface and other flows to >>>>> another >>>>> interface": I would replace "interface" with "CoA" >>>>> >>>>> >>>>> * Some editorial comments: >>>>> >>>>> The document is inconsistent on how "Binding Update" / "Binding >>>>> Acknowledgement" / "Flow Identification" / "Flow Binding" / "Flow >>>>> Description" >>>>> / "N-cast" are written (the first letter is sometimes lower case, >> sometimes >>>>> upper case) >>>>> >>>>> Page 11: dsecription -> description >>>>> Page 15: Acknwoledgement -> Acknowledgement Page 22: Correspondant -> >>>>> Correspondent Page 23: authrozied -> authorized >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> -- >>>>> Romain KUNTZ >>>>> kuntz@lsiit.u-strasbg.fr >>>>> LSIIT - Networks and Protocols Team >>>>> http://clarinet.u-strasbg.fr/~kuntz/ >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 27 03:54:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 791EE3A6CD4; Thu, 27 Nov 2008 03:54:04 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 322E03A6CD4 for ; Thu, 27 Nov 2008 03:54:03 -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 5Thzr0kVSGKN for ; Thu, 27 Nov 2008 03:54:02 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by core3.amsl.com (Postfix) with ESMTP id 07BEB3A6CD2 for ; Thu, 27 Nov 2008 03:54:01 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id b39so1724428ugd.15 for ; Thu, 27 Nov 2008 03:53:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=ijI42bXBgL33ryUlIFPuAH3WfX44FPSSd5M67LMkfM8=; b=uOujxP1/IRtKDxBYV7kJtaU1FeiFHK4GQbCsETZLsvLEMQUI4Fyy+F5y+Mn2aqFxdg 741QL9jqPw/8JZrzMnWlzZ8bRO1PtMJTkkDVfPYFp9leIMMnxi/lVwgcZyGow3PUFkxH C8HQEJR+gCWHYbrZknSE/dM5CR0UrCb+LLagc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:cc:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id:from; b=QJ0qFunbSZx6oEOGfuqUWXpaUbJ0NFDWgBHZ/VtCZuGb9JO7addC30Oibmrvd8xKSt 4L2RGgRKHwm/9EAjgbx6B451etHa65rc5sKoxw1/K9vrkFhL6X4Q75KTJdFHYGmPxGy7 MAjNz/pAyYTrj2cNg37L8xYsYS7EpvtBA4gn4= Received: by 10.210.62.12 with SMTP id k12mr7353776eba.140.1227786837746; Thu, 27 Nov 2008 03:53:57 -0800 (PST) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id c9sm1726750nfi.26.2008.11.27.03.53.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Nov 2008 03:53:56 -0800 (PST) To: mext@ietf.org Date: Thu, 27 Nov 2008 12:53:49 +0100 User-Agent: KMail/1.9.10 References: <492B7034.9020303@sg.panasonic.com> <057632CE4CE10D45A1A3D6D19206C3A3D6CA073E@NASANEXMB08.na.qualcomm.com> In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D6CA073E@NASANEXMB08.na.qualcomm.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200811271253.51631.julien.laganier.IETF@googlemail.com> From: Julien Laganier Subject: [MEXT] Questions on draft-ietf-mext-flow-binding-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Hesham & all, I got some high-level questions on the draft. The text of the flow binding deliverable text in our charter says: A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. I am not 100% sure of my interpretation of the above, but I read it as if it should be possible for either of the mobile node/router or the home agent to initiate the flow/binding policies exchange. Is that appropriate? If yes, am I understanding right that your draft only address an exchange of policies from the mobile host/router to the home agent? If yes, wouldn't it make sense to also support the exchange of policies initiated by the home agent, i.e. from the home agent to the mobile host/router, as I understand our charter says? Orthognoal to that, I've got a dummy question: Why is flow/binding policy exchange only considered between MN/MR and HA and excludes flow/binding policy exchange between MN/MR and a correspondent node? Is it because one can't assume an arbitrary CN supports these extensions? Thanks. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 27 04:56:41 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E763A6822; Thu, 27 Nov 2008 04:56:41 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7579C3A6822 for ; Thu, 27 Nov 2008 04:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 m4ZttPa6Q3-J for ; Thu, 27 Nov 2008 04:56:38 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 94D993A67A8 for ; Thu, 27 Nov 2008 04:56:38 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 35FB619870B; Thu, 27 Nov 2008 14:56:35 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id D3B9F198646; Thu, 27 Nov 2008 14:56:34 +0200 (EET) Message-ID: <492E98F1.6010808@piuha.net> Date: Thu, 27 Nov 2008 14:56:17 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: "Glenn M. Keeni" References: <492BE35F.2040701@piuha.net> <492E95BD.1030602@cysols.com> In-Reply-To: <492E95BD.1030602@cysols.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: draft-ietf-mext-nemo-mib@tools.ietf.org, "mext@ietf.org" Subject: Re: [MEXT] Re-AD review comments on the nemo mib document X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Looks good, thanks. Jari Glenn M. Keeni wrote: > Jari, > Thanks for the review. > Jari Arkko wrote: > >> So, due to the large changes in the new version, this is going back to a >> WGLC and is also going to require a few more reviews. In the meantime I >> have re-reviewed the new version and I have the following comments: >> >> Please remove the commented out parts of the MIB (e.g., "-- Counter64"). >> > Done. > >> The object NemoBURequestRejectionCode says "The value of the status >> field in the BA ..." but lists values that are in the 1-4 range as >> opposed to the actual values in BAs. Please clarify which ones you >> actually want to use. >> > I see the problem here. We were introducing another mapping between > the textual-convention code and the value in the status field of the BA. > And the DESCRIPTION did not say that. > This will be fixed as: > NemoBURequestRejectionCode ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The value of the status field in the Binding > Acknowledgment message when the Binding Update > was rejected for NEMO specific reasons. > " > REFERENCE > "RFC 3963 : Section 4.2" > SYNTAX INTEGER { > mobileRouterOperationNotPermitted (140), > invalidPrefix (141), > notAuthorizedForPrefix (142), > forwardingSetupFailed (143) > } > > >> The object nemoHaBindingAcksOtherError seems to have a similar problem. >> >> > Yes. This too will be fixed as > nemoHaBindingAcksOtherError OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The total number of Binding Update requests > from mobile routers (Mobile Router Flag is > set) rejected by the home agent with status code > other than > mobileRouterOperationNotPermitted (Code 140), > invalidPrefix (Code 141), > notAuthorizedForPrefix (Code 142), > forwardingSetupFailed (Code 143) > and, > nemoMrBindingAcksOtherError OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The total number of Binding Acknowledgements > received by the mobile router (Mobile Router Flag is > set) with status code other than > successfully processed (0) > mobileRouterOperationNotPermitted (140) > invalidPrefix (141) > notAuthorizedForPrefix (142) > forwardingSetupFailed (143) > > >> Otherwise the new document looks good. I do expect some additional >> reviews, however. >> >> Jari >> > Thanks, Glenn > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 27 11:21:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1298C3A6A2D; Thu, 27 Nov 2008 11:21:47 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CE163A6A1F for ; Thu, 27 Nov 2008 11:21:45 -0800 (PST) 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=[AWL=-1.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 03ORyLMMBQ9z for ; Thu, 27 Nov 2008 11:21: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 24F233A69E5 for ; Thu, 27 Nov 2008 11:21:39 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1L5mQg-0002pD-Pl; Fri, 28 Nov 2008 06:21:35 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Fri, 28 Nov 2008 06:21:27 +1100 From: Hesham Soliman To: Julien Laganier , Message-ID: Thread-Topic: Questions on draft-ietf-mext-flow-binding-00 Thread-Index: AclQxVfi7HDBh6GcVEyHobRwszv4Zw== In-Reply-To: <200811271253.51631.julien.laganier.IETF@googlemail.com> Mime-version: 1.0 Subject: Re: [MEXT] Questions on draft-ietf-mext-flow-binding-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, This draft doesn't deal with "Policy exchange". Policy exchange does something like the following: - If 802.11b AND port 80 then use 802.11b - if VoIP then use 3G ....etc This draft deals with exchanging the routing information, based on policy decisions that were done by the MN/MR. There were other draft proposing XML policies be exchanged between the MN/HA. They're orthogonal to this draft. Also, the draft deals with MN-CN relationships already in the same way that it deals with the MN-HA relationship. Hesham On 27/11/08 10:53 PM, "Julien Laganier" wrote: > Hello Hesham & all, > > I got some high-level questions on the draft. > > The text of the flow binding deliverable text in our charter says: > A "Flow/binding policies exchange" solution for an exchange of policies > from the mobile host/router to the Home Agent and from the Home Agent > to the mobile host/router influencing the choice of the Care-of Address > and Home Agent address. > > I am not 100% sure of my interpretation of the above, but I read it as > if it should be possible for either of the mobile node/router or the > home agent to initiate the flow/binding policies exchange. Is that > appropriate? > > If yes, am I understanding right that your draft only address an > exchange of policies from the mobile host/router to the home agent? > > If yes, wouldn't it make sense to also support the exchange of policies > initiated by the home agent, i.e. from the home agent to the mobile > host/router, as I understand our charter says? > > Orthognoal to that, I've got a dummy question: Why is flow/binding > policy exchange only considered between MN/MR and HA and excludes > flow/binding policy exchange between MN/MR and a correspondent node? Is > it because one can't assume an arbitrary CN supports these extensions? > > Thanks. > > --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 27 18:04:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251CE3A68AC; Thu, 27 Nov 2008 18:04:47 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 967733A6826 for ; Thu, 27 Nov 2008 18:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[AWL=-1.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 7Ei2lmo-YnwL for ; Thu, 27 Nov 2008 18:04:44 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 9653A3A67FC for ; Thu, 27 Nov 2008 18:04:43 -0800 (PST) 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 mAS24W8M014430; Fri, 28 Nov 2008 11:04:32 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id mAS24W923021; Fri, 28 Nov 2008 11:04:32 +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 mAS24Ui19753; Fri, 28 Nov 2008 11:04:30 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Nov 2008 10:04:18 +0800 Message-ID: <492F51A1.40900@sg.panasonic.com> Date: Fri, 28 Nov 2008 10:04:17 +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 X-OriginalArrivalTime: 28 Nov 2008 02:04:18.0304 (UTC) FILETIME=[9F1AA000:01C950FD] Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Questions on draft-ietf-mext-flow-binding-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham & Julien, For clarification, if some policy decision that are done on the HA/MAP that influence how MN/MR should send uplink traffic, can HA/MAP use the FID option to set these routing rules on the MN/MR? If the mechanisms is similar, can we add some text in the introduction section (2nd last paragraph) stating that the FID option can also be sent from HA/MAP to MN/MR. What do you think? Regards, Benjamin Lim Hesham Soliman wrote: > Hi Julien, > > This draft doesn't deal with "Policy exchange". Policy exchange does > something like the following: > > - If 802.11b AND port 80 then use 802.11b > - if VoIP then use 3G > ....etc > This draft deals with exchanging the routing information, based on policy > decisions that were done by the MN/MR. > There were other draft proposing XML policies be exchanged between the > MN/HA. They're orthogonal to this draft. > > Also, the draft deals with MN-CN relationships already in the same way that > it deals with the MN-HA relationship. > > Hesham > > > On 27/11/08 10:53 PM, "Julien Laganier" > wrote: > >> Hello Hesham & all, >> >> I got some high-level questions on the draft. >> >> The text of the flow binding deliverable text in our charter says: >> A "Flow/binding policies exchange" solution for an exchange of policies >> from the mobile host/router to the Home Agent and from the Home Agent >> to the mobile host/router influencing the choice of the Care-of Address >> and Home Agent address. >> >> I am not 100% sure of my interpretation of the above, but I read it as >> if it should be possible for either of the mobile node/router or the >> home agent to initiate the flow/binding policies exchange. Is that >> appropriate? >> >> If yes, am I understanding right that your draft only address an >> exchange of policies from the mobile host/router to the home agent? >> >> If yes, wouldn't it make sense to also support the exchange of policies >> initiated by the home agent, i.e. from the home agent to the mobile >> host/router, as I understand our charter says? >> >> Orthognoal to that, I've got a dummy question: Why is flow/binding >> policy exchange only considered between MN/MR and HA and excludes >> flow/binding policy exchange between MN/MR and a correspondent node? Is >> it because one can't assume an arbitrary CN supports these extensions? >> >> Thanks. >> >> --julien > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 27 18:46:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E23173A689A; Thu, 27 Nov 2008 18:46:49 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A976D3A689A for ; Thu, 27 Nov 2008 18:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, GB_I_LETTER=-2, 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 6+HdJe3wM7ed for ; Thu, 27 Nov 2008 18:46:47 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 285D83A6809 for ; Thu, 27 Nov 2008 18:46:47 -0800 (PST) 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 mAS2kffX022253; Fri, 28 Nov 2008 11:46:41 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb2) with ESMTP id mAS2kfs21748; Fri, 28 Nov 2008 11:46:41 +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 mAS2kai07863; Fri, 28 Nov 2008 11:46:37 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Nov 2008 10:46:21 +0800 Message-ID: <492F5B7D.6020806@sg.panasonic.com> Date: Fri, 28 Nov 2008 10:46:21 +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 X-OriginalArrivalTime: 28 Nov 2008 02:46:21.0708 (UTC) FILETIME=[7F2B84C0:01C95103] 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 List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi all, My comment inline. I snip to the text. Hesham Soliman wrote: > > There might be a simple way of doing this if we reserve one FID to indicate > "All". For instance, the all 1s FID can be used to say the above statement. [Ben] For this way, there will be quite a significant number of rules created to cater most permutation (i.e. refresh this group of rules). Not sure if it raises the complexity in the terminal for rules processing. To summaries, I believe we are trying to specify the behavior of HA (who currently have rules for MN) and MN sends a BU without FID option. Should the HA: (a) totally do not care. (b) treat them as MN is refreshing all rules. (c) treat them as MN is deleting all rules. For (a), it is as per the current draft (although not explicitly stated) and if MN wants to do something to the rule, MN has to indicate it to HA with FID option (i.e. when MN sends BU to refresh CoA, MN has to tell HA via FID options on the status of each rule bound to that entry). For (b) and (c), it is seen as an optimization of (a), due to the case of MR that Romain brought up (which does make sense). The disadvantage I see for (b) is when MN wants to remove all rules from CoA (or a significant amount of rules) and keep that CoA entry in BCE, MN needs to include all FID options with 'delete' action. Question is how often does this happen? The disadvantage I see for (c) is when rules does not change, MN would have to keep telling HA using FID option. A way to combat this is to create a FID that states refresh rule(s) and MN need only to tell HA of this FID. Question is that will this create many rules in terminal and hence increase complexity for rule processing? Hopes this help for discussion. Regards, Benjamin Lim > Hesham > > > Hesham > > > >> Gerardo >> >>> Hesham >>> >>> >>>> Regards, >>>> Benjamin Lim >>>> >>>>>> So in the current state of the draft, refreshing seems useless. >>>>>> >>>>>> Besides, note that refreshing can be a costly operation: Mobile Routers >>> may >>>>>> have hundreds of rules, e.g. depending on the number of clients they >>> serve. >>>>> I see your concerns and I agree we should optimize this. >>>>> >>>>> One way would be to add a new flag in the BU which indicates that flow >>>>> bindings >>>>> are also extended with the new lifetime. Note that BIDs also must always be >>>>> included in the BU as a BU without BID will overwrite all BIDs. >>>>> >>>>> Another approach is to introduce the lifetime at the FID level but that is >>>>> not >>>>> good in my opinion. >>>>> >>>>>> Another concern is why another method to update a CoA is defined in this >>>>>> document (section 6.2)? First, I don't really see the motivations behind >>>>>> this, >>>>>> and if I understood correctly how n-casting is specified in the BC, one >>>>>> (HoA, >>>>>> FID) pair may reference multiple entries, which makes the CoA update >>>>>> impossible in case n-casting is used (see my other comment on that later). >>>>>> >>>>> I don't fully understand your point here. Are you saying that a CoA change >>>>> should always be done as per the MCoA draft (i.e. via BID)? If this is the >>>>> intention, I agree - I don't see reasons why we should introduce the FIDs >>>>> unless they need to be changed (e.g. added or removed). >>>>> >>>>>> * Some more detailed comments: >>>>>> >>>>>> - Section 3.1, page 7, the Flow ID option shows a FID field of 16 bits but >>>>>> it >>>>>> is described as an "an 8-bit unsigned integer". >>>>>> - Page 9, it is said "If this value is used, one or more Binding Reference >>>>>> sub-options MUST exist.". Actually only a single Binding Reference >>>>>> sub-option >>>>>> is used but one or more BIDs must be indicated inside of it. >>>>>> >>>>> I think both comments are correct >>>>> >>>>>> - Section 3.2: The BID sub-option is 16 bits in the MCoA draft while here >>>>>> only >>>>>> 8 bits are used to specify a BID. >>>>> Better: the BID field in BID sub-option is 16 bits in the MCoA draft >>>>> >>>>>> - Some indication is needed on how this option (which can have a variable >>>>>> length) should be aligned and padded using the MIPv6 padding options >>>>>> >>>>>> - Section 4.2: "an entry is now identified by the pair (home address, >>> FID)". >>>>>> This is true only when we want to update the flow bindings. To update a >>> CoA >>>>>> (e.g. with a BU that only contains a BID option and no flow id options), >>> the >>>>>> (HoA, BID) pair remains the key to lookup the BC/BUL. Note also that the >>>>>> pair >>>>>> (HoA, FID) can refer to multiple entries when n-casting is used. >>>>>> >>>>> I think this is correct but also the text in the draft is correct. My >>>>> understanding is that the text in the draft deals with the processing of >>> BUs >>>>> when they contain the FID option. If a BU only contains the BID option, the >>>>> processing of the MCoA draft applies. >>>>> >>>>>> - Section 4.5: what happens if the flow id option has the PRO field set to >>> 1 >>>>>> (modify) and no flow description is present? Section 6.2 explains that it >>>>>> should be considered as a CoA update, but IMHO this should rather be >>>>>> considered as a request to modify the existing flow description in the BCE >>>>>> to >>>>>> a wild card request. >>>>>> >>>>> More in general the draft should clarify how wild card request and default >>>>> bindings are supported. See my review a couple of days ago for details on >>>>> which are the issues in my view. >>>>> >>>>>> - Section 6.1.1: "The FID field includes a value that does not already >>> exist >>>>>> in the mobile node's binding update list.": [...] for that HA or MAP >>>>>> - "If the Binding Update sub-option includes only one BID," -> which sub- >>>>>> option, the Binding Reference sub-option? >>>>>> >>>>>> - Section 6.1.2: "the mobile node MUST NOT refresh or delete bindings >>>>>> associated with any care-of address other than the one included in the BU >>>>>> message." -> why? >>>>>> >>>>>> - Section 6.2: the "MODIFY" code is used but is never defined. It would be >>>>>> good to define the ADD/MODIFY/DELETE terms in section 3.1 and to use them >>>>>> through the document. >>>>>> >>>>>> - Section 6.3 states that n-casting is possible with the CN with some >>>>>> conditions, but section 7.1 simply forbids n-casting ("If the Action field >>>>>> indicates a request to n-cast the flow, the correspondent node MUST reject >>>>>> the >>>>>> option [...]") >>>>>> >>>>>> - Section 7.1: some notes on how the the flow binding is added to the >>>>>> binding >>>>>> cache should be written (existence of a BID sub-option in the BU, lookup >>> in >>>>>> the BCE with that BID, ...). Same comment for section 8.1 >>>>>> - This section and section 8.1 do not say what to do when a request to >>>>>> delete >>>>>> a flow is received. >>>>>> >>>>>> - Section 8.1: "the home agent MUST check for the presence of the BID sub- >>>>>> option(s)." -> actually section 3.2 does not mandate the presence of the >>> BID >>>>>> sub-options if the BID already exists in the BCE ("A BID sub-option is not >>>>>> necessarily included in the same BU [...]"). If the BID does not exist yet >>>>>> in >>>>>> the BCE or if no BID sub-options are present, then this is an error case. >>>>>> - "If one or more BIDs are present in the BID Reference sub-option" -> >>>>>> Binding >>>>>> Reference sub-option >>>>>> - The following procedure is too complex IMHO: >>>>>> >>>>>> If only one BID were >>>>>> included in the Binding Reference sub-option and it pointed to a >>>>>> different care-of address from the one included in the packet, >>>>>> then packets matching the flow would be bicast to those two >>>>>> addresses. >>>>>> >>>>>> Especially because the BU may be sent using another source address than >>> the >>>>>> one expected for n-casting. Why not just forbid this case and explicitly >>> ask >>>>>> for at least 2 BIDs in the binding reference sub-option? >>>>>> >>>>> Agree on this as I mentioned in my review of the draft >>>>> >>>>> Gerardo >>>>> >>>>>> - I think it was already raised, but the document lacks some text on what >>>>>> status code should be used upon error (section 7.1, 8.1, ...) and how such >>>>>> error code should be treated on the receiver side. >>>>>> >>>>>> - Section 8.2: this section make me think that the section talking about >>> the >>>>>> MN side does not say what should be done when the BAck is not received >>>>>> >>>>>> - Section 10: "associate some flows to an interface and other flows to >>>>>> another >>>>>> interface": I would replace "interface" with "CoA" >>>>>> >>>>>> >>>>>> * Some editorial comments: >>>>>> >>>>>> The document is inconsistent on how "Binding Update" / "Binding >>>>>> Acknowledgement" / "Flow Identification" / "Flow Binding" / "Flow >>>>>> Description" >>>>>> / "N-cast" are written (the first letter is sometimes lower case, >>> sometimes >>>>>> upper case) >>>>>> >>>>>> Page 11: dsecription -> description >>>>>> Page 15: Acknwoledgement -> Acknowledgement Page 22: Correspondant -> >>>>>> Correspondent Page 23: authrozied -> authorized >>>>>> >>>>>> >>>>>> >>>>>> Cheers, >>>>>> -- >>>>>> Romain KUNTZ >>>>>> kuntz@lsiit.u-strasbg.fr >>>>>> LSIIT - Networks and Protocols Team >>>>>> http://clarinet.u-strasbg.fr/~kuntz/ >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Nov 27 18:52:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B52E3A68E8; Thu, 27 Nov 2008 18:52:50 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3C823A68E8 for ; Thu, 27 Nov 2008 18:52:48 -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 lqAweuRpweur for ; Thu, 27 Nov 2008 18:52:48 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id E456D3A677E for ; Thu, 27 Nov 2008 18:52:46 -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 1L5tTD-00082O-Ou; Fri, 28 Nov 2008 13:52:40 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Fri, 28 Nov 2008 13:52:32 +1100 From: Hesham Soliman To: Benjamin Lim Message-ID: Thread-Topic: [MEXT] Questions on draft-ietf-mext-flow-binding-00 Thread-Index: AclRBFvhv1c3AUXQEUqt5tffPEhzOQ== In-Reply-To: <492F51A1.40900@sg.panasonic.com> Mime-version: 1.0 Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Questions on draft-ietf-mext-flow-binding-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I think that's way too messy to include in this draft. Policy is a completely different beast and is not necessarily based on a flow descriptor. This should be done properly in a separate draft I think. There is a lot of work out there that can be reused. I also would do this using something like XML. This is not something that needs to be updated regulary or has any relationship to movement. Hesham On 28/11/08 1:04 PM, "Benjamin Lim" wrote: > Hi Hesham & Julien, > > For clarification, if some policy decision that are done on the HA/MAP > that influence how MN/MR should send uplink traffic, can HA/MAP use the > FID option to set these routing rules on the MN/MR? > > If the mechanisms is similar, can we add some text in the introduction > section (2nd last paragraph) stating that the FID option can also be > sent from HA/MAP to MN/MR. > > What do you think? > > Regards, > Benjamin Lim > > Hesham Soliman wrote: >> Hi Julien, >> >> This draft doesn't deal with "Policy exchange". Policy exchange does >> something like the following: >> >> - If 802.11b AND port 80 then use 802.11b >> - if VoIP then use 3G >> ....etc >> This draft deals with exchanging the routing information, based on policy >> decisions that were done by the MN/MR. >> There were other draft proposing XML policies be exchanged between the >> MN/HA. They're orthogonal to this draft. >> >> Also, the draft deals with MN-CN relationships already in the same way that >> it deals with the MN-HA relationship. >> >> Hesham >> >> >> On 27/11/08 10:53 PM, "Julien Laganier" >> wrote: >> >>> Hello Hesham & all, >>> >>> I got some high-level questions on the draft. >>> >>> The text of the flow binding deliverable text in our charter says: >>> A "Flow/binding policies exchange" solution for an exchange of policies >>> from the mobile host/router to the Home Agent and from the Home Agent >>> to the mobile host/router influencing the choice of the Care-of Address >>> and Home Agent address. >>> >>> I am not 100% sure of my interpretation of the above, but I read it as >>> if it should be possible for either of the mobile node/router or the >>> home agent to initiate the flow/binding policies exchange. Is that >>> appropriate? >>> >>> If yes, am I understanding right that your draft only address an >>> exchange of policies from the mobile host/router to the home agent? >>> >>> If yes, wouldn't it make sense to also support the exchange of policies >>> initiated by the home agent, i.e. from the home agent to the mobile >>> host/router, as I understand our charter says? >>> >>> Orthognoal to that, I've got a dummy question: Why is flow/binding >>> policy exchange only considered between MN/MR and HA and excludes >>> flow/binding policy exchange between MN/MR and a correspondent node? Is >>> it because one can't assume an arbitrary CN supports these extensions? >>> >>> Thanks. >>> >>> --julien >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 28 01:39:32 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CFB63A682F; Fri, 28 Nov 2008 01:39:32 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37DC53A682F for ; Fri, 28 Nov 2008 01:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 AxSA-9Q0uFZt for ; Fri, 28 Nov 2008 01:39:30 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 6C6103A677C for ; Fri, 28 Nov 2008 01:39:29 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so536732eyd.31 for ; Fri, 28 Nov 2008 01:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=jfQEQofGs4UQIxsBW2WYqtEYo5T9cSgNE+Bm6xsbpHw=; b=bBY0g3HZAoElgLsQOQ31VnzPLBv8ivHbnr5cRYcCJ78SKKgTduYSAy/qOumER02jVn vfEAWk6tQVMZtf2TbvPP7lf/ZqrbWzlOvzDI1/AI0P6DWMTabWWPLl8e3M6qqQaFoFuh EILQq4+nF8gFrZCsFGFEmyz1AJ6c2K9OudYfc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:cc:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id:from; b=jaKHvtES30QWk2Plxfn3895EDUmXRc/3kaddJqshKb1DDz1hS/ZQi5CdTSA517jLjd fKcXna+mImndGH2WCdFpQdgV2MGB26qvA/bAWp8LIYQZrstvHbVk/QqkWZ3dFskCkTNN Wjjf6bMmw60//n+PK0z9xbkwkg8paFmBHpksE= Received: by 10.210.125.13 with SMTP id x13mr3277760ebc.144.1227865164966; Fri, 28 Nov 2008 01:39:24 -0800 (PST) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id g9sm597280gvc.31.2008.11.28.01.39.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 28 Nov 2008 01:39:23 -0800 (PST) To: Hesham Soliman Date: Fri, 28 Nov 2008 10:39:17 +0100 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200811281039.18769.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: mext@ietf.org Subject: Re: [MEXT] Questions on draft-ietf-mext-flow-binding-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, Maybe I shouldn't have used the term policy exchange. I understand the CN can be involved too, that's good. How about the home agent initiating a routing information exchange towards the MN - that doesn't seem to be supported by the draft... --julien On Thursday 27 November 2008, Hesham Soliman wrote: > Hi Julien, > > This draft doesn't deal with "Policy exchange". Policy exchange does > something like the following: > > - If 802.11b AND port 80 then use 802.11b > - if VoIP then use 3G > ....etc > This draft deals with exchanging the routing information, based on > policy decisions that were done by the MN/MR. > There were other draft proposing XML policies be exchanged between > the MN/HA. They're orthogonal to this draft. > > Also, the draft deals with MN-CN relationships already in the same > way that it deals with the MN-HA relationship. > > Hesham > > > On 27/11/08 10:53 PM, "Julien Laganier" > > wrote: > > Hello Hesham & all, > > > > I got some high-level questions on the draft. > > > > The text of the flow binding deliverable text in our charter says: > > A "Flow/binding policies exchange" solution for an exchange of > > policies from the mobile host/router to the Home Agent and from the > > Home Agent to the mobile host/router influencing the choice of the > > Care-of Address and Home Agent address. > > > > I am not 100% sure of my interpretation of the above, but I read it > > as if it should be possible for either of the mobile node/router or > > the home agent to initiate the flow/binding policies exchange. Is > > that appropriate? > > > > If yes, am I understanding right that your draft only address an > > exchange of policies from the mobile host/router to the home agent? > > > > If yes, wouldn't it make sense to also support the exchange of > > policies initiated by the home agent, i.e. from the home agent to > > the mobile host/router, as I understand our charter says? > > > > Orthognoal to that, I've got a dummy question: Why is flow/binding > > policy exchange only considered between MN/MR and HA and excludes > > flow/binding policy exchange between MN/MR and a correspondent > > node? Is it because one can't assume an arbitrary CN supports these > > extensions? > > > > Thanks. > > > > --julien -- --julien [ New email address: julien.laganier.IETF@googlemail.com ] _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 28 01:47:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFFD03A6A95; Fri, 28 Nov 2008 01:47:52 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CBA73A6AA5 for ; Fri, 28 Nov 2008 01:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 xUBOErGBz+NP for ; Fri, 28 Nov 2008 01:47:50 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 73BED3A6A27 for ; Fri, 28 Nov 2008 01:47:49 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1L5zwr-0002nq-0W; Fri, 28 Nov 2008 20:47:45 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Fri, 28 Nov 2008 20:47:19 +1100 From: Hesham Soliman To: Julien Laganier Message-ID: Thread-Topic: Questions on draft-ietf-mext-flow-binding-00 Thread-Index: AclRPk2wUIt8XP/ALEetIMMFfYctOw== In-Reply-To: <200811281039.18769.julien.laganier.IETF@googlemail.com> Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] Questions on draft-ietf-mext-flow-binding-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, > Hi Hesham, > > Maybe I shouldn't have used the term policy exchange. > > I understand the CN can be involved too, that's good. > > How about the home agent initiating a routing information exchange > towards the MN - that doesn't seem to be supported by the draft... => We discussed this in some detail in MIP6. The problem with this approach is that the HA can't possibly know what to recommend. In fact, the HA has no way of knowing if the recommended access point even works. It kind of goes against how MIPv6 works as well if the HA just changes routing by itself. If the HA only suggests a change of routing then it's a policy configuration :) So, I think the clean way to do this is to have a policy config mechanism that can be used by the HA to configure the MN. I'm sure we can reuse other work here and we shouldn't have to do this from scratch. Hesham > > --julien > > On Thursday 27 November 2008, Hesham Soliman wrote: >> Hi Julien, >> >> This draft doesn't deal with "Policy exchange". Policy exchange does >> something like the following: >> >> - If 802.11b AND port 80 then use 802.11b >> - if VoIP then use 3G >> ....etc >> This draft deals with exchanging the routing information, based on >> policy decisions that were done by the MN/MR. >> There were other draft proposing XML policies be exchanged between >> the MN/HA. They're orthogonal to this draft. >> >> Also, the draft deals with MN-CN relationships already in the same >> way that it deals with the MN-HA relationship. >> >> Hesham >> >> >> On 27/11/08 10:53 PM, "Julien Laganier" >> >> wrote: >>> Hello Hesham & all, >>> >>> I got some high-level questions on the draft. >>> >>> The text of the flow binding deliverable text in our charter says: >>> A "Flow/binding policies exchange" solution for an exchange of >>> policies from the mobile host/router to the Home Agent and from the >>> Home Agent to the mobile host/router influencing the choice of the >>> Care-of Address and Home Agent address. >>> >>> I am not 100% sure of my interpretation of the above, but I read it >>> as if it should be possible for either of the mobile node/router or >>> the home agent to initiate the flow/binding policies exchange. Is >>> that appropriate? >>> >>> If yes, am I understanding right that your draft only address an >>> exchange of policies from the mobile host/router to the home agent? >>> >>> If yes, wouldn't it make sense to also support the exchange of >>> policies initiated by the home agent, i.e. from the home agent to >>> the mobile host/router, as I understand our charter says? >>> >>> Orthognoal to that, I've got a dummy question: Why is flow/binding >>> policy exchange only considered between MN/MR and HA and excludes >>> flow/binding policy exchange between MN/MR and a correspondent >>> node? Is it because one can't assume an arbitrary CN supports these >>> extensions? >>> >>> Thanks. >>> >>> --julien > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 28 02:05:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49113A6AB4; Fri, 28 Nov 2008 02:05:28 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762AC3A6AB5 for ; Fri, 28 Nov 2008 02:05:27 -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 G3hycz5cNBbF for ; Fri, 28 Nov 2008 02:05:26 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by core3.amsl.com (Postfix) with ESMTP id 289983A6AA3 for ; Fri, 28 Nov 2008 02:05:25 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b11so736179nfh.39 for ; Fri, 28 Nov 2008 02:05:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=6BdCKmfXiLVbbWGm2bJOyqDJWwTa7UNyHJZBshvzhXA=; b=jxv1/90PXlxGZu+9umGADVAUU8Nc0zOY5cOfEDfqVY+nf1GEagkVYLq+eURUOUKfGN nmHOS4S4QtPXNJD4qfSpGD+2TzUjNRLZsIYiBpVueMkg3NPSLzz085GQZhuDvh1KNL/2 5QFhRHX93SZBoVb99rffTsXWdlX2gGk43iAog= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:cc:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id:from; b=hMrYjbM30g+U6i8A5InQLiyam6/xrUWr8LScCvj1Xr9mVvoV5scovArluV6t37etTN lvvmdUGaCiM0ohYHOHI0FItFwao+44xHPJ51idubYmE2mx2d+L/e8p4lhVTY4Wdcziyu bo2bmreIxq6dSY8Nn8GTLppF9lxKntQnui3/s= Received: by 10.210.58.17 with SMTP id g17mr8582066eba.130.1227866722464; Fri, 28 Nov 2008 02:05:22 -0800 (PST) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id i6sm1274962gve.2.2008.11.28.02.05.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 28 Nov 2008 02:05:21 -0800 (PST) To: Hesham Soliman Date: Fri, 28 Nov 2008 11:05:13 +0100 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200811281105.14315.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: mext@ietf.org Subject: Re: [MEXT] Questions on draft-ietf-mext-flow-binding-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Thanks for the explanation Hesham. I understand the situation better now. --julien On Friday 28 November 2008, Hesham Soliman wrote: > Hi Julien, > > > Hi Hesham, > > > > Maybe I shouldn't have used the term policy exchange. > > > > I understand the CN can be involved too, that's good. > > > > How about the home agent initiating a routing information exchange > > towards the MN - that doesn't seem to be supported by the draft... > > => We discussed this in some detail in MIP6. The problem with this > approach is that the HA can't possibly know what to recommend. In > fact, the HA has no way of knowing if the recommended access point > even works. It kind of goes against how MIPv6 works as well if the HA > just changes routing by itself. If the HA only suggests a change of > routing then it's a policy configuration :) > > So, I think the clean way to do this is to have a policy config > mechanism that can be used by the HA to configure the MN. I'm sure we > can reuse other work here and we shouldn't have to do this from > scratch. > > Hesham > > > --julien > > > > On Thursday 27 November 2008, Hesham Soliman wrote: > >> Hi Julien, > >> > >> This draft doesn't deal with "Policy exchange". Policy exchange > >> does something like the following: > >> > >> - If 802.11b AND port 80 then use 802.11b > >> - if VoIP then use 3G > >> ....etc > >> This draft deals with exchanging the routing information, based on > >> policy decisions that were done by the MN/MR. > >> There were other draft proposing XML policies be exchanged between > >> the MN/HA. They're orthogonal to this draft. > >> > >> Also, the draft deals with MN-CN relationships already in the same > >> way that it deals with the MN-HA relationship. > >> > >> Hesham > >> > >> > >> On 27/11/08 10:53 PM, "Julien Laganier" > >> > >> wrote: > >>> Hello Hesham & all, > >>> > >>> I got some high-level questions on the draft. > >>> > >>> The text of the flow binding deliverable text in our charter > >>> says: A "Flow/binding policies exchange" solution for an exchange > >>> of policies from the mobile host/router to the Home Agent and > >>> from the Home Agent to the mobile host/router influencing the > >>> choice of the Care-of Address and Home Agent address. > >>> > >>> I am not 100% sure of my interpretation of the above, but I read > >>> it as if it should be possible for either of the mobile > >>> node/router or the home agent to initiate the flow/binding > >>> policies exchange. Is that appropriate? > >>> > >>> If yes, am I understanding right that your draft only address an > >>> exchange of policies from the mobile host/router to the home > >>> agent? > >>> > >>> If yes, wouldn't it make sense to also support the exchange of > >>> policies initiated by the home agent, i.e. from the home agent to > >>> the mobile host/router, as I understand our charter says? > >>> > >>> Orthognoal to that, I've got a dummy question: Why is > >>> flow/binding policy exchange only considered between MN/MR and HA > >>> and excludes flow/binding policy exchange between MN/MR and a > >>> correspondent node? Is it because one can't assume an arbitrary > >>> CN supports these extensions? > >>> > >>> Thanks. > >>> > >>> --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 28 03:54:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD27D3A6B8A; Fri, 28 Nov 2008 03:54:47 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B65353A6994 for ; Fri, 28 Nov 2008 03:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 81mXx+vOO8oU for ; Fri, 28 Nov 2008 03:54:46 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id D778D3A6809 for ; Fri, 28 Nov 2008 03:54:45 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-153.messagelabs.com!1227873281!11432495!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 11651 invoked from network); 28 Nov 2008 11:54:42 -0000 Received: from unknown (HELO motgate3.mot.com) (136.182.1.13) by server-4.tower-153.messagelabs.com with SMTP; 28 Nov 2008 11:54:42 -0000 Received: from il27exr02.cig.mot.com (il27exr02.mot.com [10.17.196.71]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id mASBsbeM010747 for ; Fri, 28 Nov 2008 04:54:41 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr02.cig.mot.com (8.13.1/Vontu) with SMTP id mASBsb4d019139 for ; Fri, 28 Nov 2008 05:54:37 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il27exr02.cig.mot.com (8.13.1/8.13.0) with ESMTP id mASBsa3E019111 for ; Fri, 28 Nov 2008 05:54:36 -0600 (CST) Message-ID: <492FDBF8.9010203@gmail.com> Date: Fri, 28 Nov 2008 12:54:32 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: mext X-Antivirus: avast! (VPS 081127-1, 27/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Subject: [MEXT] Put it straight (draft-ietf-mext-nemo-ro-automotive-req-01.txt) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org MEXTers, Let's first make one thing straight about draft-ietf-mext-nemo-ro-automotive-req-01.txt. Are the requirements written such as the RO vehicular design uses Correspondent Routers as mentioned in draft-bernardos-mext-nemo-ro-cr-00 and in draft-wakikawa-mext-cr-consideration-0? This text in the RO-automotive draft makes think so: > With respect to the classification of NEMO Route Optimization > scenarios described in [RFC4889], the non-nested NEMO RO case > (Section 3.1) is considered as the most important for the automotive > deployment. rfc4889 section 3.1: > The Non-Nested NEMO Route Optimization involves a Mobile Router > sending binding information to a Correspondent Entity. [...] The > Correspondent Entity can be a Correspondent Node or a Correspondent > Router. The interesting case is when the Correspondent Entity is a > Correspondent Router. With the use of Correspondent Router, Route > Optimization session is terminated at the Correspondent Router on > behalf of the Correspondent Node. As long as the Correspondent > Router is located "closer" to the Correspondent Node than the Home > Agent of the Mobile Router, the route between Mobile Network Node and > the Correspondent Node can be said to be optimized. For this > purpose, Correspondent Routers may be deployed to provide an optimal > route as illustrated in Figure 1. Along the same lines: is the RO-vehicular technique designed following these requirements supposed to use Mobile IPv6 extensions? Like extending BUs/BAcks? Or can it use some other existing protocol as basis? Alex PS: I will provide comments separately on draft-ietf-mext-nemo-ro-automotive-req-01.txt but first let's clarify the above points. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 28 04:08:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBCE13A69EE; Fri, 28 Nov 2008 04:08:00 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A76E13A6994 for ; Fri, 28 Nov 2008 04:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 skTHcNmTZTGe for ; Fri, 28 Nov 2008 04:07:57 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 6D3463A69EE for ; Fri, 28 Nov 2008 04:07:57 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.147.182])by smtp01.uc3m.es (Postfix) with ESMTP id CDAEDACBA71; Fri, 28 Nov 2008 13:07:51 +0100 (CET) Message-ID: <492FDF16.7020708@it.uc3m.es> Date: Fri, 28 Nov 2008 13:07:50 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Alexandru Petrescu References: <492FDBF8.9010203@gmail.com> In-Reply-To: <492FDBF8.9010203@gmail.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-12.6515 TC:1F TRN:44 TV:5.5.1026(16306.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: mext Subject: Re: [MEXT] Put it straight(draft-ietf-mext-nemo-ro-automotive-req-01.txt) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alex, Alexandru Petrescu escribi=F3: > MEXTers, > > Let's first make one thing straight about = > draft-ietf-mext-nemo-ro-automotive-req-01.txt. > > Are the requirements written such as the RO vehicular design uses = > Correspondent Routers as mentioned in = > draft-bernardos-mext-nemo-ro-cr-00 and in = > draft-wakikawa-mext-cr-consideration-0? well a requirement doc should be neutral w.r.t. the solution In draft-bernardos, there is a RO correpsondetn entity, that performs = the RO fucntions in the CN side, which can be placed in different = device, including the CN itself, the HA or a new device, like the CR. I think that it is importnat to differentiate the fucntional entities = that are required in any solutions and the particular form and places = that these fucntions are placed in the different solutions > This text in the RO-automotive draft makes think so: >> With respect to the classification of NEMO Route Optimization >> scenarios described in [RFC4889], the non-nested NEMO RO case >> (Section 3.1) is considered as the most important for the automotive >> deployment. > rfc4889 section 3.1: >> The Non-Nested NEMO Route Optimization involves a Mobile Router >> sending binding information to a Correspondent Entity. [...] The >> Correspondent Entity can be a Correspondent Node or a Correspondent >> Router. The interesting case is when the Correspondent Entity is a >> Correspondent Router. With the use of Correspondent Router, Route >> Optimization session is terminated at the Correspondent Router on >> behalf of the Correspondent Node. As long as the Correspondent >> Router is located "closer" to the Correspondent Node than the Home >> Agent of the Mobile Router, the route between Mobile Network Node and >> the Correspondent Node can be said to be optimized. For this >> purpose, Correspondent Routers may be deployed to provide an optimal >> route as illustrated in Figure 1. > > Along the same lines: is the RO-vehicular technique designed following = > these requirements supposed to use Mobile IPv6 extensions? Like = > extending BUs/BAcks? Or can it use some other existing protocol as = > basis? > well, we are in mext, so we work on mip6 regards, marcelo > Alex > PS: I will provide comments separately on > draft-ietf-mext-nemo-ro-automotive-req-01.txt but first let's > clarify the above points. > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email = > ______________________________________________________________________ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 28 05:03:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B41BC3A6827; Fri, 28 Nov 2008 05:03:23 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5113A6827 for ; Fri, 28 Nov 2008 05:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 STfDClySKBBd for ; Fri, 28 Nov 2008 05:03:21 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with SMTP id 0A5263A67F5 for ; Fri, 28 Nov 2008 05:03:20 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1227877397!39267012!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 23607 invoked from network); 28 Nov 2008 13:03:17 -0000 Received: from unknown (HELO motgate3.mot.com) (136.182.1.13) by server-3.tower-119.messagelabs.com with SMTP; 28 Nov 2008 13:03:17 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id mASD3Gwa017867; Fri, 28 Nov 2008 06:03:16 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id mASD3Gx6004495; Fri, 28 Nov 2008 07:03:16 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id mASD3FRJ004475; Fri, 28 Nov 2008 07:03:15 -0600 (CST) Message-ID: <492FEC16.1020502@gmail.com> Date: Fri, 28 Nov 2008 14:03:18 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: marcelo bagnulo braun References: <492FDBF8.9010203@gmail.com> <492FDF16.7020708@it.uc3m.es> In-Reply-To: <492FDF16.7020708@it.uc3m.es> X-Antivirus: avast! (VPS 081127-1, 27/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext Subject: Re: [MEXT] Mobile IPv6 for car-to-car communications X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org marcelo bagnulo braun wrote: > Alex, > = > Alexandru Petrescu escribi=F3: >> MEXTers, >> = >> Let's first make one thing straight about = >> draft-ietf-mext-nemo-ro-automotive-req-01.txt. >> = >> Are the requirements written such as the RO vehicular design uses = >> Correspondent Routers as mentioned in = >> draft-bernardos-mext-nemo-ro-cr-00 and in = >> draft-wakikawa-mext-cr-consideration-0? > = > well a requirement doc should be neutral w.r.t. the solution I fully agree, but it does not seem the case with this requirements document. It assumes a Correspondent Router. > In draft-bernardos, there is a RO correpsondetn entity, that performs > the RO fucntions in the CN side, which can be placed in different = > device, including the CN itself, the HA or a new device, like the CR. > I think that it is importnat to differentiate the fucntional = > entities that are required in any solutions and the particular form = > and places that these fucntions are placed in the different solutions > = Extending the concept of RO correspondent entity, to a Correspondent Router and further to a Mobile Router is superfluous to me. If we need Mobile Router to Mobile Router communication we don't need to talk about Mobile Router being a Correspondent Router. It's simply Mobile Router to Mobile Router communication. >> Along the same lines: is the RO-vehicular technique designed = >> following these requirements supposed to use Mobile IPv6 = >> extensions? Like extending BUs/BAcks? Or can it use some other = >> existing protocol as basis? >> = > well, we are in mext, so we work on mip6 I don't think Mobile IPv6 is well adapted for car-to-car communications, without fixed infrastructure. Mobile IPv6 has many topological assumptions (a fixed HA, an often fixed CN) that make it difficult to use in a car-to-car communications. I believe car-to-car communications are a significant departure from Mobile IPv6. We can achieve car-to-car communications by using Mobile Router to Mobile Router communications by their egress interfaces and without using Mobile IPv6. If it is believed that Mobile IPv6 should be modified in order to achieve car-to-car communications then I fully disagree. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email = ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 28 05:56:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7028328C134; Fri, 28 Nov 2008 05:56:55 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5830828C134 for ; Fri, 28 Nov 2008 05:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 ItdhlcrrE8hk for ; Fri, 28 Nov 2008 05:56:53 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 4875628C0DB for ; Fri, 28 Nov 2008 05:56:52 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108])by smtp02.uc3m.es (Postfix) with ESMTP id B84745CBF03;Fri, 28 Nov 2008 14:56:47 +0100 (CET) Message-ID: <492FF89F.8030304@it.uc3m.es> Date: Fri, 28 Nov 2008 14:56:47 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Alexandru Petrescu References: <492FDBF8.9010203@gmail.com> <492FDF16.7020708@it.uc3m.es> <492FEC16.1020502@gmail.com> In-Reply-To: <492FEC16.1020502@gmail.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-7.1252 TC:1F TRN:44 TV:5.5.1026(16306.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: mext Subject: Re: [MEXT] Mobile IPv6 for car-to-car communications X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alexandru Petrescu escribi=F3: > marcelo bagnulo braun wrote: >> Alex, >> >> Alexandru Petrescu escribi=F3: >>> MEXTers, >>> >>> Let's first make one thing straight about = >>> draft-ietf-mext-nemo-ro-automotive-req-01.txt. >>> >>> Are the requirements written such as the RO vehicular design uses = >>> Correspondent Routers as mentioned in = >>> draft-bernardos-mext-nemo-ro-cr-00 and in = >>> draft-wakikawa-mext-cr-consideration-0? >> >> well a requirement doc should be neutral w.r.t. the solution > > I fully agree, but it does not seem the case with this requirements > document. It assumes a Correspondent Router. > >> In draft-bernardos, there is a RO correpsondetn entity, that performs >> the RO fucntions in the CN side, which can be placed in different = >> device, including the CN itself, the HA or a new device, like the CR. >> I think that it is importnat to differentiate the fucntional = >> entities that are required in any solutions and the particular form = >> and places that these fucntions are placed in the different solutions >> > Extending the concept of RO correspondent entity, to a Correspondent > Router and further to a Mobile Router is superfluous to me. If we need > Mobile Router to Mobile Router communication we don't need to talk about > Mobile Router being a Correspondent Router. It's simply Mobile Router > to Mobile Router communication. no, the correspondet router does not need to be mobile (like the CN does = not need to be mobile neither) > >>> Along the same lines: is the RO-vehicular technique designed = >>> following these requirements supposed to use Mobile IPv6 = >>> extensions? Like extending BUs/BAcks? Or can it use some other = >>> existing protocol as basis? >>> >> well, we are in mext, so we work on mip6 > > I don't think Mobile IPv6 is well adapted for car-to-car communications, > without fixed infrastructure. > ok, so i suggest you to go an propose your ideas in the wg that has a = protocol that according to you is well suited for car to car = communication, cause in this wg, we usually work on mip6 :-) regards, marcelo > Mobile IPv6 has many topological assumptions (a fixed HA, an often fixed > CN) that make it difficult to use in a car-to-car communications. > > I believe car-to-car communications are a significant departure from > Mobile IPv6. > > We can achieve car-to-car communications by using Mobile Router to > Mobile Router communications by their egress interfaces and without > using Mobile IPv6. > > If it is believed that Mobile IPv6 should be modified in order to > achieve car-to-car communications then I fully disagree. > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email = > ______________________________________________________________________ > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 28 06:15:23 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A95373A6878; Fri, 28 Nov 2008 06:15:23 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 516BE3A6878 for ; Fri, 28 Nov 2008 06:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-1.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 ZGzjJbMsvsab for ; Fri, 28 Nov 2008 06:15:21 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with SMTP id D47F83A67F5 for ; Fri, 28 Nov 2008 06:15:20 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1227881716!31744965!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 3099 invoked from network); 28 Nov 2008 14:15:17 -0000 Received: from unknown (HELO motgate4.mot.com) (136.182.1.14) by server-8.tower-119.messagelabs.com with SMTP; 28 Nov 2008 14:15:17 -0000 Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id mASEFG3f003834 for ; Fri, 28 Nov 2008 07:15:16 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id mASEFGr8019330 for ; Fri, 28 Nov 2008 08:15:16 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id mASEFFSM019324 for ; Fri, 28 Nov 2008 08:15:16 -0600 (CST) Message-ID: <492FFCF2.7020400@gmail.com> Date: Fri, 28 Nov 2008 15:15:14 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: mext X-Antivirus: avast! (VPS 081127-1, 27/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Subject: [MEXT] Comments on draft-ietf-mext-nemo-ro-automotive-req-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello MEXTers, I would like to offer comments on draft-ietf-mext-nemo-ro-automotive-req-01.txt. I find it very readable and concise, well-formed. I think we need this document. I have some hopefully improving comments. I think it would make sense to try to talk somewhere in the document about IP-over-foo-technology. It may give a good accompanying perspective to the architecture-uses-IPv6 perspective currently described. It's very relevant to talk about IPv6-over-802.11p in a document mentioning 802.11p and IPv6 several times. Nit: page 5, 'composed of' is better than 'composed by'. Still in the Terminology section, right after V2I definition, it would be good to add V2I2V definition (vehicle to infra to vehicle), term used later in the document; I think the scenario is very relevant. Figure 1: 'Mod IEEE 802.11p Interface'? What does Mod mean? I could read it easily if it said 'Modified' or its abbreviation "Mod'ed". But 'Mod' sounds too abbreviated :-) Page 11: > o according to the current availability of infrastructure > connectivity, OBUs can use (at least) 2 types of globally routable > IPv6 addresses: an IPv6 address configured using standard IPv6 > stateless address configuration from Router Advertisements sent by > RSUs connected to a network infrastructure and an IPv6 address > configured from a prefix permanently allocated to the vehicle and > delegated to the vehicle from a home network. The former globally > routable IPv6 address is used as the NEMO Care-of Address (CoA) and > the latter as the NEMO Home Address (HoA). For the second case, MR's Home Address derived from MNP. One would make sure to clarify that this behaviour is not standard NEMOv6, needs tweaks on the MR and on the HA, as mentioned in section 5.3 "Home Address from MNP" of RFC 4887 "Home Network Models". > o for V2V communication, i.e. when no infrastructure is available, > OBUs can use link-local addresses (default ones or with a C2C-CC > specific prefix TBD). As described above, a portion of the VANET > (geographically or topologically scoped) is presented to IPv6 as a > single, link-local multicast link. Therefore the link-local address > can be used for multi-hop communications within the VANET; First, can there be an IPv6 link-local address with a prefix other than fe80? (as suggested above by "C2C-CC specific prefix TBD"). Shouldn't this be agreed by the IPv6-related WG - or maybe that's why it's mentioned TBD? Second, what is understood by 'multi-hop communications'? In my understanding, 'multi-hop' is like Internet is multi-hop and IP datagrams travel from hop to hop and have their TTL decremented at each hop. In this sense, if the VANET is presented to IPv6 a single link-local multicast link then it is not multi-hop - the TTL is not decremented throughout this link. Third, whereas it is indeed possible to have two OBUs (On-Board Units, MRs) to talk to each other by using their link-local addresses, it is not possible for the AUs (Applicatin Units, LFNs) to talk to each other even if their respective OBUs used their link-local addresses to talk to each other. In this sense, I wouldn't say "Therefore the link-local address can be used for multi-hop communications within the VANET". Can I simply suggest: "Two OBUs can communicate directly through their respective egress interfaces by using their IPv6 link-local addresses. But their respective AUs can not take advantage of this possibility." Nit: 'divided' is better than 'devided', page 10. Section 3.2.1 "System and Protocol Architecture" first paragraph starting with "Vehicles are equipped with..." is identical to first paragraph of page 7. Possibly subsequent paragraphs are identical as well. I think it's redundant text between the C2C-CC and ISO CALM sections. The reader has already read the C2C-CC part, so now it would make sense to simply state the differences. Similarly, Figures 1 and 3 are almost identical, with the only difference being the presence of an optional interface on OBU1. It's hard to spot that difference - better stress it in the text. Figure 4 - what's 2G/3G GSM and CALM IR? Whereas most acronyms in the figure are explained ok in the text, these two aren't, and the reader may need to have a grasp on these. For example, is CALM IR Infra-red? > This block comprises the NME (Network Management Entity) which is > able to interoperate with other layers in order to negociate priority > flow requirements Nit: dot missing at the end of paragraph. Also, what is NME (Network Management Entity)? This is the sole time this term is mentioned, and with its acronym - what does it mean, why is it here? > o in order to avoid address resolution procedures, vehicles use only > IPv6 addresses with as host part an EUI-64 identifier derived from > the MAC address. Privacy issues described in [...] I think it would be better to say "Interface Identifier" instead of 'host part'. At the same time, if we take figure 4 into consideration where 2G/3G GSM networks are used instead of 802 networks, then MAC addresses are not available, but Interface Identifier yes, if IPv6 with PPP is being used. Thus I could suggest a rephrasing if you agree. > 2 types of globally routable IPv6 addresses: an IPv6 address > configured using standard IPv6 stateless address configuration from > Router Advertisements sent by RSUs connected to a network > infrastructure and an IPv6 address configured from a prefix > permanently allocated to the vehicle and delegated to the vehicle > from a home network. The former globally routable IPv6 address is > used as the NEMO Care-of Address (CoA) and the latter as the NEMO > Home Address (HoA). This again sounds as a duplicate of a paragraph on page 10, so my remarks on that paragraph (cite section 5.3 of rfc4887) apply here as well. > In addition, a self-generated IPv6 address with as prefix part a > pre-defined IPv6 prefix (either reserved for ISO CALM communications > or a general purpose one) may be used for ad-hoc communications with > other OBUs; What does 'self-generated' mean? A novel method of running IPv6-over-foo method of generating addresses, like IPv6-over-CALM? Or using stateless autoconf? Or using DHCP? Maybe any of these three? Maybe none of these three? > o RSUs can either act as IPv6 Access Routers or as bridges connected > to external IPv6 Access Routers. Different Access Routers are > responsible for announcing different network prefixes with global > validity. As a consequence, when roaming between different Access > Routers, vehicles experience layer 3 handovers. This again sounds as copypaste of something I read earlier. Is it intentional? > 4.4. Vehicles Monitoring > > Vehicles monitoring services allow car manufacturers, car garages and > other trusted parties to remotely monitor vehicle statistics. Data > is collected by an AU and sent by the OBU to the service center via > the Internet. > > As an example, car manufacturers or garages offering this service > could deploy NEMO Home Agents to serve thousands of cars. I agree with the application and example use case. However, I don't think NEMO protocol is adapted for this. For example, in the above paragraph, was the intention to say that NEMO Home Agents will receive monitored data from the thousands of cars? That's what is implied by the text. The NEMO HA would only be involved in managing the mobility, and not in monitoring the data. Another CN would be receiving the monitored data, from OBU (and probably from AU actually). HA would be there simply to deal with the mobility of the OBU. I am not sure what is the intention of the above paragraph, but I would clarify in order to avoid confusions of believing HA monitors data. > 4.5. Infotainment Applications > > TBD by ISO CALM > > 4.6. Navigation Services > > TBD by ISO CALM I suppose this is to be defined? > The requirements defined in this document refer to RO between MR and > CE (Correspondent Entity). According to the automotive use cases, > the CE can be: > > 1. Another vehicle, i.e. another automotive MR. I suggest call it RO between MR and MR. Or maybe RO between OBU and OBU. But introducing the term CE is unnecessary. > In cases 1 and 2, the CE is a newly deployed entity. It's not new, it's the MR, or the OBU. BEtter call it MR or OBU, rather than CE. Nit: 'occur' is better than 'occour'. Nit: 'known in advance to the MR' is better than 'known in advanced to the MR' > 6.1. Req 1 - Separability > > An RO technique, including its establishment procedure, MUST have the > ability to be enabled on a per-flow basis according to pre-defined > policies. Policies criteria for the switching to RO MUST at least > include the end points' addresses and the MNP for which RO is to be > established. Policies MAY change dynamically. > Before Req 1 I would suggest Req 0 'Reusability' to reuse an existing protocol. For req 1, I don't understand 'per-flow' - what's a flow? Does it use the flow label in the IPv6 header? Or is it another newly defined term? Nit: 'This requirement' is better than 'This requirements' Nit: 'unveil' or 'reveal' are both better than 'unveal'. > 6.6. Req 6 - Switching HA > > An RO technique MUST allow a MR to switch from one HA to another one > topologically distant from the first one. This sounds either as an incomplete requirement (subsequent text doesn't contribute to completeness, just to over-generalization) or as a non-requirement at all. A requirement would be for MR to switch to another HA while keeping its existing HoAs and CoAs. That is a requirement, probably difficult to satisfy. I'd agree list it as requirement, but only if it were qualified by that 'keep its HoAs and CoAs'. > [c2ccc-manifesto] > "Car2Car Communication Consortium Manifesto", > http://www.car-2-car.org/index.php?id=570 , May 2007. When I click on the link it says "TYP03 Error! The requested page does not exist!" > [calm-handbook] > "The CALM Handbook", http://www.calm.hu , May 2005. I can't find a Handbook on this page - where is it more precisely? Thank you. > [ISO-21210-CALM-IPv6-Networking] > "Intelligent Transport Systems - Continuous air interface, > long and medium range (CALM) - Networking Protocols", ISO > Draft DIS 21210, February 2008. Where is this document? > [ISO-21217-CALM-Architecture] > "Intelligent Transport Systems - Communications access for > land mobiles (CALM) - Architecture", ISO Draft DIS 21217, > June 2008. Where is this document? > [IEEE.802-11p-d3-0] > "Draft Amendment to Standard for Information Technology . > Telecommunications and information exchange between > systems . Local and Metropolitan networks . Specific > requirements - Part 11: Wireless LAN Medium Access Control > (MAC) and Physical Layer (PHY) specifications: Amendment > 3: Wireless Access in Vehicular Environments (WAVE)", > IEEE P802.11p/D1.0, February 2006. Where is this document? Thanks, Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 28 06:24:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966873A6BBB; Fri, 28 Nov 2008 06:24:35 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9213A67F5 for ; Fri, 28 Nov 2008 06:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 u0LyPSSiHbvt for ; Fri, 28 Nov 2008 06:24:33 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id CBE343A6BBA for ; Fri, 28 Nov 2008 06:24:32 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1227882268!8023374!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16955 invoked from network); 28 Nov 2008 14:24:28 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-153.messagelabs.com with SMTP; 28 Nov 2008 14:24:28 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mASEOPhf025442; Fri, 28 Nov 2008 07:24:26 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id mASEOPnn011380; Fri, 28 Nov 2008 08:24:25 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id mASEOOqT011371; Fri, 28 Nov 2008 08:24:24 -0600 (CST) Message-ID: <492FFF17.3010508@gmail.com> Date: Fri, 28 Nov 2008 15:24:23 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: marcelo bagnulo braun References: <492FDBF8.9010203@gmail.com> <492FDF16.7020708@it.uc3m.es> <492FEC16.1020502@gmail.com> <492FF89F.8030304@it.uc3m.es> In-Reply-To: <492FF89F.8030304@it.uc3m.es> X-Antivirus: avast! (VPS 081127-1, 27/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext Subject: Re: [MEXT] Mobile IPv6 for car-to-car communications X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org marcelo bagnulo braun wrote: [...] >> Extending the concept of RO correspondent entity, to a >> Correspondent Router and further to a Mobile Router is superfluous >> to me. If we need Mobile Router to Mobile Router communication we >> don't need to talk about Mobile Router being a Correspondent >> Router. It's simply Mobile Router to Mobile Router communication. > > no, the correspondet router does not need to be mobile (like the CN > does not need to be mobile neither) Marcelo why do we need to talk about a Correspondent Router when we talk Mobile Router to Mobile Router communication? >> I don't think Mobile IPv6 is well adapted for car-to-car >> communications, without fixed infrastructure. >> > ok, so i suggest you to go an propose your ideas in the wg that has a > protocol that according to you is well suited for car to car > communication, cause in this wg, we usually work on mip6 :-) Note taken. I take this as a Chair indication to not touch other protocols when doing Mobile IPv6 for car-to-car communications (without infrastructure). Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 28 06:34:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5205F28C133; Fri, 28 Nov 2008 06:34:54 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A550B28C133 for ; Fri, 28 Nov 2008 06:34:53 -0800 (PST) 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=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzzVoic91FOu for ; Fri, 28 Nov 2008 06:34:52 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id 3497D28C101 for ; Fri, 28 Nov 2008 06:34:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,682,1220220000"; d="vcf'?scan'208";a="17739069" Received: from dhcp-rocq-163.inria.fr ([128.93.62.163]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Nov 2008 15:34:47 +0100 Message-ID: <49300187.1080409@inria.fr> Date: Fri, 28 Nov 2008 15:34:47 +0100 From: Thierry Ernst Organization: INRIA User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: marcelo bagnulo braun References: <492FDBF8.9010203@gmail.com> <492FDF16.7020708@it.uc3m.es> <492FEC16.1020502@gmail.com> <492FF89F.8030304@it.uc3m.es> In-Reply-To: <492FF89F.8030304@it.uc3m.es> Content-Type: multipart/mixed; boundary="------------000602090007070203050503" Cc: mext Subject: Re: [MEXT] Mobile IPv6 for car-to-car communications X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------000602090007070203050503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit marcelo bagnulo braun wrote: > Alexandru Petrescu escribió: >> marcelo bagnulo braun wrote: >>> Alex, >>> >>> Alexandru Petrescu escribió: >>>> MEXTers, >>>> >>>> Let's first make one thing straight about >>>> draft-ietf-mext-nemo-ro-automotive-req-01.txt. >>>> >>>> Are the requirements written such as the RO vehicular design uses >>>> Correspondent Routers as mentioned in >>>> draft-bernardos-mext-nemo-ro-cr-00 and in >>>> draft-wakikawa-mext-cr-consideration-0? >>> >>> well a requirement doc should be neutral w.r.t. the solution >> >> I fully agree, but it does not seem the case with this requirements >> document. It assumes a Correspondent Router. The document is using the established NEMO Terminology (RFC 4885) and CR is corresponding to section 2.9. Correspondent Router (CR) . . . . . . . . . . . . . . . . 7 of RFC 4885. Actually, draft-ietf-mext-nemo-ro-automotive-req-01.txt is mostly using the term CE (Correspondent Entity) which is by nature neutral (could be fixed or mobile): in the automotive use-case we are dealing with scenarios where we really mean MR to MR communications which must be optimized; and there are also other scenarios where we want to optimize communications between a MR and a nearby CN. There could be one solution for the two cases, or a common solution. For a specific MR-MR solution it doesn't make sense to use the term CR. >> >>> In draft-bernardos, there is a RO correpsondetn entity, that performs >>> the RO fucntions in the CN side, which can be placed in different >>> device, including the CN itself, the HA or a new device, like the CR. >>> I think that it is importnat to differentiate the fucntional >>> entities that are required in any solutions and the particular form >>> and places that these fucntions are placed in the different solutions >>> >> Extending the concept of RO correspondent entity, to a Correspondent >> Router and further to a Mobile Router is superfluous to me. If we need >> Mobile Router to Mobile Router communication we don't need to talk about >> Mobile Router being a Correspondent Router. It's simply Mobile Router >> to Mobile Router communication. > no, the correspondet router does not need to be mobile (like the CN > does not need to be mobile neither) Agree. > >> >>>> Along the same lines: is the RO-vehicular technique designed >>>> following these requirements supposed to use Mobile IPv6 >>>> extensions? Like extending BUs/BAcks? Or can it use some other >>>> existing protocol as basis? >>>> >>> well, we are in mext, so we work on mip6 >> >> I don't think Mobile IPv6 is well adapted for car-to-car communications, >> without fixed infrastructure. One has to understand that cars may be once in an infrastructure-less situation and once in an infrastructure-based situation and they also must be reachable at a permanent address (therefore IPv6 and NEMO). ITS architectures are designed in a way both are supported (so, there could be different solutions but they have to co-exist in a single architecture). >> > ok, so i suggest you to go an propose your ideas in the wg that has a > protocol that according to you is well suited for car to car > communication, cause in this wg, we usually work on mip6 :-) > > regards, marcelo > >> Mobile IPv6 has many topological assumptions (a fixed HA, an often fixed >> CN) that make it difficult to use in a car-to-car communications. >> >> I believe car-to-car communications are a significant departure from >> Mobile IPv6. >> >> We can achieve car-to-car communications by using Mobile Router to >> Mobile Router communications by their egress interfaces and without >> using Mobile IPv6. >> >> If it is believed that Mobile IPv6 should be modified in order to >> achieve car-to-car communications then I fully disagree. Alex has a point indeed, but may be not the background. Car-to-Car communication would both need an NEMO-type of solution (with HA, CoA, etc - note that I avoided to use Mobile IPv6 because we need to support in-vehicle networks) which is optimized for car-to-car communications and an MANET-type of solution where there is no HA. The first has to be dealt with MEXT, the second possibly with Autoconf. Thierry --------------000602090007070203050503 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA Rocquencourt;IMARA - LARA adr:;;;;;;France tel;work:+33 1 39 63 59 30 tel;fax:+33 1 39 63 54 91 tel;cell:+33 6 76 56 25 96 url:http://www.lara.prd.fr version:2.1 end:vcard --------------000602090007070203050503 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --------------000602090007070203050503-- From mext-bounces@ietf.org Fri Nov 28 06:35:09 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BD633A6BBC; Fri, 28 Nov 2008 06:35:09 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E89743A6B74 for ; Fri, 28 Nov 2008 06:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 VoG6C0MN+ls7 for ; Fri, 28 Nov 2008 06:35:06 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id D00DC3A6BBF for ; Fri, 28 Nov 2008 06:35:03 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (wlap002.it.uc3m.es [163.117.139.44])by smtp01.uc3m.es (Postfix) with ESMTP id 58FEDACBA61; Fri, 28 Nov 2008 15:34:57 +0100 (CET) Message-ID: <49300191.1070707@it.uc3m.es> Date: Fri, 28 Nov 2008 15:34:57 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Alexandru Petrescu References: <492FDBF8.9010203@gmail.com> <492FDF16.7020708@it.uc3m.es> <492FEC16.1020502@gmail.com> <492FF89F.8030304@it.uc3m.es> <492FFF17.3010508@gmail.com> In-Reply-To: <492FFF17.3010508@gmail.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-8.8831 TC:1F TRN:38 TV:5.5.1026(16306.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: mext Subject: Re: [MEXT] Mobile IPv6 for car-to-car communications X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alexandru Petrescu escribi=F3: > marcelo bagnulo braun wrote: > [...] >>> Extending the concept of RO correspondent entity, to a Correspondent = >>> Router and further to a Mobile Router is superfluous to me. If we = >>> need Mobile Router to Mobile Router communication we don't need to = >>> talk about Mobile Router being a Correspondent Router. It's simply = >>> Mobile Router to Mobile Router communication. >> >> no, the correspondet router does not need to be mobile (like the CN = >> does not need to be mobile neither) > > Marcelo why do we need to talk about a Correspondent Router when we talk > Mobile Router to Mobile Router communication? I think i understnad where the misunderstanding is. Are you considering = only the car to car communication? Cause i understnad that the scenario = that we are considering is broader than that and it allows the car to = communicate to the fixed infrastrcutre as well, so, in that case, we = need to CE as a general concept, agree? > >>> I don't think Mobile IPv6 is well adapted for car-to-car = >>> communications, without fixed infrastructure. >>> >> ok, so i suggest you to go an propose your ideas in the wg that has a >> protocol that according to you is well suited for car to car = >> communication, cause in this wg, we usually work on mip6 :-) > > Note taken. I take this as a Chair indication to not touch other > protocols when doing Mobile IPv6 for car-to-car communications (without > infrastructure). > no, this is not what is said. What i said is that in MEXT we work in = mip6/nemo based solutions and not on solutions that don't involve MIP6/nemo If in order to make a MIP6/nemo solution to work properly we need to = have extensions in other protocols, that's perfectly ok (see for = instance the work we have done with dhcp pd, and so on) regards, marcelo > Alex > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email = > ______________________________________________________________________ > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 28 08:20:41 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBCB13A67B2; Fri, 28 Nov 2008 08:20:40 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F82C3A67B2 for ; Fri, 28 Nov 2008 08:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 R5zPnvC9zaO2 for ; Fri, 28 Nov 2008 08:20:38 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id B33A73A67AB for ; Fri, 28 Nov 2008 08:20:38 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1227889234!9451163!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 9507 invoked from network); 28 Nov 2008 16:20:34 -0000 Received: from unknown (HELO motgate3.mot.com) (136.182.1.13) by server-5.tower-153.messagelabs.com with SMTP; 28 Nov 2008 16:20:34 -0000 Received: from il27exr01.cig.mot.com ([10.17.196.70]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id mASGKTgD010436; Fri, 28 Nov 2008 09:20:29 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr01.cig.mot.com (8.13.1/Vontu) with SMTP id mASGKSuV007497; Fri, 28 Nov 2008 10:20:28 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il27exr01.cig.mot.com (8.13.1/8.13.0) with ESMTP id mASGKRsg007466; Fri, 28 Nov 2008 10:20:28 -0600 (CST) Message-ID: <49301A4B.7040309@gmail.com> Date: Fri, 28 Nov 2008 17:20:27 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: marcelo bagnulo braun References: <492FDBF8.9010203@gmail.com> <492FDF16.7020708@it.uc3m.es> <492FEC16.1020502@gmail.com> <492FF89F.8030304@it.uc3m.es> <492FFF17.3010508@gmail.com> <49300191.1070707@it.uc3m.es> In-Reply-To: <49300191.1070707@it.uc3m.es> X-Antivirus: avast! (VPS 081127-1, 27/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext Subject: Re: [MEXT] Mobile IPv6 for car-to-car communications X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org marcelo bagnulo braun wrote: > Alexandru Petrescu escribi=F3: >> marcelo bagnulo braun wrote: [...] >>>> Extending the concept of RO correspondent entity, to a = >>>> Correspondent Router and further to a Mobile Router is = >>>> superfluous to me. If we need Mobile Router to Mobile Router = >>>> communication we don't need to talk about Mobile Router being a >>>> Correspondent Router. It's simply Mobile Router to Mobile = >>>> Router communication. >>> = >>> no, the correspondet router does not need to be mobile (like the = >>> CN does not need to be mobile neither) >> = >> Marcelo why do we need to talk about a Correspondent Router when we >> talk Mobile Router to Mobile Router communication? > = > I think i understnad where the misunderstanding is. Are you = > considering only the car to car communication? YEs. > Cause i understnad that the scenario that we are considering is = > broader than that and it allows the car to communicate to the fixed = > infrastrcutre as well, so, in that case, we need to CE as a general = > concept, agree? Well I thought we would rather design a purpose-specific method of RO, adapted for particular cases, rather than a generic RO method. In this sense I don't agree a generic vehicular RO method would work for all vehicular scenarios. >>>> I don't think Mobile IPv6 is well adapted for car-to-car = >>>> communications, without fixed infrastructure. >>>> = >>> ok, so i suggest you to go an propose your ideas in the wg that = >>> has a protocol that according to you is well suited for car to = >>> car communication, cause in this wg, we usually work on mip6 :-) >> = >> Note taken. I take this as a Chair indication to not touch other = >> protocols when doing Mobile IPv6 for car-to-car communications = >> (without infrastructure). >> = > no, this is not what is said. What i said is that in MEXT we work in = > mip6/nemo based solutions and not on solutions that don't involve = > MIP6/nemo If in order to make a MIP6/nemo solution to work properly = > we need to have extensions in other protocols, that's perfectly ok = > (see for instance the work we have done with dhcp pd, and so on) Ah, that's right. In this sense, an RO method for car-to-car communications that wouldn't extend Mobile IPv6 (but some other protocol), could be designed here maybe. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email = ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Nov 28 08:30:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2EE53A67FF; Fri, 28 Nov 2008 08:30:51 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7BC3A67FF for ; Fri, 28 Nov 2008 08:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.742 X-Spam-Level: X-Spam-Status: No, score=-3.742 tagged_above=-999 required=5 tests=[AWL=-1.143, 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 kRjuiVER8Qoj for ; Fri, 28 Nov 2008 08:30:50 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with SMTP id 0475E3A67A7 for ; Fri, 28 Nov 2008 08:30:49 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1227889846!32367166!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 21987 invoked from network); 28 Nov 2008 16:30:46 -0000 Received: from unknown (HELO motgate2.mot.com) (136.182.1.12) by server-4.tower-119.messagelabs.com with SMTP; 28 Nov 2008 16:30:46 -0000 Received: from il27exr01.cig.mot.com (il27exr01.mot.com [10.17.196.70]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id mASGUefM012199; Fri, 28 Nov 2008 09:30:41 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr01.cig.mot.com (8.13.1/Vontu) with SMTP id mASGUeND016484; Fri, 28 Nov 2008 10:30:40 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il27exr01.cig.mot.com (8.13.1/8.13.0) with ESMTP id mASGUdjq016446; Fri, 28 Nov 2008 10:30:39 -0600 (CST) Message-ID: <49301CAF.90205@gmail.com> Date: Fri, 28 Nov 2008 17:30:39 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Thierry Ernst References: <492FDBF8.9010203@gmail.com> <492FDF16.7020708@it.uc3m.es> <492FEC16.1020502@gmail.com> <492FF89F.8030304@it.uc3m.es> <49300187.1080409@inria.fr> In-Reply-To: <49300187.1080409@inria.fr> X-Antivirus: avast! (VPS 081127-1, 27/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext Subject: Re: [MEXT] Mobile IPv6 for car-to-car communications X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Thierry, Thierry Ernst wrote: > marcelo bagnulo braun wrote: >> Alexandru Petrescu escribi=F3: >>> marcelo bagnulo braun wrote: >>>> Alex, >>>> = >>>> Alexandru Petrescu escribi=F3: >>>>> MEXTers, >>>>> = >>>>> Let's first make one thing straight about = >>>>> draft-ietf-mext-nemo-ro-automotive-req-01.txt. >>>>> = >>>>> Are the requirements written such as the RO vehicular design >>>>> uses Correspondent Routers as mentioned in = >>>>> draft-bernardos-mext-nemo-ro-cr-00 and in = >>>>> draft-wakikawa-mext-cr-consideration-0? >>>> = >>>> well a requirement doc should be neutral w.r.t. the solution >>> = >>> I fully agree, but it does not seem the case with this = >>> requirements document. It assumes a Correspondent Router. > The document is using the established NEMO Terminology (RFC 4885) and > CR is corresponding to section 2.9. Correspondent Router (CR) . . > . . . . . . . . . . . . . . 7 of RFC 4885. Well yes, but the term CR isn't used neither by Mobile IPv6 nor by its extension NEMOv6. We could of course define new terms informationally, but sometimes it is good to shortcut many definitions by terms actually used in implementations. We already have to talk OBU to mean MR - if we define CE or CR to be yet another term for the same thing then it's maybe a lot... or depends on how people get this altogether... just some thought. > Actually, draft-ietf-mext-nemo-ro-automotive-req-01.txt is mostly = > using the term CE (Correspondent Entity) which is by nature neutral = > (could be fixed or mobile): in the automotive use-case we are dealing > with scenarios where we really mean MR to MR communications which = > must be optimized; Well I agree, but in this particular car-to-car communication it is very meaningful to just mean MR or OBU. The term Correspondent Router isn't used by any protocol like NEMOv6 or Mobile IPv6. > and there are also other scenarios where we want to optimize = > communications between a MR and a nearby CN. YEs I agree. I agree that a scenario needing to optimize routes between MR and CN in the fixed infrastructure needs Mobile IPv6 extensions. > There could be one solution for the two cases, or a common solution. I disagree in this case. I don't see the use of Mobile IPv6 for car-to-car communications (without fixed infrastructure). It's like forcing the use of the hammer even on small things, smaller than nails. > For a specific MR-MR solution it doesn't make sense to use the term = > CR. I agree. MR-to-MR solution wouldn't mention CR. Alex > = > = > = >>> = >>>> In draft-bernardos, there is a RO correpsondetn entity, that = >>>> performs the RO fucntions in the CN side, which can be placed = >>>> in different device, including the CN itself, the HA or a new = >>>> device, like the CR. I think that it is importnat to = >>>> differentiate the fucntional entities that are required in any = >>>> solutions and the particular form and places that these = >>>> fucntions are placed in the different solutions >>>> = >>> Extending the concept of RO correspondent entity, to a = >>> Correspondent Router and further to a Mobile Router is = >>> superfluous to me. If we need Mobile Router to Mobile Router = >>> communication we don't need to talk about Mobile Router being a = >>> Correspondent Router. It's simply Mobile Router to Mobile Router >>> communication. >> no, the correspondet router does not need to be mobile (like the CN >> does not need to be mobile neither) > Agree. > = >> = >>> = >>>>> Along the same lines: is the RO-vehicular technique designed = >>>>> following these requirements supposed to use Mobile IPv6 = >>>>> extensions? Like extending BUs/BAcks? Or can it use some = >>>>> other existing protocol as basis? >>>>> = >>>> well, we are in mext, so we work on mip6 >>> = >>> I don't think Mobile IPv6 is well adapted for car-to-car = >>> communications, without fixed infrastructure. > One has to understand that cars may be once in an infrastructure-less > situation and once in an infrastructure-based situation and they = > also must be reachable at a permanent address (therefore IPv6 and = > NEMO). ITS architectures are designed in a way both are supported = > (so, there could be different solutions but they have to co-exist in = > a single architecture). > = >>> = >> ok, so i suggest you to go an propose your ideas in the wg that has >> a protocol that according to you is well suited for car to car = >> communication, cause in this wg, we usually work on mip6 :-) >> = >> regards, marcelo >> = >>> Mobile IPv6 has many topological assumptions (a fixed HA, an = >>> often fixed CN) that make it difficult to use in a car-to-car = >>> communications. >>> = >>> I believe car-to-car communications are a significant departure = >>> from Mobile IPv6. >>> = >>> We can achieve car-to-car communications by using Mobile Router = >>> to Mobile Router communications by their egress interfaces and = >>> without using Mobile IPv6. >>> = >>> If it is believed that Mobile IPv6 should be modified in order to >>> achieve car-to-car communications then I fully disagree. > = > Alex has a point indeed, but may be not the background. Car-to-Car = > communication would both need an NEMO-type of solution (with HA, CoA, > etc - note that I avoided to use Mobile IPv6 because we need to = > support in-vehicle networks) which is optimized for car-to-car = > communications and an MANET-type of solution where there is no HA. = > The first has to be dealt with MEXT, the second possibly with = > Autoconf. > = > Thierry > = > = > = > = > = ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email = ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From moran@amcd.ie Fri Nov 28 20:04:30 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFFFD3A6AC3 for ; Fri, 28 Nov 2008 20:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -32.388 X-Spam-Level: X-Spam-Status: No, score=-32.388 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_CZ=0.445, HOST_EQ_BROADBND=1.118, HOST_EQ_CZ=0.904, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWRh4ff5br5V for ; Fri, 28 Nov 2008 20:04:30 -0800 (PST) Received: from 236.83.broadband4.iol.cz (236.83.broadband4.iol.cz [85.71.83.236]) by core3.amsl.com (Postfix) with SMTP id 3B9E93A6778 for ; Fri, 28 Nov 2008 20:04:28 -0800 (PST) To: Subject: Private Order 77153 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081129040429.3B9E93A6778@core3.amsl.com> Date: Fri, 28 Nov 2008 20:04:28 -0800 (PST) Click here to view as a webpage.


Windows Live Customer Support | Hotmail Support FAQs | Newsletter feedback

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052 As a Windows Live member you have received this e-mail to inform you of updates, changes to the service, or special news and information vital to the service. Our policy is to send e-mail messages only to announce such information, and we'll continue to honor this policy. These communications are required as a part of this service. If you do not wish to receive these letters you may discontinue your participation in the service and close your account.

Microsoft respects your privacy. To learn more, please read our online Privacy Statement

Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
From lcjvamsdeve@abbeytitle.com Sat Nov 29 08:20:53 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78EDC3A6924 for ; Sat, 29 Nov 2008 08:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.956 X-Spam-Level: X-Spam-Status: No, score=-16.956 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfukk6txzGkP for ; Sat, 29 Nov 2008 08:20:52 -0800 (PST) Received: from 77-85-98-238.btc-net.bg (77-85-98-238.btc-net.bg [77.85.98.238]) by core3.amsl.com (Postfix) with SMTP id A15443A684C for ; Sat, 29 Nov 2008 08:20:51 -0800 (PST) To: Subject: Private Order 82198 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081129162051.A15443A684C@core3.amsl.com> Date: Sat, 29 Nov 2008 08:20:51 -0800 (PST) Click here to view as a webpage.


Windows Live Customer Support | Hotmail Support FAQs | Newsletter feedback

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052 As a Windows Live member you have received this e-mail to inform you of updates, changes to the service, or special news and information vital to the service. Our policy is to send e-mail messages only to announce such information, and we'll continue to honor this policy. These communications are required as a part of this service. If you do not wish to receive these letters you may discontinue your participation in the service and close your account.

Microsoft respects your privacy. To learn more, please read our online Privacy Statement

Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
From mext-bounces@ietf.org Sat Nov 29 12:09:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79F033A6A00; Sat, 29 Nov 2008 12:09:39 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4590B3A6A00 for ; Sat, 29 Nov 2008 12:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 xowOItzkr+GY for ; Sat, 29 Nov 2008 12:09:37 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 2CBEB3A67B5 for ; Sat, 29 Nov 2008 12:09:36 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (14.pool85-53-137.dynamic.orange.es [85.53.137.14])by smtp03.uc3m.es (Postfix) with ESMTP id 9F1146B00E4; Sat, 29 Nov 2008 21:09:28 +0100 (CET) Message-ID: <4931A178.7060600@it.uc3m.es> Date: Sat, 29 Nov 2008 21:09:28 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Alexandru Petrescu References: <492FDBF8.9010203@gmail.com> <492FDF16.7020708@it.uc3m.es> <492FEC16.1020502@gmail.com> <492FF89F.8030304@it.uc3m.es> <492FFF17.3010508@gmail.com> <49300191.1070707@it.uc3m.es> <49301A4B.7040309@gmail.com> In-Reply-To: <49301A4B.7040309@gmail.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-3.2389 TC:1F TRN:41 TV:5.5.1026(16310.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: mext Subject: Re: [MEXT] Mobile IPv6 for car-to-car communications X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alexandru Petrescu escribi=F3: > > Well I thought we would rather design a purpose-specific method of RO, > adapted for particular cases, rather than a generic RO method. In this > sense I don't agree a generic vehicular RO method would work for all > vehicular scenarios. > right, but i understand that the automotive case, they also want to = communicate the nodes in the car network to the fixed infrastrcuture, so = not only car to car communications need to be considered. >>>>> I don't think Mobile IPv6 is well adapted for car-to-car = >>>>> communications, without fixed infrastructure. >>>>> >>>> ok, so i suggest you to go an propose your ideas in the wg that has = >>>> a protocol that according to you is well suited for car to car = >>>> communication, cause in this wg, we usually work on mip6 :-) >>> >>> Note taken. I take this as a Chair indication to not touch other = >>> protocols when doing Mobile IPv6 for car-to-car communications = >>> (without infrastructure). >>> >> no, this is not what is said. What i said is that in MEXT we work in = >> mip6/nemo based solutions and not on solutions that don't involve = >> MIP6/nemo If in order to make a MIP6/nemo solution to work properly = >> we need to have extensions in other protocols, that's perfectly ok = >> (see for instance the work we have done with dhcp pd, and so on) > > Ah, that's right. In this sense, an RO method for car-to-car > communications that wouldn't extend Mobile IPv6 (but some other > protocol), could be designed here maybe. > not sure what you have in mind so, i guess the best approahc is for you = to describe what you have in mind in more detail and then we cna figure = out if this is the right wg for that work regards, marcelo > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email = > ______________________________________________________________________ > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Nov 29 14:02:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E56C3A6B59; Sat, 29 Nov 2008 14:02:31 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4FFE3A6B59 for ; Sat, 29 Nov 2008 14:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 6iEbnUX95RR0 for ; Sat, 29 Nov 2008 14:02:28 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with SMTP id AA9453A67C0 for ; Sat, 29 Nov 2008 14:02:28 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1227996144!39311631!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 18846 invoked from network); 29 Nov 2008 22:02:24 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-119.messagelabs.com with SMTP; 29 Nov 2008 22:02:24 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mATM2OCp018541; Sat, 29 Nov 2008 15:02:24 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id mATM2OVl028096; Sat, 29 Nov 2008 16:02:24 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.54]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id mATM2MvM028091; Sat, 29 Nov 2008 16:02:23 -0600 (CST) Message-ID: <4931BBEE.4030801@gmail.com> Date: Sat, 29 Nov 2008 23:02:22 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: marcelo bagnulo braun References: <492FDBF8.9010203@gmail.com> <492FDF16.7020708@it.uc3m.es> <492FEC16.1020502@gmail.com> <492FF89F.8030304@it.uc3m.es> <492FFF17.3010508@gmail.com> <49300191.1070707@it.uc3m.es> <49301A4B.7040309@gmail.com> <4931A178.7060600@it.uc3m.es> In-Reply-To: <4931A178.7060600@it.uc3m.es> X-Antivirus: avast! (VPS 081129-0, 29/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext Subject: Re: [MEXT] Mobile IPv6 for car-to-car communications X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org marcelo bagnulo braun wrote: > Alexandru Petrescu escribi=F3: >> = >> Well I thought we would rather design a purpose-specific method of >> RO, adapted for particular cases, rather than a generic RO method. >> In this sense I don't agree a generic vehicular RO method would >> work for all vehicular scenarios. >> = > right, but i understand that the automotive case, they also want to = > communicate the nodes in the car network to the fixed infrastrcuture, > so not only car to car communications need to be considered. I agree, the automotive case often considers also the case of nodes in the car network communicating to the fixed infrastructure. Often the first steps in that direction is to see how IPv6 can run over the vehicular links towards the infrastructure, and also often mobility as handover between subnets is not considered in these first steps. >>>>>> I don't think Mobile IPv6 is well adapted for car-to-car = >>>>>> communications, without fixed infrastructure. >>>>>> = >>>>> ok, so i suggest you to go an propose your ideas in the wg >>>>> that has a protocol that according to you is well suited for >>>>> car to car communication, cause in this wg, we usually work >>>>> on mip6 :-) >>>> = >>>> Note taken. I take this as a Chair indication to not touch >>>> other protocols when doing Mobile IPv6 for car-to-car >>>> communications (without infrastructure). >>>> = >>> no, this is not what is said. What i said is that in MEXT we work >>> in mip6/nemo based solutions and not on solutions that don't >>> involve MIP6/nemo If in order to make a MIP6/nemo solution to >>> work properly we need to have extensions in other protocols, >>> that's perfectly ok (see for instance the work we have done with >>> dhcp pd, and so on) >> = >> Ah, that's right. In this sense, an RO method for car-to-car = >> communications that wouldn't extend Mobile IPv6 (but some other = >> protocol), could be designed here maybe. >> = > not sure what you have in mind so, i guess the best approahc is for > you to describe what you have in mind in more detail and then we cna > figure out if this is the right wg for that work What I have in mind is to look closer at how IPv6 can be deployed in the vehicular types of deployments. I think we need the req document for vehicular RO, I offered comments, and also think we can add some simpler aspects to the reqs document; for example the necessity of requiring IPv6 to run over 802.11p, and the necessity of requiring car-to-car communications without using Mobile = IPv6 - in a first step. In a first step these should be accomodated = without the mobility necessity. These comments come after having read the RO vehicular reqs in detail, = and after having had just a little exposure to the vehicular standards. Speaking of which - do you think in MEXT we can work with non-IETF = vehicular standards without having access to these standard documents = (IEEE 802.11p and ISO CALM)? Where are these documents? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email = ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 30 03:09:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357243A6821; Sun, 30 Nov 2008 03:09:47 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E44523A6821 for ; Sun, 30 Nov 2008 03:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 Lu3vcy5-UlWz for ; Sun, 30 Nov 2008 03:09:45 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id BB8CE3A67E5 for ; Sun, 30 Nov 2008 03:09:43 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.135.38])by smtp01.uc3m.es (Postfix) with ESMTP id E2B8CACBAB7;Sun, 30 Nov 2008 12:09:35 +0100 (CET) Message-ID: <4932746F.3050605@it.uc3m.es> Date: Sun, 30 Nov 2008 12:09:35 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Alexandru Petrescu References: <492FDBF8.9010203@gmail.com> <492FDF16.7020708@it.uc3m.es> <492FEC16.1020502@gmail.com> <492FF89F.8030304@it.uc3m.es> <492FFF17.3010508@gmail.com> <49300191.1070707@it.uc3m.es> <49301A4B.7040309@gmail.com> <4931A178.7060600@it.uc3m.es> <4931BBEE.4030801@gmail.com> In-Reply-To: <4931BBEE.4030801@gmail.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-9.1185 TC:1F TRN:65 TV:5.5.1026(16310.005) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: mext Subject: Re: [MEXT] Mobile IPv6 for car-to-car communications X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alexandru Petrescu escribi=F3: > marcelo bagnulo braun wrote: >> Alexandru Petrescu escribi=F3: >>> >>> Well I thought we would rather design a purpose-specific method of >>> RO, adapted for particular cases, rather than a generic RO method. >>> In this sense I don't agree a generic vehicular RO method would >>> work for all vehicular scenarios. >>> >> right, but i understand that the automotive case, they also want to = >> communicate the nodes in the car network to the fixed infrastrcuture, >> so not only car to car communications need to be considered. > > I agree, the automotive case often considers also the case of nodes in > the car network communicating to the fixed infrastructure. Often the > first steps in that direction is to see how IPv6 can run over the > vehicular links towards the infrastructure, and also often mobility as > handover between subnets is not considered in these first steps. > well, this is decision that the WG can take i.e. to scope the problem = and focus in some parts of it, but this is up for disucssion (this issue = wasn't brought up until now afaict) >>>>>>> I don't think Mobile IPv6 is well adapted for car-to-car = >>>>>>> communications, without fixed infrastructure. >>>>>>> >>>>>> ok, so i suggest you to go an propose your ideas in the wg >>>>>> that has a protocol that according to you is well suited for >>>>>> car to car communication, cause in this wg, we usually work >>>>>> on mip6 :-) >>>>> >>>>> Note taken. I take this as a Chair indication to not touch >>>>> other protocols when doing Mobile IPv6 for car-to-car >>>>> communications (without infrastructure). >>>>> >>>> no, this is not what is said. What i said is that in MEXT we work >>>> in mip6/nemo based solutions and not on solutions that don't >>>> involve MIP6/nemo If in order to make a MIP6/nemo solution to >>>> work properly we need to have extensions in other protocols, >>>> that's perfectly ok (see for instance the work we have done with >>>> dhcp pd, and so on) >>> >>> Ah, that's right. In this sense, an RO method for car-to-car = >>> communications that wouldn't extend Mobile IPv6 (but some other = >>> protocol), could be designed here maybe. >>> >> not sure what you have in mind so, i guess the best approahc is for >> you to describe what you have in mind in more detail and then we cna >> figure out if this is the right wg for that work > > What I have in mind is to look closer at how IPv6 can be deployed in the > vehicular types of deployments. > > I think we need the req document for vehicular RO, I offered comments, > and also think we can add some simpler aspects to the reqs document; for > example the necessity of requiring IPv6 to run over 802.11p, and the > necessity of requiring car-to-car communications without using Mobile = > IPv6 - in a first step. In a first step these should be accomodated = > without the mobility necessity. > I guess that we need to run IP on the first place, but i am not sure i = understand what the problems are with that... > These comments come after having read the RO vehicular reqs in detail, = > and after having had just a little exposure to the vehicular standards. > > Speaking of which - do you think in MEXT we can work with non-IETF = > vehicular standards without having access to these standard documents = > (IEEE 802.11p and ISO CALM)? Where are these documents? > mmm, i guess we usually work with link layers that are not defined by = the ietf, so i don't see what is the problem with that... i mean, the = IETF haven't defined ethernet but still we have defined arp and ND... regards, marcelo > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email = > ______________________________________________________________________ > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 30 09:29:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0283A68D5; Sun, 30 Nov 2008 09:29:48 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 770C33A68D5 for ; Sun, 30 Nov 2008 09:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 RKzxfwuoDCSD for ; Sun, 30 Nov 2008 09:29:45 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 99D183A68CC for ; Sun, 30 Nov 2008 09:29:45 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1228066180!5820992!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 21333 invoked from network); 30 Nov 2008 17:29:41 -0000 Received: from unknown (HELO motgate3.mot.com) (136.182.1.13) by server-6.tower-153.messagelabs.com with SMTP; 30 Nov 2008 17:29:41 -0000 Received: from il27exr01.cig.mot.com ([10.17.196.70]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id mAUHTZKW011421; Sun, 30 Nov 2008 10:29:35 -0700 (MST) Received: from il27vts01 (il27vts01.cig.mot.com [10.17.196.85]) by il27exr01.cig.mot.com (8.13.1/Vontu) with SMTP id mAUHTZVS001996; Sun, 30 Nov 2008 11:29:35 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.5]) by il27exr01.cig.mot.com (8.13.1/8.13.0) with ESMTP id mAUHTXnw001979; Sun, 30 Nov 2008 11:29:34 -0600 (CST) Message-ID: <4932CD7D.6040506@gmail.com> Date: Sun, 30 Nov 2008 18:29:33 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: marcelo bagnulo braun References: <492FDBF8.9010203@gmail.com> <492FDF16.7020708@it.uc3m.es> <492FEC16.1020502@gmail.com> <492FF89F.8030304@it.uc3m.es> <492FFF17.3010508@gmail.com> <49300191.1070707@it.uc3m.es> <49301A4B.7040309@gmail.com> <4931A178.7060600@it.uc3m.es> <4931BBEE.4030801@gmail.com> <4932746F.3050605@it.uc3m.es> In-Reply-To: <4932746F.3050605@it.uc3m.es> X-Antivirus: avast! (VPS 081129-0, 29/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext Subject: Re: [MEXT] Access to CALM and 802.11p documents (was: Mobile IPv6 for car-to-car communications) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org marcelo bagnulo braun wrote: [...] >> Speaking of which - do you think in MEXT we can work with non-IETF >> vehicular standards without having access to these standard documents >> (IEEE 802.11p and ISO CALM)? Where are these documents? >> > mmm, i guess we usually work with link layers that are not defined by > the ietf, so i don't see what is the problem with that... i mean, the > IETF haven't defined ethernet but still we have defined arp and ND... I agree, we work with link layers that are not defined by IETF. For Ethernet we have public free access to Ethernet standard documents. I'm afraid there may not be public access for latest 802.11p documents, neither ISO CALM documents. Maybe we could obtain this access restricted to the MEXT WG members somehow. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 30 09:41:30 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966A33A68D5; Sun, 30 Nov 2008 09:41:30 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C50E53A68D5 for ; Sun, 30 Nov 2008 09:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 WsMJDSS+WS+a for ; Sun, 30 Nov 2008 09:41:28 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id C9DD03A67EC for ; Sun, 30 Nov 2008 09:41:27 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (38.pool85-53-135.dynamic.orange.es [85.53.135.38])by smtp03.uc3m.es (Postfix) with ESMTP id 46EF36B0197; Sun, 30 Nov 2008 18:41:19 +0100 (CET) Message-ID: <4932D03C.5000801@it.uc3m.es> Date: Sun, 30 Nov 2008 18:41:16 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Alexandru Petrescu References: <492FDBF8.9010203@gmail.com> <492FDF16.7020708@it.uc3m.es> <492FEC16.1020502@gmail.com> <492FF89F.8030304@it.uc3m.es> <492FFF17.3010508@gmail.com> <49300191.1070707@it.uc3m.es> <49301A4B.7040309@gmail.com> <4931A178.7060600@it.uc3m.es> <4931BBEE.4030801@gmail.com> <4932746F.3050605@it.uc3m.es> <4932CD7D.6040506@gmail.com> In-Reply-To: <4932CD7D.6040506@gmail.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-16.6438 TC:1F TRN:35 TV:5.5.1026(16312.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: mext Subject: Re: [MEXT] Access to CALM and 802.11p documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org We can ask, certainly C2C has appointed a liaison with the MEXT wg, so we can try that... Regards, marcelo Alexandru Petrescu escribi=F3: > marcelo bagnulo braun wrote: > [...] >>> Speaking of which - do you think in MEXT we can work with non-IETF = >>> vehicular standards without having access to these standard = >>> documents (IEEE 802.11p and ISO CALM)? Where are these documents? >>> >> mmm, i guess we usually work with link layers that are not defined by = >> the ietf, so i don't see what is the problem with that... i mean, the = >> IETF haven't defined ethernet but still we have defined arp and ND... > > I agree, we work with link layers that are not defined by IETF. For = > Ethernet we have public free access to Ethernet standard documents. = > I'm afraid there may not be public access for latest 802.11p = > documents, neither ISO CALM documents. Maybe we could obtain this = > access restricted to the MEXT WG members somehow. > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email = > ______________________________________________________________________ > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From lanzillottasqyq@6o9.net Sun Nov 30 10:49:27 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07D9428C12B for ; Sun, 30 Nov 2008 10:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.097 X-Spam-Level: X-Spam-Status: No, score=-10.097 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oubdf2mgMRW for ; Sun, 30 Nov 2008 10:49:26 -0800 (PST) Received: from 201-213-202-36.net.prima.net.ar (201-213-202-36.net.prima.net.ar [201.213.202.36]) by core3.amsl.com (Postfix) with SMTP id B93243A6820 for ; Sun, 30 Nov 2008 10:49:20 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081130184921.B93243A6820@core3.amsl.com> Date: Sun, 30 Nov 2008 10:49:20 -0800 (PST) Click here to view as a webpage. From 2008note2911@gmail.com Sun Nov 30 10:53:44 2008 Return-Path: <2008note2911@gmail.com> X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6B113A69D0; Sun, 30 Nov 2008 10:53:44 -0800 (PST) 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.035, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RAZOR2_CHECK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwJgqdHG+wJR; Sun, 30 Nov 2008 10:53:44 -0800 (PST) Received: from maildcarg4.dc-host.net.ar (maildcarg4.dc-host.net.ar [200.55.6.135]) by core3.amsl.com (Postfix) with ESMTP id A1FE23A6820; Sun, 30 Nov 2008 10:53:44 -0800 (PST) Received: from localhost ([190.245.9.133]) by maildcarg4.dc-host.net.ar (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0KB5009ILTSZ3D90@maildcarg4.dc-host.net.ar>; Sun, 30 Nov 2008 15:53:25 -0300 (ART) Received: from f3t ([127.0.0.1]) by localhost with SMTP (Code-Crafters Ability Mail Server 2.61); Sun, 30 Nov 2008 16:53:30 +0100 Date: Sun, 30 Nov 2008 16:53:31 +0100 From: "2008note2911@gmail.com" <2008note2911@gmail.com> Subject: COMPUTADORA ATHLON COMPLETA UNICA! ATHLON 5000+ GeForce 6100 To: PCs <2008note2911@gmail.com> Message-id: <3816-2200811030155331187@f3t> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable COMPUTADORAS con 1 A=D1O DE GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALL= ITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS TAMBIEN DISPONIBLES PARA EL INTERIO= R=2E CONSULTE FACTURA A o B EMail: 2008note2911@gmail=2Ecom -Modelo: ATHLON FIRE -Procesador: AMD ATHLON 64 DUAL CORE 5000+ Socket AM2 BOX -Motherboard: ASUS M2NMX SE PLUS chipset nVidia nForce 430 -Memoria: 1GB DDR2 667 -Placa de video: nVIDIA GeForce 6100GS 256MB -Disco r=EDgido: 160 GB SATA2 -Medio optico: ReGrabadora de DVD Hewlett Packard 20X -Placa de red: 10/100 on board -Placa de sonido: 6 canales -Puertos: 2USB frontales + 4USB traseros -Gabinete: KIT CIRKUIT PLANET 9024 -Teclado multimedia, Mouse optico, Parlantes y Diskettera 3 =BD=2E -Garantia 12 meses -Sistema operativo instalado y funcionando FULL, todos los programa y util= idades=2E Microsoft Windows XP SP3 -PRECIO $899 FINAL From mext-bounces@ietf.org Sun Nov 30 16:24:21 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3AC23A6A80; Sun, 30 Nov 2008 16:24:21 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384F33A6A1A for ; Sun, 30 Nov 2008 16:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.027 X-Spam-Level: X-Spam-Status: No, score=-104.027 tagged_above=-999 required=5 tests=[AWL=-1.428, 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 63CXoZIzbr6l for ; Sun, 30 Nov 2008 16:24:18 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id B9CA23A67EF for ; Sun, 30 Nov 2008 16:24:18 -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=1228091055; x=1259627055; 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=20Julien=20Laganier=0D=0A=09|CC:=20"mext@ietf.org" =20|Date:=20Sun,=2030=20Nov=202008=2016:24 :10=20-0800|Subject:=20RE:=20Questions=20on=20draft-ietf- mext-flow-binding-00|Thread-Topic:=20Questions=20on=20dra ft-ietf-mext-flow-binding-00|Thread-Index:=20AclRPk2wUIt8 XP/ALEetIMMFfYctOwCDJjjw|Message-ID:=20<057632CE4CE10D45A 1A3D6D19206C3A3D6CA0912@NASANEXMB08.na.qualcomm.com> |References:=20<200811281039.18769.julien.laganier.IETF@g ooglemail.com>=0D=0A=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 100,188,5449"=3B=20a=3D"13539594"; bh=ncacWbR/mZ+CNn0siFJ/WhcStkDdF6aOLvC11wbrmXI=; b=RJJl0oLCYDiqPaI65gAu0VbUI6nFdMte+5/m71qr69KB3MaRDMJuLTxq lKiom2eQXMw4Ro4mM3DRXN6iwpKlw1hP++agtNKEHmE7rAwU+8Ugi/TD0 YaLDToCBp1euBPjIw3WcNxX5YV0ZCjUjtpSsGcehgXsko38he7Y799kaO s=; X-IronPort-AV: E=McAfee;i="5100,188,5449"; a="13539594" 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; 30 Nov 2008 16:24:15 -0800 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mB10OEY8001865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 30 Nov 2008 16:24:15 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mB10OCdv028229 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 30 Nov 2008 16:24:14 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.132]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Sun, 30 Nov 2008 16:24:11 -0800 From: "Giaretta, Gerardo" To: Hesham Soliman , Julien Laganier Date: Sun, 30 Nov 2008 16:24:10 -0800 Thread-Topic: Questions on draft-ietf-mext-flow-binding-00 Thread-Index: AclRPk2wUIt8XP/ALEetIMMFfYctOwCDJjjw Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D6CA0912@NASANEXMB08.na.qualcomm.com> References: <200811281039.18769.julien.laganier.IETF@googlemail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] Questions on draft-ietf-mext-flow-binding-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I would also add that the HA does not even know which CoA is associated with which network interface type and therefore it would be difficult to provide routing information based on the CoA. As a side note, the approach mentioned by Hesham (policies provided by the network and then followed by the MN when initiating mobility events) is also the one 3GPP is heading to with the work on ANDSF Gerardo > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Friday, November 28, 2008 1:47 AM > To: Julien Laganier > Cc: mext@ietf.org; Giaretta, Gerardo > Subject: Re: Questions on draft-ietf-mext-flow-binding-00 > > > Hi Julien, > > > > Hi Hesham, > > > > Maybe I shouldn't have used the term policy exchange. > > > > I understand the CN can be involved too, that's good. > > > > How about the home agent initiating a routing information exchange > > towards the MN - that doesn't seem to be supported by the draft... > > => We discussed this in some detail in MIP6. The problem with this approach > is that the HA can't possibly know what to recommend. In fact, the HA has no > way of knowing if the recommended access point even works. It kind of goes > against how MIPv6 works as well if the HA just changes routing by itself. If > the HA only suggests a change of routing then it's a policy configuration :) > > So, I think the clean way to do this is to have a policy config mechanism > that can be used by the HA to configure the MN. I'm sure we can reuse other > work here and we shouldn't have to do this from scratch. > > Hesham > > > > > --julien > > > > On Thursday 27 November 2008, Hesham Soliman wrote: > >> Hi Julien, > >> > >> This draft doesn't deal with "Policy exchange". Policy exchange does > >> something like the following: > >> > >> - If 802.11b AND port 80 then use 802.11b > >> - if VoIP then use 3G > >> ....etc > >> This draft deals with exchanging the routing information, based on > >> policy decisions that were done by the MN/MR. > >> There were other draft proposing XML policies be exchanged between > >> the MN/HA. They're orthogonal to this draft. > >> > >> Also, the draft deals with MN-CN relationships already in the same > >> way that it deals with the MN-HA relationship. > >> > >> Hesham > >> > >> > >> On 27/11/08 10:53 PM, "Julien Laganier" > >> > >> wrote: > >>> Hello Hesham & all, > >>> > >>> I got some high-level questions on the draft. > >>> > >>> The text of the flow binding deliverable text in our charter says: > >>> A "Flow/binding policies exchange" solution for an exchange of > >>> policies from the mobile host/router to the Home Agent and from the > >>> Home Agent to the mobile host/router influencing the choice of the > >>> Care-of Address and Home Agent address. > >>> > >>> I am not 100% sure of my interpretation of the above, but I read it > >>> as if it should be possible for either of the mobile node/router or > >>> the home agent to initiate the flow/binding policies exchange. Is > >>> that appropriate? > >>> > >>> If yes, am I understanding right that your draft only address an > >>> exchange of policies from the mobile host/router to the home agent? > >>> > >>> If yes, wouldn't it make sense to also support the exchange of > >>> policies initiated by the home agent, i.e. from the home agent to > >>> the mobile host/router, as I understand our charter says? > >>> > >>> Orthognoal to that, I've got a dummy question: Why is flow/binding > >>> policy exchange only considered between MN/MR and HA and excludes > >>> flow/binding policy exchange between MN/MR and a correspondent > >>> node? Is it because one can't assume an arbitrary CN supports these > >>> extensions? > >>> > >>> Thanks. > >>> > >>> --julien > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 30 17:20:33 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B4A3A6A80; Sun, 30 Nov 2008 17:20:33 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D4193A6A80 for ; Sun, 30 Nov 2008 17:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.849 X-Spam-Level: X-Spam-Status: No, score=-104.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMa1sz+uiRyN for ; Sun, 30 Nov 2008 17:20:30 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id B05383A6A3A for ; Sun, 30 Nov 2008 17:20:30 -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=1228094427; x=1259630427; 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=20Benjamin=20Lim=0D=0A=09|CC:=20"mext@ietf.org"=20|Date:=20Sun,=2030=20Nov=202008=2017:20:24=20-08 00|Subject:=20RE:=20[MEXT]=20Comments=20on=20draft-ietf-m ext-flow-binding-00|Thread-Topic:=20[MEXT]=20Comments=20o n=20draft-ietf-mext-flow-binding-00|Thread-Index:=20AclOv 9JB9wi2u1Q/qkGmNuSo03NZNgAW1CIwAFjXmKIAtMAQsA=3D=3D |Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3D6CA0919@ NASANEXMB08.na.qualcomm.com>|References:=20<057632CE4CE10 D45A1A3D6D19206C3A3D6CA073E@NASANEXMB08.na.qualcomm.com> =0D=0A=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 100,188,5449"=3B=20a=3D"13540159"; bh=BhxGqm/BDbT9QhPIR4hFxAlFvHJED00kswldbzju4nA=; b=glyuuLInitrIDkyWWmQVYSXFoH3bUiQVINMQtSUWIwZiI/LSekmClVqd A9FVO5MsJzkT6+RQo680+zD37vDgMrujX2LudAPldJQvNKnhE7Cu94Nn4 mjm2UXMTSeFwJYhVk3yTWT2pWDeAtpS9nuFtd1UYGVHrnKymoVUVqpzUN 4=; X-IronPort-AV: E=McAfee;i="5100,188,5449"; a="13540159" 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; 30 Nov 2008 17:20:27 -0800 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 mB11KQ8e006688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 30 Nov 2008 17:20:27 -0800 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 mB11KQ4U007997 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 30 Nov 2008 17:20:26 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.132]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Sun, 30 Nov 2008 17:20:25 -0800 From: "Giaretta, Gerardo" To: Hesham Soliman , Benjamin Lim Date: Sun, 30 Nov 2008 17:20:24 -0800 Thread-Topic: [MEXT] Comments on draft-ietf-mext-flow-binding-00 Thread-Index: AclOv9JB9wi2u1Q/qkGmNuSo03NZNgAW1CIwAFjXmKIAtMAQsA== Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D6CA0919@NASANEXMB08.na.qualcomm.com> References: <057632CE4CE10D45A1A3D6D19206C3A3D6CA073E@NASANEXMB08.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 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 List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Thursday, November 27, 2008 2:54 AM > To: Giaretta, Gerardo; Benjamin Lim > Cc: mext@ietf.org > Subject: Re: [MEXT] Comments on draft-ietf-mext-flow-binding-00 > > Hi Gerardo, > > > > >> => I'll try to answer all of the above by simply stating the following: > >> The way MIPv6 works is that one BU replaces another, there is no state > >> differentials that are carried across between the old and new BCEs in an > >> implicit manner. > >> What this means is that if you want to refresh a state, you include that > >> state in the BU. > >> If we do the above, then we're simply removing the "big BU" to the remove > >> operation. If a MN wants to remove all FIDs, it can simply send a BU with > >> none of the FIDs included. Hence, removing all data is very efficient. > >> > >> If we make the assumption that refreshing all is more common that removing > >> all (fair assumption I think) then we can try to optimise for that. > >> > > > > I think it is a fair assumption. I think the following should be the > > principles to implement: > > > > - add, replace, remove flow bindings require 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 specific BID are not changed in this case. > > - The lifetime of the flow binding is tied to the lifetime of the CoA > binding. > > This implies 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 option overwrites all bindings including the flow > > binding > > > > The latter is used for example when the MN wants to go through MCoA mode to > > single CoA mode. > > > > Does it make sense? > > => Mostly yes. But I think we need to be explicit to some extent about the > refresh. For example, what happens if you want to modify one or more FIDs > while keeping the others unchanged? > I think if we change things to the way you propose we have to have an > explicit option that says "refresh everything except for the FIDs included > in this BU, they need to be treated on a per-FID basis" > Otherwise, the mixed operations become quite messy. > One option would be that we don't allow the change of a FID during the refresh operation. That would mean that to enable the scenario you mentioned the MN will send a refresh BU with all BIDs to be renewed and after that a new BU with the FID(s) to be changed. This has the drawback of requiring two BUs for the case where the MN wants to change the FID exactly when the BC entry is expiring. But is this a real drawback? Is this a common case which needs to be optimized? > There might be a simple way of doing this if we reserve one FID to indicate > "All". For instance, the all 1s FID can be used to say the above statement. > Would this leave unchanged all the FIDs? If it is a confirmation of all FIDs, it seems not clean to allow a change of one specific FID in the same message. But this would work, though. Gerardo > Hesham > > > Hesham > > > > > > > Gerardo > > > >> Hesham > >> > >> > >>> > >>> Regards, > >>> Benjamin Lim > >>> > >>>> > >>>>> So in the current state of the draft, refreshing seems useless. > >>>>> > >>>>> Besides, note that refreshing can be a costly operation: Mobile Routers > >> may > >>>>> have hundreds of rules, e.g. depending on the number of clients they > >> serve. > >>>>> > >>>> > >>>> I see your concerns and I agree we should optimize this. > >>>> > >>>> One way would be to add a new flag in the BU which indicates that flow > >>>> bindings > >>>> are also extended with the new lifetime. Note that BIDs also must always > be > >>>> included in the BU as a BU without BID will overwrite all BIDs. > >>>> > >>>> Another approach is to introduce the lifetime at the FID level but that > is > >>>> not > >>>> good in my opinion. > >>>> > >>>>> Another concern is why another method to update a CoA is defined in this > >>>>> document (section 6.2)? First, I don't really see the motivations behind > >>>>> this, > >>>>> and if I understood correctly how n-casting is specified in the BC, one > >>>>> (HoA, > >>>>> FID) pair may reference multiple entries, which makes the CoA update > >>>>> impossible in case n-casting is used (see my other comment on that > later). > >>>>> > >>>> > >>>> I don't fully understand your point here. Are you saying that a CoA > change > >>>> should always be done as per the MCoA draft (i.e. via BID)? If this is > the > >>>> intention, I agree - I don't see reasons why we should introduce the FIDs > >>>> unless they need to be changed (e.g. added or removed). > >>>> > >>>>> * Some more detailed comments: > >>>>> > >>>>> - Section 3.1, page 7, the Flow ID option shows a FID field of 16 bits > but > >>>>> it > >>>>> is described as an "an 8-bit unsigned integer". > >>>>> - Page 9, it is said "If this value is used, one or more Binding > Reference > >>>>> sub-options MUST exist.". Actually only a single Binding Reference > >>>>> sub-option > >>>>> is used but one or more BIDs must be indicated inside of it. > >>>>> > >>>> > >>>> I think both comments are correct > >>>> > >>>>> - Section 3.2: The BID sub-option is 16 bits in the MCoA draft while > here > >>>>> only > >>>>> 8 bits are used to specify a BID. > >>>> > >>>> Better: the BID field in BID sub-option is 16 bits in the MCoA draft > >>>> > >>>>> - Some indication is needed on how this option (which can have a > variable > >>>>> length) should be aligned and padded using the MIPv6 padding options > >>>>> > >>>>> - Section 4.2: "an entry is now identified by the pair (home address, > >> FID)". > >>>>> This is true only when we want to update the flow bindings. To update a > >> CoA > >>>>> (e.g. with a BU that only contains a BID option and no flow id options), > >> the > >>>>> (HoA, BID) pair remains the key to lookup the BC/BUL. Note also that the > >>>>> pair > >>>>> (HoA, FID) can refer to multiple entries when n-casting is used. > >>>>> > >>>> > >>>> I think this is correct but also the text in the draft is correct. My > >>>> understanding is that the text in the draft deals with the processing of > >> BUs > >>>> when they contain the FID option. If a BU only contains the BID option, > the > >>>> processing of the MCoA draft applies. > >>>> > >>>>> - Section 4.5: what happens if the flow id option has the PRO field set > to > >> 1 > >>>>> (modify) and no flow description is present? Section 6.2 explains that > it > >>>>> should be considered as a CoA update, but IMHO this should rather be > >>>>> considered as a request to modify the existing flow description in the > BCE > >>>>> to > >>>>> a wild card request. > >>>>> > >>>> > >>>> More in general the draft should clarify how wild card request and > default > >>>> bindings are supported. See my review a couple of days ago for details on > >>>> which are the issues in my view. > >>>> > >>>>> - Section 6.1.1: "The FID field includes a value that does not already > >> exist > >>>>> in the mobile node's binding update list.": [...] for that HA or MAP > >>>>> - "If the Binding Update sub-option includes only one BID," -> which > sub- > >>>>> option, the Binding Reference sub-option? > >>>>> > >>>>> - Section 6.1.2: "the mobile node MUST NOT refresh or delete bindings > >>>>> associated with any care-of address other than the one included in the > BU > >>>>> message." -> why? > >>>>> > >>>>> - Section 6.2: the "MODIFY" code is used but is never defined. It would > be > >>>>> good to define the ADD/MODIFY/DELETE terms in section 3.1 and to use > them > >>>>> through the document. > >>>>> > >>>>> - Section 6.3 states that n-casting is possible with the CN with some > >>>>> conditions, but section 7.1 simply forbids n-casting ("If the Action > field > >>>>> indicates a request to n-cast the flow, the correspondent node MUST > reject > >>>>> the > >>>>> option [...]") > >>>>> > >>>>> - Section 7.1: some notes on how the the flow binding is added to the > >>>>> binding > >>>>> cache should be written (existence of a BID sub-option in the BU, lookup > >> in > >>>>> the BCE with that BID, ...). Same comment for section 8.1 > >>>>> - This section and section 8.1 do not say what to do when a request to > >>>>> delete > >>>>> a flow is received. > >>>>> > >>>>> - Section 8.1: "the home agent MUST check for the presence of the BID > sub- > >>>>> option(s)." -> actually section 3.2 does not mandate the presence of the > >> BID > >>>>> sub-options if the BID already exists in the BCE ("A BID sub-option is > not > >>>>> necessarily included in the same BU [...]"). If the BID does not exist > yet > >>>>> in > >>>>> the BCE or if no BID sub-options are present, then this is an error > case. > >>>>> - "If one or more BIDs are present in the BID Reference sub-option" -> > >>>>> Binding > >>>>> Reference sub-option > >>>>> - The following procedure is too complex IMHO: > >>>>> > >>>>> If only one BID were > >>>>> included in the Binding Reference sub-option and it pointed to a > >>>>> different care-of address from the one included in the packet, > >>>>> then packets matching the flow would be bicast to those two > >>>>> addresses. > >>>>> > >>>>> Especially because the BU may be sent using another source address than > >> the > >>>>> one expected for n-casting. Why not just forbid this case and explicitly > >> ask > >>>>> for at least 2 BIDs in the binding reference sub-option? > >>>>> > >>>> > >>>> Agree on this as I mentioned in my review of the draft > >>>> > >>>> Gerardo > >>>> > >>>>> - I think it was already raised, but the document lacks some text on > what > >>>>> status code should be used upon error (section 7.1, 8.1, ...) and how > such > >>>>> error code should be treated on the receiver side. > >>>>> > >>>>> - Section 8.2: this section make me think that the section talking about > >> the > >>>>> MN side does not say what should be done when the BAck is not received > >>>>> > >>>>> - Section 10: "associate some flows to an interface and other flows to > >>>>> another > >>>>> interface": I would replace "interface" with "CoA" > >>>>> > >>>>> > >>>>> * Some editorial comments: > >>>>> > >>>>> The document is inconsistent on how "Binding Update" / "Binding > >>>>> Acknowledgement" / "Flow Identification" / "Flow Binding" / "Flow > >>>>> Description" > >>>>> / "N-cast" are written (the first letter is sometimes lower case, > >> sometimes > >>>>> upper case) > >>>>> > >>>>> Page 11: dsecription -> description > >>>>> Page 15: Acknwoledgement -> Acknowledgement Page 22: Correspondant -> > >>>>> Correspondent Page 23: authrozied -> authorized > >>>>> > >>>>> > >>>>> > >>>>> Cheers, > >>>>> -- > >>>>> Romain KUNTZ > >>>>> kuntz@lsiit.u-strasbg.fr > >>>>> LSIIT - Networks and Protocols Team > >>>>> http://clarinet.u-strasbg.fr/~kuntz/ > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext > >>>> > >>>> > >>> > >>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Nov 30 21:41:32 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3CE33A691C; Sun, 30 Nov 2008 21:41:32 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E6143A691C for ; Sun, 30 Nov 2008 21:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 7snOAcoKHDME for ; Sun, 30 Nov 2008 21:41:30 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 8578D3A6813 for ; Sun, 30 Nov 2008 21:41:30 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1L71X9-0002nh-2U; Mon, 01 Dec 2008 06:41:23 +0100 X-Hashcash: 1:20:081201:mext@ietf.org::6QDaIZxi3U16vwYk:00004C66 X-Hashcash: 1:20:081201:whaddad@qualcomm.com::3FUAHkChOnVVgJ1n:000000000000000000000000000000000000000002FFw From: arno@natisbad.org (Arnaud Ebalard) To: IETF MEXT WG ML X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 Date: Sun, 30 Nov 2008 21:39:22 -0800 Message-ID: <87y6z0e9o5.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Subject: [MEXT] [RFC3375bis] Expected BU format and processing / associated impacts X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, First, sorry for the late post, just before the deadline (Dec 05). While studying the impacts of MIPv6 Home Link Detection mechanism in IPsec environments [1], I spent some time carefully rereading the associated reference documents (3775, 3776, 4877, ...). >From that reading, I came to the conclusion that the various possible formats allowed for the BU (when on a foreign network, at home, for deregistration or not, ...) and the way BU should be processed by the HA leave room for interoperability issues and possibly threats. This includes handling of AltCoA option and also HAO/RH2. I think the spec is too lose on those topics and rfc3775bis could be a good opportunity to make things clearer/tighter for implementors on *some* of those points. [1] is a work in progress (read 'raw material'), extracted from a bigger document, which explains the unusual format (pdf) and the fact I have currently not found the time to perform some of the tests I intend to do (on existing implementations). Read it with some salt. Anyway, I'd be interested if some among you could take a look at the document and see if some of the points raised could be handled in the context of rfc377bis (appendices contains the interesting quotes from the reference documents). Better stated explicitly: I don't expect the "Home Link Detection threat in IPsec environment" topic covered in the doc to be discussed or solved in the context of rfc3775bis. Comments welcome, Cheers, a+ [1]: http://rfc.1924.fr/ipsec-hld-threats.pdf _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 1 00:29:22 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43673A691C; Mon, 1 Dec 2008 00:29:22 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A877E3A6909; Mon, 1 Dec 2008 00:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 u9Bu5hIIP9E2; Mon, 1 Dec 2008 00:29:20 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 6B55A3A69BD; Mon, 1 Dec 2008 00:29:19 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1L749W-0005lB-7C; Mon, 01 Dec 2008 19:29:10 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Mon, 01 Dec 2008 19:29:02 +1100 From: Hesham Soliman To: Colin Perkins , , "mext@ietf.org" Message-ID: Thread-Topic: tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt Thread-Index: AclTjt1Mt+BRIKpv1kOeOuk4ZPVXHw== In-Reply-To: Mime-version: 1.0 Cc: TSV Dir Subject: Re: [MEXT] tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Colin, Thank you for the review. Please see some comments inline. > In summary, this draft seems to be on the right track but has some > open issues, as discussed below. > > The NAT keep-alive interval (Section 5.3 and 7) is set to 110 seconds > by default, unless configured by the home agent in a binding > acknowledgement. While the default interval seems a safe choice, it's > not clear why it was chosen, or when it's appropriate for a home > agent to signal an alternative interval. The draft would benefit from > an explanation of this choice, and further discussion of the issues > inherent in choosing an appropriate keep-alive interval (Section 3.5 > of RFC 5405 considers this point, and might be appropriate to > reference). => Thanks for the reference. I'll include that in the new rev. The interval was chosen based on recommendations from people with experience in NAT deployments and the WG agreed with it. But the reference will certainly help the reader. > > The NAT detection mechanism specified in Section 5.2 relies on the > NAT rewriting the source address of the outer IPv4 header, but not > the IPv4 address carried in the binding update payload. I'm not > familiar with the way in which mobile IPv6 uses IPsec ESP, but if > it's used in a way that provides integrity protection but not > confidentiality, issues may arise with NAT devices that rewrite IPv4 > addresses in the UDP payload, causing the integrity check to fail > (this is why STUN [RFC5389] provides an XOR-MAPPED-ADDRESS attribute > to obfuscate the IP address). => Well, I'm not sure how a NAT can do that. You mean the NAT will parse the binding update message deep inside the IPv6 extension header in the inner IP packet? This is where the original address is preserved. To do that, a NAT would have to understand the various MIPv6 options, and if it did, it would know not to do that :) The inner header is IPv6, so a NAT should not touch that. > > It's not clear that the use with ECN is fully specified. Section > 5.1.1 notes that it's "RECOMMENDED that the ECN information is copied > between the inner and outer header as defined in [RFC3168]" - is the > intent that the full-functionality option defined in RFC 3168 is > recommended? If so, it would be useful to state that explicitly. => Yes. I think we can explicitly mention that. This was done to follow the same rules which are done for IP in IP encapsulation, as per RFC 4213. It > also seems that UDP encapsulation will prevent the use of ECN over > the tunnel, since the UDP API doesn't allow access to the ECN bits, > and cause different ECN (and hence congestion) behaviour depending on > the encapsulation method used. This should be called out in the draft. => Ok, although I think this might not be an issue with many implementations as UDP encapsulation may be done in the kernel with the rest of the MIPv6 implementations (typically anyway). I'll add your comment to the draft. > > Processing of other IP header fields (e.g. the diffserv field and > TTL) when encapsulated in UDP tunnels also seems poorly defined. The > intent, presumably, is for the choice of tunnelling mechanism to be > hidden from higher-levels, but the exact en-/de-capsulation steps > needed to achieve this must be specified for the UDP encapsulation. > For example, when is the TTL of the encapsulated packet decremented? => It is decremented in the same way that it's done for IP in IP tunnelling. I can add that. > > Finally, the use of multiple UDP tunnelling schemes (vanilla or with > TLV-header) seems undesirable, and it would be useful to document why > this is necessary, for those not familiar with the working group > history. => Well, I personally agree with you. However, there was a concensus call in the WG about this particular issue and it was decided (narrowly) that we should include support for this. Based on my understanding, some people wanted to be able to efficiently use GRE tunnelling. While this is not useful for MIPv6 mobile nodes (typically GRE tunnelling is done in the network), people wanted to be able to use this specification for PMIPv6, which uses MIPv6 without the mobile node's involvement. Hence, the supposed need for GRE tunnelling. If you ask me why GRE tunnelling is needed at all in IPv6 then I'm not the right person to represent that opinion because I'm completely against it :) I hope this helps. Hesham > > Regards, _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 1 00:58:57 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C05A63A68C2; Mon, 1 Dec 2008 00:58:57 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2603A6A64; Mon, 1 Dec 2008 00:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.95 X-Spam-Level: X-Spam-Status: No, score=-5.95 tagged_above=-999 required=5 tests=[AWL=0.649, 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 OkSOQaL7PVbZ; Mon, 1 Dec 2008 00:53:20 -0800 (PST) Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by core3.amsl.com (Postfix) with ESMTP id C75803A68C2; Mon, 1 Dec 2008 00:53:19 -0800 (PST) Received: from starkperkins.demon.co.uk ([80.176.158.71]:60084 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1L74Wo-0001FB-FH; Mon, 01 Dec 2008 08:53:14 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Colin Perkins Date: Mon, 1 Dec 2008 08:52:40 +0000 To: Hesham Soliman X-Mailer: Apple Mail (2.753.1) X-Mailman-Approved-At: Mon, 01 Dec 2008 00:58:56 -0800 Cc: TSV Dir , ietf@ietf.org, "mext@ietf.org" Subject: Re: [MEXT] tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hesham, Thanks - one minor follow-up inline. Colin On 1 Dec 2008, at 08:29, Hesham Soliman wrote: > Colin, > > Thank you for the review. Please see some comments inline. > > >> In summary, this draft seems to be on the right track but has some >> open issues, as discussed below. >> >> The NAT keep-alive interval (Section 5.3 and 7) is set to 110 seconds >> by default, unless configured by the home agent in a binding >> acknowledgement. While the default interval seems a safe choice, it's >> not clear why it was chosen, or when it's appropriate for a home >> agent to signal an alternative interval. The draft would benefit from >> an explanation of this choice, and further discussion of the issues >> inherent in choosing an appropriate keep-alive interval (Section 3.5 >> of RFC 5405 considers this point, and might be appropriate to >> reference). > > => Thanks for the reference. I'll include that in the new rev. The > interval was chosen based on recommendations from people with > experience in NAT deployments and the WG agreed with it. But the > reference will certainly help the reader. > >> The NAT detection mechanism specified in Section 5.2 relies on the >> NAT rewriting the source address of the outer IPv4 header, but not >> the IPv4 address carried in the binding update payload. I'm not >> familiar with the way in which mobile IPv6 uses IPsec ESP, but if >> it's used in a way that provides integrity protection but not >> confidentiality, issues may arise with NAT devices that rewrite IPv4 >> addresses in the UDP payload, causing the integrity check to fail >> (this is why STUN [RFC5389] provides an XOR-MAPPED-ADDRESS attribute >> to obfuscate the IP address). > > => Well, I'm not sure how a NAT can do that. You mean the NAT will > parse the binding update message deep inside the IPv6 extension > header in the inner IP packet? This is where the original address > is preserved. To do that, a NAT would have to understand the > various MIPv6 options, and if it did, it would know not to do > that :) The inner header is IPv6, so a NAT should not touch that. My understanding from the STUN work is that NATs have been observed which rewrite any sequence of four aligned bytes matching the source IP address, irrespective of its location within the packet (section 15.2 of RFC 5389). >> It's not clear that the use with ECN is fully specified. Section >> 5.1.1 notes that it's "RECOMMENDED that the ECN information is copied >> between the inner and outer header as defined in [RFC3168]" - is the >> intent that the full-functionality option defined in RFC 3168 is >> recommended? If so, it would be useful to state that explicitly. > > => Yes. I think we can explicitly mention that. This was done to > follow the same rules which are done for IP in IP encapsulation, as > per RFC 4213. > > It >> also seems that UDP encapsulation will prevent the use of ECN over >> the tunnel, since the UDP API doesn't allow access to the ECN bits, >> and cause different ECN (and hence congestion) behaviour depending on >> the encapsulation method used. This should be called out in the >> draft. > > => Ok, although I think this might not be an issue with many > implementations as UDP encapsulation may be done in the kernel with > the rest of the MIPv6 implementations (typically anyway). I'll add > your comment to the draft. > >> Processing of other IP header fields (e.g. the diffserv field and >> TTL) when encapsulated in UDP tunnels also seems poorly defined. The >> intent, presumably, is for the choice of tunnelling mechanism to be >> hidden from higher-levels, but the exact en-/de-capsulation steps >> needed to achieve this must be specified for the UDP encapsulation. >> For example, when is the TTL of the encapsulated packet decremented? > > => It is decremented in the same way that it's done for IP in IP > tunnelling. I can add that. > >> Finally, the use of multiple UDP tunnelling schemes (vanilla or with >> TLV-header) seems undesirable, and it would be useful to document why >> this is necessary, for those not familiar with the working group >> history. > > => Well, I personally agree with you. However, there was a > concensus call in the WG about this particular issue and it was > decided (narrowly) that we should include support for this. Based > on my understanding, some people wanted to be able to efficiently > use GRE tunnelling. While this is not useful for MIPv6 mobile nodes > (typically GRE tunnelling is done in the network), people wanted to > be able to use this specification for PMIPv6, which uses MIPv6 > without the mobile node's involvement. Hence, the supposed need for > GRE tunnelling. If you ask me why GRE tunnelling is needed at all > in IPv6 then I'm not the right person to represent that opinion > because I'm completely against it :) > I hope this helps. > > Hesham > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 1 01:04:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC3A3A68C2; Mon, 1 Dec 2008 01:04:40 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FA6E3A68C2; Mon, 1 Dec 2008 01:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 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 zcZwGMOyX0sj; Mon, 1 Dec 2008 01:04:38 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 9911A3A683A; Mon, 1 Dec 2008 01:04:37 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1L74hE-0006Jy-Fl; Mon, 01 Dec 2008 20:04:31 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Mon, 01 Dec 2008 20:00:35 +1100 From: Hesham Soliman To: Colin Perkins Message-ID: Thread-Topic: tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt Thread-Index: AclTk0WdjZUk4daAZUWr985r+BYwTw== In-Reply-To: Mime-version: 1.0 Cc: TSV Dir , ietf@ietf.org, "mext@ietf.org" Subject: Re: [MEXT] tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org >> >> => Well, I'm not sure how a NAT can do that. You mean the NAT will >> parse the binding update message deep inside the IPv6 extension >> header in the inner IP packet? This is where the original address >> is preserved. To do that, a NAT would have to understand the >> various MIPv6 options, and if it did, it would know not to do >> that :) The inner header is IPv6, so a NAT should not touch that. > > My understanding from the STUN work is that NATs have been observed > which rewrite any sequence of four aligned bytes matching the source > IP address, irrespective of its location within the packet (section > 15.2 of RFC 5389). => Sounds freightning! May be we need to mandate encryption and hope that no 4-byte sequence matched the IP address? What do they do with encrypted packets? How do they know they're encrypted? Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From 2008colo2011@gmail.com Mon Dec 1 01:09:30 2008 Return-Path: <2008colo2011@gmail.com> X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECE173A68C4; Mon, 1 Dec 2008 01:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.97 X-Spam-Level: X-Spam-Status: No, score=0.97 tagged_above=-999 required=5 tests=[AWL=0.992, BAYES_00=-2.599, RAZOR2_CHECK=0.5, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08iyksQK-SiD; Mon, 1 Dec 2008 01:09:30 -0800 (PST) Received: from maildcarg4.dc-host.net.ar (maildcarg4.dc-host.net.ar [200.55.6.135]) by core3.amsl.com (Postfix) with ESMTP id 2CD773A6832; Mon, 1 Dec 2008 01:09:30 -0800 (PST) Received: from coloso ([200.122.92.50]) by maildcarg4.dc-host.net.ar (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0KB600LFWXF3WJ40@maildcarg4.dc-host.net.ar>; Mon, 01 Dec 2008 06:09:04 -0300 (ART) Date: Mon, 01 Dec 2008 06:07:42 -0300 From: "2008colo2011@gmail.com" <2008colo2011@gmail.com> Subject: COMPUTADORA ATHLON COMPLETA To: mkt 2007 <2008colo2011@gmail.com> Message-id: <3819-2200812119741999@coloso> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable COMPUTADORAS con 1 A=D1O DE GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALL= ITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS FACTURA A o B EMail: 2008colo2011@gmail=2Ecom -Modelo: ATHLON FIRE -Procesador: AMD ATHLON 64 DUAL CORE 5000+ Socket AM2 BOX -Motherboard: MSI K9N6GM-V chipset nVidia nForce 430 -Memoria: 1GB DDR2 667 -Placa de video: nVIDIA GeForce 6100GS 256MB -Disco r=EDgido: 80 GB SATA2 -Medio optico: ReGrabadora de DVD PHILIPS 20X -Placa de red: 10/100 on board -Placa de sonido: 8 canales -Puertos: 2USB frontales + 4USB traseros -Gabinete: KIT CIRKUIT PLANET 1305 -Teclado multimedia, Mouse optico, Parlantes y Diskettera 3 =BD=2E -Garantia 12 meses -Sistema operativo instalado y funcionando FULL, todos los programa y util= idades -Monitor: LCD 17" LG LS177WS Wide Screen -$1699 IVA Incluido Consulte por otras configuracion y otros productos, monitores LCD, noteboo= ks, etc