From a20092008@gmail.com Wed Oct 1 03:54:15 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5A843A6C33; Wed, 1 Oct 2008 03:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.66 X-Spam-Level: *** X-Spam-Status: No, score=3.66 tagged_above=-999 required=5 tests=[AWL=-0.963, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SUBJ_ALL_CAPS=2.077, UPPERCASE_50_75=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 j-R-t+EnGumU; Wed, 1 Oct 2008 03:54:15 -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 95CAF3A6BF4; Wed, 1 Oct 2008 03:54:15 -0700 (PDT) Received: from f3t ([190.245.3.144]) by maildcarg4.dc-host.net.ar (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0K8200EV73LE8F20@maildcarg4.dc-host.net.ar>; Wed, 01 Oct 2008 07:53:39 -0300 (ART) Date: Wed, 01 Oct 2008 07:53:46 +0200 From: "a20092008@gmail.com" Subject: NOTEBOOKS DIA DE LA MADRE To: dia de la madre Message-id: <3838-22008103155346671@f3t> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable 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: a20092008@gmail=2Ecom CEL: 15-3197-5821 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: $2850 From mext-bounces@ietf.org Wed Oct 1 10:47: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 A011A3A6909; Wed, 1 Oct 2008 10:47:14 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C046C3A6909 for ; Wed, 1 Oct 2008 10:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6iwDKqqz2Im for ; Wed, 1 Oct 2008 10:47:13 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id F0AFC3A6A7D for ; Wed, 1 Oct 2008 10:47:12 -0700 (PDT) Received: from [75.26.137.116] (helo=[10.166.255.27]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Kl5mq-0006Gn-Bw; Wed, 01 Oct 2008 13:46:56 -0400 Message-ID: <48E3B78D.6060803@wichorus.com> Date: Wed, 01 Oct 2008 10:46:53 -0700 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: mext@ietf.org X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f520e52816a50e2929ad7b39816d811b4ce350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: Jari Arkko , "mext-chairs@tools.ietf.org" Subject: [MEXT] Mobility Support in IPv6, revised (draft 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-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, As promised a few weeks ago, I have submitted the ..-02 revision of the Internet Draft for rfc3775bis. Revision ...-02 includes text to close the following issues: #1, #2, #4, #8, #9, #12, #13, and #14 The following issues are still to be resolved: #7, #10., #11, #15, #16, #17 I'll work on trying to resolve the remaining issues during the next week, and issue another draft before Minneapolis including whatever text is seen to be agreeable for those issues. Until the Internet Draft is posted, the new draft will be available at the following URL: http://psg.com/~charliep/txt/mobilev6/draft-ietf-mext-rfc3775bis-02.txt Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Oct 1 11:51: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 D0A5628C163; Wed, 1 Oct 2008 11:51:04 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9A228C163 for ; Wed, 1 Oct 2008 11:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2YoRGs54DTO for ; Wed, 1 Oct 2008 11:51:02 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id DA66028C148 for ; Wed, 1 Oct 2008 11:51:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=IJx+zzIyzMemTT/4umDTGSp4/cK862ODLakFmbR70NGg6Nu82Gr22kjd18AlG1rv; 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 [75.26.137.116] (helo=[10.166.255.27]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Kl6mR-0005aw-A2 for mext@ietf.org; Wed, 01 Oct 2008 14:50:35 -0400 Message-ID: <48E3C678.5060509@earthlink.net> Date: Wed, 01 Oct 2008 11:50:32 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: mext@ietf.org X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f523bfe5fa04fd7b184c80d7c68d0baf7c6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Subject: [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" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org 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 From mext-bounces@ietf.org Wed Oct 1 12:42: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 D39AB3A6809; Wed, 1 Oct 2008 12:42:35 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C4F03A6909 for ; Wed, 1 Oct 2008 12:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwoHm5pkuA2x for ; Wed, 1 Oct 2008 12:42:33 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 94B393A67A6 for ; Wed, 1 Oct 2008 12:42:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=qCKwYAzny2HlaHEExkFjSGh59tqAd/qJuStEAiqqlijj6MBqb8z9L2wtVgclHXhk; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.27]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Kl7b5-00036D-Lv; Wed, 01 Oct 2008 15:42:55 -0400 Message-ID: <48E3D2BC.6020800@earthlink.net> Date: Wed, 01 Oct 2008 12:42:52 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: mext@ietf.org X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f520b48571cf2a5d7a6fc632fcd04391a6e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Subject: [MEXT] Issue #15: BRR sent by HA too, not only by CN X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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, Here is the URL for the discussion: http://trac.tools.ietf.org/wg/mext/trac/ticket/15 I think it is clear that RFC3775 restricts the BRR to be used by the correspondent nodes. Of course, any node (including a home agent) can also host correspondent node protocol operations, but for the purposes of this discussion such a node should be called a correspondent node regardless of whether or not it is also a home agent. As one example, section 6.1.2 states: The Binding Refresh Request (BRR) message requests a mobile node to update its mobility binding. This message is sent by correspondent nodes according to the rules in Section 9.5.5. I don't think that there has been much support for changing the standardized usage of BRR to include new functionality at the home agent. Since the mobile node has to request acknowledgement, there is little likelihood that a lost BU would go unnoticed by the mobile node. Thus there is little likelihood that the home agent would need to remind the mobile node that it was time to update its binding. I propose that this issue be closed with no further changes to rfc3775bis. I don't find that the existing text is unclear, and there is no suggestion that the home agent, in its role as the mobility anchor and router for the mobile node, needs to send BRR for other reasons. If anyone finds some text in the document that is not clear on this point, please let me know. I searched for every occurrence of "Binding Refresh" and "BRR" and did not find problems. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Oct 1 14:45: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 C8E6328C20B; Wed, 1 Oct 2008 14:45:11 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CF14628C1EF; Wed, 1 Oct 2008 14:45:06 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081001214506.CF14628C1EF@core3.amsl.com> Date: Wed, 1 Oct 2008 14:45:06 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D ACTION:draft-ietf-mext-rfc3775bis-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 : Mobility Support in IPv6 Author(s) : D. Johnson, C. Perkins, J. Arkko Filename : draft-ietf-mext-rfc3775bis-02.txt Pages : 174 Date : 2008-10-1 This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-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-rfc3775bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-1144238.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 Wed Oct 1 14:48: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 CA74028C1FD; Wed, 1 Oct 2008 14:48:39 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AA1D28C1ED for ; Wed, 1 Oct 2008 14:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 gxUNa8VlIFY9 for ; Wed, 1 Oct 2008 14:48:38 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.245.51]) by core3.amsl.com (Postfix) with SMTP id D98F428C163 for ; Wed, 1 Oct 2008 14:48:37 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1222897736!32996393!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 11465 invoked from network); 1 Oct 2008 21:48:56 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-119.messagelabs.com with SMTP; 1 Oct 2008 21:48:56 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m91LmuSf024630; Wed, 1 Oct 2008 14:48:56 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id m91LmtFf011880; Wed, 1 Oct 2008 16:48:55 -0500 (CDT) Received: from [127.0.0.1] ([10.129.40.75]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id m91LmrbB011863; Wed, 1 Oct 2008 16:48:54 -0500 (CDT) Message-ID: <48E3F044.1040804@gmail.com> Date: Wed, 01 Oct 2008 23:48:52 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Charles E. Perkins" References: <48E3D2BC.6020800@earthlink.net> In-Reply-To: <48E3D2BC.6020800@earthlink.net> X-Antivirus: avast! (VPS 081001-0, 01/10/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] Issue #15: BRR sent by HA too, not only by CN X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Charles, First thanks for taking detailed care of this issue (among the others). Charles E. Perkins wrote: > > Hello folks, > > Here is the URL for the discussion: > http://trac.tools.ietf.org/wg/mext/trac/ticket/15 > > I think it is clear that RFC3775 restricts the BRR to be used by the > correspondent nodes. Of course, any node (including a home agent) > can also host correspondent node protocol operations, but for the > purposes of this discussion such a node should be called a > correspondent node regardless of whether or not it is also a home > agent. This clarification could be stated, like saying 'for BRR, the HA is not a CN'. This is paramount help for implementer planning for the features to implement. > As one example, section 6.1.2 states: The Binding Refresh Request > (BRR) message requests a mobile node to update its mobility binding. > This message is sent by correspondent nodes according to the rules in > Section 9.5.5. > > I don't think that there has been much support for changing the > standardized usage of BRR to include new functionality at the home > agent. Since the mobile node has to request acknowledgement, there is > little likelihood that a lost BU would go unnoticed by the mobile > node. Thus there is little likelihood that the home agent would need > to remind the mobile node that it was time to update its binding. Well yes, the MN can timeout when the sent BU is unreplied. But logically, the HA can't distinguish whether the BU was sent and lost, or hasn't been sent at all. Having the HA do a BRR when _its_ timer expired (HA's timer) clearl makes sense towards a more reliable exchange. > I propose that this issue be closed with no further changes to > rfc3775bis. I don't find that the existing text is unclear, and > there is no suggestion that the home agent, in its role as the > mobility anchor and router for the mobile node, needs to send BRR for > other reasons. Maybe one would exemplify how HA sending BRR breaks something. Maybe it's just perceived as an unnecessary textual change. In a 150+ pp document this reticence could be justified. > If anyone finds some text in the document that is not clear on this > point, please let me know. I searched for every occurrence of > "Binding Refresh" and "BRR" and did not find problems. Just that at some point it's said that HA acts as a CN (and CN sends BRR), but you already said that. That's all I could think of. Thanks, Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Oct 1 14:50: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 87ECA28C209; Wed, 1 Oct 2008 14:50:38 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 584C928C163 for ; Wed, 1 Oct 2008 14:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.767 X-Spam-Level: X-Spam-Status: No, score=-5.767 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 i3aJOz9L1ObM for ; Wed, 1 Oct 2008 14:50:36 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 523DB28C1E0 for ; Wed, 1 Oct 2008 14:50:09 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1222897808!3794714!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 32005 invoked from network); 1 Oct 2008 21:50:08 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with SMTP; 1 Oct 2008 21:50: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 m91Lo8cq024859; Wed, 1 Oct 2008 14:50:08 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id m91Lo7Z6012334; Wed, 1 Oct 2008 16:50:07 -0500 (CDT) Received: from [127.0.0.1] ([10.129.40.75]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id m91Lo521012318; Wed, 1 Oct 2008 16:50:06 -0500 (CDT) Message-ID: <48E3F08D.5030605@gmail.com> Date: Wed, 01 Oct 2008 23:50:05 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 References: <48E3D2BC.6020800@earthlink.net> <48E3F044.1040804@gmail.com> In-Reply-To: <48E3F044.1040804@gmail.com> X-Antivirus: avast! (VPS 081001-0, 01/10/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext@ietf.org Subject: Re: [MEXT] Issue #15: BRR sent by HA too, not only by CN X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Sorry following up my own message, I forgot to say I agree with the resolution. Alex Alexandru Petrescu wrote: > Charles, > > First thanks for taking detailed care of this issue (among the others). > > Charles E. Perkins wrote: >> >> Hello folks, >> >> Here is the URL for the discussion: >> http://trac.tools.ietf.org/wg/mext/trac/ticket/15 >> >> I think it is clear that RFC3775 restricts the BRR to be used by the >> correspondent nodes. Of course, any node (including a home agent) >> can also host correspondent node protocol operations, but for the >> purposes of this discussion such a node should be called a >> correspondent node regardless of whether or not it is also a home >> agent. > > This clarification could be stated, like saying 'for BRR, the HA is not > a CN'. This is paramount help for implementer planning for the features > to implement. > >> As one example, section 6.1.2 states: The Binding Refresh Request >> (BRR) message requests a mobile node to update its mobility binding. >> This message is sent by correspondent nodes according to the rules in >> Section 9.5.5. >> >> I don't think that there has been much support for changing the >> standardized usage of BRR to include new functionality at the home >> agent. Since the mobile node has to request acknowledgement, there is >> little likelihood that a lost BU would go unnoticed by the mobile >> node. Thus there is little likelihood that the home agent would need >> to remind the mobile node that it was time to update its binding. > > Well yes, the MN can timeout when the sent BU is unreplied. > > But logically, the HA can't distinguish whether the BU was sent and > lost, or hasn't been sent at all. Having the HA do a BRR when _its_ > timer expired (HA's timer) clearl makes sense towards a more reliable > exchange. > >> I propose that this issue be closed with no further changes to >> rfc3775bis. I don't find that the existing text is unclear, and >> there is no suggestion that the home agent, in its role as the >> mobility anchor and router for the mobile node, needs to send BRR for >> other reasons. > > Maybe one would exemplify how HA sending BRR breaks something. Maybe > it's just perceived as an unnecessary textual change. In a 150+ pp > document this reticence could be justified. > >> If anyone finds some text in the document that is not clear on this >> point, please let me know. I searched for every occurrence of >> "Binding Refresh" and "BRR" and did not find problems. > > Just that at some point it's said that HA acts as a CN (and CN sends > BRR), but you already said that. That's all I could think of. > > Thanks, > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mohammedibn@live.com Thu Oct 2 11:04:18 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E947E3A6B07 for ; Thu, 2 Oct 2008 11:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -77.163 X-Spam-Level: X-Spam-Status: No, score=-77.163 tagged_above=-999 required=5 tests=[ADVANCE_FEE_2=1.234, ADVANCE_FEE_3=1.432, AWL=-0.042, BAYES_99=3.5, DEAR_FRIEND=2.699, FORGED_MUA_OUTLOOK=3.116, FORGED_OUTLOOK_HTML=0.001, FORGED_OUTLOOK_TAGS=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_81=0.6, MIME_HTML_ONLY=1.457, MSOE_MID_WRONG_CASE=0.82, NA_DOLLARS=1.329, RAZOR2_CHECK=0.5, SUBJ_ALL_CAPS=2.077, UPPERCASE_75_100=1.528, USER_IN_WHITELIST=-100, XMAILER_MIMEOLE_OL_1ECD5=1.034] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FN25CDQuvXe for ; Thu, 2 Oct 2008 11:04:14 -0700 (PDT) Received: from smtp20.orange.fr (smtp20.orange.fr [80.12.242.26]) by core3.amsl.com (Postfix) with ESMTP id ECB9F3A6AD6 for ; Thu, 2 Oct 2008 11:04:13 -0700 (PDT) Received: from User (82.Red-81-47-155.staticIP.rima-tde.net [81.47.155.82]) by mwinf2003.orange.fr (SMTP Server) with ESMTP id 0613E1C008EF; Thu, 2 Oct 2008 20:03:59 +0200 (CEST) X-ME-UUID: 20081002180400251.0613E1C008EF@mwinf2003.orange.fr Reply-To: From: "IBN MOHAMMED MOHAMMED" Subject: DEAR FRIEND Date: Thu, 2 Oct 2008 11:04:07 -0700 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1081 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1081 Message-Id: <20081002180359.0613E1C008EF@mwinf2003.orange.fr> To: undisclosed-recipients:;
DEAR FRIEND,
I AM IBN MOHAMMED MOHAMMED,I AM 67YEARS OLD.I AM A
CITIZEN OF SAUDI ARABIA, BUT I AM RESIDENT IN CAYMAN
ISLAND.
 
I WAS BORN AN ORPHAN AND ALMIGHTY ALLAH BLESSED ME
ABUNDANTLY WITH RICHES,BUT I AM NOT A HAPPY MAN.I HAVE
NO WIFE AND I HAVE NO CHILDREN. AS AT NOW I AM
SERIOUSLY SICK.I AM PRESENTLY IN HOSPITAL SUFFERING
FROM LUNG CANCER AND I HAD PATIAL STROKE WHICH HAS
AFFECTED MY SPEECH. I CAN NO LONGER TALK AND I AM ALSO
DEAF. HALF OF MY BODY IS PARALYSED. THE DOCTORS SAY I
HAVE ABOUT 2 MOUNTHS TO LIVE. I SEND YOU THIS MAIL
WITH THE HELP OF MY PRIVATE NURSE, ASSISTING ME.
 
I HAVE LITTLE TIME SO I HAVE COMMITTED IT TO SPREADING
MY WEALTH TOWARDS BETTER HEALTH CARE FOR MANKIND.IN
THE HOSPITAL WHERE I AM ,I HAVE GIVEN THE MANAGEMENT
US$15MILLION TO UPGRADE AND BUILD A NEW CANCER RESEACH
FACILITY.
 
I DONT KNOW YOU, BUT DUE TO MY CONDITION I AM
CONTACTING YOU WITH THE HOPE THAT YOU WILL CARRYOUT MY
WISH FOR THE SAKE OF HUMANITY.
 
I HAVE TWO BOXES OF GOLD AND CASH DEPOSITED WITH A SECURITY
DEPOSIT COMPANY THE CASH IS 5MILLION U.S DOLLARS .I WANT YOU TO SELL THE GOLD,ADD THE 5 MILLION TO IT AND USE IT TO BUILD AN ORPHANAGE IN YOUR COUNTRY. YOU WILL NAME IT MOHAMMED ORPHANAGE HOME. YOU MUST FOLLOW MY WISH FOR IT WILL GLADEN THE HEART OF ALMIGHTY
ALLAH.
 
IF YOU ARE READY TO DO THIS AND CARRYOUT MY WISH, THEN
SEND ME
[1]YOUR FULL NAMES
[2] YOUR PHONE/FAX NUMBER
[3] AND YOUR RESIDENTIAL ADDRESS.
 
WITH THE HELP OF MY NURSE I WILL BE IN CONTACT WITH
YOU.MY EMAIL infosolenids@comcast.net
 
I AWAIT YOUR REPLY.
 
IBN MOHD MOHAMMED
 
 From mext-bounces@ietf.org Thu Oct 2 14:45: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 4BED23A69EE; Thu, 2 Oct 2008 14:45:36 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B63633A69EE for ; Thu, 2 Oct 2008 14:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6fyk-zAP3B9 for ; Thu, 2 Oct 2008 14:45:34 -0700 (PDT) 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 A45A33A693C for ; Thu, 2 Oct 2008 14:45:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=c4v2/bawzvM3YeOr9GiK8TLhTw6hOFRX9KK03Q93PRWt7ttMjwhZaHlM04V6ksls; 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.255.16]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KlVzj-0004HY-Gq; Thu, 02 Oct 2008 17:45:59 -0400 Message-ID: <48E54114.6010503@earthlink.net> Date: Thu, 02 Oct 2008 14:45:56 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Alexandru Petrescu References: <48E3D2BC.6020800@earthlink.net> <48E3F044.1040804@gmail.com> In-Reply-To: <48E3F044.1040804@gmail.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f524fd1266ab6eaf7ce4b931032daf2e8ff350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: mext@ietf.org Subject: Re: [MEXT] Issue #15: BRR sent by HA too, not only by CN X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Alex, Alexandru Petrescu wrote: >> >> I think it is clear that RFC3775 restricts the BRR to be used by the >> correspondent nodes. Of course, any node (including a home agent) >> can also host correspondent node protocol operations, but for the >> purposes of this discussion such a node should be called a >> correspondent node regardless of whether or not it is also a home >> agent. > > This clarification could be stated, like saying 'for BRR, the HA is > not a CN'. This is paramount help for implementer planning for the > features to implement. I confess that I am not sure what the intention would be for the suggested text in quotes. > >> As one example, section 6.1.2 states: The Binding Refresh Request >> (BRR) message requests a mobile node to update its mobility binding. >> This message is sent by correspondent nodes according to the rules in >> Section 9.5.5. >> >> I don't think that there has been much support for changing the >> standardized usage of BRR to include new functionality at the home >> agent. Since the mobile node has to request acknowledgement, there is >> little likelihood that a lost BU would go unnoticed by the mobile >> node. Thus there is little likelihood that the home agent would need >> to remind the mobile node that it was time to update its binding. > > Well yes, the MN can timeout when the sent BU is unreplied. > > But logically, the HA can't distinguish whether the BU was sent and > lost, or hasn't been sent at all. Having the HA do a BRR when _its_ > timer expired (HA's timer) clearl makes sense towards a more reliable > exchange. But it is just this use of BRR that is at issue. On the one hand, we have that the MN should be responsible for making sure that the BU is sent and acknowledged. On the other hand, you suggest that the home agent should remind the MN that the binding is timing out. I believe that the MN should be designed to avoid the need for this reminder. > >> I propose that this issue be closed with no further changes to >> rfc3775bis. I don't find that the existing text is unclear, and >> there is no suggestion that the home agent, in its role as the >> mobility anchor and router for the mobile node, needs to send BRR for >> other reasons. > > Maybe one would exemplify how HA sending BRR breaks something. Maybe > it's just perceived as an unnecessary textual change. In a 150+ pp > document this reticence could be justified. If it were just adding the text, of course I would not mind. The prospect of having the home agent send out reminders for dozens or hundreds of mobile nodes per hour, that may even have powered down, seems like a bad idea to me. That's how I would exemplify the downside. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Oct 2 15:37: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 58CFA3A6A8A; Thu, 2 Oct 2008 15:37:38 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296C83A6A8A for ; Thu, 2 Oct 2008 15:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OC3J9S+BtRJ4 for ; Thu, 2 Oct 2008 15:37:36 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 276BA3A69D1 for ; Thu, 2 Oct 2008 15:37:36 -0700 (PDT) Received: from [75.26.137.116] (helo=[10.166.255.16]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KlWo6-0007A0-Sm; Thu, 02 Oct 2008 18:38:03 -0400 Message-ID: <48E54D49.9000109@computer.org> Date: Thu, 02 Oct 2008 15:38:01 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: pthubert@cisco.com References: <063.c95a2d67b2a3a9638c10a31fe147cbed@tools.ietf.org> In-Reply-To: <063.c95a2d67b2a3a9638c10a31fe147cbed@tools.ietf.org> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f529142a1ec582f4a354de2dab03cf0fad9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #16: HA behaviour upon MN returning Home [Pascal Thubert ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Pascal, I have some thoughts about this issue. mext wrote: > > With both the original RFC 3775 and the current rework, a HA that has a > binding to a Home Address owns that Home Adddress over the Home Link > till either the node unbinds or the binding times out. Until then the HA > will defend that Home Address using the Override bit in the NA messages > over the Home Link, and until then a mobile node would be out of > compliance > to use its Home Address if it is at Home or switch to another HA if it is > not at Home. > > There are multiple issues with this behaviour: > > - service: Whether it is at Home or not, a node that looses the states > about its current binding might be unreachable until the end of its > binding lifetime. It will take a manual operation to recover from that > situation when the lifetime is too long. And it will cause excess > traffic or load on the HAs if the lifetime is too short. In any case > there will be a service disruption that the user might perceive. Here, we have to imagine that a mobile node would lose the state of its mobility security association, and yet not lose its home address or other information. Or, that it would show up on its home network and run DHCP after suffering from the loss of state, while not running any mobility-related bootstrapping procedures. It's not a totally convincing scenario to me. > > - security: The HA defends an address that it does not own so it can not > prove it owns it. With SeND, it would just be nonsense for a HA to try > and reclaim SeND based addresses when a MN proves ownership on link. It seems to me that this should be understood as a phenomenon described as part of the SeND documentation. If there is support for making some relevant clarification as part of rfc3775bis, would you be willing to write up some proposed text? > > - compatibility with other proxies: The HA performs a form of ND > proxying for the Mobile Node. We can expect that there will be new forms > of ND proxies coming up - see for instance > http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-01 -, > and there should be a common behaviour over a shared link for proxies, > regardless of the registration mechanism; in particular a proxy should > yield in the face of the object it proxies for. I agree with your last statement, and yet I don't see this general statement as fitting very well as part of rfc3775bis. > > - speed: A Mobile Node reaching Home should be able to use its Home > Address as optimistic (RFC 4429) right away like it could do on any > visited link with any CoA. This is a stronger argument I think, and yet still suffers because the basic scenario about selectively losing state has debatable relevance. > > > Proposed resolution: > > The proposal to fix this issue is to let the MN use DAD/oDAD over the > Home Link with its Home Address. A proxy would defend the address > without the O bit, and the MN would ignore it, and upon DAD completion, > NA(Override) its address. The HA would be allowed to set the override > bit only within a binding flow, when it knows synchronously that it > represents the live MN. That would enable new HA to take over old HA > when the MN looses states away from home. That would also enable MN to > make before break a tunnel with new HA. Depending on whether there is support in the working group, this modification might be workable. So far, I can't think of any major damage to any other part of rfc3775bis. But, as pointed out, it is a significant change to the existing protocol and should not be undertaken lightly on the basis of only the existing discussion so far. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Oct 2 16:51: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 B38A33A68B2; Thu, 2 Oct 2008 16:51:18 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A35C3A68B2 for ; Thu, 2 Oct 2008 16:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bnbqm0PmCzLk for ; Thu, 2 Oct 2008 16:51:17 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id DFC2E3A67F2 for ; Thu, 2 Oct 2008 16:51:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=hLvW2FVKlKCCDYc/oVoTNKlExTjyyF4WwZUHLpYlZQmZufVee+td7GA0h7U0RA5F; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.255.16]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KlXwd-00076f-T9; Thu, 02 Oct 2008 19:50:56 -0400 Message-ID: <48E55E5F.5040101@earthlink.net> Date: Thu, 02 Oct 2008 16:50:55 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Benjamin Lim X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52fb64ba39de1efdc7dfe1c97656cafc40350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: mext@ietf.org Subject: [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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org 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. 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 From mext-bounces@ietf.org Thu Oct 2 19:08: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 377E33A68E8; Thu, 2 Oct 2008 19:08:57 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D1E63A68E8 for ; Thu, 2 Oct 2008 19:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXuCCfRn1KKM for ; Thu, 2 Oct 2008 19:08:54 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 404783A6899 for ; Thu, 2 Oct 2008 19:08:54 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m93292lG004937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 2 Oct 2008 19:09:07 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m93292lX019443; Thu, 2 Oct 2008 21:09:02 -0500 (CDT) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m93292QK019437 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 2 Oct 2008 21:09:02 -0500 (CDT) Received: from XCH-NW-CCR1V.nw.nos.boeing.com ([130.247.64.17]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Thu, 2 Oct 2008 19:09:01 -0700 From: "Davis, Terry L" To: "Charles E. Perkins" , Benjamin Lim Date: Thu, 2 Oct 2008 19:09:00 -0700 Thread-Topic: [MEXT] Issue #17: Multi-homed mobile node can cause routing loopbetween home agents Thread-Index: Ackk6dahZkovgSniRxin3yd1LeKW0wAECKxQ Message-ID: <2557049CDBC35B4EBD79CFACFEC045840ABA72E6@XCH-NW-CCR1V.nw.nos.boeing.com> References: <48E55E5F.5040101@earthlink.net> In-Reply-To: <48E55E5F.5040101@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1285-5.500.1027-16194.002 x-tm-as-result: No--63.194700-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can cause routing loopbetween 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 Charlie Seems like a potential solution; but I'm not sure the cause would necessarily relate to security. The natural state of an aircraft will be to attempt to be multi-homed in the "Air Traffic Management Network" (ATN) domain with two or more active links and most of the links available to an aircraft will be "narrow-band", a megabit or less. If we do really well, our new aviation communication link providers may get us to a shared "broadband" link capability of 10 megabits. The good thing is that this ATN domain will likely be run as a closed network so that routing loops only impact the ATN domain. (Our existing OSI "broadband links", which we don't intend to convert to IP, run from 2K "bits" to 30K "bits".) However the other two aircraft network domains will have the potential to impact general Internet routing with their mobility services; "airline operations" which will look like a corporate business network and "passenger Internet and Entertainment" which will look like an ISP. And at least at times, both may be multi-homed, if for no other reason than the satellite handoffs or air-to-ground tower handoffs being done at layer three instead of two. Take care Terry > -----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 > loopbetween 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. > > 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 From mext-bounces@ietf.org Thu Oct 2 19:51: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 8D0133A6821; Thu, 2 Oct 2008 19:51:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB24E3A6821 for ; Thu, 2 Oct 2008 19:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkXJJ7H9CliK for ; Thu, 2 Oct 2008 19:51:49 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 938243A6810 for ; Thu, 2 Oct 2008 19:51:48 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id m932q7T1009541; Fri, 3 Oct 2008 11:52:07 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id m932q7Q08684; Fri, 3 Oct 2008 11:52:07 +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 m932q3F18305; Fri, 3 Oct 2008 11:52:04 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Oct 2008 10:49:29 +0800 Message-ID: <48E58839.4040606@sg.panasonic.com> Date: Fri, 03 Oct 2008 10:49:29 +0800 From: Benjamin Lim User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Davis, Terry L" , "Charles E. Perkins" References: <48E55E5F.5040101@earthlink.net> <2557049CDBC35B4EBD79CFACFEC045840ABA72E6@XCH-NW-CCR1V.nw.nos.boeing.com> In-Reply-To: <2557049CDBC35B4EBD79CFACFEC045840ABA72E6@XCH-NW-CCR1V.nw.nos.boeing.com> X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 03 Oct 2008 02:49:29.0698 (UTC) FILETIME=[A8168420:01C92502] Cc: "mext@ietf.org" Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can cause routing loopbetween 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 Charlie and Terry, I agree with Charlie that using TEL option would ensure that packets does not stay in the loop for a long time. But this might not fully solve the problem, as the loop still exist. I think a solution to the problem can be seen as two steps. (a) A loop detection mechanism at HA. (b) A correction procedure when a loop is being detected. For (a), there would a draft submitted to the coming IETF meeting for discussion. The general idea is to tag a packet with some ID that HA can identify if the packet is looped. For (b), my understanding from Terry would be that the correction steps to be taken would be based on the policy of controller of the network. I.e. for aviation, they can have a policy that states that if loop is detected for ATN traffic, its ok. If loop is detected for operations and passenger traffic, then HAs would remove the affected binding to break the loop. Regards, Benjamin Lim Davis, Terry L wrote: > Charlie > > Seems like a potential solution; but I'm not sure the cause would necessarily relate to security. > > The natural state of an aircraft will be to attempt to be multi-homed in the "Air Traffic Management Network" (ATN) domain with two or more active links and most of the links available to an aircraft will be "narrow-band", a megabit or less. If we do really well, our new aviation communication link providers may get us to a shared "broadband" link capability of 10 megabits. The good thing is that this ATN domain will likely be run as a closed network so that routing loops only impact the ATN domain. > > (Our existing OSI "broadband links", which we don't intend to convert to IP, run from 2K "bits" to 30K "bits".) > > However the other two aircraft network domains will have the potential to impact general Internet routing with their mobility services; "airline operations" which will look like a corporate business network and "passenger Internet and Entertainment" which will look like an ISP. And at least at times, both may be multi-homed, if for no other reason than the satellite handoffs or air-to-ground tower handoffs being done at layer three instead of two. > > > Take care > Terry > > > > > >> -----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 >> loopbetween 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. >> >> 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 From mext-bounces@ietf.org Thu Oct 2 20:26: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 9171E3A68CD; Thu, 2 Oct 2008 20:26:35 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39FD83A68CD for ; Thu, 2 Oct 2008 20:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ugieTC5uFlf for ; Thu, 2 Oct 2008 20:26:33 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 37F523A6827 for ; Thu, 2 Oct 2008 20:26:33 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m933QmnD012923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 2 Oct 2008 20:26:57 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m933Qm1m019667; Thu, 2 Oct 2008 20:26:48 -0700 (PDT) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m933QmM6019664 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 2 Oct 2008 20:26:48 -0700 (PDT) Received: from XCH-NW-CCR1V.nw.nos.boeing.com ([130.247.64.17]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Thu, 2 Oct 2008 20:26:47 -0700 From: "Davis, Terry L" To: Benjamin Lim , "Charles E. Perkins" Date: Thu, 2 Oct 2008 20:26:46 -0700 Thread-Topic: [MEXT] Issue #17: Multi-homed mobile node can cause routing loopbetween home agents Thread-Index: AcklAwgiUwEkD1dbSDqLx9xBKSRy1QABFKcQ Message-ID: <2557049CDBC35B4EBD79CFACFEC045840ABA72F1@XCH-NW-CCR1V.nw.nos.boeing.com> References: <48E55E5F.5040101@earthlink.net> <2557049CDBC35B4EBD79CFACFEC045840ABA72E6@XCH-NW-CCR1V.nw.nos.boeing.com> <48E58839.4040606@sg.panasonic.com> In-Reply-To: <48E58839.4040606@sg.panasonic.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1285-5.500.1027-16194.002 x-tm-as-result: No--74.385000-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can cause routing loopbetween 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 Benjamin It would not "be ok" for the ATN to loop; it just wouldn't affect the global Internet routing, just ATN. The onboard policy routing would hopefully prevent the loop in any case for any of the networks. Take care Terry > -----Original Message----- > From: Benjamin Lim [mailto:benjamin.limck@sg.panasonic.com] > Sent: Thursday, October 02, 2008 7:49 PM > To: Davis, Terry L; Charles E. Perkins > Cc: mext@ietf.org > Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can cause routing > loopbetween home agents > > Hi Charlie and Terry, > > I agree with Charlie that using TEL option would ensure that packets > does not stay in the loop for a long time. But this might not fully > solve the problem, as the loop still exist. > > I think a solution to the problem can be seen as two steps. > > (a) A loop detection mechanism at HA. > (b) A correction procedure when a loop is being detected. > > For (a), there would a draft submitted to the coming IETF meeting for > discussion. The general idea is to tag a packet with some ID that HA > can identify if the packet is looped. > > For (b), my understanding from Terry would be that the correction steps > to be taken would be based on the policy of controller of the network. > I.e. for aviation, they can have a policy that states that if loop is > detected for ATN traffic, its ok. If loop is detected for operations and > passenger traffic, then HAs would remove the affected binding to break > the loop. > > Regards, > Benjamin Lim > > Davis, Terry L wrote: > > Charlie > > > > Seems like a potential solution; but I'm not sure the cause would > necessarily relate to security. > > > > The natural state of an aircraft will be to attempt to be multi-homed in > the "Air Traffic Management Network" (ATN) domain with two or more active > links and most of the links available to an aircraft will be "narrow-band", > a megabit or less. If we do really well, our new aviation communication > link providers may get us to a shared "broadband" link capability of 10 > megabits. The good thing is that this ATN domain will likely be run as a > closed network so that routing loops only impact the ATN domain. > > > > (Our existing OSI "broadband links", which we don't intend to convert to > IP, run from 2K "bits" to 30K "bits".) > > > > However the other two aircraft network domains will have the potential > to impact general Internet routing with their mobility services; "airline > operations" which will look like a corporate business network and > "passenger Internet and Entertainment" which will look like an ISP. And > at least at times, both may be multi-homed, if for no other reason than > the satellite handoffs or air-to-ground tower handoffs being done at layer > three instead of two. > > > > > > Take care > > Terry > > > > > > > > > > > >> -----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 > >> loopbetween 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. > >> > >> 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 From mext-bounces@ietf.org Fri Oct 3 11:10: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 85DC43A6A86; Fri, 3 Oct 2008 11:10:23 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C4053A6986 for ; Fri, 3 Oct 2008 11:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L16gW1pa61Ub for ; Fri, 3 Oct 2008 11:10:20 -0700 (PDT) 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 66F913A6839 for ; Fri, 3 Oct 2008 11:10:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=mIbBLBqMIPtGUq3IiTruUxDQajMrgKQ/sMFxTas/md0kEQmCcDzdS0jsmCOjPZnC; 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.255.15]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Klp70-0007m5-UA; Fri, 03 Oct 2008 14:10:47 -0400 Message-ID: <48E66025.8090007@earthlink.net> Date: Fri, 03 Oct 2008 11:10:45 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Ryuji Wakikawa References: <248F3F2E-4373-4653-B579-B9C6714498A2@gmail.com> <20DF8E07-3D15-471E-81DA-6F8C0486940E@elevatemobile.com> <7B0B4760-CAAA-45C0-91B1-D32BA5034926@gmail.com> <00a001c88a6b$7b53c380$7471510a@psl.local> <47F4A002.5040109@gmail.com> In-Reply-To: <47F4A002.5040109@gmail.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52e4fdf6a379feb50e24da3f95167a44cc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: mext@ietf.org Subject: [MEXT] Issue #10: The usage of "HA lifetime" (RFC3775-update) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Ryuji, I'd like to suggest a resolution to this issue. First, it's interesting to note that not all IPv6 addresses come equipped with lifetimes. For instance, DNS server addresses are supplied by DHCP without any associated address lifetime. I think it is O.K. to have the home agent address lifetime. treated similarly. If the mobile node is preconfigured with a home agent address, that information should not be timed out by way of any default lifetime. Similarly, the home agent addresses supplied in the "Home Agent Address Discovery Reply" message are not equipped with lifetimes. So, I think that any home agent that was discovered in this way should be used in the same way as a preconfigured home agent address, and not timed out. On the other hand, home agent addresses discovered by way of local Router Advertisement messages (containing the Prefix Information option) do have address lifetimes. However, in this case the presumption is that the the Advertisement messages are beaconed periodically, and that each periodic advertisement updates the time-out schedule at each receiver on the subnet. Thus, effectively, the typical scenario is that the home agent address seldom times out at any device receiving the Advertisement messages. Of course, if the home agent dies and no longer sends advertisements, the home agent address information has to be expunged. But this does not happen very often, and should not be the model for operation when the Advertisements are no longer available due to node movement. Thus, in all cases, it seems to me that allowing the Home Agent address information to expire is counter to the operational intention as indicated in RFC 3775. Conceptually, this depends on the mobile node being able to distinguish between loss of connectivity to the home network due to mobility, versus loss of neighbor connectivity to the home agent on the home network. We can presume that an operational IPv6 network has Internet connectivity and thus a local router. Then, this can be done if the mobile node keeps track of advertisements on its home subnet, for which it does have a record of the subnet prefix. When there are no advertisements from the home network, the mobile node can take action as if it had moved away -- and keep the home agent address without applying any timeout. When there are advertisements from the home network, but no more advertisements from the mobile node's home agent, it should act as if the home agent was no longer accessible, and apply the address lifetime to the home agent's IPv6 address. If this is agreeable, I will craft some clarifying text for rfc3775bis. Or, even better, I would happily accept text from others containing an acceptable resolution to this issue. Comments? Regards, Charlie P. Ryuji Wakikawa wrote: > Hi George > > In my previous email, I tried to figure out why DHAAD does not provide > HA lifetime. > My guess was that the HA lifetime is originally proposed for HA who manages > other HAs at the home link by original authors. > I think my guess was wrong... > > Anyway, if MN manages the HA lifetime if the lifetime is available, we > need some > operational description when the lifetime is not available. > RFC3775 clearly said that the HA entry MUST be deleted when its lifetime > is expired. > BUT the lifetime is not always available... > > So far, we have two options for this. > > 1. George > No cache. MN does not record the HA information in its home agent list. > 2. Vijay > Local configuration matter. No modification is required to RFC3775. > > I personally agree with Vijay, but I think we need some clarification > for this in the bis. > We might need to define the default value for the locally configured HA > lifetime.. > > regards, > ryuji > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Oct 3 11:22: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 F1E393A6839; Fri, 3 Oct 2008 11:22:21 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135E93A6814 for ; Fri, 3 Oct 2008 11:22:20 -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.098, 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 rEuFIryCbG6l for ; Fri, 3 Oct 2008 11:22:19 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 25A8728C0D8 for ; Fri, 3 Oct 2008 11:22:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=q/Do3Kii205HGIwQDrbrpdQ3p+fRCLRuwc7nvCkcHiXpGrPfnG8nBIOINO+WWa6f; 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.255.15]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KlpHt-0000rW-PW; Fri, 03 Oct 2008 14:22:01 -0400 Message-ID: <48E662C8.5090103@earthlink.net> Date: Fri, 03 Oct 2008 11:22:00 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Benjamin Lim References: <47F4A002.5040109@gmail.com> <002201c8961b$805cfc00$7471510a@psl.local> In-Reply-To: <002201c8961b$805cfc00$7471510a@psl.local> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5256d54195031d7e7ed732671ea86ef34e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: mext@ietf.org Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) -- list processing X-BeenThere: mext@ietf.org X-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 Benjamin, Along the way to resolving issue #10, I had some thoughts about the points you raised. If you go along with my suggestion that the home agent addresses supplied in the Home Agent Address Discovery Reply message do not have lifetimes associated with the addresses, then we can make a reasonable suggestion about list maintenance and processing. I would suggest that the home agent addresses obtained from the Reply message should be stored and used as necessary. When the current home agent becomes inaccessible, the mobile node should try to send an update to the next home agent on the list. When one of the home agents on the list seems unresponsive, it should be deleted from the list of available home agents. When the list is depleted, the mobile node can re-attempt the discovery process. But these are rare events. Perhaps the mobile node would have to try the discovery process on a timescale measured in months or years, under most scenarios for administering the home network. If you agree with this, then I guess there is again a need for some clarifying text in section 11.4.1. Contributions are always welcome. The previous discussion points are documented at the following URL: http://trac.tools.ietf.org/wg/mext/trac/ticket/10 Regards, Charlie P. Benjamin Lim wrote: > > [Ben] Base on my understanding of 3775 sect 11.4.1, it does not specifically > mention what MN will do to the list of HA address received in DHAAD reply. I > think the confusion comes in because the section state one possible way to > do home registration is to perform a sequential trial of each home agent > address in the list (e.g. test 1st HA address --> fail --> test 2nd HA > address --> fail --> until end of list or succeed.) So this implies that MN > should store the list of HA address in order to do the above action. Whether > this list is store temporary (just to find HA) or permenantly (info for MN > in case HA goes down) is not mention. Maybe we should add some clarifying > text for this matter? > > Regards, > Benjamin Lim > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Oct 3 13:40: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 52FE628C2C6; Fri, 3 Oct 2008 13:40:20 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B8B428C262 for ; Fri, 3 Oct 2008 13:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.324 X-Spam-Level: X-Spam-Status: No, score=-6.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOiZOrs5D+ud for ; Fri, 3 Oct 2008 13:40:18 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 9685F28C2E2 for ; Fri, 3 Oct 2008 13:35:47 -0700 (PDT) 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 m93KZxHj021719; Fri, 3 Oct 2008 23:36:12 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Oct 2008 23:36:06 +0300 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Oct 2008 15:35:54 -0500 Received: from 172.19.60.149 ([172.19.60.149]) by daebe104.NOE.Nokia.com ([10.241.36.13]) with Microsoft Exchange Server HTTP-DAV ; Fri, 3 Oct 2008 20:35:15 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Fri, 03 Oct 2008 15:35:17 -0500 From: Basavaraj Patil To: Charles Perkins , Benjamin Lim Message-ID: Thread-Topic: [MEXT] The usage of "HA lifetime" (RFC3775-update) -- list processing Thread-Index: Ackll4umx4GLv32RFU2TgLS3Dv9bzQ== In-Reply-To: <48E662C8.5090103@earthlink.net> Mime-version: 1.0 X-OriginalArrivalTime: 03 Oct 2008 20:35:54.0034 (UTC) FILETIME=[A1B96120:01C92597] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) -- list processing X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, In the bootstrapping work that was done in the MIP6 WG, the MN is dynamically assigned an HA. The scenario where an MN does HA discovery using DHAAD was considered to be remote. But of course 3775 does specify HA discovery and I am not arguing against that. Maybe it is worthwhile revisiting the issue about DHAAD. Is dynamic HA discovery still an important feature for MIP6? Or given that we now have some bootstrapping solutions (integrated and split) can we rely on those for HA discovery/assignment. I do not believe that the idea of an MN maintaining a list of HAs received in the Home Agent Address Discovery Reply message is very practical. If an MN finds that the HA is unresponsive, I don't think it will try to verify the next HA on the list. Most likely it will simply find another HA and perform another registration. Agree that the previous HoA is no longer valid. But I don't think that it would be disastrous to the MN. So maybe we should reconsider the DHAAD feature in MIP6. It would be a way of simplifying the protocol as well. -Raj On 10/3/08 1:22 PM, "Charles Perkins" wrote: > > Hello Benjamin, > > Along the way to resolving issue #10, I had some thoughts > about the points you raised. > > If you go along with my suggestion that the home agent addresses > supplied in the Home Agent Address Discovery Reply message > do not have lifetimes associated with the addresses, then we can > make a reasonable suggestion about list maintenance and processing. > > I would suggest that the home agent addresses obtained from the > Reply message should be stored and used as necessary. When the > current home agent becomes inaccessible, the mobile node should > try to send an update to the next home agent on the list. When one > of the home agents on the list seems unresponsive, it should be > deleted from the list of available home agents. When the list is > depleted, the mobile node can re-attempt the discovery process. > > But these are rare events. Perhaps the mobile node would have to > try the discovery process on a timescale measured in months or > years, under most scenarios for administering the home network. > > If you agree with this, then I guess there is again a need for some > clarifying text in section 11.4.1. Contributions are always welcome. > > The previous discussion points are documented at the following URL: > http://trac.tools.ietf.org/wg/mext/trac/ticket/10 > > Regards, > Charlie P. > > > > > > Benjamin Lim wrote: >> >> [Ben] Base on my understanding of 3775 sect 11.4.1, it does not specifically >> mention what MN will do to the list of HA address received in DHAAD reply. I >> think the confusion comes in because the section state one possible way to >> do home registration is to perform a sequential trial of each home agent >> address in the list (e.g. test 1st HA address --> fail --> test 2nd HA >> address --> fail --> until end of list or succeed.) So this implies that MN >> should store the list of HA address in order to do the above action. Whether >> this list is store temporary (just to find HA) or permenantly (info for MN >> in case HA goes down) is not mention. Maybe we should add some clarifying >> text for this matter? >> >> Regards, >> Benjamin Lim >> > _______________________________________________ > MEXT mailing 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 Oct 3 14:25: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 761633A684F; Fri, 3 Oct 2008 14:25:00 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B43C43A683A for ; Fri, 3 Oct 2008 14:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 aIlnKYezrY+8 for ; Fri, 3 Oct 2008 14:24:58 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id A90053A67CF for ; Fri, 3 Oct 2008 14:24:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=I8MixoK2oSrQTkaNPZ8iGpWklLNSwDmYeJRzuaq95BatTG5AS5uTIchrT9vURnXw; 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.255.15]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Kls9L-0005dK-LX; Fri, 03 Oct 2008 17:25:23 -0400 Message-ID: <48E68DC2.8020903@earthlink.net> Date: Fri, 03 Oct 2008 14:25:22 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5201dfe2b57a7169304df66af43d3a27d7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: mext@ietf.org Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) -- list processing X-BeenThere: mext@ietf.org X-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 Basavaraj, I am neutral on this. Any new discussion should take into account the voluminous discussion which has gone before, summarized at the following URL: http://trac.tools.ietf.org/wg/mext/trac/ticket/2 I won't attempt to summarize the discussion here, but I'd like to point out that the new revision of rfc3775bis incorporates text as discussed at the Dublin IETF and on the mailing list, and intended to close the issue. On the other hand, I know that there are people who would like to reopen the discussion. Basically, I have encouraged them to try convince the working group, and to convince the chairs that rfc3775bis is the appropriate vehicle for carrying out such a relatively large change to the protocol. Regards, Charlie P. Basavaraj Patil wrote: > Hi Charlie, > > In the bootstrapping work that was done in the MIP6 WG, the MN is > dynamically assigned an HA. The scenario where an MN does HA discovery using > DHAAD was considered to be remote. But of course 3775 does specify HA > discovery and I am not arguing against that. > Maybe it is worthwhile revisiting the issue about DHAAD. Is dynamic HA > discovery still an important feature for MIP6? Or given that we now have > some bootstrapping solutions (integrated and split) can we rely on those for > HA discovery/assignment. > > I do not believe that the idea of an MN maintaining a list of HAs received > in the Home Agent Address Discovery Reply message is very practical. If an > MN finds that the HA is unresponsive, I don't think it will try to verify > the next HA on the list. Most likely it will simply find another HA and > perform another registration. Agree that the previous HoA is no longer > valid. But I don't think that it would be disastrous to the MN. > > So maybe we should reconsider the DHAAD feature in MIP6. It would be a way > of simplifying the protocol as well. > > -Raj > > > > > On 10/3/08 1:22 PM, "Charles Perkins" wrote: > > >> Hello Benjamin, >> >> Along the way to resolving issue #10, I had some thoughts >> about the points you raised. >> >> If you go along with my suggestion that the home agent addresses >> supplied in the Home Agent Address Discovery Reply message >> do not have lifetimes associated with the addresses, then we can >> make a reasonable suggestion about list maintenance and processing. >> >> I would suggest that the home agent addresses obtained from the >> Reply message should be stored and used as necessary. When the >> current home agent becomes inaccessible, the mobile node should >> try to send an update to the next home agent on the list. When one >> of the home agents on the list seems unresponsive, it should be >> deleted from the list of available home agents. When the list is >> depleted, the mobile node can re-attempt the discovery process. >> >> But these are rare events. Perhaps the mobile node would have to >> try the discovery process on a timescale measured in months or >> years, under most scenarios for administering the home network. >> >> If you agree with this, then I guess there is again a need for some >> clarifying text in section 11.4.1. Contributions are always welcome. >> >> The previous discussion points are documented at the following URL: >> http://trac.tools.ietf.org/wg/mext/trac/ticket/10 >> >> Regards, >> Charlie P. >> >> >> >> >> >> Benjamin Lim wrote: >> >>> [Ben] Base on my understanding of 3775 sect 11.4.1, it does not specifically >>> mention what MN will do to the list of HA address received in DHAAD reply. I >>> think the confusion comes in because the section state one possible way to >>> do home registration is to perform a sequential trial of each home agent >>> address in the list (e.g. test 1st HA address --> fail --> test 2nd HA >>> address --> fail --> until end of list or succeed.) So this implies that MN >>> should store the list of HA address in order to do the above action. Whether >>> this list is store temporary (just to find HA) or permenantly (info for MN >>> in case HA goes down) is not mention. Maybe we should add some clarifying >>> text for this matter? >>> >>> Regards, >>> Benjamin Lim >>> >>> >> _______________________________________________ >> MEXT mailing 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 Oct 3 14: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 3A4973A6867; Fri, 3 Oct 2008 14:30:05 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0273A67EF for ; Fri, 3 Oct 2008 14:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.216 X-Spam-Level: X-Spam-Status: No, score=-105.216 tagged_above=-999 required=5 tests=[AWL=1.383, 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 TtgTMW4KUDbK for ; Fri, 3 Oct 2008 14:30:02 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id B75453A67EC for ; Fri, 3 Oct 2008 14:30:02 -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=1223069432; x=1254605432; 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=20Charles=20Perkins=0D=0A=09< charles.perkins@earthlink.net>,=0D=0A=20=20=20=20=20=20 =20=20Benjamin=20Lim=0D=0A=09|CC:=20"mext@ietf.org"=20|Date:=20Fri ,=203=20Oct=202008=2014:30:31=20-0700|Subject:=20RE:=20[M EXT]=20The=20usage=20of=20"HA=20lifetime"=20(RFC3775-upda te)=20--=20list=0D=0A=20processing|Thread-Topic:=20[MEXT] =20The=20usage=20of=20"HA=20lifetime"=20(RFC3775-update) =20--=20list=0D=0A=20processing|Thread-Index:=20Ackll4umx 4GLv32RFU2TgLS3Dv9bzQAB2o/w|Message-ID:=20<057632CE4CE10D 45A1A3D6D19206C3A3D29BB0A1@NASANEXMB08.na.qualcomm.com> |References:=20<48E662C8.5090103@earthlink.net>=0D=0A=20< C50BEC35.1AAB9%basavaraj.patil@nokia.com>|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5398"=3B=20a=3D"9863850"; bh=++90xFWUQ8T34tc5FDaZps47w1XHaqiCjqr69tLDR2Y=; b=l4nowXBxgVKEe0uyI8+chCA9WCsVqXGoEXF+jqKYEEhcHDay/HGUAdSj LIAjNKQsjDwk7Fcrmwf93UR0qm7/XqqVng5b89mcZV25X2eBQ0EtoQsE8 VotH0MxCaHXPAF+GwjRet4LeURY2wzzdLlMxRcchvp3pPi9mYcA1o1ylk 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5398"; a="9863850" 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 Oct 2008 14:30:32 -0700 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 m93LUVRB018335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 3 Oct 2008 14:30:31 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m93LUVWs030265 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 3 Oct 2008 14:30:31 -0700 Received: from nasanexhub06.na.qualcomm.com (129.46.134.254) by nasanexhc02.na.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 3 Oct 2008 14:30:30 -0700 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub06.na.qualcomm.com ([129.46.134.254]) with mapi; Fri, 3 Oct 2008 14:30:29 -0700 From: "Giaretta, Gerardo" To: Basavaraj Patil , Charles Perkins , Benjamin Lim Date: Fri, 3 Oct 2008 14:30:31 -0700 Thread-Topic: [MEXT] The usage of "HA lifetime" (RFC3775-update) -- list processing Thread-Index: Ackll4umx4GLv32RFU2TgLS3Dv9bzQAB2o/w Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D29BB0A1@NASANEXMB08.na.qualcomm.com> References: <48E662C8.5090103@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] The usage of "HA lifetime" (RFC3775-update) -- list processing X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Raj and Charlie, I agree with Raj on this issue. There are two main solution for dynamic HA discovery we have specified in the bootstrapping work and those are based on DNS and DHCP. These were also the solutions adopted by all other SDOs which adopted MIPv6. Based on this I agree there is a value in simplifying MIPv6 removing the support for DHAAD. Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Basavaraj Patil > Sent: Friday, October 03, 2008 1:35 PM > To: Charles Perkins; Benjamin Lim > Cc: mext@ietf.org > Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) -- list > processing > > > Hi Charlie, > > In the bootstrapping work that was done in the MIP6 WG, the MN is > dynamically assigned an HA. The scenario where an MN does HA discovery > using > DHAAD was considered to be remote. But of course 3775 does specify HA > discovery and I am not arguing against that. > Maybe it is worthwhile revisiting the issue about DHAAD. Is dynamic HA > discovery still an important feature for MIP6? Or given that we now > have > some bootstrapping solutions (integrated and split) can we rely on > those for > HA discovery/assignment. > > I do not believe that the idea of an MN maintaining a list of HAs > received > in the Home Agent Address Discovery Reply message is very practical. If > an > MN finds that the HA is unresponsive, I don't think it will try to > verify > the next HA on the list. Most likely it will simply find another HA and > perform another registration. Agree that the previous HoA is no longer > valid. But I don't think that it would be disastrous to the MN. > > So maybe we should reconsider the DHAAD feature in MIP6. It would be a > way > of simplifying the protocol as well. > > -Raj > > > > > On 10/3/08 1:22 PM, "Charles Perkins" > wrote: > > > > > Hello Benjamin, > > > > Along the way to resolving issue #10, I had some thoughts > > about the points you raised. > > > > If you go along with my suggestion that the home agent addresses > > supplied in the Home Agent Address Discovery Reply message > > do not have lifetimes associated with the addresses, then we can > > make a reasonable suggestion about list maintenance and processing. > > > > I would suggest that the home agent addresses obtained from the > > Reply message should be stored and used as necessary. When the > > current home agent becomes inaccessible, the mobile node should > > try to send an update to the next home agent on the list. When one > > of the home agents on the list seems unresponsive, it should be > > deleted from the list of available home agents. When the list is > > depleted, the mobile node can re-attempt the discovery process. > > > > But these are rare events. Perhaps the mobile node would have to > > try the discovery process on a timescale measured in months or > > years, under most scenarios for administering the home network. > > > > If you agree with this, then I guess there is again a need for some > > clarifying text in section 11.4.1. Contributions are always welcome. > > > > The previous discussion points are documented at the following URL: > > http://trac.tools.ietf.org/wg/mext/trac/ticket/10 > > > > Regards, > > Charlie P. > > > > > > > > > > > > Benjamin Lim wrote: > >> > >> [Ben] Base on my understanding of 3775 sect 11.4.1, it does not > specifically > >> mention what MN will do to the list of HA address received in DHAAD > reply. I > >> think the confusion comes in because the section state one possible > way to > >> do home registration is to perform a sequential trial of each home > agent > >> address in the list (e.g. test 1st HA address --> fail --> test 2nd > HA > >> address --> fail --> until end of list or succeed.) So this implies > that MN > >> should store the list of HA address in order to do the above action. > Whether > >> this list is store temporary (just to find HA) or permenantly (info > for MN > >> in case HA goes down) is not mention. Maybe we should add some > clarifying > >> text for this matter? > >> > >> Regards, > >> Benjamin Lim > >> > > _______________________________________________ > > MEXT mailing 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 a20092008@gmail.com Sat Oct 4 16:43:46 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CA823A67E9; Sat, 4 Oct 2008 16:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.738 X-Spam-Level: *** X-Spam-Status: No, score=3.738 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_50=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, 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 cTUYK3OU-CTX; Sat, 4 Oct 2008 16:43:45 -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 939F83A67A6; Sat, 4 Oct 2008 16:43:45 -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 <0K8800CJXN9DK9H0@maildcarg4.dc-host.net.ar>; Sat, 04 Oct 2008 20:44:02 -0300 (ART) Date: Sat, 04 Oct 2008 20:44:21 -0300 From: "a20092008@gmail.com" Subject: COMPUTADORA ATHLON COMPLETA To: PCs Errors-to: a200982008_@gmail.com Message-id: <3819-220081064234421783@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: a20092008@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: 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 -$1049 IVA Incluido Consulte por otras configuracion y otros productos, monitores LCD, noteboo= ks, etc From mext-bounces@ietf.org Mon Oct 6 09:59: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 B9D683A6B0E; Mon, 6 Oct 2008 09:59:02 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF77E3A6B0E for ; Mon, 6 Oct 2008 09:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.345 X-Spam-Level: X-Spam-Status: No, score=-6.345 tagged_above=-999 required=5 tests=[AWL=0.254, 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 35DoOQK7V1SG for ; Mon, 6 Oct 2008 09:58:55 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id DDAD43A6B05 for ; Mon, 6 Oct 2008 09:58:54 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m96Gwg90023547; Mon, 6 Oct 2008 19:59:05 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 19:57:41 +0300 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 11:57:40 -0500 Received: from 172.19.60.153 ([172.19.60.153]) by daebe104.NOE.Nokia.com ([10.241.36.13]) with Microsoft Exchange Server HTTP-DAV ; Mon, 6 Oct 2008 16:57:40 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Mon, 06 Oct 2008 11:57:42 -0500 From: Basavaraj Patil To: Charles Perkins Message-ID: Thread-Topic: [MEXT] The usage of "HA lifetime" (RFC3775-update) -- list processing Thread-Index: Ackn1KWA3Nn5WMGCxkqSc/zgXdAH4g== In-Reply-To: <48E68DC2.8020903@earthlink.net> Mime-version: 1.0 X-OriginalArrivalTime: 06 Oct 2008 16:57:40.0290 (UTC) FILETIME=[A47BDA20:01C927D4] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) -- list processing X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Mext chairs (Marcelo/Julien), Would you comment on the proposal to revisit thee DHAAD feature in MIP6 (RFC3775) and replace it with the solutions that were subsequently developed as part of the bootstrapping work. This change would be done as part of the effort to revise RFC3775. -Raj On 10/3/08 4:25 PM, "Charles Perkins" wrote: > > Hello Basavaraj, > > I am neutral on this. Any new discussion should take into > account the voluminous discussion which has gone before, > summarized at the following URL: > http://trac.tools.ietf.org/wg/mext/trac/ticket/2 > > I won't attempt to summarize the discussion here, but I'd like to > point out that the new revision of rfc3775bis incorporates text as > discussed at the Dublin IETF and on the mailing list, and intended > to close the issue. On the other hand, I know that there are people > who would like to reopen the discussion. Basically, I have > encouraged them to try convince the working group, and to > convince the chairs that rfc3775bis is the appropriate vehicle > for carrying out such a relatively large change to the protocol. > > Regards, > Charlie P. > > > > Basavaraj Patil wrote: >> Hi Charlie, >> >> In the bootstrapping work that was done in the MIP6 WG, the MN is >> dynamically assigned an HA. The scenario where an MN does HA discovery using >> DHAAD was considered to be remote. But of course 3775 does specify HA >> discovery and I am not arguing against that. >> Maybe it is worthwhile revisiting the issue about DHAAD. Is dynamic HA >> discovery still an important feature for MIP6? Or given that we now have >> some bootstrapping solutions (integrated and split) can we rely on those for >> HA discovery/assignment. >> >> I do not believe that the idea of an MN maintaining a list of HAs received >> in the Home Agent Address Discovery Reply message is very practical. If an >> MN finds that the HA is unresponsive, I don't think it will try to verify >> the next HA on the list. Most likely it will simply find another HA and >> perform another registration. Agree that the previous HoA is no longer >> valid. But I don't think that it would be disastrous to the MN. >> >> So maybe we should reconsider the DHAAD feature in MIP6. It would be a way >> of simplifying the protocol as well. >> >> -Raj >> >> >> >> >> On 10/3/08 1:22 PM, "Charles Perkins" wrote: >> >> >>> Hello Benjamin, >>> >>> Along the way to resolving issue #10, I had some thoughts >>> about the points you raised. >>> >>> If you go along with my suggestion that the home agent addresses >>> supplied in the Home Agent Address Discovery Reply message >>> do not have lifetimes associated with the addresses, then we can >>> make a reasonable suggestion about list maintenance and processing. >>> >>> I would suggest that the home agent addresses obtained from the >>> Reply message should be stored and used as necessary. When the >>> current home agent becomes inaccessible, the mobile node should >>> try to send an update to the next home agent on the list. When one >>> of the home agents on the list seems unresponsive, it should be >>> deleted from the list of available home agents. When the list is >>> depleted, the mobile node can re-attempt the discovery process. >>> >>> But these are rare events. Perhaps the mobile node would have to >>> try the discovery process on a timescale measured in months or >>> years, under most scenarios for administering the home network. >>> >>> If you agree with this, then I guess there is again a need for some >>> clarifying text in section 11.4.1. Contributions are always welcome. >>> >>> The previous discussion points are documented at the following URL: >>> http://trac.tools.ietf.org/wg/mext/trac/ticket/10 >>> >>> Regards, >>> Charlie P. >>> >>> >>> >>> >>> >>> Benjamin Lim wrote: >>> >>>> [Ben] Base on my understanding of 3775 sect 11.4.1, it does not >>>> specifically >>>> mention what MN will do to the list of HA address received in DHAAD reply. >>>> I >>>> think the confusion comes in because the section state one possible way to >>>> do home registration is to perform a sequential trial of each home agent >>>> address in the list (e.g. test 1st HA address --> fail --> test 2nd HA >>>> address --> fail --> until end of list or succeed.) So this implies that MN >>>> should store the list of HA address in order to do the above action. >>>> Whether >>>> this list is store temporary (just to find HA) or permenantly (info for MN >>>> in case HA goes down) is not mention. Maybe we should add some clarifying >>>> text for this matter? >>>> >>>> Regards, >>>> Benjamin Lim >>>> >>>> >>> _______________________________________________ >>> MEXT mailing 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 Oct 6 10:16: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 3C87A28C18B; Mon, 6 Oct 2008 10:16:27 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3126D28C18B for ; Mon, 6 Oct 2008 10:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.363 X-Spam-Level: X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 GKYFzmU-soyC for ; Mon, 6 Oct 2008 10:16:25 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 255063A6AD2 for ; Mon, 6 Oct 2008 10:16:24 -0700 (PDT) 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 m96HGfYn011217; Mon, 6 Oct 2008 12:16:57 -0500 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 20:16:16 +0300 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 12:16:13 -0500 Received: from 172.19.60.153 ([172.19.60.153]) by daebe104.NOE.Nokia.com ([10.241.36.13]) with Microsoft Exchange Server HTTP-DAV ; Mon, 6 Oct 2008 17:16:13 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Mon, 06 Oct 2008 12:16:16 -0500 From: Basavaraj Patil To: Charles Perkins , Benjamin Lim Message-ID: Thread-Topic: [MEXT] Issue #17: Multi-homed mobile node can cause routing loop between home agents Thread-Index: Ackn1z1/l8R0WJn83UuKoifDDxTMbQ== In-Reply-To: <48E55E5F.5040101@earthlink.net> Mime-version: 1.0 X-OriginalArrivalTime: 06 Oct 2008 17:16:13.0518 (UTC) FILETIME=[3C04F6E0:01C927D7] X-Nokia-AV: Clean 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 Charlie, I don't see this issue being specific to MIP6 base spec. The fact that such a threat may arise as a result of multihoming is outside the scope of MIP6 protocol itself. IMO this is a non-issue for MIP6. -Raj On 10/2/08 6:50 PM, "Charles Perkins" wrote: > > 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. > > 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 From mext-bounces@ietf.org Mon Oct 6 10:20: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 CB0BA28C194; Mon, 6 Oct 2008 10:20:13 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F29C3A6AF5 for ; Mon, 6 Oct 2008 10:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.181 X-Spam-Level: X-Spam-Status: No, score=-5.181 tagged_above=-999 required=5 tests=[AWL=-1.419, 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 pS-YHBv4KEwf for ; Mon, 6 Oct 2008 10:20:09 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id B17F03A67D0 for ; Mon, 6 Oct 2008 10:20:08 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (208.pool85-53-145.dynamic.orange.es [85.53.145.208])by smtp02.uc3m.es (Postfix) with ESMTP id 17C4C5BC355; Mon, 6 Oct 2008 19:20:23 +0200 (CEST) Message-ID: <48EA48D6.7040302@it.uc3m.es> Date: Mon, 06 Oct 2008 19:20:22 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Basavaraj Patil 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:-35.9575 TC:1F TRN:89 TV:5.5.1026(16202.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@ietf.org Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) -- listprocessing X-BeenThere: mext@ietf.org X-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 Raj, Basavaraj Patil escribi=F3: > Mext chairs (Marcelo/Julien), > > Would you comment on the proposal to revisit thee DHAAD feature in MIP6 > (RFC3775) and replace it with the solutions that were subsequently develo= ped > as part of the bootstrapping work. Our charter states: Work items related to base specification maintenance include: (B.1) Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. One specific area of concern that should be analyzed and addressed relates to multilink subnets. This work item relates only to corrections and clarifications. The working group shall not revisit design decisions or change the protocol. Changing DHAAD feature by other solution as you mention, seems to me = more than a clarification or a correction, but a significant change in = the spec. This would go beyond the scope of our current work. If there were strong WG consensus behind the proposed change i.e. it is = obvious that we need to make that change, I would be tempted to go = beyond a simple correction or clarification, and we could discuss how = make that change with our AD, but i don't think we are there yet. So, my take on this is that so far, the issue does not seem to fall into = the scope of our work in rfc3775 and there doesn't seem to be strong = consensus in doing it neither, so i think the solution proposed by = charlie at this point is the reasonable way to go. (I am merely = expressing my view on the wg status and the charter on this issue, so if = the wg feels differently, this could be changed) Regards, marcelo > This change would be done as part of the > effort to revise RFC3775. > > -Raj > > > On 10/3/08 4:25 PM, "Charles Perkins" wro= te: > > = >> Hello Basavaraj, >> >> I am neutral on this. Any new discussion should take into >> account the voluminous discussion which has gone before, >> summarized at the following URL: >> http://trac.tools.ietf.org/wg/mext/trac/ticket/2 >> >> I won't attempt to summarize the discussion here, but I'd like to >> point out that the new revision of rfc3775bis incorporates text as >> discussed at the Dublin IETF and on the mailing list, and intended >> to close the issue. On the other hand, I know that there are people >> who would like to reopen the discussion. Basically, I have >> encouraged them to try convince the working group, and to >> convince the chairs that rfc3775bis is the appropriate vehicle >> for carrying out such a relatively large change to the protocol. >> >> Regards, >> Charlie P. >> >> >> >> Basavaraj Patil wrote: >> = >>> Hi Charlie, >>> >>> In the bootstrapping work that was done in the MIP6 WG, the MN is >>> dynamically assigned an HA. The scenario where an MN does HA discovery = using >>> DHAAD was considered to be remote. But of course 3775 does specify HA >>> discovery and I am not arguing against that. >>> Maybe it is worthwhile revisiting the issue about DHAAD. Is dynamic HA >>> discovery still an important feature for MIP6? Or given that we now have >>> some bootstrapping solutions (integrated and split) can we rely on thos= e for >>> HA discovery/assignment. >>> >>> I do not believe that the idea of an MN maintaining a list of HAs recei= ved >>> in the Home Agent Address Discovery Reply message is very practical. If= an >>> MN finds that the HA is unresponsive, I don't think it will try to veri= fy >>> the next HA on the list. Most likely it will simply find another HA and >>> perform another registration. Agree that the previous HoA is no longer >>> valid. But I don't think that it would be disastrous to the MN. >>> >>> So maybe we should reconsider the DHAAD feature in MIP6. It would be a = way >>> of simplifying the protocol as well. >>> >>> -Raj = >>> = >>> >>> >>> >>> On 10/3/08 1:22 PM, "Charles Perkins" w= rote: >>> >>> = >>> = >>>> Hello Benjamin, >>>> >>>> Along the way to resolving issue #10, I had some thoughts >>>> about the points you raised. >>>> >>>> If you go along with my suggestion that the home agent addresses >>>> supplied in the Home Agent Address Discovery Reply message >>>> do not have lifetimes associated with the addresses, then we can >>>> make a reasonable suggestion about list maintenance and processing. >>>> >>>> I would suggest that the home agent addresses obtained from the >>>> Reply message should be stored and used as necessary. When the >>>> current home agent becomes inaccessible, the mobile node should >>>> try to send an update to the next home agent on the list. When one >>>> of the home agents on the list seems unresponsive, it should be >>>> deleted from the list of available home agents. When the list is >>>> depleted, the mobile node can re-attempt the discovery process. >>>> >>>> But these are rare events. Perhaps the mobile node would have to >>>> try the discovery process on a timescale measured in months or >>>> years, under most scenarios for administering the home network. >>>> >>>> If you agree with this, then I guess there is again a need for some >>>> clarifying text in section 11.4.1. Contributions are always welcome. >>>> >>>> The previous discussion points are documented at the following URL: >>>> http://trac.tools.ietf.org/wg/mext/trac/ticket/10 >>>> >>>> Regards, >>>> Charlie P. >>>> >>>> >>>> >>>> >>>> >>>> Benjamin Lim wrote: >>>> = >>>> = >>>>> [Ben] Base on my understanding of 3775 sect 11.4.1, it does not >>>>> specifically >>>>> mention what MN will do to the list of HA address received in DHAAD r= eply. >>>>> I >>>>> think the confusion comes in because the section state one possible w= ay to >>>>> do home registration is to perform a sequential trial of each home ag= ent >>>>> address in the list (e.g. test 1st HA address --> fail --> test 2nd HA >>>>> address --> fail --> until end of list or succeed.) So this implies t= hat MN >>>>> should store the list of HA address in order to do the above action. >>>>> Whether >>>>> this list is store temporary (just to find HA) or permenantly (info f= or MN >>>>> in case HA goes down) is not mention. Maybe we should add some clarif= ying >>>>> text for this matter? >>>>> >>>>> Regards, >>>>> Benjamin Lim >>>>> = >>>>> = >>>>> = >>>> _______________________________________________ >>>> MEXT mailing 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 Oct 6 10: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 17B653A6AD2; Mon, 6 Oct 2008 10:35:04 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C47683A6AD2 for ; Mon, 6 Oct 2008 10:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.379 X-Spam-Level: X-Spam-Status: No, score=-6.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 5Iywu5wbvm0z for ; Mon, 6 Oct 2008 10:34:58 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 0F26C3A6A24 for ; Mon, 6 Oct 2008 10:34:57 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m96HYSGS024648; Mon, 6 Oct 2008 20:34:32 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 20:33:44 +0300 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Oct 2008 12:33:42 -0500 Received: from 172.19.60.153 ([172.19.60.153]) by daebe104.NOE.Nokia.com ([10.241.36.13]) with Microsoft Exchange Server HTTP-DAV ; Mon, 6 Oct 2008 17:33:42 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Mon, 06 Oct 2008 12:33:45 -0500 From: Basavaraj Patil To: Marcelo Bagnulo Message-ID: Thread-Topic: [MEXT] The usage of "HA lifetime" (RFC3775-update) -- listprocessing Thread-Index: Ackn2a7A0sqB4txFCUWTMqAQ3i/ljg== In-Reply-To: <48EA48D6.7040302@it.uc3m.es> Mime-version: 1.0 X-OriginalArrivalTime: 06 Oct 2008 17:33:42.0980 (UTC) FILETIME=[AD8C2840:01C927D9] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) -- listprocessing X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.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 that the WG charter w.r.t MIP6 (RFC3775) is limited to only doing maintenance work ("Corrections and clarifications "). However I think it would be worthwhile to potentially consider simplifying the protocol as well. = One of the things that the previous MIP6 WG intended to do was to decouple some of the more larger features in the protocol (such as route optimization, movement detection, home agent discovery) in separate specs. However we never did get to that point. Maybe it is something that MEXT WG ought to take up. Anyway, I will propose this simplification of MIP6 for discussion at the upcoming IETF73 meeting and we can get a sense of the WG. -Raj On 10/6/08 12:20 PM, "Marcelo Bagnulo" wrote: > Hi Raj, > = > = > = > Basavaraj Patil escribi=F3: >> Mext chairs (Marcelo/Julien), >> = >> Would you comment on the proposal to revisit thee DHAAD feature in MIP6 >> (RFC3775) and replace it with the solutions that were subsequently devel= oped >> as part of the bootstrapping work. > = > Our charter states: > = > Work items related to base specification maintenance include: > = > (B.1) Create and maintain issue lists that are generated on the basis > of implementation and interoperability experience. Address > specific issues with specific updates or revisions of the base > specification. One specific area of concern that should be > analyzed and addressed relates to multilink subnets. > = > This work item relates only to corrections and > clarifications. The working group shall not revisit design > decisions or change the protocol. > = > Changing DHAAD feature by other solution as you mention, seems to me > more than a clarification or a correction, but a significant change in > the spec. This would go beyond the scope of our current work. > = > If there were strong WG consensus behind the proposed change i.e. it is > obvious that we need to make that change, I would be tempted to go > beyond a simple correction or clarification, and we could discuss how > make that change with our AD, but i don't think we are there yet. > = > So, my take on this is that so far, the issue does not seem to fall into > the scope of our work in rfc3775 and there doesn't seem to be strong > consensus in doing it neither, so i think the solution proposed by > charlie at this point is the reasonable way to go. (I am merely > expressing my view on the wg status and the charter on this issue, so if > the wg feels differently, this could be changed) > = > Regards, marcelo > = > = >> This change would be done as part of the >> effort to revise RFC3775. >> = >> -Raj >> = >> = >> On 10/3/08 4:25 PM, "Charles Perkins" wr= ote: >> = >> = >>> Hello Basavaraj, >>> = >>> I am neutral on this. Any new discussion should take into >>> account the voluminous discussion which has gone before, >>> summarized at the following URL: >>> http://trac.tools.ietf.org/wg/mext/trac/ticket/2 >>> = >>> I won't attempt to summarize the discussion here, but I'd like to >>> point out that the new revision of rfc3775bis incorporates text as >>> discussed at the Dublin IETF and on the mailing list, and intended >>> to close the issue. On the other hand, I know that there are people >>> who would like to reopen the discussion. Basically, I have >>> encouraged them to try convince the working group, and to >>> convince the chairs that rfc3775bis is the appropriate vehicle >>> for carrying out such a relatively large change to the protocol. >>> = >>> Regards, >>> Charlie P. >>> = >>> = >>> = >>> Basavaraj Patil wrote: >>> = >>>> Hi Charlie, >>>> = >>>> In the bootstrapping work that was done in the MIP6 WG, the MN is >>>> dynamically assigned an HA. The scenario where an MN does HA discovery >>>> using >>>> DHAAD was considered to be remote. But of course 3775 does specify HA >>>> discovery and I am not arguing against that. >>>> Maybe it is worthwhile revisiting the issue about DHAAD. Is dynamic HA >>>> discovery still an important feature for MIP6? Or given that we now ha= ve >>>> some bootstrapping solutions (integrated and split) can we rely on tho= se >>>> for >>>> HA discovery/assignment. >>>> = >>>> I do not believe that the idea of an MN maintaining a list of HAs rece= ived >>>> in the Home Agent Address Discovery Reply message is very practical. I= f an >>>> MN finds that the HA is unresponsive, I don't think it will try to ver= ify >>>> the next HA on the list. Most likely it will simply find another HA and >>>> perform another registration. Agree that the previous HoA is no longer >>>> valid. But I don't think that it would be disastrous to the MN. >>>> = >>>> So maybe we should reconsider the DHAAD feature in MIP6. It would be a= way >>>> of simplifying the protocol as well. >>>> = >>>> -Raj = >>>> = >>>> = >>>> = >>>> = >>>> On 10/3/08 1:22 PM, "Charles Perkins" >>>> wrote: >>>> = >>>> = >>>> = >>>>> Hello Benjamin, >>>>> = >>>>> Along the way to resolving issue #10, I had some thoughts >>>>> about the points you raised. >>>>> = >>>>> If you go along with my suggestion that the home agent addresses >>>>> supplied in the Home Agent Address Discovery Reply message >>>>> do not have lifetimes associated with the addresses, then we can >>>>> make a reasonable suggestion about list maintenance and processing. >>>>> = >>>>> I would suggest that the home agent addresses obtained from the >>>>> Reply message should be stored and used as necessary. When the >>>>> current home agent becomes inaccessible, the mobile node should >>>>> try to send an update to the next home agent on the list. When one >>>>> of the home agents on the list seems unresponsive, it should be >>>>> deleted from the list of available home agents. When the list is >>>>> depleted, the mobile node can re-attempt the discovery process. >>>>> = >>>>> But these are rare events. Perhaps the mobile node would have to >>>>> try the discovery process on a timescale measured in months or >>>>> years, under most scenarios for administering the home network. >>>>> = >>>>> If you agree with this, then I guess there is again a need for some >>>>> clarifying text in section 11.4.1. Contributions are always welcome. >>>>> = >>>>> The previous discussion points are documented at the following URL: >>>>> http://trac.tools.ietf.org/wg/mext/trac/ticket/10 >>>>> = >>>>> Regards, >>>>> Charlie P. >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> Benjamin Lim wrote: >>>>> = >>>>> = >>>>>> [Ben] Base on my understanding of 3775 sect 11.4.1, it does not >>>>>> specifically >>>>>> mention what MN will do to the list of HA address received in DHAAD >>>>>> reply. >>>>>> I >>>>>> think the confusion comes in because the section state one possible = way >>>>>> to >>>>>> do home registration is to perform a sequential trial of each home a= gent >>>>>> address in the list (e.g. test 1st HA address --> fail --> test 2nd = HA >>>>>> address --> fail --> until end of list or succeed.) So this implies = that >>>>>> MN >>>>>> should store the list of HA address in order to do the above action. >>>>>> Whether >>>>>> this list is store temporary (just to find HA) or permenantly (info = for >>>>>> MN >>>>>> in case HA goes down) is not mention. Maybe we should add some clari= fying >>>>>> text for this matter? >>>>>> = >>>>>> Regards, >>>>>> Benjamin Lim >>>>>> = >>>>>> = >>>>>> = >>>>> _______________________________________________ >>>>> MEXT mailing 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 Oct 6 12:14: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 EE3D13A6B07; Mon, 6 Oct 2008 12:14: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 0AA9C28C14D for ; Mon, 6 Oct 2008 12:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.471 X-Spam-Level: X-Spam-Status: No, score=-4.471 tagged_above=-999 required=5 tests=[AWL=-0.709, 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 KM1JkZgt4Z-F for ; Mon, 6 Oct 2008 12:14:11 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 798C23A6804 for ; Mon, 6 Oct 2008 12:14:11 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.147.202])by smtp01.uc3m.es (Postfix) with ESMTP id E35EDAAFF28; Mon, 6 Oct 2008 21:14:09 +0200 (CEST) Message-ID: <48EA6381.1@it.uc3m.es> Date: Mon, 06 Oct 2008 21:14:09 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Basavaraj Patil 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:-30.3988 TC:1F TRN:93 TV:5.5.1026(16202.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@ietf.org Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) -- listprocessing X-BeenThere: mext@ietf.org X-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 Basavaraj Patil escribi=F3: > Hi Marcelo, > > I agree that the WG charter w.r.t MIP6 (RFC3775) is limited to only doing > maintenance work ("Corrections and clarifications "). However I think it > would be worthwhile to potentially consider simplifying the protocol as > well. = > One of the things that the previous MIP6 WG intended to do was to decouple > some of the more larger features in the protocol (such as route > optimization, movement detection, home agent discovery) in separate specs. > However we never did get to that point. Maybe it is something that MEXT WG > ought to take up. Anyway, I will propose this simplification of MIP6 for > discussion at the upcoming IETF73 meeting and we can get a sense of the W= G. > > = that seems a good plan to me let us know how much time do you think i will be needed for this and = following disucssion regards, marcelo > -Raj > > > On 10/6/08 12:20 PM, "Marcelo Bagnulo" wrote: > > = >> Hi Raj, >> >> >> >> Basavaraj Patil escribi=F3: >> = >>> Mext chairs (Marcelo/Julien), >>> >>> Would you comment on the proposal to revisit thee DHAAD feature in MIP6 >>> (RFC3775) and replace it with the solutions that were subsequently deve= loped >>> as part of the bootstrapping work. >>> = >> Our charter states: >> >> Work items related to base specification maintenance include: >> >> (B.1) Create and maintain issue lists that are generated on the basis >> of implementation and interoperability experience. Address >> specific issues with specific updates or revisions of the base >> specification. One specific area of concern that should be >> analyzed and addressed relates to multilink subnets. >> >> This work item relates only to corrections and >> clarifications. The working group shall not revisit design >> decisions or change the protocol. >> >> Changing DHAAD feature by other solution as you mention, seems to me >> more than a clarification or a correction, but a significant change in >> the spec. This would go beyond the scope of our current work. >> >> If there were strong WG consensus behind the proposed change i.e. it is >> obvious that we need to make that change, I would be tempted to go >> beyond a simple correction or clarification, and we could discuss how >> make that change with our AD, but i don't think we are there yet. >> >> So, my take on this is that so far, the issue does not seem to fall into >> the scope of our work in rfc3775 and there doesn't seem to be strong >> consensus in doing it neither, so i think the solution proposed by >> charlie at this point is the reasonable way to go. (I am merely >> expressing my view on the wg status and the charter on this issue, so if >> the wg feels differently, this could be changed) >> >> Regards, marcelo >> >> >> = >>> This change would be done as part of the >>> effort to revise RFC3775. >>> >>> -Raj >>> >>> >>> On 10/3/08 4:25 PM, "Charles Perkins" w= rote: >>> >>> = >>> = >>>> Hello Basavaraj, >>>> >>>> I am neutral on this. Any new discussion should take into >>>> account the voluminous discussion which has gone before, >>>> summarized at the following URL: >>>> http://trac.tools.ietf.org/wg/mext/trac/ticket/2 >>>> >>>> I won't attempt to summarize the discussion here, but I'd like to >>>> point out that the new revision of rfc3775bis incorporates text as >>>> discussed at the Dublin IETF and on the mailing list, and intended >>>> to close the issue. On the other hand, I know that there are people >>>> who would like to reopen the discussion. Basically, I have >>>> encouraged them to try convince the working group, and to >>>> convince the chairs that rfc3775bis is the appropriate vehicle >>>> for carrying out such a relatively large change to the protocol. >>>> >>>> Regards, >>>> Charlie P. >>>> >>>> >>>> >>>> Basavaraj Patil wrote: >>>> = >>>> = >>>>> Hi Charlie, >>>>> >>>>> In the bootstrapping work that was done in the MIP6 WG, the MN is >>>>> dynamically assigned an HA. The scenario where an MN does HA discovery >>>>> using >>>>> DHAAD was considered to be remote. But of course 3775 does specify HA >>>>> discovery and I am not arguing against that. >>>>> Maybe it is worthwhile revisiting the issue about DHAAD. Is dynamic HA >>>>> discovery still an important feature for MIP6? Or given that we now h= ave >>>>> some bootstrapping solutions (integrated and split) can we rely on th= ose >>>>> for >>>>> HA discovery/assignment. >>>>> >>>>> I do not believe that the idea of an MN maintaining a list of HAs rec= eived >>>>> in the Home Agent Address Discovery Reply message is very practical. = If an >>>>> MN finds that the HA is unresponsive, I don't think it will try to ve= rify >>>>> the next HA on the list. Most likely it will simply find another HA a= nd >>>>> perform another registration. Agree that the previous HoA is no longer >>>>> valid. But I don't think that it would be disastrous to the MN. >>>>> >>>>> So maybe we should reconsider the DHAAD feature in MIP6. It would be = a way >>>>> of simplifying the protocol as well. >>>>> >>>>> -Raj = >>>>> = >>>>> >>>>> >>>>> >>>>> On 10/3/08 1:22 PM, "Charles Perkins" >>>>> wrote: >>>>> >>>>> = >>>>> = >>>>> = >>>>>> Hello Benjamin, >>>>>> >>>>>> Along the way to resolving issue #10, I had some thoughts >>>>>> about the points you raised. >>>>>> >>>>>> If you go along with my suggestion that the home agent addresses >>>>>> supplied in the Home Agent Address Discovery Reply message >>>>>> do not have lifetimes associated with the addresses, then we can >>>>>> make a reasonable suggestion about list maintenance and processing. >>>>>> >>>>>> I would suggest that the home agent addresses obtained from the >>>>>> Reply message should be stored and used as necessary. When the >>>>>> current home agent becomes inaccessible, the mobile node should >>>>>> try to send an update to the next home agent on the list. When one >>>>>> of the home agents on the list seems unresponsive, it should be >>>>>> deleted from the list of available home agents. When the list is >>>>>> depleted, the mobile node can re-attempt the discovery process. >>>>>> >>>>>> But these are rare events. Perhaps the mobile node would have to >>>>>> try the discovery process on a timescale measured in months or >>>>>> years, under most scenarios for administering the home network. >>>>>> >>>>>> If you agree with this, then I guess there is again a need for some >>>>>> clarifying text in section 11.4.1. Contributions are always welcome. >>>>>> >>>>>> The previous discussion points are documented at the following URL: >>>>>> http://trac.tools.ietf.org/wg/mext/trac/ticket/10 >>>>>> >>>>>> Regards, >>>>>> Charlie P. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Benjamin Lim wrote: >>>>>> = >>>>>> = >>>>>> = >>>>>>> [Ben] Base on my understanding of 3775 sect 11.4.1, it does not >>>>>>> specifically >>>>>>> mention what MN will do to the list of HA address received in DHAAD >>>>>>> reply. >>>>>>> I >>>>>>> think the confusion comes in because the section state one possible= way >>>>>>> to >>>>>>> do home registration is to perform a sequential trial of each home = agent >>>>>>> address in the list (e.g. test 1st HA address --> fail --> test 2nd= HA >>>>>>> address --> fail --> until end of list or succeed.) So this implies= that >>>>>>> MN >>>>>>> should store the list of HA address in order to do the above action. >>>>>>> Whether >>>>>>> this list is store temporary (just to find HA) or permenantly (info= for >>>>>>> MN >>>>>>> in case HA goes down) is not mention. Maybe we should add some clar= ifying >>>>>>> text for this matter? >>>>>>> >>>>>>> Regards, >>>>>>> Benjamin Lim >>>>>>> = >>>>>>> = >>>>>>> = >>>>>>> = >>>>>> _______________________________________________ >>>>>> MEXT mailing 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 Oct 7 07:31: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 0EE283A6B61; Tue, 7 Oct 2008 07:31:07 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 046533A6B61 for ; Tue, 7 Oct 2008 07:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.930, 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 kxbjXZvXOn8z for ; Tue, 7 Oct 2008 07:31:04 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 4DFFE3A6B2F for ; Tue, 7 Oct 2008 07:31:04 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Oct 2008 16:30:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 16:30:54 +0200 Message-ID: In-Reply-To: <48E58839.4040606@sg.panasonic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Issue #17: Multi-homed mobile node can cause routingloopbetween home agents Thread-Index: AcklAxDvQAa/ZHRwSASI4HwYjNMz1ADhY6yA References: <48E55E5F.5040101@earthlink.net><2557049CDBC35B4EBD79CFACFEC045840ABA72E6@XCH-NW-CCR1V.nw.nos.boeing.com> <48E58839.4040606@sg.panasonic.com> From: To: , , X-OriginalArrivalTime: 07 Oct 2008 14:30:55.0742 (UTC) FILETIME=[4EFA31E0:01C92889] Cc: mext@ietf.org Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can cause routingloopbetween 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Benjamin, I agree with your two steps proposal. For a), a solution could be to use GR= E encapsulation and the GRE key option as the identifier you propose. What = do you think? Regards, Pierrick > -----Message d'origine----- > De=A0: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de > Benjamin Lim > Envoy=E9=A0: vendredi 3 octobre 2008 04:49 > =C0=A0: Davis, Terry L; Charles E. Perkins > Cc=A0: mext@ietf.org > Objet=A0: Re: [MEXT] Issue #17: Multi-homed mobile node can cause > routingloopbetween home agents > = > Hi Charlie and Terry, > = > I agree with Charlie that using TEL option would ensure that packets > does not stay in the loop for a long time. But this might not fully > solve the problem, as the loop still exist. > = > I think a solution to the problem can be seen as two steps. > = > (a) A loop detection mechanism at HA. > (b) A correction procedure when a loop is being detected. > = > For (a), there would a draft submitted to the coming IETF meeting for > discussion. The general idea is to tag a packet with some ID that HA > can identify if the packet is looped. > = > For (b), my understanding from Terry would be that the correction steps > to be taken would be based on the policy of controller of the network. > I.e. for aviation, they can have a policy that states that if loop is > detected for ATN traffic, its ok. If loop is detected for operations and > passenger traffic, then HAs would remove the affected binding to break > the loop. > = > Regards, > Benjamin Lim > = > Davis, Terry L wrote: > > Charlie > > > > Seems like a potential solution; but I'm not sure the cause would > necessarily relate to security. > > > > The natural state of an aircraft will be to attempt to be multi-homed in > the "Air Traffic Management Network" (ATN) domain with two or more active > links and most of the links available to an aircraft will be "narrow-band= ", > a megabit or less. If we do really well, our new aviation communication > link providers may get us to a shared "broadband" link capability of 10 > megabits. The good thing is that this ATN domain will likely be run as a > closed network so that routing loops only impact the ATN domain. > > > > (Our existing OSI "broadband links", which we don't intend to convert to > IP, run from 2K "bits" to 30K "bits".) > > > > However the other two aircraft network domains will have the potential > to impact general Internet routing with their mobility services; "airline > operations" which will look like a corporate business network and > "passenger Internet and Entertainment" which will look like an ISP. And > at least at times, both may be multi-homed, if for no other reason than > the satellite handoffs or air-to-ground tower handoffs being done at layer > three instead of two. > > > > > > Take care > > Terry > > > > > > > > > > > >> -----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 > >> loopbetween 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. > >> > >> 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 Thu Oct 9 10:00: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 1AB803A6B01; Thu, 9 Oct 2008 10:00:30 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F673A6B01 for ; Thu, 9 Oct 2008 10:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q81vOXKjRz2X for ; Thu, 9 Oct 2008 10:00:25 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 917A53A6AC9 for ; Thu, 9 Oct 2008 10:00:25 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so94577rvf.49 for ; Thu, 09 Oct 2008 10:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Th0QZLGYltSsxgNT7RI1uIhVJfmbWdyJoNjkKI3SWaE=; b=sWobpWTfHUvOaK3OjazfRghyjJ26Z4NWzd0FDHHyyO6yp+Y/ilmTCWAHH8/xQbaDHL 9f2GWhIiE1ZPMJ6D2vgR2bDpRmvssTz4y+tfL0aw5UDsh3I2IsVECpKqdJs/FV4hIR4M gWV+Wl1p2HF2PiEKiJiZQ9OUeMUx8zMdjpRK4= 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=J9zEGFRuSr8ZrWSKUNPw+DRYSijRKvUM4NOsM1OmfJ4Sg4BfEPdlZDIOQAF8f3YDaz J0AtLIS/mgRQzngFbcwLrQptpmMhqKP/vRL59tj2KbjxRQpzOYUlLhHcmL+tzIDYVfJz x9un78A8yL8o6Nwx4r6kaWPXK8oLcrx20XSys= Received: by 10.140.226.14 with SMTP id y14mr295390rvg.123.1223571625094; Thu, 09 Oct 2008 10:00:25 -0700 (PDT) Received: by 10.141.168.21 with HTTP; Thu, 9 Oct 2008 10:00:25 -0700 (PDT) Message-ID: <5e2406980810091000q3cea6b13md4bc67b854230064@mail.gmail.com> Date: Thu, 9 Oct 2008 19:00:25 +0200 From: "Julien Bournelle" To: "Basavaraj Patil" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <48E55E5F.5040101@earthlink.net> 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, I'm not sure that this is a non-issue for mip6. The fact is that any deployment of mip6 will have this issue and it would be probably best if IETF comes with a solution. Regards, Julien On Mon, Oct 6, 2008 at 7:16 PM, Basavaraj Patil wrote: > > Charlie, > > I don't see this issue being specific to MIP6 base spec. The fact that such > a threat may arise as a result of multihoming is outside the scope of MIP6 > protocol itself. > > IMO this is a non-issue for MIP6. > > -Raj > > > On 10/2/08 6:50 PM, "Charles Perkins" wrote: > >> >> 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. >> >> 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 Thu Oct 9 10:14: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 335233A6AE0; Thu, 9 Oct 2008 10:14:11 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77D983A6AE0 for ; Thu, 9 Oct 2008 10:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.393 X-Spam-Level: X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 0rAoFumNjpMR for ; Thu, 9 Oct 2008 10:14:09 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 784753A67DD for ; Thu, 9 Oct 2008 10:14:09 -0700 (PDT) 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 m99HDN1w019762; Thu, 9 Oct 2008 12:14:25 -0500 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Oct 2008 20:13:44 +0300 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Oct 2008 12:13:38 -0500 Received: from 10.162.252.195 ([10.162.252.195]) by daebe104.NOE.Nokia.com ([10.241.36.13]) with Microsoft Exchange Server HTTP-DAV ; Thu, 9 Oct 2008 17:13:37 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Thu, 09 Oct 2008 12:13:38 -0500 From: Basavaraj Patil To: ext Julien Bournelle Message-ID: Thread-Topic: [MEXT] Issue #17: Multi-homed mobile node can cause routing loop between home agents Thread-Index: AckqMl6QIr7q81j6hU2VuXhUjX5EFQ== In-Reply-To: <5e2406980810091000q3cea6b13md4bc67b854230064@mail.gmail.com> Mime-version: 1.0 X-OriginalArrivalTime: 09 Oct 2008 17:13:38.0269 (UTC) FILETIME=[5EB918D0:01C92A32] X-Nokia-AV: Clean 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 Julien, One minor recommendation for deployments concerned with this issue would be to avoid using the Alt-CoA address in creating the binding. But I guess you will have to convince the WG about the scenario which results in such a threat more explicitly and then determine if there is a need to deal with it. -Raj On 10/9/08 12:00 PM, "ext Julien Bournelle" wrote: > Hi, > > I'm not sure that this is a non-issue for mip6. The fact is that any > deployment > of mip6 will have this issue and it would be probably best if IETF comes with > a solution. > > Regards, > > Julien > > On Mon, Oct 6, 2008 at 7:16 PM, Basavaraj Patil > wrote: >> >> Charlie, >> >> I don't see this issue being specific to MIP6 base spec. The fact that such >> a threat may arise as a result of multihoming is outside the scope of MIP6 >> protocol itself. >> >> IMO this is a non-issue for MIP6. >> >> -Raj >> >> >> On 10/2/08 6:50 PM, "Charles Perkins" wrote: >> >>> >>> 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. >>> >>> 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 Fri Oct 10 06:08: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 547A728C1A6; Fri, 10 Oct 2008 06:08:20 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E637128C15F; Fri, 10 Oct 2008 06:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 2spXwDPk4cY7; Fri, 10 Oct 2008 06:08:18 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B46AD3A69C9; Fri, 10 Oct 2008 06:08:17 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m9AD8Ur26168; Fri, 10 Oct 2008 13:08:31 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Oct 2008 08:08:29 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] comment ondraft-ietf-mext-binding-revocation-01 Thread-Index: Ackq1/c5JaDLzztOS0C4tWqOAwjHtAAACPwgAAA83QA= From: "Ahmad Muhanna" To: "Premec, Domagoj" Cc: Netlmm , mext@ietf.org Subject: [MEXT] FW: [netlmm] comment ondraft-ietf-mext-binding-revocation-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 **** Adding Mext mailing list. Also correcting the subject. Comment is on binding revocation not GRE:) *** Hi Domagoj, I believe this is a valid concern. I guess either way should work, but I believe the cleaner solution is to have some text to indicate that if the alt-CoA included in the PBU, the revocation should be sent to the same address the PBA is sent to. In this case the source of the PBU. If people feels that is the best approach, we can add some clarification to the draft. What do you think? Regards, Ahmad > -----Original Message----- > From: Premec, Domagoj [mailto:domagoj.premec@siemens.com] > Sent: Friday, October 10, 2008 7:59 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Netlmm > Subject: comment on draft-ietf-netlmm-grekey-option-01 > > Hi Ahmad, > > I have a comment on the interactions between the binding revocation > mechanism and the alt-CoA usage as specified in RFC 5213. According to > the RFC 5213, the MAG is allowed to use the alt-CoA to redirect the > downlink traffic to an address different from the source address of > the PBU. In this case the Binding revocation will get sent to the > alt-CoA address, but I think it should actually be sent to the source > address of the PBU, as this is where the signalling part of the MAG is > located. Is this is a valid concern or should we assume that the MAG > also accepts signalling messages at the alt-CoA? > > domagoj > > _______________________________________________ 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 Fri Oct 10 06:31: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 B71BC28C1A0; Fri, 10 Oct 2008 06:31:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2801B3A69C9; Fri, 10 Oct 2008 06:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbFtdxjqXk6o; Fri, 10 Oct 2008 06:31:45 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 5E3AA3A67E3; Fri, 10 Oct 2008 06:31:45 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m9ADT3G10906; Fri, 10 Oct 2008 13:29:04 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Oct 2008 08:31:45 -0500 Message-ID: In-Reply-To: <3C31CDD06342EA4A8137716247B1CD68046943E9@zagh223a.ww300.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comment on draft-ietf-binding-revocation-01 Thread-Index: Ackq1/c5JaDLzztOS0C4tWqOAwjHtAAACPwgAABVfQAAAKnk4A== References: <3C31CDD06342EA4A8137716247B1CD68046943AE@zagh223a.ww300.siemens.net> <3C31CDD06342EA4A8137716247B1CD68046943E9@zagh223a.ww300.siemens.net> From: "Ahmad Muhanna" To: "Premec, Domagoj" Cc: Netlmm , mext@ietf.org Subject: Re: [MEXT] comment on draft-ietf-binding-revocation-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 Domagoj, I agree. Let us wait and see what other folks think of this. If there is no objection, then we can add the clarification text and the new field in the MN BCE at the LMA. Thanks! Regards, Ahmad > -----Original Message----- > From: Premec, Domagoj [mailto:domagoj.premec@siemens.com] > Sent: Friday, October 10, 2008 8:14 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Netlmm > Subject: RE: comment on draft-ietf-binding-revocation-01 > > Ahmad, > > IMO sending the Binding revocation to the source IP of the > PBU is the right way to go and I'd like to see this > documented in the draft. Though this will require the > extension of the BCE structure as the LMA will need to save > both the source IP of the PBU and the alt-CoA. > > domagoj > > > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: 10. listopad 2008 15:03 > > To: Premec, Domagoj > > Cc: Netlmm > > Subject: RE: comment on draft-ietf-netlmm-grekey-option-01 > > > > Hi Domagoj, > > > > I believe this is a valid concern. I guess either way > should work, but > > I believe the cleaner solution is to have some text to > indicate that > > if the alt-CoA included in the PBU, the revocation should > be sent to > > the same address the PBA is sent to. In this case the source of the > > PBU. > > > > If people feels that is the best approach, we can add some > > clarification to the draft. > > > > What do you think? > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Premec, Domagoj [mailto:domagoj.premec@siemens.com] > > > Sent: Friday, October 10, 2008 7:59 AM > > > To: Muhanna, Ahmad (RICH1:2H10) > > > Cc: Netlmm > > > Subject: comment on draft-ietf-netlmm-grekey-option-01 > > > > > > Hi Ahmad, > > > > > > I have a comment on the interactions between the binding > revocation > > > mechanism and the alt-CoA usage as specified in RFC 5213. > > According to > > > the RFC 5213, the MAG is allowed to use the alt-CoA to > redirect the > > > downlink traffic to an address different from the source > address of > > > the PBU. In this case the Binding revocation will get sent to the > > > alt-CoA address, but I think it should actually be sent to > > the source > > > address of the PBU, as this is where the signalling part of > > the MAG is > > > located. Is this is a valid concern or should we assume > > that the MAG > > > also accepts signalling messages at the alt-CoA? > > > > > > domagoj > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Oct 10 14:29: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 3127B3A6A6F; Fri, 10 Oct 2008 14:29:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7AD13A69CB; Fri, 10 Oct 2008 14:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 IQO0ogMjx4X5; Fri, 10 Oct 2008 14:29:38 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 02BDC3A6901; Fri, 10 Oct 2008 14:29:37 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Oct 2008 17:30:19 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-01 Thread-Index: Ackq1/c5JaDLzztOS0C4tWqOAwjHtAAACPwgAAA83QAAEVIqoA== References: From: "Vijay Devarapalli" To: "Ahmad Muhanna" , "Premec, Domagoj" Cc: Netlmm , mext@ietf.org Subject: Re: [MEXT] [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 Domagoj, Ahmad, In MIPv6, if the binding update is successful, the binding ack is always sent to the CoA and not to the source address of the BU. If the AltCoA option is used, then the binding ack would go back to the address that appeared in the AltCoA option. In PMIPv6, I don't believe there is a scenario where you would want to use the AltCoA option. (if someone has a valid scenario, please let me know). netlmm-bounces@ietf.org wrote: > **** Adding Mext mailing list. Also correcting the subject. Comment is > on binding revocation not GRE:) *** > > Hi Domagoj, > > I believe this is a valid concern. I guess either way should > work, but I > believe the cleaner solution is to have some text to indicate that if > the alt-CoA included in the PBU, the revocation should be sent to the > same address the PBA is sent to. In this case the source of the PBU. *If* the AltCoA option is used, then the address that appears in the AltCoA option would be stored as the proxy CoA in the binding cache entry. When a binding revocation needs to be sent, it would be sent to the proxy CoA in the binding cache entry. For the binding revocation document, I think it is sufficient to say that the revocation message is sent to the Proxy CoA. It shouldn't say anything about the source address of the PBU or the address in the AltCoA option. In other words, the binding revocation document should not care about the use of AltCoA option. Vijay > > If people feels that is the best approach, we can add some > clarification to the draft. > > What do you think? > > Regards, > Ahmad > > >> -----Original Message----- >> From: Premec, Domagoj [mailto:domagoj.premec@siemens.com] >> Sent: Friday, October 10, 2008 7:59 AM >> To: Muhanna, Ahmad (RICH1:2H10) >> Cc: Netlmm >> Subject: comment on draft-ietf-netlmm-grekey-option-01 >> >> Hi Ahmad, >> >> I have a comment on the interactions between the binding revocation >> mechanism and the alt-CoA usage as specified in RFC 5213. According >> to > >> the RFC 5213, the MAG is allowed to use the alt-CoA to redirect the >> downlink traffic to an address different from the source address of >> the PBU. In this case the Binding revocation will get sent to the >> alt-CoA address, but I think it should actually be sent to the source >> address of the PBU, as this is where the signalling part of the MAG >> is > >> located. Is this is a valid concern or should we assume that the MAG >> also accepts signalling messages at the alt-CoA? >> >> domagoj >> >> > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Oct 10 16:54: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 4AA7E3A6ACD; Fri, 10 Oct 2008 16:54:05 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D881C28C0D8 for ; Fri, 10 Oct 2008 16:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.653 X-Spam-Level: X-Spam-Status: No, score=-5.653 tagged_above=-999 required=5 tests=[AWL=0.946, 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 RjTjNIfVFxOl for ; Fri, 10 Oct 2008 16:54:03 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id D5B7B3A6ACD for ; Fri, 10 Oct 2008 16:54:02 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (158.pool85-53-140.dynamic.orange.es [85.53.140.158])by smtp03.uc3m.es (Postfix) with ESMTP id C0C166A1506for ; Sat, 11 Oct 2008 01:54:46 +0200 (CEST) Message-ID: <48EFEB46.2030703@it.uc3m.es> Date: Sat, 11 Oct 2008 01:54:46 +0200 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:N SM:2 X-imss-tmaseResult: TT:1 TS:-17.7446 TC:1F TRN:20 TV:5.5.1026(16210.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [MEXT] [Fwd: MEXT - Requested sessions have been scheduled 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 FYI -------- Mensaje original -------- Asunto: MEXT - Requested sessions have been scheduled for IETF 73 Fecha: Fri, 10 Oct 2008 15:29:27 -0700 (PDT) De: IETF Secretariat Para: marcelo@it.uc3m.es CC: julien.laganier.IETF@googlemail.com, jari.arkko@piuha.net, townsley@cisco.com, session-request@ietf.org Dear Marcelo Bagnulo, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the information of sessions that you have requested. MEXT Session 1 (1.5 hours) Thursday, Afternoon Session I 1300-1500 Room Name: Meeting Room ---------------------------------------------- MEXT Session 2 (1.5 hours) Monday, Afternoon Session III 1740-1930 Room Name: Meeting Room ---------------------------------------------- Requested Information: --------------------------------------------------------- Working Group Name: mext Area Name: Internet Area Session Requester: Marcelo Bagnulo Number of Sessions: 2 Length of Session(s): 1.5 hours 1.5 hours Special Requests: --------------------------------------------------------- _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Oct 11 03:45: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 998743A6B3E; Sat, 11 Oct 2008 03:45:02 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 39BD43A6B11; Sat, 11 Oct 2008 03:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081011104501.39BD43A6B11@core3.amsl.com> Date: Sat, 11 Oct 2008 03:45:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-firewall-admin-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 --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 : Guidelines for firewall administrators regarding MIPv6 traffic Author(s) : S. Krishnan, et al. Filename : draft-ietf-mext-firewall-admin-00.txt Pages : 12 Date : 2008-10-10 This document presents some recommendations for firewall administrators to help them configure their existing firewalls in a way that allows in certain deployment scenarios the Mobile IPv6 signaling and data messages to pass through. For other scenarios, the support of additional mechanisms to create pinholes required for MIPv6 will be necessary. This document assumes that the firewalls in question include some kind of stateful packet filtering capability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-firewall-admin-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-mext-firewall-admin-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-11033310.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 Oct 11 03:45: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 F401128C18B; Sat, 11 Oct 2008 03:45:03 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3F9233A6B41; Sat, 11 Oct 2008 03:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081011104501.3F9233A6B41@core3.amsl.com> Date: Sat, 11 Oct 2008 03:45:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-firewall-vendor-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 --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 : Guidelines for firewall vendors regarding MIPv6 traffic Author(s) : S. Krishnan, et al. Filename : draft-ietf-mext-firewall-vendor-00.txt Pages : 9 Date : 2008-10-10 This document presents some recommendations for firewall vendors to help them implement their firewalls in a way that allows Mobile IPv6 signaling and data messages to pass through. This document describes how to implement stateful packet filtering capability for MIPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-firewall-vendor-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-mext-firewall-vendor-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-11033324.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 Oct 13 03:59: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 D77043A6B8A; Mon, 13 Oct 2008 03:59:24 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1033A6B8A; Mon, 13 Oct 2008 03:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.573 X-Spam-Level: X-Spam-Status: No, score=-4.573 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 zJvIxmClC8TA; Mon, 13 Oct 2008 03:59:22 -0700 (PDT) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id 5AE1E3A659B; Mon, 13 Oct 2008 03:59:22 -0700 (PDT) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id m9DB0EbQ022540; Mon, 13 Oct 2008 13:00:14 +0200 Received: from nets138a.ww300.siemens.net ([192.168.217.3]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m9DB0DmA027287; Mon, 13 Oct 2008 13:00:14 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Oct 2008 13:00:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Oct 2008 13:00:10 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD68046BE9A0@zagh223a.ww300.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-01 Thread-Index: Ackq1/c5JaDLzztOS0C4tWqOAwjHtAAACPwgAAA83QAAEVIqoACA4NgA References: From: "Premec, Domagoj" To: "Vijay Devarapalli" , "Ahmad Muhanna" X-OriginalArrivalTime: 13 Oct 2008 11:00:13.0022 (UTC) FILETIME=[DDCEB7E0:01C92D22] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::081013130014-0BA2EBA0-52626A29/0-0/0-15 X-purgate-size: 4062/0 Cc: Netlmm , mext@ietf.org Subject: Re: [MEXT] [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 Vijay, RFC 5213 mentiones the usage of alt-CoA at several places, for example: 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. I thought that the scenario in mind here is the MAG with one control plane blade and several data plane blades, and the alt-CoA would contain the address of the data plane. domagoj > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: 10. listopad 2008 23:30 > To: Ahmad Muhanna; Premec, Domagoj > Cc: Netlmm; mext@ietf.org > Subject: RE: [netlmm] FW: comment > ondraft-ietf-mext-binding-revocation-01 > > Hi Domagoj, Ahmad, > > In MIPv6, if the binding update is successful, the binding > ack is always sent to the CoA and not to the source address > of the BU. If the AltCoA option is used, then the binding ack > would go back to the address that appeared in the AltCoA option. > > In PMIPv6, I don't believe there is a scenario where you > would want to use the AltCoA option. (if someone has a valid > scenario, please let me know). > > netlmm-bounces@ietf.org wrote: > > **** Adding Mext mailing list. Also correcting the subject. > Comment is > > on binding revocation not GRE:) *** > > > > Hi Domagoj, > > > > I believe this is a valid concern. I guess either way > should work, but > > I believe the cleaner solution is to have some text to > indicate that > > if the alt-CoA included in the PBU, the revocation should > be sent to > > the same address the PBA is sent to. In this case the source of the > > PBU. > > *If* the AltCoA option is used, then the address that appears > in the AltCoA option would be stored as the proxy CoA in the > binding cache entry. When a binding revocation needs to be > sent, it would be sent to the proxy CoA in the binding cache > entry. For the binding revocation document, I think it is > sufficient to say that the revocation message is sent to the > Proxy CoA. It shouldn't say anything about the source address > of the PBU or the address in the AltCoA option. In other > words, the binding revocation document should not care about > the use of AltCoA option. > > Vijay > > > > > If people feels that is the best approach, we can add some > > clarification to the draft. > > > > What do you think? > > > > Regards, > > Ahmad > > > > > >> -----Original Message----- > >> From: Premec, Domagoj [mailto:domagoj.premec@siemens.com] > >> Sent: Friday, October 10, 2008 7:59 AM > >> To: Muhanna, Ahmad (RICH1:2H10) > >> Cc: Netlmm > >> Subject: comment on draft-ietf-netlmm-grekey-option-01 > >> > >> Hi Ahmad, > >> > >> I have a comment on the interactions between the binding > revocation > >> mechanism and the alt-CoA usage as specified in RFC 5213. > According > >> to > > > >> the RFC 5213, the MAG is allowed to use the alt-CoA to > redirect the > >> downlink traffic to an address different from the source > address of > >> the PBU. In this case the Binding revocation will get sent to the > >> alt-CoA address, but I think it should actually be sent to > the source > >> address of the PBU, as this is where the signalling part > of the MAG > >> is > > > >> located. Is this is a valid concern or should we assume > that the MAG > >> also accepts signalling messages at the alt-CoA? > >> > >> domagoj > >> > >> > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Oct 13 11: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 7378E28C14C; Mon, 13 Oct 2008 11:10:01 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894B73A6820; Mon, 13 Oct 2008 11:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 XhTMCfDG7DzV; Mon, 13 Oct 2008 11:09:59 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id EA8383A68E3; Mon, 13 Oct 2008 11:09:58 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Oct 2008 14:09:57 -0400 Message-ID: In-Reply-To: <3C31CDD06342EA4A8137716247B1CD68046BE9A0@zagh223a.ww300.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-01 Thread-Index: Ackq1/c5JaDLzztOS0C4tWqOAwjHtAAACPwgAAA83QAAEVIqoACA4NgAAA7ZjiA= References: <3C31CDD06342EA4A8137716247B1CD68046BE9A0@zagh223a.ww300.siemens.net> From: "Vijay Devarapalli" To: "Premec, Domagoj" , "Ahmad Muhanna" Cc: Netlmm , mext@ietf.org Subject: Re: [MEXT] [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 Premec, Domagoj wrote: > Hi Vijay, > > RFC 5213 mentiones the usage of alt-CoA at several places, > for example: > > 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. > > I thought that the scenario in mind here is the MAG with one > control plane blade and several data plane blades, and the > alt-CoA would contain the address of the data plane. First of all, RFC 5213 did not extend the binding cache entry structure to store both the control plane and data plane addresses. RFC 5213 does not specify that the LMA should store both the source address of the PBU and the address in the altCoA option in the binding cache. There is only one address - the Proxy CoA, that is stored in the binding cache entry. So trying to send the binding revocation indication message to any other address, other than what is stored in the binding cache (Proxy CoA), may not work. Secondly, the above scenario is not realistic, IMHO. The different IP addresses for the control plane blade and the multiple data plane blades is typically not exposed to the other network elements. Each blade acting as a separate MAG is of course possible, but that is not relevant to what we are talking about here. Vijay > > domagoj > > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >> Sent: 10. listopad 2008 23:30 >> To: Ahmad Muhanna; Premec, Domagoj >> Cc: Netlmm; mext@ietf.org >> Subject: RE: [netlmm] FW: comment >> ondraft-ietf-mext-binding-revocation-01 >> >> Hi Domagoj, Ahmad, >> >> In MIPv6, if the binding update is successful, the binding >> ack is always sent to the CoA and not to the source address >> of the BU. If the AltCoA option is used, then the binding ack >> would go back to the address that appeared in the AltCoA option. >> >> In PMIPv6, I don't believe there is a scenario where you >> would want to use the AltCoA option. (if someone has a valid >> scenario, please let me know). >> >> netlmm-bounces@ietf.org wrote: >>> **** Adding Mext mailing list. Also correcting the subject. Comment >>> is on binding revocation not GRE:) *** >>> >>> Hi Domagoj, >>> >>> I believe this is a valid concern. I guess either way should work, >>> but I believe the cleaner solution is to have some text to indicate >>> that if the alt-CoA included in the PBU, the revocation should be >>> sent to the same address the PBA is sent to. In this case the >>> source of the PBU. >> >> *If* the AltCoA option is used, then the address that appears >> in the AltCoA option would be stored as the proxy CoA in the >> binding cache entry. When a binding revocation needs to be >> sent, it would be sent to the proxy CoA in the binding cache >> entry. For the binding revocation document, I think it is >> sufficient to say that the revocation message is sent to the >> Proxy CoA. It shouldn't say anything about the source address >> of the PBU or the address in the AltCoA option. In other >> words, the binding revocation document should not care about the use >> of AltCoA option. >> >> Vijay >> >>> >>> If people feels that is the best approach, we can add some >>> clarification to the draft. >>> >>> What do you think? >>> >>> Regards, >>> Ahmad >>> >>> >>>> -----Original Message----- >>>> From: Premec, Domagoj [mailto:domagoj.premec@siemens.com] >>>> Sent: Friday, October 10, 2008 7:59 AM >>>> To: Muhanna, Ahmad (RICH1:2H10) >>>> Cc: Netlmm >>>> Subject: comment on draft-ietf-netlmm-grekey-option-01 >>>> >>>> Hi Ahmad, >>>> >>>> I have a comment on the interactions between the binding revocation >>>> mechanism and the alt-CoA usage as specified in RFC 5213. According >>>> to >>> >>>> the RFC 5213, the MAG is allowed to use the alt-CoA to redirect the >>>> downlink traffic to an address different from the source address of >>>> the PBU. In this case the Binding revocation will get sent to the >>>> alt-CoA address, but I think it should actually be sent to the >>>> source address of the PBU, as this is where the signalling part of >>>> the MAG is >>> >>>> located. Is this is a valid concern or should we assume that the >>>> MAG also accepts signalling messages at the alt-CoA? >>>> >>>> domagoj >>>> >>>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/netlmm >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/netlmm _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 14 01:59: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 188CD3A6A50; Tue, 14 Oct 2008 01:59:35 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760BC3A6849 for ; Tue, 14 Oct 2008 01:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvEOkI4R2WVj for ; Tue, 14 Oct 2008 01:59:32 -0700 (PDT) Received: from cluster-b.mailcontrol.com (cluster-b.mailcontrol.com [217.68.146.190]) by core3.amsl.com (Postfix) with ESMTP id 0B0973A6A50 for ; Tue, 14 Oct 2008 01:59:31 -0700 (PDT) Received: from eundsmtpout02.pan.eu ([168.87.60.204]) by rly22b.srv.mailcontrol.com (MailControl) with ESMTP id m9E8xdW7028562 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 14 Oct 2008 09:59:40 +0100 Received: from eundadmi02.pan.eu ([10.109.33.23]) by eundsmtpout02.pan.eu (Lotus Domino Release 7.0.2) with ESMTP id 2008101410593333-352830 ; Tue, 14 Oct 2008 10:59:33 +0200 Received: from VPN-MRelay-02.PRDCG.Panasonic.de ([10.100.176.57]) by eundadmi02.pan.eu (Lotus Domino Release 7.0.3) with ESMTP id 2008101410593200-982396 ; Tue, 14 Oct 2008 10:59:32 +0200 Received: from localhost ([127.0.0.1]) by VPN-MRelay-02.PRDCG.Panasonic.de for mext@ietf.org; Tue, 14 Oct 2008 11:00:45 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New RFC3775bis issue "BU de-registration race condition"? Thread-Index: Ackt2reYg9mLVlzYTUGoi0HZZaFtnw== To: Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACBCF7B9E@lan-ex-02.panasonic.de> Date: Tue, 14 Oct 2008 10:59:16 +0200 From: "Kilian Weniger" X-MIMETrack: Itemize by SMTP Server on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 14.10.2008 10:59:32, Serialize by Router on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 14.10.2008 10:59:33, Serialize complete at 14.10.2008 10:59:33, Itemize by SMTP Server on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 10/14/2008 10:59:33 AM, Serialize by Router on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 10/14/2008 10:59:40 AM, Serialize complete at 10/14/2008 10:59:40 AM Content-class: urn:content-classes:message X-Scanned-By: MailControl A-08-50-15 (www.mailcontrol.com) on 10.66.0.132 Subject: [MEXT] New RFC3775bis issue "BU de-registration race condition"? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 think there is a possible race condition issue in RFC3775, which should be considered for RFC3775bis. The scenario is as follows: A MN returns home and sends a BU de-registration. Once the HA receives the de-registration, it deletes the BCE for the MN according to RFC3775. Now assume that just before returning home, the MN has sent a BU (either refresh BU or BU with new CoA due to handover) and that the BU is delayed and is received by the HA after the BU de-registration. Since the HA has just deleted the MN's BCE due to the received BU de-registration, the HA would accept the delayed BU without SN check and create a new BCE with a CoA pertaining to the previous location of the MN. This results in wrong forwarding state in the HA and hence packet loss for the MN till the MN sends a new BU (next handover of the MN or the lifetime of the BCE expires). A simple mitigation for this problem could be that the HA keeps some BCE information (at least HoA and SN) for some time after receiving a BU de-registration. This would enable the HA to identify a delayed BU as a delayed one based on the SN. Comments? BR, Kilian -------------------------------------------- Dr. Kilian Weniger Panasonic R&D Center Germany Monzastr. 4c, 63225 Langen, Germany phone: +49 (0)6103 766 137 fax: +49 (0)6103 766 166 e-mail: kilian.weniger@eu.panasonic.com -------------------------------------------- Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 14 03:18: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 6777428C126; Tue, 14 Oct 2008 03:18:18 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 967F63A6BA6 for ; Tue, 14 Oct 2008 03:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 Oy+gvRTN7vNp for ; Tue, 14 Oct 2008 03:18:16 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 343463A6BCC for ; Tue, 14 Oct 2008 03:18:15 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0ADB120E73; Tue, 14 Oct 2008 12:18:37 +0200 (CEST) X-AuditID: c1b4fb3c-af0d0bb0000015b5-65-48f471fc69ce Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C62D1206AD; Tue, 14 Oct 2008 12:18:36 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 12:18:29 +0200 Received: from [127.0.0.1] ([147.214.130.70]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 12:18:29 +0200 Message-ID: <48F471F4.8030503@ericsson.com> Date: Tue, 14 Oct 2008 12:18:28 +0200 From: Conny Larsson User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Kilian Weniger References: <1FEB9B9F2EC38343955D02B2AE86AACBCF7B9E@lan-ex-02.panasonic.de> In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACBCF7B9E@lan-ex-02.panasonic.de> X-OriginalArrivalTime: 14 Oct 2008 10:18:29.0242 (UTC) FILETIME=[33D9F5A0:01C92DE6] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] New RFC3775bis issue "BU de-registration race condition"? X-BeenThere: mext@ietf.org X-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 Kilian, I had a quick look in RFC3775 and I agree that it's not clear and most likely some clarifications would be good. However, I thought about the SA established between the MN and the HA. When the BCE is deleted does the SA go away as well? In case of static SAs I guess they remain but in case of dynamic SA establishment they could have been deleted and in that case the delayed BU would not be accepted and an ICMP message would be sent back to the MN. I need to look a bit more into RFC3775 to understand it better ... Regards Conny Kilian Weniger wrote: > Hi all, > > I think there is a possible race condition issue in RFC3775, which > should be considered for RFC3775bis. > > The scenario is as follows: A MN returns home and sends a BU > de-registration. Once the HA receives the de-registration, it deletes > the BCE for the MN according to RFC3775. Now assume that just before > returning home, the MN has sent a BU (either refresh BU or BU with new > CoA due to handover) and that the BU is delayed and is received by the > HA after the BU de-registration. > > Since the HA has just deleted the MN's BCE due to the received BU > de-registration, the HA would accept the delayed BU without SN check and > create a new BCE with a CoA pertaining to the previous location of the > MN. This results in wrong forwarding state in the HA and hence packet > loss for the MN till the MN sends a new BU (next handover of the MN or > the lifetime of the BCE expires). > > A simple mitigation for this problem could be that the HA keeps some BCE > information (at least HoA and SN) for some time after receiving a BU > de-registration. This would enable the HA to identify a delayed BU as a > delayed one based on the SN. > > Comments? > > BR, > > Kilian > > -------------------------------------------- > Dr. Kilian Weniger > Panasonic R&D Center Germany > Monzastr. 4c, 63225 Langen, Germany > phone: +49 (0)6103 766 137 > fax: +49 (0)6103 766 166 > e-mail: kilian.weniger@eu.panasonic.com > -------------------------------------------- > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 14 03:57: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 8F5863A6B7E; Tue, 14 Oct 2008 03:57:21 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E001E3A68D7 for ; Tue, 14 Oct 2008 03:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LA7kOJ2wKL6m for ; Tue, 14 Oct 2008 03:57:19 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id EC2683A67F8 for ; Tue, 14 Oct 2008 03:57:18 -0700 (PDT) Received: from [218.185.66.196] (helo=[172.16.8.68]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1Kphak-00030E-00; Tue, 14 Oct 2008 21:57:30 +1100 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Tue, 14 Oct 2008 21:57:26 +1100 From: Hesham Soliman To: Kilian Weniger , Message-ID: Thread-Topic: [MEXT] New RFC3775bis issue "BU de-registration race condition"? Thread-Index: Ackt2reYg9mLVlzYTUGoi0HZZaFtnwAEO0Rj In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACBCF7B9E@lan-ex-02.panasonic.de> Mime-version: 1.0 Subject: Re: [MEXT] New RFC3775bis issue "BU de-registration race condition"? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 14/10/08 7:59 PM, "Kilian Weniger" wrote: > Hi all, > > I think there is a possible race condition issue in RFC3775, which > should be considered for RFC3775bis. > > The scenario is as follows: A MN returns home and sends a BU > de-registration. Once the HA receives the de-registration, it deletes > the BCE for the MN according to RFC3775. Now assume that just before > returning home, the MN has sent a BU (either refresh BU or BU with new > CoA due to handover) and that the BU is delayed and is received by the > HA after the BU de-registration. > > Since the HA has just deleted the MN's BCE due to the received BU > de-registration, the HA would accept the delayed BU without SN check => How can it accept it without an IPsec SA? If the SA is already there it won't accept it. If the SA is no longer there then it won't accept it either. Hesham and > create a new BCE with a CoA pertaining to the previous location of the > MN. This results in wrong forwarding state in the HA and hence packet > loss for the MN till the MN sends a new BU (next handover of the MN or > the lifetime of the BCE expires). > > A simple mitigation for this problem could be that the HA keeps some BCE > information (at least HoA and SN) for some time after receiving a BU > de-registration. This would enable the HA to identify a delayed BU as a > delayed one based on the SN. > > Comments? > > BR, > > Kilian > > -------------------------------------------- > Dr. Kilian Weniger > Panasonic R&D Center Germany > Monzastr. 4c, 63225 Langen, Germany > phone: +49 (0)6103 766 137 > fax: +49 (0)6103 766 166 > e-mail: kilian.weniger@eu.panasonic.com > -------------------------------------------- > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 14 05:08: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 8BE3F3A6A3C; Tue, 14 Oct 2008 05:08:24 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9E23A6A3C for ; Tue, 14 Oct 2008 05:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 CZT4X0DjPJSH for ; Tue, 14 Oct 2008 05:08:22 -0700 (PDT) Received: from cluster-e.mailcontrol.com (cluster-e.mailcontrol.com [217.79.216.190]) by core3.amsl.com (Postfix) with ESMTP id BE3D23A67EE for ; Tue, 14 Oct 2008 05:08:21 -0700 (PDT) Received: from rly39e.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly39e.srv.mailcontrol.com (MailControl) with ESMTP id m9EC7rRf018562 for ; Tue, 14 Oct 2008 13:08:34 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly39e.srv.mailcontrol.com (MailControl) id m9EC7Waj017899 for mext@ietf.org; Tue, 14 Oct 2008 13:07:32 +0100 Received: from eundsmtpout02.pan.eu ([168.87.60.204]) by rly39e-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id m9EC7KaV016942; Tue, 14 Oct 2008 13:07:32 +0100 (BST) Received: from eundadmi02.pan.eu ([10.109.33.23]) by eundsmtpout02.pan.eu (Lotus Domino Release 7.0.2) with ESMTP id 2008101414071442-356032 ; Tue, 14 Oct 2008 14:07:14 +0200 Received: from VPN-MRelay-02.PRDCG.Panasonic.de ([10.100.176.57]) by eundadmi02.pan.eu (Lotus Domino Release 7.0.3) with ESMTP id 2008101414071112-997330 ; Tue, 14 Oct 2008 14:07:11 +0200 Received: from localhost ([127.0.0.1]) by VPN-MRelay-02.PRDCG.Panasonic.de; Tue, 14 Oct 2008 14:08:22 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <48F471F4.8030503@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] New RFC3775bis issue "BU de-registration race condition"? Thread-Index: Ackt5kkBcdIOaHm6TOazJBiKqDOWxwABvfUw References: <1FEB9B9F2EC38343955D02B2AE86AACBCF7B9E@lan-ex-02.panasonic.de> <48F471F4.8030503@ericsson.com> To: "Conny Larsson" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACBCF7BF0@lan-ex-02.panasonic.de> Date: Tue, 14 Oct 2008 14:06:50 +0200 From: "Kilian Weniger" X-MIMETrack: Itemize by SMTP Server on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 14.10.2008 14:07:13, Serialize by Router on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 14.10.2008 14:07:14, Serialize complete at 14.10.2008 14:07:14, Itemize by SMTP Server on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 10/14/2008 02:07:14 PM, Serialize by Router on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 10/14/2008 02:07:22 PM, Serialize complete at 10/14/2008 02:07:22 PM Content-class: urn:content-classes:message X-Scanned-By: MailControl A-08-50-15 (www.mailcontrol.com) on 10.69.1.149 Cc: mext@ietf.org Subject: Re: [MEXT] New RFC3775bis issue "BU de-registration race condition"? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Conny, Hesham, right, the delayed BU is not accepted by HA if the SAs for protecting MIP6 signaling traffic are deleted once the MN is returning home (i.e., when BU de-registration is received by HA). There is some related text in RFC3776: "When the mobile node returns home and de-registers with the Home Agent, the tunnel between the home agent and the mobile node's care-of address is torn down. The security policy entries, which were used for protecting tunneled traffic between the mobile node and the home agent MUST be made inactive (for instance, by removing them and installing them back later through an API). The corresponding security associations could be kept as they are or deleted depending on how they were created. If the security associations were created dynamically using IKE, they are automatically deleted when they expire. If the security associations were created through manual configuration, they MUST be retained and used later when the mobile node moves away from home again. The security associations protecting Binding Updates and Acknowledgements, and prefix discovery SHOULD NOT be deleted as they do not depend on care-of addresses and can be used again. According to this the SAs protecting data traffic are torn down, but the SAs protecting MIP6 signaling traffic should not be deleted when MN is returning home. BR, Kilian > -----Original Message----- > From: Conny Larsson [mailto:conny.larsson@ericsson.com] > Sent: Dienstag, 14. Oktober 2008 12:18 > To: Kilian Weniger > Cc: mext@ietf.org > Subject: Re: [MEXT] New RFC3775bis issue "BU de-registration > race condition"? > > Hi Kilian, > > I had a quick look in RFC3775 and I agree that it's not clear > and most > likely some clarifications would be good. However, I thought > about the > SA established between the MN and the HA. When the BCE is > deleted does > the SA go away as well? In case of static SAs I guess they > remain but in > case of dynamic SA establishment they could have been deleted and in > that case the delayed BU would not be accepted and an ICMP > message would > be sent back to the MN. I need to look a bit more into RFC3775 to > understand it better ... > > Regards > Conny > > Kilian Weniger wrote: > > Hi all, > > > > I think there is a possible race condition issue in RFC3775, which > > should be considered for RFC3775bis. > > > > The scenario is as follows: A MN returns home and sends a BU > > de-registration. Once the HA receives the de-registration, > it deletes > > the BCE for the MN according to RFC3775. Now assume that just before > > returning home, the MN has sent a BU (either refresh BU or > BU with new > > CoA due to handover) and that the BU is delayed and is > received by the > > HA after the BU de-registration. > > > > Since the HA has just deleted the MN's BCE due to the received BU > > de-registration, the HA would accept the delayed BU without > SN check and > > create a new BCE with a CoA pertaining to the previous > location of the > > MN. This results in wrong forwarding state in the HA and > hence packet > > loss for the MN till the MN sends a new BU (next handover > of the MN or > > the lifetime of the BCE expires). > > > > A simple mitigation for this problem could be that the HA > keeps some BCE > > information (at least HoA and SN) for some time after receiving a BU > > de-registration. This would enable the HA to identify a > delayed BU as a > > delayed one based on the SN. > > > > Comments? > > > > BR, > > > > Kilian > > > > -------------------------------------------- > > Dr. Kilian Weniger > > Panasonic R&D Center Germany > > Monzastr. 4c, 63225 Langen, Germany > > phone: +49 (0)6103 766 137 > > fax: +49 (0)6103 766 166 > > e-mail: kilian.weniger@eu.panasonic.com > > -------------------------------------------- > > > > > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 > > Managing Director: Thomas Micke > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > > Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 14 05:16: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 7F63D28C15C; Tue, 14 Oct 2008 05:16:11 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F4A28C0CF; Tue, 14 Oct 2008 05:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.541 X-Spam-Level: X-Spam-Status: No, score=-4.541 tagged_above=-999 required=5 tests=[AWL=0.889, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 qJVFd72yyI-I; Tue, 14 Oct 2008 05:16:08 -0700 (PDT) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id E48F33A692E; Tue, 14 Oct 2008 05:16:07 -0700 (PDT) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id m9E8oPIo030362; Tue, 14 Oct 2008 10:50:25 +0200 Received: from nets138a.ww300.siemens.net ([192.168.217.3]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m9E8oPm2028330; Tue, 14 Oct 2008 10:50:25 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 10:50:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 10:49:52 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD68046BEF39@zagh223a.ww300.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-01 Thread-Index: Ackq1/c5JaDLzztOS0C4tWqOAwjHtAAACPwgAAA83QAAEVIqoACA4NgAAA7ZjiAAHcSn8A== References: <3C31CDD06342EA4A8137716247B1CD68046BE9A0@zagh223a.ww300.siemens.net> From: "Premec, Domagoj" To: "Vijay Devarapalli" , "Ahmad Muhanna" X-OriginalArrivalTime: 14 Oct 2008 08:50:24.0394 (UTC) FILETIME=[E5D626A0:01C92DD9] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::081014105025-0BA28BA0-02219BA5/0-0/0-15 X-purgate-size: 7035/0 Cc: Netlmm , mext@ietf.org Subject: Re: [MEXT] [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 Vijay, > First of all, RFC 5213 did not extend the binding cache entry > structure to store both the control plane and data plane > addresses. RFC 5213 does not specify that the LMA should > store both the source address of the PBU and the address in > the altCoA option in the binding cache. This is not a problem from the perspective of RFC 5213 as the LMA does not send unsolicited messages to the MAG. In the context of RFC 5213 there is no need to store both the alt-CoA and the source IP of the PBU in the BCE, so I wouldn't expect RFC 5213 to specify any extensions to the BCE in this regard. > Secondly, the above scenario is not realistic, IMHO. The > different IP addresses for the control plane blade and the > multiple data plane blades is typically not exposed to the > other network elements. Well.. different designs are possible. I'm not going to argue that my interpretation of the intended alt-CoA usage is right. In fact, if I'm right then the mechanims for the other direction is missing (e.g. alt-CoA in PBAck) and we'd need to do something about it as this other direction is more important since the LMA has to deal with more load then the MAG. So if I agree with you, then I'm confused about the purpose of the alt-CoA in the RFC 5213, what is the usage for it? domagoj > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: 13. listopad 2008 20:10 > To: Premec, Domagoj; Ahmad Muhanna > Cc: Netlmm; mext@ietf.org > Subject: RE: [netlmm] FW: comment > ondraft-ietf-mext-binding-revocation-01 > > Premec, Domagoj wrote: > > Hi Vijay, > > > > RFC 5213 mentiones the usage of alt-CoA at several places, for > > example: > > > > 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. > > > > I thought that the scenario in mind here is the MAG with > one control > > plane blade and several data plane blades, and the alt-CoA would > > contain the address of the data plane. > > First of all, RFC 5213 did not extend the binding cache entry > structure to store both the control plane and data plane > addresses. RFC 5213 does not specify that the LMA should > store both the source address of the PBU and the address in > the altCoA option in the binding cache. There is only one > address - the Proxy CoA, that is stored in the binding cache entry. > So trying to send the binding revocation indication message > to any other address, other than what is stored in the > binding cache (Proxy CoA), may not work. > > Secondly, the above scenario is not realistic, IMHO. The > different IP addresses for the control plane blade and the > multiple data plane blades is typically not exposed to the > other network elements. Each blade acting as a separate MAG > is of course possible, but that is not relevant to what we > are talking about here. > > Vijay > > > > > > > domagoj > > > > > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] > >> Sent: 10. listopad 2008 23:30 > >> To: Ahmad Muhanna; Premec, Domagoj > >> Cc: Netlmm; mext@ietf.org > >> Subject: RE: [netlmm] FW: comment > >> ondraft-ietf-mext-binding-revocation-01 > >> > >> Hi Domagoj, Ahmad, > >> > >> In MIPv6, if the binding update is successful, the binding ack is > >> always sent to the CoA and not to the source address of the BU. If > >> the AltCoA option is used, then the binding ack would go > back to the > >> address that appeared in the AltCoA option. > >> > >> In PMIPv6, I don't believe there is a scenario where you > would want > >> to use the AltCoA option. (if someone has a valid scenario, please > >> let me know). > >> > >> netlmm-bounces@ietf.org wrote: > >>> **** Adding Mext mailing list. Also correcting the > subject. Comment > >>> is on binding revocation not GRE:) *** > >>> > >>> Hi Domagoj, > >>> > >>> I believe this is a valid concern. I guess either way > should work, > >>> but I believe the cleaner solution is to have some text > to indicate > >>> that if the alt-CoA included in the PBU, the revocation should be > >>> sent to the same address the PBA is sent to. In this case > the source > >>> of the PBU. > >> > >> *If* the AltCoA option is used, then the address that > appears in the > >> AltCoA option would be stored as the proxy CoA in the > binding cache > >> entry. When a binding revocation needs to be sent, it > would be sent > >> to the proxy CoA in the binding cache entry. For the binding > >> revocation document, I think it is sufficient to say that the > >> revocation message is sent to the Proxy CoA. It shouldn't say > >> anything about the source address of the PBU or the address in the > >> AltCoA option. In other words, the binding revocation > document should > >> not care about the use of AltCoA option. > >> > >> Vijay > >> > >>> > >>> If people feels that is the best approach, we can add some > >>> clarification to the draft. > >>> > >>> What do you think? > >>> > >>> Regards, > >>> Ahmad > >>> > >>> > >>>> -----Original Message----- > >>>> From: Premec, Domagoj [mailto:domagoj.premec@siemens.com] > >>>> Sent: Friday, October 10, 2008 7:59 AM > >>>> To: Muhanna, Ahmad (RICH1:2H10) > >>>> Cc: Netlmm > >>>> Subject: comment on draft-ietf-netlmm-grekey-option-01 > >>>> > >>>> Hi Ahmad, > >>>> > >>>> I have a comment on the interactions between the binding > revocation > >>>> mechanism and the alt-CoA usage as specified in RFC > 5213. According > >>>> to > >>> > >>>> the RFC 5213, the MAG is allowed to use the alt-CoA to > redirect the > >>>> downlink traffic to an address different from the source > address of > >>>> the PBU. In this case the Binding revocation will get > sent to the > >>>> alt-CoA address, but I think it should actually be sent to the > >>>> source address of the PBU, as this is where the > signalling part of > >>>> the MAG is > >>> > >>>> located. Is this is a valid concern or should we assume that the > >>>> MAG also accepts signalling messages at the alt-CoA? > >>>> > >>>> domagoj > >>>> > >>>> > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netlmm > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 14 06: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 AF1053A6BE6; Tue, 14 Oct 2008 06:46:50 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F2D28C1A4 for ; Tue, 14 Oct 2008 06:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6saAgcBZF8l for ; Tue, 14 Oct 2008 06:46:47 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8E5D63A6BDA for ; Tue, 14 Oct 2008 06:46:47 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m9EDkLM23722; Tue, 14 Oct 2008 13:46:21 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 08:46:19 -0500 Message-ID: In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACBCF7B9E@lan-ex-02.panasonic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] New RFC3775bis issue "BU de-registration race condition"? Thread-Index: Ackt2reYg9mLVlzYTUGoi0HZZaFtnwAI50oA References: <1FEB9B9F2EC38343955D02B2AE86AACBCF7B9E@lan-ex-02.panasonic.de> From: "Ahmad Muhanna" To: "Kilian Weniger" , Subject: Re: [MEXT] New RFC3775bis issue "BU de-registration race condition"? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Kilian, I see this a very very rare race condition that possibly may never happen. Both BU are sent by the mobile node and the mobile node, before it sent the de-registration BU, it is for sure aware that there is an outstanding BU that has not been acknowledged yet. So I am wondering why we need to consider this case? Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Kilian Weniger > Sent: Tuesday, October 14, 2008 3:59 AM > To: mext@ietf.org > Subject: [MEXT] New RFC3775bis issue "BU de-registration race > condition"? > > Hi all, > > I think there is a possible race condition issue in RFC3775, > which should be considered for RFC3775bis. > > The scenario is as follows: A MN returns home and sends a BU > de-registration. Once the HA receives the de-registration, it > deletes the BCE for the MN according to RFC3775. Now assume > that just before returning home, the MN has sent a BU (either > refresh BU or BU with new CoA due to handover) and that the > BU is delayed and is received by the HA after the BU de-registration. > > Since the HA has just deleted the MN's BCE due to the > received BU de-registration, the HA would accept the delayed > BU without SN check and create a new BCE with a CoA > pertaining to the previous location of the MN. This results > in wrong forwarding state in the HA and hence packet loss for > the MN till the MN sends a new BU (next handover of the MN or > the lifetime of the BCE expires). > > A simple mitigation for this problem could be that the HA > keeps some BCE information (at least HoA and SN) for some > time after receiving a BU de-registration. This would enable > the HA to identify a delayed BU as a delayed one based on the SN. > > Comments? > > BR, > > Kilian > > -------------------------------------------- > Dr. Kilian Weniger > Panasonic R&D Center Germany > Monzastr. 4c, 63225 Langen, Germany > phone: +49 (0)6103 766 137 > fax: +49 (0)6103 766 166 > e-mail: kilian.weniger@eu.panasonic.com > -------------------------------------------- > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 14 07:49: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 582CB3A6BF1; Tue, 14 Oct 2008 07:49:37 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04E53A6BF1 for ; Tue, 14 Oct 2008 07:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hFjFzK5-8kJ for ; Tue, 14 Oct 2008 07:49:31 -0700 (PDT) Received: from cluster-b.mailcontrol.com (cluster-b.mailcontrol.com [217.68.146.190]) by core3.amsl.com (Postfix) with ESMTP id E905F3A69C3 for ; Tue, 14 Oct 2008 07:49:30 -0700 (PDT) Received: from rly15b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly15b.srv.mailcontrol.com (MailControl) with ESMTP id m9EEncbj013826 for ; Tue, 14 Oct 2008 15:49:38 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly15b.srv.mailcontrol.com (MailControl) id m9EEnY4i013266 for mext@ietf.org; Tue, 14 Oct 2008 15:49:34 +0100 Received: from eundsmtpout02.pan.eu ([168.87.60.204]) by rly15b-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id m9EEnX6N012986; Tue, 14 Oct 2008 15:49:34 +0100 (BST) Received: from eundadmi02.pan.eu ([10.109.33.23]) by eundsmtpout02.pan.eu (Lotus Domino Release 7.0.2) with ESMTP id 2008101416493072-358240 ; Tue, 14 Oct 2008 16:49:30 +0200 Received: from VPN-MRelay-02.PRDCG.Panasonic.de ([10.100.176.57]) by eundadmi02.pan.eu (Lotus Domino Release 7.0.3) with ESMTP id 2008101416492814-1010200 ; Tue, 14 Oct 2008 16:49:28 +0200 Received: from localhost ([127.0.0.1]) by VPN-MRelay-02.PRDCG.Panasonic.de; Tue, 14 Oct 2008 16:50:42 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] New RFC3775bis issue "BU de-registration race condition"? Thread-Index: Ackt2reYg9mLVlzYTUGoi0HZZaFtnwAI50oAAAGevRA= References: <1FEB9B9F2EC38343955D02B2AE86AACBCF7B9E@lan-ex-02.panasonic.de> To: "Ahmad Muhanna" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACBCF7C1E@lan-ex-02.panasonic.de> Date: Tue, 14 Oct 2008 16:49:10 +0200 From: "Kilian Weniger" X-MIMETrack: Itemize by SMTP Server on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 14.10.2008 16:49:29, Serialize by Router on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 14.10.2008 16:49:31, Serialize complete at 14.10.2008 16:49:31, Itemize by SMTP Server on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 10/14/2008 04:49:30 PM, Serialize by Router on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 10/14/2008 04:49:34 PM, Serialize complete at 10/14/2008 04:49:34 PM Content-class: urn:content-classes:message X-Scanned-By: MailControl A-08-50-15 (www.mailcontrol.com) on 10.66.1.125 Cc: mext@ietf.org Subject: Re: [MEXT] New RFC3775bis issue "BU de-registration race condition"? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, > I see this a very very rare race condition that possibly may never > happen. I agree this is a very rare case, but the consequence can be drastic (packet loss till next BU). Furthermore, I think this case is not less likely than the case that registration Binding Updates overtake each other, which is handled in RFC3775 by sequencing of Binding Updates with the Sequence Number. Or do you say sequencing of Binding Updates is not needed at all in RFC3775bis? > Both BU are sent by the mobile node and the mobile node, > before it sent > the de-registration BU, it is for sure aware that there is an > outstanding BU that has not been acknowledged yet. Even though the MN knows that the previous BU has not been acknowledged yet, the MN does not know whether the BU has overtaken the BU de-reg or not, i.e., whether wrong forwarding state was actually established in HA or not. For instance, it is also possible that just the BAck was delayed/lost. > So I am wondering why we need to consider this case? see above for reasoning. BR, Kilian > > Regards, > Ahmad > > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of Kilian Weniger > > Sent: Tuesday, October 14, 2008 3:59 AM > > To: mext@ietf.org > > Subject: [MEXT] New RFC3775bis issue "BU de-registration race > > condition"? > > > > Hi all, > > > > I think there is a possible race condition issue in RFC3775, > > which should be considered for RFC3775bis. > > > > The scenario is as follows: A MN returns home and sends a BU > > de-registration. Once the HA receives the de-registration, it > > deletes the BCE for the MN according to RFC3775. Now assume > > that just before returning home, the MN has sent a BU (either > > refresh BU or BU with new CoA due to handover) and that the > > BU is delayed and is received by the HA after the BU > de-registration. > > > > Since the HA has just deleted the MN's BCE due to the > > received BU de-registration, the HA would accept the delayed > > BU without SN check and create a new BCE with a CoA > > pertaining to the previous location of the MN. This results > > in wrong forwarding state in the HA and hence packet loss for > > the MN till the MN sends a new BU (next handover of the MN or > > the lifetime of the BCE expires). > > > > A simple mitigation for this problem could be that the HA > > keeps some BCE information (at least HoA and SN) for some > > time after receiving a BU de-registration. This would enable > > the HA to identify a delayed BU as a delayed one based on the SN. > > > > Comments? > > > > BR, > > > > Kilian > > > > -------------------------------------------- > > Dr. Kilian Weniger > > Panasonic R&D Center Germany > > Monzastr. 4c, 63225 Langen, Germany > > phone: +49 (0)6103 766 137 > > fax: +49 (0)6103 766 166 > > e-mail: kilian.weniger@eu.panasonic.com > > -------------------------------------------- > > > > > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 > > Managing Director: Thomas Micke > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 14 12:12: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 8E4A93A6849; Tue, 14 Oct 2008 12:12:41 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB40E3A6849 for ; Tue, 14 Oct 2008 12:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGieOHIaMAW1 for ; Tue, 14 Oct 2008 12:12:38 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id A0B4B3A63EC for ; Tue, 14 Oct 2008 12:12:38 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m9EJCZM13885; Tue, 14 Oct 2008 19:12:35 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 14:11:39 -0500 Message-ID: In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACBCF7C1E@lan-ex-02.panasonic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] New RFC3775bis issue "BU de-registration race condition"? Thread-Index: Ackt2reYg9mLVlzYTUGoi0HZZaFtnwAI50oAAAGevRAACmfngA== References: <1FEB9B9F2EC38343955D02B2AE86AACBCF7B9E@lan-ex-02.panasonic.de> <1FEB9B9F2EC38343955D02B2AE86AACBCF7C1E@lan-ex-02.panasonic.de> From: "Ahmad Muhanna" To: "Kilian Weniger" Cc: mext@ietf.org Subject: Re: [MEXT] New RFC3775bis issue "BU de-registration race condition"? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Kilian, > Subject: RE: [MEXT] New RFC3775bis issue "BU de-registration > race condition"? > > Hi Ahmad, > > > I see this a very very rare race condition that possibly may never > > happen. > > I agree this is a very rare case, but the consequence can be > drastic (packet loss till next BU). > > Furthermore, I think this case is not less likely than the > case that registration Binding Updates overtake each other, > which is handled in > RFC3775 by sequencing of Binding Updates with the Sequence > Number. Or do you say sequencing of Binding Updates is not > needed at all in RFC3775bis? [Ahmad] No I do not want any change for the way sequence number is handled; however, in this specific case, before the mobile node sends a de-registration BU, the mobile node knows for sure that there is an outstanding BU with a different CoA. IMO, the mobile node SHOULD wait until it receives a BA or expires all retransmissions before sending a de-registration. If that happens, this race condition is nothing but a theoretical one. > > > Both BU are sent by the mobile node and the mobile node, before it > > sent the de-registration BU, it is for sure aware that there is an > > outstanding BU that has not been acknowledged yet. > > Even though the MN knows that the previous BU has not been > acknowledged yet, the MN does not know whether the BU has > overtaken the BU de-reg or not, i.e., whether wrong > forwarding state was actually established in HA or not. For > instance, it is also possible that just the BAck was delayed/lost. [Ahmad] The mobile node does not need to know any of that at all. All what the mobile node needs to know is to make sure that the outstanding BU is handled properly according to RFC3775 before sending a new BU with a different CoA, which happened in this case to be a de-registration. > > > So I am wondering why we need to consider this case? > > see above for reasoning. > > BR, > > Kilian > > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: mext-bounces@ietf.org > [mailto:mext-bounces@ietf.org] On Behalf > > > Of Kilian Weniger > > > Sent: Tuesday, October 14, 2008 3:59 AM > > > To: mext@ietf.org > > > Subject: [MEXT] New RFC3775bis issue "BU de-registration race > > > condition"? > > > > > > Hi all, > > > > > > I think there is a possible race condition issue in > RFC3775, which > > > should be considered for RFC3775bis. > > > > > > The scenario is as follows: A MN returns home and sends a BU > > > de-registration. Once the HA receives the de-registration, it > > > deletes the BCE for the MN according to RFC3775. Now assume that > > > just before returning home, the MN has sent a BU (either > refresh BU > > > or BU with new CoA due to handover) and that the BU is > delayed and > > > is received by the HA after the BU > > de-registration. > > > > > > Since the HA has just deleted the MN's BCE due to the received BU > > > de-registration, the HA would accept the delayed BU > without SN check > > > and create a new BCE with a CoA pertaining to the > previous location > > > of the MN. This results in wrong forwarding state in the HA and > > > hence packet loss for the MN till the MN sends a new BU (next > > > handover of the MN or the lifetime of the BCE expires). > > > > > > A simple mitigation for this problem could be that the HA > keeps some > > > BCE information (at least HoA and SN) for some time after > receiving > > > a BU de-registration. This would enable the HA to > identify a delayed > > > BU as a delayed one based on the SN. > > > > > > Comments? > > > > > > BR, > > > > > > Kilian > > > > > > -------------------------------------------- > > > Dr. Kilian Weniger > > > Panasonic R&D Center Germany > > > Monzastr. 4c, 63225 Langen, Germany > > > phone: +49 (0)6103 766 137 > > > fax: +49 (0)6103 766 166 > > > e-mail: kilian.weniger@eu.panasonic.com > > > -------------------------------------------- > > > > > > > > > Panasonic R&D Center Germany GmbH > > > 63225 Langen, Hessen, Germany > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: > Thomas Micke > > > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 14 18:24: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 5612328C1FD; Tue, 14 Oct 2008 18:24:49 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80BF28C1FD; Tue, 14 Oct 2008 18:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.323 X-Spam-Level: X-Spam-Status: No, score=-0.323 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxEE8YoBS73M; Tue, 14 Oct 2008 18:24:47 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E298E28C1F6; Tue, 14 Oct 2008 18:24:46 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8R00CBYAMLLG@szxga04-in.huawei.com>; Wed, 15 Oct 2008 09:25:33 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8R001KSAMLC6@szxga04-in.huawei.com>; Wed, 15 Oct 2008 09:25:33 +0800 (CST) Received: from w52006b ([10.164.12.21]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K8R00LHWAMIE2@szxml05-in.huawei.com>; Wed, 15 Oct 2008 09:25:33 +0800 (CST) Date: Wed, 15 Oct 2008 09:25:30 +0800 From: Wang Yungui To: "Premec, Domagoj" Message-id: <01f201c92e64$e9842a50$150ca40a@china.huawei.com> Organization: HUAWEI TECHNOLOGIES CO.,LTD. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal X-RFC2646: Format=Flowed; Original References: <3C31CDD06342EA4A8137716247B1CD68046BE9A0@zagh223a.ww300.siemens.net> <3C31CDD06342EA4A8137716247B1CD68046BEF39@zagh223a.ww300.siemens.net> Cc: Netlmm , mext@ietf.org Subject: Re: [MEXT] [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Wang Yungui List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Domagoj Please see inline. ----- Original Message ----- From: "Premec, Domagoj" To: "Vijay Devarapalli" ; "Ahmad Muhanna" Cc: "Netlmm" ; Sent: Tuesday, October 14, 2008 4:49 PM Subject: Re: [MEXT] [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-01 > Vijay, > >> First of all, RFC 5213 did not extend the binding cache >> entry >> structure to store both the control plane and data plane >> addresses. RFC 5213 does not specify that the LMA should >> store both the source address of the PBU and the address >> in >> the altCoA option in the binding cache. > > This is not a problem from the perspective of RFC 5213 as > the LMA does not send unsolicited messages to the MAG. In > the context of RFC 5213 there is no need to store both the > alt-CoA and the source IP of the PBU in the BCE, so I > wouldn't expect RFC 5213 to specify any extensions to the > BCE in this regard. > [Yungui] The LMA may send the unsolicited messages to the MAG, such as heartbeat request message introduced in draft-ietf-netlmm-pmipv6-heartbeat-00.txt. However, I agree with Vijay's opinion in the last mail, "...In other words, the binding revocation document should not care about the use of AltCoA option." It's okey to make the binding revocation document comply with RFC3775 and RFC5213. In fact, in RFC3775, section 9.5.4. Sending Binding Acknowledgements, is described: " ...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." In RFC5213, there are some similiar description for PBA (section 5.3.6). Therefore, it seems the source address should be saved in the BCE. B.R. Yungui _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 14 22:06:45 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 29D413A6BA0; Tue, 14 Oct 2008 22:06:45 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1A873A67E7; Tue, 14 Oct 2008 22:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.457 X-Spam-Level: X-Spam-Status: No, score=-0.457 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBvBeYA5f75M; Tue, 14 Oct 2008 22:06:42 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 43F923A67FF; Tue, 14 Oct 2008 22:06:42 -0700 (PDT) Received: from 24.130.62.120 ([24.130.62.120]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Oct 2008 05:07:40 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 14 Oct 2008 22:07:39 -0700 From: Vijay Devarapalli To: "Premec, Domagoj" , Ahmad Muhanna Message-ID: Thread-Topic: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-01 Thread-Index: Ackq1/c5JaDLzztOS0C4tWqOAwjHtAAACPwgAAA83QAAEVIqoACA4NgAAA7ZjiAAHcSn8AAr55gk In-Reply-To: <3C31CDD06342EA4A8137716247B1CD68046BEF39@zagh223a.ww300.siemens.net> Mime-version: 1.0 Cc: Netlmm , mext@ietf.org Subject: Re: [MEXT] [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 On 10/14/08 1:49 AM, "Premec, Domagoj" wrote: > Vijay, > >> First of all, RFC 5213 did not extend the binding cache entry >> structure to store both the control plane and data plane >> addresses. RFC 5213 does not specify that the LMA should >> store both the source address of the PBU and the address in >> the altCoA option in the binding cache. > > This is not a problem from the perspective of RFC 5213 as the LMA does not > send unsolicited messages to the MAG. Well, one could use the HA Switch mechanism (RFC 5142) for the LMA to re-direct the MAG to another LMA. > In the context of RFC 5213 there is no > need to store both the alt-CoA and the source IP of the PBU in the BCE, so I > wouldn't expect RFC 5213 to specify any extensions to the BCE in this regard. > >> Secondly, the above scenario is not realistic, IMHO. The >> different IP addresses for the control plane blade and the >> multiple data plane blades is typically not exposed to the >> other network elements. > > Well.. different designs are possible. I'm not going to argue that my > interpretation of the intended alt-CoA usage is right. In fact, if I'm right > then the mechanims for the other direction is missing (e.g. alt-CoA in PBAck) > and we'd need to do something about it as this other direction is more > important since the LMA has to deal with more load then the MAG. > > So if I agree with you, then I'm confused about the purpose of the alt-CoA in > the RFC 5213, what is the usage for it? Coming back the discussion we were having, I think it is sufficient for the binding revocation document to say that the binding revocation indication message should be sent to the Proxy CoA. Vijay > > domagoj > > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >> Sent: 13. listopad 2008 20:10 >> To: Premec, Domagoj; Ahmad Muhanna >> Cc: Netlmm; mext@ietf.org >> Subject: RE: [netlmm] FW: comment >> ondraft-ietf-mext-binding-revocation-01 >> >> Premec, Domagoj wrote: >>> Hi Vijay, >>> >>> RFC 5213 mentiones the usage of alt-CoA at several places, for >>> example: >>> >>> 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. >>> >>> I thought that the scenario in mind here is the MAG with >> one control >>> plane blade and several data plane blades, and the alt-CoA would >>> contain the address of the data plane. >> >> First of all, RFC 5213 did not extend the binding cache entry >> structure to store both the control plane and data plane >> addresses. RFC 5213 does not specify that the LMA should >> store both the source address of the PBU and the address in >> the altCoA option in the binding cache. There is only one >> address - the Proxy CoA, that is stored in the binding cache entry. >> So trying to send the binding revocation indication message >> to any other address, other than what is stored in the >> binding cache (Proxy CoA), may not work. >> >> Secondly, the above scenario is not realistic, IMHO. The >> different IP addresses for the control plane blade and the >> multiple data plane blades is typically not exposed to the >> other network elements. Each blade acting as a separate MAG >> is of course possible, but that is not relevant to what we >> are talking about here. >> >> Vijay >> >> >> >>> >>> domagoj >>> >>> >>>> -----Original Message----- >>>> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >>>> Sent: 10. listopad 2008 23:30 >>>> To: Ahmad Muhanna; Premec, Domagoj >>>> Cc: Netlmm; mext@ietf.org >>>> Subject: RE: [netlmm] FW: comment >>>> ondraft-ietf-mext-binding-revocation-01 >>>> >>>> Hi Domagoj, Ahmad, >>>> >>>> In MIPv6, if the binding update is successful, the binding ack is >>>> always sent to the CoA and not to the source address of the BU. If >>>> the AltCoA option is used, then the binding ack would go >> back to the >>>> address that appeared in the AltCoA option. >>>> >>>> In PMIPv6, I don't believe there is a scenario where you >> would want >>>> to use the AltCoA option. (if someone has a valid scenario, please >>>> let me know). >>>> >>>> netlmm-bounces@ietf.org wrote: >>>>> **** Adding Mext mailing list. Also correcting the >> subject. Comment >>>>> is on binding revocation not GRE:) *** >>>>> >>>>> Hi Domagoj, >>>>> >>>>> I believe this is a valid concern. I guess either way >> should work, >>>>> but I believe the cleaner solution is to have some text >> to indicate >>>>> that if the alt-CoA included in the PBU, the revocation should be >>>>> sent to the same address the PBA is sent to. In this case >> the source >>>>> of the PBU. >>>> >>>> *If* the AltCoA option is used, then the address that >> appears in the >>>> AltCoA option would be stored as the proxy CoA in the >> binding cache >>>> entry. When a binding revocation needs to be sent, it >> would be sent >>>> to the proxy CoA in the binding cache entry. For the binding >>>> revocation document, I think it is sufficient to say that the >>>> revocation message is sent to the Proxy CoA. It shouldn't say >>>> anything about the source address of the PBU or the address in the >>>> AltCoA option. In other words, the binding revocation >> document should >>>> not care about the use of AltCoA option. >>>> >>>> Vijay >>>> >>>>> >>>>> If people feels that is the best approach, we can add some >>>>> clarification to the draft. >>>>> >>>>> What do you think? >>>>> >>>>> Regards, >>>>> Ahmad >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Premec, Domagoj [mailto:domagoj.premec@siemens.com] >>>>>> Sent: Friday, October 10, 2008 7:59 AM >>>>>> To: Muhanna, Ahmad (RICH1:2H10) >>>>>> Cc: Netlmm >>>>>> Subject: comment on draft-ietf-netlmm-grekey-option-01 >>>>>> >>>>>> Hi Ahmad, >>>>>> >>>>>> I have a comment on the interactions between the binding >> revocation >>>>>> mechanism and the alt-CoA usage as specified in RFC >> 5213. According >>>>>> to >>>>> >>>>>> the RFC 5213, the MAG is allowed to use the alt-CoA to >> redirect the >>>>>> downlink traffic to an address different from the source >> address of >>>>>> the PBU. In this case the Binding revocation will get >> sent to the >>>>>> alt-CoA address, but I think it should actually be sent to the >>>>>> source address of the PBU, as this is where the >> signalling part of >>>>>> the MAG is >>>>> >>>>>> located. Is this is a valid concern or should we assume that the >>>>>> MAG also accepts signalling messages at the alt-CoA? >>>>>> >>>>>> domagoj >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> netlmm mailing list >>>>> netlmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netlmm >>>>> _______________________________________________ >>>>> netlmm mailing list >>>>> netlmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netlmm >> >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Oct 15 01:19: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 EF0F53A68B3; Wed, 15 Oct 2008 01:19: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 872FA3A68B1 for ; Wed, 15 Oct 2008 01:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 hRvTEdLN51HJ for ; Wed, 15 Oct 2008 01:19:17 -0700 (PDT) Received: from cluster-b.mailcontrol.com (cluster-b.mailcontrol.com [217.68.146.190]) by core3.amsl.com (Postfix) with ESMTP id 050973A68B7 for ; Wed, 15 Oct 2008 01:19:15 -0700 (PDT) Received: from rly17b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly17b.srv.mailcontrol.com (MailControl) with ESMTP id m9F8JVuG003801 for ; Wed, 15 Oct 2008 09:19:50 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly17b.srv.mailcontrol.com (MailControl) id m9F8J48x001052 for mext@ietf.org; Wed, 15 Oct 2008 09:19:04 +0100 Received: from eundsmtpout02.pan.eu ([168.87.60.204]) by rly17b-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id m9F8IuXA032724; Wed, 15 Oct 2008 09:19:04 +0100 (BST) Received: from eundadmi02.pan.eu ([10.109.33.23]) by eundsmtpout02.pan.eu (Lotus Domino Release 7.0.2) with ESMTP id 2008101510185633-363400 ; Wed, 15 Oct 2008 10:18:56 +0200 Received: from VPN-MRelay-02.PRDCG.Panasonic.de ([10.100.176.57]) by eundadmi02.pan.eu (Lotus Domino Release 7.0.3) with ESMTP id 2008101510185218-1040818 ; Wed, 15 Oct 2008 10:18:52 +0200 Received: from localhost ([127.0.0.1]) by VPN-MRelay-02.PRDCG.Panasonic.de; Wed, 15 Oct 2008 10:20:04 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] New RFC3775bis issue "BU de-registration race condition"? Thread-Index: Ackt5kkBcdIOaHm6TOazJBiKqDOWxwABvfUwACXP3vcABVJCEA== References: <1FEB9B9F2EC38343955D02B2AE86AACBCF7BF0@lan-ex-02.panasonic.de> To: "Hesham Soliman" , "Kilian Weniger" , "Conny Larsson" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACBCF7CA3@lan-ex-02.panasonic.de> Date: Wed, 15 Oct 2008 10:18:29 +0200 From: "Kilian Weniger" X-MIMETrack: Itemize by SMTP Server on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 15.10.2008 10:18:52, Serialize by Router on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 15.10.2008 10:18:56, Serialize complete at 15.10.2008 10:18:56, Itemize by SMTP Server on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 10/15/2008 10:18:56 AM, Serialize by Router on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 10/15/2008 10:19:00 AM, Serialize complete at 10/15/2008 10:19:00 AM Content-class: urn:content-classes:message X-Scanned-By: MailControl A-08-50-15 (www.mailcontrol.com) on 10.66.1.127 Cc: mext@ietf.org Subject: Re: [MEXT] New RFC3775bis issue "BU de-registration race condition"? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, > => Right, so according to that and my previous email, the > race condition > can't happen because the BU sent from the old foreign network > will have an > old seq no. But how can the HA know that the seqno in the received BU is old? In this specific scenario the HA has deleted the MN's BCE containing the current seqno before receiving the delayed BU (upon receiving the BU de-registration). Or do you refer to the IPsec ESP seqno? IPsec ESP wouldn't discard a BU with old ESP seqno, since ESP doesn't provide correct ordering of messages (just anti-replay service). BR, Kilian > >> -----Original Message----- > >> From: Conny Larsson [mailto:conny.larsson@ericsson.com] > >> Sent: Dienstag, 14. Oktober 2008 12:18 > >> To: Kilian Weniger > >> Cc: mext@ietf.org > >> Subject: Re: [MEXT] New RFC3775bis issue "BU de-registration > >> race condition"? > >> > >> Hi Kilian, > >> > >> I had a quick look in RFC3775 and I agree that it's not clear > >> and most > >> likely some clarifications would be good. However, I thought > >> about the > >> SA established between the MN and the HA. When the BCE is > >> deleted does > >> the SA go away as well? In case of static SAs I guess they > >> remain but in > >> case of dynamic SA establishment they could have been > deleted and in > >> that case the delayed BU would not be accepted and an ICMP > >> message would > >> be sent back to the MN. I need to look a bit more into RFC3775 to > >> understand it better ... > >> > >> Regards > >> Conny > >> > >> Kilian Weniger wrote: > >>> Hi all, > >>> > >>> I think there is a possible race condition issue in RFC3775, which > >>> should be considered for RFC3775bis. > >>> > >>> The scenario is as follows: A MN returns home and sends a BU > >>> de-registration. Once the HA receives the de-registration, > >> it deletes > >>> the BCE for the MN according to RFC3775. Now assume that > just before > >>> returning home, the MN has sent a BU (either refresh BU or > >> BU with new > >>> CoA due to handover) and that the BU is delayed and is > >> received by the > >>> HA after the BU de-registration. > >>> > >>> Since the HA has just deleted the MN's BCE due to the received BU > >>> de-registration, the HA would accept the delayed BU without > >> SN check and > >>> create a new BCE with a CoA pertaining to the previous > >> location of the > >>> MN. This results in wrong forwarding state in the HA and > >> hence packet > >>> loss for the MN till the MN sends a new BU (next handover > >> of the MN or > >>> the lifetime of the BCE expires). > >>> > >>> A simple mitigation for this problem could be that the HA > >> keeps some BCE > >>> information (at least HoA and SN) for some time after > receiving a BU > >>> de-registration. This would enable the HA to identify a > >> delayed BU as a > >>> delayed one based on the SN. > >>> > >>> Comments? > >>> > >>> BR, > >>> > >>> Kilian > >>> > >>> -------------------------------------------- > >>> Dr. Kilian Weniger > >>> Panasonic R&D Center Germany > >>> Monzastr. 4c, 63225 Langen, Germany > >>> phone: +49 (0)6103 766 137 > >>> fax: +49 (0)6103 766 166 > >>> e-mail: kilian.weniger@eu.panasonic.com > >>> -------------------------------------------- > >>> > >>> > >>> Panasonic R&D Center Germany GmbH > >>> 63225 Langen, Hessen, Germany > >>> Reg: AG Offenbach (Hessen) HRB 33974 > >>> Managing Director: Thomas Micke > >>> > >>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >>> > >> > >> > >> > > > > > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 > > Managing Director: Thomas Micke > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Oct 15 01:20: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 C0A3B3A68B3; Wed, 15 Oct 2008 01:20:53 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0775B3A68B3 for ; Wed, 15 Oct 2008 01:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXmt0Ka4njMn for ; Wed, 15 Oct 2008 01:20:52 -0700 (PDT) Received: from cluster-b.mailcontrol.com (cluster-b.mailcontrol.com [217.68.146.190]) by core3.amsl.com (Postfix) with ESMTP id 831BC3A6852 for ; Wed, 15 Oct 2008 01:20:50 -0700 (PDT) Received: from rly39b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly39b.srv.mailcontrol.com (MailControl) with ESMTP id m9F8Kxpe011379 for ; Wed, 15 Oct 2008 09:20:59 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly39b.srv.mailcontrol.com (MailControl) id m9F8JAbt006732 for mext@ietf.org; Wed, 15 Oct 2008 09:19:10 +0100 Received: from eundsmtpout02.pan.eu ([168.87.60.204]) by rly39b-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id m9F8Im4a005451; Wed, 15 Oct 2008 09:19:07 +0100 (BST) Received: from eundadmi02.pan.eu ([10.109.33.23]) by eundsmtpout02.pan.eu (Lotus Domino Release 7.0.2) with ESMTP id 2008101510184838-363397 ; Wed, 15 Oct 2008 10:18:48 +0200 Received: from VPN-MRelay-02.PRDCG.Panasonic.de ([10.100.176.57]) by eundadmi02.pan.eu (Lotus Domino Release 7.0.3) with ESMTP id 2008101510184715-1040809 ; Wed, 15 Oct 2008 10:18:47 +0200 Received: from localhost ([127.0.0.1]) by VPN-MRelay-02.PRDCG.Panasonic.de; Wed, 15 Oct 2008 10:20:03 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] New RFC3775bis issue "BU de-registration race condition"? Thread-Index: Ackt2reYg9mLVlzYTUGoi0HZZaFtnwAI50oAAAGevRAACmfngAAaQlZQ References: <1FEB9B9F2EC38343955D02B2AE86AACBCF7B9E@lan-ex-02.panasonic.de> <1FEB9B9F2EC38343955D02B2AE86AACBCF7C1E@lan-ex-02.panasonic.de> To: "Ahmad Muhanna" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACBCF7CA2@lan-ex-02.panasonic.de> Date: Wed, 15 Oct 2008 10:15:30 +0200 From: "Kilian Weniger" X-MIMETrack: Itemize by SMTP Server on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 15.10.2008 10:18:47, Serialize by Router on EUNDADMI02/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 15.10.2008 10:18:48, Serialize complete at 15.10.2008 10:18:48, Itemize by SMTP Server on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 10/15/2008 10:18:48 AM, Serialize by Router on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 10/15/2008 10:19:06 AM, Serialize complete at 10/15/2008 10:19:06 AM Content-class: urn:content-classes:message X-Scanned-By: MailControl A-08-50-15 (www.mailcontrol.com) on 10.66.1.149 Cc: mext@ietf.org Subject: Re: [MEXT] New RFC3775bis issue "BU de-registration race condition"? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, > No I do not want any change for the way sequence number is handled; > however, in this specific case, before the mobile node sends a > de-registration BU, the mobile node knows for sure that there is an > outstanding BU with a different CoA. IMO, the mobile node SHOULD wait > until it receives a BA or expires all retransmissions before sending a > de-registration. If that happens, this race condition is nothing but a > theoretical one. I see what you mean, but I'm not sure if this actually works, because in this specific scenario the MN has moved from the foreign link to the home link after sending the BU and before receiving the BA. The BA is sent to the source address of the BU (i.e., to the foreign link) and hence cannot be received by the MN (unless the MN is still attached to the foreign link while being attached to the home link, which cannot be assumed to be generally true). So the MN would wait forever for the BA. ;) Furthermore, this behaviour is not specified in RFC3775. Even if it would work, I guess it would need to be described in RFC3775bis. BR, Kilian > > > > > > > Both BU are sent by the mobile node and the mobile node, > before it > > > sent the de-registration BU, it is for sure aware that > there is an > > > outstanding BU that has not been acknowledged yet. > > > > Even though the MN knows that the previous BU has not been > > acknowledged yet, the MN does not know whether the BU has > > overtaken the BU de-reg or not, i.e., whether wrong > > forwarding state was actually established in HA or not. For > > instance, it is also possible that just the BAck was delayed/lost. > > [Ahmad] > The mobile node does not need to know any of that at all. All what the > mobile node needs to know is to make sure that the outstanding BU is > handled properly according to RFC3775 before sending a new BU with a > different CoA, which happened in this case to be a de-registration. > > > > > > > So I am wondering why we need to consider this case? > > > > see above for reasoning. > > > > BR, > > > > Kilian > > > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: mext-bounces@ietf.org > > [mailto:mext-bounces@ietf.org] On Behalf > > > > Of Kilian Weniger > > > > Sent: Tuesday, October 14, 2008 3:59 AM > > > > To: mext@ietf.org > > > > Subject: [MEXT] New RFC3775bis issue "BU de-registration race > > > > condition"? > > > > > > > > Hi all, > > > > > > > > I think there is a possible race condition issue in > > RFC3775, which > > > > should be considered for RFC3775bis. > > > > > > > > The scenario is as follows: A MN returns home and sends a BU > > > > de-registration. Once the HA receives the de-registration, it > > > > deletes the BCE for the MN according to RFC3775. Now > assume that > > > > just before returning home, the MN has sent a BU (either > > refresh BU > > > > or BU with new CoA due to handover) and that the BU is > > delayed and > > > > is received by the HA after the BU > > > de-registration. > > > > > > > > Since the HA has just deleted the MN's BCE due to the > received BU > > > > de-registration, the HA would accept the delayed BU > > without SN check > > > > and create a new BCE with a CoA pertaining to the > > previous location > > > > of the MN. This results in wrong forwarding state in the HA and > > > > hence packet loss for the MN till the MN sends a new BU (next > > > > handover of the MN or the lifetime of the BCE expires). > > > > > > > > A simple mitigation for this problem could be that the HA > > keeps some > > > > BCE information (at least HoA and SN) for some time after > > receiving > > > > a BU de-registration. This would enable the HA to > > identify a delayed > > > > BU as a delayed one based on the SN. > > > > > > > > Comments? > > > > > > > > BR, > > > > > > > > Kilian > > > > > > > > -------------------------------------------- > > > > Dr. Kilian Weniger > > > > Panasonic R&D Center Germany > > > > Monzastr. 4c, 63225 Langen, Germany > > > > phone: +49 (0)6103 766 137 > > > > fax: +49 (0)6103 766 166 > > > > e-mail: kilian.weniger@eu.panasonic.com > > > > -------------------------------------------- > > > > > > > > > > > > Panasonic R&D Center Germany GmbH > > > > 63225 Langen, Hessen, Germany > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: > > Thomas Micke > > > > > > > > > > > > _______________________________________________ > > > > MEXT mailing list > > > > MEXT@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 > > Managing Director: Thomas Micke > > > > > > > > Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Oct 15 05:41: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 1F6D93A6C46; Wed, 15 Oct 2008 05:41:04 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A713A69C3 for ; Wed, 15 Oct 2008 05:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jL8vKgpGBpYn for ; Wed, 15 Oct 2008 05:41:02 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id BE04E3A689E for ; Wed, 15 Oct 2008 05:41:00 -0700 (PDT) Received: from [218.185.66.196] (helo=[172.16.8.68]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1Kpyfi-0002SW-35; Wed, 15 Oct 2008 16:11:46 +1100 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 15 Oct 2008 16:11:38 +1100 From: Hesham Soliman To: Kilian Weniger , Conny Larsson Message-ID: Thread-Topic: [MEXT] New RFC3775bis issue "BU de-registration race condition"? Thread-Index: Ackt5kkBcdIOaHm6TOazJBiKqDOWxwABvfUwACXP3vc= In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACBCF7BF0@lan-ex-02.panasonic.de> Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] New RFC3775bis issue "BU de-registration race condition"? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > There is some related text in RFC3776: > > "When the mobile node returns home and de-registers with the Home > Agent, the tunnel between the home agent and the mobile node's > care-of address is torn down. The security policy entries, which > were used for protecting tunneled traffic between the mobile node > and the home agent MUST be made inactive (for instance, by > removing them and installing them back later through an API). The > corresponding security associations could be kept as they are or > deleted depending on how they were created. If the security > associations were created dynamically using IKE, they are > automatically deleted when they expire. If the security > associations were created through manual configuration, they MUST > be retained and used later when the mobile node moves away from > home again. The security associations protecting Binding Updates > and Acknowledgements, and prefix discovery SHOULD NOT be deleted > as they do not depend on care-of addresses and can be used again. > > According to this the SAs protecting data traffic are torn down, but the > SAs protecting MIP6 signaling traffic should not be deleted when MN is > returning home. => Right, so according to that and my previous email, the race condition can't happen because the BU sent from the old foreign network will have an old seq no. Hesham > > BR, > > Kilian > > >> -----Original Message----- >> From: Conny Larsson [mailto:conny.larsson@ericsson.com] >> Sent: Dienstag, 14. Oktober 2008 12:18 >> To: Kilian Weniger >> Cc: mext@ietf.org >> Subject: Re: [MEXT] New RFC3775bis issue "BU de-registration >> race condition"? >> >> Hi Kilian, >> >> I had a quick look in RFC3775 and I agree that it's not clear >> and most >> likely some clarifications would be good. However, I thought >> about the >> SA established between the MN and the HA. When the BCE is >> deleted does >> the SA go away as well? In case of static SAs I guess they >> remain but in >> case of dynamic SA establishment they could have been deleted and in >> that case the delayed BU would not be accepted and an ICMP >> message would >> be sent back to the MN. I need to look a bit more into RFC3775 to >> understand it better ... >> >> Regards >> Conny >> >> Kilian Weniger wrote: >>> Hi all, >>> >>> I think there is a possible race condition issue in RFC3775, which >>> should be considered for RFC3775bis. >>> >>> The scenario is as follows: A MN returns home and sends a BU >>> de-registration. Once the HA receives the de-registration, >> it deletes >>> the BCE for the MN according to RFC3775. Now assume that just before >>> returning home, the MN has sent a BU (either refresh BU or >> BU with new >>> CoA due to handover) and that the BU is delayed and is >> received by the >>> HA after the BU de-registration. >>> >>> Since the HA has just deleted the MN's BCE due to the received BU >>> de-registration, the HA would accept the delayed BU without >> SN check and >>> create a new BCE with a CoA pertaining to the previous >> location of the >>> MN. This results in wrong forwarding state in the HA and >> hence packet >>> loss for the MN till the MN sends a new BU (next handover >> of the MN or >>> the lifetime of the BCE expires). >>> >>> A simple mitigation for this problem could be that the HA >> keeps some BCE >>> information (at least HoA and SN) for some time after receiving a BU >>> de-registration. This would enable the HA to identify a >> delayed BU as a >>> delayed one based on the SN. >>> >>> Comments? >>> >>> BR, >>> >>> Kilian >>> >>> -------------------------------------------- >>> Dr. Kilian Weniger >>> Panasonic R&D Center Germany >>> Monzastr. 4c, 63225 Langen, Germany >>> phone: +49 (0)6103 766 137 >>> fax: +49 (0)6103 766 166 >>> e-mail: kilian.weniger@eu.panasonic.com >>> -------------------------------------------- >>> >>> >>> Panasonic R&D Center Germany GmbH >>> 63225 Langen, Hessen, Germany >>> Reg: AG Offenbach (Hessen) HRB 33974 >>> Managing Director: Thomas Micke >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> >> >> > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Oct 15 08:58: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 A91CD28C25D; Wed, 15 Oct 2008 08:58:49 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D996428C24E; Wed, 15 Oct 2008 08:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FM6YzqUgREo; Wed, 15 Oct 2008 08:58:41 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by core3.amsl.com (Postfix) with ESMTP id 535803A68C0; Wed, 15 Oct 2008 08:58:41 -0700 (PDT) Received: from IBM52A5038A94F (dsl88-247-34287.ttnet.net.tr [88.247.133.239]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1Kq8ly09o4-0003qy; Wed, 15 Oct 2008 11:59:00 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" , "'Ahmad Muhanna'" , "'Premec, Domagoj'" Date: Wed, 15 Oct 2008 18:58:46 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: Thread-index: Ackq1/c5JaDLzztOS0C4tWqOAwjHtAAACPwgAAA83QAAEVIqoADvlOWw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Message-Id: <0MKpCa-1Kq8ly09o4-0003qy@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+Oyfq0q6FW7dKQ6XQx/lpIfRbN7iWEq5hspRr SyA6iyE3uw4evUiSKzVskdIDefEwIKliAAluFN3CxB7YBcU3FQ GvqvFTttxe8x0OTXkQQzg== Cc: 'Netlmm' , mext@ietf.org Subject: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 Vijay, > In MIPv6, if the binding update is successful, the binding ack is always > sent to the CoA and not to the source address of the BU. If the AltCoA > option is used, then the binding ack would go back to the address that > appeared in the AltCoA option. That's interesting. Is there a technical reason why BA cannot be sent back to the source address of the BU (other than not being specified so in RFC 3775)? Mirroring the src/dst IP addresses between BU/BA appears logical, simple, and useful. Not sure why it is not explicitly allowed in the RFC 3775. > In PMIPv6, I don't believe there is a scenario where you would want to > use the AltCoA option. (if someone has a valid scenario, please let me > know). Sending and receiving PMIP signaling using Alt-CoA provides the ability to separate control plane and data plane. And that's useful for relocating the PMIP6 tunnel while keeping the PMIP6 signaling anchored on a fixed MAG (because moving that requires re-negotiation of security-related parameters). This scenario is being examined by WiMAX Forum and use of Alt-CoA appears to fit (module some wrinkles and clarifications). Alper > Vijay > > > > > If people feels that is the best approach, we can add some > > clarification to the draft. > > > > What do you think? > > > > Regards, > > Ahmad > > > > > >> -----Original Message----- > >> From: Premec, Domagoj [mailto:domagoj.premec@siemens.com] > >> Sent: Friday, October 10, 2008 7:59 AM > >> To: Muhanna, Ahmad (RICH1:2H10) > >> Cc: Netlmm > >> Subject: comment on draft-ietf-netlmm-grekey-option-01 > >> > >> Hi Ahmad, > >> > >> I have a comment on the interactions between the binding revocation > >> mechanism and the alt-CoA usage as specified in RFC 5213. According > >> to > > > >> the RFC 5213, the MAG is allowed to use the alt-CoA to redirect the > >> downlink traffic to an address different from the source address of > >> the PBU. In this case the Binding revocation will get sent to the > >> alt-CoA address, but I think it should actually be sent to the source > >> address of the PBU, as this is where the signalling part of the MAG > >> is > > > >> located. Is this is a valid concern or should we assume that the MAG > >> also accepts signalling messages at the alt-CoA? > >> > >> domagoj > >> > >> > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ > 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 Wed Oct 15 10:18: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 F0C283A6C85; Wed, 15 Oct 2008 10:18:10 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEBDC3A6AF6; Wed, 15 Oct 2008 10:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cs6xVsJHlUxT; Wed, 15 Oct 2008 10:18:09 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id D562E3A6AC1; Wed, 15 Oct 2008 10:18:08 -0700 (PDT) Received: from [127.0.0.1] ([75.26.137.116]) by outbound.mse15.exchange.ms with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 13:19:07 -0400 Message-ID: <48F62602.303@wichorus.com> Date: Wed, 15 Oct 2008 10:18:58 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Alper Yegin References: <0MKpCa-1Kq8ly09o4-0003qy@mrelay.perfora.net> In-Reply-To: <0MKpCa-1Kq8ly09o4-0003qy@mrelay.perfora.net> X-OriginalArrivalTime: 15 Oct 2008 17:19:07.0642 (UTC) FILETIME=[2185EDA0:01C92EEA] Cc: mext@ietf.org, 'Netlmm' Subject: Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 Alper Yegin wrote: > Vijay, > >> In MIPv6, if the binding update is successful, the binding ack is always >> sent to the CoA and not to the source address of the BU. If the AltCoA >> option is used, then the binding ack would go back to the address that >> appeared in the AltCoA option. > > That's interesting. Is there a technical reason why BA cannot be sent back > to the source address of the BU (other than not being specified so in RFC > 3775)? > > Mirroring the src/dst IP addresses between BU/BA appears logical, simple, > and useful. Not sure why it is not explicitly allowed in the RFC 3775. > >> In PMIPv6, I don't believe there is a scenario where you would want to >> use the AltCoA option. (if someone has a valid scenario, please let me >> know). > > Sending and receiving PMIP signaling using Alt-CoA provides the ability to > separate control plane and data plane. And that's useful for relocating the > PMIP6 tunnel while keeping the PMIP6 signaling anchored on a fixed MAG > (because moving that requires re-negotiation of security-related > parameters). > > This scenario is being examined by WiMAX Forum and use of Alt-CoA appears to > fit (module some wrinkles and clarifications). IMO, a clean solution for this would to define a new mobility option called the Data Plane Address option. When the LMA encounters the Data Plane Address option, it uses the address stored in that as the tunnel end point for data packets. The source address of the Proxy Binding Update would still be considered as the Proxy CoA and used for all control plane packets (Proxy Binding Ack, HA/LMA Switch Message and Binding Revocation Indication Message). I think such an extension would be simple enough that we can standardize it quickly. Trying to do the above with the AltCoA option, IMO, is a misuse of the AltCoA option. AltCoA option by definition is supposed to over ride the source address of the BU/PBU and be treated as the CoA/Proxy CoA. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Oct 15 13:30: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 6B8303A6C6F; Wed, 15 Oct 2008 13:30:53 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3A43A6C74; Wed, 15 Oct 2008 13:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9NMsu3Y1qfY; Wed, 15 Oct 2008 13:30:51 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by core3.amsl.com (Postfix) with ESMTP id F169B3A6C7C; Wed, 15 Oct 2008 13:30:50 -0700 (PDT) Received: from IBM52A5038A94F (dsl88-247-34287.ttnet.net.tr [88.247.133.239]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KqD1x13D1-000721; Wed, 15 Oct 2008 16:31:49 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" Date: Wed, 15 Oct 2008 23:31:33 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <48F62602.303@wichorus.com> Thread-index: Acku6iG8BzaTPpOLQY2FwvFYGVtRxgADwiBg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Message-Id: <0MKp8S-1KqD1x13D1-000721@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/+FOzW2KzzuC7kfa7cxr2YJrUC0mKjVtaBxe6 VLMvWF+EmEHu2dLCM3AJDPUbrJryXgUcRZSQUJqxyb5+4Jd6bf aBtcPSZMUO7KBEOQocT6g== Cc: mext@ietf.org, 'Netlmm' Subject: Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 Vijay, > >> In MIPv6, if the binding update is successful, the binding ack is > always > >> sent to the CoA and not to the source address of the BU. If the AltCoA > >> option is used, then the binding ack would go back to the address that > >> appeared in the AltCoA option. > > > > That's interesting. Is there a technical reason why BA cannot be sent > back > > to the source address of the BU (other than not being specified so in > RFC > > 3775)? > > > > Mirroring the src/dst IP addresses between BU/BA appears logical, simple, > > and useful. Not sure why it is not explicitly allowed in the RFC 3775. > > > >> In PMIPv6, I don't believe there is a scenario where you would want to > >> use the AltCoA option. (if someone has a valid scenario, please let me > >> know). > > > > Sending and receiving PMIP signaling using Alt-CoA provides the ability > to > > separate control plane and data plane. And that's useful for relocating > the > > PMIP6 tunnel while keeping the PMIP6 signaling anchored on a fixed MAG > > (because moving that requires re-negotiation of security-related > > parameters). > > > > This scenario is being examined by WiMAX Forum and use of Alt-CoA > appears to > > fit (module some wrinkles and clarifications). > > IMO, a clean solution for this would to define a new mobility option > called the Data Plane Address option. When the LMA encounters the Data > Plane Address option, it uses the address stored in that as the tunnel > end point for data packets. The source address of the Proxy Binding > Update would still be considered as the Proxy CoA and used for all > control plane packets (Proxy Binding Ack, HA/LMA Switch Message and > Binding Revocation Indication Message). > > I think such an extension would be simple enough that we can standardize > it quickly. > > Trying to do the above with the AltCoA option, IMO, is a misuse of the > AltCoA option. AltCoA option by definition is supposed to over ride the > source address of the BU/PBU and be treated as the CoA/Proxy CoA. If I'm understanding you right, you are saying first the source address of the BU is overwritten by Alt-CoA, and then the MIP6 implementation picks up the "CoA" from that source address, and for that MIP6 does not even know the original source address to respond to.... Are you referring to some specific implementation or the standard? I'd like to understand the technical reason for such implementation. Also, see the below text from RFC 3775: Normally, a Binding Update specifies the desired care-of address in the Source Address field of the IPv6 header. However, this is not possible in some cases, such as when the mobile node wishes to indicate a care-of address which it cannot use as a topologically correct source address (Section 6.1.7 and Section 11.7.2) or when the used security mechanism does not protect the IPv6 header (Section 11.7.1). If the reason is topological, how do you expect the MN to receive the BA sent to such topologically-incorrect IP address if HA sends the response back to the Alt-CoA, as opposed to the source address of the BU? Alper _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Oct 15 22:04: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 3ED963A6B39; Wed, 15 Oct 2008 22:04:48 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C7E43A6B26; Wed, 15 Oct 2008 22:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJdxlNWHpZWz; Wed, 15 Oct 2008 22:04:45 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 7E3353A6ABB; Wed, 15 Oct 2008 22:04:45 -0700 (PDT) Received: from 24.130.62.120 ([24.130.62.120]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Oct 2008 05:05:46 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 15 Oct 2008 22:05:45 -0700 From: Vijay Devarapalli To: Alper Yegin Message-ID: Thread-Topic: Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-01) Thread-Index: Acku6iG8BzaTPpOLQY2FwvFYGVtRxgADwiBgABTrhbs= In-Reply-To: <0MKp8S-1KqD1x13D1-000721@mrelay.perfora.net> Mime-version: 1.0 Cc: mext@ietf.org, 'Netlmm' Subject: Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 Alper, On 10/15/08 1:31 PM, "Alper Yegin" wrote: > Vijay, > >>>> In MIPv6, if the binding update is successful, the binding ack is >> always >>>> sent to the CoA and not to the source address of the BU. If the AltCoA >>>> option is used, then the binding ack would go back to the address that >>>> appeared in the AltCoA option. >>> >>> That's interesting. Is there a technical reason why BA cannot be sent >> back >>> to the source address of the BU (other than not being specified so in >> RFC >>> 3775)? >>> >>> Mirroring the src/dst IP addresses between BU/BA appears logical, > simple, >>> and useful. Not sure why it is not explicitly allowed in the RFC 3775. >>> >>>> In PMIPv6, I don't believe there is a scenario where you would want to >>>> use the AltCoA option. (if someone has a valid scenario, please let me >>>> know). >>> >>> Sending and receiving PMIP signaling using Alt-CoA provides the ability >> to >>> separate control plane and data plane. And that's useful for relocating >> the >>> PMIP6 tunnel while keeping the PMIP6 signaling anchored on a fixed MAG >>> (because moving that requires re-negotiation of security-related >>> parameters). >>> >>> This scenario is being examined by WiMAX Forum and use of Alt-CoA >> appears to >>> fit (module some wrinkles and clarifications). >> >> IMO, a clean solution for this would to define a new mobility option >> called the Data Plane Address option. When the LMA encounters the Data >> Plane Address option, it uses the address stored in that as the tunnel >> end point for data packets. The source address of the Proxy Binding >> Update would still be considered as the Proxy CoA and used for all >> control plane packets (Proxy Binding Ack, HA/LMA Switch Message and >> Binding Revocation Indication Message). >> >> I think such an extension would be simple enough that we can standardize >> it quickly. >> >> Trying to do the above with the AltCoA option, IMO, is a misuse of the >> AltCoA option. AltCoA option by definition is supposed to over ride the >> source address of the BU/PBU and be treated as the CoA/Proxy CoA. > > > If I'm understanding you right, you are saying first the source address of > the BU is overwritten by Alt-CoA, and then the MIP6 implementation picks up > the "CoA" from that source address, and for that MIP6 does not even know the > original source address to respond to.... Are you referring to some specific > implementation or the standard? I'd like to understand the technical reason > for such implementation. > > > Also, see the below text from RFC 3775: > > Normally, a Binding Update specifies the desired care-of address in > the Source Address field of the IPv6 header. However, this is not > possible in some cases, such as when the mobile node wishes to > indicate a care-of address which it cannot use as a topologically > correct source address (Section 6.1.7 and Section 11.7.2) or when the > used security mechanism does not protect the IPv6 header (Section > 11.7.1). > > > If the reason is topological, how do you expect the MN to receive the BA > sent to such topologically-incorrect IP address if HA sends the response > back to the Alt-CoA, as opposed to the source address of the BU? If you continue along with this reasoning, then the MN won't receive any data packets that the HA tunnels to the topologically incorrect IP address either. So the HA can't use the topologically incorrect IP address for both the Binding Ack messages and for regular data traffic. So what was the point in the MN sending this address to the HA in the AltCoA option? Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Oct 16 03:02: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 816453A6B73; Thu, 16 Oct 2008 03:02: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 1A2553A6B66; Thu, 16 Oct 2008 03:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnjOkToasJIx; Thu, 16 Oct 2008 03:02:17 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 36CEE3A68C0; Thu, 16 Oct 2008 03:02:17 -0700 (PDT) Received: from IBM52A5038A94F (dsl88-247-34287.ttnet.net.tr [88.247.133.239]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KqPga39DN-0007N9; Thu, 16 Oct 2008 06:02:36 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" Date: Thu, 16 Oct 2008 13:02:19 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acku6iG8BzaTPpOLQY2FwvFYGVtRxgADwiBgABTrhbsAChtNsA== In-Reply-To: Message-Id: <0MKp8S-1KqPga39DN-0007N9@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18sL4sKb4gs6JchLm/8gAcSdWb9y9EuXenkItq D8qdKBOWY0fmbGGxMYf2S81jcLMs3GiTSCaVeXGbAbjG9gtFtj sDQNKMi0zG6GCFkx38cJQ== Cc: mext@ietf.org, 'Netlmm' Subject: Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 > > > Also, see the below text from RFC 3775: > > > > Normally, a Binding Update specifies the desired care-of address in > > the Source Address field of the IPv6 header. However, this is not > > possible in some cases, such as when the mobile node wishes to > > indicate a care-of address which it cannot use as a topologically > > correct source address (Section 6.1.7 and Section 11.7.2) or when the > > used security mechanism does not protect the IPv6 header (Section > > 11.7.1). > > > > > > If the reason is topological, how do you expect the MN to receive the BA > > sent to such topologically-incorrect IP address if HA sends the response > > back to the Alt-CoA, as opposed to the source address of the BU? > > If you continue along with this reasoning, then the MN won't receive any > data packets that the HA tunnels to the topologically incorrect IP address > either. So the HA can't use the topologically incorrect IP address for > both > the Binding Ack messages and for regular data traffic. So what was the > point > in the MN sending this address to the HA in the AltCoA option? The path followed by BU/BA does not have to be same as the path followed by the HA-MN tunnel. That separation is possible with the use of Alt-CoA where Alt-CoA dictates only the tunnel end-point on the MN side (not the destination IP address of the BA). Alper _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Oct 16 11:27: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 AE6353A6917; Thu, 16 Oct 2008 11:27:49 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2978D3A6917; Thu, 16 Oct 2008 11:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWd6WEsyqhUX; Thu, 16 Oct 2008 11:27:47 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 2EA8B3A67D4; Thu, 16 Oct 2008 11:27:47 -0700 (PDT) Received: from [127.0.0.1] ([75.26.137.116]) by outbound.mse15.exchange.ms with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Oct 2008 14:27:52 -0400 Message-ID: <48F7879F.3040201@wichorus.com> Date: Thu, 16 Oct 2008 11:27:43 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Alper Yegin References: <0MKp8S-1KqPga39DN-0007N9@mrelay.perfora.net> In-Reply-To: <0MKp8S-1KqPga39DN-0007N9@mrelay.perfora.net> X-OriginalArrivalTime: 16 Oct 2008 18:27:52.0910 (UTC) FILETIME=[E6C99EE0:01C92FBC] Cc: mext@ietf.org, 'Netlmm' Subject: Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 Alper, Alper Yegin wrote: >>> Also, see the below text from RFC 3775: >>> >>> Normally, a Binding Update specifies the desired care-of address in >>> the Source Address field of the IPv6 header. However, this is not >>> possible in some cases, such as when the mobile node wishes to >>> indicate a care-of address which it cannot use as a topologically >>> correct source address (Section 6.1.7 and Section 11.7.2) or when the >>> used security mechanism does not protect the IPv6 header (Section >>> 11.7.1). >>> >>> >>> If the reason is topological, how do you expect the MN to receive the BA >>> sent to such topologically-incorrect IP address if HA sends the response >>> back to the Alt-CoA, as opposed to the source address of the BU? >> If you continue along with this reasoning, then the MN won't receive any >> data packets that the HA tunnels to the topologically incorrect IP address >> either. So the HA can't use the topologically incorrect IP address for >> both >> the Binding Ack messages and for regular data traffic. So what was the >> point >> in the MN sending this address to the HA in the AltCoA option? > > The path followed by BU/BA does not have to be same as the path followed by > the HA-MN tunnel. That separation is possible with the use of Alt-CoA where > Alt-CoA dictates only the tunnel end-point on the MN side (not the > destination IP address of the BA). But if the MN is binding an address that it can't receive regular traffic at, then something is broken right? The BU/BAck exchange might succeed, but the MN is not able to receive any traffic that is sent for its home address. The Home Agent would be tunneling to the care-of address. Lets step back a bit. The discussion started off with us trying to figure out where the binding revocation should be sent. RFC 3775 does not require the home agent to store the source address on the binding update if the source address does not match the address in the AltCoA option. There is only one address - the care-of address, stored in the binding cache entry. And the care-of address comes from the AltCoA option, if it is present. Data traffic and subsequent signaling messages initiated by the Home Agent would be sent to this care-of address. The source address on the original BU might not even be valid anymore. Then we started talking about the Home Agent/LMA being able to store two separate addresses, one for the control plane and one for the data plane, I think defining a new mobility option to carry the data plane address is the cleanest solution. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Oct 16 14:39: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 BABD83A68B9; Thu, 16 Oct 2008 14:39:43 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22BAC3A68B9; Thu, 16 Oct 2008 14:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syht1OhrOBUg; Thu, 16 Oct 2008 14:39:41 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 32A3A3A67B6; Thu, 16 Oct 2008 14:39:41 -0700 (PDT) Received: from IBM52A5038A94F (dsl88-247-34287.ttnet.net.tr [88.247.133.239]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1KqaaD0DHA-0003d6; Thu, 16 Oct 2008 17:40:42 -0400 From: "Alper Yegin" To: "'Yingzhe Wu'" , "'Vijay Devarapalli'" Date: Fri, 17 Oct 2008 00:40:28 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <006f01c92fc0$5772fdf0$0658f9d0$@wu@zteusa.com> Thread-Index: Acku6iG8BzaTPpOLQY2FwvFYGVtRxgADwiBgABTrhbsAChtNsAAPaysQAAkuxnA= Message-Id: <0MKpCa-1KqaaD0DHA-0003d6@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX192hmCRcx7j1JEj9p1pMzeq2to82Stnmkq86lj uD7Gi9/WjMqPKnWZAK6b3Hu0rENTlwACz14XoWdoHHjZX4Gx6D WTJffkk5RRKbvXqekyWYQ== Cc: 'Netlmm' , mext@ietf.org Subject: Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 Yingzhe said his emails didn't make it to the lists. See below... Alper > -----Original Message----- > From: Yingzhe Wu [mailto:yingzhe.wu@zteusa.com] > Sent: Thursday, October 16, 2008 9:52 PM > To: 'Alper Yegin'; 'Vijay Devarapalli' > Cc: mext@ietf.org; 'Netlmm' > Subject: RE: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment > ondraft-ietf-mext-binding-revocation-01) > > Hello Alper and Vijay, > > Acknowledgement is always returned to the source address of Binding Update. > This is specified in RFC3775 section 9.5.4 "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." > > Otherwise the sender of BU risks not receiving the BA if Alt-CoA!= source > address of BU. > > Alt-CoA can be different from source address of BU, especially in > deregistration. There is also similar usage in FMIP, where MN can > pre-register a NCoA different from PCoA. > > Thanks, > Yingzhe > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > > Alper Yegin > > Sent: Thursday, October 16, 2008 3:02 AM > > To: 'Vijay Devarapalli' > > Cc: mext@ietf.org; 'Netlmm' > > Subject: Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment > > ondraft-ietf-mext-binding-revocation-01) > > > > > > > > > Also, see the below text from RFC 3775: > > > > > > > > Normally, a Binding Update specifies the desired care-of address > > in > > > > the Source Address field of the IPv6 header. However, this is > > not > > > > possible in some cases, such as when the mobile node wishes to > > > > indicate a care-of address which it cannot use as a > > topologically > > > > correct source address (Section 6.1.7 and Section 11.7.2) or > > when the > > > > used security mechanism does not protect the IPv6 header > > (Section > > > > 11.7.1). > > > > > > > > > > > > If the reason is topological, how do you expect the MN to receive > > the BA > > > > sent to such topologically-incorrect IP address if HA sends the > > response > > > > back to the Alt-CoA, as opposed to the source address of the BU? > > > > > > If you continue along with this reasoning, then the MN won't receive > > any > > > data packets that the HA tunnels to the topologically incorrect IP > > address > > > either. So the HA can't use the topologically incorrect IP address > > for > > > both > > > the Binding Ack messages and for regular data traffic. So what was > > the > > > point > > > in the MN sending this address to the HA in the AltCoA option? > > > > The path followed by BU/BA does not have to be same as the path > > followed by > > the HA-MN tunnel. That separation is possible with the use of Alt-CoA > > where > > Alt-CoA dictates only the tunnel end-point on the MN side (not the > > destination IP address of the BA). > > > > 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 Thu Oct 16 15:03: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 B32813A690F; Thu, 16 Oct 2008 15:03:35 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088CA3A6806; Thu, 16 Oct 2008 15:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaLphLd55yN6; Thu, 16 Oct 2008 15:03:33 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by core3.amsl.com (Postfix) with ESMTP id 38A7E3A6810; Thu, 16 Oct 2008 15:03:33 -0700 (PDT) Received: from IBM52A5038A94F (dsl88-247-34287.ttnet.net.tr [88.247.133.239]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KqaxE1eku-0007GL; Thu, 16 Oct 2008 18:04:31 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" Date: Fri, 17 Oct 2008 01:04:15 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <48F7879F.3040201@wichorus.com> Thread-Index: AckvvOdv56oXM/CCQoSoRgDJ5Ys5FAAHSyIw Message-Id: <0MKp8S-1KqaxE1eku-0007GL@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19PK9xCkbrCeKM0D85IN73CghHyQcxwYPXGZeB p88tkC2ER6eRvesi9rXWVlgT18kZBnF1C1LU1WdA2qS13tCcuw fNOPuu0uWgwR4IRpl//pg== Cc: mext@ietf.org, 'Netlmm' Subject: Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 > > The path followed by BU/BA does not have to be same as the path followed > by > > the HA-MN tunnel. That separation is possible with the use of Alt-CoA > where > > Alt-CoA dictates only the tunnel end-point on the MN side (not the > > destination IP address of the BA). > > But if the MN is binding an address that it can't receive regular > traffic at, then something is broken right? I'll give you an example: Consider an MN with two IP addresses: IP1 on if1, IP2 on if2. IP2 is identified as CoA by the MN. But for some reason, MN needs to send the BU out of if1. So, BU's source address is set to IP1, Alt-CoA is set to IP2. BA is sent back to IP1 and received on if1. Tunneled packets are sent to IP2 and received on if2. Everything is fine. Alper The BU/BAck exchange might > succeed, but the MN is not able to receive any traffic that is sent for > its home address. The Home Agent would be tunneling to the care-of address. > > Lets step back a bit. The discussion started off with us trying to > figure out where the binding revocation should be sent. RFC 3775 does > not require the home agent to store the source address on the binding > update if the source address does not match the address in the AltCoA > option. There is only one address - the care-of address, stored in the > binding cache entry. And the care-of address comes from the AltCoA > option, if it is present. Data traffic and subsequent signaling messages > initiated by the Home Agent would be sent to this care-of address. > > The source address on the original BU might not even be valid anymore. > > Then we started talking about the Home Agent/LMA being able to store two > separate addresses, one for the control plane and one for the data > plane, I think defining a new mobility option to carry the data plane > address is the cleanest solution. > > Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Oct 16 15:20: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 B30923A685C; Thu, 16 Oct 2008 15:20:55 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF8E3A6852 for ; Thu, 16 Oct 2008 15:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 1c2JvEWhb-K9 for ; Thu, 16 Oct 2008 15:20:53 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id BDC083A6806 for ; Thu, 16 Oct 2008 15:20:52 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m9GMLjL10436; Thu, 16 Oct 2008 22:21:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Oct 2008 17:21:44 -0500 Message-ID: In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACBCF7CA2@lan-ex-02.panasonic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] New RFC3775bis issue "BU de-registration race condition"? Thread-Index: Ackt2reYg9mLVlzYTUGoi0HZZaFtnwAI50oAAAGevRAACmfngAAaQlZQAFCeGQA= References: <1FEB9B9F2EC38343955D02B2AE86AACBCF7B9E@lan-ex-02.panasonic.de> <1FEB9B9F2EC38343955D02B2AE86AACBCF7C1E@lan-ex-02.panasonic.de> <1FEB9B9F2EC38343955D02B2AE86AACBCF7CA2@lan-ex-02.panasonic.de> From: "Ahmad Muhanna" To: "Kilian Weniger" Cc: mext@ietf.org Subject: Re: [MEXT] New RFC3775bis issue "BU de-registration race condition"? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Kilian, Sorry for the late reply. Please see one comment inline. Regards, Ahmad > Subject: RE: [MEXT] New RFC3775bis issue "BU de-registration > race condition"? > > Hi Ahmad, > > > No I do not want any change for the way sequence number is handled; > > however, in this specific case, before the mobile node sends a > > de-registration BU, the mobile node knows for sure that there is an > > outstanding BU with a different CoA. IMO, the mobile node > SHOULD wait > > until it receives a BA or expires all retransmissions > before sending a > > de-registration. If that happens, this race condition is > nothing but a > > theoretical one. > > I see what you mean, but I'm not sure if this actually works, > because in this specific scenario the MN has moved from the > foreign link to the home link after sending the BU and before > receiving the BA. The BA is sent to the source address of the > BU (i.e., to the foreign link) and hence cannot be received > by the MN (unless the MN is still attached to the foreign > link while being attached to the home link, which cannot be > assumed to be generally true). So the MN would wait forever > for the BA. [Ahmad] Well, it depends, but BA may not come back, however, I still believe that the least the mobile node should do is to wait for retransmission timer to expires before sending the de-registration BU. If that happens, then I believe this race condition becomes somewhat theoretical. > ;) > > Furthermore, this behaviour is not specified in RFC3775. Even > if it would work, I guess it would need to be described in RFC3775bis. [Ahmad] Hmmm... I am not sure if we need to document this in the RFC3775bis, because, IMO, this nothing but how the mobile node should handle its state machine gracefully. > > BR, > > Kilian > > > > > > > > > > > > Both BU are sent by the mobile node and the mobile node, > > before it > > > > sent the de-registration BU, it is for sure aware that > > there is an > > > > outstanding BU that has not been acknowledged yet. > > > > > > Even though the MN knows that the previous BU has not been > > > acknowledged yet, the MN does not know whether the BU has > overtaken > > > the BU de-reg or not, i.e., whether wrong forwarding state was > > > actually established in HA or not. For instance, it is > also possible > > > that just the BAck was delayed/lost. > > > > [Ahmad] > > The mobile node does not need to know any of that at all. > All what the > > mobile node needs to know is to make sure that the > outstanding BU is > > handled properly according to RFC3775 before sending a new > BU with a > > different CoA, which happened in this case to be a de-registration. > > > > > > > > > > > So I am wondering why we need to consider this case? > > > > > > see above for reasoning. > > > > > > BR, > > > > > > Kilian > > > > > > > > > > > Regards, > > > > Ahmad > > > > > > > > > > > > > -----Original Message----- > > > > > From: mext-bounces@ietf.org > > > [mailto:mext-bounces@ietf.org] On Behalf > > > > > Of Kilian Weniger > > > > > Sent: Tuesday, October 14, 2008 3:59 AM > > > > > To: mext@ietf.org > > > > > Subject: [MEXT] New RFC3775bis issue "BU de-registration race > > > > > condition"? > > > > > > > > > > Hi all, > > > > > > > > > > I think there is a possible race condition issue in > > > RFC3775, which > > > > > should be considered for RFC3775bis. > > > > > > > > > > The scenario is as follows: A MN returns home and sends a BU > > > > > de-registration. Once the HA receives the de-registration, it > > > > > deletes the BCE for the MN according to RFC3775. Now > > assume that > > > > > just before returning home, the MN has sent a BU (either > > > refresh BU > > > > > or BU with new CoA due to handover) and that the BU is > > > delayed and > > > > > is received by the HA after the BU > > > > de-registration. > > > > > > > > > > Since the HA has just deleted the MN's BCE due to the > > received BU > > > > > de-registration, the HA would accept the delayed BU > > > without SN check > > > > > and create a new BCE with a CoA pertaining to the > > > previous location > > > > > of the MN. This results in wrong forwarding state in > the HA and > > > > > hence packet loss for the MN till the MN sends a new BU (next > > > > > handover of the MN or the lifetime of the BCE expires). > > > > > > > > > > A simple mitigation for this problem could be that the HA > > > keeps some > > > > > BCE information (at least HoA and SN) for some time after > > > receiving > > > > > a BU de-registration. This would enable the HA to > > > identify a delayed > > > > > BU as a delayed one based on the SN. > > > > > > > > > > Comments? > > > > > > > > > > BR, > > > > > > > > > > Kilian > > > > > > > > > > -------------------------------------------- > > > > > Dr. Kilian Weniger > > > > > Panasonic R&D Center Germany > > > > > Monzastr. 4c, 63225 Langen, Germany > > > > > phone: +49 (0)6103 766 137 > > > > > fax: +49 (0)6103 766 166 > > > > > e-mail: kilian.weniger@eu.panasonic.com > > > > > -------------------------------------------- > > > > > > > > > > > > > > > Panasonic R&D Center Germany GmbH > > > > > 63225 Langen, Hessen, Germany > > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: > > > Thomas Micke > > > > > > > > > > > > > > > _______________________________________________ > > > > > MEXT mailing list > > > > > MEXT@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > _______________________________________________ > > > > MEXT mailing list > > > > MEXT@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > Panasonic R&D Center Germany GmbH > > > 63225 Langen, Hessen, Germany > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: > Thomas Micke > > > > > > > > > > > > > > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Oct 16 15:56: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 B4E713A6852; Thu, 16 Oct 2008 15:56:27 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 734A13A6852; Thu, 16 Oct 2008 15:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kU9WllvbSU-C; Thu, 16 Oct 2008 15:56:25 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 8DEC63A67A2; Thu, 16 Oct 2008 15:56:25 -0700 (PDT) Received: from [127.0.0.1] ([75.26.137.116]) by outbound.mse15.exchange.ms with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Oct 2008 18:57:25 -0400 Message-ID: <48F7C6CC.50208@wichorus.com> Date: Thu, 16 Oct 2008 15:57:16 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Alper Yegin References: <0MKp8S-1KqaxE1eku-0007GL@mrelay.perfora.net> In-Reply-To: <0MKp8S-1KqaxE1eku-0007GL@mrelay.perfora.net> X-OriginalArrivalTime: 16 Oct 2008 22:57:25.0992 (UTC) FILETIME=[8EB21680:01C92FE2] Cc: mext@ietf.org, 'Netlmm' Subject: Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 Alper Yegin wrote: >>> The path followed by BU/BA does not have to be same as the path followed >> by >>> the HA-MN tunnel. That separation is possible with the use of Alt-CoA >> where >>> Alt-CoA dictates only the tunnel end-point on the MN side (not the >>> destination IP address of the BA). >> But if the MN is binding an address that it can't receive regular >> traffic at, then something is broken right? > > I'll give you an example: > > Consider an MN with two IP addresses: IP1 on if1, IP2 on if2. > > IP2 is identified as CoA by the MN. > But for some reason, MN needs to send the BU out of if1. So, BU's source > address is set to IP1, Alt-CoA is set to IP2. > > BA is sent back to IP1 and received on if1. > > Tunneled packets are sent to IP2 and received on if2. > > Everything is fine. This would work. In an earlier email, you had said IP2 is a topologically incorrect address and the MN is not able to receive packets at IP2. Note that only IP2 will be stored in the binding cache entry. IP1 will not be stored. So IP1 would not be available for sending a binding revocation message later on. Even if the HA stores IP1, it might not be valid later on (i.e., the MN might not be reachable on IP1 later). Vijay > > > The BU/BAck exchange might >> succeed, but the MN is not able to receive any traffic that is sent for >> its home address. The Home Agent would be tunneling to the care-of > address. >> Lets step back a bit. The discussion started off with us trying to >> figure out where the binding revocation should be sent. RFC 3775 does >> not require the home agent to store the source address on the binding >> update if the source address does not match the address in the AltCoA >> option. There is only one address - the care-of address, stored in the >> binding cache entry. And the care-of address comes from the AltCoA >> option, if it is present. Data traffic and subsequent signaling messages >> initiated by the Home Agent would be sent to this care-of address. >> >> The source address on the original BU might not even be valid anymore. >> >> Then we started talking about the Home Agent/LMA being able to store two >> separate addresses, one for the control plane and one for the data >> plane, I think defining a new mobility option to carry the data plane >> address is the cleanest solution. >> >> Vijay > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Oct 17 01:24: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 8961A28C0D6; Fri, 17 Oct 2008 01:24:18 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D00543A6A1D; Fri, 17 Oct 2008 01:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEZLpBaCF5jK; Fri, 17 Oct 2008 01:24:16 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by core3.amsl.com (Postfix) with ESMTP id F160F3A6A12; Fri, 17 Oct 2008 01:24:15 -0700 (PDT) Received: from IBM52A5038A94F (dsl88-247-34287.ttnet.net.tr [88.247.133.239]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1Kqkdy0vf9-00041Q; Fri, 17 Oct 2008 04:25:17 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" Date: Fri, 17 Oct 2008 11:25:00 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <48F7C6CC.50208@wichorus.com> Thread-Index: Ackv4o6zgx/aS8sXQWum/1BVaCa8BQATePsg Message-Id: <0MKpCa-1Kqkdy0vf9-00041Q@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18ju+ynMnBA5fsykM5oAYU5NuDyu997H/bKApF Leyaevg2NqdsyZZ7PxASw3+0Ly8wZrcR06D/6kdOSn4vJkDEAh f0fKYv/TuIw9BOORIXKRQ== Cc: mext@ietf.org, 'Netlmm' Subject: Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 > > I'll give you an example: > > > > Consider an MN with two IP addresses: IP1 on if1, IP2 on if2. > > > > IP2 is identified as CoA by the MN. > > But for some reason, MN needs to send the BU out of if1. So, BU's source > > address is set to IP1, Alt-CoA is set to IP2. > > > > BA is sent back to IP1 and received on if1. > > > > Tunneled packets are sent to IP2 and received on if2. > > > > Everything is fine. > > This would work. > > In an earlier email, you had said IP2 is a topologically incorrect > address and the MN is not able to receive packets at IP2. Yes, there exist such scenarios. My above scenario is not one of them because both interfaces are "up at the same time on the same MN". Now remember the other scenario where one MAG is in charge of control signaling (PBU/PBA) and the other in charge of being tunnel end-point. > Note that only IP2 will be stored in the binding cache entry. IP1 will > not be stored. You are saying this because RFC 3775 does not state that source IP address of the last received BU shall be stored. I think this is a bug in the light of the following statement (at the least): 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. If we agree that the BA/PBA should be sent back to the source address of the BA/PBA then the fix is simple. > So IP1 would not be available for sending a binding > revocation message later on. Even if the HA stores IP1, it might not be > valid later on (i.e., the MN might not be reachable on IP1 later). If the MN changes its point of attachment, then it is MN's responsibility to notify the HA if it wants to receive revocation messages. Alper _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Oct 19 21:10:42 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 E4D2A3A69EA; Sun, 19 Oct 2008 21:10:41 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D8DA3A69EA; Sun, 19 Oct 2008 21:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[AWL=1.067, 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 iSH2liFXrgX1; Sun, 19 Oct 2008 21:10:39 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id AB7B03A6833; Sun, 19 Oct 2008 21:10:39 -0700 (PDT) Received: from [127.0.0.1] ([24.130.62.120]) by outbound.mse15.exchange.ms with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Oct 2008 00:11:20 -0400 Message-ID: <48FC04F8.3060502@wichorus.com> Date: Sun, 19 Oct 2008 21:11:36 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Alper Yegin References: <0MKpCa-1Kqkdy0vf9-00041Q@mrelay.perfora.net> In-Reply-To: <0MKpCa-1Kqkdy0vf9-00041Q@mrelay.perfora.net> X-OriginalArrivalTime: 20 Oct 2008 04:11:20.0884 (UTC) FILETIME=[E867C740:01C93269] Cc: mext@ietf.org, Netlmm Subject: Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 Alper Yegin wrote: > > Note that only IP2 will be stored in the binding cache entry. IP1 will > > not be stored. > > You are saying this because RFC 3775 does not state that source IP address > of the last received BU shall be stored. I think this is a bug in the light > of the following statement (at the least): No it is not. See below. > > 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. When you are responding to the BU, the context associated with the BU is still available when you construct the BAck message. The above statement cannot be read as if it indicates that the source address is stored. :) Vijay > If we agree that the BA/PBA should be sent back to the source address of the > BA/PBA then the fix is simple. > > > So IP1 would not be available for sending a binding > > revocation message later on. Even if the HA stores IP1, it might not be > > valid later on (i.e., the MN might not be reachable on IP1 later). > > If the MN changes its point of attachment, then it is MN's responsibility to > notify the HA if it wants to receive revocation messages. > > Alper > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Oct 20 00:20: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 6CB8C3A68FF; Mon, 20 Oct 2008 00:20:06 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D89B3A68FF; Mon, 20 Oct 2008 00:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlbrcLn1kpYs; Mon, 20 Oct 2008 00:20:04 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 2A52D3A6833; Mon, 20 Oct 2008 00:20:04 -0700 (PDT) Received: from IBM52A5038A94F (dsl88-247-34287.ttnet.net.tr [88.247.133.239]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1Krp4a0LlI-0003zz; Mon, 20 Oct 2008 03:21:11 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" Date: Mon, 20 Oct 2008 10:21:01 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Ackyaff4idiWb0JVRzW3qc5Ko2cmXQAFqaqw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <48FC04F8.3060502@wichorus.com> Message-Id: <0MKpCa-1Krp4a0LlI-0003zz@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18Fe+qSIoc6QJrAGVw0EJbGB6bExHpo83z04QD x9ssNAs0k/bx5iFfSeU8sIUue68sw1ZpzHNS7h02HppC9qlhRV DdCiAwHMEClees7rhTdXQ== Cc: mext@ietf.org, 'Netlmm' Subject: Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 Vijay, > > > Note that only IP2 will be stored in the binding cache entry. IP1 > will > > > not be stored. > > > > You are saying this because RFC 3775 does not state that source IP > address > > of the last received BU shall be stored. I think this is a bug in the > light > > of the following statement (at the least): > > No it is not. See below. > > > > > 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. > > When you are responding to the BU, the context associated with the BU is > still available when you construct the BAck message. The above statement > cannot be read as if it indicates that the source address is stored. :) Certainly "stored" at least for the duration of the "BU processing". In other words, it is not blindly tossed away. I acknowledge that it does not mean the address gets stored for an extended period of time. I couldn't trace back where the RFC said what you said "the binding ack is always sent to the CoA and not to the source address of the BU. If the AltCoA option is used, then the binding ack would go back to the address that appeared in the AltCoA option." Wherever it is, it is in direct conflict (a BUG) with the text quoted above. Don't you think so? Alper _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Oct 20 02:37: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 A7AC13A68F3; Mon, 20 Oct 2008 02:37:34 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59BA13A6A7F for ; Mon, 20 Oct 2008 02:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCjjRzOuQTFp for ; Mon, 20 Oct 2008 02:37:32 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 7AD093A68F3 for ; Mon, 20 Oct 2008 02:37:31 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1974566wfd.31 for ; Mon, 20 Oct 2008 02:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=UupNshXsXx7sWvqJWuSQ2f6zxGBdPlzilcqnpavpJ5w=; b=NsGjuZ+lRl+DKua9NMG4MgqwrVxcOYAtPA309f359uFp+gOHe+T0CZrByy02GXC1s7 C8rut/e3pCzt+IAyV2GtWW2RZCSYWa4A+ujaGl4rJ/ZnP6aNFXZCAy3Ul/gzfAKQPWwW zT6B7WUTLawcqSm0QUqxKUDmdzUFap3qA2Cp0= 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=CHsgaGki7OXZgYZjiEQyd0bvcotZ7GNGplDq4IdEOXvXR/iNxDAGs+ZxYbA7ZKwkEi RrNWa/FAQMRSA3WWwVqbfUG4Tfr3ne2EjNVwicr5ihGcSbT+rr41peCnpjg9ep0dkF5I KiG/wN0PAa/7X+sfDUKl8QKZlCqOS5y8wQzDk= Received: by 10.143.6.19 with SMTP id j19mr2936374wfi.330.1224495522888; Mon, 20 Oct 2008 02:38:42 -0700 (PDT) Received: from ?172.17.105.34? (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 24sm13383175wfc.6.2008.10.20.02.38.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Oct 2008 02:38:41 -0700 (PDT) From: Ryuji Wakikawa To: Charles E. Perkins In-Reply-To: <48E66025.8090007@earthlink.net> References: <248F3F2E-4373-4653-B579-B9C6714498A2@gmail.com> <20DF8E07-3D15-471E-81DA-6F8C0486940E@elevatemobile.com> <7B0B4760-CAAA-45C0-91B1-D32BA5034926@gmail.com> <00a001c88a6b$7b53c380$7471510a@psl.local> <47F4A002.5040109@gmail.com> <48E66025.8090007@earthlink.net> Message-Id: <127312AF-FAF7-472E-970D-4CF1D0575F1E@gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 20 Oct 2008 18:38:27 +0900 X-Mailer: Apple Mail (2.929.2) Cc: mext@ietf.org Subject: Re: [MEXT] Issue #10: The usage of "HA lifetime" (RFC3775-update) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-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, Thanks for clarification. I am sorry for my long delay. At Fri, 03 Oct 2008 11:10:45 -0700, Charles E. Perkins wrote: > > > Hello Ryuji, > > I'd like to suggest a resolution to this issue. > > First, it's interesting to note that not all IPv6 addresses come > equipped with lifetimes. For instance, DNS server addresses > are supplied by DHCP without any associated address lifetime. > > I think it is O.K. to have the home agent address lifetime. > treated similarly. If the mobile node is preconfigured with > a home agent address, that information should not be timed > out by way of any default lifetime. > > Similarly, the home agent addresses supplied in the > "Home Agent Address Discovery Reply" message are > not equipped with lifetimes. So, I think that any home > agent that was discovered in this way should be used > in the same way as a preconfigured home agent address, > and not timed out. If RFC3775 clearly mention this, I am OK with it. > On the other hand, home agent addresses discovered > by way of local Router Advertisement messages (containing > the Prefix Information option) do have address lifetimes. > However, in this case the presumption is that the the > Advertisement messages are beaconed periodically, and > that each periodic advertisement updates the time-out > schedule at each receiver on the subnet. Thus, effectively, > the typical scenario is that the home agent address seldom > times out at any device receiving the Advertisement > messages. Of course, if the home agent dies and no > longer sends advertisements, the home agent address > information has to be expunged. But this does not happen > very often, and should not be the model for operation > when the Advertisements are no longer available due to > node movement. > Thus, in all cases, it seems to me that allowing the Home > Agent address information to expire is counter to the > operational intention as indicated in RFC 3775. > > Conceptually, this depends on the mobile node being > able to distinguish between loss of connectivity to the > home network due to mobility, versus loss of neighbor > connectivity to the home agent on the home network. > We can presume that an operational IPv6 network > has Internet connectivity and thus a local router. Then, > this can be done if the mobile node keeps track of > advertisements on its home subnet, for which it does > have a record of the subnet prefix. When there are no > advertisements from the home network, the mobile > node can take action as if it had moved away -- and > keep the home agent address without applying any > timeout. When there are advertisements from the > home network, but no more advertisements from the > mobile node's home agent, it should act as if the home > agent was no longer accessible, and apply the address > lifetime to the home agent's IPv6 address. I support this. > If this is agreeable, I will craft some clarifying text > for rfc3775bis. Or, even better, I would happily accept > text from others containing an acceptable resolution to > this issue. thanks! ryuji > Comments? > > Regards, > Charlie P. > > > > > > Ryuji Wakikawa wrote: > > Hi George > > > > In my previous email, I tried to figure out why DHAAD does not provide > > HA lifetime. > > My guess was that the HA lifetime is originally proposed for HA who manages > > other HAs at the home link by original authors. > > I think my guess was wrong... > > > > Anyway, if MN manages the HA lifetime if the lifetime is available, we > > need some > > operational description when the lifetime is not available. > > RFC3775 clearly said that the HA entry MUST be deleted when its lifetime > > is expired. > > BUT the lifetime is not always available... > > > > So far, we have two options for this. > > > > 1. George > > No cache. MN does not record the HA information in its home agent list. > > 2. Vijay > > Local configuration matter. No modification is required to RFC3775. > > > > I personally agree with Vijay, but I think we need some clarification > > for this in the bis. > > We might need to define the default value for the locally configured HA > > lifetime.. > > > > regards, > > ryuji > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Oct 20 06:48:45 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 B4AE63A6A2D; Mon, 20 Oct 2008 06:48:45 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514C33A69E6; Mon, 20 Oct 2008 06:48:43 -0700 (PDT) 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 1gZM6vW1oHnw; Mon, 20 Oct 2008 06:48:39 -0700 (PDT) Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by core3.amsl.com (Postfix) with ESMTP id 4AFD03A699A; Mon, 20 Oct 2008 06:48:39 -0700 (PDT) Received: from g5t0029.atlanta.hp.com (g5t0029.atlanta.hp.com [16.228.8.141]) by g4t0014.houston.hp.com (Postfix) with ESMTP id 8FA6724590; Mon, 20 Oct 2008 13:49:50 +0000 (UTC) Received: from [192.168.1.101] (squirrel.fc.hp.com [15.11.146.57]) by g5t0029.atlanta.hp.com (Postfix) with ESMTP id B5C581010D; Mon, 20 Oct 2008 13:49:24 +0000 (UTC) Message-ID: <48FC8C59.1040505@hp.com> Date: Mon, 20 Oct 2008 09:49:13 -0400 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: <0MKpCa-1Krp4a0LlI-0003zz@mrelay.perfora.net> In-Reply-To: <0MKpCa-1Krp4a0LlI-0003zz@mrelay.perfora.net> Cc: 'Netlmm' , mext@ietf.org Subject: Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 Alper, Alper Yegin wrote: > Vijay, > >>> > Note that only IP2 will be stored in the binding cache entry. IP1 >> will >>> > not be stored. >>> >>> You are saying this because RFC 3775 does not state that source IP >> address >>> of the last received BU shall be stored. I think this is a bug in the >> light >>> of the following statement (at the least): >> No it is not. See below. >> >>> 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. >> When you are responding to the BU, the context associated with the BU is >> still available when you construct the BAck message. The above statement >> cannot be read as if it indicates that the source address is stored. :) > > Certainly "stored" at least for the duration of the "BU processing". In > other words, it is not blindly tossed away. I acknowledge that it does not > mean the address gets stored for an extended period of time. Yes, the BU is typically tossed away once the data in it is copied out. In the typical case where a HA receives a BU and has to do DAD for the address, it can't save the BU since the buffer needs to be released back to the system. > I couldn't trace back where the RFC said what you said "the binding ack is > always sent to the CoA and not to the source address of the BU. If the > AltCoA option is used, then the binding ack would go back to the address > that appeared in the AltCoA option." Wherever it is, it is in direct > conflict (a BUG) with the text quoted above. Don't you think so? Looking at what I implemented I would have to agree with Alper, I always send the BAck to the source address, so unless the TAHI tests have changed recently (they haven't) that's probably the correct behavior. Alper quoted the text above from Section 9.5.4. The CoA is going to be used for the remote tunnel end-point, so it's specifying where future packets should be sent. -Brian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Oct 20 08:17: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 EBF2D3A6ADB; Mon, 20 Oct 2008 08:17: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 A0FD53A6A6D; Mon, 20 Oct 2008 08:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grxQLPmSsDuw; Mon, 20 Oct 2008 08:17:12 -0700 (PDT) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id 6FC003A69FF; Mon, 20 Oct 2008 08:17:12 -0700 (PDT) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id m9KFIJUP010172; Mon, 20 Oct 2008 17:18:19 +0200 Received: from nets139a.ww300.siemens.net ([192.168.217.3]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m9KFIJd7003588; Mon, 20 Oct 2008 17:18:19 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Oct 2008 17:18:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 20 Oct 2008 17:18:14 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD680472711B@zagh223a.ww300.siemens.net> In-Reply-To: <48FC8C59.1040505@hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] [MEXT] Alt-CoA and PMIP6 (was RE: FW:comment ondraft-ietf-mext-binding-revocation-01) Thread-Index: AckyusRNL1UwBMz1Sv2lPx7YsPQVlAAC6vnQ References: <0MKpCa-1Krp4a0LlI-0003zz@mrelay.perfora.net> <48FC8C59.1040505@hp.com> From: "Premec, Domagoj" To: "Brian Haley" , "Alper Yegin" X-OriginalArrivalTime: 20 Oct 2008 15:18:18.0986 (UTC) FILETIME=[150D8CA0:01C932C7] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::081020171819-0BA21BA0-08D80576/0-0/0-15 X-purgate-size: 3242/0 Cc: Netlmm , mext@ietf.org Subject: Re: [MEXT] [netlmm] Alt-CoA and PMIP6 (was RE: FW:comment ondraft-ietf-mext-binding-revocation-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 Alper, I agree with others here that the source IP of the BU is available during the BU/Back transaction processing and once the transaction is completed, the source IP of the BU is gone. IMO if we want the source IP of the BU to be saved in the BCE, this must be specified in some RFC. domagoj > -----Original Message----- > From: netlmm-bounces@ietf.org > [mailto:netlmm-bounces@ietf.org] On Behalf Of Brian Haley > Sent: 20. listopad 2008 15:49 > To: Alper Yegin > Cc: 'Netlmm'; mext@ietf.org > Subject: Re: [netlmm] [MEXT] Alt-CoA and PMIP6 (was RE: > FW:comment ondraft-ietf-mext-binding-revocation-01) > > Hi Alper, > > Alper Yegin wrote: > > Vijay, > > > >>> > Note that only IP2 will be stored in the binding cache > entry. IP1 > >> will > >>> > not be stored. > >>> > >>> You are saying this because RFC 3775 does not state that source IP > >> address > >>> of the last received BU shall be stored. I think this is a bug in > >>> the > >> light > >>> of the following statement (at the least): > >> No it is not. See below. > >> > >>> 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. > >> When you are responding to the BU, the context associated > with the BU > >> is still available when you construct the BAck message. The above > >> statement cannot be read as if it indicates that the > source address > >> is stored. :) > > > > Certainly "stored" at least for the duration of the "BU > processing". > > In other words, it is not blindly tossed away. I > acknowledge that it > > does not mean the address gets stored for an extended > period of time. > > Yes, the BU is typically tossed away once the data in it is > copied out. > In the typical case where a HA receives a BU and has to do > DAD for the address, it can't save the BU since the buffer > needs to be released back to the system. > > > I couldn't trace back where the RFC said what you said "the binding > > ack is always sent to the CoA and not to the source address > of the BU. > > If the AltCoA option is used, then the binding ack would go back to > > the address that appeared in the AltCoA option." Wherever > it is, it is > > in direct conflict (a BUG) with the text quoted above. > Don't you think so? > > Looking at what I implemented I would have to agree with > Alper, I always send the BAck to the source address, so > unless the TAHI tests have changed recently (they haven't) > that's probably the correct behavior. > Alper quoted the text above from Section 9.5.4. The CoA is > going to be used for the remote tunnel end-point, so it's > specifying where future packets should be sent. > > -Brian > _______________________________________________ > 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 Oct 20 08:52: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 5596F3A6984; Mon, 20 Oct 2008 08:52:47 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454263A6826 for ; Mon, 20 Oct 2008 08:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.826 X-Spam-Level: X-Spam-Status: No, score=-3.826 tagged_above=-999 required=5 tests=[AWL=-0.064, 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 s8w7o9bdeZ69 for ; Mon, 20 Oct 2008 08:52:45 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 4EEA63A68B5 for ; Mon, 20 Oct 2008 08:52:45 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (67.pool85-53-133.dynamic.orange.es [85.53.133.67])by smtp03.uc3m.es (Postfix) with ESMTP id 879496AB20B; Mon, 20 Oct 2008 17:53:55 +0200 (CEST) Message-ID: <48FCA992.3070703@it.uc3m.es> Date: Mon, 20 Oct 2008 17:53:54 +0200 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:0.6004 TC:1F TRN:7 TV:5.5.1026(16230.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 Subject: [MEXT] Agenda requests for the MEXT meeting at IETF73 X-BeenThere: mext@ietf.org X-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 having two sessions at IETF73. Please send us requests for slots if you have any. regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Oct 20 10: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 D70743A6AEE; Mon, 20 Oct 2008 10:27:12 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 236353A6AE5; Mon, 20 Oct 2008 10:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUdQoJeY3C0z; Mon, 20 Oct 2008 10:27:10 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 3547A3A6A65; Mon, 20 Oct 2008 10:27:10 -0700 (PDT) Received: from [127.0.0.1] ([75.26.137.116]) by outbound.mse15.exchange.ms with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Oct 2008 13:27:37 -0400 Message-ID: <48FCBF89.7030502@wichorus.com> Date: Mon, 20 Oct 2008 10:27:37 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Alper Yegin References: <0MKpCa-1Krp4a0LlI-0003zz@mrelay.perfora.net> In-Reply-To: <0MKpCa-1Krp4a0LlI-0003zz@mrelay.perfora.net> X-OriginalArrivalTime: 20 Oct 2008 17:27:38.0428 (UTC) FILETIME=[260A6FC0:01C932D9] Cc: mext@ietf.org, 'Netlmm' Subject: Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 Alper Yegin wrote: > Vijay, > >>> > Note that only IP2 will be stored in the binding cache entry. IP1 >> will >>> > not be stored. >>> >>> You are saying this because RFC 3775 does not state that source IP >> address >>> of the last received BU shall be stored. I think this is a bug in the >> light >>> of the following statement (at the least): >> No it is not. See below. >> >>> 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. >> When you are responding to the BU, the context associated with the BU is >> still available when you construct the BAck message. The above statement >> cannot be read as if it indicates that the source address is stored. :) > > Certainly "stored" at least for the duration of the "BU processing". In > other words, it is not blindly tossed away. I acknowledge that it does not > mean the address gets stored for an extended period of time. Ok > I couldn't trace back where the RFC said what you said "the binding ack is > always sent to the CoA and not to the source address of the BU. If the > AltCoA option is used, then the binding ack would go back to the address > that appeared in the AltCoA option." Wherever it is, it is in direct > conflict (a BUG) with the text quoted above. Don't you think so? I am not sure. This should perhaps be clarified in 3775bis. Practically thinking, the MN should be able to receive the binding ack irrespective of whether it was sent to the source address on the BU or to the address in the AltCoA option. It should be perfectly valid for a HA implementation to send a Binding Ack to the CoA always. The FBU message in the predictive mode of FMIPv6 is the only scenario that I know of when the MN sends a BU with the source address being different from the contents of the AltCoA option. In FMIPv6, the previous access router sends an FBACK to both the oldCoA and the newCoA. BTW, I am planning to submit a draft on the Data Plane Address mobility option, for separation of control and data plane, before the draft submission deadline. Let me know if you are interested in contributing. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Oct 20 10:51: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 EEA4D3A68B0; Mon, 20 Oct 2008 10:51:56 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78B1A3A6887; Mon, 20 Oct 2008 10:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-Tl4sWFFFzS; Mon, 20 Oct 2008 10:51:55 -0700 (PDT) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by core3.amsl.com (Postfix) with ESMTP id 95AA93A6844; Mon, 20 Oct 2008 10:51:55 -0700 (PDT) Received: from g5t0030.atlanta.hp.com (g5t0030.atlanta.hp.com [16.228.8.142]) by g1t0027.austin.hp.com (Postfix) with ESMTP id 0495638012; Mon, 20 Oct 2008 17:52:33 +0000 (UTC) Received: from [192.168.1.101] (squirrel.fc.hp.com [15.11.146.57]) by g5t0030.atlanta.hp.com (Postfix) with ESMTP id 0044E240F3; Mon, 20 Oct 2008 17:52:31 +0000 (UTC) Message-ID: <48FCC55F.7030508@hp.com> Date: Mon, 20 Oct 2008 13:52:31 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: "Premec, Domagoj" References: <0MKpCa-1Krp4a0LlI-0003zz@mrelay.perfora.net> <48FC8C59.1040505@hp.com> <3C31CDD06342EA4A8137716247B1CD680472711B@zagh223a.ww300.siemens.net> In-Reply-To: <3C31CDD06342EA4A8137716247B1CD680472711B@zagh223a.ww300.siemens.net> Cc: Netlmm , mext@ietf.org Subject: Re: [MEXT] [netlmm] Alt-CoA and PMIP6 (was RE: FW:comment ondraft-ietf-mext-binding-revocation-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 Premec, Domagoj wrote: > I agree with others here that the source IP of the BU is available during the BU/Back transaction processing and once the transaction is completed, the source IP of the BU is gone. IMO if we want the source IP of the BU to be saved in the BCE, this must be specified in some RFC. I agree that we don't need the source address once we send the BAck, just the CoA, which is usually the source address. But I don't think we need to specify if the address is saved in the conceptual data structure mentioned in 3775, implementations are free to store additional information in a BCE if they wish, and most do. If some new draft needs the original source address saved, then it should specify it. Maybe that's what you meant and I mis-understood? -Brian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Oct 20 15:27: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 33C093A6B0C; Mon, 20 Oct 2008 15:27:33 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DC343A6AA3; Mon, 20 Oct 2008 15:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=-0.948, BAYES_00=-2.599, DATE_IN_FUTURE_06_12=1.897] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNqBLtrzz7tN; Mon, 20 Oct 2008 15:27:31 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 505A73A6862; Mon, 20 Oct 2008 15:27:31 -0700 (PDT) Received: from LENOVO (dsl88-247-34287.ttnet.net.tr [88.247.133.239]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1Ks3Em2bzT-0003v4; Mon, 20 Oct 2008 18:28:40 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" References: <0MKpCa-1Krp4a0LlI-0003zz@mrelay.perfora.net> <48FCBF89.7030502@wichorus.com> Date: Tue, 21 Oct 2008 01:28:24 -0700 Message-ID: <00a001c93357$01bcc6d0$0302a8c0@LENOVO> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acky2TJNJUzhcB1jQs6t0qTYNJV/KAAfSm9w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <48FCBF89.7030502@wichorus.com> X-Provags-ID: V01U2FsdGVkX19NSPQODGfg4CgvkvreeUii1YQICOMBAQ23bvj 6IABxF337fXAIfeCb9VeOZ9TioSpMPNVRB61/MS3U6MtSk4JAr hZitNe3jppXUAm8Ncj1NA== Cc: mext@ietf.org, 'Netlmm' Subject: Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 Vijay, > > I couldn't trace back where the RFC said what you said "the binding ack > is > > always sent to the CoA and not to the source address of the BU. If the > > AltCoA option is used, then the binding ack would go back to the address > > that appeared in the AltCoA option." Wherever it is, it is in direct > > conflict (a BUG) with the text quoted above. Don't you think so? > > I am not sure. This should perhaps be clarified in 3775bis. Practically > thinking, the MN should be able to receive the binding ack irrespective > of whether it was sent to the source address on the BU or to the address > in the AltCoA option. It should be perfectly valid for a HA > implementation to send a Binding Ack to the CoA always. As Brian said that's not the case for TAHI-tested implementations. Besides, according to the following RFC 3775 text, the destination address of BA "MUST be" copied from the source address of BU. The text is clear. >>> 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. > The FBU message in the predictive mode of FMIPv6 is the only scenario > that I know of when the MN sends a BU with the source address being > different from the contents of the AltCoA option. In FMIPv6, the > previous access router sends an FBACK to both the oldCoA and the newCoA. > > BTW, I am planning to submit a draft on the Data Plane Address mobility > option, for separation of control and data plane, before the draft > submission deadline. Let me know if you are interested in contributing. I still think use of Alt-CoA already accomplishes that and no additional spec is needed. Thank you nevertheless. Alper _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Oct 20 15:42: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 2E5083A6A8D; Mon, 20 Oct 2008 15:42:50 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99C193A6A8D; Mon, 20 Oct 2008 15:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=-1.508, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10qhAmsj9LRm; Mon, 20 Oct 2008 15:42:48 -0700 (PDT) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id 75C073A6862; Mon, 20 Oct 2008 15:42:48 -0700 (PDT) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id m9KMhx6K015164; Tue, 21 Oct 2008 00:43:59 +0200 Received: from nets138a.ww300.siemens.net ([192.168.217.3]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m9KMhsGi027212; Tue, 21 Oct 2008 00:43:54 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 00:43:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 00:43:51 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD680475B818@zagh223a.ww300.siemens.net> In-Reply-To: <48FCC55F.7030508@hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] [MEXT] Alt-CoA and PMIP6 (was RE: FW:comment ondraft-ietf-mext-binding-revocation-01) Thread-Index: Acky3KL0pDEatPXuS/6OK1UfldVzEAAJ9uEQ References: <0MKpCa-1Krp4a0LlI-0003zz@mrelay.perfora.net> <48FC8C59.1040505@hp.com> <3C31CDD06342EA4A8137716247B1CD680472711B@zagh223a.ww300.siemens.net> <48FCC55F.7030508@hp.com> From: "Premec, Domagoj" To: "Brian Haley" X-OriginalArrivalTime: 20 Oct 2008 22:43:53.0916 (UTC) FILETIME=[54501FC0:01C93305] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::081021004359-4E2B3BA0-6DD7474A/0-0/0-15 X-purgate-size: 1611/999999 Cc: Netlmm , mext@ietf.org Subject: Re: [MEXT] [netlmm] Alt-CoA and PMIP6 (was RE: FW:comment ondraft-ietf-mext-binding-revocation-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 Brian, > If some new draft needs the > original source address saved, then it should specify it. > Maybe that's what you meant and I mis-understood? Yes, that was my point. The original question in this thread was "where is the Binding revocation sent to if the PBU contained alt-CoA", and one option would be to specify in the Binding revocation draft that the alt-CoA must be saved in the BCE. domagoj > -----Original Message----- > From: Brian Haley [mailto:brian.haley@hp.com] > Sent: 20. listopad 2008 19:53 > To: Premec, Domagoj > Cc: Alper Yegin; Netlmm; mext@ietf.org > Subject: Re: [netlmm] [MEXT] Alt-CoA and PMIP6 (was RE: > FW:comment ondraft-ietf-mext-binding-revocation-01) > > Premec, Domagoj wrote: > > I agree with others here that the source IP of the BU is > available during the BU/Back transaction processing and once > the transaction is completed, the source IP of the BU is > gone. IMO if we want the source IP of the BU to be saved in > the BCE, this must be specified in some RFC. > > I agree that we don't need the source address once we send > the BAck, just the CoA, which is usually the source address. > But I don't think we need to specify if the address is saved > in the conceptual data structure mentioned in 3775, > implementations are free to store additional information in a > BCE if they wish, and most do. If some new draft needs the > original source address saved, then it should specify it. > Maybe that's what you meant and I mis-understood? > > -Brian > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Oct 20 15:51: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 7D6643A6B21; Mon, 20 Oct 2008 15:51:12 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 948FB3A6B21; Mon, 20 Oct 2008 15:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.53 X-Spam-Level: X-Spam-Status: No, score=-4.53 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 B1cp4CbjJLxk; Mon, 20 Oct 2008 15:51:10 -0700 (PDT) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id 408A33A6B20; Mon, 20 Oct 2008 15:51:10 -0700 (PDT) Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs1.siemens.at with ESMTP id m9KMqKL6011055; Tue, 21 Oct 2008 00:52:20 +0200 Received: from nets138a.ww300.siemens.net ([192.168.217.3]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m9KMqK4s015230; Tue, 21 Oct 2008 00:52:20 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 00:52:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 00:52:18 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD680475B81B@zagh223a.ww300.siemens.net> In-Reply-To: <00a001c93357$01bcc6d0$0302a8c0@LENOVO> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-01) Thread-Index: Acky2TJNJUzhcB1jQs6t0qTYNJV/KAAfSm9wABQoITA= References: <0MKpCa-1Krp4a0LlI-0003zz@mrelay.perfora.net> <48FCBF89.7030502@wichorus.com> <00a001c93357$01bcc6d0$0302a8c0@LENOVO> From: "Premec, Domagoj" To: "Alper Yegin" , "Vijay Devarapalli" X-OriginalArrivalTime: 20 Oct 2008 22:52:19.0979 (UTC) FILETIME=[81F335B0:01C93306] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::081021005220-0BA2EBA0-6AF1855F/0-0/0-15 X-purgate-size: 3126/0 Cc: mext@ietf.org, Netlmm Subject: Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 > > BTW, I am planning to submit a draft on the Data Plane Address > > mobility option, for separation of control and data plane, > before the > > draft submission deadline. Let me know if you are > interested in contributing. > > I still think use of Alt-CoA already accomplishes that and no > additional spec is needed. Thank you nevertheless. The alt-CoA works only in one direction, MAG->LMA. If the LMA has several blades and would like to load balance between them, we need to specify how this is done in the other direction, too. domagoj > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: 21. listopad 2008 10:28 > To: 'Vijay Devarapalli' > Cc: 'Ahmad Muhanna'; Premec, Domagoj; 'Netlmm'; mext@ietf.org > Subject: RE: Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment > ondraft-ietf-mext-binding-revocation-01) > > Vijay, > > > > I couldn't trace back where the RFC said what you said > "the binding > > > ack > > is > > > always sent to the CoA and not to the source address of > the BU. If > > > the AltCoA option is used, then the binding ack would go > back to the > > > address that appeared in the AltCoA option." Wherever it > is, it is > > > in direct conflict (a BUG) with the text quoted above. > Don't you think so? > > > > I am not sure. This should perhaps be clarified in 3775bis. > > Practically thinking, the MN should be able to receive the > binding ack > > irrespective of whether it was sent to the source address > on the BU or > > to the address in the AltCoA option. It should be perfectly > valid for > > a HA implementation to send a Binding Ack to the CoA always. > > As Brian said that's not the case for TAHI-tested implementations. > Besides, according to the following RFC 3775 text, the > destination address of BA "MUST be" copied from the source > address of BU. The text is clear. > > >>> 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. > > > > The FBU message in the predictive mode of FMIPv6 is the > only scenario > > that I know of when the MN sends a BU with the source address being > > different from the contents of the AltCoA option. In FMIPv6, the > > previous access router sends an FBACK to both the oldCoA > and the newCoA. > > > > BTW, I am planning to submit a draft on the Data Plane Address > > mobility option, for separation of control and data plane, > before the > > draft submission deadline. Let me know if you are > interested in contributing. > > I still think use of Alt-CoA already accomplishes that and no > additional spec is needed. Thank you nevertheless. > > Alper > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Oct 20 15:53: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 889F13A6B22; Mon, 20 Oct 2008 15:53:13 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA36A3A6AA0; Mon, 20 Oct 2008 15:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-1.460, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYJrlKm+gPTm; Mon, 20 Oct 2008 15:53:11 -0700 (PDT) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id BA0B33A6781; Mon, 20 Oct 2008 15:53:10 -0700 (PDT) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id m9KMsNIC016931; Tue, 21 Oct 2008 00:54:23 +0200 Received: from nets139a.ww300.siemens.net ([192.168.217.3]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m9KMsIMV028587; Tue, 21 Oct 2008 00:54:18 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 00:54:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 00:54:16 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD680475B81C@zagh223a.ww300.siemens.net> In-Reply-To: <3C31CDD06342EA4A8137716247B1CD680475B818@zagh223a.ww300.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [netlmm] Alt-CoA and PMIP6 (was RE:FW:comment ondraft-ietf-mext-binding-revocation-01) Thread-Index: Acky3KL0pDEatPXuS/6OK1UfldVzEAAJ9uEQAACGZfA= References: <0MKpCa-1Krp4a0LlI-0003zz@mrelay.perfora.net><48FC8C59.1040505@hp.com><3C31CDD06342EA4A8137716247B1CD680472711B@zagh223a.ww300.siemens.net><48FCC55F.7030508@hp.com> <3C31CDD06342EA4A8137716247B1CD680475B818@zagh223a.ww300.siemens.net> From: "Premec, Domagoj" To: "Premec, Domagoj" , "Brian Haley" X-OriginalArrivalTime: 20 Oct 2008 22:54:17.0956 (UTC) FILETIME=[C8451240:01C93306] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::081021005423-4E2B3BA0-4F0F0DC3/0-0/0-15 X-purgate-size: 2368/999999 Cc: Netlmm , mext@ietf.org Subject: Re: [MEXT] [netlmm] Alt-CoA and PMIP6 (was RE:FW:comment ondraft-ietf-mext-binding-revocation-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 there was a typo in my previous mail: [..] that the alt-CoA must be saved in the BCE should have been [..] that the source IP of the BU must be saved in the BCE. domagoj > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Premec, Domagoj > Sent: 21. listopad 2008 00:44 > To: Brian Haley > Cc: Netlmm; mext@ietf.org > Subject: Re: [MEXT] [netlmm] Alt-CoA and PMIP6 (was > RE:FW:comment ondraft-ietf-mext-binding-revocation-01) > > Brian, > > > If some new draft needs the > > original source address saved, then it should specify it. > > Maybe that's what you meant and I mis-understood? > > Yes, that was my point. The original question in this thread > was "where is the Binding revocation sent to if the PBU > contained alt-CoA", and one option would be to specify in the > Binding revocation draft that the alt-CoA must be saved in the BCE. > > domagoj > > > -----Original Message----- > > From: Brian Haley [mailto:brian.haley@hp.com] > > Sent: 20. listopad 2008 19:53 > > To: Premec, Domagoj > > Cc: Alper Yegin; Netlmm; mext@ietf.org > > Subject: Re: [netlmm] [MEXT] Alt-CoA and PMIP6 (was RE: > > FW:comment ondraft-ietf-mext-binding-revocation-01) > > > > Premec, Domagoj wrote: > > > I agree with others here that the source IP of the BU is > > available during the BU/Back transaction processing and once the > > transaction is completed, the source IP of the BU is gone. > IMO if we > > want the source IP of the BU to be saved in the BCE, this must be > > specified in some RFC. > > > > I agree that we don't need the source address once we send > the BAck, > > just the CoA, which is usually the source address. > > But I don't think we need to specify if the address is saved in the > > conceptual data structure mentioned in 3775, > implementations are free > > to store additional information in a BCE if they wish, and > most do. > > If some new draft needs the original source address saved, then it > > should specify it. > > Maybe that's what you meant and I mis-understood? > > > > -Brian > > > _______________________________________________ > MEXT mailing 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 Oct 20 23:16: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 034813A6822; Mon, 20 Oct 2008 23:16:30 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC9F93A6822 for ; Mon, 20 Oct 2008 23:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMhzV8sug5WW for ; Mon, 20 Oct 2008 23:16:27 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id A23773A67E5 for ; Mon, 20 Oct 2008 23:16:27 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id m9L6HSFs004476; Tue, 21 Oct 2008 15:17:28 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id m9L6HSP15858; Tue, 21 Oct 2008 15:17:28 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili02) with ESMTP id m9L6HPZ12425; Tue, 21 Oct 2008 15:17:26 +0900 (JST) Received: from NW-Sephiroth ([10.68.141.58]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 14:17:41 +0800 Message-ID: <48FD7403.10705@sg.panasonic.com> Date: Tue, 21 Oct 2008 14:17:39 +0800 From: Benjamin Lim User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Charles E. Perkins" References: <47F4A002.5040109@gmail.com> <002201c8961b$805cfc00$7471510a@psl.local> <48E662C8.5090103@earthlink.net> In-Reply-To: <48E662C8.5090103@earthlink.net> X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 21 Oct 2008 06:17:41.0183 (UTC) FILETIME=[B9075CF0:01C93344] Cc: mext@ietf.org Subject: Re: [MEXT] The usage of "HA lifetime" (RFC3775-update) -- list processing X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 agree with your points. Below is the propose text to Section 11.4.1 capturing the discussed points (hopefully). Pls feel free to provide comments for better wording. Old Text (Section 11.4.1) ======== ... In this case, the mobile node MAY attempt to discover the address of a suitable home agent on its home link. To do so, the mobile node sends an ICMP Home Agent Address Discovery Request message to the Mobile IPv6 Home-Agents anycast address [16] for its home subnet prefix. As described in Section 10.5, the home agent on its home link that receives this Request message will return an ICMP Home Agent Address Discovery Reply message. This message gives the addresses for the home agents operating on the home link. The mobile node, upon receiving this Home Agent Address Discovery Reply message, MAY then send its home registration Binding Update to any of the unicast IP addresses listed in the Home Agent Addresses field in the Reply. For example, the mobile node MAY attempt its home registration to each of these addresses, in turn, until its registration is accepted. The mobile node sends a Binding Update to an address and waits for the matching Binding Acknowledgement, moving on to the next address if there is no response. The mobile node MUST, however, wait at least InitialBindackTimeoutFirstReg seconds (see Section 13) before sending a Binding Update to the next home agent. In trying each of the returned home agent addresses, the mobile node SHOULD try each of them in the order they appear in the Home Agent Addresses field in the received Home Agent Address Discovery Reply message. New Text ======== .. In this case, the mobile node MAY attempt to discover the address of a suitable home agent on its home link. To do so, the mobile node sends an ICMP Home Agent Address Discovery Request message to the Mobile IPv6 Home-Agents anycast address [16] for its home subnet prefix. As described in Section 10.5, the home agent on its home link that receives this Request message will return an ICMP Home Agent Address Discovery Reply message. This message gives the addresses for the home agents operating on the home link without having any lifetimes associated with the addresses. The mobile node MAY store these home agent addresses in an internal list to perform its home registration procedures (e.g. sending of Binding Update). The mobile node, upon receiving this Home Agent Address Discovery Reply message, MAY then send its home registration Binding Update to any of the unicast IP addresses listed in the Home Agent Addresses field in the Reply. For example, the mobile node MAY attempt its home registration to each of these addresses, in turn, until its registration is accepted. The mobile node sends a Binding Update to an address and waits for the matching Binding Acknowledgement. If the mobile node does not receive a matching Binding Acknowledgement, the mobile node SHOULD remove that Home Agent Address from its internal list before moving on to the next address in its list. The mobile node MUST, however, wait at least InitialBindackTimeoutFirstReg seconds (see Section 13) before sending a Binding Update to the next home agent. In trying each of the returned home agent addresses, the mobile node SHOULD try each of them in the order they appear in the Home Agent Addresses field in the received Home Agent Address Discovery Reply message. When the internal list is depleted, the mobile node can re-attempt the discovery process by sending an ICMP Home Agent Address Discovery Request message to the Mobile IPv6 Home-Agents anycast address for its home subnet prefix. Regards, Benjamin Lim Charles E. Perkins wrote: > > Hello Benjamin, > > Along the way to resolving issue #10, I had some thoughts > about the points you raised. > > If you go along with my suggestion that the home agent addresses > supplied in the Home Agent Address Discovery Reply message > do not have lifetimes associated with the addresses, then we can > make a reasonable suggestion about list maintenance and processing. > > I would suggest that the home agent addresses obtained from the > Reply message should be stored and used as necessary. When the > current home agent becomes inaccessible, the mobile node should > try to send an update to the next home agent on the list. When one > of the home agents on the list seems unresponsive, it should be > deleted from the list of available home agents. When the list is > depleted, the mobile node can re-attempt the discovery process. > > But these are rare events. Perhaps the mobile node would have to > try the discovery process on a timescale measured in months or > years, under most scenarios for administering the home network. > > If you agree with this, then I guess there is again a need for some > clarifying text in section 11.4.1. Contributions are always welcome. > > The previous discussion points are documented at the following URL: > http://trac.tools.ietf.org/wg/mext/trac/ticket/10 > > Regards, > Charlie P. > > > > > > Benjamin Lim wrote: >> >> [Ben] Base on my understanding of 3775 sect 11.4.1, it does not >> specifically >> mention what MN will do to the list of HA address received in DHAAD >> reply. I >> think the confusion comes in because the section state one possible >> way to >> do home registration is to perform a sequential trial of each home agent >> address in the list (e.g. test 1st HA address --> fail --> test 2nd HA >> address --> fail --> until end of list or succeed.) So this implies >> that MN >> should store the list of HA address in order to do the above action. >> Whether >> this list is store temporary (just to find HA) or permenantly (info >> for MN >> in case HA goes down) is not mention. Maybe we should add some clarifying >> text for this matter? >> >> Regards, >> Benjamin Lim >> > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 21 00: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 CBAE33A69DB; Tue, 21 Oct 2008 00:09:13 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0455D3A69DB; Tue, 21 Oct 2008 00:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.571 X-Spam-Level: X-Spam-Status: No, score=-1.571 tagged_above=-999 required=5 tests=[AWL=-0.869, BAYES_00=-2.599, DATE_IN_FUTURE_06_12=1.897] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NHnuD0yGFnw; Tue, 21 Oct 2008 00:09:11 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 2C51C3A63EC; Tue, 21 Oct 2008 00:09:11 -0700 (PDT) Received: from LENOVO (dsl88-247-34287.ttnet.net.tr [88.247.133.239]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KsBNS3sOx-00076N; Tue, 21 Oct 2008 03:10:12 -0400 From: "Alper Yegin" To: "'Premec, Domagoj'" , "'Vijay Devarapalli'" References: <0MKpCa-1Krp4a0LlI-0003zz@mrelay.perfora.net> <48FCBF89.7030502@wichorus.com> <00a001c93357$01bcc6d0$0302a8c0@LENOVO> <3C31CDD06342EA4A8137716247B1CD680475B81B@zagh223a.ww300.siemens.net> Date: Tue, 21 Oct 2008 10:09:56 -0700 Message-ID: <00dd01c9339f$ddbe9080$0302a8c0@LENOVO> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acky2TJNJUzhcB1jQs6t0qTYNJV/KAAfSm9wABQoITAAAdoRgA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <3C31CDD06342EA4A8137716247B1CD680475B81B@zagh223a.ww300.siemens.net> X-Provags-ID: V01U2FsdGVkX18cdOjETI2b6WmraTraVh0+z8qTZEtoLDCHnSz H2yadg9b/S7Tk58uKRGqC5jqIyWJmfg5tfSYlhRU8SafNvKMRX 5skY9+70D7hHTIcpKqxng== Cc: mext@ietf.org, 'Netlmm' Subject: Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-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 > > > BTW, I am planning to submit a draft on the Data Plane Address > > > mobility option, for separation of control and data plane, > > before the > > > draft submission deadline. Let me know if you are > > interested in contributing. > > > > I still think use of Alt-CoA already accomplishes that and no > > additional spec is needed. Thank you nevertheless. > > The alt-CoA works only in one direction, MAG->LMA. If the LMA has several > blades and would like to load balance between them, we need to specify how > this is done in the other direction, too. If you want to go into such "advanced" scenarios (multi-CoA, load balancing, etc.) you would need additional specification, of course. But for single CoA case, I don't see what you need other than standard Alt-CoA usage. Alper > > domagoj > > > > -----Original Message----- > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > Sent: 21. listopad 2008 10:28 > > To: 'Vijay Devarapalli' > > Cc: 'Ahmad Muhanna'; Premec, Domagoj; 'Netlmm'; mext@ietf.org > > Subject: RE: Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment > > ondraft-ietf-mext-binding-revocation-01) > > > > Vijay, > > > > > > I couldn't trace back where the RFC said what you said > > "the binding > > > > ack > > > is > > > > always sent to the CoA and not to the source address of > > the BU. If > > > > the AltCoA option is used, then the binding ack would go > > back to the > > > > address that appeared in the AltCoA option." Wherever it > > is, it is > > > > in direct conflict (a BUG) with the text quoted above. > > Don't you think so? > > > > > > I am not sure. This should perhaps be clarified in 3775bis. > > > Practically thinking, the MN should be able to receive the > > binding ack > > > irrespective of whether it was sent to the source address > > on the BU or > > > to the address in the AltCoA option. It should be perfectly > > valid for > > > a HA implementation to send a Binding Ack to the CoA always. > > > > As Brian said that's not the case for TAHI-tested implementations. > > Besides, according to the following RFC 3775 text, the > > destination address of BA "MUST be" copied from the source > > address of BU. The text is clear. > > > > >>> 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. > > > > > > > The FBU message in the predictive mode of FMIPv6 is the > > only scenario > > > that I know of when the MN sends a BU with the source address being > > > different from the contents of the AltCoA option. In FMIPv6, the > > > previous access router sends an FBACK to both the oldCoA > > and the newCoA. > > > > > > BTW, I am planning to submit a draft on the Data Plane Address > > > mobility option, for separation of control and data plane, > > before the > > > draft submission deadline. Let me know if you are > > interested in contributing. > > > > I still think use of Alt-CoA already accomplishes that and no > > additional spec is needed. Thank you nevertheless. > > > > Alper > > > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 21 08:47: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 3D1A03A6B75; Tue, 21 Oct 2008 08:47:04 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D01E3A6B74 for ; Tue, 21 Oct 2008 08:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.422 X-Spam-Level: X-Spam-Status: No, score=-6.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 fFPvaIc97Ykz for ; Tue, 21 Oct 2008 08:47:02 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 5EE753A6B6C for ; Tue, 21 Oct 2008 08:47:02 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m9LFnFKr010207 for ; Tue, 21 Oct 2008 10:49:15 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 10:47:58 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 10:47:58 -0500 Message-ID: <48FDF91F.7070800@ericsson.com> Date: Tue, 21 Oct 2008 11:45:35 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: mext@ietf.org X-OriginalArrivalTime: 21 Oct 2008 15:47:58.0095 (UTC) FILETIME=[63E5C9F0:01C93394] Subject: [MEXT] Revoking all bindings of an MN X-BeenThere: mext@ietf.org X-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, Section 9.2.1 contains the following text about revoking all PMIP bindings for a given MN-ID when no HNP is present " 1. If only the mobile node identifier, MN-ID, option is included, the local mobility anchor MUST revoke all bindings for this mobile node which have a proxy CoA that is used as the source of the IPv6 packet that carried the BRI or in the Alternate Care-of-Address option in the BRI. " I consider this to be a valid use case. But the text in Section 6.1 about the P bit disallows this scenario "o Home Network Prefix option [RFC5213]. This option is mandatory when the (P) bit is set." I request the authors to remove this restriction in section 6.1. Cheers Suresh _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 21 09:10: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 11F0C3A6A87; Tue, 21 Oct 2008 09:10:27 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454763A6A57 for ; Tue, 21 Oct 2008 09:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 5P6rCIDWGDkB for ; Tue, 21 Oct 2008 09:10:25 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 3F7563A6A87 for ; Tue, 21 Oct 2008 09:10:25 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m9LGBWb28141; Tue, 21 Oct 2008 16:11:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 11:11:18 -0500 Message-ID: In-Reply-To: <48FDF91F.7070800@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Revoking all bindings of an MN Thread-Index: AckzlHcf9jS8ke0WTt61u7KjCcCYiAAArcvg References: <48FDF91F.7070800@ericsson.com> From: "Ahmad Muhanna" To: "Suresh Krishnan" , Subject: Re: [MEXT] Revoking all bindings of an MN X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, Probably what you meant is to modify the requirement under section 6.1. What about the following: o Home Network Prefix option [RFC5213]. This option is mandatory when the (P) bit is set and the BRI is used for revoking a single binding cache entry. What do you think? Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Suresh Krishnan > Sent: Tuesday, October 21, 2008 10:46 AM > To: mext@ietf.org > Subject: [MEXT] Revoking all bindings of an MN > > Hi Folks, > Section 9.2.1 contains the following text about revoking > all PMIP bindings for a given MN-ID when no HNP is present > > " > 1. If only the mobile node identifier, MN-ID, option > is included, > the local mobility anchor MUST revoke all bindings for this > mobile node which have a proxy CoA that is used as > the source > of the IPv6 packet that carried the BRI or in the Alternate > Care-of-Address option in the BRI. > " > > I consider this to be a valid use case. But the text in > Section 6.1 about the P bit disallows this scenario > > > "o Home Network Prefix option [RFC5213]. This option is mandatory > when the (P) bit is set." > > I request the authors to remove this restriction in section 6.1. > > Cheers > Suresh > _______________________________________________ > MEXT mailing 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 Oct 21 12:10: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 1A52328C176; Tue, 21 Oct 2008 12:10:06 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC3E828C176 for ; Tue, 21 Oct 2008 12:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.393 X-Spam-Level: X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[AWL=0.207, 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 Ygj7VPPrhK69 for ; Tue, 21 Oct 2008 12:10:01 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 4026D28C115 for ; Tue, 21 Oct 2008 12:10:01 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m9LJCLHF020665; Tue, 21 Oct 2008 14:12:22 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 14:11:05 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 14:11:04 -0500 Message-ID: <48FE28BB.5040608@ericsson.com> Date: Tue, 21 Oct 2008 15:08:43 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Ahmad Muhanna References: <48FDF91F.7070800@ericsson.com> In-Reply-To: X-OriginalArrivalTime: 21 Oct 2008 19:11:04.0704 (UTC) FILETIME=[C3AEC000:01C933B0] Cc: mext@ietf.org Subject: Re: [MEXT] Revoking all bindings of an MN X-BeenThere: mext@ietf.org X-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, How about this text. o Home Network Prefix option [RFC5213]. This option MAY be used when the (P) bit is set. This option MUST be present when the BRI is used to revoke a single PMIP binding cache entry. I do not like having the word "mandatory" when it is not really mandatory. Thanks Suresh Ahmad Muhanna wrote: > Hi Suresh, > > Probably what you meant is to modify the requirement under section 6.1. > > What about the following: > > o Home Network Prefix option [RFC5213]. This option is mandatory > when the (P) bit is set and the BRI is used for revoking a single > binding cache entry. > > What do you think? > > Regards, > Ahmad > > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Suresh Krishnan >> Sent: Tuesday, October 21, 2008 10:46 AM >> To: mext@ietf.org >> Subject: [MEXT] Revoking all bindings of an MN >> >> Hi Folks, >> Section 9.2.1 contains the following text about revoking >> all PMIP bindings for a given MN-ID when no HNP is present >> >> " >> 1. If only the mobile node identifier, MN-ID, option >> is included, >> the local mobility anchor MUST revoke all bindings for this >> mobile node which have a proxy CoA that is used as >> the source >> of the IPv6 packet that carried the BRI or in the Alternate >> Care-of-Address option in the BRI. >> " >> >> I consider this to be a valid use case. But the text in >> Section 6.1 about the P bit disallows this scenario >> >> >> "o Home Network Prefix option [RFC5213]. This option is mandatory >> when the (P) bit is set." >> >> I request the authors to remove this restriction in section 6.1. >> >> Cheers >> Suresh >> _______________________________________________ >> MEXT mailing 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 Oct 21 12:11: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 11FAA28C176; Tue, 21 Oct 2008 12:11:43 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4233A6B8D for ; Tue, 21 Oct 2008 12:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 w1YqL85RwVaI for ; Tue, 21 Oct 2008 12:11:40 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 581E228C133 for ; Tue, 21 Oct 2008 12:11:40 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m9LJCUu08387; Tue, 21 Oct 2008 19:12:30 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 14:12:24 -0500 Message-ID: In-Reply-To: <48FE28BB.5040608@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Revoking all bindings of an MN Thread-Index: AckzsNFLv/4dqHOpQNCMfUGMI4RqyAAABNFw References: <48FDF91F.7070800@ericsson.com> <48FE28BB.5040608@ericsson.com> From: "Ahmad Muhanna" To: "Suresh Krishnan" Cc: mext@ietf.org Subject: Re: [MEXT] Revoking all bindings of an MN X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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. This sounds good to me. Regards, Ahmad > -----Original Message----- > From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] > Sent: Tuesday, October 21, 2008 2:09 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext@ietf.org > Subject: Re: [MEXT] Revoking all bindings of an MN > > Hi Ahmad, > How about this text. > > o Home Network Prefix option [RFC5213]. This option MAY be used > when the (P) bit is set. This option MUST be present when the > BRI is used to revoke a single PMIP binding cache entry. > > I do not like having the word "mandatory" when it is not > really mandatory. > > Thanks > Suresh > > Ahmad Muhanna wrote: > > Hi Suresh, > > > > Probably what you meant is to modify the requirement under > section 6.1. > > > > What about the following: > > > > o Home Network Prefix option [RFC5213]. This option is > mandatory > > when the (P) bit is set and the BRI is used for > revoking a single > > binding cache entry. > > > > What do you think? > > > > Regards, > > Ahmad > > > > > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > On Behalf > >> Of Suresh Krishnan > >> Sent: Tuesday, October 21, 2008 10:46 AM > >> To: mext@ietf.org > >> Subject: [MEXT] Revoking all bindings of an MN > >> > >> Hi Folks, > >> Section 9.2.1 contains the following text about > revoking all PMIP > >> bindings for a given MN-ID when no HNP is present > >> > >> " > >> 1. If only the mobile node identifier, MN-ID, option is > >> included, > >> the local mobility anchor MUST revoke all > bindings for this > >> mobile node which have a proxy CoA that is used as the > >> source > >> of the IPv6 packet that carried the BRI or in > the Alternate > >> Care-of-Address option in the BRI. > >> " > >> > >> I consider this to be a valid use case. But the text in > Section 6.1 > >> about the P bit disallows this scenario > >> > >> > >> "o Home Network Prefix option [RFC5213]. This option is mandatory > >> when the (P) bit is set." > >> > >> I request the authors to remove this restriction in section 6.1. > >> > >> Cheers > >> Suresh > >> _______________________________________________ > >> MEXT mailing 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 Oct 23 09:26: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 71FA83A6ADA; Thu, 23 Oct 2008 09:26:17 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EA713A66B4; Thu, 23 Oct 2008 09:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-kxh0kf9gv2; Thu, 23 Oct 2008 09:26:13 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 28F783A6821; Thu, 23 Oct 2008 09:26:12 -0700 (PDT) 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 1Kt30t-0000Ml-8E; Thu, 23 Oct 2008 18:26:19 +0200 X-Hashcash: 1:20:081023:mext@ietf.org::2QF7DldS3LaqWBYk:00001Xc+ From: arno@natisbad.org (Arnaud Ebalard) To: "Sheila Frankel" References: <20081023111335.93181fsvzkllr3q7@webmail.nist.gov> 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:081023:sheila.frankel@nist.gov::Fe/iiUSwBeIyuotH:000000000000000000000000000000000000002pcD X-Hashcash: 1:20:081023:ipsec@ietf.org::ndUaEzrUX4jQ/2y0:0009VIc Date: Thu, 23 Oct 2008 18:24:23 +0200 In-Reply-To: <20081023111335.93181fsvzkllr3q7@webmail.nist.gov> (Sheila Frankel's message of "Thu, 23 Oct 2008 11:13:35 -0400") Message-ID: <87skqnl1oo.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: IPsec@ietf.org, IETF MEXT WG ML Subject: Re: [MEXT] [IPsec] Roadmap doc X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, [mext added in CC] "Sheila Frankel" writes: > 7. Outgrowths of IPsec/IKE > 7.1. IPComp (Compression) > 7.2. IKEv2 Mobility and Multihoming (MobIKE) > 7.3. Better-than-Nothing Security (Btns) > 7.4. Kerberized Internet Negotiation of Keys (Kink) > 7.5. IPsec Secure Remote Access (IPSRA) > 7.6. IPsec Keying Information Resource Record (IPsecKEY) > 8. Other Protocols that use IPsec/IKE > 8.1. Mobile IP (MIPv4 and MIPv6) IMHO, MIPv6 is user of IPsec/IKE but not a common user: it uses IPsec/IKE for its protection but it also has some very tight interactions with IKE/IPsec/[PF_KEY] and for that reason, specific requirements: - configuration via IKEv2 (various RFC) - bootstrapping and efficient handling of movement in IPsec/IKE context (see draft draft-ebalard-mext-pfkey-enhanced-migrate-00 which is a follow-up of draft-sugimoto-mip6-pfkey-migrate-04) The problem is that this last item sits in the middle of the field with IPsec WG on one side and MIPv6 on the other; each side considering that it should be handled by the other. At the moment, MIPv6 specification documents (3775, 3776, 4877, 5026, ...) have expectations on the behavior in IPsec/IKE environments but IPsec/IKE (and possibly PF_KEY) are missing the interfaces to support those requirements. This is currently making progress outside any working group. In the end, I am wondering where this item stand w.r.t the roadmap document. I know that it is not in the initial set of work items of the WG but this does not prevent clarifying the position of the WG on it in the doc, does it? > 8.2. Open Shortest Path First (OSPF) > 8.3. Host Identity Protocol (HIP) > 8.4. Extensible Authentication Protocol (EAP) Method Update (EMU) 10 > 8.5. Stream Control Transmission Protocol (SCTP) > 8.6. Fibre Channel > 9. Security Considerations > 10. IANA Considerations > 11. References > 11.1. Normative References > 11.2. Informative References > > Sections 1 and 2 will contain introductory material about IPsec and > IKE: their functions, placement in the stack, inter-relationships, > etc. > > The rest of the doc will basically be a list of RFCs, with a brief > description of each. For the cryptographic algorithms, each section > will describe where each type of algorithm is used within IPsec and/or > IKE. For each algorithm, the following information will be included: > whether it applies to IPsec, IKE, or both; requirement level (MUST > etc.); special considerations (e.g. cannot be used with manual > keying); how widely/commonly it is deployed. Section 8 (other > protocols that use IPsec/IKE) will very briefly mention the context in > which each protocol and/or RFC uses IPsec/IKE. > > Questions for the list: > 1) Are there any other topics that should be discussed? the one above, i.e. where should MIPv6 IPsec/IKE roadmap/work be handled ;-) Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Oct 23 10:58: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 4858128C0FC; Thu, 23 Oct 2008 10:58:08 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1BB3A684D for ; Thu, 23 Oct 2008 10:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id et+9qg9qNlcm for ; Thu, 23 Oct 2008 10:58:04 -0700 (PDT) Received: from us.es (mail.us.es [193.147.175.20]) by core3.amsl.com (Postfix) with ESMTP id 55E893A6A99 for ; Thu, 23 Oct 2008 10:58:03 -0700 (PDT) Received: (qmail 27450 invoked from network); 23 Oct 2008 19:59:20 +0200 Received: from unknown (HELO us.es) (192.168.2.12) by us.es with SMTP; 23 Oct 2008 19:59:20 +0200 Received: (qmail 30907 invoked by uid 510); 23 Oct 2008 17:59:18 -0000 Received: from localhost by antivirus2 (envelope-from , uid 502) with qmail-scanner-2.02 (clamdscan: 0.94/8476. Clear:RC:1(127.0.0.1):. Processed in 0.029658 secs); 23 Oct 2008 17:59:18 -0000 Received: from localhost (HELO us.es) (127.0.0.1) by us.es with SMTP; 23 Oct 2008 19:59:18 +0200 Received: (qmail 3343 invoked from network); 23 Oct 2008 19:59:20 +0200 Received: from trajano.us.es (193.147.162.130) by us.es with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Oct 2008 19:59:20 +0200 Received: from [193.147.162.142] (trajano.us.es [193.147.162.130]) by trajano.us.es (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m9NHxBjs013543 for ; Thu, 23 Oct 2008 19:59:11 +0200 Message-ID: <4900BB68.6090806@trajano.us.es> Date: Thu, 23 Oct 2008 19:59:04 +0200 From: "Juan A. Ternero" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: es,en MIME-Version: 1.0 To: mext@ietf.org Subject: [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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org 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." -- Regards, Juan A. Ternero _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From secureupdate@amazon.com Thu Oct 23 19:22:07 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA983A67AB for ; Thu, 23 Oct 2008 19:22:07 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: Dear Amazon\256 Member,\n X-Spam-Flag: NO X-Spam-Score: -90.454 X-Spam-Level: X-Spam-Status: No, score=-90.454 tagged_above=-999 required=5 tests=[AWL=0.624, BAYES_50=0.001, FORGED_MUA_OUTLOOK=3.116, FRT_BELOW2=2.154, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SARE_FORGED_AMAZON=3, SUBJECT_NEEDS_ENCODING=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 XTevxNTVbacv for ; Thu, 23 Oct 2008 19:22:07 -0700 (PDT) Received: from gxdanbrit.co.uk (213-131-124-116.onyx.net [213.131.124.116]) by core3.amsl.com (Postfix) with ESMTP id 091C33A67A2 for ; Thu, 23 Oct 2008 19:22:06 -0700 (PDT) Received: from User ([124.178.229.79]) by gxdanbrit.co.uk with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Oct 2008 03:09:03 +0100 From: "Amazon Inc Security Center" Subject: Dear Amazon® Member, Date: Fri, 24 Oct 2008 13:09:00 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" 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: X-OriginalArrivalTime: 24 Oct 2008 02:09:04.0034 (UTC) FILETIME=[7CF45020:01C9357D] To: undisclosed-recipients:; We are contacting you to inform you that our Account Review Team identified some unusual activity in your account. In accordance with Amazon's User Agreement and to ensure that your account has not been compromised, access to your account was limited. Your account access will remain limited until this issue has been resolved. To secure your account and quickly restore full access, we may require some additional information from you for the following reason: We have been notified that a card associated with your account has been reported as lost or stolen, or that there were additional problems with your card. This process is mandatory, and if not completed within the nearest time your account or credit card may be subject for temporary suspension. To securely confirm your Amazon information please click on the link bellow: http://ns1.eideasnet.com/ehome/-/Amazon/www.amazon.com/ We encourage you to log in and perform the steps necessary to restore your account access as soon as possible. Allowing your account access to remain limited for an extended period of time may result in further limitations on the use of your account and possible account closure. For more information about how to protect your account please visit Amazon Security Center. We apologize for any incovenience this may cause, and we apriciate your assistance in helping us to maintain the integrity of the entire Amazon system. Thank you for using Amazon! The Amazon Team Privacy Notice © 1995-2008, Amazon.com, Inc. or its affiliates. From mext-bounces@ietf.org Fri Oct 24 08:03:42 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 4751C3A6B70; Fri, 24 Oct 2008 08:03:42 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 790DB3A6B5A for ; Fri, 24 Oct 2008 08:03:40 -0700 (PDT) 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 ANQ4SzOfNBVz for ; Fri, 24 Oct 2008 08:03:39 -0700 (PDT) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.181]) by core3.amsl.com (Postfix) with ESMTP id 8C5E728C1D9 for ; Fri, 24 Oct 2008 08:03:38 -0700 (PDT) Received: by ik-out-1112.google.com with SMTP id c30so632549ika.5 for ; Fri, 24 Oct 2008 08:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=cZ9UeeKCggZlb8Hyz3db//Cgqbzb1yp82FHjpvByfR4=; b=vgE+427S9Prt/oNB9XnLoDbKk1Ytw9f+tcvojKH/swX2nSSvuHcH4ffVFACR8ApGU9 WuV+izPzvhyaNzXlv9kVVO+mT7MPZL5AQXQ844zq9h+FB/H7ucJoEckkHbKy2S2uSKYf YQqzxCs3Hnof85qYZeD2wUH7SMsIhd3cubRCM= 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=q6KulhzD8ITHafGFqC7cHpRp65ZUNWMn6aG8im/xnygnZ4IvQ3iLX1FC6IRoBbZGTP On/4X/OJa7lTvNhajoj0OOkwT+KrjKJ3qpDei6MDYpU61qylY17XUXplIsR9aQkW8m2f YKP8leOoUyGVXd5823rDQ4hh3JSHLZTk2o2zM= Received: by 10.210.134.5 with SMTP id h5mr2465798ebd.85.1224860673557; Fri, 24 Oct 2008 08:04:33 -0700 (PDT) Received: by 10.210.109.14 with HTTP; Fri, 24 Oct 2008 08:04:33 -0700 (PDT) Message-ID: <1d38a3350810240804n5cd50234pff959381102503b2@mail.gmail.com> Date: Fri, 24 Oct 2008 23:04:33 +0800 From: "Hui Deng" To: "Yaron Sheffer" In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CCA70@il-ex01.ad.checkpoint.com> MIME-Version: 1.0 References: <20081023111335.93181fsvzkllr3q7@webmail.nist.gov> <87skqnl1oo.fsf@natisbad.org> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CCA70@il-ex01.ad.checkpoint.com> Cc: "IPsec@ietf.org" , Sheila Frankel , IETF MEXT WG ML Subject: Re: [MEXT] [IPsec] Roadmap doc X-BeenThere: mext@ietf.org X-Mailman-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="===============0541397755==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0541397755== Content-Type: multipart/alternative; boundary="----=_Part_9373_6680290.1224860673543" ------=_Part_9373_6680290.1224860673543 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, all We also have wrote this draft http://tools.ietf.org/id/draft-qi-mip6-ikev2-interfacing-02.txt and present in mip6 working group before several time. and won the support from the floor, but no in the top priority list of the current mext WG. Regards, -Hui 2008/10/24 Yaron Sheffer > Hi Sheila, Arnaud, > > First, I am happy with the outline as presented here, including the 24XX > documents. If anything, it may be too ambitious (i.e. lengthy). > > Regarding the interactions of MIP6 with IKE/IPsec: > > - The Roadmap document should cover these areas, just as it covers other > consumers of this technology. But despite its (unfortunate) name, I don't > see the document as a future-looking position statement of the WG, but > rather as documentation of completed work. > > - As for the actual work on MIP6/IPsec dependencies: the ipsecme WG is busy > today with documents that have far wider applicability to the IPsec > community. _If_ there is strong interest in these issues from a specific > community of people, perhaps the way to go about it is with a dedicated > design team. > > Thanks, > Yaron > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Arnaud Ebalard > Sent: Thursday, October 23, 2008 18:24 > To: Sheila Frankel > Cc: IPsec@ietf.org; IETF MEXT WG ML > Subject: Re: [IPsec] Roadmap doc > > Hi, [mext added in CC] > > "Sheila Frankel" writes: > > > 7. Outgrowths of IPsec/IKE > > 7.1. IPComp (Compression) > > 7.2. IKEv2 Mobility and Multihoming (MobIKE) > > 7.3. Better-than-Nothing Security (Btns) > > 7.4. Kerberized Internet Negotiation of Keys (Kink) > > 7.5. IPsec Secure Remote Access (IPSRA) > > 7.6. IPsec Keying Information Resource Record (IPsecKEY) > > 8. Other Protocols that use IPsec/IKE > > 8.1. Mobile IP (MIPv4 and MIPv6) > > IMHO, MIPv6 is user of IPsec/IKE but not a common user: it uses > IPsec/IKE for its protection but it also has some very tight > interactions with IKE/IPsec/[PF_KEY] and for that reason, specific > requirements: > > - configuration via IKEv2 (various RFC) > - bootstrapping and efficient handling of movement in IPsec/IKE context > (see draft draft-ebalard-mext-pfkey-enhanced-migrate-00 which is a > follow-up of draft-sugimoto-mip6-pfkey-migrate-04) > > The problem is that this last item sits in the middle of the field with > IPsec WG on one side and MIPv6 on the other; each side considering that > it should be handled by the other. > > At the moment, MIPv6 specification documents (3775, 3776, 4877, 5026, > ...) have expectations on the behavior in IPsec/IKE environments but > IPsec/IKE (and possibly PF_KEY) are missing the interfaces to support > those requirements. This is currently making progress outside any > working group. > > In the end, I am wondering where this item stand w.r.t the roadmap > document. I know that it is not in the initial set of work items of the > WG but this does not prevent clarifying the position of the WG on it in > the doc, does it? > > > 8.2. Open Shortest Path First (OSPF) > > 8.3. Host Identity Protocol (HIP) > > 8.4. Extensible Authentication Protocol (EAP) Method Update (EMU) 10 > > 8.5. Stream Control Transmission Protocol (SCTP) > > 8.6. Fibre Channel > > 9. Security Considerations > > 10. IANA Considerations > > 11. References > > 11.1. Normative References > > 11.2. Informative References > > > > Sections 1 and 2 will contain introductory material about IPsec and > > IKE: their functions, placement in the stack, inter-relationships, > > etc. > > > > The rest of the doc will basically be a list of RFCs, with a brief > > description of each. For the cryptographic algorithms, each section > > will describe where each type of algorithm is used within IPsec and/or > > IKE. For each algorithm, the following information will be included: > > whether it applies to IPsec, IKE, or both; requirement level (MUST > > etc.); special considerations (e.g. cannot be used with manual > > keying); how widely/commonly it is deployed. Section 8 (other > > protocols that use IPsec/IKE) will very briefly mention the context in > > which each protocol and/or RFC uses IPsec/IKE. > > > > Questions for the list: > > 1) Are there any other topics that should be discussed? > > the one above, i.e. where should MIPv6 IPsec/IKE roadmap/work be > handled ;-) > > Cheers, > > a+ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > ------=_Part_9373_6680290.1224860673543 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello, all
 
and present in mip6 working group before several time.
and won the support from the floor, but no in the top priority list of the current mext WG.
 
Regards,
 
-Hui

2008/10/24 Yaron Sheffer <yaronf@checkpoint.com>
Hi Sheila, Arnaud,

First, I am happy with the outline as presented here, including the 24XX
documents. If anything, it may be too ambitious (i.e. lengthy).

Regarding the interactions of MIP6 with IKE/IPsec:

- The Roadmap document should cover these areas, just as it covers other
consumers of this technology. But despite its (unfortunate) name, I don't
see the document as a future-looking position statement of the WG, but
rather as documentation of completed work.

- As for the actual work on MIP6/IPsec dependencies: the ipsecme WG is busy
today with documents that have far wider applicability to the IPsec
community. _If_ there is strong interest in these issues from a specific
community of people, perhaps the way to go about it is with a dedicated
design team.

Thanks,
       Yaron

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of
Arnaud Ebalard
Sent: Thursday, October 23, 2008 18:24
To: Sheila Frankel
Cc: IPsec@ietf.org; IETF MEXT WG ML
Subject: Re: [IPsec] Roadmap doc

Hi,                                                [mext added in CC]

"Sheila Frankel" <sheila.frankel@nist.gov> writes:

> 7.  Outgrowths of IPsec/IKE
>    7.1.  IPComp (Compression)
>    7.2.  IKEv2 Mobility and Multihoming (MobIKE)
>    7.3.  Better-than-Nothing Security (Btns)
>    7.4.  Kerberized Internet Negotiation of Keys (Kink)
>    7.5.  IPsec Secure Remote Access (IPSRA)
>    7.6.  IPsec Keying Information Resource Record (IPsecKEY)
> 8.  Other Protocols that use IPsec/IKE
>    8.1.  Mobile IP (MIPv4 and MIPv6)

IMHO, MIPv6 is user of IPsec/IKE but not a common user: it uses
IPsec/IKE for its protection but it also has some very tight
interactions with IKE/IPsec/[PF_KEY] and for that reason, specific
requirements:

- configuration via IKEv2 (various RFC)
- bootstrapping and efficient handling of movement in IPsec/IKE context
 (see draft draft-ebalard-mext-pfkey-enhanced-migrate-00 which is a
 follow-up of draft-sugimoto-mip6-pfkey-migrate-04)

The problem is that this last item sits in the middle of the field with
IPsec WG on one side and MIPv6 on the other; each side considering that
it should be handled by the other.

At the moment, MIPv6 specification documents (3775, 3776, 4877, 5026,
...) have expectations on the behavior in IPsec/IKE environments but
IPsec/IKE (and possibly PF_KEY) are missing the interfaces to support
those requirements. This is currently making progress outside any
working group.

In the end, I am wondering where this item stand w.r.t the roadmap
document. I know that it is not in the initial set of work items of the
WG but this does not prevent clarifying the position of the WG on it in
the doc, does it?

>    8.2.  Open Shortest Path First (OSPF)
>    8.3.  Host Identity Protocol (HIP)
>    8.4.  Extensible Authentication Protocol (EAP) Method Update (EMU) 10
>    8.5.  Stream Control Transmission Protocol (SCTP)
>    8.6.  Fibre Channel
> 9.  Security Considerations
> 10.  IANA Considerations
> 11. References
>    11.1. Normative References
>    11.2. Informative References
>
> Sections 1 and 2 will contain introductory material about IPsec and
> IKE: their functions, placement in the stack, inter-relationships,
> etc.
>
> The rest of the doc will basically be a list of RFCs, with a brief
> description of each. For the cryptographic algorithms, each section
> will describe where each type of algorithm is used within IPsec and/or
> IKE. For each algorithm, the following information will be included:
> whether it applies to IPsec, IKE, or both; requirement level (MUST
> etc.); special considerations (e.g. cannot be used with manual
> keying); how widely/commonly it is deployed. Section 8 (other
> protocols that use IPsec/IKE) will very briefly mention the context in
> which each protocol and/or RFC uses IPsec/IKE.
>
> Questions for the list:
> 1) Are there any other topics that should be discussed?

the one above, i.e. where should MIPv6 IPsec/IKE roadmap/work be
handled ;-)

Cheers,

a+

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Scanned by Check Point Total Security Gateway.

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


------=_Part_9373_6680290.1224860673543-- --===============0541397755== 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 --===============0541397755==-- From n21102008@gmail.com Sat Oct 25 02:37:19 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693883A6946; Sat, 25 Oct 2008 02:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.612 X-Spam-Level: ** X-Spam-Status: No, score=2.612 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, 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 tBqm9aCcLaxP; Sat, 25 Oct 2008 02:37:19 -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 2A84F3A6940; Sat, 25 Oct 2008 02:37:18 -0700 (PDT) Received: from f3t ([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 <0K9A003E0G42U3F0@maildcarg4.dc-host.net.ar>; Sat, 25 Oct 2008 06:38:27 -0300 (ART) Date: Sat, 25 Oct 2008 07:38:33 +0200 From: "n21102008@gmail.com" Subject: SOLO POR HOY To: solo por hoy Message-id: <386-220081062553833250@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: 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 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: $3800 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 Mon Oct 27 06:08: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 3059C28C0EC; Mon, 27 Oct 2008 06:08:58 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2A73A6AB4 for ; Mon, 27 Oct 2008 06:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 wITshM00+sWh for ; Mon, 27 Oct 2008 06:08:55 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 35A273A6AAD for ; Mon, 27 Oct 2008 06:08:54 -0700 (PDT) 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 1KuRpw-0002eg-NI; Tue, 28 Oct 2008 00:08:49 +1100 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Tue, 28 Oct 2008 00:08:40 +1100 From: Hesham Soliman To: Jari Arkko , "mext@ietf.org" , Message-ID: Thread-Topic: [MEXT] AD review of mext-nemo-v4traversal - CoA selection Thread-Index: Ack4NSFOLVkYVNVrvkWLDJVQUBhjHw== In-Reply-To: <48AECBCB.6010605@piuha.net> Mime-version: 1.0 Cc: Pasi Eronen Subject: Re: [MEXT] AD review of mext-nemo-v4traversal - CoA selection X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Jari, I'm sorry this took so long. I'll have a new rev next week with your comments handled as discussed on the list. There is one comment that requires text. This comment: > This is the priority, but its also likely to have the same problems as > we have with dual stack hosts getting long timeouts due to trying out > broken IPv6 connectivity. Look at the Stuart Cheshire's technical > plenary presentation, for instance. I would suggest that you have an > explicit specification of the recovery mechanism: trying out both in > parallel, trying one first and then falling back -- I do not have the > details but you have to have a recovery mechanism. I suggest the following text: 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: - Resend the binding update using the exponential back-off algorithm described in [RFC3775]. - 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: 1. IPv6 2. IPv4 (using IP in IP or UDP encapsulation if a NAT is detected) 3. UDP encapsulation when no NAT is detected but IP in IP is not allowed by the local domain. > > Similarly, it would be very useful if the document contained better > instruction about when a mobile node sets the F flag. If there is no NAT > but a firewall, the mobile node may wish to use UDP encapsulation. Would > it be possible to have the mobile node revert back UDP encapsulation if > the direct encapsulation does not appear to be working? > => See the second last paragraph above. I think it's not a good solution but I'll wait for your response. I can't think of a cleaner way of doing this. Comments? Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Oct 27 10:28: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 1C1F33A6B89; Mon, 27 Oct 2008 10:28:21 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A35063A6B89 for ; Mon, 27 Oct 2008 10:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBZne3-+UlqZ for ; Mon, 27 Oct 2008 10:28:18 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 7A6C43A69B9 for ; Mon, 27 Oct 2008 10:28:18 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9RHS53J032485 for ; Mon, 27 Oct 2008 19:28:15 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 19:27:46 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 12:27:30 -0500 Received: from 10.241.58.244 ([10.241.58.244]) by daebe104.NOE.Nokia.com ([10.241.36.13]) with Microsoft Exchange Server HTTP-DAV ; Mon, 27 Oct 2008 17:27:30 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Mon, 27 Oct 2008 12:27:33 -0500 From: Basavaraj Patil To: "mext@ietf.org" Message-ID: Thread-Topic: New Version Notification for draft-patil-mext-mip6issueswithipsec-00 Thread-Index: Ack4WUuybdLDiLagg02WJhfF9JZq0g== In-Reply-To: <20081027165513.C3AEB3A6943@core3.amsl.com> Mime-version: 1.0 X-OriginalArrivalTime: 27 Oct 2008 17:27:30.0240 (UTC) FILETIME=[4A0D4C00:01C93859] X-Nokia-AV: Clean Subject: [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 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 From mext-bounces@ietf.org Mon Oct 27 11:19: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 A33D128C1C7; Mon, 27 Oct 2008 11:19:59 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58BC28C1CA for ; Mon, 27 Oct 2008 11:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYp3iqii08d8 for ; Mon, 27 Oct 2008 11:19:58 -0700 (PDT) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id A53EA28C0E6 for ; Mon, 27 Oct 2008 11:19:57 -0700 (PDT) Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id m9RHdevo024730 for ; Mon, 27 Oct 2008 18:39:40 +0100 Received: from nets138a.ww300.siemens.net ([192.168.217.3]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id m9RHdZ38006835 for ; Mon, 27 Oct 2008 18:39:35 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 18:39:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9385A.F9B0419E" Date: Mon, 27 Oct 2008 18:39:31 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD68047AC9CF@zagh223a.ww300.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-premec-mext-extended-home-link-00.txt Thread-Index: Ack4Vf8ZZ0GJJDNhRGqW5JJrUg0sHQAA8Rcg From: "Premec, Domagoj" To: X-OriginalArrivalTime: 27 Oct 2008 17:39:35.0287 (UTC) FILETIME=[FA36B070:01C9385A] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::081027183940-4E2B9BA0-6B642F6F/0-0/0-15 X-purgate-size: 2855/999999 Subject: [MEXT] FW: I-D Action:draft-premec-mext-extended-home-link-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. ------_=_NextPart_001_01C9385A.F9B0419E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everyone, This is a draft on enabling the IPv4-only or IPv6-only home link for DSMIP6. Any comments are appriciated. domagoj =20 -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext Internet-Drafts@ietf.org Sent: 27. listopad 2008 18:00 To: i-d-announce@ietf.org Subject: I-D Action:draft-premec-mext-extended-home-link-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extended Home Link Support for DSMIPv6 Author(s) : D. Premec Filename : draft-premec-mext-extended-home-link-00.txt Pages : 18 Date : 2008-10-27 Mobile IPv6 Support for Dual Stack Hosts and Routers requires that the mobile node's home link provides native dual stack support. This document relaxes this requirement and specifies how a DSMIP6-enabled mobile node can, with the help of its home agent, maintain connectivity for both of its home addresses while attached to a home link that supports only single IP family.=20 =20 Conventions used in this document=20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-premec-mext-extended-home-link -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_001_01C9385A.F9B0419E Content-Type: application/octet-stream; name="draft-premec-mext-extended-home-link-00.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-premec-mext-extended-home-link-00.txt" Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8MjAwOC0xMC0yNzA5NDg1Mi5J LURAaWV0Zi5vcmc+DQoNCg== ------_=_NextPart_001_01C9385A.F9B0419E Content-Type: text/plain; name="ATT01599.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ATT01599.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01C9385A.F9B0419E Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ------_=_NextPart_001_01C9385A.F9B0419E-- From mext-bounces@ietf.org Mon Oct 27 14:20: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 75D223A6A2C; Mon, 27 Oct 2008 14:20:38 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14F53A6A2C for ; Mon, 27 Oct 2008 14:20:37 -0700 (PDT) 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 BG+9PaDp1srM for ; Mon, 27 Oct 2008 14:20:36 -0700 (PDT) Received: from web38802.mail.mud.yahoo.com (web38802.mail.mud.yahoo.com [209.191.125.93]) by core3.amsl.com (Postfix) with SMTP id 9DD103A6943 for ; Mon, 27 Oct 2008 14:20:36 -0700 (PDT) Received: (qmail 15669 invoked by uid 60001); 27 Oct 2008 21:20:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=NliG4uVbW6Oolb+1ljDkpNIuxxajsP0USB9JMSob/Th9ug9c4BdC1fnmbKmor5g169eQ8DMrjCUmyQV9kKi3r06+TA73+nMnGx/7UzKkHC8uqAdKtrUIVlUkwo19nYhm5b6Ci/XDeM3mpSFomMoAREzp1J732zGvycpPKKx1IKw=; X-YMail-OSG: 5XBtM_gVM1nYxH725ztFpXn3dTIfvous5g.hdJfKyUqA9ViTzJsEeHoz28yDGmw_9xTrkwisKEAniikCBWYxjkzpWuhRGAixRjJKoC.NFfnO2OmF1FijZG0AkbaVowGqWhZWk6N0fEXoj033PEri.rStroarPBj1SRsypptHwYiShPo- Received: from [206.16.17.212] by web38802.mail.mud.yahoo.com via HTTP; Mon, 27 Oct 2008 14:20:35 PDT X-Mailer: YahooMailRC/1155.11 YahooMailWebService/0.7.247.3 Date: Mon, 27 Oct 2008 14:20:35 -0700 (PDT) From: Behcet Sarikaya To: Basavaraj Patil , "mext@ietf.org" MIME-Version: 1.0 Message-ID: <16618.14938.qm@web38802.mail.mud.yahoo.com> 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 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="===============1769323258==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1769323258== Content-Type: multipart/alternative; boundary="0-1772761783-1225142435=:14938" --0-1772761783-1225142435=:14938 Content-Type: text/plain; charset=us-ascii Hi Raj, I read this draft with interest. I remember long and heated debate in 6man list on IPSec being mandatory in IPv6. Overall I kind of disagree with you saying that MIPv6 hasn't been widely deployed just because of IPSec. Probably the status of IPv6 deployment has something to do with it. Regards, Behcet ________________________________ From: Basavaraj Patil To: "mext@ietf.org" Sent: Monday, October 27, 2008 12:27:33 PM Subject: [MEXT] FW: New Version Notification for draft-patil-mext-mip6issueswithipsec-00 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 --0-1772761783-1225142435=:14938 Content-Type: text/html; charset=us-ascii
Hi Raj,
  I read this draft with interest. I remember long and heated debate in 6man list on IPSec being mandatory in IPv6.
  Overall I kind of disagree with you saying that MIPv6 hasn't been widely deployed just because of IPSec. Probably the status of IPv6 deployment has something to do with it.

Regards,

Behcet

From: Basavaraj Patil <basavaraj.patil@nokia.com>
To: "mext@ietf.org" <mext@ietf.org>
Sent: Monday, October 27, 2008 12:27:33 PM
Subject: [MEXT] FW: New Version Notification for draft-patil-mext-mip6issueswithipsec-00


FYI,

------ Forwarded Message
From: ext IETF I-D Submission Tool <idsubmission@ietf.org>
Date: Mon, 27 Oct 2008 09:55:13 -0700 (PDT)
To: Basavaraj Patil <basavaraj.patil@nokia.com>
Cc: Charles Perkins <charliep@wichorus.com>, <Hannes.Tschofenig@gmx.net>
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

--0-1772761783-1225142435=:14938-- --===============1769323258== 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 --===============1769323258==-- From mext-bounces@ietf.org Mon Oct 27 14:42: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 2765828C146; Mon, 27 Oct 2008 14:42:17 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1360828C16E for ; Mon, 27 Oct 2008 14:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[AWL=3.289, 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 5lET8alfHnwc for ; Mon, 27 Oct 2008 14:42:14 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 28AB13A6943 for ; Mon, 27 Oct 2008 14:42:14 -0700 (PDT) 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 1KuZqM-0000gO-H0; Mon, 27 Oct 2008 22:41:47 +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:081027:mext@ietf.org::91teDr/04/Pe57PK:00004uAu X-Hashcash: 1:20:081027:basavaraj.patil@nokia.com::riCZ3KyQHmhCjCHH:0000000000000000000000000000000000005Z+V Date: Mon, 27 Oct 2008 22:40:03 +0100 In-Reply-To: (Basavaraj Patil's message of "Mon, 27 Oct 2008 12:27:33 -0500") Message-ID: <87iqrdvhsc.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, 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. > 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 ;-) > in view of the experience gained from implementation That is fair! > and adoption in other standards bodies. Is that fair? > 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 > 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. > 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. > 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. > 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? > 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? 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. > (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. > 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. > (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? > (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. > 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? > (5) IPsec and IKEv2 is not implemented in every IPv6 or dual stack > host. Not in all, but most stacks. > 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, ... > (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? > (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? > 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 ;-) > 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. > 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. 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. Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Oct 27 14:51: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 1BE7C3A6902; Mon, 27 Oct 2008 14:51:58 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54BBE3A6902 for ; Mon, 27 Oct 2008 14:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[AWL=-2.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GN0cuvyPbW-4 for ; Mon, 27 Oct 2008 14:51:56 -0700 (PDT) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id A969C3A68C6 for ; Mon, 27 Oct 2008 14:51:55 -0700 (PDT) Received: from mgw-mx03.nokia.com (mgw-mx03.nokia.com [192.100.122.230]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9RLQUcF005596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 27 Oct 2008 23:26:31 +0200 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9RLQ4MN002265; Mon, 27 Oct 2008 23:26:18 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 23:26:00 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 16:25:43 -0500 Received: from 10.241.58.244 ([10.241.58.244]) by daebe104.NOE.Nokia.com ([10.241.36.13]) with Microsoft Exchange Server HTTP-DAV ; Mon, 27 Oct 2008 21:25:03 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Mon, 27 Oct 2008 16:25:07 -0500 From: Basavaraj Patil To: Behcet Sarikaya , "mext@ietf.org" Message-ID: Thread-Topic: [MEXT] FW: New Version Notification for draft-patil-mext-mip6issueswithipsec-00 Thread-Index: Ack4enu+raDMHSIPGEaCxryUkpe93w== In-Reply-To: <16618.14938.qm@web38802.mail.mud.yahoo.com> Mime-version: 1.0 X-OriginalArrivalTime: 27 Oct 2008 21:25:43.0360 (UTC) FILETIME=[916A5400:01C9387A] X-Nokia-AV: Clean 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: multipart/mixed; boundary="===============0211484784==" 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. --===============0211484784== Content-type: multipart/alternative; boundary="B_3307969507_8147046" > 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_3307969507_8147046 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Behcet, The main point of the I-D is that the choice of IPsec as the protocol for securing MIP6 signaling was premature and hence needs to be reconsidered. -Raj On 10/27/08 4:20 PM, "ext Behcet Sarikaya" wrote: > Hi Raj, > I read this draft with interest. I remember long and heated debate in 6man > list on IPSec being mandatory in IPv6. > Overall I kind of disagree with you saying that MIPv6 hasn't been widely > deployed just because of IPSec. Probably the status of IPv6 deployment has > something to do with it. > > Regards, > > Behcet > > > From: Basavaraj Patil > To: "mext@ietf.org" > Sent: Monday, October 27, 2008 12:27:33 PM > Subject: [MEXT] FW: New Version Notification for > draft-patil-mext-mip6issueswithipsec-00 > > > 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 > > --B_3307969507_8147046 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [MEXT] FW: New Version Notification for draft-patil-mext-mip6iss= ueswithipsec-00
Hi Behcet,

The main point of the I-D is that the choice of IPsec as the protocol for s= ecuring MIP6 signaling was premature and hence needs to be reconsidered.
-Raj


On 10/27/08 4:20 PM, "ext Behcet Sarikaya" <behcetsarikaya@yahoo.com> wrote:

Hi Raj,
  I read this draft with interest. I remember long and heated deb= ate in 6man list on IPSec being mandatory in IPv6.
  Overall I kind of disagree with you saying that MIPv6 hasn't be= en widely deployed just because of IPSec. Probably the status of IPv6 deploy= ment has something to do with it.

Regards,

Behcet

From: Ba= savaraj Patil <basavaraj.patil@nokia.= com>
To: "mext@ietf.org" <mext@ietf.org>
Sent: Monday, October 27, 2008 12:27:33 PM
Subject: [MEXT] FW: New Version Notification for draft-patil-mext-mi= p6issueswithipsec-00


FYI,

------ Forwarded Message
From: ext IETF I-D Submission Tool <idsu= bmission@ietf.org>
Date: Mon, 27 Oct 2008 09:55:13 -0700 (PDT)
To: Basavaraj Patil <basavaraj.patil= @nokia.com>
Cc: Charles Perkins <charliep@wichorus.c= om>, <Hannes.Tschofenig@gmx.ne= t>
Subject: New Version Notification for
draft-patil-mext-mip6issueswithipsec-00


A new version of I-D, draft-patil-mext-mip6issueswithipsec-00.txt has been<= BR> 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<= BR> 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.
            &nb= sp;      


The IETF Secretariat.



------ End of Forwarded Message

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

 
--B_3307969507_8147046-- --===============0211484784== 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 --===============0211484784==-- From n21102008@gmail.com Tue Oct 28 22:07:43 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729053A67E2; Tue, 28 Oct 2008 22:07:43 -0700 (PDT) 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 cBL+Lww6-jEN; Tue, 28 Oct 2008 22:07:43 -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 3390E3A6801; Tue, 28 Oct 2008 22:07:43 -0700 (PDT) Received: from f3t ([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 <0K9H00K42I8DINF0@maildcarg4.dc-host.net.ar>; Wed, 29 Oct 2008 02:07:26 -0300 (ART) Date: Wed, 29 Oct 2008 03:07:26 +0100 From: "n21102008@gmail.com" Subject: COMPUTADORA CORE 2 DUO E7200 + Monitor Samsung LCD 19" To: core2duo Message-id: <3818-22008103292726828@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 CEL: 15-3197-5821 EMail: n07102008@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: CIRKUIT PLANET ATX con 2 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 $2599 FINAL (IVA inc) Consulte otras configuraciones a medida, notebooks, camaras digitales y mu= cho mas From mext-bounces@ietf.org Wed Oct 29 00:04: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 67DDE3A6AB8; Wed, 29 Oct 2008 00:04:34 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FC523A6AB8 for ; Wed, 29 Oct 2008 00:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 jkIDyFqpA2qP for ; Wed, 29 Oct 2008 00:04:26 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id D2F673A6783 for ; Wed, 29 Oct 2008 00:04:26 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m9T73i0w019462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Oct 2008 02:03:44 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m9T73hmH020059; Wed, 29 Oct 2008 02:03:43 -0500 (CDT) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m9T73h65020044 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 29 Oct 2008 02:03:43 -0500 (CDT) Received: from XCH-NW-CCR1V.nw.nos.boeing.com ([130.247.64.17]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Wed, 29 Oct 2008 00:03:43 -0700 From: "Davis, Terry L" To: Behcet Sarikaya , Basavaraj Patil , "mext@ietf.org" , Mobile Platform Internet Mailing List Date: Wed, 29 Oct 2008 00:03:40 -0700 Thread-Topic: [MEXT] FW: New Version Notification fordraft-patil-mext-mip6issueswithipsec-00 Thread-Index: Ack4ed9KWUTO0Z+fTyy9mjJIGgp2tQBF2CuA Message-ID: <2557049CDBC35B4EBD79CFACFEC045840ADB7447@XCH-NW-CCR1V.nw.nos.boeing.com> References: <16618.14938.qm@web38802.mail.mud.yahoo.com> In-Reply-To: <16618.14938.qm@web38802.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1285-5.500.1027-16246.003 x-tm-as-result: No--68.632400-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No MIME-Version: 1.0 Subject: Re: [MEXT] FW: New Version Notification fordraft-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: multipart/mixed; boundary="===============2087721050==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============2087721050== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_2557049CDBC35B4EBD79CFACFEC045840ADB7447XCHNWCCR1Vnwnos_" --_000_2557049CDBC35B4EBD79CFACFEC045840ADB7447XCHNWCCR1Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All One of the key things that we all need to press on, is to FORCE the IPSec v= endors to STANDARDIZE their implementations and terminology so that IPSec i= nteroperability is actually achievable (without one of the few existing rea= l IPSec wizards) by normal networking/security folks. This will be especially problematic for aviation since we will have so many= different PKIs to interface with and our aircraft will have to seamlessly = handoff from PKI to PKI around the world to re-establish their IPSec tunnel= s as they change Navigation Service Providers. For us, having a "single ve= ndor" IPSec solution or "single PKI" solution (which is how the corporate w= orld solves the IPSec non-interoperability problem now) for aviation is a t= rue "non-starter". All that said, from my point-of-view, IPSec MUST remain mandatory in IPv6; = it may need another working group to get implementations and interfaces sta= ndardized though. Take care Terry PS: This is also very problematic for DNSSec which has become critical for = the TLDs. I expect some interesting discussions on that in Cairo next week= . ________________________________ From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Beh= cet Sarikaya Sent: Monday, October 27, 2008 2:21 PM To: Basavaraj Patil; mext@ietf.org Subject: Re: [MEXT] FW: New Version Notification fordraft-patil-mext-mip6is= sueswithipsec-00 Hi Raj, I read this draft with interest. I remember long and heated debate in 6ma= n list on IPSec being mandatory in IPv6. Overall I kind of disagree with you saying that MIPv6 hasn't been widely = deployed just because of IPSec. Probably the status of IPv6 deployment has = something to do with it. Regards, Behcet ________________________________ From: Basavaraj Patil To: "mext@ietf.org" Sent: Monday, October 27, 2008 12:27:33 PM Subject: [MEXT] FW: New Version Notification for draft-patil-mext-mip6issue= swithipsec-00 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 --_000_2557049CDBC35B4EBD79CFACFEC045840ADB7447XCHNWCCR1Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All

 

One of the key things that we all need= to press on, is to FORCE the IPSec vendors to STANDARDIZE their implementation= s and terminology so that IPSec interoperability is actually achievable (with= out one of the few existing real IPSec wizards) by normal networking/security folks.

 

This will be especially problematic fo= r aviation since we will have so many different PKIs to interface with and ou= r aircraft will have to seamlessly handoff from PKI to PKI around the world t= o re-establish their IPSec tunnels as they change Navigation Service Provider= s.  For us, having a “single vendor” IPSec solution or “singl= e PKI” solution (which is how the corporate world solves the IPSec non-interoperability problem now) for aviation is a true “non-starter= ”.

 

All that said, from my point-of-view, IPSec MUST remain mandatory in IPv6; it may need another working group to g= et implementations and interfaces standardized though.

Take care
Terry

PS: This is also very problematic for DNSSec which has be= come critical for the TLDs.  I expect some interesting discussions on that = in Cairo next week.<= /span>

From: mext-bou= nces@ietf.org [mailto:mext-bounces@ietf.org] On Behal= f Of Behcet Sarikaya
Sent: Monday, October 27, 20= 08 2:21 PM
To: Basavaraj Patil; mext@ietf.org
Subject: Re: [MEXT] FW: New Version Notification fordraft-patil-mext-mip6issueswithipsec-00

 

Hi Raj,
  I read this draft with interest. I remember long and heated debate i= n 6man list on IPSec being mandatory in IPv6.
  Overall I kind of disagree with you saying that MIPv6 hasn't been wi= dely deployed just because of IPSec. Probably the status of IPv6 deployment has something to do with it.

Regards,

Behcet

 

From: Basavara= j Patil <basavaraj.patil@nokia.com>
To: "mext@ietf.org" <mext@ietf.org>
Sent: Monday, October 27, 20= 08 12:27:33 PM
Subject: [MEXT] FW: New Vers= ion Notification for draft-patil-mext-mip6issueswithipsec-00


FYI,

------ Forwarded Message
From: ext IETF I-D Submission Tool <idsubmission@ietf.org>
Date: Mon, 27 Oct 2008 09:55:13 -0700 (PDT)
To: Basavaraj Patil <basavaraj.patil@nokia.com&= gt;
Cc: Charles Perkins <charliep@wichorus.com>, <= ;Hannes.Tschofenig@gmx.net&= gt;
Subject: New Version Notification for
draft-patil-mext-mip6issueswithipsec-00


A new version of I-D, draft-patil-mext-mip6issueswithipsec-00.txt has been<= br> 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<= br> 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
ht= tps://www.ietf.org/mailman/listinfo/mext

 

--_000_2557049CDBC35B4EBD79CFACFEC045840ADB7447XCHNWCCR1Vnwnos_-- --===============2087721050== 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 --===============2087721050==-- From mext-bounces@ietf.org Wed Oct 29 01:03: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 275C23A6CE5; Wed, 29 Oct 2008 01:03:34 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84AF73A6ACD for ; Wed, 29 Oct 2008 01:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=1.081, 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 0-JKDpOMpnyF for ; Wed, 29 Oct 2008 01:03:31 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9D90D3A6CD5 for ; Wed, 29 Oct 2008 01:03:30 -0700 (PDT) Received: (qmail invoked by alias); 29 Oct 2008 08:03:27 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp001) with SMTP; 29 Oct 2008 09:03:27 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18IYbBxOrYI2fCiSZwHo6Q8cOF4cSatf+YVQRjuhd Z8KAyYafnu+3jV From: "Hannes Tschofenig" To: "'Davis, Terry L'" , "'Behcet Sarikaya'" , "'Basavaraj Patil'" , , "'Mobile Platform Internet Mailing List'" References: <16618.14938.qm@web38802.mail.mud.yahoo.com> <2557049CDBC35B4EBD79CFACFEC045840ADB7447@XCH-NW-CCR1V.nw.nos.boeing.com> Date: Wed, 29 Oct 2008 10:03:26 +0200 Message-ID: <003401c9399c$d38ffc40$04ffa8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ack4ed9KWUTO0Z+fTyy9mjJIGgp2tQBF2CuAAALOZ7A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <2557049CDBC35B4EBD79CFACFEC045840ADB7447@XCH-NW-CCR1V.nw.nos.boeing.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.79 Subject: Re: [MEXT] FW: New Version Notification fordraft-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 Overall I kind of disagree with you saying that MIPv6 hasn't been widely deployed just because of IPSec. Probably the status of IPv6 deployment has something to do with it. [Hannes] Interestingly, Mobile IPv4 is not widely implemented/used either. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Oct 29 01:06: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 AE4A63A6CD3; Wed, 29 Oct 2008 01:06:01 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7597C3A6CD3 for ; Wed, 29 Oct 2008 01:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=0.541, 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 dx2hceZoGjUY for ; Wed, 29 Oct 2008 01:05:56 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 765F93A6ACD for ; Wed, 29 Oct 2008 01:05:54 -0700 (PDT) Received: (qmail invoked by alias); 29 Oct 2008 08:05:53 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp003) with SMTP; 29 Oct 2008 09:05:53 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1++UEMjdFW+IIPycOTeoWiDW7UX6vPZv5eC+Q6xTD qm/i09JAF6tpzX From: "Hannes Tschofenig" To: "'Hannes Tschofenig'" , "'Davis, Terry L'" , "'Behcet Sarikaya'" , "'Basavaraj Patil'" , , "'Mobile Platform Internet Mailing List'" References: <16618.14938.qm@web38802.mail.mud.yahoo.com> <2557049CDBC35B4EBD79CFACFEC045840ADB7447@XCH-NW-CCR1V.nw.nos.boeing.com> Date: Wed, 29 Oct 2008 10:05:51 +0200 Message-ID: <003501c9399d$2acbae50$04ffa8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ack4ed9KWUTO0Z+fTyy9mjJIGgp2tQBF2CuAAALOZ7AAABrm4A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: Re: [MEXT] FW: New Version Notification fordraft-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 I should also add: Mobile IP in general is facing a couple of challenges and producing complex specifications to make it harder for implementers to get started will not make it easier. With regard to the challenges: Security is only one of them, I agree. But we need to start somewhere. >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >Sent: 29 October, 2008 10:03 >To: 'Davis, Terry L'; 'Behcet Sarikaya'; 'Basavaraj Patil'; >'mext@ietf.org'; 'Mobile Platform Internet Mailing List' >Subject: RE: [MEXT] FW: New Version Notification >fordraft-patil-mext-mip6issueswithipsec-00 > > Overall I kind of disagree with you saying that MIPv6 hasn't >been widely deployed just because of IPSec. Probably the >status of IPv6 deployment has something to do with it. > >[Hannes] Interestingly, Mobile IPv4 is not widely >implemented/used either. > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Oct 29 02:33: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 E4B923A6C71; Wed, 29 Oct 2008 02:33:29 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 929BA3A6874; Fri, 24 Oct 2008 02:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 gFiL6lPlkY66; Fri, 24 Oct 2008 02:47:37 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 95A743A63D2; Fri, 24 Oct 2008 02:47:36 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D154B294005; Fri, 24 Oct 2008 11:48:56 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7895C294003; Fri, 24 Oct 2008 11:48:55 +0200 (IST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9O9mske028393; Fri, 24 Oct 2008 11:48:54 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Fri, 24 Oct 2008 11:48:54 +0200 From: Yaron Sheffer To: Arnaud Ebalard , Sheila Frankel Date: Fri, 24 Oct 2008 11:48:50 +0200 Thread-Topic: [IPsec] Roadmap doc Thread-Index: Ack1LGRMyAD/vdBoTUy7kyh2AGIFdAAjt8Tw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CCA70@il-ex01.ad.checkpoint.com> References: <20081023111335.93181fsvzkllr3q7@webmail.nist.gov> <87skqnl1oo.fsf@natisbad.org> In-Reply-To: <87skqnl1oo.fsf@natisbad.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 29 Oct 2008 02:33:29 -0700 Cc: "IPsec@ietf.org" , IETF MEXT WG ML Subject: Re: [MEXT] [IPsec] Roadmap doc X-BeenThere: mext@ietf.org X-Mailman-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="===============0896177922==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0896177922== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0012_01C935CE.7B08A8F0" ------=_NextPart_000_0012_01C935CE.7B08A8F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Sheila, Arnaud, First, I am happy with the outline as presented here, including the 24XX documents. If anything, it may be too ambitious (i.e. lengthy). Regarding the interactions of MIP6 with IKE/IPsec: - The Roadmap document should cover these areas, just as it covers other consumers of this technology. But despite its (unfortunate) name, I don't see the document as a future-looking position statement of the WG, but rather as documentation of completed work. - As for the actual work on MIP6/IPsec dependencies: the ipsecme WG is busy today with documents that have far wider applicability to the IPsec community. _If_ there is strong interest in these issues from a specific community of people, perhaps the way to go about it is with a dedicated design team. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Arnaud Ebalard Sent: Thursday, October 23, 2008 18:24 To: Sheila Frankel Cc: IPsec@ietf.org; IETF MEXT WG ML Subject: Re: [IPsec] Roadmap doc Hi, [mext added in CC] "Sheila Frankel" writes: > 7. Outgrowths of IPsec/IKE > 7.1. IPComp (Compression) > 7.2. IKEv2 Mobility and Multihoming (MobIKE) > 7.3. Better-than-Nothing Security (Btns) > 7.4. Kerberized Internet Negotiation of Keys (Kink) > 7.5. IPsec Secure Remote Access (IPSRA) > 7.6. IPsec Keying Information Resource Record (IPsecKEY) > 8. Other Protocols that use IPsec/IKE > 8.1. Mobile IP (MIPv4 and MIPv6) IMHO, MIPv6 is user of IPsec/IKE but not a common user: it uses IPsec/IKE for its protection but it also has some very tight interactions with IKE/IPsec/[PF_KEY] and for that reason, specific requirements: - configuration via IKEv2 (various RFC) - bootstrapping and efficient handling of movement in IPsec/IKE context (see draft draft-ebalard-mext-pfkey-enhanced-migrate-00 which is a follow-up of draft-sugimoto-mip6-pfkey-migrate-04) The problem is that this last item sits in the middle of the field with IPsec WG on one side and MIPv6 on the other; each side considering that it should be handled by the other. At the moment, MIPv6 specification documents (3775, 3776, 4877, 5026, ...) have expectations on the behavior in IPsec/IKE environments but IPsec/IKE (and possibly PF_KEY) are missing the interfaces to support those requirements. This is currently making progress outside any working group. In the end, I am wondering where this item stand w.r.t the roadmap document. I know that it is not in the initial set of work items of the WG but this does not prevent clarifying the position of the WG on it in the doc, does it? > 8.2. Open Shortest Path First (OSPF) > 8.3. Host Identity Protocol (HIP) > 8.4. Extensible Authentication Protocol (EAP) Method Update (EMU) 10 > 8.5. Stream Control Transmission Protocol (SCTP) > 8.6. Fibre Channel > 9. Security Considerations > 10. IANA Considerations > 11. References > 11.1. Normative References > 11.2. Informative References > > Sections 1 and 2 will contain introductory material about IPsec and > IKE: their functions, placement in the stack, inter-relationships, > etc. > > The rest of the doc will basically be a list of RFCs, with a brief > description of each. For the cryptographic algorithms, each section > will describe where each type of algorithm is used within IPsec and/or > IKE. For each algorithm, the following information will be included: > whether it applies to IPsec, IKE, or both; requirement level (MUST > etc.); special considerations (e.g. cannot be used with manual > keying); how widely/commonly it is deployed. Section 8 (other > protocols that use IPsec/IKE) will very briefly mention the context in > which each protocol and/or RFC uses IPsec/IKE. > > Questions for the list: > 1) Are there any other topics that should be discussed? the one above, i.e. where should MIPv6 IPsec/IKE roadmap/work be handled ;-) Cheers, a+ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0012_01C935CE.7B08A8F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAyNDA5NDg1MFowIwYJKoZIhvcNAQkEMRYEFMikrgKTRNng b8yjGEZpv2U2p8klMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA d2MdbG+X6IDeBW8w7ttJ2JeqUAqvMYo+ZeuD5tpQUHhcbgRCRDFFCtjTGtWgDXZ5hcKOde/CtykL WN4XXDJ2TWFD89Scy1bs9BBfvrUhNoIhV58oNF8/mbgco3b34JWXEbSuAwvnHcoJ5JwKVBwhAn0Z Gid6Dizt8d3kzT6Q7kMFUND4zbFHDxbg1p5GbykEXK6WjV9N4j8C710FpQIGwk+xDTLSgCf9u9pj Rw7HSkJIDsp0tDW5+bAQR3zSIVJu/2+LVHSdLilsL7wem5Mm80mjpJ7xT5Xf+MsbxZkxVaJK4ZuN wRdv2C/VdRa1MTbLfpz4n1xUn6753ecSHYvWHQAAAAAAAA== ------=_NextPart_000_0012_01C935CE.7B08A8F0-- --===============0896177922== 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 --===============0896177922==-- From mext-bounces@ietf.org Thu Oct 30 01:05: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 BBCAF3A6999; Thu, 30 Oct 2008 01:05:58 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3DE3A6999 for ; Thu, 30 Oct 2008 01:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGLugbtCwAu0 for ; Thu, 30 Oct 2008 01:05:57 -0700 (PDT) Received: from ws000774.tietoenator.com (ws000774.tietoenator.com [193.12.181.129]) by core3.amsl.com (Postfix) with ESMTP id EE28A3A6901 for ; Thu, 30 Oct 2008 01:05:56 -0700 (PDT) X-AuditID: c10cb581-00001008000004d8-e8-49096ae22ee3 Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 09:05:54 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Oct 2008 09:06:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 09:06:37 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Home Agent Switch Message (RFC 5142) and DSMIP Thread-Index: Ack6Zm5qKoPCxa7xSPyVyukVmLWAcg== From: To: X-OriginalArrivalTime: 30 Oct 2008 08:06:27.0003 (UTC) FILETIME=[687038B0:01C93A66] X-Brightmail-Tracker: AAAAAA== Subject: [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 The home agent switch message allows a home agent to inform the mobile node, that the mobile node should deregister from the home agent, and register with some other home agent. The address of this other home agent is supplied in the home agent switch message. The address in an IPv6 address. If the home agent supports DSMIP, the home agent should also provide an IPv4 address. Isn't there a need for an extention, such that the home agent's IPv4 address can be given to the mobile node? Christian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Oct 30 10:38: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 32FD03A6ADA; Thu, 30 Oct 2008 10:38:59 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 226D43A6ADA for ; Thu, 30 Oct 2008 10:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyBovp9TJ2SZ for ; Thu, 30 Oct 2008 10:38:57 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 35E8D3A6AD7 for ; Thu, 30 Oct 2008 10:38:57 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 13:38:50 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Agent Switch Message (RFC 5142) and DSMIP Thread-Index: Ack6Zm5qKoPCxa7xSPyVyukVmLWAcgAT7GrQ References: From: "Vijay Devarapalli" To: , Cc: Julien Laganier 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 Hi Christian, RFC 5142 was done a while ago. To able to re-direct the mobile node to an IPv4 address of the home agent, we need to revise RFC 5142. I can do that, if there is interest. Vijay Christian.Kaas-Petersen@tietoenator.com wrote: > The home agent switch message allows a home agent to inform the > mobile node, that the mobile node should deregister from the home > agent, and register with some other home agent. The address of this > other home agent is supplied in the home agent switch message. > The address in an IPv6 address. If the home agent supports DSMIP, > the home agent should also provide an IPv4 address. Isn't there a > need for an extention, such that the home agent's IPv4 address > can be given to the mobile node? > > Christian > _______________________________________________ > MEXT mailing 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 Oct 30 13:02: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 B7EE33A6AD9; Thu, 30 Oct 2008 13:02:55 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60BEB3A6AD7 for ; Thu, 30 Oct 2008 13:02:54 -0700 (PDT) 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 orVexky5BrMC for ; Thu, 30 Oct 2008 13:02:53 -0700 (PDT) Received: from g5t0008.atlanta.hp.com (g5t0008.atlanta.hp.com [15.192.0.45]) by core3.amsl.com (Postfix) with ESMTP id B12333A69FB for ; Thu, 30 Oct 2008 13:02:53 -0700 (PDT) Received: from g5t0029.atlanta.hp.com (g5t0029.atlanta.hp.com [16.228.8.141]) by g5t0008.atlanta.hp.com (Postfix) with ESMTP id F160B2430B; Thu, 30 Oct 2008 20:02:51 +0000 (UTC) Received: from [192.168.1.102] (squirrel.fc.hp.com [15.11.146.57]) by g5t0029.atlanta.hp.com (Postfix) with ESMTP id 31A2B10037; Thu, 30 Oct 2008 20:02:50 +0000 (UTC) Message-ID: <490A12E9.60907@hp.com> Date: Thu, 30 Oct 2008 16:02:49 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Vijay Devarapalli References: In-Reply-To: Cc: Christian.Kaas-Petersen@tietoenator.com, Julien Laganier , 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 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. -Brian Vijay Devarapalli wrote: > Hi Christian, > > RFC 5142 was done a while ago. To able to re-direct the mobile node to > an IPv4 address of the home agent, we need to revise RFC 5142. I can do > that, if there is interest. > > Vijay > > Christian.Kaas-Petersen@tietoenator.com wrote: >> The home agent switch message allows a home agent to inform the >> mobile node, that the mobile node should deregister from the home >> agent, and register with some other home agent. The address of this >> other home agent is supplied in the home agent switch message. >> The address in an IPv6 address. If the home agent supports DSMIP, >> the home agent should also provide an IPv4 address. Isn't there a >> need for an extention, such that the home agent's IPv4 address >> can be given to the mobile node? >> >> Christian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Oct 30 13:44:42 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 6A79E3A6B4E; Thu, 30 Oct 2008 13:44:42 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64A383A6B45 for ; Thu, 30 Oct 2008 13:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 kvNVm8JtEQtr for ; Thu, 30 Oct 2008 13:44:39 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 9213B3A6B20 for ; Thu, 30 Oct 2008 13:44:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 16:44:27 -0400 Message-ID: In-Reply-To: <490A12E9.60907@hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Agent Switch Message (RFC 5142) and DSMIP Thread-Index: Ack6yn4KBpJ0YuM+T2eOwFOCtLwZRwABXvRQ References: <490A12E9.60907@hp.com> From: "Vijay Devarapalli" To: "Brian Haley" Cc: Christian.Kaas-Petersen@tietoenator.com, Julien Laganier , 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 Brian Haley 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. Vijay > > -Brian > > Vijay Devarapalli wrote: >> Hi Christian, >> >> RFC 5142 was done a while ago. To able to re-direct the mobile node >> to an IPv4 address of the home agent, we need to revise RFC 5142. I >> can do that, if there is interest. >> >> Vijay >> >> Christian.Kaas-Petersen@tietoenator.com wrote: >>> The home agent switch message allows a home agent to inform the >>> mobile node, that the mobile node should deregister from the home >>> agent, and register with some other home agent. The address of this >>> other home agent is supplied in the home agent switch message. >>> The address in an IPv6 address. If the home agent supports DSMIP, >>> the home agent should also provide an IPv4 address. Isn't there a >>> need for an extention, such that the home agent's IPv4 address >>> can be given to the mobile node? >>> >>> Christian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Oct 31 00:16:45 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 E485B3A6804; Fri, 31 Oct 2008 00:16:44 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B821E3A6804 for ; Fri, 31 Oct 2008 00:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uojvb7MDj26q for ; Fri, 31 Oct 2008 00:16:43 -0700 (PDT) Received: from ws000774.tietoenator.com (ws000774.tietoenator.com [193.12.181.129]) by core3.amsl.com (Postfix) with ESMTP id 4C0673A657C for ; Fri, 31 Oct 2008 00:16:40 -0700 (PDT) X-AuditID: c10cb581-000004bc000004d8-4a-490ab0d452f7 Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Oct 2008 08:16:36 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Oct 2008 08:17:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 31 Oct 2008 08:17:07 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home Agent Switch Message (RFC 5142) and DSMIP Thread-Index: Ack6Zm5qKoPCxa7xSPyVyukVmLWAcgAT7GrQABxuV3A= References: From: To: , X-OriginalArrivalTime: 31 Oct 2008 07:17:08.0397 (UTC) FILETIME=[AF6285D0:01C93B28] X-Brightmail-Tracker: AAAAAA== Cc: julien.laganier.ietf@googlemail.com 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 Yes, please suggest a mobility option and please prepare a document (RFC5142bis or separate document). I have the 3GPP release 8 in mind and should like to have a solution. Christian > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: 30. oktober 2008 18:39 > To: Kaas-Petersen Christian; mext@ietf.org > Cc: Julien Laganier; marcelo bagnulo braun > Subject: RE: [MEXT] Home Agent Switch Message (RFC 5142) and DSMIP > > Hi Christian, > > RFC 5142 was done a while ago. To able to re-direct the > mobile node to an IPv4 address of the home agent, we need to > revise RFC 5142. I can do that, if there is interest. > > Vijay > > Christian.Kaas-Petersen@tietoenator.com wrote: > > The home agent switch message allows a home agent to inform > the mobile > > node, that the mobile node should deregister from the home > agent, and > > register with some other home agent. The address of this > other home > > agent is supplied in the home agent switch message. > > The address in an IPv6 address. If the home agent supports > DSMIP, the > > home agent should also provide an IPv4 address. Isn't there a need > > for an extention, such that the home agent's IPv4 address > can be given > > to the mobile node? > > > > Christian > > _______________________________________________ > > MEXT mailing 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 Oct 31 01:30: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 D0DF73A6BAC; Fri, 31 Oct 2008 01:30:26 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA2D3A6BAC for ; Fri, 31 Oct 2008 01:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdH9LW0hXR03 for ; Fri, 31 Oct 2008 01:30:23 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by core3.amsl.com (Postfix) with ESMTP id 6B1893A6BAD for ; Fri, 31 Oct 2008 01:30:22 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so509438nfh.39 for ; Fri, 31 Oct 2008 01:30:18 -0700 (PDT) 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=tOHz4xYrDHoh4EwqXPZo5uR8o2gha1lFQaqCCTT30qM=; b=GFWZG/yJwh5cjoUmHX8UNmGO1DiO3FQ61VzoF4yhn5I8AKDpSls56BxferTsYW+b/+ SkT18d38I285gAPRCQaWWq2sRcEcWD5jelNbOrLmVKdwCAv1ZAwHpEc9EGQ/ia6gC8Yr PWl59SvFhikbEE4XR+Otg/VwDf5BDR0HnWLA0= 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=bTeD73b27fUZepU4pZ6Nv0uCmm5BLXlqm6Fy/jDffKBEBfsXtTsFEY58gNt2b/clnL txGr7yUkm0l19PKtc+q0I6zRnRLpHiM4Ve6RhY9skOI3DcE1IoB6cLKKBKs6uLJpUUTu jKhsfG1bhZshLUfJjJE1Me6qKjqcuIvbuN+9s= Received: by 10.210.133.2 with SMTP id g2mr11562184ebd.99.1225441818322; Fri, 31 Oct 2008 01:30:18 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id p10sm4858206gvf.7.2008.10.31.01.30.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 31 Oct 2008 01:30:17 -0700 (PDT) To: "Vijay Devarapalli" Date: Fri, 31 Oct 2008 09:30:20 +0100 User-Agent: KMail/1.9.10 References: <490A12E9.60907@hp.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200810310930.20753.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 Thursday 30 October 2008, Vijay Devarapalli wrote: > Brian Haley wrote: > > > > 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? --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Oct 31 07:09: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 3E7D528C290; Fri, 31 Oct 2008 07:09:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1592028C28B for ; Fri, 31 Oct 2008 07:09:39 -0700 (PDT) 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 KHqxiQyfeKqg for ; Fri, 31 Oct 2008 07:09:38 -0700 (PDT) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by core3.amsl.com (Postfix) with ESMTP id 4B15B28C289 for ; Fri, 31 Oct 2008 07:09:38 -0700 (PDT) Received: from g4t0009.houston.hp.com (g4t0009.houston.hp.com [16.234.32.26]) by g1t0028.austin.hp.com (Postfix) with ESMTP id C9C9C1C206; Fri, 31 Oct 2008 14:09:36 +0000 (UTC) Received: from [192.168.1.102] (squirrel.fc.hp.com [15.11.146.57]) by g4t0009.houston.hp.com (Postfix) with ESMTP id D68E2C0CE; Fri, 31 Oct 2008 14:09:34 +0000 (UTC) Message-ID: <490B119E.5000908@hp.com> Date: Fri, 31 Oct 2008 10:09:34 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Vijay Devarapalli References: <490A12E9.60907@hp.com> In-Reply-To: Cc: Christian.Kaas-Petersen@tietoenator.com, Julien Laganier , 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 Vijay Devarapalli wrote: > Brian Haley 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. But with that logic we'd update 3775 every time we had a new mobility option, and we don't do that. I'd prefer a separate document. -Brian >> Vijay Devarapalli wrote: >>> Hi Christian, >>> >>> RFC 5142 was done a while ago. To able to re-direct the mobile node >>> to an IPv4 address of the home agent, we need to revise RFC 5142. I >>> can do that, if there is interest. >>> >>> Vijay >>> >>> Christian.Kaas-Petersen@tietoenator.com wrote: >>>> The home agent switch message allows a home agent to inform the >>>> mobile node, that the mobile node should deregister from the home >>>> agent, and register with some other home agent. The address of this >>>> other home agent is supplied in the home agent switch message. >>>> The address in an IPv6 address. If the home agent supports DSMIP, >>>> the home agent should also provide an IPv4 address. Isn't there a >>>> need for an extention, such that the home agent's IPv4 address >>>> can be given to the mobile node? >>>> >>>> Christian > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Oct 31 07:46: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 B10003A682F; Fri, 31 Oct 2008 07:46:09 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC4B3A67F3 for ; Fri, 31 Oct 2008 07:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojn+d4D-QNFk for ; Fri, 31 Oct 2008 07:46:03 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id AAF153A6A58 for ; Fri, 31 Oct 2008 07:45:53 -0700 (PDT) Received: from 24.130.62.120 ([24.130.62.120]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Fri, 31 Oct 2008 14:45:51 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 31 Oct 2008 07:45:50 -0700 From: Vijay Devarapalli To: Julien Laganier Message-ID: Thread-Topic: [MEXT] Home Agent Switch Message (RFC 5142) and DSMIP Thread-Index: Ack7Z13pP5/Tw2AYTEmkmCMi8qyxTQ== In-Reply-To: <200810310930.20753.julien.laganier.IETF@googlemail.com> Mime-version: 1.0 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 10/31/08 1:30 AM, "Julien Laganier" wrote: > On Thursday 30 October 2008, Vijay Devarapalli wrote: >> Brian Haley wrote: >>> >>> 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. Vijay > > --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Oct 31 07:52: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 C49233A6A70; Fri, 31 Oct 2008 07:52:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A2A3A6A58 for ; Fri, 31 Oct 2008 07:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id He15KMe9Ib11 for ; Fri, 31 Oct 2008 07:52:39 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 88AA23A6A15 for ; Fri, 31 Oct 2008 07:52:17 -0700 (PDT) Received: from 24.130.62.120 ([24.130.62.120]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Fri, 31 Oct 2008 14:52:15 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 31 Oct 2008 07:52:15 -0700 From: Vijay Devarapalli To: Brian Haley Message-ID: Thread-Topic: [MEXT] Home Agent Switch Message (RFC 5142) and DSMIP Thread-Index: Ack7aENjXCXZpRzfLESQEiMow5tijw== In-Reply-To: <490B119E.5000908@hp.com> Mime-version: 1.0 Cc: Christian.Kaas-Petersen@tietoenator.com, Julien Laganier , 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 10/31/08 7:09 AM, "Brian Haley" wrote: > Vijay Devarapalli wrote: >> Brian Haley 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. > > But with that logic we'd update 3775 every time we had a new mobility > option, and we don't do that. I'd prefer a separate document. In general, if it is a new feature, we should standardize it in a separate document. In this case, we just want the ability to carry the HA IPv4 address in an existing message. 5142 is already a very simple short spec, revising it wouldn't take much effort. Since we are adding a mobility option, it would be backward compatible with implementations that are out today that implement 5142. Vijay > > -Brian > > >>> Vijay Devarapalli wrote: >>>> Hi Christian, >>>> >>>> RFC 5142 was done a while ago. To able to re-direct the mobile node >>>> to an IPv4 address of the home agent, we need to revise RFC 5142. I >>>> can do that, if there is interest. >>>> >>>> Vijay >>>> >>>> Christian.Kaas-Petersen@tietoenator.com wrote: >>>>> The home agent switch message allows a home agent to inform the >>>>> mobile node, that the mobile node should deregister from the home >>>>> agent, and register with some other home agent. The address of this >>>>> other home agent is supplied in the home agent switch message. >>>>> The address in an IPv6 address. If the home agent supports DSMIP, >>>>> the home agent should also provide an IPv4 address. Isn't there a >>>>> need for an extention, such that the home agent's IPv4 address >>>>> can be given to the mobile node? >>>>> >>>>> Christian >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Oct 31 09:45: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 516A93A6C33; Fri, 31 Oct 2008 09:45:55 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B35C3A6C33 for ; Fri, 31 Oct 2008 09:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, 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 tgA06iEq--nv for ; Fri, 31 Oct 2008 09:45:53 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id EFAC73A6997 for ; Fri, 31 Oct 2008 09:45:35 -0700 (PDT) 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 <0K9M00BRZ3VXPE@usaga04-in.huawei.com> for mext@ietf.org; Fri, 31 Oct 2008 11:45:34 -0500 (CDT) 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 <0K9M00H3E3VWNZ@usaga04-in.huawei.com> for mext@ietf.org; Fri, 31 Oct 2008 11:45:33 -0500 (CDT) Date: Fri, 31 Oct 2008 11:45:32 -0500 From: Frank Xia To: Basavaraj Patil , mext@ietf.org Message-id: <002f01c93b78$17786410$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: 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" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Raj It is a very interesting draft. Issue #1 "... As a result of this dependence, MIP6 is no longer a standalone host-based mobility protocol..." General speaking, I am with you. The protocol is not elastic enough. IPSec is a very good tool which MIPv6 should make use of . On the other hand, it is better to keep the protocol minimal self-sufficient in case some external dependencies can not be satisfied. Issue #2 "...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" Question: could you give me one case as an example? Issue #3 "...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 can partly agree with you because it is optional to use IPSec for data traffice between MNs and HAs. Issue #5 " MIP6 without any dependencies on protocols for security is easier to implement and has wider applicability' I agree to decouple MIPv6 from IKE/IPSec. BR Frank ----- Original Message ----- From: "Basavaraj Patil" To: Sent: Monday, October 27, 2008 12:27 PM Subject: [MEXT] FW: New Version Notification for draft-patil-mext-mip6issueswithipsec-00 > > 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 Fri Oct 31 15:56: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 3A7A93A6802; Fri, 31 Oct 2008 15:56:30 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CFAE3A67B2 for ; Fri, 31 Oct 2008 15:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phGktEVWiOX7 for ; Fri, 31 Oct 2008 15:56:27 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 9944C3A6802 for ; Fri, 31 Oct 2008 15:56:27 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 31 Oct 2008 18:56:24 -0400 Message-ID: In-Reply-To: <48E3C678.5060509@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Issue #11: De-registration when returning home Thread-Index: Ackj9r1RcaVLgcTcSsa0GEklWWnH3AXtGQog References: <48E3C678.5060509@earthlink.net> From: "Vijay Devarapalli" To: "Charles E. Perkins" , 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 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 From mext-bounces@ietf.org Fri Oct 31 16:15: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 72C7228C1E5; Fri, 31 Oct 2008 16:15: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 9103128C1CD for ; Fri, 31 Oct 2008 16:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXUyhQT0vu5f for ; Fri, 31 Oct 2008 16:15:17 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 7A0AD3A6C57 for ; Fri, 31 Oct 2008 16:15:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 31 Oct 2008 19:15:14 -0400 Message-ID: In-Reply-To: <48E55E5F.5040101@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Issue #17: Multi-homed mobile node can cause routing loop between home agents Thread-Index: Ackk6dl9GZJg9nlmTHiz1sRKz2u5AwWw4Wiw References: <48E55E5F.5040101@earthlink.net> From: "Vijay Devarapalli" 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 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, > -----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