From mext-bounces@ietf.org Mon Dec 1 02:14: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 6A8AA3A69C1; Mon, 1 Dec 2008 02:14:24 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C820F3A69C1 for ; Mon, 1 Dec 2008 02:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVit46biNG3u for ; Mon, 1 Dec 2008 02:14:23 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id 8ACAB3A6944 for ; Mon, 1 Dec 2008 02:14:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,694,1220220000"; d="vcf'?scan'208";a="17807108" Received: from dhcp-rocq-17.inria.fr ([128.93.62.17]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Dec 2008 11:14:17 +0100 Message-ID: <4933B8F7.2030705@inria.fr> Date: Mon, 01 Dec 2008 11:14:15 +0100 From: Thierry Ernst Organization: INRIA User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: mext References: <492FDBF8.9010203@gmail.com> <492FDF16.7020708@it.uc3m.es> <492FEC16.1020502@gmail.com> <492FF89F.8030304@it.uc3m.es> <492FFF17.3010508@gmail.com> <49300191.1070707@it.uc3m.es> <49301A4B.7040309@gmail.com> <4931A178.7060600@it.uc3m.es> <4931BBEE.4030801@gmail.com> <4932746F.3050605@it.uc3m.es> <4932CD7D.6040506@gmail.com> In-Reply-To: <4932CD7D.6040506@gmail.com> Content-Type: multipart/mixed; boundary="------------050600040809000307020602" Subject: Re: [MEXT] Access to CALM and 802.11p documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------050600040809000307020602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Alex, all, CALM is an architecture, so there are documents from the link layer up to the application layers, but these are not published yet so not public either. The document must be stable enough before it could be distributed. There is an underlying liaison statement between ISO and IETF but it needs to proceed through the ISO secretariat and I don't know what is the current status. Once the liaison is established access to documents should be provided. Regards, Thierry Alexandru Petrescu wrote: > marcelo bagnulo braun wrote: > [...] >>> Speaking of which - do you think in MEXT we can work with non-IETF >>> vehicular standards without having access to these standard >>> documents (IEEE 802.11p and ISO CALM)? Where are these documents? >>> >> mmm, i guess we usually work with link layers that are not defined by >> the ietf, so i don't see what is the problem with that... i mean, the >> IETF haven't defined ethernet but still we have defined arp and ND... > > I agree, we work with link layers that are not defined by IETF. For > Ethernet we have public free access to Ethernet standard documents. > I'm afraid there may not be public access for latest 802.11p > documents, neither ISO CALM documents. Maybe we could obtain this > access restricted to the MEXT WG members somehow. > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext --------------050600040809000307020602 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA Rocquencourt;IMARA - LARA adr:;;;;;;France tel;work:+33 1 39 63 59 30 tel;fax:+33 1 39 63 54 91 tel;cell:+33 6 76 56 25 96 url:http://www.lara.prd.fr version:2.1 end:vcard --------------050600040809000307020602 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 --------------050600040809000307020602-- From mext-bounces@ietf.org Mon Dec 1 02:33: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 6D4403A69D3; Mon, 1 Dec 2008 02:33:42 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 386D73A6847; Mon, 1 Dec 2008 02:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, GUARANTEED_100_PERCENT=0.012] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYeJ8LTkcu4h; Mon, 1 Dec 2008 02:33:40 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 201E93A63EC; Mon, 1 Dec 2008 02:33:39 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1L765n-0007sQ-CN; Mon, 01 Dec 2008 21:33:29 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Mon, 01 Dec 2008 21:33:15 +1100 From: Hesham Soliman To: Colin Perkins Message-ID: Thread-Topic: tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt Thread-Index: AclToDehY9f7D5O2B0SDZCHZLI7C0g== In-Reply-To: <5B953275-471A-40FF-B923-EB697AA96CA8@csperkins.org> Mime-version: 1.0 Cc: TSV Dir , ietf@ietf.org, "mext@ietf.org" Subject: Re: [MEXT] tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Thanks Colin, I agree with your rationale but I wonder if we need to support every broken device out there. In any case, if we have to, I prefer to require encryption than to add the XORED address option. I'd like to hear what people in MEXT think about this, comments from MEXT? Hesham On 1/12/08 9:13 PM, "Colin Perkins" wrote: > On 1 Dec 2008, at 09:00, Hesham Soliman wrote: >>>> => Well, I'm not sure how a NAT can do that. You mean the NAT will >>>> parse the binding update message deep inside the IPv6 extension >>>> header in the inner IP packet? This is where the original address >>>> is preserved. To do that, a NAT would have to understand the >>>> various MIPv6 options, and if it did, it would know not to do >>>> that :) The inner header is IPv6, so a NAT should not touch that. >>> >>> My understanding from the STUN work is that NATs have been observed >>> which rewrite any sequence of four aligned bytes matching the source >>> IP address, irrespective of its location within the packet (section >>> 15.2 of RFC 5389). >> >> => Sounds freightning! May be we need to mandate encryption and >> hope that no 4-byte sequence matched the IP address? What do they >> do with encrypted packets? How do they know they're encrypted? > > One would assume these broken devices will potentially corrupt > encrypted packets, the same as they will potentially corrupt any > other packet. Hiding the source address when it appears in the > payload (either by encryption, or using some trivial obfuscation as > does STUN) simply reduces the probability of such corruption so it's > no longer 100% guaranteed that the payload will be mangled. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 1 04:28: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 15E603A6A89; Mon, 1 Dec 2008 04:28:19 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B97B3A6879; Mon, 1 Dec 2008 02:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, GUARANTEED_100_PERCENT=0.012, 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 5BKPplv0LhUP; Mon, 1 Dec 2008 02:13:30 -0800 (PST) Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by core3.amsl.com (Postfix) with ESMTP id 44D823A63EC; Mon, 1 Dec 2008 02:13:30 -0800 (PST) Received: from starkperkins.demon.co.uk ([80.176.158.71]:60194 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1L75mO-00042I-La; Mon, 01 Dec 2008 10:13:24 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <5B953275-471A-40FF-B923-EB697AA96CA8@csperkins.org> From: Colin Perkins Date: Mon, 1 Dec 2008 10:13:21 +0000 To: Hesham Soliman X-Mailer: Apple Mail (2.753.1) X-Mailman-Approved-At: Mon, 01 Dec 2008 04:28:17 -0800 Cc: TSV Dir , ietf@ietf.org, "mext@ietf.org" Subject: Re: [MEXT] tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On 1 Dec 2008, at 09:00, Hesham Soliman wrote: >>> => Well, I'm not sure how a NAT can do that. You mean the NAT will >>> parse the binding update message deep inside the IPv6 extension >>> header in the inner IP packet? This is where the original address >>> is preserved. To do that, a NAT would have to understand the >>> various MIPv6 options, and if it did, it would know not to do >>> that :) The inner header is IPv6, so a NAT should not touch that. >> >> My understanding from the STUN work is that NATs have been observed >> which rewrite any sequence of four aligned bytes matching the source >> IP address, irrespective of its location within the packet (section >> 15.2 of RFC 5389). > > => Sounds freightning! May be we need to mandate encryption and > hope that no 4-byte sequence matched the IP address? What do they > do with encrypted packets? How do they know they're encrypted? One would assume these broken devices will potentially corrupt encrypted packets, the same as they will potentially corrupt any other packet. Hiding the source address when it appears in the payload (either by encryption, or using some trivial obfuscation as does STUN) simply reduces the probability of such corruption so it's no longer 100% guaranteed that the payload will be mangled. -- Colin Perkins http://csperkins.org/ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 1 04:28: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 AA0D128C107; Mon, 1 Dec 2008 04:28:19 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAD733A69D3; Mon, 1 Dec 2008 03:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.137 X-Spam-Level: X-Spam-Status: No, score=-6.137 tagged_above=-999 required=5 tests=[AWL=0.112, 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 Yd6d7r+aKzAM; Mon, 1 Dec 2008 03:06:40 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id AAE533A6969; Mon, 1 Dec 2008 03:06:40 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E8DE421163; Mon, 1 Dec 2008 12:06:35 +0100 (CET) X-AuditID: c1b4fb3c-ad0ccbb0000015b5-f8-4933c53b396e Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D5C522114D; Mon, 1 Dec 2008 12:06:35 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 12:06:35 +0100 Received: from [147.214.183.72] ([147.214.183.72]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 12:06:35 +0100 Message-ID: <4933C53B.5000303@ericsson.com> Date: Mon, 01 Dec 2008 12:06:35 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 01 Dec 2008 11:06:35.0181 (UTC) FILETIME=[DFD54DD0:01C953A4] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Mon, 01 Dec 2008 04:28:17 -0800 Cc: "mext@ietf.org" , ietf@ietf.org, Colin Perkins , TSV Dir Subject: Re: [MEXT] [tsv-dir] tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hesham Soliman skrev: > Thanks Colin, > = > I agree with your rationale but I wonder if we need to support every brok= en > device out there. In any case, if we have to, I prefer to require encrypt= ion > than to add the XORED address option. I'd like to hear what people in MEXT > think about this, comments from MEXT? > = I don't think we should go to far to correct this bug in implementations. My understanding is that this have been observed but is not a common behavior as these generic ALGs do break things randomly and horribly. I would only do something about if it has no minimal impact on the specification and any deployed implementations. Otherwise the fix is likely to cause more grief than the few devices that are broken. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 1 04:28: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 301B728C166; Mon, 1 Dec 2008 04:28:20 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6048F3A6A73; Mon, 1 Dec 2008 03:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.434, 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 U9V8YdafapMM; Mon, 1 Dec 2008 03:12:18 -0800 (PST) Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by core3.amsl.com (Postfix) with ESMTP id 5FFA63A6A4C; Mon, 1 Dec 2008 03:12:18 -0800 (PST) Received: from starkperkins.demon.co.uk ([80.176.158.71]:60740 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1L76hJ-00069O-H6; Mon, 01 Dec 2008 11:12:13 +0000 In-Reply-To: <4933C53B.5000303@ericsson.com> References: <4933C53B.5000303@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <0B298FEA-6D38-4FE5-8210-A382E1E7DFA3@csperkins.org> From: Colin Perkins Date: Mon, 1 Dec 2008 11:12:11 +0000 To: Magnus Westerlund X-Mailer: Apple Mail (2.753.1) X-Mailman-Approved-At: Mon, 01 Dec 2008 04:28:17 -0800 Cc: "mext@ietf.org" , TSV Dir , ietf@ietf.org Subject: Re: [MEXT] [tsv-dir] tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On 1 Dec 2008, at 11:06, Magnus Westerlund wrote: > Hesham Soliman skrev: >> Thanks Colin, >> >> I agree with your rationale but I wonder if we need to support >> every broken device out there. In any case, if we have to, I >> prefer to require encryption than to add the XORED address option. >> I'd like to hear what people in MEXT think about this, comments >> from MEXT? > > I don't think we should go to far to correct this bug in > implementations. My understanding is that this have been observed > but is > not a common behavior as these generic ALGs do break things > randomly and > horribly. I would only do something about if it has no minimal > impact on > the specification and any deployed implementations. Otherwise the > fix is > likely to cause more grief than the few devices that are broken. Right - the issue should be documented, and if there is a trivial fix it should be recommended, but this isn't a big issue. -- Colin Perkins http://csperkins.org/ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 1 04:28: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 A49A328C194; Mon, 1 Dec 2008 04:28:20 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325473A63EC for ; Mon, 1 Dec 2008 04:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 nobiHH6r8SQo for ; Mon, 1 Dec 2008 04:16:43 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id E06763A6847 for ; Mon, 1 Dec 2008 04:16:42 -0800 (PST) Received: from bombo (bombo.it.uc3m.es [163.117.139.125])by smtp03.uc3m.es (Postfix) with ESMTP id 0CF826AFB08; Mon, 1 Dec 2008 13:16:35 +0100 (CET) From: =?iso-8859-15?Q?Alberto_Garc=EDa?= To: Date: Mon, 1 Dec 2008 13:16:37 +0100 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclTrqbq6AW3MqrERIaBDOL+vunqFw== 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.2582 TC:1F TRN:86 TV:5.5.1026(16312.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Mailman-Approved-At: Mon, 01 Dec 2008 04:28:17 -0800 Subject: [MEXT] Review of draft-ietf-mext-nemo-mib-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1135693906==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1135693906== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01C953B7.0A67B8A0" This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C953B7.0A67B8A0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Hi, Marcelo Bagnulo has requested me to review the draft-ietf-mext-nemo-mib-03.txt from a MIB-expert point of view (sorry, I'm not a NEMO expert). Here are some comments: - Page 3, section 2.1, second paragraph. It is not clear what is the relationship of the first two sentences and the third. Needs some rewrite - Page 5. remove commented line in IMPORTS section -- Counter64 - page 16. This is a matter of preferences: I prefer the name of the table being included in the name of the objects that belong to the table. Most of the tables you define are according to this rule of thumb. Then, nemoBindingMrFlag should be nemoBindingCacheMrFlag. The same for nemoBindingMrMode. Then, it is easy to read nemoBindingCacheGroup OBJECT-GROUP OBJECTS { nemoBindingMrFlag, nemoBindingMrMode } The same consideration is raised for the objects of the nemoHaCounterTable, defined in page 28 and above. - Page 18. It is unclear why both { nemoMrEgressIfIndex, nemoMrEgressIfPriority } must be INDEX of the table. It seems nemoMrEgressIfIndex is enough. If not, explain in the DESCRIPTION of the Entry clause why you need nemoMrEgressIfPriority. - Page 18. In nemoMrEgressIfPriority, s/Unsigned32/ Unsigned32 (0..255) If finally the priority is included in the INDEX clause, then (RFC 4181, page 14) "It is acceptable to include zero in the range when it is semantically significant or when it is used as the index value for a unique row with special properties. Such usage SHOULD be clearly documented in the DESCRIPTION clause." - Page 19. why does nemoMrEgressIfDescription has read-write MAX-ACCESS ? I don't see the point of this. However, if there is, explain in the DESCRIPTION clause. Additionally, it is unclear which string is expected for this object: describe which kind of description should be included as a value for the objects. Finally, which default values or which criteria the agent will follow to set this description? Include both issues in the DESCRIPTION - Page 19. why does nemoMrEgressIfRoamHoldDownTime is read-write? Detail in DESCRIPTION Default values? What happens with the written information if the agent reboots? - Page 33. From the DESCRIPTION clause, it is impossible to see the difference among nemoHaStatsGroup and nemoHaGlobalStatsGroup. By the way, note some inconsistency in the names for the objects in the nemoHaStatsGroup (eg. nemoHaBUReque...) and the names in the nemoHaGlobalStatsGroup (eg. nemoHaBindingAck...). Use always "BU" and "BA" or "BindingUpdate" and "BindingAck"... - Page 40. Does the malicious configuration of the nemoMrEgressIfRoamHoldDownTime object may suppose any kind of vulnerability for the system? - Page 41. In the second line there are the names of 3 objects unconnected to the rest of the text. Regards, Alberto Garcia (alberto@it.uc3m.es) ------=_NextPart_000_0044_01C953B7.0A67B8A0 Content-Type: text/html; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable

Hi,

Marcelo = Bagnulo has requested me to review the draft-ietf-mext-nemo-mib-03.txt from a MIB-expert point of view (sorry, I’m not a NEMO expert). Here are = some comments:

 

- Page 3, = section 2.1, second paragraph. It is not clear what is the relationship of the first = two sentences and the third. Needs some rewrite

- Page 5. = remove commented line in IMPORTS section

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 -- Counter64

- page 16. = This is a matter of preferences: I prefer the name of the table being included in = the name of the objects that belong to the table. Most of the tables you = define are according to this rule of thumb.

Then, = nemoBindingMrFlag should be nemoBindingCacheMrFlag. The same for nemoBindingMrMode. Then, = it is easy to read

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 nemoBindingCacheGroup=A0=A0= =A0 OBJECT-GROUP

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0 OBJECTS {

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 = =A0=A0=A0=A0=A0=A0=A0=A0nemoBindingMrFlag,

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 = =A0=A0=A0=A0=A0=A0=A0=A0nemoBindingMrMode

=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0 }

 

The same = consideration is raised for the objects of the nemoHaCounterTable, defined in page 28 = and above.

 

- Page 18. It = is unclear why both { nemoMrEgressIfIndex, nemoMrEgressIfPriority } must be INDEX = of the table. It seems nemoMrEgressIfIndex is enough. If not, explain in the DESCRIPTION of the Entry clause why you need = nemoMrEgressIfPriority.

- Page = 18. In nemoMrEgressIfPriority, s/Unsigned32/ Unsigned32 (0..255) If finally the priority is included in the INDEX clause, then (RFC 4181, page 14) =

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 "It is acceptable to include zero in the

=A0=A0=A0=A0=A0=A0 range = when it is semantically significant or when it is used = as

=A0=A0=A0=A0=A0=A0 the = index value for a unique row with special properties.=A0 = Such

=A0=A0=A0=A0=A0=A0 usage = SHOULD be clearly documented in the DESCRIPTION = clause."

- Page 19. = why does nemoMrEgressIfDescription=A0=A0 has read-write MAX-ACCESS ? I don't see = the point of this. However, if there is, explain in the DESCRIPTION = clause.

Additionally, = it is unclear which string is expected for this object: describe which kind of description should be included as a value for the objects. =

Finally, = which default values or which criteria the agent will follow to set this description? = Include both issues in the DESCRIPTION

- Page 19. = why does nemoMrEgressIfRoamHoldDownTime is read-write? Detail in DESCRIPTION = Default values?

What happens = with the written information if the agent reboots?

 

- Page 33. = >From the DESCRIPTION clause, it is impossible to see the difference among nemoHaStatsGroup=A0=A0 and = nemoHaGlobalStatsGroup.

By the way, = note some inconsistency in the names for the objects in the nemoHaStatsGroup=A0=A0 = (eg. nemoHaBUReque...) and the names in the nemoHaGlobalStatsGroup=A0=A0 (eg. nemoHaBindingAck...). Use always "BU" and "BA" or "BindingUpdate" and = "BindingAck"...

 

- Page 40. = Does the malicious configuration of the nemoMrEgressIfRoamHoldDownTime object may suppose any kind of vulnerability for the = system?

 

- Page = 41. In the second = line there are the names of 3 objects unconnected to the rest of the = text.

 

Regards,<= /font>

Alberto = Garcia (alberto@it.uc3m.es)

 

------=_NextPart_000_0044_01C953B7.0A67B8A0-- --===============1135693906== 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 --===============1135693906==-- From mext-bounces@ietf.org Mon Dec 1 07:35: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 82D583A6AA6; Mon, 1 Dec 2008 07:35:36 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC9563A6AA6 for ; Mon, 1 Dec 2008 07:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqIRUXnXKB+d for ; Mon, 1 Dec 2008 07:35:32 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id CCC603A6A57 for ; Mon, 1 Dec 2008 07:35:31 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 70C192C0004DA; Mon, 1 Dec 2008 16:35:27 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLwo0CALmx-A; Mon, 1 Dec 2008 16:35:27 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 4356C2C000305; Mon, 1 Dec 2008 16:35:17 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 1 Dec 2008 16:35:16 +0100 Message-ID: <547F018265F92642B577B986577D671C4FBDBF@VENUS.office> In-Reply-To: <492FFCF2.7020400@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Comments on draft-ietf-mext-nemo-ro-automotive-req-01.txt Thread-Index: AclRY9JlFxEEz0gDQZGfHBwBv7vpFwCWZkPw From: "Roberto Baldessari" To: "Alexandru Petrescu" , "mext" Subject: Re: [MEXT] Comments on draft-ietf-mext-nemo-ro-automotive-req-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Dear Alex, Thank you very much for your comments. Please see inline. > > I think it would make sense to try to talk somewhere in the > document about IP-over-foo-technology. It may give a good > accompanying perspective to the architecture-uses-IPv6 > perspective currently described. It's very relevant to talk > about IPv6-over-802.11p in a document mentioning 802.11p and > IPv6 several times. > Good point. What needs to be specified is IPv6-over-C2CNET (see Figure 2). In fact ETSI TC ITS WG 3 is going to write the standard for the geonetworking protocol that provides non-IP geographic ad-hoc routing. In ETSI, a work item for the specification of IPv6-over-geonetworking (Title: Intelligent Transport System (ITS); Transport & Network; Integration of IPv6 and GeoNetworking) has already been assigned. I am the "rapporteur". The ETSI document should also be followed-up by an IETF I-D. The ETSI drafts need to be stable first. A stable ETSI draft is due by Nov 2009. But that activity does not affect this requirements draft. Regarding IPv6-over-11p, nothing needs to be specified as 11p does not amend changes to 802.11 as far as this is concerned. The same mechanism as for 802.11 apply (802.11+802.2+SNAP). > > Still in the Terminology section, right after V2I definition, > it would be good to add V2I2V definition (vehicle to infra to > vehicle), term used later in the document; I think the > scenario is very relevant. > You're right, the definition is missing. Among the authors we did not have 100% consensus on this term. The terms 'V2V' and 'V2I' are used in many automotive documents to distinguish whether or not the infrastructure is involved. So V2I2V can be seen as part of V2I, according to this criterion and therefore I think the term can be removed (in fact it only appears in the second part). We'll rediscuss this point. > Page 11: > > o according to the current availability of infrastructure > > connectivity, OBUs can use (at least) 2 types of globally routable > > IPv6 addresses: an IPv6 address configured using standard IPv6 > > stateless address configuration from Router Advertisements sent by > > RSUs connected to a network infrastructure and an IPv6 address > > configured from a prefix permanently allocated to the vehicle and > > delegated to the vehicle from a home network. The former globally > > routable IPv6 address is used as the NEMO Care-of Address (CoA) and > > the latter as the NEMO Home Address (HoA). > > For the second case, MR's Home Address derived from MNP. One > would make sure to clarify that this behaviour is not > standard NEMOv6, needs tweaks on the MR and on the HA, as > mentioned in section 5.3 "Home Address from MNP" of RFC 4887 > "Home Network Models". > Thanks for pointing this out. In fact, this may be an unwanted restriction due to misphrasing. IMO there is no particular reason related to the automotive use cases for which the HoA should be derived from the MNP. > > o for V2V communication, i.e. when no infrastructure is available, > > OBUs can use link-local addresses (default ones or with a C2C-CC > > specific prefix TBD). As described above, a portion of the VANET > > (geographically or topologically scoped) is presented to IPv6 as a > > single, link-local multicast link. Therefore the > link-local address > > can be used for multi-hop communications within the VANET; > > First, can there be an IPv6 link-local address with a prefix > other than > fe80? (as suggested above by "C2C-CC specific prefix TBD"). > Shouldn't > this be agreed by the IPv6-related WG - or maybe that's why > it's mentioned TBD? > Right. We tried to be as general as possible in these first versions of the draft. But it's unlikely that the automotive industry will really need a (additional) link-local unicast prefix different than fe80::/10. > Second, what is understood by 'multi-hop communications'? In > my understanding, 'multi-hop' is like Internet is multi-hop > and IP datagrams travel from hop to hop and have their TTL > decremented at each hop. In this sense, if the VANET is > presented to IPv6 a single link-local multicast link then it > is not multi-hop - the TTL is not decremented throughout this link. > Multi-hop in the draft is not necessarily referred to IP. Since this is an IETF draft, I see your point. If a non-IP protocol is used, then multi-hop communication should be called differently. We'll try to improve this. > Third, whereas it is indeed possible to have two OBUs (On-Board Units, > MRs) to talk to each other by using their link-local > addresses, it is not possible for the AUs (Applicatin Units, > LFNs) to talk to each other even if their respective OBUs > used their link-local addresses to talk to each other. In > this sense, I wouldn't say "Therefore the link-local address > can be used for multi-hop communications within the VANET". > See the previous observation. In the text, OBU to OBU (not involving AUs) via several non-IP hops is still called multi-hop. This generates confusion. We need to improve the text as to usage of terms. > Can I simply suggest: > > "Two OBUs can communicate directly through their respective > egress interfaces by using their IPv6 link-local addresses. > But their respective AUs can not take advantage of this possibility." > Well, correct observation but maybe not in the scope of the doc. Please note that we tried to restrict the scope of requirements to the ones related to Route Optimization for NEMO BS, therefore infrastructure-based. The automotive industry needs more than this, no doubt. But MEXT does not seem to be the right place for that. I was involved in the MANEMO discussion but in the end I agreed with the objections on scopes. Solutions for IPv6 AU-to-AU (note that I don't use MNN-to-MNN on purpose) infrastructure-less are needed. But this draft can not target them. We can still point this out in the draft and say that it's out of scope. > Nit: 'divided' is better than 'devided', page 10. > > Section 3.2.1 "System and Protocol Architecture" first > paragraph starting with "Vehicles are equipped with..." is > identical to first paragraph of page 7. Possibly subsequent > paragraphs are identical as well. I think it's redundant > text between the C2C-CC and ISO CALM sections. The reader > has already read the C2C-CC part, so now it would make sense > to simply state the differences. > > Similarly, Figures 1 and 3 are almost identical, with the > only difference being the presence of an optional interface > on OBU1. It's hard to spot that difference - better stress > it in the text. > Right, the next step will most likely be merging the sections (we need consensus from the involved bodies) [can't comment on CALM-related issues, sorry] > > 4.4. Vehicles Monitoring > > > > Vehicles monitoring services allow car manufacturers, car > garages and > > other trusted parties to remotely monitor vehicle > statistics. Data is > > collected by an AU and sent by the OBU to the service > center via the > > Internet. > > > > As an example, car manufacturers or garages offering this service > > could deploy NEMO Home Agents to serve thousands of cars. > > I agree with the application and example use case. > > However, I don't think NEMO protocol is adapted for this. > For example, in the above paragraph, was the intention to say > that NEMO Home Agents will receive monitored data from the > thousands of cars? That's what is implied by the text. > > The NEMO HA would only be involved in managing the mobility, > and not in monitoring the data. Another CN would be > receiving the monitored data, from OBU (and probably from AU > actually). HA would be there simply to deal with the > mobility of the OBU. > > I am not sure what is the intention of the above paragraph, > but I would clarify in order to avoid confusions of believing > HA monitors data. > Yes, that's what we meant. The HA is not necessarily the entity that offers the application service. We can clarify this. > > 4.5. Infotainment Applications > > > > TBD by ISO CALM > > > > 4.6. Navigation Services > > > > TBD by ISO CALM > > I suppose this is to be defined? > > > The requirements defined in this document refer to RO > between MR and > > CE (Correspondent Entity). According to the automotive > use cases, > > the CE can be: > > > > 1. Another vehicle, i.e. another automotive MR. > > I suggest call it RO between MR and MR. Or maybe RO between > OBU and OBU. But introducing the term CE is unnecessary. > Already addressed by Thierry. We followed RFC 4885. > > In cases 1 and 2, the CE is a newly deployed entity. > > It's not new, it's the MR, or the OBU. BEtter call it MR or > OBU, rather than CE. > Newly deployed means that we have more design freedom as compared to legacy IPv6 nodes. I think the distinction is important. You might want to suggest a different terminology. > Nit: 'occur' is better than 'occour'. > > Nit: 'known in advance to the MR' is better than > 'known in advanced to the MR' > > > 6.1. Req 1 - Separability > > > > An RO technique, including its establishment procedure, > MUST have the > > ability to be enabled on a per-flow basis according to > pre-defined > > policies. Policies criteria for the switching to RO > MUST at least > > include the end points' addresses and the MNP for which > RO is to be > > established. Policies MAY change dynamically. > > > > Before Req 1 I would suggest Req 0 'Reusability' to reuse an > existing protocol. > Please elaborate. > For req 1, I don't understand 'per-flow' - what's a flow? > Does it use the flow label in the IPv6 header? Or is it > another newly defined term? > Flow is used in so many RFCs without defining it. Even RFC 2460 defines Flow Labeling Capability without defining what a flow is (Sec 1). Did I maybe miss the RFC where the term flow is defined? > Nit: 'This requirement' is better than 'This requirements' > > Nit: 'unveil' or 'reveal' are both better than 'unveal'. > > > 6.6. Req 6 - Switching HA > > > > An RO technique MUST allow a MR to switch from one HA to > another one > > topologically distant from the first one. > > This sounds either as an incomplete requirement (subsequent > text doesn't > contribute to completeness, just to over-generalization) or > as a non-requirement at all. > > A requirement would be for MR to switch to another HA while > keeping its existing HoAs and CoAs. That is a requirement, > probably difficult to satisfy. I'd agree list it as > requirement, but only if it were qualified by that 'keep its > HoAs and CoAs'. Agreed. CALM needs to clarify. > > > [c2ccc-manifesto] > > "Car2Car Communication Consortium Manifesto", > > http://www.car-2-car.org/index.php?id=570 , May 2007. > > When I click on the link it says "TYP03 Error! The requested > page does not exist!" The C2C-CC website has just been redone. This is the new link: http://www.car-2-car.org/fileadmin/downloads/C2C-CC_manifesto_v1.1.pdf > > > [IEEE.802-11p-d3-0] > > "Draft Amendment to Standard for Information > Technology . > > Telecommunications and information exchange between > > systems . Local and Metropolitan networks . Specific > > requirements - Part 11: Wireless LAN Medium > Access Control > > (MAC) and Physical Layer (PHY) > specifications: Amendment > > 3: Wireless Access in Vehicular Environments (WAVE)", > > IEEE P802.11p/D1.0, February 2006. > > Where is this document? > IEEE drafts are only available for IEEE members. Best regards, Roberto _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 1 07:44: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 0EE5B28C0D7; Mon, 1 Dec 2008 07:44:17 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1624028C0D7 for ; Mon, 1 Dec 2008 07:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ow8bpDiX1lHS for ; Mon, 1 Dec 2008 07:44:15 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id 5AB4028C0D6 for ; Mon, 1 Dec 2008 07:44:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,695,1220220000"; d="vcf'?scan'208";a="17828069" Received: from dhcp-rocq-185.inria.fr ([128.93.62.185]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Dec 2008 16:44:09 +0100 Message-ID: <49340647.6020601@inria.fr> Date: Mon, 01 Dec 2008 16:44:07 +0100 From: Thierry Ernst Organization: INRIA User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: mext References: <492FDBF8.9010203@gmail.com> <492FDF16.7020708@it.uc3m.es> <492FEC16.1020502@gmail.com> <492FF89F.8030304@it.uc3m.es> <49300187.1080409@inria.fr> <49301CAF.90205@gmail.com> In-Reply-To: <49301CAF.90205@gmail.com> Content-Type: multipart/mixed; boundary="------------070602090706030207090402" Subject: Re: [MEXT] Mobile IPv6 for car-to-car communications X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------070602090706030207090402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Alexandru Petrescu wrote: > Hi Thierry, > > Thierry Ernst wrote: >> marcelo bagnulo braun wrote: >>> Alexandru Petrescu escribió: >>>> marcelo bagnulo braun wrote: >>>>> Alex, >>>>> >>>>> Alexandru Petrescu escribió: >>>>>> MEXTers, >>>>>> >>>>>> Let's first make one thing straight about >>>>>> draft-ietf-mext-nemo-ro-automotive-req-01.txt. >>>>>> >>>>>> Are the requirements written such as the RO vehicular design >>>>>> uses Correspondent Routers as mentioned in >>>>>> draft-bernardos-mext-nemo-ro-cr-00 and in >>>>>> draft-wakikawa-mext-cr-consideration-0? >>>>> >>>>> well a requirement doc should be neutral w.r.t. the solution >>>> >>>> I fully agree, but it does not seem the case with this requirements >>>> document. It assumes a Correspondent Router. >> The document is using the established NEMO Terminology (RFC 4885) and >> CR is corresponding to section 2.9. Correspondent Router (CR) . . >> . . . . . . . . . . . . . . 7 of RFC 4885. > > Well yes, but the term CR isn't used neither by Mobile IPv6 nor by its > extension NEMOv6. We could of course define new terms informationally, > but sometimes it is good to shortcut many definitions by terms actually > used in implementations. CR is of course not used in Mobile IPv6 (it was defined after Mobile IPv6) nor in NEMO BS (RFC 3963 is not dealing with RO). On the other hand it is used in the RO problem scope and RO solution analysis documents, and in RO solutions. So it is used. (I remember how much you opposed with this term so let's not argue about this anymore. All of us have things we didn't agree upon but which were agreed by a higher number of people). > > We already have to talk OBU to mean MR - if we define CE or CR to be yet > another term for the same thing then it's maybe a lot... or depends on > how people get this altogether... just some thought. Actually, the car industry has difficulty to call an OBU a MR (or a MR an OBU). So, in this specific situation, a new term is needed. Currently, the term "ITS station" seems to take momentum. An "ITS station" is either a router, or a router and a set of hosts. The advantage of this new term is that the car industry does not need to refine the definition of OBU and the IETF folks don't have to refine the definition of MR. Things happen. > >> Actually, draft-ietf-mext-nemo-ro-automotive-req-01.txt is mostly >> using the term CE (Correspondent Entity) which is by nature neutral >> (could be fixed or mobile): in the automotive use-case we are dealing >> with scenarios where we really mean MR to MR communications which >> must be optimized; > > Well I agree, but in this particular car-to-car communication it is very > meaningful to just mean MR or OBU. The term Correspondent Router isn't > used by any protocol like NEMOv6 or Mobile IPv6. > >> and there are also other scenarios where we want to optimize >> communications between a MR and a nearby CN. > > YEs I agree. I agree that a scenario needing to optimize routes between > MR and CN in the fixed infrastructure needs Mobile IPv6 extensions. > >> There could be one solution for the two cases, or a common solution. > > I disagree in this case. I don't see the use of Mobile IPv6 for > car-to-car communications (without fixed infrastructure). It's like > forcing the use of the hammer even on small things, smaller than nails. I don't get it. Cars will be NEMO-enabled and when two cars talk together they will be in situations where they would do this over NEMO (cars not nearby) or they would need to skip NEMO (cars nearby). Both are RO situation; the solution may not be NEMO-like particularly in the second case but they will need to interoperate with NEMO (a decision to use the NEMO tunnel or not will be needed at the MR - if it doesn't use the tunnel to HA I call this RO from the point of view of NEMO). > >> For a specific MR-MR solution it doesn't make sense to use the term CR. > > I agree. MR-to-MR solution wouldn't mention CR. Thierry. > > Alex > > >> >> >> >>>> >>>>> In draft-bernardos, there is a RO correpsondetn entity, that >>>>> performs the RO fucntions in the CN side, which can be placed in >>>>> different device, including the CN itself, the HA or a new device, >>>>> like the CR. I think that it is importnat to differentiate the >>>>> fucntional entities that are required in any solutions and the >>>>> particular form and places that these fucntions are placed in the >>>>> different solutions >>>>> >>>> Extending the concept of RO correspondent entity, to a >>>> Correspondent Router and further to a Mobile Router is superfluous >>>> to me. If we need Mobile Router to Mobile Router communication we >>>> don't need to talk about Mobile Router being a Correspondent >>>> Router. It's simply Mobile Router to Mobile Router >>>> communication. >>> no, the correspondet router does not need to be mobile (like the CN >>> does not need to be mobile neither) >> Agree. >> >>> >>>> >>>>>> Along the same lines: is the RO-vehicular technique designed >>>>>> following these requirements supposed to use Mobile IPv6 >>>>>> extensions? Like extending BUs/BAcks? Or can it use some other >>>>>> existing protocol as basis? >>>>>> >>>>> well, we are in mext, so we work on mip6 >>>> >>>> I don't think Mobile IPv6 is well adapted for car-to-car >>>> communications, without fixed infrastructure. >> One has to understand that cars may be once in an infrastructure-less >> situation and once in an infrastructure-based situation and they >> also must be reachable at a permanent address (therefore IPv6 and >> NEMO). ITS architectures are designed in a way both are supported >> (so, there could be different solutions but they have to co-exist in >> a single architecture). >> >>>> >>> ok, so i suggest you to go an propose your ideas in the wg that has >>> a protocol that according to you is well suited for car to car >>> communication, cause in this wg, we usually work on mip6 :-) >>> >>> regards, marcelo >>> >>>> Mobile IPv6 has many topological assumptions (a fixed HA, an often >>>> fixed CN) that make it difficult to use in a car-to-car >>>> communications. >>>> >>>> I believe car-to-car communications are a significant departure >>>> from Mobile IPv6. >>>> >>>> We can achieve car-to-car communications by using Mobile Router to >>>> Mobile Router communications by their egress interfaces and without >>>> using Mobile IPv6. >>>> >>>> If it is believed that Mobile IPv6 should be modified in order to >>>> achieve car-to-car communications then I fully disagree. >> >> Alex has a point indeed, but may be not the background. Car-to-Car >> communication would both need an NEMO-type of solution (with HA, CoA, >> etc - note that I avoided to use Mobile IPv6 because we need to >> support in-vehicle networks) which is optimized for car-to-car >> communications and an MANET-type of solution where there is no HA. >> The first has to be dealt with MEXT, the second possibly with Autoconf. >> >> Thierry >> >> >> >> >> > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ --------------070602090706030207090402 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA Rocquencourt;IMARA - LARA adr:;;;;;;France tel;work:+33 1 39 63 59 30 tel;fax:+33 1 39 63 54 91 tel;cell:+33 6 76 56 25 96 url:http://www.lara.prd.fr version:2.1 end:vcard --------------070602090706030207090402 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 --------------070602090706030207090402-- From li.demirtas@akcansa.com.tr Mon Dec 1 10:08:56 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CB1928C0F2 for ; Mon, 1 Dec 2008 10:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.011 X-Spam-Level: X-Spam-Status: No, score=-24.011 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_ALMOST_IP=5.417, FH_HOST_ALMOST_IP=1.889, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsA5rRxtnFd2 for ; Mon, 1 Dec 2008 10:08:56 -0800 (PST) Received: from dyn-170-236-16.myactv.net (dyn-170-236-16.myactv.net [24.170.236.16]) by core3.amsl.com (Postfix) with SMTP id D3DC828C0F0 for ; Mon, 1 Dec 2008 10:08:53 -0800 (PST) To: Subject: whoa! Great tool, man! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081201180854.D3DC828C0F0@core3.amsl.com> Date: Mon, 1 Dec 2008 10:08:53 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mext-bounces@ietf.org Mon Dec 1 11:29: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 2663C28C0E2; Mon, 1 Dec 2008 11:29:42 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C096B28C0E2 for ; Mon, 1 Dec 2008 11:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 0W9TWhL6GmQV for ; Mon, 1 Dec 2008 11:29:39 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id BD5F43A6B25 for ; Mon, 1 Dec 2008 11:29:38 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1228159773!5879411!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16110 invoked from network); 1 Dec 2008 19:29:34 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 1 Dec 2008 19:29:34 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mB1JTXaY010864; Mon, 1 Dec 2008 12:29:33 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id mB1JTXwH006706; Mon, 1 Dec 2008 13:29:33 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.87]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id mB1JTWSk006691; Mon, 1 Dec 2008 13:29:32 -0600 (CST) Message-ID: <49343B1B.8080707@gmail.com> Date: Mon, 01 Dec 2008 20:29:31 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Roberto Baldessari References: <547F018265F92642B577B986577D671C4FBDBF@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C4FBDBF@VENUS.office> X-Antivirus: avast! (VPS 081130-0, 30/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext Subject: Re: [MEXT] Comments on draft-ietf-mext-nemo-ro-automotive-req-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Dear Roberto, Thank you for the email. See below a few further comments. The parts = I've silently snipped are ok with me. Roberto Baldessari wrote: >> I think it would make sense to try to talk somewhere in the = >> document about IP-over-foo-technology. It may give a good = >> accompanying perspective to the architecture-uses-IPv6 perspective >> currently described. It's very relevant to talk about = >> IPv6-over-802.11p in a document mentioning 802.11p and IPv6 several >> times. > = > Good point. What needs to be specified is IPv6-over-C2CNET (see = > Figure 2). In fact ETSI TC ITS WG 3 is going to write the standard = > for the geonetworking protocol that provides non-IP geographic ad-hoc > routing. In ETSI, a work item for the specification of = > IPv6-over-geonetworking (Title: Intelligent Transport System (ITS); = > Transport & Network; Integration of IPv6 and GeoNetworking) has = > already been assigned. I am the "rapporteur". The ETSI document = > should also be followed-up by an IETF I-D. The ETSI drafts need to be > stable first. A stable ETSI draft is due by Nov 2009. But that = > activity does not affect this requirements draft. > = > Regarding IPv6-over-11p, nothing needs to be specified as 11p does = > not amend changes to 802.11 as far as this is concerned. The same = > mechanism as for 802.11 apply (802.11+802.2+SNAP). It is good to note the same IPv6 mechanism for 802.11 (802.11+802.2+SNAP) applies to IPv6 over 802.11p. I think this assumption is worth noting in the draft. Yet I have some doubts about the use of ND over 802.11p. One reason of my doubts is because the 802.11p draft I can access is not the latest - maybe things changed. I'm using "IEEE Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE)=97Networking Services" 20 IEEE Std 1609.3=99-2007 20 April 2007. I'm not even sure whether that's what we mean by "802.11p". This document has explicit assumptions on the use of IPv6. Among others, for example, section 4.5 "IPv6 Neighbor Cache" makes explicit assumptions about how the NC is filled with addresses. It is stated, for example : "... so alternate methods for generating the Neighbor Cache are defined. Note that neighbor discovery is not precluded in cases where it might be needed." It would probably be appropriate for a MEXT method achieving direct paths ("RO"?) between two vehicular MRs without infrastructure - to say that "if ND is needed with these P1609.3 systems, ND is used in this and that way". You may wonder why I'm talking ND here. I do so at least because Mobile IPv6 and NEMOv6 do talk ND at some point. So this could be pertinent. >> Still in the Terminology section, right after V2I definition, it = >> would be good to add V2I2V definition (vehicle to infra to = >> vehicle), term used later in the document; I think the scenario is >> very relevant. >> = > = > You're right, the definition is missing. Among the authors we did not > have 100% consensus on this term. The terms 'V2V' and 'V2I' are used > in many automotive documents to distinguish whether or not the = > infrastructure is involved. So V2I2V can be seen as part of V2I, = > according to this criterion and therefore I think the term can be = > removed (in fact it only appears in the second part). We'll rediscuss > this point. Ah I see... the point of V2I2V being actually two times a V2I makes sense to me. This explanation could be added when the term V2I2V is mentioned first. Or it could be discussed further. >> Page 11: >>> o according to the current availability of infrastructure = >>> connectivity, OBUs can use (at least) 2 types of globally = >>> routable IPv6 addresses: an IPv6 address configured using = >>> standard IPv6 stateless address configuration from Router = >>> Advertisements sent by RSUs connected to a network infrastructure >>> and an IPv6 address configured from a prefix permanently = >>> allocated to the vehicle and delegated to the vehicle from a home >>> network. The former globally routable IPv6 address is used as = >>> the NEMO Care-of Address (CoA) and the latter as the NEMO Home = >>> Address (HoA). >> For the second case, MR's Home Address derived from MNP. One would >> make sure to clarify that this behaviour is not standard NEMOv6, = >> needs tweaks on the MR and on the HA, as mentioned in section 5.3 = >> "Home Address from MNP" of RFC 4887 "Home Network Models". >> = > = > Thanks for pointing this out. In fact, this may be an unwanted = > restriction due to misphrasing. IMO there is no particular reason = > related to the automotive use cases for which the HoA should be = > derived from the MNP. I agree. >>> o for V2V communication, i.e. when no infrastructure is = >>> available, OBUs can use link-local addresses (default ones or = >>> with a C2C-CC specific prefix TBD). As described above, a = >>> portion of the VANET (geographically or topologically scoped) is >>> presented to IPv6 as a single, link-local multicast link. = >>> Therefore the >> link-local address >>> can be used for multi-hop communications within the VANET; >> First, can there be an IPv6 link-local address with a prefix other >> than fe80? (as suggested above by "C2C-CC specific prefix TBD"). >> Shouldn't this be agreed by the IPv6-related WG - or maybe that's >> why it's mentioned TBD? >> = > = > Right. We tried to be as general as possible in these first versions > of the draft. But it's unlikely that the automotive industry will = > really need a (additional) link-local unicast prefix different than = > fe80::/10. I agree. >> Second, what is understood by 'multi-hop communications'? In my = >> understanding, 'multi-hop' is like Internet is multi-hop and IP = >> datagrams travel from hop to hop and have their TTL decremented at >> each hop. In this sense, if the VANET is presented to IPv6 a = >> single link-local multicast link then it is not multi-hop - the TTL >> is not decremented throughout this link. >> = > = > Multi-hop in the draft is not necessarily referred to IP. Since this > is an IETF draft, I see your point. If a non-IP protocol is used, = > then multi-hop communication should be called differently. We'll try > to improve this. I agree, thank you. Maybe describing link-layer multi-hops as not decrementing the Hop Limit field in the IPv6 base header (akin to IPv4 = TTL) could do. Anyways, defining link behaviour in terms of what = happens to Hop Limit is easily understood often, I think. >> Third, whereas it is indeed possible to have two OBUs (On-Board = >> Units, MRs) to talk to each other by using their link-local = >> addresses, it is not possible for the AUs (Applicatin Units, LFNs) >> to talk to each other even if their respective OBUs used their = >> link-local addresses to talk to each other. In this sense, I = >> wouldn't say "Therefore the link-local address can be used for = >> multi-hop communications within the VANET". >> = > = > See the previous observation. In the text, OBU to OBU (not involving > AUs) via several non-IP hops is still called multi-hop. This = > generates confusion. We need to improve the text as to usage of = > terms. Thanks, I agree. >> Can I simply suggest: >> = >> "Two OBUs can communicate directly through their respective egress >> interfaces by using their IPv6 link-local addresses. But their = >> respective AUs can not take advantage of this possibility." >> = > = > Well, correct observation but maybe not in the scope of the doc. = > Please note that we tried to restrict the scope of requirements to = > the ones related to Route Optimization for NEMO BS, therefore = > infrastructure-based. The automotive industry needs more than this, = > no doubt. But MEXT does not seem to be the right place for that. I = > was involved in the MANEMO discussion but in the end I agreed with = > the objections on scopes. > = > Solutions for IPv6 AU-to-AU (note that I don't use MNN-to-MNN on = > purpose) infrastructure-less are needed. But this draft can not = > target them. We can still point this out in the draft and say that = > it's out of scope. I see what you mean, as a scoping problem. Explicitly leaving vehicular MR-to-MR infrastructure-less RO out of scope of this document would be = then fine with me too. >>> In cases 1 and 2, the CE is a newly deployed entity. >> = >> It's not new, it's the MR, or the OBU. BEtter call it MR or OBU, = >> rather than CE. >> = > = > Newly deployed means that we have more design freedom as compared to > legacy IPv6 nodes. I think the distinction is important. You might = > want to suggest a different terminology. Whereas I agree with you a CE may be new compared to an = IPv6-but-non-NEMOv6 Mobile Router, I don't agree CE is new compared to a = NEMOv6 Mobile Router. It's difficult to understand what new means here. CE is a new term indeed, but it designates an existing MR plus RO _sometimes_. >>> 6.1. Req 1 - Separability >>> = >>> An RO technique, including its establishment procedure, MUST have >>> the ability to be enabled on a per-flow basis according to = >>> pre-defined policies. Policies criteria for the switching to RO = >>> MUST at least include the end points' addresses and the MNP for = >>> which RO is to be established. Policies MAY change dynamically. >>> = >> Before Req 1 I would suggest Req 0 'Reusability' to reuse an = >> existing protocol. >> = > = > Please elaborate. Thanks for asking. I meant to say something about the necessity to re-use an existing protocol. This could be Mobile IPv6 and/or ND. NEMOv6 is not a protocol per se, but an extension to Mobile IPv6. In this sense, the requirements would better be better scoped, (1) eliminating the possibility of designing, for example, an UDP-based message exchange for security credentials (maybe IKE) to achieve optimal paths. And also eliminating any new exchange designed out of nothing, like for example an xml-based http exchange for achieving same goals. >> For req 1, I don't understand 'per-flow' - what's a flow? Does it = >> use the flow label in the IPv6 header? Or is it another newly = >> defined term? >> = > = > Flow is used in so many RFCs without defining it. Even RFC 2460 = > defines Flow Labeling Capability without defining what a flow is (Sec > 1). Did I maybe miss the RFC where the term flow is defined? I think flow has many different co-notations and the only formally implemented is the Flow Label. This draft's per-flow behaviour doesn't assume flow labels because, for example, it says at some point: > The IP version 6 is the version considered for IP types of flows. [datagr= ams?] and later on > a particular IPv6 flow [a flow label?] I'm not trying to confuse anybody, but it is confusing to me. Or maybe = some readers can easily disambiguate these occurences. >>> [c2ccc-manifesto] "Car2Car Communication Consortium Manifesto", = >>> http://www.car-2-car.org/index.php?id=3D570 , May 2007. >> When I click on the link it says "TYP03 Error! The requested page = >> does not exist!" > = > = > The C2C-CC website has just been redone. This is the new link: = > http://www.car-2-car.org/fileadmin/downloads/C2C-CC_manifesto_v1.1.pdf 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 Mon Dec 1 11:57:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1A73A687D; Mon, 1 Dec 2008 11:57:51 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E349C3A687D for ; Mon, 1 Dec 2008 11:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.71 X-Spam-Level: X-Spam-Status: No, score=-5.71 tagged_above=-999 required=5 tests=[AWL=0.889, 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 8Sj08YQSMc43 for ; Mon, 1 Dec 2008 11:57:49 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 13BC43A6808 for ; Mon, 1 Dec 2008 11:57:49 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1228161464!8175324!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 9162 invoked from network); 1 Dec 2008 19:57:45 -0000 Received: from unknown (HELO motgate4.mot.com) (136.182.1.14) by server-11.tower-153.messagelabs.com with SMTP; 1 Dec 2008 19:57:45 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id mB1JvijJ012000; Mon, 1 Dec 2008 12:57:44 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id mB1JviPn024593; Mon, 1 Dec 2008 13:57:44 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.87]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id mB1JvghS024578; Mon, 1 Dec 2008 13:57:43 -0600 (CST) Message-ID: <493441B6.5030703@gmail.com> Date: Mon, 01 Dec 2008 20:57:42 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Thierry Ernst References: <492FDBF8.9010203@gmail.com> <492FDF16.7020708@it.uc3m.es> <492FEC16.1020502@gmail.com> <492FF89F.8030304@it.uc3m.es> <49300187.1080409@inria.fr> <49301CAF.90205@gmail.com> <49340647.6020601@inria.fr> In-Reply-To: <49340647.6020601@inria.fr> X-Antivirus: avast! (VPS 081130-0, 30/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext Subject: Re: [MEXT] Mobile IPv6 for car-to-car communications X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Thierry, Thierry Ernst wrote: [...] [...] > Actually, the car industry has difficulty to call an OBU a MR (or a > MR an OBU). So, in this specific situation, a new term is needed. > Currently, the term "ITS station" seems to take momentum. An "ITS > station" is either a router, or a router and a set of hosts. The > advantage of this new term is that the car industry does not need to > refine the definition of OBU and the IETF folks don't have to refine > the definition of MR. Things happen. If 'ITS station' makes sense an dhelp in building relevant IP requirements then I agree with it. [...] >> I disagree in this case. I don't see the use of Mobile IPv6 for >> car-to-car communications (without fixed infrastructure). It's >> like forcing the use of the hammer even on small things, smaller >> than nails. > > I don't get it. Cars will be NEMO-enabled and when two cars talk > together they will be in situations where they would do this over > NEMO (cars not nearby) or they would need to skip NEMO (cars nearby). > Both are RO situation; the solution may not be NEMO-like particularly > in the second case but they will need to interoperate with NEMO (a > decision to use the NEMO tunnel or not will be needed at the MR - if > it doesn't use the tunnel to HA I call this RO from the point of view > of NEMO). YEs, have MR-to-MR communication would need to interoperate with NEMO implementations when infrastructure is in the picture. There's probably an interoperation issue, make sure the MR-to-MR mechanism works ok with NEMO, I agree. But I also think there may be vehicles which rarely if ever connect to infrastructure, but their main task would be car-to-car communication, in which case a NEMO type of RO extension for infrastructure wouldn't be needed in these cases. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 1 12:46: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 29DC83A69AF; Mon, 1 Dec 2008 12:46:04 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21F8E3A69AF for ; Mon, 1 Dec 2008 12:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, 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 4-C74foroSXV for ; Mon, 1 Dec 2008 12:46:02 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 4D01E3A6937 for ; Mon, 1 Dec 2008 12:46:02 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id mB1Kjrdo018530; Mon, 1 Dec 2008 14:45:58 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 14:45:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 15:45:51 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AclT9cv5JA+1h7g/RR26VTnK4EnOsA== From: "Desire Oulai" To: X-OriginalArrivalTime: 01 Dec 2008 20:45:53.0671 (UTC) FILETIME=[CD81F970:01C953F5] Subject: [MEXT] (no subject) X-BeenThere: mext@ietf.org X-Mailman-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="===============0259185119==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0259185119== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C953F5.CC2148DD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C953F5.CC2148DD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ahmad, All, The Binding revocation draft does not mention revocation related to NEMO. If used as is, the BRI will revoke the binding between the MR's HoA and CoA. I think it's woth adding another level of revocation: revocation of Mobile Network Prefixes. A HA may decide to stop forwarding data to the CoA for certain MNPs and BR could be used for that. Here is a proposed text for a new section: "In case of NEMO protocol, the HA follows the same procedure as MIPv6 if the goal is to revoke the binding between the Mobile Router's HoA and CoA. It is also possible to have finer granularity of revocation targeting the Mobile Network Prefixes assigned to the Mobile Router. In this case, the HA sends a BRI message including one or more MNP options with the A bit set and the Revocation Trigger set to a proper value, e.g. Administrative Reasons. When receiving this BRI, the MR deletes the MNP(s) from the Prefix Information field in the Binding Update List and responds with a BRA message. The BRA MUST include the MNP(s) contained in the BRI." Also, Mobile network Prefix should be addes as valid option in section "6.2. Binding Revocation Acknowledgement Message". BR Desire ------_=_NextPart_001_01C953F5.CC2148DD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ahmad, = All,

 The Binding = revocation draft does not mention revocation related to NEMO. If = used as is, the BRI will revoke the binding between the MR's HoA and = CoA. I think it's woth adding another level of revocation: revocation of = Mobile Network Prefixes. A HA may decide to stop forwarding data to the = CoA for certain MNPs and BR could be used for that. Here is a proposed = text for a new section:

"In case of = NEMO protocol, the HA follows the same procedure as MIPv6 if the goal is = to revoke the binding between the Mobile Router's HoA and CoA. It is = also possible to have finer granularity of revocation targeting the = Mobile Network Prefixes assigned to the Mobile Router. In this case, the = HA sends a BRI message including one or more MNP options with the A bit = set and the Revocation Trigger set to a proper value, e.g. = Administrative Reasons. When receiving this BRI, the MR deletes the = MNP(s) from the Prefix Information field in the Binding Update List and = responds with a BRA message. The BRA MUST include the MNP(s) contained = in the BRI."

Also, Mobile = network Prefix should be addes as valid option in section = "6.2. Binding Revocation = Acknowledgement Message".

BR
Desire

------_=_NextPart_001_01C953F5.CC2148DD-- --===============0259185119== 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 --===============0259185119==-- From mext-bounces@ietf.org Mon Dec 1 15:51:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C830F3A6998; Mon, 1 Dec 2008 15:51:54 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 850623A6998 for ; Mon, 1 Dec 2008 15:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.964 X-Spam-Level: X-Spam-Status: No, score=-0.964 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmQGYz2ARriJ for ; Mon, 1 Dec 2008 15:51:52 -0800 (PST) Received: from n1.bullet.mail.gq1.yahoo.com (n1.bullet.mail.gq1.yahoo.com [67.195.9.84]) by core3.amsl.com (Postfix) with SMTP id 9F6743A6991 for ; Mon, 1 Dec 2008 15:51:52 -0800 (PST) Received: from [67.195.9.83] by n1.bullet.mail.gq1.yahoo.com with NNFMP; 01 Dec 2008 23:51:49 -0000 Received: from [67.195.9.105] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 01 Dec 2008 23:51:48 -0000 Received: from [127.0.0.1] by omp109.mail.gq1.yahoo.com with NNFMP; 01 Dec 2008 23:51:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 983368.52418.bm@omp109.mail.gq1.yahoo.com Received: (qmail 45511 invoked by uid 60001); 1 Dec 2008 23:51:48 -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=U0F55rul9qyKxhyrJk7kUNYlh08tKSiVMmGj7djRRXoln0emhohiHIr736SDWVevmfCJpf5gHXhZ/I0l0ASTw7KDJlWKoJurfn46cObuUed5C2XNPN31XE4nBO/BnLtoW5vssC3QImExSiOfBH+Q2C1TeODFhbaNOgLKV9hVp50=; X-YMail-OSG: dAhzRwUVM1l1gu0S7z9lf1W3cUOL_ZhtrC1_tj17LMx.WhKOvwSTV4Pa8WCVIgH0GjLp3D_Wdxt3teJD2OK_Kz1yyVaehwtsW9r6hVeOfGX3svDB_Jx0RGBKudLACNvMMQAu1bbfsju5LdJISftSHr5NxHarzpXOGMU2oBYnEvKBEAhgcssHLQfYVZ0W Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Mon, 01 Dec 2008 15:51:48 PST X-Mailer: YahooMailRC/1155.32 YahooMailWebService/0.7.260.1 Date: Mon, 1 Dec 2008 15:51:48 -0800 (PST) From: Behcet Sarikaya To: mext@ietf.org MIME-Version: 1.0 Message-ID: <398528.45451.qm@web111413.mail.gq1.yahoo.com> Subject: [MEXT] Fw: Comments on draft-ietf-mext-flow-binding-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0419136477==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0419136477== Content-Type: multipart/alternative; boundary="0-1904991292-1228175508=:45451" --0-1904991292-1228175508=:45451 Content-Type: text/plain; charset=us-ascii ----- Forwarded Message ---- From: Behcet Sarikaya To: Hesham Soliman Sent: Monday, December 1, 2008 5:51:00 PM Subject: Re: [MEXT] Comments on draft-ietf-mext-flow-binding-00 Hi Hesham, Maybe somebody already reported this: I found that on p.7 Figure 1, FID which is an 8-bit field is shown twice. I don't think two FIDs are needed in each flow identification option. Regards, Behcet ________________________________ From: Romain KUNTZ To: mext Sent: Thursday, November 27, 2008 4:44:45 AM Subject: Re: [MEXT] Comments on draft-ietf-mext-flow-binding-00 Hello, On 2008/11/25, at 17:41, Giaretta, Gerardo wrote: >> If we make the assumption that refreshing all is more common that removing >> all (fair assumption I think) then we can try to optimise for that. >> > > I think it is a fair assumption. I think the following should be the principles to implement: > > - add, replace, remove flow bindings require FID option in the BU > - a BU with BID options is used to update the binding in terms of CoA and lifetime, but does not change the flow binding. Flow bindings which correspond to a specific BID are not changed in this case. > - The lifetime of the flow binding is tied to the lifetime of the CoA binding. This implies that a flow binding is removed only if there is a remove action via FID option from the MN, if the respective BID is removed or the respective BID expires > - a BU without any BID option overwrites all bindings including the flow binding > > The latter is used for example when the MN wants to go through MCoA mode to single CoA mode. > > Does it make sense? I'm in favor with what Gerardo is proposing. This is also what I had in mind. Regards, romain _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-1904991292-1228175508=:45451 Content-Type: text/html; charset=us-ascii


----- Forwarded Message ----
From: Behcet Sarikaya <behcetsarikaya@yahoo.com>
To: Hesham Soliman <Hesham@elevatemobile.com>
Sent: Monday, December 1, 2008 5:51:00 PM
Subject: Re: [MEXT] Comments on draft-ietf-mext-flow-binding-00

Hi Hesham,
  Maybe somebody already reported this: I found that on p.7 Figure 1, FID which is an 8-bit field is shown twice. I don't think two FIDs are needed in each flow identification option.

Regards,

Behcet

From: Romain KUNTZ <kuntz@lsiit.u-strasbg.fr>
To: mext <mext@ietf.org>
Sent: Thursday, November 27, 2008 4:44:45 AM
Subject: Re: [MEXT] Comments on draft-ietf-mext-flow-binding-00

Hello,

On 2008/11/25, at 17:41, Giaretta, Gerardo wrote:
>> If we make the assumption that refreshing all is more common that removing
>> all (fair assumption I think) then we can try to optimise for that.
>>
>
> I think it is a fair assumption. I think the following should be the principles to implement:
>
> - add, replace, remove flow bindings require FID option in the BU
> - a BU with BID options is used to update the binding in terms of CoA and lifetime, but does not change the flow binding. Flow bindings which correspond to a specific BID are not changed in this case.
> - The lifetime of the flow binding is tied to the lifetime of the CoA binding. This implies that a flow binding is removed only if there is a remove action via FID option from the MN, if the respective BID is removed or the respective BID expires
> - a BU without any BID option overwrites all bindings including the flow binding
>
> The latter is used for example when the MN wants to go through MCoA mode to single CoA mode.
>
> Does it make sense?

I'm in favor with what Gerardo is proposing. This is also what I had in mind.

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


--0-1904991292-1228175508=:45451-- --===============0419136477== 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 --===============0419136477==-- From mext-bounces@ietf.org Mon Dec 1 19:22: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 D910D3A6ABB; Mon, 1 Dec 2008 19:22:45 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32A9A3A6ABB for ; Mon, 1 Dec 2008 19:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.762 X-Spam-Level: X-Spam-Status: No, score=-5.762 tagged_above=-999 required=5 tests=[AWL=0.837, 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 FskZggFUHHCx for ; Mon, 1 Dec 2008 19:22:44 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 01BA93A6938 for ; Mon, 1 Dec 2008 19:22:43 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mB23Mas05792; Tue, 2 Dec 2008 03:22:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 21:22:35 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Binding Revocation for IPv6 Mobility Supports NEMO usecase Thread-Index: AclT9cv5JA+1h7g/RR26VTnK4EnOsAANh5Dw References: From: "Ahmad Muhanna" To: "Desire Oulai" , Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase X-BeenThere: mext@ietf.org X-Mailman-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="===============1495782661==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1495782661== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9542D.39110C99" This is a multi-part message in MIME format. ------_=_NextPart_001_01C9542D.39110C99 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Desire, =20 Added a relative subject. =20 I guess the usecase is clear and it makes sense to me.=20 We can add some text similar to yours to capture this functionality under the HA and MN operations after the conclusion of the WGLC.. =20 BTW: Is there anyone who thinks that we should not add this usecase? Regards,=20 Ahmad=20 =20 ________________________________ From: Desire Oulai [mailto:desire.oulai@ericsson.com]=20 Sent: Monday, December 01, 2008 2:46 PM To: mext@ietf.org Cc: Muhanna, Ahmad (RICH1:2H10) Subject:=20 =09 =09 Hi Ahmad, All,=20 The Binding revocation draft does not mention revocation related to NEMO. If used as is, the BRI will revoke the binding between the MR's HoA and CoA. I think it's woth adding another level of revocation: revocation of Mobile Network Prefixes. A HA may decide to stop forwarding data to the CoA for certain MNPs and BR could be used for that. Here is a proposed text for a new section: "In case of NEMO protocol, the HA follows the same procedure as MIPv6 if the goal is to revoke the binding between the Mobile Router's HoA and CoA. It is also possible to have finer granularity of revocation targeting the Mobile Network Prefixes assigned to the Mobile Router. In this case, the HA sends a BRI message including one or more MNP options with the A bit set and the Revocation Trigger set to a proper value, e.g. Administrative Reasons. When receiving this BRI, the MR deletes the MNP(s) from the Prefix Information field in the Binding Update List and responds with a BRA message. The BRA MUST include the MNP(s) contained in the BRI." Also, Mobile network Prefix should be addes as valid option in section "6.2. Binding Revocation Acknowledgement Message". BR=20 Desire=20 ------_=_NextPart_001_01C9542D.39110C99 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi=20 Desire,
 
Added=20 a relative subject.
 
I=20 guess the usecase is clear and it makes sense to me. =
We can=20 add some text similar to yours to capture this functionality under the = HA and MN=20 operations after the conclusion of the WGLC..
 
BTW:=20 Is there anyone who thinks that we should not add this=20 usecase?

Regards, =
Ahmad

 

From: Desire Oulai=20 [mailto:desire.oulai@ericsson.com]
Sent: Monday, December = 01, 2008=20 2:46 PM
To: mext@ietf.org
Cc: Muhanna, Ahmad=20 (RICH1:2H10)
Subject:

Hi Ahmad, = All,

 The Binding=20 revocation draft does=20 not mention revocation related to NEMO. If used as is, the BRI will = revoke the=20 binding between the MR's HoA and CoA. I think it's woth adding another = level=20 of revocation: revocation of Mobile Network Prefixes. A HA may decide = to stop=20 forwarding data to the CoA for certain MNPs and BR could be used for = that.=20 Here is a proposed text for a new section:

"In case of NEMO = protocol, the HA=20 follows the same procedure as MIPv6 if the goal is to revoke the = binding=20 between the Mobile Router's HoA and CoA. It is also possible to have = finer=20 granularity of revocation targeting the Mobile Network Prefixes = assigned to=20 the Mobile Router. In this case, the HA sends a BRI message including = one or=20 more MNP options with the A bit set and the Revocation Trigger set to = a proper=20 value, e.g. Administrative Reasons. When receiving this BRI, the MR = deletes=20 the MNP(s) from the Prefix Information field in the Binding Update = List and=20 responds with a BRA message. The BRA MUST include the MNP(s) contained = in the=20 BRI."

Also, Mobile network = Prefix should=20 be addes as valid option in section "6.2.=20 Binding Revocation Acknowledgement Message".

BR =
Desire=20

------_=_NextPart_001_01C9542D.39110C99-- --===============1495782661== 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 --===============1495782661==-- From mext-bounces@ietf.org Tue Dec 2 04: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 DD2C53A68E1; Tue, 2 Dec 2008 04:30:53 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80FED3A69C0; Mon, 1 Dec 2008 06:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 JLrtyGB6AllM; Mon, 1 Dec 2008 06:13:58 -0800 (PST) Received: from mailer2.psc.edu (mailer2v6.psc.edu [IPv6:2001:5e8:2:42::6a]) by core3.amsl.com (Postfix) with ESMTP id 61F5328C0E6; Mon, 1 Dec 2008 06:13:44 -0800 (PST) Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer2.psc.edu (8.14.2/8.13.3) with ESMTP id mB1ED6id002871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Dec 2008 09:13:06 -0500 (EST) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.13.1) with ESMTP id mB1ED5xn023737; Mon, 1 Dec 2008 09:13:06 -0500 Date: Mon, 1 Dec 2008 09:13:05 -0500 (EST) From: Matt Mathis To: Hesham Soliman In-Reply-To: Message-ID: References: MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 02 Dec 2008 04:30:53 -0800 Cc: "mext@ietf.org" , ietf@ietf.org, Colin Perkins , TSV Dir Subject: Re: [MEXT] [tsv-dir] tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Mon, 1 Dec 2008, Hesham Soliman wrote: > >>> >>> => Well, I'm not sure how a NAT can do that. You mean the NAT will >>> parse the binding update message deep inside the IPv6 extension >>> header in the inner IP packet? This is where the original address >>> is preserved. To do that, a NAT would have to understand the >>> various MIPv6 options, and if it did, it would know not to do >>> that :) The inner header is IPv6, so a NAT should not touch that. >> >> My understanding from the STUN work is that NATs have been observed >> which rewrite any sequence of four aligned bytes matching the source >> IP address, irrespective of its location within the packet (section >> 15.2 of RFC 5389). > > => Sounds freightning! May be we need to mandate encryption and hope that no > 4-byte sequence matched the IP address? What do they do with encrypted > packets? How do they know they're encrypted? I'd really hate to have address 32.116.104.101 (" the").... Such devices can't possibly survive, can they? Aghast, --MM-- ------------------------------------------- Matt Mathis http://staff.psc.edu/mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 2 04:30:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6428428C0DC; Tue, 2 Dec 2008 04:30:54 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81AA13A69D7; Mon, 1 Dec 2008 06:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Crubpj0sTdfu; Mon, 1 Dec 2008 06:26:20 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id A51E83A67F6; Mon, 1 Dec 2008 06:26:20 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mB1EPXpW014363; Mon, 1 Dec 2008 08:26:09 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 16:25:50 +0200 Received: from esdhcp041160.research.nokia.com ([172.21.41.160]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 16:25:49 +0200 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: ietf@ietf.org Date: Mon, 1 Dec 2008 16:25:48 +0200 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200812011625.49412.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 01 Dec 2008 14:25:49.0888 (UTC) FILETIME=[B564D400:01C953C0] X-Nokia-AV: Clean X-Mailman-Approved-At: Tue, 02 Dec 2008 04:30:53 -0800 Cc: ext Matt Mathis , TSV Dir , "mext@ietf.org" , Colin Perkins Subject: Re: [MEXT] [tsv-dir] tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Monday 01 December 2008 16:13:05 ext Matt Mathis, you wrote: > On Mon, 1 Dec 2008, Hesham Soliman wrote: > >>> =3D> Well, I'm not sure how a NAT can do that. You mean the NAT will > >>> parse the binding update message deep inside the IPv6 extension > >>> header in the inner IP packet? This is where the original address > >>> is preserved. To do that, a NAT would have to understand the > >>> various MIPv6 options, and if it did, it would know not to do > >>> that :) The inner header is IPv6, so a NAT should not touch that. > >> > >> My understanding from the STUN work is that NATs have been observed > >> which rewrite any sequence of four aligned bytes matching the source > >> IP address, irrespective of its location within the packet (section > >> 15.2 of RFC 5389). > > > > =3D> Sounds freightning! May be we need to mandate encryption and hope = that > > no 4-byte sequence matched the IP address? What do they do with encrypt= ed > > packets? How do they know they're encrypted? > > I'd really hate to have address 32.116.104.101 (" the").... > Such devices can't possibly survive, can they? Depends what you need to survive... If you only do DNS and a few TCP-based protocols which the brain-damaged AL= G = would not affect, it might just work. We probably don't care about MIP not = passing through such abomination though. -- = R=E9mi Denis-Courmont Maemo Software, Nokia Devices R&D _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 2 06:29:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81ED3A6ABA; Tue, 2 Dec 2008 06:29:24 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3BBA3A6ABA for ; Tue, 2 Dec 2008 06:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mlz7536Q8jwO for ; Tue, 2 Dec 2008 06:29:22 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 623203A6A48 for ; Tue, 2 Dec 2008 06:29:22 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 15:29:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Dec 2008 15:29:10 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] BU and BA flag overlap between DSMIPv6 (draft-ietf-mext-nemo-v4traversal-06.txt) and Proxy MIPv6 (RFC 5213) thread-index: AclUildKI6yFBLDwSeW+fVqEJP3Ggg== From: To: X-OriginalArrivalTime: 02 Dec 2008 14:29:18.0547 (UTC) FILETIME=[5C2D6A30:01C9548A] Subject: [MEXT] BU and BA flag overlap between DSMIPv6 (draft-ietf-mext-nemo-v4traversal-06.txt) and Proxy MIPv6 (RFC 5213) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 everybody, I have noticed that in the extension to BU and BA messages proposed in DSMIPv6 (draft-ietf-mext-nemo-v4traversal-06.txt), the DSMIPv6-specific flag bits overlap the flag bits proposed in BU and BA message extensions defined in Proxy MIPv6 (RFC 5213). More specifically, in the extension to MIPv6 BU message proposed in DSMIPv6, the flag (F) is located in the same position of the flag (P) defined in BU extensions proposed in RFC 5213 (Proxy MIPv6). Similarly, the flag (T) of DSMIPv6 BA message is located in the same position of flag (P) of Proxy MIPv6 BA message. To make it easier to compare those messages, I reported the format of BU and BA messages proposed in Dual Stack MIPv6 and Proxy MIPv6 at the bottom of this e-mail. Has this overlapping been designed deliberately? In my opinion, these overlaps would generate incompatibility issues between DSMIPv6 and PMIPv6. For this reason, I think they should be addressed, for instance, by shifting the position of DSMIP-specific flags (F and T) of 1 bit to the right-hand-side. Thank you very much for your attention. If you have already discussed this topic in the mailing list, I apologize. Best regards, Lorenzo Saino *************************** * BINDING UPDATE MESSAGES * *************************** PROXY MOBILE IPv6 (RFC 5213) ============================ 8.1. Proxy Binding Update Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|P| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A Binding Update message that is sent by a mobile access gateway to a local mobility anchor is referred to as the "Proxy Binding Update" message. A new flag (P) is included in the Binding Update message. The rest of the Binding Update message format remains the same as defined in [RFC3775] and with the additional (R) and (M) flags, as specified in [RFC3963] and [RFC4140], respectively. Proxy Registration Flag (P) A new flag (P) is included in the Binding Update message to indicate to the local mobility anchor that the Binding Update message is a proxy registration. The flag MUST be set to the value of 1 for proxy registrations and MUST be set to 0 for direct registrations sent by a mobile node. DUAL STACK MOBILE IPv6 ====================== 4.1.3. The Binding Update Message Extensions This specification extends the Binding Update message with two new flags. The flags are shown and described below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|F|T| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Binding Update message F When set, this flag indicates a request for forcing UDP encapsulation regardless of whether a NAT is present on the path between the mobile node and the home agent. T When set, this flag indicates that the mobile node requests the use of the TLV-format for encapsulating IPv6 in IPv4. The TLV- format is described later in this document. ************************************ * BINDING ACKNOWLEDGEMENT MESSAGES * ************************************ PROXY MOBILE IPv6 (RFC 5213) ============================ 8.2. Proxy Binding Acknowledgement Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|R|P|Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A Binding Acknowledgement message that is sent by a local mobility anchor to a mobile access gateway is referred to as the "Proxy Binding Acknowledgement" message. A new flag (P) is included in the Binding Acknowledgement message. The rest of the Binding Acknowledgement message format remains the same as defined in [RFC3775] and with the additional (R) flag as specified in [RFC3963]. Proxy Registration Flag (P) A new flag (P) is included in the Binding Acknowledgement message to indicate that the local mobility anchor that processed the corresponding Proxy Binding Update message supports proxy registrations. The flag is set to a value of 1 only if the corresponding Proxy Binding Update had the Proxy Registration Flag (P) set to value of 1. DUAL STACK MOBILE IPv6 ====================== 4.2.3. Extensions to the Binding Acknowledgement Message This specification extends the binding acknowledgement message with a new flag. The new flag is shown and described below. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|R|T| Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Binding Acknowledgement message T This flag indicates, when set, that the sender of the binding acknowledgement supports the TLV- tunnel format. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 2 09:04: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 C21B73A6811; Tue, 2 Dec 2008 09:04:05 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 087D628C17D for ; Tue, 2 Dec 2008 09:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.383 X-Spam-Level: X-Spam-Status: No, score=-10.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKB6kr4Lfz2o for ; Tue, 2 Dec 2008 09:04:04 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 40F1A3A6811 for ; Tue, 2 Dec 2008 09:04:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,702,1220227200"; d="scan'208";a="27443517" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Dec 2008 17:03:55 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB2H3tHA023356; Tue, 2 Dec 2008 18:03:55 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB2H3r1Q010683; Tue, 2 Dec 2008 17:03:55 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 18:03:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Dec 2008 18:03:50 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06A3A8CB@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #16 on 3775bis Thread-Index: AclUn/Jo/oYdfCw4QZC43Sg0uVPi4w== From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 02 Dec 2008 17:03:54.0877 (UTC) FILETIME=[F54D0AD0:01C9549F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1393; t=1228237435; x=1229101435; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20Issue=20#16=20on=203775bis |Sender:=20; bh=lIdqwtx1qvMbywpuzZQ/Q8zN5Zx+cTYJqUomgIxXkbg=; b=OEg1mZQZiytdI6oQkNBWnMt2fLhacass5lqwk6Pg3T/O4XFaw59YxOrfq8 jz3w3eo+ztDeOBa43ct24n6YszL2t7lgwkUs5TdM47R6KPXL82Zh8ziY+m7L f0/6py5E5Z; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: mext@ietf.org Subject: [MEXT] Issue #16 on 3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Charlie: There was little change to ticket 16 for awhile. The last update on the ticket said: " Vijay Devarapalli : - 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. Well, if SeND is not being used, does it make sense for the home agent to allow the mobile node to claim its address, until the mobile node de-registers with a secure binding update? What if a misbehaving mobile node on the home link tries to claim the legitimate mobile node's home address while the home agent is defending the address? 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, This would modify the existing behavior. For unsolicited neighbor advertisements, the Home Agent sets the 'O' bit. See section 10.4.1. " Vijay is right, I'm asking for a change from 3775; OTOH RFC 3775 is in contradiction with RFC 4861 (7.2.8. Proxy Neighbor Advertisements) that states clearly that "All solicited proxy Neighbor Advertisement messages MUST have the Override flag set to zero." So what's best, maintain a debatable choice made in 3775 or comply with base ND rules? Pascal _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 2 09:43: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 69DE73A691A; Tue, 2 Dec 2008 09:43:04 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ABC03A67D0 for ; Tue, 2 Dec 2008 09:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 1iJNTJqO2ath for ; Tue, 2 Dec 2008 09:43:03 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2D6CF28B56A for ; Tue, 2 Dec 2008 09:43:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,702,1220227200"; d="scan'208";a="112488656" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 02 Dec 2008 17:42:59 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id mB2HgxqF008124; Tue, 2 Dec 2008 09:42:59 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB2HgxEw022917; Tue, 2 Dec 2008 17:42:59 GMT Date: Tue, 2 Dec 2008 09:42:59 -0800 (PST) From: Sri Gundavelli To: lorenzo.saino@orange-ftgroup.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7663; t=1228239779; x=1229103779; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20BU=20and=20BA=20flag=20overlap =20between=20DSMIPv6=0A=20(draft-ietf-mext-nemo-v4traversal- 06.txt)=20and=20Proxy=20MIPv6=20(RFC=205213) |Sender:=20; bh=N4g+LT9gu9k0iiVNgXP87+55HV7/VH7OfMlMigT+qGM=; b=mZOT4Oke152Yxb+g1QvZ3dVSWp49eOqBt++2T5d0sz5L1vO8407xFPgxj6 zd4A1ArqKFZpZMq9niz/mIDGIHsWrJx2Oywb6NLjZh6DIlWpsTTqNhIJ/SNo U814cFkiX2; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: mext@ietf.org Subject: Re: [MEXT] BU and BA flag overlap between DSMIPv6 (draft-ietf-mext-nemo-v4traversal-06.txt) and Proxy MIPv6 (RFC 5213) X-BeenThere: mext@ietf.org X-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 I've pointed this out few months back. I thought, its taken care off, looks like this is not corrected. Hesham ? Sri On Tue, 2 Dec 2008, lorenzo.saino@orange-ftgroup.com wrote: > Hello everybody, > > I have noticed that in the extension to BU and BA messages proposed in > DSMIPv6 (draft-ietf-mext-nemo-v4traversal-06.txt), the DSMIPv6-specific > flag bits overlap the flag bits proposed in BU and BA message extensions > defined in Proxy MIPv6 (RFC 5213). > > More specifically, in the extension to MIPv6 BU message proposed in > DSMIPv6, the flag (F) is located in the same position of the flag (P) > defined in BU extensions proposed in RFC 5213 (Proxy MIPv6). Similarly, > the flag (T) of DSMIPv6 BA message is located in the same position of > flag (P) of Proxy MIPv6 BA message. > > To make it easier to compare those messages, I reported the format of BU > and BA messages proposed in Dual Stack MIPv6 and Proxy MIPv6 at the > bottom of this e-mail. > > Has this overlapping been designed deliberately? > > In my opinion, these overlaps would generate incompatibility issues > between DSMIPv6 and PMIPv6. For this reason, I think they should be > addressed, for instance, by shifting the position of DSMIP-specific > flags (F and T) of 1 bit to the right-hand-side. > > Thank you very much for your attention. > > If you have already discussed this topic in the mailing list, I > apologize. > > Best regards, > Lorenzo Saino > > > *************************** > * BINDING UPDATE MESSAGES * > *************************** > > > PROXY MOBILE IPv6 (RFC 5213) > ============================ > > 8.1. Proxy Binding Update Message > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |A|H|L|K|M|R|P| Reserved | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Mobility options . > . . > > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > A Binding Update message that is sent by a mobile access gateway to a > local mobility anchor is referred to as the "Proxy Binding Update" > message. A new flag (P) is included in the Binding Update message. > The rest of the Binding Update message format remains the same as > defined in [RFC3775] and with the additional (R) and (M) flags, as > specified in [RFC3963] and [RFC4140], respectively. > > Proxy Registration Flag (P) > > A new flag (P) is included in the Binding Update message to > indicate to the local mobility anchor that the Binding Update > message is a proxy registration. The flag MUST be set to the > value of 1 for proxy registrations and MUST be set to 0 for direct > registrations sent by a mobile node. > > > > DUAL STACK MOBILE IPv6 > ====================== > > 4.1.3. The Binding Update Message Extensions > > This specification extends the Binding Update message with two new > flags. The flags are shown and described below. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |A|H|L|K|M|R|F|T| Reserved | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 3: Binding Update message > > F > > When set, this flag indicates a request for forcing UDP > encapsulation regardless of whether a NAT is present on the path > between the mobile node and the home agent. > > T > > When set, this flag indicates that the mobile node requests the > use of the TLV-format for encapsulating IPv6 in IPv4. The TLV- > format is described later in this document. > > > > > ************************************ > * BINDING ACKNOWLEDGEMENT MESSAGES * > ************************************ > > > PROXY MOBILE IPv6 (RFC 5213) > ============================ > > 8.2. Proxy Binding Acknowledgement Message > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status |K|R|P|Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Mobility options . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > A Binding Acknowledgement message that is sent by a local mobility > anchor to a mobile access gateway is referred to as the "Proxy > Binding Acknowledgement" message. A new flag (P) is included in the > Binding Acknowledgement message. The rest of the Binding > Acknowledgement message format remains the same as defined in > [RFC3775] and with the additional (R) flag as specified in [RFC3963]. > > Proxy Registration Flag (P) > > A new flag (P) is included in the Binding Acknowledgement message > to indicate that the local mobility anchor that processed the > corresponding Proxy Binding Update message supports proxy > registrations. The flag is set to a value of 1 only if the > corresponding Proxy Binding Update had the Proxy Registration Flag > (P) set to value of 1. > > > > DUAL STACK MOBILE IPv6 > ====================== > > 4.2.3. Extensions to the Binding Acknowledgement Message > > This specification extends the binding acknowledgement message with a > new flag. The new flag is shown and described below. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status |K|R|T| Reserved| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 6: Binding Acknowledgement message > > T > > This flag indicates, when set, that the sender of the binding > acknowledgement supports the TLV- tunnel format. > _______________________________________________ > MEXT mailing 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 Dec 2 09:57: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 6922328C14B; Tue, 2 Dec 2008 09:57:11 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2F1828C14B for ; Tue, 2 Dec 2008 09:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvhM8iqECZXg for ; Tue, 2 Dec 2008 09:57:09 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id BD67428C125 for ; Tue, 2 Dec 2008 09:57:08 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so811179qwe.31 for ; Tue, 02 Dec 2008 09:57:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Ns814y4ik/IFGH+rYNFlw6yhQf+JzOjlAWPErqBbtOg=; b=kVU4KWP1Pab61Ks1eQU/vk9EpGr+XypQsIM7gFi41g1m41SHfFD3ZZXZBCW3clwd95 a/b5vicq+veYYiHjtK6M2FktdnjEneqUNXyZtn9Bt8NZZ0JW1p+u1tjPzEHy/v6r1ijL udr6Gsmrag6CtHggMjazddW86yjBakc9HX754= 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=gcvHcqO+zbGhfovhXXeufyffvFC0tvc69slwvwZ7lh8HMb/2+pxJw+QUlgJ0fR+8ir 458fr2cwH+z1zfGtkltYJ4QNbpdHnY49lSiUd8xcCpbG/ssInqkLirQ8wbZRYRiup1Rl +Q9rq3iBDXoUGpL3R5kdSDo11/XsUIfwRQZ0k= Received: by 10.214.215.3 with SMTP id n3mr11898222qag.243.1228240624349; Tue, 02 Dec 2008 09:57:04 -0800 (PST) Received: by 10.214.181.8 with HTTP; Tue, 2 Dec 2008 09:57:04 -0800 (PST) Message-ID: Date: Tue, 2 Dec 2008 09:57:04 -0800 From: "fan zhao" To: "Ahmad Muhanna" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: Desire Oulai , mext@ietf.org Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 think this should be documented. Sincerely, fan On Mon, Dec 1, 2008 at 7:22 PM, Ahmad Muhanna wrote: > Hi Desire, > > Added a relative subject. > > I guess the usecase is clear and it makes sense to me. > We can add some text similar to yours to capture this functionality under > the HA and MN operations after the conclusion of the WGLC.. > > BTW: Is there anyone who thinks that we should not add this usecase? > > Regards, > Ahmad > > > > ________________________________ > From: Desire Oulai [mailto:desire.oulai@ericsson.com] > Sent: Monday, December 01, 2008 2:46 PM > To: mext@ietf.org > Cc: Muhanna, Ahmad (RICH1:2H10) > Subject: > > Hi Ahmad, All, > > The Binding revocation draft does not mention revocation related to NEMO. > If used as is, the BRI will revoke the binding between the MR's HoA and CoA. > I think it's woth adding another level of revocation: revocation of Mobile > Network Prefixes. A HA may decide to stop forwarding data to the CoA for > certain MNPs and BR could be used for that. Here is a proposed text for a > new section: > > "In case of NEMO protocol, the HA follows the same procedure as MIPv6 if the > goal is to revoke the binding between the Mobile Router's HoA and CoA. It is > also possible to have finer granularity of revocation targeting the Mobile > Network Prefixes assigned to the Mobile Router. In this case, the HA sends a > BRI message including one or more MNP options with the A bit set and the > Revocation Trigger set to a proper value, e.g. Administrative Reasons. When > receiving this BRI, the MR deletes the MNP(s) from the Prefix Information > field in the Binding Update List and responds with a BRA message. The BRA > MUST include the MNP(s) contained in the BRI." > > Also, Mobile network Prefix should be addes as valid option in section "6.2. > Binding Revocation Acknowledgement Message". > > BR > Desire > > _______________________________________________ > MEXT mailing 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 Dec 2 10:19: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 A6A2E3A6B35; Tue, 2 Dec 2008 10:19:42 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0AB43A6B35 for ; Tue, 2 Dec 2008 10:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Rl1-ZG5dqw6 for ; Tue, 2 Dec 2008 10:19:41 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id E257E3A6B34 for ; Tue, 2 Dec 2008 10:19:40 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so814403qwe.31 for ; Tue, 02 Dec 2008 10:19:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=3r/NdDsA+G3POBQMr7n/8UPQq3lQwNjIMCIXbcV2NZQ=; b=DMWZpgQTAYn3oDhnoD4kqrJnEovB89653LHqLog+s5dKbeJ8HKiT+kEWA9fgcQa0ZS ICSpxBv0SuT4nnV3Bmos43U0Wb5MliajNwAouzzCN0Fag73xbdAMmQabXNjs/u5YarlT 7X7/JetyXr4AQ9e+pQZazTRflKbuokIXWVUJ8= 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=mofK6BfYF7Dmnu4dJa5PrmDIsaW+Uc+AjAIRIdBCbY9LUy+RQNUh7/viHa3vf6CN8J 7S/iKc6xJTuXoA8rA3uPo4MMItxkxglMm0D4kl+gOtkGYmgmbtPC1CM52EA2g0mYBwwH t0SFTfyf+gBbwvh+3aQefsdNiv9rwDbOVLH28= Received: by 10.214.45.12 with SMTP id s12mr11934180qas.0.1228241975676; Tue, 02 Dec 2008 10:19:35 -0800 (PST) Received: by 10.214.181.8 with HTTP; Tue, 2 Dec 2008 10:19:35 -0800 (PST) Message-ID: Date: Tue, 2 Dec 2008 10:19:35 -0800 From: "fan zhao" To: "Desire Oulai" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: mext@ietf.org Subject: Re: [MEXT] (no subject) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Desire, I support adding this case. Nevertheless, please see some comments below. On Mon, Dec 1, 2008 at 12:45 PM, Desire Oulai wrote: > Hi Ahmad, All, > > The Binding revocation draft does not mention revocation related to NEMO. > If used as is, the BRI will revoke the binding between the MR's HoA and CoA. > I think it's woth adding another level of revocation: revocation of Mobile > Network Prefixes. A HA may decide to stop forwarding data to the CoA for > certain MNPs and BR could be used for that. This could be one of reasons to trigger the binding revocation of mobile network prefixes. However, when the binding revocation is used in this case, only the binding cache entry is modified and the MNP is not explicitly released. That is, after the binding revocation, the packets to such MNP is not tunneled by the HA. To release the MNP, I think it is better to use the method similar to how the MNP is obtained. This, IMO, would avoid messing up state machines. > Here is a proposed text for a > new section: > > "In case of NEMO protocol, the HA follows the same procedure as MIPv6 if the > goal is to revoke the binding between the Mobile Router's HoA and CoA. It is > also possible to have finer granularity of revocation targeting the Mobile > Network Prefixes assigned to the Mobile Router. In this case, the HA sends a > BRI message including one or more MNP options with the A bit set and the I reword it a little bit: "BRI message carrying one or more or even all MNPs allocated before in the MNP option(s) with the A bit set and the" That is, if the HA wants to remove all the MNPs from the BCE and still keep the binding between the CoA and the HoA, it includes all the MNPs. If the HA wants to remove the whole binding cache enry including the MNPs, it does not need to indicate the MNPs. > Revocation Trigger set to a proper value, e.g. Administrative Reasons. When > receiving this BRI, the MR deletes the MNP(s) from the Prefix Information > field in the Binding Update List and responds with a BRA message. The BRA > MUST include the MNP(s) contained in the BRI." I also want to add: If the home address is part of the mobile network prefix(es) to be revoked, the mobile router can still use such home address after such revocation of MNPs. Sincerely, fan > > Also, Mobile network Prefix should be addes as valid option in section "6.2. > Binding Revocation Acknowledgement Message". > > BR > Desire > > _______________________________________________ > MEXT mailing 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 Dec 2 11:32: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 148AD3A6B3A; Tue, 2 Dec 2008 11:32:50 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E85093A6B3A for ; Tue, 2 Dec 2008 11:32:48 -0800 (PST) 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 hUq6qC6y2vJv for ; Tue, 2 Dec 2008 11:32:48 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id D02643A6778 for ; Tue, 2 Dec 2008 11:32:47 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id mB2JVpEt030239; Tue, 2 Dec 2008 13:31:54 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 13:31:51 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Dec 2008 14:31:50 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase Thread-Index: AclUqpO+zw6f5rGkQWS5eFlARBARdAABerwQ References: From: "Desire Oulai" To: "fan zhao" X-OriginalArrivalTime: 02 Dec 2008 19:31:51.0373 (UTC) FILETIME=[A01AD7D0:01C954B4] Cc: mext@ietf.org Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi fan, I added the subject of the related thread. See inline. BR Desire > -----Original Message----- > From: fan zhao [mailto:fanzhao828@gmail.com] > Sent: December 2, 2008 1:20 PM > To: Desire Oulai > Cc: mext@ietf.org > Subject: Re: [MEXT] (no subject) > > Hi Desire, > > I support adding this case. Nevertheless, please see some > comments below. > > On Mon, Dec 1, 2008 at 12:45 PM, Desire Oulai > wrote: > > Hi Ahmad, All, > > > > The Binding revocation draft does not mention revocation > related to NEMO. > > If used as is, the BRI will revoke the binding between the > MR's HoA and CoA. > > I think it's woth adding another level of revocation: revocation of > > Mobile Network Prefixes. A HA may decide to stop forwarding data to > > the CoA for certain MNPs and BR could be used for that. > This could be one of reasons to trigger the binding > revocation of mobile network prefixes. However, when the > binding revocation is used in this case, only the binding > cache entry is modified and the MNP is not explicitly released. > That is, after the binding revocation, the packets to such > MNP is not tunneled by the HA. To release the MNP, I think it > is better to use the method similar to how the MNP is > obtained. This, IMO, would avoid messing up state machines. [Desire]: For sure, we need to be consistent. If the HA is the one that assigns the prefixes, BRI/BRA seems to me a good and sufficient approach to release the MNP. If the MNP was assigned by an external entity, the MN or HA can start other procedure after BRI/BRA. > > > Here is a proposed text for a > > new section: > > > > "In case of NEMO protocol, the HA follows the same > procedure as MIPv6 > > if the goal is to revoke the binding between the Mobile > Router's HoA > > and CoA. It is also possible to have finer granularity of > revocation > > targeting the Mobile Network Prefixes assigned to the > Mobile Router. > > In this case, the HA sends a BRI message including one or more MNP > > options with the A bit set and the > I reword it a little bit: > "BRI message carrying one or more or even all MNPs allocated > before in the MNP option(s) with the A bit set and the" > > That is, if the HA wants to remove all the MNPs from the BCE > and still keep the binding between the CoA and the HoA, it > includes all the MNPs. > If the HA wants to remove the whole binding cache enry > including the MNPs, it does not need to indicate the MNPs. [Desire]: That sounds good. > > > Revocation Trigger set to a proper value, e.g. > Administrative Reasons. > > When receiving this BRI, the MR deletes the MNP(s) from the Prefix > > Information field in the Binding Update List and responds > with a BRA > > message. The BRA MUST include the MNP(s) contained in the BRI." > I also want to add: > If the home address is part of the mobile network prefix(es) > to be revoked, the mobile router can still use such home > address after such revocation of MNPs. [Desire]: I don't know if we need this clarification but I see no problem with the text. > > Sincerely, > fan > > > > > Also, Mobile network Prefix should be addes as valid option > in section "6.2. > > Binding Revocation Acknowledgement Message". > > > > BR > > Desire > > > > _______________________________________________ > > MEXT mailing 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 Dec 2 11:51: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 D9F333A6B65; Tue, 2 Dec 2008 11:51:35 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B69B63A6B65; Tue, 2 Dec 2008 11:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.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 SERcslQlQsqq; Tue, 2 Dec 2008 11:51:34 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id CEACD3A6B58; Tue, 2 Dec 2008 11:51:33 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 3B1C619870B; Tue, 2 Dec 2008 21:51:29 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id D13DB198639; Tue, 2 Dec 2008 21:51:28 +0200 (EET) Message-ID: <493591AC.2030303@piuha.net> Date: Tue, 02 Dec 2008 21:51:08 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: Colin Perkins , Hesham Soliman References: In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: "mext@ietf.org" , ietf@ietf.org, TSV Dir Subject: Re: [MEXT] tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Thanks for your review, Colin. I agree that fixes or better explanations of the background should be given for the points that you raised. It seems that you and Hesham are making progress on what needs to be added to the document, great! The only item that I too am somewhat worried about in your list is the address replacement by broken NATs and the tricks used to prevent that. I feel that the best way to deal with that is to document this as a potential problem -- the protocol already has tools to provide a far better obfuscation technique than XOR -- just turn on encryption if this turns out to be a problem and the device in question cannot be ripped out of the network. Do we have any information about how widespread such NATs might be? RFC 5389 just says "some NATs". Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 2 11:53: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 49E2B3A6BD5; Tue, 2 Dec 2008 11:53:08 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 593CA3A6BD5 for ; Tue, 2 Dec 2008 11:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.614 X-Spam-Level: X-Spam-Status: No, score=-1.614 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xJ9J8XP6HiK for ; Tue, 2 Dec 2008 11:53:06 -0800 (PST) Received: from web111410.mail.gq1.yahoo.com (web111410.mail.gq1.yahoo.com [67.195.15.186]) by core3.amsl.com (Postfix) with SMTP id 582893A6B5D for ; Tue, 2 Dec 2008 11:53:06 -0800 (PST) Received: (qmail 92366 invoked by uid 60001); 2 Dec 2008 19:53:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=AtUfcJjRa+KtrIW5bndaNCcPPXh3112jS+H+a7DZsD4dD8EuJNUp8WDdVhT1tGUxOwNM0Uq0RFgPMiMcH5VHV8silm7+xmm8e3enzkp8PpaY+IFjOVoZ7tZh1nxOCk/CILrw36SRc+ZczxZb0PBHrzbVP6TMKZVwWyxPtd9i18c=; X-YMail-OSG: 2O8W_AQVM1noASjY_Lon.6hNocVXN1ebalaiQRlA7PL7E1B.hy.ViRqQ9m90pqDRaTiAzS8PJqlG4RM68_GITcqyKa3oiF0yVsAY.ETKVaVgZez5BfnqWsFIkG.2MeQ4vCrgL8npzYCe8xBXR8Hp7ONKexdEped5chorZPT3tE4o4Z4- Received: from [206.16.17.212] by web111410.mail.gq1.yahoo.com via HTTP; Tue, 02 Dec 2008 11:52:59 PST X-Mailer: YahooMailRC/1155.32 YahooMailWebService/0.7.260.1 References: Date: Tue, 2 Dec 2008 11:52:59 -0800 (PST) From: Behcet Sarikaya To: Ahmad Muhanna MIME-Version: 1.0 Message-ID: <570090.92095.qm@web111410.mail.gq1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase 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="===============0776987128==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0776987128== Content-Type: multipart/alternative; boundary="0-618635302-1228247579=:92095" --0-618635302-1228247579=:92095 Content-Type: text/plain; charset=us-ascii Hi Ahmad, Can you please explain how MNP is related to your draft? MNP is something that MR needs and is specific to Nemo operation not to MN-HA relationship and the binding that comes with it. So I don't see any binding to revocate with MNPs? Regards, Behcet ________________________________ From: Ahmad Muhanna To: Desire Oulai ; mext@ietf.org Sent: Monday, December 1, 2008 9:22:35 PM Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase Hi Desire, Added a relative subject. I guess the usecase is clear and it makes sense to me. We can add some text similar to yours to capture this functionality under the HA and MN operations after the conclusion of the WGLC.. BTW: Is there anyone who thinks that we should not add this usecase? Regards, Ahmad ________________________________ From: Desire Oulai [mailto:desire.oulai@ericsson.com] Sent: Monday, December 01, 2008 2:46 PM To: mext@ietf.org Cc: Muhanna, Ahmad (RICH1:2H10) Subject: Hi Ahmad, All, The Binding revocationdraft does not mention revocation related to NEMO. If used as is, the BRI will revoke the binding between the MR's HoA and CoA. I think it's woth adding another level of revocation: revocation of Mobile Network Prefixes. A HA may decide to stop forwarding data to the CoA for certain MNPs and BR could be used for that. Here is a proposed text for a new section: "In case of NEMO protocol, the HA follows the same procedure as MIPv6 if the goal is to revoke the binding between the Mobile Router's HoA and CoA. It is also possible to have finer granularity of revocation targeting the Mobile Network Prefixes assigned to the Mobile Router. In this case, the HA sends a BRI message including one or more MNP options with the A bit set and the Revocation Trigger set to a proper value, e.g. Administrative Reasons. When receiving this BRI, the MR deletes the MNP(s) from the Prefix Information field in the Binding Update List and responds with a BRA message. The BRA MUST include the MNP(s) contained in the BRI." Also, Mobile network Prefix should be addes as valid option in section "6.2. Binding Revocation Acknowledgement Message". BR Desire --0-618635302-1228247579=:92095 Content-Type: text/html; charset=us-ascii
Hi Ahmad,
  Can you please explain how MNP is related to your draft? MNP is something that MR needs and is specific to Nemo operation not to MN-HA relationship and the binding that comes with it.
  So I don't see any binding to revocate with MNPs?

Regards,

Behcet

From: Ahmad Muhanna <amuhanna@nortel.com>
To: Desire Oulai <desire.oulai@ericsson.com>; mext@ietf.org
Sent: Monday, December 1, 2008 9:22:35 PM
Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase

Hi Desire,
 
Added a relative subject.
 
I guess the usecase is clear and it makes sense to me.
We can add some text similar to yours to capture this functionality under the HA and MN operations after the conclusion of the WGLC..
 
BTW: Is there anyone who thinks that we should not add this usecase?

Regards,
Ahmad

 

From: Desire Oulai [mailto:desire.oulai@ericsson.com]
Sent: Monday, December 01, 2008 2:46 PM
To: mext@ietf.org
Cc: Muhanna, Ahmad (RICH1:2H10)
Subject:

Hi Ahmad, All,

 The Binding revocation draft does not mention revocation related to NEMO. If used as is, the BRI will revoke the binding between the MR's HoA and CoA. I think it's woth adding another level of revocation: revocation of Mobile Network Prefixes. A HA may decide to stop forwarding data to the CoA for certain MNPs and BR could be used for that. Here is a proposed text for a new section:

"In case of NEMO protocol, the HA follows the same procedure as MIPv6 if the goal is to revoke the binding between the Mobile Router's HoA and CoA. It is also possible to have finer granularity of revocation targeting the Mobile Network Prefixes assigned to the Mobile Router. In this case, the HA sends a BRI message including one or more MNP options with the A bit set and the Revocation Trigger set to a proper value, e.g. Administrative Reasons. When receiving this BRI, the MR deletes the MNP(s) from the Prefix Information field in the Binding Update List and responds with a BRA message. The BRA MUST include the MNP(s) contained in the BRI."

Also, Mobile network Prefix should be addes as valid option in section "6.2. Binding Revocation Acknowledgement Message".

BR
Desire


--0-618635302-1228247579=:92095-- --===============0776987128== 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 --===============0776987128==-- From mext-bounces@ietf.org Tue Dec 2 13:32:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39ED93A6835; Tue, 2 Dec 2008 13:32:31 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2D253A6835 for ; Tue, 2 Dec 2008 13:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.723 X-Spam-Level: X-Spam-Status: No, score=-2.723 tagged_above=-999 required=5 tests=[AWL=-0.124, 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 o4x-J7vSyOd2 for ; Tue, 2 Dec 2008 13:32:28 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 8DE543A67D4 for ; Tue, 2 Dec 2008 13:32:28 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1L7cqx-0000jE-Ge; Wed, 03 Dec 2008 08:32:20 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Wed, 03 Dec 2008 08:32:13 +1100 From: Hesham Soliman To: Sri Gundavelli , Message-ID: Thread-Topic: [MEXT] BU and BA flag overlap between DSMIPv6 (draft-ietf-mext-nemo-v4traversal-06.txt) and Proxy MIPv6 (RFC 5213) Thread-Index: AclUxXCH5+Xjdr5dbUaZ8G/WLhHB2g== In-Reply-To: Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] BU and BA flag overlap between DSMIPv6 (draft-ietf-mext-nemo-v4traversal-06.txt) and Proxy MIPv6 (RFC 5213) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Yes you did and I thought I fixed it. Thanks for the catch, I'll fix this with the rest of the updates. Hesham On 3/12/08 4:42 AM, "Sri Gundavelli" wrote: > I've pointed this out few months back. I thought, its taken care off, > looks like this is not corrected. Hesham ? > > > Sri > > > On Tue, 2 Dec 2008, lorenzo.saino@orange-ftgroup.com wrote: > >> Hello everybody, >> >> I have noticed that in the extension to BU and BA messages proposed in >> DSMIPv6 (draft-ietf-mext-nemo-v4traversal-06.txt), the DSMIPv6-specific >> flag bits overlap the flag bits proposed in BU and BA message extensions >> defined in Proxy MIPv6 (RFC 5213). >> >> More specifically, in the extension to MIPv6 BU message proposed in >> DSMIPv6, the flag (F) is located in the same position of the flag (P) >> defined in BU extensions proposed in RFC 5213 (Proxy MIPv6). Similarly, >> the flag (T) of DSMIPv6 BA message is located in the same position of >> flag (P) of Proxy MIPv6 BA message. >> >> To make it easier to compare those messages, I reported the format of BU >> and BA messages proposed in Dual Stack MIPv6 and Proxy MIPv6 at the >> bottom of this e-mail. >> >> Has this overlapping been designed deliberately? >> >> In my opinion, these overlaps would generate incompatibility issues >> between DSMIPv6 and PMIPv6. For this reason, I think they should be >> addressed, for instance, by shifting the position of DSMIP-specific >> flags (F and T) of 1 bit to the right-hand-side. >> >> Thank you very much for your attention. >> >> If you have already discussed this topic in the mailing list, I >> apologize. >> >> Best regards, >> Lorenzo Saino >> >> >> *************************** >> * BINDING UPDATE MESSAGES * >> *************************** >> >> >> PROXY MOBILE IPv6 (RFC 5213) >> ============================ >> >> 8.1. Proxy Binding Update Message >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence # | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |A|H|L|K|M|R|P| Reserved | Lifetime | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> . . >> . Mobility options . >> . . >> >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> A Binding Update message that is sent by a mobile access gateway to a >> local mobility anchor is referred to as the "Proxy Binding Update" >> message. A new flag (P) is included in the Binding Update message. >> The rest of the Binding Update message format remains the same as >> defined in [RFC3775] and with the additional (R) and (M) flags, as >> specified in [RFC3963] and [RFC4140], respectively. >> >> Proxy Registration Flag (P) >> >> A new flag (P) is included in the Binding Update message to >> indicate to the local mobility anchor that the Binding Update >> message is a proxy registration. The flag MUST be set to the >> value of 1 for proxy registrations and MUST be set to 0 for direct >> registrations sent by a mobile node. >> >> >> >> DUAL STACK MOBILE IPv6 >> ====================== >> >> 4.1.3. The Binding Update Message Extensions >> >> This specification extends the Binding Update message with two new >> flags. The flags are shown and described below. >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence # | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |A|H|L|K|M|R|F|T| Reserved | Lifetime | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Figure 3: Binding Update message >> >> F >> >> When set, this flag indicates a request for forcing UDP >> encapsulation regardless of whether a NAT is present on the path >> between the mobile node and the home agent. >> >> T >> >> When set, this flag indicates that the mobile node requests the >> use of the TLV-format for encapsulating IPv6 in IPv4. The TLV- >> format is described later in this document. >> >> >> >> >> ************************************ >> * BINDING ACKNOWLEDGEMENT MESSAGES * >> ************************************ >> >> >> PROXY MOBILE IPv6 (RFC 5213) >> ============================ >> >> 8.2. Proxy Binding Acknowledgement Message >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Status |K|R|P|Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence # | Lifetime | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> . . >> . Mobility options . >> . . >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> A Binding Acknowledgement message that is sent by a local mobility >> anchor to a mobile access gateway is referred to as the "Proxy >> Binding Acknowledgement" message. A new flag (P) is included in the >> Binding Acknowledgement message. The rest of the Binding >> Acknowledgement message format remains the same as defined in >> [RFC3775] and with the additional (R) flag as specified in [RFC3963]. >> >> Proxy Registration Flag (P) >> >> A new flag (P) is included in the Binding Acknowledgement message >> to indicate that the local mobility anchor that processed the >> corresponding Proxy Binding Update message supports proxy >> registrations. The flag is set to a value of 1 only if the >> corresponding Proxy Binding Update had the Proxy Registration Flag >> (P) set to value of 1. >> >> >> >> DUAL STACK MOBILE IPv6 >> ====================== >> >> 4.2.3. Extensions to the Binding Acknowledgement Message >> >> This specification extends the binding acknowledgement message with a >> new flag. The new flag is shown and described below. >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Status |K|R|T| Reserved| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence # | Lifetime | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Figure 6: Binding Acknowledgement message >> >> T >> >> This flag indicates, when set, that the sender of the binding >> acknowledgement supports the TLV- tunnel format. >> _______________________________________________ >> MEXT mailing 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 Dec 2 13:34: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 C49BC3A69AB; Tue, 2 Dec 2008 13:34:07 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33C4328C0EB for ; Tue, 2 Dec 2008 13:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.929 X-Spam-Level: X-Spam-Status: No, score=-5.929 tagged_above=-999 required=5 tests=[AWL=0.669, 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 b2xm2nkpne36 for ; Tue, 2 Dec 2008 13:34:06 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id CBF9C3A67D4 for ; Tue, 2 Dec 2008 13:34:05 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mB2LXsE12942; Tue, 2 Dec 2008 21:33:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Dec 2008 15:33:14 -0600 Message-ID: In-Reply-To: <570090.92095.qm@web111410.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase Thread-Index: AclUt6g3NWgFM6EmQtamDyhN5v8TYwADNi1A References: <570090.92095.qm@web111410.mail.gq1.yahoo.com> From: "Ahmad Muhanna" To: "Behcet Sarikaya" Cc: mext@ietf.org Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase X-BeenThere: mext@ietf.org X-Mailman-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="===============0474289698==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0474289698== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C954C5.95609DAF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C954C5.95609DAF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Behcet, =20 That is why I asked the if there is anyone against adding this use case. If the wg think that this usecase should not be added or addressed by binding revocation, I am absolutely fine with that. or to be precise, we need to have the wg to agree to add this usecase. Regards,=20 Ahmad=20 =20 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Tuesday, December 02, 2008 1:53 PM To: Muhanna, Ahmad (RICH1:2H10) Cc: mext@ietf.org Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase =09 =09 Hi Ahmad, Can you please explain how MNP is related to your draft? MNP is something that MR needs and is specific to Nemo operation not to MN-HA relationship and the binding that comes with it.=20 So I don't see any binding to revocate with MNPs? =09 Regards, =09 Behcet =09 =09 ________________________________ From: Ahmad Muhanna To: Desire Oulai ; mext@ietf.org Sent: Monday, December 1, 2008 9:22:35 PM Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase =09 =09 Hi Desire, =20 Added a relative subject. =20 I guess the usecase is clear and it makes sense to me.=20 We can add some text similar to yours to capture this functionality under the HA and MN operations after the conclusion of the WGLC.. =20 BTW: Is there anyone who thinks that we should not add this usecase? Regards,=20 Ahmad=20 =20 ________________________________ From: Desire Oulai [mailto:desire.oulai@ericsson.com]=20 Sent: Monday, December 01, 2008 2:46 PM To: mext@ietf.org Cc: Muhanna, Ahmad (RICH1:2H10) Subject:=20 =09 =09 Hi Ahmad, All,=20 The Binding revocation draft does not mention revocation related to NEMO. If used as is, the BRI will revoke the binding between the MR's HoA and CoA. I think it's woth adding another level of revocation: revocation of Mobile Network Prefixes. A HA may decide to stop forwarding data to the CoA for certain MNPs and BR could be used for that. Here is a proposed text for a new section: "In case of NEMO protocol, the HA follows the same procedure as MIPv6 if the goal is to revoke the binding between the Mobile Router's HoA and CoA. It is also possible to have finer granularity of revocation targeting the Mobile Network Prefixes assigned to the Mobile Router. In this case, the HA sends a BRI message including one or more MNP options with the A bit set and the Revocation Trigger set to a proper value, e.g. Administrative Reasons. When receiving this BRI, the MR deletes the MNP(s) from the Prefix Information field in the Binding Update List and responds with a BRA message. The BRA MUST include the MNP(s) contained in the BRI." Also, Mobile network Prefix should be addes as valid option in section "6.2. Binding Revocation Acknowledgement Message". BR=20 Desire=20 ------_=_NextPart_001_01C954C5.95609DAF Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi=20 Behcet,
 
That=20 is why I asked the if there is anyone against adding this use case.=20
If the=20 wg think that this usecase should not be added or addressed by = binding=20 revocation, I am absolutely fine with that. or to be precise, we need to = have=20 the wg to agree to add this usecase.

Regards, =
Ahmad

 

From: Behcet Sarikaya=20 [mailto:behcetsarikaya@yahoo.com]
Sent: Tuesday, December = 02, 2008=20 1:53 PM
To: Muhanna, Ahmad (RICH1:2H10)
Cc:=20 mext@ietf.org
Subject: Re: [MEXT] Binding Revocation for = IPv6=20 Mobility Supports NEMO usecase

Hi Ahmad,
  Can you please explain how MNP is related to = your=20 draft? MNP is something that MR needs and is specific to Nemo = operation not to=20 MN-HA relationship and the binding that comes with it.
  So I = don't=20 see any binding to revocate with = MNPs?

Regards,

Behcet

From: Ahmad Muhanna=20 <amuhanna@nortel.com>
To: Desire Oulai=20 <desire.oulai@ericsson.com>; mext@ietf.org
Sent: Monday, December 1, 2008 = 9:22:35=20 PM
Subject: Re: = [MEXT]=20 Binding Revocation for IPv6 Mobility Supports NEMO = usecase

Hi=20 Desire,
 
Added a relative subject.
 
I=20 guess the usecase is clear and it makes sense to me. =
We=20 can add some text similar to yours to capture this functionality under = the HA=20 and MN operations after the conclusion of the = WGLC..
 
BTW:=20 Is there anyone who thinks that we should not add this=20 usecase?

Regards,
Ahmad

 

From: Desire Oulai=20 [mailto:desire.oulai@ericsson.com]
Sent: Monday, December = 01,=20 2008 2:46 PM
To: mext@ietf.org
Cc: Muhanna, = Ahmad=20 (RICH1:2H10)
Subject:

Hi Ahmad, = All,=20

 The Binding=20 revocation draft does=20 not mention revocation related to NEMO. If used as is, the BRI will = revoke=20 the binding between the MR's HoA and CoA. I think it's woth adding = another=20 level of revocation: revocation of Mobile Network Prefixes. A HA may = decide=20 to stop forwarding data to the CoA for certain MNPs and BR could be = used for=20 that. Here is a proposed text for a new section:

"In case of NEMO = protocol, the=20 HA follows the same procedure as MIPv6 if the goal is to revoke the = binding=20 between the Mobile Router's HoA and CoA. It is also possible to have = finer=20 granularity of revocation targeting the Mobile Network Prefixes = assigned to=20 the Mobile Router. In this case, the HA sends a BRI message = including one or=20 more MNP options with the A bit set and the Revocation Trigger set = to a=20 proper value, e.g. Administrative Reasons. When receiving this BRI, = the MR=20 deletes the MNP(s) from the Prefix Information field in the Binding = Update=20 List and responds with a BRA message. The BRA MUST include the = MNP(s)=20 contained in the BRI."

Also, Mobile = network Prefix=20 should be addes as valid option in section "6.2. Binding Revocation Acknowledgement=20 Message".

BR
Desire=20


------_=_NextPart_001_01C954C5.95609DAF-- --===============0474289698== 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 --===============0474289698==-- From mext-bounces@ietf.org Tue Dec 2 13:42:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A71CB3A6BEA; Tue, 2 Dec 2008 13:42:03 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B94A3A6BEA for ; Tue, 2 Dec 2008 13:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 TIhHVn5Pcwu1 for ; Tue, 2 Dec 2008 13:42:01 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 463833A69A2 for ; Tue, 2 Dec 2008 13:42:01 -0800 (PST) Received: by qyk4 with SMTP id 4so3707698qyk.13 for ; Tue, 02 Dec 2008 13:41:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=oBzDxcbeVfm8FB4L902qidt+4FmvPrFDBouqlLFmj8I=; b=bwcSrZwRRnPlpyswHUiMLMHA+thV7+d+sCEmDzeBnb8nEf8uZmyItj6bL/o4IoD58P kl8HAnqvnI2ETiKKZ7fs634f66oJZKLUwA7v7vzzuQJMXSKWCTwF3dv0zMSRVbqFlHNs 2rhxZtXI1qIdaL6AzphVWfnUIcQVQEscPtsCo= 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=M22dwudQupz4CnO/689nzLZvhdi+XjGCU8nI3c4kU4VI11HPw/vhxyp4tb1tQLrcID q2Mto2Kfhgk1v/mz4B35PX7/wP6/et2IDJZjzFws64nMufcAT06+yQ8akgyonuVbdbkp 23qHR58/o9rk7QdZMjHCyDMyVDskwI1s9uKVA= Received: by 10.214.150.9 with SMTP id x9mr12328407qad.38.1228254116548; Tue, 02 Dec 2008 13:41:56 -0800 (PST) Received: by 10.214.181.8 with HTTP; Tue, 2 Dec 2008 13:41:56 -0800 (PST) Message-ID: Date: Tue, 2 Dec 2008 13:41:56 -0800 From: "fan zhao" To: "Behcet Sarikaya" In-Reply-To: <570090.92095.qm@web111410.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline References: <570090.92095.qm@web111410.mail.gq1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Behcet, The binding revocation is designed for DSMIPv6 and DSMIPv6 supports both mobile host and mobile router. I do not see any issue. Sincerely, fan On Tue, Dec 2, 2008 at 11:52 AM, Behcet Sarikaya wrote: > Hi Ahmad, > Can you please explain how MNP is related to your draft? MNP is something > that MR needs and is specific to Nemo operation not to MN-HA relationship > and the binding that comes with it. > So I don't see any binding to revocate with MNPs? > > Regards, > > Behcet > > ________________________________ > From: Ahmad Muhanna > To: Desire Oulai ; mext@ietf.org > Sent: Monday, December 1, 2008 9:22:35 PM > Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO > usecase > > Hi Desire, > > Added a relative subject. > > I guess the usecase is clear and it makes sense to me. > We can add some text similar to yours to capture this functionality under > the HA and MN operations after the conclusion of the WGLC.. > > BTW: Is there anyone who thinks that we should not add this usecase? > > Regards, > Ahmad > > > > ________________________________ > From: Desire Oulai [mailto:desire.oulai@ericsson.com] > Sent: Monday, December 01, 2008 2:46 PM > To: mext@ietf.org > Cc: Muhanna, Ahmad (RICH1:2H10) > Subject: > > Hi Ahmad, All, > > The Binding revocation draft does not mention revocation related to NEMO. > If used as is, the BRI will revoke the binding between the MR's HoA and CoA. > I think it's woth adding another level of revocation: revocation of Mobile > Network Prefixes. A HA may decide to stop forwarding data to the CoA for > certain MNPs and BR could be used for that. Here is a proposed text for a > new section: > > "In case of NEMO protocol, the HA follows the same procedure as MIPv6 if the > goal is to revoke the binding between the Mobile Router's HoA and CoA. It is > also possible to have finer granularity of revocation targeting the Mobile > Network Prefixes assigned to the Mobile Router. In this case, the HA sends a > BRI message including one or more MNP options with the A bit set and the > Revocation Trigger set to a proper value, e.g. Administrative Reasons. When > receiving this BRI, the MR deletes the MNP(s) from the Prefix Information > field in the Binding Update List and responds with a BRA message. The BRA > MUST include the MNP(s) contained in the BRI." > > Also, Mobile network Prefix should be addes as valid option in section "6.2. > Binding Revocation Acknowledgement Message". > > BR > Desire > > _______________________________________________ > MEXT mailing 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 Dec 2 14:51:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0623B28C207; Tue, 2 Dec 2008 14:51:03 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66A5528C207 for ; Tue, 2 Dec 2008 14:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJnNT9Js8qLb for ; Tue, 2 Dec 2008 14:51:00 -0800 (PST) Received: from web111411.mail.gq1.yahoo.com (web111411.mail.gq1.yahoo.com [67.195.15.192]) by core3.amsl.com (Postfix) with SMTP id 56A6E28C1FF for ; Tue, 2 Dec 2008 14:51:00 -0800 (PST) Received: (qmail 85478 invoked by uid 60001); 2 Dec 2008 22:50:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=2Z51Gu6vweR5KphzJqBrqk8X9GYf75zMaTgdpfHQ7jzSi3+yrEh20gOw87Di3fuGXTF5jojF4C3MR4VmF+m4obgGQng/w18d6Lo+JgT6C8wEloFFNgvS9ZBZjB9ilPQQ3ZpCr6/PKw0pgtvSW1JdzPPoArxoROICtNTDG/Y/mhA=; X-YMail-OSG: QjPluqsVM1nGVWlwYbkC908j5QyPoNWzc2eG4I4UqP8TzC7RRz_JAqkqnfOm7oonfgKYnEud9wIt4CQ2TFNgAu3kEL5kCHq7HPD.yS16MDXD1SLMBbDSRab7gvhGN90HZwtti3m_fygZQktl_ERaq0f4ii.0m2z31LJxxrCuNyLrZMg- Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Tue, 02 Dec 2008 14:50:56 PST X-Mailer: YahooMailRC/1155.32 YahooMailWebService/0.7.260.1 References: <570090.92095.qm@web111410.mail.gq1.yahoo.com> Date: Tue, 2 Dec 2008 14:50:56 -0800 (PST) From: Behcet Sarikaya To: fan zhao MIME-Version: 1.0 Message-ID: <496302.84429.qm@web111411.mail.gq1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase 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="===============1371799343==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1371799343== Content-Type: multipart/alternative; boundary="0-1346805225-1228258256=:84429" --0-1346805225-1228258256=:84429 Content-Type: text/plain; charset=us-ascii Hi Fan, Prefix delegation/authorization function should take care of this. In DHCP PD there is a way to release the prefixes. Regards, Behcet ________________________________ From: fan zhao To: Behcet Sarikaya Cc: Ahmad Muhanna ; mext@ietf.org Sent: Tuesday, December 2, 2008 3:41:56 PM Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase Hi Behcet, The binding revocation is designed for DSMIPv6 and DSMIPv6 supports both mobile host and mobile router. I do not see any issue. Sincerely, fan On Tue, Dec 2, 2008 at 11:52 AM, Behcet Sarikaya wrote: > Hi Ahmad, > Can you please explain how MNP is related to your draft? MNP is something > that MR needs and is specific to Nemo operation not to MN-HA relationship > and the binding that comes with it. > So I don't see any binding to revocate with MNPs? > > Regards, > > Behcet > > ________________________________ > From: Ahmad Muhanna > To: Desire Oulai ; mext@ietf.org > Sent: Monday, December 1, 2008 9:22:35 PM > Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO > usecase > > Hi Desire, > > Added a relative subject. > > I guess the usecase is clear and it makes sense to me. > We can add some text similar to yours to capture this functionality under > the HA and MN operations after the conclusion of the WGLC.. > > BTW: Is there anyone who thinks that we should not add this usecase? > > Regards, > Ahmad > > > > ________________________________ > From: Desire Oulai [mailto:desire.oulai@ericsson.com] > Sent: Monday, December 01, 2008 2:46 PM > To: mext@ietf.org > Cc: Muhanna, Ahmad (RICH1:2H10) > Subject: > > Hi Ahmad, All, > > The Binding revocation draft does not mention revocation related to NEMO. > If used as is, the BRI will revoke the binding between the MR's HoA and CoA. > I think it's woth adding another level of revocation: revocation of Mobile > Network Prefixes. A HA may decide to stop forwarding data to the CoA for > certain MNPs and BR could be used for that. Here is a proposed text for a > new section: > > "In case of NEMO protocol, the HA follows the same procedure as MIPv6 if the > goal is to revoke the binding between the Mobile Router's HoA and CoA. It is > also possible to have finer granularity of revocation targeting the Mobile > Network Prefixes assigned to the Mobile Router. In this case, the HA sends a > BRI message including one or more MNP options with the A bit set and the > Revocation Trigger set to a proper value, e.g. Administrative Reasons. When > receiving this BRI, the MR deletes the MNP(s) from the Prefix Information > field in the Binding Update List and responds with a BRA message. The BRA > MUST include the MNP(s) contained in the BRI." > > Also, Mobile network Prefix should be addes as valid option in section "6.2. > Binding Revocation Acknowledgement Message". > > BR > Desire > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > --0-1346805225-1228258256=:84429 Content-Type: text/html; charset=us-ascii
Hi Fan,
  Prefix delegation/authorization function should take care of this. In DHCP PD there is a way to release the prefixes.

Regards,

Behcet

From: fan zhao <fanzhao828@gmail.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: Ahmad Muhanna <amuhanna@nortel.com>; mext@ietf.org
Sent: Tuesday, December 2, 2008 3:41:56 PM
Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase

Hi Behcet,

The binding revocation is designed for DSMIPv6 and DSMIPv6 supports
both mobile host
and mobile router. I do not see any issue.

Sincerely,
fan

On Tue, Dec 2, 2008 at 11:52 AM, Behcet Sarikaya
<behcetsarikaya@yahoo.com> wrote:
> Hi Ahmad,
>  Can you please explain how MNP is related to your draft? MNP is something
> that MR needs and is specific to Nemo operation not to MN-HA relationship
> and the binding that comes with it.
>  So I don't see any binding to revocate with MNPs?
>
> Regards,
>
> Behcet
>
> ________________________________
> From: Ahmad Muhanna <amuhanna@nortel.com>
> To: Desire Oulai <desire.oulai@ericsson.com>; mext@ietf.org
> Sent: Monday, December 1, 2008 9:22:35 PM
> Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO
> usecase
>
> Hi Desire,
>
> Added a relative subject.
>
> I guess the usecase is clear and it makes sense to me.
> We can add some text similar to yours to capture this functionality under
> the HA and MN operations after the conclusion of the WGLC..
>
> BTW: Is there anyone who thinks that we should not add this usecase?
>
> Regards,
> Ahmad
>
>
>
> ________________________________
> From: Desire Oulai [mailto:desire.oulai@ericsson.com]
> Sent: Monday, December 01, 2008 2:46 PM
> To: mext@ietf.org
> Cc: Muhanna, Ahmad (RICH1:2H10)
> Subject:
>
> Hi Ahmad, All,
>
>  The Binding revocation draft does not mention revocation related to NEMO.
> If used as is, the BRI will revoke the binding between the MR's HoA and CoA.
> I think it's woth adding another level of revocation: revocation of Mobile
> Network Prefixes. A HA may decide to stop forwarding data to the CoA for
> certain MNPs and BR could be used for that. Here is a proposed text for a
> new section:
>
> "In case of NEMO protocol, the HA follows the same procedure as MIPv6 if the
> goal is to revoke the binding between the Mobile Router's HoA and CoA. It is
> also possible to have finer granularity of revocation targeting the Mobile
> Network Prefixes assigned to the Mobile Router. In this case, the HA sends a
> BRI message including one or more MNP options with the A bit set and the
> Revocation Trigger set to a proper value, e.g. Administrative Reasons. When
> receiving this BRI, the MR deletes the MNP(s) from the Prefix Information
> field in the Binding Update List and responds with a BRA message. The BRA
> MUST include the MNP(s) contained in the BRI."
>
> Also, Mobile network Prefix should be addes as valid option in section "6.2.
> Binding Revocation Acknowledgement Message".
>
> BR
> Desire
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>
>

--0-1346805225-1228258256=:84429-- --===============1371799343== 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 --===============1371799343==-- From mext-bounces@ietf.org Tue Dec 2 15:47: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 18D9E28C20A; Tue, 2 Dec 2008 15:47:42 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18B1B28C20A for ; Tue, 2 Dec 2008 15:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJf0lBmdr8SD for ; Tue, 2 Dec 2008 15:47:40 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id E329728C207 for ; Tue, 2 Dec 2008 15:47:39 -0800 (PST) Received: by qyk4 with SMTP id 4so3761479qyk.13 for ; Tue, 02 Dec 2008 15:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ALI29kgMH2ml2v/eCcSbLMacQGjPNyxdypjzcXANm0Y=; b=pOWl057ZDvJp6L9Ok2CGs0Z1AbfKDFDNKNOaB5lfoGm8bV1TJSm7mI8LZuZQXwJhsz IQcbNzL0F7VG1+Y0/hid/Zstg3HdLXSOyIrsd4yhhU+zbeWn9A3XQPvpv2fixLVySdx3 sRdkrYgY6DGleD+Co1/2Ae3mNj3JvhFddSkoI= 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=pH1HdW7j7aSZSODWrg6V5YbYIdN5W+pMI8yIfz2KD80kry8YGV6/pEATnPM+RfUg1v L915/7k3uEFJt1Kt7Q1ZByPPvZbAA6+t8vL42O3cSTg8WHqm4std0AT3kxrMo9zO32xQ JEJk6JNreZGdOQLnhHJ1GaWC4Boo13nCVzS+Q= Received: by 10.214.25.7 with SMTP id 7mr12494539qay.263.1228261655449; Tue, 02 Dec 2008 15:47:35 -0800 (PST) Received: by 10.214.181.8 with HTTP; Tue, 2 Dec 2008 15:47:35 -0800 (PST) Message-ID: Date: Tue, 2 Dec 2008 15:47:35 -0800 From: "fan zhao" To: "Behcet Sarikaya" In-Reply-To: <496302.84429.qm@web111411.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline References: <570090.92095.qm@web111410.mail.gq1.yahoo.com> <496302.84429.qm@web111411.mail.gq1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Behcet, There is a difference between binding revocation for MNPs and MNP release. When the binding revocation for MNPs is performed, the MNP information stored in the binding cache entry for the MR is removed, which means that the packets for such MNP will not be tunneled by the HA; however, such MNP is not explicitly released by the binding revocation. This is needed because the mobile network nodes connecting to the MR before may handover to their home network (such as wimax) while the MR still stays in its foreign link (since for example the MR does not have the wimax interface); therefore, such MNP should still be made valid for such mobile network nodes. To release such MNP, the same method to allocate the MNP should be used. For example, if the MNP is allocated by using DHCP, then DHCP needs to be used again to remove such MNP. This is similar to the MIPv6 case where the MN sends the BU with the lifetime=zero or the HA sends the BRI to remove the binding, the home address on the other hand needs to remove by deleting the IPsec SA if this is detach. It makes sense to me using the BR to remove the MNP from the BCE since such MNP is registered by using BU and BR is the opposite way to BU. Sincerely, fan On Tue, Dec 2, 2008 at 2:50 PM, Behcet Sarikaya wrote: > Hi Fan, > Prefix delegation/authorization function should take care of this. In DHCP > PD there is a way to release the prefixes. > > Regards, > > Behcet > > ________________________________ > From: fan zhao > To: Behcet Sarikaya > Cc: Ahmad Muhanna ; mext@ietf.org > Sent: Tuesday, December 2, 2008 3:41:56 PM > Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO > usecase > > Hi Behcet, > > The binding revocation is designed for DSMIPv6 and DSMIPv6 supports > both mobile host > and mobile router. I do not see any issue. > > Sincerely, > fan > > On Tue, Dec 2, 2008 at 11:52 AM, Behcet Sarikaya > wrote: >> Hi Ahmad, >> Can you please explain how MNP is related to your draft? MNP is something >> that MR needs and is specific to Nemo operation not to MN-HA relationship >> and the binding that comes with it. >> So I don't see any binding to revocate with MNPs? >> >> Regards, >> >> Behcet >> >> ________________________________ >> From: Ahmad Muhanna >> To: Desire Oulai ; mext@ietf.org >> Sent: Monday, December 1, 2008 9:22:35 PM >> Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO >> usecase >> >> Hi Desire, >> >> Added a relative subject. >> >> I guess the usecase is clear and it makes sense to me. >> We can add some text similar to yours to capture this functionality under >> the HA and MN operations after the conclusion of the WGLC.. >> >> BTW: Is there anyone who thinks that we should not add this usecase? >> >> Regards, >> Ahmad >> >> >> >> ________________________________ >> From: Desire Oulai [mailto:desire.oulai@ericsson.com] >> Sent: Monday, December 01, 2008 2:46 PM >> To: mext@ietf.org >> Cc: Muhanna, Ahmad (RICH1:2H10) >> Subject: >> >> Hi Ahmad, All, >> >> The Binding revocation draft does not mention revocation related to NEMO. >> If used as is, the BRI will revoke the binding between the MR's HoA and >> CoA. >> I think it's woth adding another level of revocation: revocation of Mobile >> Network Prefixes. A HA may decide to stop forwarding data to the CoA for >> certain MNPs and BR could be used for that. Here is a proposed text for a >> new section: >> >> "In case of NEMO protocol, the HA follows the same procedure as MIPv6 if >> the >> goal is to revoke the binding between the Mobile Router's HoA and CoA. It >> is >> also possible to have finer granularity of revocation targeting the Mobile >> Network Prefixes assigned to the Mobile Router. In this case, the HA sends >> a >> BRI message including one or more MNP options with the A bit set and the >> Revocation Trigger set to a proper value, e.g. Administrative Reasons. >> When >> receiving this BRI, the MR deletes the MNP(s) from the Prefix Information >> field in the Binding Update List and responds with a BRA message. The BRA >> MUST include the MNP(s) contained in the BRI." >> >> Also, Mobile network Prefix should be addes as valid option in section >> "6.2. >> Binding Revocation Acknowledgement Message". >> >> BR >> Desire >> >> _______________________________________________ >> MEXT mailing 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 Dec 3 00:06: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 5522E3A68B1; Wed, 3 Dec 2008 00:06:08 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 299FF3A67F0 for ; Wed, 3 Dec 2008 00:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.239 X-Spam-Level: X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=0.360, 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 m6F7aqDvVUQK for ; Wed, 3 Dec 2008 00:06:03 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id EA9723A68B1 for ; Wed, 3 Dec 2008 00:05:43 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1L7mjm-0006SX-Qt; Wed, 03 Dec 2008 09:05:35 +0100 X-Hashcash: 1:20:081203:ryuji.wakikawa@gmail.com::5km//sfYsja2T3So:00000000000000000000000000000000000003TL5 X-Hashcash: 1:20:081203:vijay@wichorus.com::u3NPRdilGD75KxDI:00000000000000000000000000000000000000000000359 X-Hashcash: 1:20:081203:mext@ietf.org::NgDYAGuJMRxXeLFl:000035qB From: arno@natisbad.org (Arnaud Ebalard) To: Ryuji Wakikawa , Vijay Devarapalli X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 Date: Wed, 03 Dec 2008 00:03:39 -0800 Message-ID: <877i6h7kis.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: IETF MEXT WG ML Subject: [MEXT] Comments on draft-ietf-monami6-multiplecoa-10 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Here are some comments and corrections on the latest version of the draft (-10). > 1. Introduction > > A mobile node may use various types of network interfaces to obtain > durable and wide area network connectivity. This is increasingly > become true with mobile nodes having multiple interfaces such as ^^^^^^ becoming > 2. Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC-2119]. > > Terms used in this draft are defined in [RFC-3775], [RFC-3753] and > [RFC-4885]. In addition or in replacement of these, the following > terms are defined or redefined: > > Binding Identification number (BID) > > The BID is an identification number used to distinguish multiple > bindings registered by the mobile node. Assignment of distinct > BIDs allows a mobile node to register multiple binding cache > entries for a given home address. The BIDs assigned to a same > home address MUST NOT be duplicated at a time. Zero and negative > values MUST NOT be used. Each BID is generated and managed by a > mobile node. The BID is stored in the Binding Update List and is > sent by the mobile node in the Binding Update. A mobile node MAY > change the value of a BID at any time according to its > administrative policy, for instance to protect its privacy. BID are protected (encrypted) when exchanged between MN and HA so there is no need in that case. Just to be sure, this privacy concern is only for BID exchanged with CN, right? > 3. Protocol Overview > > [snip] > > The mobile node may return to the home link through one of its > interfaces. There are two options possible for the mobile node when > its returns home. Section 5.6 and Section 5.5.1 describe the ^^^ it > returning home procedures in more detail. > > [snip] > > 2. The mobile node may simultaneously use both the interface > attached to the home link and the interfaces still attached to > the visited link(s) as shown in Figure 3. There are two possible > topologies depending on whether the home agent is only router on ^^^^^^^^ is the only > the home link or not. The operation of Neighbor Discovery [RFC- > 4861] is different in the two topologies. More details can be > found in Section 5.6. The home agent and the correspondent node > have the binding entries listed in Figure 3 in their binding > cache database in both topologies. The home agent also knows > that the mobile node is attached to the home link. All the > traffic from the Internet is intercepted by the home agent first > and routed to either the interface attached to the home link or > the one of the foreign links. How the home agent decides to > route a particular flow to the interface attached to the home > link or foreign link is out of scope in this document. This may create asymetric routing situations. > 4. Mobile IPv6 Extensions > > This section summarizes the extensions to Mobile IPv6 necessary for > manage multiple bindings. ^^^^^^ managing > 4.1. Binding Cache Structure and Binding Update List > > The BID is required to be stored in the binding cache and binding > update list structure. > > The sequence number value MUST be shared among all the binding update > list entries related to binding updates sent to a particular home > agent or correspondent node. Whenever a mobile node sends either > individual or bulk binding update, the sequence number is > incremented. When a home agent receives an individual BU, it should ^^^^^^ Why not making it a MUST? > update the sequence number for all the bindings for a particular > mobile node with the sequence number in the received BU. > > 4.2. Binding Identifier Mobility Option > > The Binding Identifier mobility option is included in the Binding > Update, Binding Acknowledgement, Binding Refresh Request, and Care-of > Test Init and Care-of Test message. 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. > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = TBD | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Binding ID (BID) | Status |O|H| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ > + + > : IPv4 or IPv6 care-of address (CoA) : > + + > +---------------------------------------------------------------+ > > Figure 4: BID Mobility Option > > Type > > Type value for Binding Identifier is TBD > > > > > > > > Wakikawa (Ed.), et al. Expires May 8, 2009 [Page 11] > > Internet-Draft MCoA November 2008 > > > 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 ^^ 8, or am I missing something? > 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 ^^^^ I don't think DSMIPv6 has been introduced before that point. > care-of address field, the length MUST be 12. Otherwise, the ^^ 8 > Length value MUST be set to 20 for IPv6 care-of address. > > Binding ID (BID) > > The BID which is assigned to the binding indicated by the care-of > address in the Binding Update or the BID mobility option. The BID > is a 16-bit unsigned integer. The value of zero is reserved and > MUST NOT be used. > > Status > > The Status field is an 8-bit unsigned integer. When the Binding > Identifier mobility option is included in a Binding > Acknowledgement, this field overwrites the status field in the > Binding Acknowledgement only for this BID. If this field is set > to zero, the receiver ignores this field and uses the registration > status stored in the Binding Acknowledgement message. The > receiver MUST ignore this field if the Binding Identifier mobility > option is not carried within either the Binding Acknowledgement or > the Care-of Test messages. The possible status codes are the same > as the status codes of Binding Acknowledgement. This Status field > is also used to carry error information related to the care-of > address test in the Care-of Test message. > > Overwrite (O) flag > > When this flag is set, all the binding cache entries for a mobile > node are replaced by new entries registering with this binding > update message. This flag is only used when BID Mobility Option > is carried with Binding Update. What about adding at the end. "When present, it must be found in all BID Mobility Option carried in the Binding Update". > > Simultaneous Home and Foreign Binding (H) flag > > This flag indicates that the mobile node registers multiple > bindings to the home agent while is attached to the home link. ^^^^^^^^^^^^^^^^^ while attached > This flag is valid only for a Binding Update sent to the home > agent. No processing requirement here. Maybe a pointer to the interesting section(s) should be added. > > Reserved > > 5 bits Reserved field. The value MUST be initialized to zero by ^ 6 > 5. Mobile Node Operation > > 5.1. Management of Care-of Address(es) and Binding Identifier(s) > > There are two cases when a mobile node might acquire several care-of > addresses. A mixture of the two cases is also possible. Note that a > mobile node can use BID regardless of the number of interfaces and > care-of addresses. Whether a mobile node uses BID or not is > determined by a local configuration. > > 1. A mobile node may be using several physical network interfaces > and acquires a care-of address on each of its interfaces. ^^^^^^^^ acquire > 2. A mobile node uses a single physical network interface, but > receives advertisements for multiple prefixes on the link the > interface is attached to. This will result in the mobile node > configuring several global addresses on the interface from each > of the announced prefixes. > > The difference between the above two cases is only in the number of > physical network interfaces and therefore irrelevant in this > document. What is of significance is the fact that the mobile node > has several addresses it can use as care-of addresses. > > A mobile node assigns a BID to each care-of address when it wants to > register them simultaneously with its home address. The BID MUST be > unique for a given home address and care-of address pair. The value > should be an integer between 1 and 65535. Zero value MUST NOT be > used as BIDs. If a mobile node has only one care-of address, the > assignment of a BID is not needed until it has multiple care-of > addresses to register with, at which time all of the care-of > addresses MUST be mapped to BIDs. Last sentence should be removed. First part does not bring anything and last part has already been stated previously in the document. > 5.5. Returning Home: Using Single Interface > > The mobile node may return to the home link, by attaching to the home > link through one of its interfaces. When the mobile node wants to > return home, it should be configured with information on what > interface it needs to use. Nothing against it (seems logical), but last sentence adds an additional constraint compared to 3775. Any reason? > 5.5.1. Using only Interface attached to the Home Link > > The mobile node returns home and de-registers all the bindings as > shown in Figure 2 and as defined in [RFC-3775]. De-registering all > the bindings is the same as binding de-registration from foreign link > described in Section 5.4. After the de-registration step, all the > packets routed by the home agent are only forwarded to the interface > attached to the home link, even if there are other active interfaces > attached to the visited link(s). While the mobile node de-registers > all the bindings from the home agent, it may continue registering > bindings for interface(s) attached to visited link(s) to the > correspondent node as shown in Figure 2. > > 5.5.2. Using only Interface attached to the Visited Link > > The mobile node returns home in physically and shuts down the > interface attached to the home link. As a result, a mobile node does > not return home even though it attaches to the home link by one of > interfaces. Following procedures should be taken by the mobile node. > Before shutting down the interface, any binding for the care-of > address previously associated with the interface should be deleted. > To delete the binding cache entry, the mobile node SHOULD send a de- > registration Binding Update with the lifetime set to zero and include > the corresponding BID information. If the mobile node does not send > a de-registration Binding Update, the binding for the care-of address > previously assigned to the interface remains at the home agent until > its lifetime expires. > > In this scenario, despite the fact that the mobile node is connected > to its home link, all of its traffic is sent and received via the > home agent and its foreign links. What is the motivation for that scenario? > 5.6. Returning Home: Simultaneous Home and Visited Link Operation > > 5.6.1. Problems of Simultaneous Home and Foreign Attachments > > The mobile node returns home and continues using all the interfaces > attached to both foreign and home links as shown in Figure 3. The > mobile node indicates this by setting the 'H' flag in the BID > mobility option as defined below. There are additional requirements > on the Returning Home procedures for possible Neighbor Discovery > states conflicts at the home link. > > In [RFC-3775], the home agent intercepts packets meant for the mobile > node using the Proxy Neighbor Discovery [RFC-4861] while the mobile > node is away from the home link. When the mobile node returns home, > the home agent deletes the binding cache and stops proxying for the > home address so that a mobile node can configure its home address on > the interface attached to the home link. In this specification, a > mobile node may return home, configure the home address on the > interface attached to the home link, but still use the interfaces > attached to the foreign links. In this case, a possible conflict > arises when the both the home agent and the mobile node try to defend ^^^^^^^^ both > the home address. If the home agent stops proxying for the home > address, the packets are always routed to the interface attached to > the home link and are never routed to the interfaces attached to the > visited links. It is required to avoid the conflict between the home > agent and the mobile node, while still allowing the simultaneous use > of home and foreign links. The following describes the mechanism for > achieving this. > > 5.6.2. Overview and Approach > > In this specification, the home agent MUST intercept all the packets > meant for the mobile node and decide whether to send the traffic > > > > Wakikawa (Ed.), et al. Expires May 8, 2009 [Page 18] > > Internet-Draft MCoA November 2008 > > > directly to the home address on the link or tunnel to the care-of > address. The home agent intercepts all the packets even when the > mobile node is attached to the home link through one of its > interfaces. The home agent would make this decision based on the > type of flow. How to make this decision is out of scope in this > document. > > Two scenarios are illustrated in Figure 3, depending on whether the > Home Agent is the only router at the home link or not. The > difference is on who defends the home address by (Proxy) Neighbor > Discovery on the home link. > > 1. Mobile node defends the home address by the regular Neighbor > Discovery Protocol (illustrated as topology-a in Figure 3). The > home agent is the only router on the home link. Therefore the > home agent is capable of intercepting packets without relying on > the proxy Neighbor Discovery protocol and the mobile node can > manage the Neighbor Cache entry of the home address on the home > link as a regular IPv6 node.　However, there is one ^^^^^^^^ > limitation of this scenario. If a correspondent node is located > at the home link, the home agent may not intercept the packets > destined to the mobile node. These packets are routed only via > the home link, but this is most optimized path for the mobile > node to communicate with nodes on the home link. > > 2. If there are other routers on the home link apart from the home > agent, then it cannot be guaranteed that all packets meant for > the mobile node are routed to the home agent. In this case, the > mobile node MUST NOT operate Neighbor Discovery protocol for the > home address on the home link. This allows the home agent to > keep using proxy neighbor discovery and thus it keeps receiving > all the packets sent to the mobile node's home address. If the > home agent, according to its local policy, needs to deliver > packets to the mobile node over the home link, an issue arises > with respect to how the home agent discovers the mobile node's > link local address. This specification uses Link-layer Address > (LLA) Option defined in [RFC-5268] in order to carry the mobile > node's link-layer address in the Binding Update. Likewise, the > mobile node would also know the link-layer address of the default > router address to send packets from the home link without > Neighbor Discovery. The link-layer address is used to transmit > packets from and to the mobile node on the home link. The > packets are transmitted without the Neighbor Discovery protocol > by constructing the link-layer header manually. This operation > is similar to Mobile IPv6 [RFC-3775] when a mobile node sends a > deregistration binding update to the home agent's link-layer > address in returning home operation. > > > > > Wakikawa (Ed.), et al. Expires May 8, 2009 [Page 19] > > Internet-Draft MCoA November 2008 > > > 5.6.3. Sending Deregistration Binding Update > > o As soon as a mobile node returns home, it sends a de-registration > Binding Update to the home agent from the interface attached to > the home link. > > o The mobile node MUST include the BID mobility option specifying > the BID the mobile node had previously associated with the > interface attached to the home link. associated with the addresses configured on the interface attached to the home link. > The 'H' flag MUST be set in > the BID mobility option. For the binding deregistration, a mobile > node SHOULD NOT store a care-of address in the Care-of Address > field of the BID mobility option. The receive, the home agent, ^^^^^^^ receiver > can match the removed binding with BID value in the BID mobility > option. If the mobile node has to remove multiple bindings > simultaneously, it contains multiple BID mobility options with O > flag set. When the 'H' flag is set, the home agent recognizes > that the mobile node wants to continue using interfaces attached > to both home and visited links. Note that H flag MUST be set for > all the binding updates sent from the mobile node (ex. Binding > Update for the interface(s) attached to the foreign link(s)). If > the home agent does not allow this scenario, it MUST send a > Binding Acknowledgement with the status code [MCOA SIMULTANEOUS > HOME AND FOREIGN PROHIBITED] set. > > o The mobile node SHOULD include the Link-layer Address (LLA) Option > [RFC-5268] to notify the mobile node's link-layer address to the > home agent, too. The option code of the Link-layer Address (LLA) > option MUST be set to '2' (Link-layer Address of the mobile node). > This link-layer address is required for the home agent to send the > Binding Acknowledgement and to forward the mobile node's packet. > > o According to [RFC-3775], the mobile node MUST start responding to > Neighbor Solicitation for its home address right after it sends > the deregistration Binding Update to the home agent. However, in > this specification, the mobile node MUST NOT respond to Neighbor > Solicitation before receiving a Binding Acknowledgement, since the > home agent may continue proxying for the home address. If the > mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value > in the received Binding Acknowledgment, it MUST NOT respond to > Neighbor Solicitation even after the Binding Acknowledgement. > > 5.6.4. Sending Binding Acknowledgement > > o When the home agent sends the Binding Acknowledgement after > successfully processing the binding de-registration, it MUST set > the status value to either 0 [Binding Update Accepted] or to [MCOA > RETURNHOME WO/NDP (TBD)] in the Status field of the Binding > Acknowledgment depending on home agent configuration at the home > > > > Wakikawa (Ed.), et al. Expires May 8, 2009 [Page 20] > > Internet-Draft MCoA November 2008 > > > link. The new values are: > > * Binding Update Accepted (0): NDP is permitted for the home > address at the home link. This is regular returning home > operation of [RFC-3775] > > * MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home > address at the home link > > If the binding update is rejected, the appropriate error value > MUST be set to the status field. In this case, the home agent > operation is same as [RFC-3775]. > > o Only if the home agent is certainly the only router in the home > link, it MAY turn off Neighbor Discovery for the requested home > address and responds with the [Binding Update Accepted] status > value to the mobile node. Since the mobile node will not reply to > Neighbor Solicitation for the home address before receiving the > Binding Acknowledgement, the home agent SHOULD use the link-layer > address carried by the Link Layer Address option [RFC-5268] in the > received Binding Update. After the completion of the binding > deregistration, the mobile node starts regular Neighbor Discovery > operations for the home address on the home link. The neighbor > cache entry for the home address is created by the regular > exchange of Neighbor Solicitation and Neighbor Advertisement. > > o On the other hand, the home agent returns [MCOA RETURNHOME WO/NDP] > value in the Status field of the BID mobility option. The home > agent learns the mobile node's link-layer address by receiving the > link-layer address option carried by the Binding Update. It > stores the link-layer address as a neighbor cache entry for the > mobile node so that it can send the packets to the mobile node's > link-layer address. > > o Note that the use of proxy Neighbor Discovery is easier way to ^^^^^^ the easiest > intercept the mobile nodes' packets instead of IP routing in some > deployment scenarios. Therefore, even if a home agent is the only > router, it is an implementation and operational choice whether the > home agent returns [Binding Update Accepted] or [MCOA RETURNHOME > WO/NDP]. > > o If BID option is not included in the Binding Acknowledgement, the > home agent might not recognize the simultaneous home and foreign > attachment. The home agent might have processed the de- > registration Binding Update as a regular de-registration as > described in [RFC-3775] and deletes all the registered binding ^^^^^^^ deleted > cache entries for the mobile node. Thus, the mobile node SHOULD > stop using the interface attached to foreign link and use only the ^^^^ links > > > > Wakikawa (Ed.), et al. Expires May 8, 2009 [Page 21] > > Internet-Draft MCoA November 2008 > > > interface attached to the home link. > > 5.6.5. Sending Packets from the Home Link > > o When the mobile node receives the Binding Acknowledgement with the > status value 'Binding Update Accepted' and the BID option, it can > configure its home address to the interface attached to the home > link and start operating Neighbor Discovery for the home address > on the home link. Packets can be transmitted from and to the > mobile node as if the mobile node is a regular IPv6 node. > > o If the mobile node receives the status [MCOA RETURNHOME WO/NDP] in > the Binding Acknowledgement, it MUST NOT operate Neighbor > Discovery for the home address. When the mobile node sends > packets from the interface attached to the home link, it MUST > learn the link-layer address of the next hop (i.e. default router > of the mobile node). A mobile node learns the default router's > link-layer address from a Source Link-Layer Address option in > Router Advertisements. The mobile node sends packets directly to > the default router's link-layer address. This is done by > constructing the packet including link-layer header with the > learned link-layer address of the default router. The home agent > also forwards the packet to the mobile node on the home link by > using the mobile node's link-layer address. The link-layer > address SHOULD be cached when the home agent received the ^^^^^^^^ receives > 5.7. Receiving Binding Acknowledgement > > The verification of a Binding Acknowledgement is the same as Mobile > IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a > Binding Acknowledgement is described in Section 6.2. > > If a mobile node includes a Binding Identifier mobility option in a > Binding Update with the 'A' flag set, a Binding Acknowledgement MUST > carry a Binding Identifier mobility option. According to [RFC-3775], > the receiver of the Binding Update ignores unknown mobility options > and process the Binding Update without the unknown mobility option. > Therefore, if no such mobility option is included in the Binding > Acknowledgement in response to a Binding Update for multiple care-of > address registration, this indicates that the originating node of the > Binding Acknowledgement does not support processing the Binding > Identifier mobility option regardless of status value. In such case, > the receiver of the Binding Update may create a regular binding. The > mobile node then stop multiple care-of address registration with that > node. If it is home registration, the mobile node MAY attempt to > discover another home agent supporting BID mobility option for the > home registration. > > If a Binding Identifier mobility option is present in the received > Binding Acknowledgement, the mobile node checks the status field in > the option. If the status value in the Binding Identifier mobility > option is zero, the mobile node uses the value in the Status field of > the Binding Acknowledgement. Otherwise, it uses the value in the > Status field of the Binding Identifier mobility option. > > If the status code is greater than or equal to 128, the mobile node > starts relevant operations according to the error code. Otherwise, > the mobile node assumes that the originator (home agent or > correspondent node) successfully registered the binding information > and BID for the mobile node. > > o If the Status value is [MCOA PROHIBITED], the mobile node MUST > stop registering multiple bindings to the node that sent the > Binding Acknowledgement. > > o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the > mobile node SHOULD stop using bulk registrations with the node > that sent the Binding Acknowledgement. > > > > Wakikawa (Ed.), et al. Expires May 8, 2009 [Page 23] > > Internet-Draft MCoA November 2008 > > > o If [MCOA MALFORMED] is specified, it indicates that the binding > identifier mobility option is formatted wrongly. ^^^^^^^^^^^^^^^^^ wrongly formatted > > o If [MCOA BID CONFLICT] is specified, the binding entry specified > by the Binding Identifier mobility option is already registered as > a regular binding. In such case, the mobile node SHOULD stop > sending Binding Updates with BID, or SHOULD use the 'O' flag to > reset all the registered bindings. > > 5.8. Receiving Binding Refresh Request > > The verification of a Binding Refresh Request is the same as in > Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of sending > a Binding Refresh Request is described in section Section 6.3. ^^^^^^^^^^^^^^^ remove one > If a mobile node receives a Binding Refresh Request with a Binding > Identifier mobility option, it indicates that the node sending the > Binding Refresh Request message is requesting the mobile node to send > a new Binding Update for the BID. The mobile node SHOULD then send a > Binding Update at least for the respective binding. The mobile node > MUST include a Binding Identifier mobility option in the Binding > Update. > > 5.9. Bootstrapping > > When a mobile node bootstraps and registers multiple bindings for the > first time, it MUST set the 'O' flag in the Binding Identifier > mobility option. If old bindings still exists at the home agent, the > mobile node has no knowledge of which bindings still exist at the > home agent. This scenario happens when a mobile node reboots and > looses state regarding the registrations. If the 'O' flag is set, > all the bindings are replaced by the new binding(s). If the mobile > node receives the Binding Acknowledgement with the status code set to > 135 [Sequence number out of window], it MUST follow the operations > described in [RFC-3775]. > > The 'O' flag can also be used in individual Binding Updates sent to > the correspondent nodes to override any existing binding cache > entries at the correspondent node. > > > > > > > > > > > > > Wakikawa (Ed.), et al. Expires May 8, 2009 [Page 24] > > Internet-Draft MCoA November 2008 > > > 6. Home Agent and Correspondent Node Operation > > 6.1. Searching Binding Cache with Binding Identifier > > If either a correspondent node or a home agent has multiple bindings > for a mobile node in their binding cache database, it can use any of > the bindings to communicate with the mobile node. This section > explains how to retrieve the desired binding for the binding > management. This document does not provide any mechanism to select > the suitable binding for forwarding data packets. > > A node which is either a correspondent node or a home agent SHOULD > use both the home address and the BID as the search key of the > binding cache if it knows the corresponding BID (ex. when processing > signaling messages). In the example below, if a node searches the > binding with the home address and BID2, it gets binding2 for this > mobile node. > > binding1 [2001:db8::EUI, care-of address1, BID1] > binding2 [2001:db8::EUI, care-of address2, BID2] > binding3 [2001:db8::EUI, care-of address3, BID3] > > Figure 7: Searching the Binding Cache > > The node learns the BID when it receives a Binding Identifier > mobility option. At that time, the node MUST look up its binding > cache database with the home address and the BID retrieved from the > Binding Update. If the node does not know the BID, it searches for a > binding with only the home address. In such a case, the first > matched binding is found. If the node does not desire to use > multiple bindings for a mobile node, it can simply ignore the BID. > > 6.2. Processing Binding Update > > If a Binding Update does not contain a Binding Identifier mobility > option, its processing is same as in [RFC-3775]. If the receiver > already has multiple bindings for the home address, it MUST replace > all the existing bindings by the received binding. As a result, the > receiver node MUST have only one binding cache entry for the mobile > node. If the Binding Update is for de-registration, the receiver > MUST delete all existing bindings from its Binding Cache. > > If the Binding Update contains a Binding Identifier mobility > option(s), it is first validated according to section 9.5.1 of [RFC- > 3775]. Then the receiver processes the Binding Identifier mobility > option(s) as described in the following steps. > > > > > > Wakikawa (Ed.), et al. Expires May 8, 2009 [Page 25] > > Internet-Draft MCoA November 2008 > > > o The length value is examined. The length value MUST be either 4, > 8, or 20 depending on the Care-of Address field. If the length is > incorrect, the receiver MUST reject the Binding Update and returns > the status value set to [MCOA MALFORMED]. > > o When the Length value is either 12 or 20, the care-of address MUST ^^ 8 > be present in the Binding Identifier mobility option. If the > valid care-of address is not present, the receiver MUST reject the > Binding Identifier mobility option and returns the status value > set to [MCOA MALFORMED]. > > o When multiple Binding Identifier mobility options are present in > the Binding Update, it is treated as bulk registration. If the > receiving node is a correspondent node, it MUST reject the Binding > Update and returns the status value in the binding Acknowledgement > set to [MCOA BULK REGISTRATION NOT SUPPORT] > > o If the Lifetime field in the Binding Update is set to zero, the > receiving node deletes the binding entry that corresponds to the > BID in the Binding Identifier mobility option. If the receiving > node does not have an appropriate binding for the BID, it MUST > reject the Binding Update and send a Binding Acknowledgement with > status set to 133 [not home agent for this mobile node]. > > o If the 'O' flag is set in the de-registering Binding Update, it is > ignored. If the 'H' flag is set, the home agent stores a home > address in the Care-of Address field of the binding cache entry. > The home agent MUST follow the descriptions described in > Section 5.6. > > o If the Lifetime field is not set to zero, the receiving node > registers a binding with the specified BID as a mobile node's > binding. The Care-of address is obtained from the Binding Update > packet as follows: > > * If the Length value of the Binding Identifier mobility option > is 20, the care-of address is copied the IPv6 address from the > care-of address field in the Binding Identifier mobility > option. When the Length value is 12, the address MUST be the ^^ 8 > IPv4 valid address. Detail information can be found in > Section 8. > > * If the Length value of the Binding Identifier mobility option > is 4, the care-of address is copied from the source address > field of the IPv6 header. > > * If the Length value of the Binding Identifier mobility option > is 4 and an alternate care-of address is present, the care-of > > > > Wakikawa (Ed.), et al. Expires May 8, 2009 [Page 26] > > Internet-Draft MCoA November 2008 > > > address is copied from the Alternate Care-of address mobility > option. > > o Once the care-of address(es) have been retrieved from the Binding > Update, the receiving nodes creates new binding(s). > > * If 'O' flag is not set in all the Binding Identifier options, > the home agent MUST return the status value [MCOA MALFORMED] by > Binding Acknowledgement. > > * If the 'O' flag is set in the Binding Identifier mobility > option, the home agent removes all the existing bindings and > registers the received bindings. > > * If the receiver has a regular binding which does not have BID > for the mobile node, it must not process the binding update. > The receiver should sent a binding acknowledgement with status > set to [MCOA BID CONFLICT]. > > * If the receiver already has a binding with the same BID but > different care-of address, it MUST update the binding and > respond with a Binding Acknowledgement with status set to 0 > [Binding Update accepted]. > > * If the receiver does not have a binding entry for the BID, it > registers a new binding for the BID and responds with a Binding > Acknowledgement with status set to 0 [Binding Update accepted]. > > If all the above operations are successfully completed, a Binding > Acknowledgement containing the Binding Identifier mobility options > MUST be sent to the mobile node. Whenever a Binding Acknowledgement > is sent, all the Binding Identifier mobility options stored in the > Binding Update MUST be copied to the Binding Acknowledgement except > the status field. The Care-of address field in each Binding > Identifier mobility option, however, can be omitted, because the > mobile node can match a corresponding binding update list entry using > the BID. > > When a correspondent node sends a Binding Acknowledgement, the status > value MUST be always stored in the Status field of the Binding > Acknowledgement and the Status field of Binding Identifier mobility > option MUST be always set to zero. > > When the home agent sends a Binding Acknowledgement, the status value > can be stored in the Status field of either a Binding Acknowledgement > or a Binding Identifier mobility option. If the status value is > specific to one of bindings in the bulk registration, the status ^^ of the > value MUST be stored in the Status field in the corresponding Binding > > > > Wakikawa (Ed.), et al. Expires May 8, 2009 [Page 27] > > Internet-Draft MCoA November 2008 > > > Identifier mobility option. In this case, [MCOA NOTCOMPLETE] MUST be > set to the Status field of the Binding Acknowledgement so that the > receiver can examine the Status field of each Binding Identifier > mobility option for further operations. Otherwise, the status field > of the Binding Identifier mobility option MUST be set to zero and the > home agent status field of the Binding Acknowledgement is used. > > 6.3. Sending Binding Refresh Request > > When a node (home agent or correspondent node) sends a Binding > Refresh Request for a particular binding created with the BID, the > node SHOULD include the Binding Identifier mobility option in the > Binding Refresh Request. The node MAY include multiple Binding > Identifier mobility options if there are multiple bindings that need > to be refreshed. > > 6.4. Receiving Packets from Mobile Node > > When a node receives packets with a Home Address destination option > from a mobile node, it MUST check that the care-of address that > appears in the source address field of the IPv6 header MUST be equal ^^^^^^^ there is already a MUST at the beginning of the sentence: is BTW, am I wrong to think that this requirement prevents the initial registration? > 8. DSMIPv6 Applicability I skipped this section. > 9. IPsec and IKEv2 interaction > > Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the > use of IPsec to protect signaling messages like Binding Updates, > Binding Acknowledgements and return routability messages. IPsec may > also be used protect all tunneled data traffic. The Mobile IPv6- > IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to > setup the required IPsec security associations. The following > assumptions were made in [RFC-3775], [RFC-3963] and [RFC-4877] with > respect to the use of IKEv2 and IPsec. > > o There is only one primary care-of address per mobile node. > > o The primary care-of address is stored in the IPsec database for > tunnel encapsulation and decapsulation. > > o When the home agent receives a packet from the mobile node, the > source address is verified against the care-of address in the > corresponding binding cache entry. If the packet is a reverse > tunneled packet from the mobile node, the care-of address check is > done against the source address on the outer IPv6 header. The > reverse tunnel packet could either be a tunneled HoTi message or > tunneled data traffic to the correspondent node. > > o The mobile node runs IKEv2 (or IKEv1) with the home agent using > the care-of address. The IKE SA is based on the care-of address > of the mobile node. > > The above assumptions may not be valid when multiple care-of > addresses are used by the mobile node. In the following sections, > the main issues with the use of multiple care-of address with IPsec > are addressed. > > 9.1. Use of Care-of Address in the IKEv2 exchange > > For each home address the mobile node sets up security associations > with the home agent, the mobile node must pick one care-of address > and use that as the source address for all IKEv2 messages exchanged > to create and maintain the IPsec security associations associated > with the home address. The resultant IKEv2 security association is > created based on this care-of address. > > If the mobile node needs to change the care-of address, it just sends > a Binding Update with the care-of address it wants to use, with the > corresponding Binding Identifier mobility option, and with the 'K' > bit set. This will force the home agent to update the IKEv2 security > association to use the new care-of address. What about adding a pointer to [MIGRATE] as a possible solution to do that (draft-ebalard-mext-pfkey-enhanced-migrate-00). >From a general standpoint, this has probably already been discussed, but the handling of the Home Network case adds a lot of complexity to something pretty simple at the beginning. Moreover, the various cases to support using the foreign links when at home also add complexity on top of that w/o providing motivation for this scenario. Even if this has already been extensively discussed on the list (I did not browse the archives), this should probably be introduced in the doc. Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 3 01:38: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 C3EBA28C0F5; Wed, 3 Dec 2008 01:38:38 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 014C828C0F7 for ; Wed, 3 Dec 2008 01:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 HQxpJhZQ4Fin for ; Wed, 3 Dec 2008 01:38:35 -0800 (PST) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.233]) by core3.amsl.com (Postfix) with ESMTP id A00D428C0F3 for ; Wed, 3 Dec 2008 01:38:35 -0800 (PST) Received: by qb-out-0506.google.com with SMTP id d11so1000191qbd.41 for ; Wed, 03 Dec 2008 01:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:from; bh=IQm1HDGKCNKCEHc420FbHHeN1FSY9ip5Z9Fgcdcd+SA=; b=Un/jGcym2SCXRV5IGz/WrF86oEu++ywNShCegPdhgWi4XkdqClYxtTMB2PrAnIGcXd jImCCp2e5WOZ7Grxn+aIKvcXZYZ/z7dUa7X1NQKTShszEHK2FByilBmKPW6LgvRLPj5m DkZTxaXmuEJ4fvNXqQspuq0HXC6DktY6AEVUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding:from; b=IyG3LLcw5X4zi72Dtaqrf0zGeq2/L2ruuwEHYjDr5PQWMO4g8DzFgdkC03qsM51y/v qbF9j0jtj5tJqlCge6HeBkWN6fhroZbphOj/4Xcub7yAaPfxKRHMVEyV0olyNWtTnXRz bSjGzorlPSa9Wj2Lxv+RQsgRTIfXhRuguSeQc= Received: by 10.67.40.6 with SMTP id s6mr1587785ugj.10.1228297109724; Wed, 03 Dec 2008 01:38:29 -0800 (PST) Received: from ?10.10.11.177? ([195.189.59.44]) by mx.google.com with ESMTPS id o7sm8098761uge.0.2008.12.03.01.38.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Dec 2008 01:38:28 -0800 (PST) Message-ID: <49365395.1060301@googlemail.com> Date: Wed, 03 Dec 2008 10:38:29 +0100 User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: fan zhao References: <200811251254.47129.julien.laganier.IETF@googlemail.com> <200811261406.57408.julien.laganier.IETF@googlemail.com> In-Reply-To: From: Julien Laganier Cc: netlmm@ietf.org, mext@ietf.org Subject: Re: [MEXT] [netlmm] question on the DHCP-PD X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Fan, fan zhao wrote: > On Wed, Nov 26, 2008 at 5:06 AM, Julien Laganier wrote: >> On Wednesday 26 November 2008, fan zhao wrote: >>> wrote: >>>> On Friday 21 November 2008, fan zhao wrote: >>>>> My question is when the MN connects to a source access network >>>>> using PMIP (or other type of network >>>>> based mobility protocol), it obtains a home network prefix. Then >>>>> the MN handovers to a target access >>>>> network (i.e. the foreign link for the MN) using the Mobile IPv6. >>>>> The handover procedure is as follows. >>>>> >>>>> 1) The MN obtains a care-of address from the target access >>>>> network. 2) The MN discovers the home agent if it does not know. >>>>> 3) The MN sets up the IPsec SA with the HA if it does not have the >>>>> SA with the HA before. >>>>> 4) During the step 3), the MN requests the HNP allocated from the >>>>> HA based on RFC 4877/5026. >>>>> 5) The MN realizes it is on the foreign link, then it needs to >>>>> send the BU to the HA. >>>>> Since the Mobile IPv6 BU can only register the binding between the >>>>> CoA and one single home address, >>>>> in order to register the binding between the HNP and the CoA, the >>>>> MN needs to use >>>>> the NEMO extensions, for example, by setting up the 'R' bit and >>>>> using the implicit mode. >>>> There's no need to involve NEMO. You are confusing the notion of >>>> Home Network Prefix with that of a NEMO Mobile Network Prefix: The >>>> Home Network Prefix is a prefix advertized on the Home Link (by the >>>> HA or a router in MIPv6 case, or a MAG in PMIPv6 case), while a >>>> NEMO Mobile Network Prefix is a prefix delegated to a Mobile Router >>>> and advertised in the Mobile Network. These are different cases. >>> I completely agree with you on this. The home agent needs to know and >>> set up the states for both the home network prefix and the mobile >>> network prefix even though they may be the same. >> The whole point is: The case where the Home Network Prefix and the >> Mobile Network Prefix are the same doesn't make any sense in the >> context of NEMO. >> >> The Home Network Prefix is advertized and used on the point-to-point >> link between the MAG and the MN - or MR in the case we're discussing. > That is correct in the PMIP domain. However, when the MN handovers to > a foreign access network with the MIP used, the Home Network Prefix can > be associated with the MN's logical/physical interface, right? Why? The MN has Home Address(es) configured within the Home Network Prefix. If it goes away from home, it register said Home Address(es) with its Home Agent. Without putting PMIPv6 in the picture, this is what happens with plain Mobile IPv6, i.e. the MN does not create a binding for the whole Home Network Prefix advertized on the Home Link, it simply creates binding for its Home Address(es). Since the mechanism work just fine for a Mobile Node moving from a PMIPv6 Home Link to a foreign access network and thus needs to use MIPv6, there's no reason for "the Home Network Prefix [to] be associated with the MN's logical/physical interface", as you put it. > Note that the case what I talked about is that a plain mobile IP terminal > (not a MR) handovers between the PMIP and CMIP access network. I understand that perfectly. I am saying that MIPv6 as-is handles both the case of a MN doing a handover from a MIPv6 home link to a foreign network, and that of a MN doing a handover from a PMIPv6 home link to a foreign network. Thus there's no need to extend MIPv6, PMIPv6, or involve NEMO, and DHCP PD in the picture. I am not going to reply to the rest of your note since I do not agree a protocol extension is required. Regards, --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 3 01:50:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588D53A6870; Wed, 3 Dec 2008 01:50:51 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86B7D3A6870; Wed, 3 Dec 2008 01:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 T0Ko-idLVGaE; Wed, 3 Dec 2008 01:42:54 -0800 (PST) Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by core3.amsl.com (Postfix) with ESMTP id 7AE7C3A6B42; Wed, 3 Dec 2008 01:42:54 -0800 (PST) Received: from starkperkins.demon.co.uk ([80.176.158.71]:63160 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1L7oFs-0000zM-4V; Wed, 03 Dec 2008 09:42:48 +0000 In-Reply-To: <493591AC.2030303@piuha.net> References: <493591AC.2030303@piuha.net> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <066113AC-B0BC-4817-9FE3-1F953FC7D770@csperkins.org> From: Colin Perkins Date: Wed, 3 Dec 2008 09:42:44 +0000 To: Jari Arkko X-Mailer: Apple Mail (2.753.1) X-Mailman-Approved-At: Wed, 03 Dec 2008 01:50:50 -0800 Cc: "mext@ietf.org" , TSV Dir , ietf@ietf.org Subject: Re: [MEXT] tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On 2 Dec 2008, at 19:51, Jari Arkko wrote: > Thanks for your review, Colin. > > I agree that fixes or better explanations of the background should > be given for the points that you raised. It seems that you and > Hesham are making progress on what needs to be added to the > document, great! > > The only item that I too am somewhat worried about in your list is > the address replacement by broken NATs and the tricks used to > prevent that. I feel that the best way to deal with that is to > document this as a potential problem -- the protocol already has > tools to provide a far better obfuscation technique than XOR -- > just turn on encryption if this turns out to be a problem and the > device in question cannot be ripped out of the network. Agreed. > Do we have any information about how widespread such NATs might be? > RFC 5389 just says "some NATs". Not really, but something that broken can't be common: it'd cause too many obvious problems. -- Colin Perkins http://csperkins.org/ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 3 02:09:32 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A3FB3A6B4F; Wed, 3 Dec 2008 02:09:32 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6EE428C0FD for ; Wed, 3 Dec 2008 02:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Taj9Xq+AHsK for ; Wed, 3 Dec 2008 02:09:29 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 568B03A685D for ; Wed, 3 Dec 2008 02:09:29 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 0636A2C0004E3; Wed, 3 Dec 2008 11:09:25 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6h-36PBivzBH; Wed, 3 Dec 2008 11:09:24 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id CDC2D2C000359; Wed, 3 Dec 2008 11:09:14 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 3 Dec 2008 11:09:13 +0100 Message-ID: <547F018265F92642B577B986577D671C4FBFEE@VENUS.office> In-Reply-To: <49343B1B.8080707@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Comments on draft-ietf-mext-nemo-ro-automotive-req-01.txt Thread-Index: AclT6yng/A4MFVuRQYWsgJ8YgrvBtgBOwrNQ From: "Roberto Baldessari" To: "Alexandru Petrescu" Cc: mext Subject: Re: [MEXT] Comments on draft-ietf-mext-nemo-ro-automotive-req-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Dear Alex, > > > > Regarding IPv6-over-11p, nothing needs to be specified as > 11p does not > > amend changes to 802.11 as far as this is concerned. The same > > mechanism as for 802.11 apply (802.11+802.2+SNAP). > > It is good to note the same IPv6 mechanism for 802.11 > (802.11+802.2+SNAP) applies to IPv6 over 802.11p. > > I think this assumption is worth noting in the draft. > > Yet I have some doubts about the use of ND over 802.11p. > > One reason of my doubts is because the 802.11p draft I can > access is not the latest - maybe things changed. I'm using > "IEEE Trial-Use Standard for Wireless Access in Vehicular > Environments (WAVE)-Networking Services" 20 IEEE Std > 1609.3(tm)-2007 20 April 2007. I'm not even sure whether that's > what we mean by "802.11p". > IEEE 802.11p and IEEE 1609.X are two separate standard drafts. The 1609 family specifies additional protocols (WSMP) and mechanisms to be used on top/in combination of/with 802.11p. In Europe 1609 does not have much consensus for various reasons. ETSI is likely to make a profile of 802.11p and redefine some functionalities that are offered by 1609 but in a different way. Further, 11p and 1609 are going to change. The latest 11p version is D4.02, Sept 2008. Many amendments have been removed. So 11p will be very similar to a 11a 'pseudo ad-hoc' mode. To cut the story short, 1609 is not assumed in the draft. Feel free to contact me offline if you need more info (I feel we're getting out of scope of this ML). > This document has explicit assumptions on the use of IPv6. > Among others, for example, section 4.5 "IPv6 Neighbor Cache" > makes explicit assumptions about how the NC is filled with > addresses. It is stated, for example : "... so alternate > methods for generating the Neighbor Cache are defined. Note > that neighbor discovery is not precluded in cases where it > might be needed." > > It would probably be appropriate for a MEXT method achieving > direct paths ("RO"?) between two vehicular MRs without > infrastructure - to say that "if ND is needed with these > P1609.3 systems, ND is used in this and that way". > > You may wonder why I'm talking ND here. I do so at least > because Mobile > IPv6 and NEMOv6 do talk ND at some point. So this could be pertinent. > Concerning NEMO BS RO requirements, I currently don't see the need for specific requirements on ND. Whereas concerning the specification of IPv6-over-ETSIgeonetworking ND should be discussed. ND extensions you probably have in mind are in the scope of those specifications rather than here. > > > > You're right, the definition is missing. Among the authors > we did not > > have 100% consensus on this term. The terms 'V2V' and 'V2I' > are used > > in many automotive documents to distinguish whether or not the > > infrastructure is involved. So V2I2V can be seen as part of V2I, > > according to this criterion and therefore I think the term can be > > removed (in fact it only appears in the second part). We'll > rediscuss > > this point. > > Ah I see... the point of V2I2V being actually two times a V2I > makes sense to me. This explanation could be added when the > term V2I2V is mentioned first. Or it could be discussed further. > Agreed. > > I agree, thank you. Maybe describing link-layer multi-hops > as not decrementing the Hop Limit field in the IPv6 base > header (akin to IPv4 > TTL) could do. Anyways, defining link behaviour in terms of > what happens to Hop Limit is easily understood often, I think. > we'll come up with something like this. > >> > > > > Newly deployed means that we have more design freedom as > compared to > > legacy IPv6 nodes. I think the distinction is important. You might > > want to suggest a different terminology. > > Whereas I agree with you a CE may be new compared to an > IPv6-but-non-NEMOv6 Mobile Router, I don't agree CE is new > compared to a > NEMOv6 Mobile Router. It's difficult to understand what new > means here. > non-NEMOv6 Mobile Router is out of scope here. Some may say it is an oxymoron RFC 4885 does not say MR neessarily runs NEMO BS. But the scope of the draft is NEMO BS RO. Regarding the CE see below. > CE is a new term indeed, but it designates an existing MR > plus RO _sometimes_. > I don't agree with the last sentence. According to RFC 4885, CE is either CR (NEMOv6-RO-enabled NEMOv6 MR) or a CN, which can be either a plain IPv6 host or a NEMOv6-RO-enabled IPv6 host. In fact RFC 4885 defines CN as "Any node that is communicating with one or more MNNs". For this reason I think CE is appropriate, because is the most general term you could use. Newly deployed CEs simply means CEs that can be deployed together with the NEMO RO mechanisms that is the subject of requirements. If this is not clear we can add some text. > >> Before Req 1 I would suggest Req 0 'Reusability' to reuse > an existing > >> protocol. > >> > > > > Please elaborate. > > Thanks for asking. I meant to say something about the > necessity to re-use an existing protocol. This could be > Mobile IPv6 and/or ND. > NEMOv6 is not a protocol per se, but an extension to Mobile > IPv6. In this sense, the requirements would better be better > scoped, (1) eliminating the possibility of designing, for > example, an UDP-based message exchange for security > credentials (maybe IKE) to achieve optimal paths. And also > eliminating any new exchange designed out of nothing, like > for example an xml-based http exchange for achieving same goals. > I think reusage of existing protocols is always required in IETF. I'm not convinced we need to write this explicitely. > >> For req 1, I don't understand 'per-flow' - what's a flow? > Does it use > >> the flow label in the IPv6 header? Or is it another newly defined > >> term? > >> > > > > Flow is used in so many RFCs without defining it. Even RFC 2460 > > defines Flow Labeling Capability without defining what a > flow is (Sec > > 1). Did I maybe miss the RFC where the term flow is defined? > > I think flow has many different co-notations and the only > formally implemented is the Flow Label. This draft's > per-flow behaviour doesn't assume flow labels because, for > example, it says at some point: > > The IP version 6 is the version considered for IP types of flows. > > [datagrams?] > and later on > > a particular IPv6 flow [a flow label?] > > I'm not trying to confuse anybody, but it is confusing to me. > Or maybe some readers can easily disambiguate these occurences. > Got the point. We'll try to clarify it. Best regards, Roberto _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 3 09:59: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 AFAB63A6882; Wed, 3 Dec 2008 09:59:57 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30FCB3A6882 for ; Wed, 3 Dec 2008 09:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3ZTtrJxzM4Y for ; Wed, 3 Dec 2008 09:59:56 -0800 (PST) Received: from web111409.mail.gq1.yahoo.com (web111409.mail.gq1.yahoo.com [67.195.15.180]) by core3.amsl.com (Postfix) with SMTP id E04A13A67E2 for ; Wed, 3 Dec 2008 09:59:55 -0800 (PST) Received: (qmail 19339 invoked by uid 60001); 3 Dec 2008 17:59:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=FzKUupfbKh8sQ8S9eMvNnN1G9jRLK5IAgYuyeRwZujHQj4PW+zXtTtGUGqlAEpqitw5S4EyoUwB0P3QXo+i+g7XaUvm0E9//Z/Gf8VKyP6P578Mj5FvAQuOt9jtse//dMs4dNejNTgp8s8MdJEFHPjDtmri4DflpMLg3JWTrKmw=; X-YMail-OSG: ejohcVsVM1kFtsM1ZCEWyPzz7Z7BmkGU7aXGgXsnyyicZQB2VA8LETf9N7BHcAaZmhWmpZP6_PHDe9GkZ.p_K7hKviN3w_J8jsMjkBVY4aM8GJ4VBP_y7IbnPn4kL_cZX7E0gJeAlTYfSsri.JL_IOcXPE74pfh0esRXgCHErMB.a5M- Received: from [206.16.17.212] by web111409.mail.gq1.yahoo.com via HTTP; Wed, 03 Dec 2008 09:59:51 PST X-Mailer: YahooMailRC/1155.32 YahooMailWebService/0.7.260.1 References: <570090.92095.qm@web111410.mail.gq1.yahoo.com> <496302.84429.qm@web111411.mail.gq1.yahoo.com> Date: Wed, 3 Dec 2008 09:59:51 -0800 (PST) From: Behcet Sarikaya To: fan zhao MIME-Version: 1.0 Message-ID: <356714.19242.qm@web111409.mail.gq1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase 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="===============0062123079==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0062123079== Content-Type: multipart/alternative; boundary="0-549171330-1228327191=:19242" --0-549171330-1228327191=:19242 Content-Type: text/plain; charset=us-ascii ________________________________ From: fan zhao To: Behcet Sarikaya Cc: mext@ietf.org Sent: Tuesday, December 2, 2008 5:47:35 PM Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase Hi Behcet, There is a difference between binding revocation for MNPs and MNP release. When the binding revocation for MNPs is performed, the MNP information stored in the binding cache entry for the MR is removed, which means that the packets for such MNP will not be tunneled by the HA; however, such MNP is not explicitly released by the binding revocation. This is needed because the mobile network nodes connecting to the MR before may handover to their home network (such as wimax) while the MR still stays in its foreign link (since for example the MR does not have the wimax interface); therefore, such MNP should still be made valid for such mobile network nodes. To release such MNP, the same method to allocate the MNP should be used. For example, if the MNP is allocated by using DHCP, then DHCP needs to be used again to remove such MNP. This is similar to the MIPv6 case where the MN sends the BU with the lifetime=zero or the HA sends the BRI to remove the binding, the home address on the other hand needs to remove by deleting the IPsec SA if this is detach. It makes sense to me using the BR to remove the MNP from the BCE since such MNP is registered by using BU and BR is the opposite way to BU. [behcet ] So it is the MR that knows thesituation and MR should initiate MNP release. Doing it with BR would be server-initiated which is something to be considered for prefix renumbering which has nothing to do with the release. Sincerely, fan On Tue, Dec 2, 2008 at 2:50 PM, Behcet Sarikaya wrote: > Hi Fan, > Prefix delegation/authorization function should take care of this. In DHCP > PD there is a way to release the prefixes. > > Regards, > > Behcet > > ________________________________ > From: fan zhao > To: Behcet Sarikaya > Cc: Ahmad Muhanna ; mext@ietf.org > Sent: Tuesday, December 2, 2008 3:41:56 PM > Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO > usecase > > Hi Behcet, > > The binding revocation is designed for DSMIPv6 and DSMIPv6 supports > both mobile host > and mobile router. I do not see any issue. > > Sincerely, > fan > > On Tue, Dec 2, 2008 at 11:52 AM, Behcet Sarikaya > wrote: >> Hi Ahmad, >> Can you please explain how MNP is related to your draft? MNP is something >> that MR needs and is specific to Nemo operation not to MN-HA relationship >> and the binding that comes with it. >> So I don't see any binding to revocate with MNPs? >> >> Regards, >> >> Behcet >> >> ________________________________ >> From: Ahmad Muhanna >> To: Desire Oulai ; mext@ietf.org >> Sent: Monday, December 1, 2008 9:22:35 PM >> Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO >> usecase >> >> Hi Desire, >> >> Added a relative subject. >> >> I guess the usecase is clear and it makes sense to me. >> We can add some text similar to yours to capture this functionality under >> the HA and MN operations after the conclusion of the WGLC.. >> >> BTW: Is there anyone who thinks that we should not add this usecase? >> >> Regards, >> Ahmad >> >> >> >> ________________________________ >> From: Desire Oulai [mailto:desire.oulai@ericsson.com] >> Sent: Monday, December 01, 2008 2:46 PM >> To: mext@ietf.org >> Cc: Muhanna, Ahmad (RICH1:2H10) >> Subject: >> >> Hi Ahmad, All, >> >> The Binding revocation draft does not mention revocation related to NEMO. >> If used as is, the BRI will revoke the binding between the MR's HoA and >> CoA. >> I think it's woth adding another level of revocation: revocation of Mobile >> Network Prefixes. A HA may decide to stop forwarding data to the CoA for >> certain MNPs and BR could be used for that. Here is a proposed text for a >> new section: >> >> "In case of NEMO protocol, the HA follows the same procedure as MIPv6 if >> the >> goal is to revoke the binding between the Mobile Router's HoA and CoA. It >> is >> also possible to have finer granularity of revocation targeting the Mobile >> Network Prefixes assigned to the Mobile Router. In this case, the HA sends >> a >> BRI message including one or more MNP options with the A bit set and the >> Revocation Trigger set to a proper value, e.g. Administrative Reasons. >> When >> receiving this BRI, the MR deletes the MNP(s) from the Prefix Information >> field in the Binding Update List and responds with a BRA message. The BRA >> MUST include the MNP(s) contained in the BRI." >> >> Also, Mobile network Prefix should be addes as valid option in section >> "6.2. >> Binding Revocation Acknowledgement Message". >> >> BR >> Desire >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > --0-549171330-1228327191=:19242 Content-Type: text/html; charset=us-ascii


From: fan zhao <fanzhao828@gmail.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: mext@ietf.org
Sent: Tuesday, December 2, 2008 5:47:35 PM
Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase

Hi Behcet,

There is a difference between binding revocation for MNPs and
MNP release.
When the binding revocation for MNPs is performed, the MNP
information stored in the binding cache entry for the MR is
removed, which means that the packets for such MNP will not
be tunneled by the HA; however, such MNP is not explicitly
released by the binding revocation. This is needed because
the mobile network nodes connecting to the MR before
may handover to their home network (such as wimax) while
the MR still stays in its foreign link (since for example the MR
does not have the wimax interface); therefore, such MNP
should still be made valid for such mobile network nodes.

To release such MNP, the same method to allocate the
MNP should be used. For example, if the MNP is allocated
by using DHCP, then DHCP needs to be used again to remove
such MNP. This is similar to the MIPv6 case where the MN
sends the BU with the lifetime=zero or the HA sends the BRI
to remove the binding, the home address on the other hand
needs to remove by deleting the IPsec SA if this is detach.

It makes sense to me using the BR to remove the MNP from
the BCE since such MNP is registered by using BU and
BR is the opposite way to BU.

[behcet ] So it is the MR that knows the situation and MR should initiate MNP release. Doing it with BR would be server-initiated which is something to be considered for prefix renumbering which has nothing to do with the release.

Sincerely,
fan

On Tue, Dec 2, 2008 at 2:50 PM, Behcet Sarikaya
<behcetsarikaya@yahoo.com> wrote:
> Hi Fan,
>  Prefix delegation/authorization function should take care of this. In DHCP
> PD there is a way to release the prefixes.
>
> Regards,
>
> Behcet
>
> ________________________________
> From: fan zhao <fanzhao828@gmail.com>
> To: Behcet Sarikaya <sarikaya@ieee.org>
> Cc: Ahmad Muhanna <amuhanna@nortel.com>; mext@ietf.org
> Sent: Tuesday, December 2, 2008 3:41:56 PM
> Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO
> usecase
>
> Hi Behcet,
>
> The binding revocation is designed for DSMIPv6 and DSMIPv6 supports
> both mobile host
> and mobile router. I do not see any issue.
>
> Sincerely,
> fan
>
> On Tue, Dec 2, 2008 at 11:52 AM, Behcet Sarikaya
> <behcetsarikaya@yahoo.com> wrote:
>> Hi Ahmad,
>>  Can you please explain how MNP is related to your draft? MNP is something
>> that MR needs and is specific to Nemo operation not to MN-HA relationship
>> and the binding that comes with it.
>>  So I don't see any binding to revocate with MNPs?
>>
>> Regards,
>>
>> Behcet
>>
>> ________________________________
>> From: Ahmad Muhanna <amuhanna@nortel.com>
>> To: Desire Oulai <desire.oulai@ericsson.com>; mext@ietf.org
>> Sent: Monday, December 1, 2008 9:22:35 PM
>> Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO
>> usecase
>>
>> Hi Desire,
>>
>> Added a relative subject.
>>
>> I guess the usecase is clear and it makes sense to me.
>> We can add some text similar to yours to capture this functionality under
>> the HA and MN operations after the conclusion of the WGLC..
>>
>> BTW: Is there anyone who thinks that we should not add this usecase?
>>
>> Regards,
>> Ahmad
>>
>>
>>
>> ________________________________
>> From: Desire Oulai [mailto:desire.oulai@ericsson.com]
>> Sent: Monday, December 01, 2008 2:46 PM
>> To: mext@ietf.org
>> Cc: Muhanna, Ahmad (RICH1:2H10)
>> Subject:
>>
>> Hi Ahmad, All,
>>
>>  The Binding revocation draft does not mention revocation related to NEMO.
>> If used as is, the BRI will revoke the binding between the MR's HoA and
>> CoA.
>> I think it's woth adding another level of revocation: revocation of Mobile
>> Network Prefixes. A HA may decide to stop forwarding data to the CoA for
>> certain MNPs and BR could be used for that. Here is a proposed text for a
>> new section:
>>
>> "In case of NEMO protocol, the HA follows the same procedure as MIPv6 if
>> the
>> goal is to revoke the binding between the Mobile Router's HoA and CoA. It
>> is
>> also possible to have finer granularity of revocation targeting the Mobile
>> Network Prefixes assigned to the Mobile Router. In this case, the HA sends
>> a
>> BRI message including one or more MNP options with the A bit set and the
>> Revocation Trigger set to a proper value, e.g. Administrative Reasons.
>> When
>> receiving this BRI, the MR deletes the MNP(s) from the Prefix Information
>> field in the Binding Update List and responds with a BRA message. The BRA
>> MUST include the MNP(s) contained in the BRI."
>>
>> Also, Mobile network Prefix should be addes as valid option in section
>> "6.2.
>> Binding Revocation Acknowledgement Message".
>>
>> BR
>> Desire
>>
>> _______________________________________________
>> MEXT mailing list
>> MEXT@ietf.org
>> https://www.ietf.org/mailman/listinfo/mext
>>
>>
>
>

--0-549171330-1228327191=:19242-- --===============0062123079== 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 --===============0062123079==-- From mext-bounces@ietf.org Wed Dec 3 10:35: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 9AFAD3A68D5; Wed, 3 Dec 2008 10:35:01 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C9263A68AB for ; Wed, 3 Dec 2008 10:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_53=0.6, 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 sy2dFypENRkR for ; Wed, 3 Dec 2008 10:34:58 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 8389D3A67EC for ; Wed, 3 Dec 2008 10:34:57 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1L7wYh-0001yu-0D; Wed, 03 Dec 2008 19:34:47 +0100 From: arno@natisbad.org (Arnaud Ebalard) To: Hesham Soliman , References: <20081103153001.5D0773A6BE5@core3.amsl.com> <87bpwvjjoi.fsf@natisbad.org> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:081203:hesham@elevatemobile.com::T399bwFiVVZC9bd0:00000000000000000000000000000000000000t5M X-Hashcash: 1:20:081203:mext@ietf.org::6p6Z+Mr61Oq2pf6s:00002byn Date: Wed, 03 Dec 2008 10:32:53 -0800 In-Reply-To: <87bpwvjjoi.fsf@natisbad.org> (Arnaud Ebalard's message of "Tue, 04 Nov 2008 21:54:53 +0100") Message-ID: <87abbdm7my.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: [MEXT] Comments on draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, Four weeks ago, I posted the following comments, questions and corrections on version 6 of draft-ietf-mext-nemo-v4traversal w/o any response so far. Did my email slipped through? > 2.1. Motivation for Using Mobile IPv6 Only > > IPv6 offers a number of improvements over today's IPv4, primarily due > to its large address space. Mobile IPv6 offers a number of > improvements over Mobile IPv4 [RFC3344], mainly due to capabilities > inherited from IPv6. For instance, route optimization and dynamic > home agent discovery can only be achieved with Mobile IPv6. > > One of the advantages of the large address space provided by IPv6 is > that it allows mobile nodes to obtain a globally unique care-of > address wherever they are. Hence, there is no need for Network > Address Translator (NAT) traversal techniques designed for Mobile > IPv4. This allows Mobile IPv6 to be a significantly simpler and more > bandwidth efficient mobility management protocol. At the same time, > during the transition towards IPv6, NAT traversal for existing > private IPv4 networks needs to be considered. This specification > introduces NAT traversal for this purpose. > > The above benefits make the case for using Mobile IPv6 only for dual > stack mobile nodes in order to allow for a long lasting mobility > solution and minimize the need to changing the mobility stack due to > the introduction of IPv6 within a deployed network. Perhaps it is just my english, but I fail to understand last paragraph. > 3.2. Mobile Prefix Solicitation and Advertisement > > According to [RFC3775], the mobile node can send a Mobile Prefix > Solicitation and receive a Mobile Prefix Advertisement containing all > prefixes advertised on the home link. > > A dual stack mobile node MAY send a Mobile Prefix Solicitation > message encapsulated in IPv4 (i.e., IPv6 in IPv4) in the case where > the mobile node has no access to IPv6 within the local network. > Securing these messages requires the mobile node to have a security > association with the home agent, using IPsec (AH or ESP) and based on > the mobile node's IPv4 care-of address as described in [RFC3775]. > Since the mobile node needs to encapsulate all IPv6 traffic sent to > the home agent into IPv4 while located in an IPv4-only visited > network, this SA would match all packets if the selectors were based > on the information in the outer header. That is, the SA selectors > being the protocol number (protocol is always IP in IP), as well as, > source and destination addresses are all common to all packets. Possibly me but last sentence seems incorrect. If not, what is its meaning? > If > this effect is not desired, the mobile node can base the SA on the > information in the inner header (i.e., using the home agent's IPv6 > address, the mobile node's home address and the ICMP protocol > number). This security association would use transport mode ESP > protection. Not clear, IMHO. > 3.3.1. Foreign Network Supports IPv6 > > In this case, the mobile node is able to configure a globally unique > IPv6 address. The mobile node will send a binding update to the IPv6 > address of its home agent, as defined in [RFC3775]. The binding > update MAY include the IPv4 home address option introduced in this > document. After receiving the binding update, the home agent creates > two binding cache entries, one for the mobile node's IPv4 home > address, and another for the mobile node's IPv6 home address. Both > entries will point to the mobile node's IPv6 care-of address. Hence, > whenever a packet is addressed to the mobile node's IPv4 or IPv6 home > addresses, the home agent will tunnel it in IPv6 to the mobile node's > IPv6 care-of address included in the binding update. Effectively, > the mobile node establishes two different tunnels, one for its IPv4 > traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6) > with a single binding update. > > In this scenario, the only addition to [RFC3775] is the inclusion of > the IPv4 home address option in the binding update message. > > After accepting the binding update and creating the corresponding > binding cache entries, the home agent MUST send a binding > acknowledgement to the mobile node as defined in [RFC3775]. In > addition, if the binding update included an IPv4 home address option, > the binding acknowledgement MUST include the IPv4 address > acknowledgment option as described later in this specification. This > option informs the mobile node whether the binding was accepted for > the IPv4 home address. If this option is not included in the binding > acknowledgement and the IPv4 home address option was included in the > binding update, the mobile node MUST assume that the home agent does > not support the IPv4 home address option and therefore SHOULD NOT > include the option in future binding updates to that home agent > address. > > When a mobile node acquires both IPv4 and IPv6 care-of addresses at > the foreign network, it SHOULD prioritize the IPv6 care-of address > for it MIPv6 its binding. Last sentence seems incorrect. > 4.1.2. The IPv4 Care-of Address Option > > This option is included in the Mobility Header including the binding > update message sent from the mobile node to a home agent or Mobility > Anchor Point. The alignment requirement for this option is 4n. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv4 Care-of address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 2: The IPv4 CoA Option > > Type > > TBD > > Length > > 6 > > Reserved > > This field is set to zero by the sender and ignored by the > receiver. > > > > > Soliman Expires May 7, 2009 [Page 15] > > Internet-Draft dsmipv6 November 2008 > > > IPv4 Care-of Address > > This field contains the mobile node's IPv4 care- of address. The care-of > 5.2. NAT Detection > > This section deals with NAT detection for the purpose of > encapsulating packets between the mobile node and the home agent. > Mobile IPv6 uses IKEv2 to establish te IPsec security association > between the mobile node and the home agent. IKE is not mandatory, it is only optional. Or did I missed a reference document? What about 'may use IKE ...' > IKEv2 has its own NAT detection mechanism. However, IKEv2's NAT > detection is only used for the purpose of setting up the IPsec SA > for secure traffic. The interactions between the two NAT traversal > mechanisms are described in Section 6 > > NAT detection is done when the initial binding update message is sent > from the mobile node to the home agent. When located in an IPv4-only > foreign link, the mobile node sends the binding update message > encapsulated in UDP and IPv4. The source address of the IPv6 packet > is the mobile node's IPv6 home address. The destination address is > the IPv6 address of the home agent. The IPv4 header contains the > IPv4 care-of address in the source address field and the IPv4 address > of the home agent in the destination address field. > > When the home agent receives the encapsulated binding update, it > compares the IPv4 address of the source address field in the IPv4 > header with the IPv4 address included in the IPv4 care-of address > option. If the two addresses match, no NAT device was in the path. > Otherwise, a NAT device was in the path and the NAT detection option > is included in the binding acknowledgement. The binding > acknowledgement, and all future packets, are then encapsulated in UDP > and IPv4. The source address in the IPv4 header is the IPv4 address > of the home agent. The destination address is the IPv4 address > received in the IPv4 header encapsulating the binding update (this > address will be different from the IPv4 care-of address when a NAT is > in the path). The source port in the packet is the home agent's > source port. The destination port is the source port received in the > binding update message. Note that the home agent stores the port > numbers and associates them with the mobile node's tunnel in order to > forward future packets. > > Upon receiving the binding acknowledgement with the NAT detection > option, the mobile node sets the tunnel to the home agent to UDP > encapsulation. Hence, all future packets to the home agent are > tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source > address in the IPv6 header is the mobile node's IPv6 home address and > the destination address is the correspondent node's IPv6 address. > All tunneled IPv4 packets will contain the mobile node's IPv4 home > address in the source address field of the inner IPv4 packet and the > correspondent node's IPv4 address in the destination address field. > The outer IPv4 header is the same whether the inner packet is IPv4 or > IPv6. > > If no NAT device was detected in the path between the mobile node and > the home agent then IPv6 packets are tunneled in an IPv4 header, > unless the home agent forces UDP encapsulation using the F flag. The > content of the inner and outer headers are identical to the UDP > encapsulation case. What if filtering somewhere prevents IP over IP but is fine with UDP encapsulated traffic. If the HA decides to go for IP over IP (i.e. does not force the F flag), this will not work. > 5.4.1. Selecting a Care-of address > > When a mobile node is in a dual stacked visited network, it will have > a choice between an IPv4 and an IPv6 care-of address. The mobile > node SHOULD prefer the IPv6 care-of address and bind it to its home > address(es). If a mobile node attempted to bind the IPv6 care-of > address to its home address(es) and the binding update timed out, the > mobile node SHOULD: > > o Resend the binding update using the exponential back-off algorithm > described in [RFC3775]. > > o If after three attempts in total a binding acknowledgement was not > received, the mobile node SHOULD send a new binding update using > the IPv4 care-of address. The exponential backoff algorithm > described in [RFC3775] should be used for re-transmission of the > binding update if needed. > > This procedure should be used to avoid scenarios where IPv6 > connectivity may not be as reliable as IPv4. This may take place > during early deployments of IPv6, or simply due to temporary outages > affecting IPv6 routing. > > It is RECOMMENDED that upon movement the mobile node does not change > the IP address family chosen for the previous binding update unless > the mobile node is aware that it has moved to a different > administrative domain where previous problems with IPv6 routing may > not be present. Repeating the above procedure upon every movement > can cause significant degradation of the mobile node's applications' > performace due to extended periods of packet losses after handover if > the routing outage is still in effect. > > When using an IPv4 care-of address and IP in IP encapsulation, if the > mobile node implementation is made aware by upper layers of > persistent packet losses , it may attempt to resend the binding > update with the F flag set, requesting UDP encapsulation for all > packets. This may avoid packet losses due to situations where local > firewalling policies prevent the use of IP in IP encapsulation. > > The effect of these address selection mechanism is to allow the > follwing preferences: following > 6. Security Considerations > > This specification allows a mobile node to send one binding update > for its IPv6 and IPv4 home addresses. This is a slight deviation > from [RFC3775] which requires one binding update per home address. > However, like [RFC3775], the IPsec security association needed to > authenticate the binding update is still based on the mobile node's > IPv6 home address. Therefore, in order to authorize the mobile > node's IPv4 home address binding, the home agent MUST store the IPv4 > address corresponding to the IPv6 address that is allocated to a > mobile node. Therefore, it is sufficient for the home agent to know > that the IPsec verification for the packet containing the binding > update was valid provided that it knows which IPv4 home address is > associated with which IPv6 home address. Hence, the security of the > IPv4 home address binding is the same as the IPv6 binding. > > In effect, associating the mobile node's IPv4 home address with its > IPv6 home address moves the authorization of the binding update for > the IPv4 address to the Mobile IPv6 implementation, which infers it > from the fact that the mobile node has an IPv6 home address and the > right credentials for sending an authentic binding update for the > IPv6 address. ok. > In cases where this specification is used for NAT traversal, it is > important to note that it has the same vulnerabilities associated > with [RFC3519]. An attacker is able to hijack the mobile node's > session with the home agent if it can modify the contents of the > outer IPv4 header. The contents of the header are not authenticated > and there is no way for the home agent to verify their validity. > Hence, a man in the middle attack where a change in the contents of > the IPv4 header can cause a legitimate mobile node's traffic to be > diverted to an illegitimate receiver independently of the > authenticity of the binding update message. > > In this specification, the binding update message MUST be protected > using ESP transport mode. Just to be sure: IP / UDP / IPv6 / ESP / MH ? > When the mobile node is located in an > IPv4-only network, the binding update message is encapsulated in UDP > as described earlier. However, UDP SHOULD NOT be used to encapsulate > the binding update message when the mobile node is located in an > IPv6-enabled network. If protection of payload traffic is needed > when the mobile node is located in an IPv4-only network, > encapsulation is done using tunnel mode ESP over port 4500 as > described in [RFC3948]. During the IKE negotiation with the home > agent, if the mobile node and home agent support the use of port > 4500, the mobile node MUST establish the security association over > port 4500, regardless of the presence of a NAT. This is done to > avoid the switching between ports 500 and 4500 and the potential > traffic disruption resulting from this switch. Is this summary correct for a MIPv6 MN that uses IPsec for both signaling and data (payload) on an IPv4 network: - signaling: IP / UDP / IPv6 / ESP / MH - data: IP / UDP / ESP / IPv6 / L4 > 6.1. Handover Interactions for IPsec and IKE > > After the mobile node detects movement it configures a new care-of > address. If the mobile node is in an IPv4-only network, it removes > binding update list entries for correspondent nodes since route > optimisation cannot be supported. This may cause inbound packet > losses as remote correspondent nodes are unaware of such movement. > To avoid confusion in the correspondent node, the mobile node SHOULD > deregister its binding with each correspondent node by sending a > deregistration binding update. The deregistration binding update > message is tunnelled to the home agent and onto the correspondent > node. This is done after the mobile node updates the home agent with > its new location as discussed below. > > The mobile node sends the binding update message to the home agent. > If the mobile node is in an IPv6-enabled network, the binding update > is sent without IPv4/UDP encapsulation. If the mobile node is in an > IPv4-only network, then after IPsec processing of the BU message, it > encapsulates the BU in UDP/IPv4 as discussed in sections 5.2 and 5.4. > In order to be able to send the binding update while in an IPv4-only > network, the mobile node needs to use the new IPv4 care-of address in > the outer header, which is different from the care-of address used in > the existing tunnel. This should be done without permanently > updating the tunnel within the mobile node's implementation in order > to allow the mobile node to receive packets on the old care-of > address until the binding acknowledgement is received. The method > used to achieve this effect is implementation dependent and is > outside the scope of this specification. This implies that the IP > forwarding function (which selects the interface or tunnel through > which a packet is sent) is not based solely on the destination > address: some IPv6 packets destined to the home agent are sent via > the existing tunnel, while BUs are sent using the new care-of > address. Since BUs are protected by IPsec, the forwarding function > cannot necessarily determine the correct treatment from the packet > headers. Thus, the DSMIPv6 implementation has to attach additional > information to BUs, and this information has to be preserved after > IPsec processing and made available to the forwarding function, or > additional DSMIP processing added to the forwarding function. > Depending on the mobile node's implementation, meeting this > requirement may require changes to the IPsec implementation. > > Upon receiving the binding update message encapsulated in UDP/IPv4, IPv4/UDP > the home agent processes it as follows. In order to allow the > DSMIPv6 implementation in the home agent to detect the presence of a > NAT on the path to the mobile node, it needs to compare the outer > IPv4 source address with the IPv4 address in the IPv4 care-of address > option. This implies that the information in the outer header will > be preserved after IPsec processing and made available to the DSMIPv6 > implementation in the home agent. Depending on the home agent's > implementation, meeting this requirement may require changes to the > IPsec implementation. > > The home agent updates its tunnel mode security association to > include the mobile node's care-of address as the remote tunnel header > address, and 4500 as the port number. The IPv4 address and port > number are likely to be wrong; the mobile node provides the correct > information in a separate exchange as described below. When the > mobile node is located in a private IPv4 network (which is detected > as described above), the new address and port number are allocated by > the NAT. The home agent will also enable or disable UDP > encapsulation for outgoing ESP packets for the purpose of NAT > traversal. > > If the Key Management Mobility Capability (K) bit was set in the > binding update, and the home agent supports this feature, the home > agent updates its IKE security associations to include the mobile > node's care-of address as the peer address and 4500 as the port > number. How? > The home agent may also need to change NAT traversal fields > in the IKE_SA to enable the dynamic update of the IP address and port > number based on the reception of authenticated IKE messages, or Following standard IKE procedure (i.e. 2.23 of RFC 4306) or is something else expected? > authenticated packets using tunnel mode ESP. How? > The dynamic updates are described in section 2.23 of RFC 4306. For IKE, yes. For other cases, it is not. > As described above, when the > mobile node is located in a private IPv4 network, the address and > port number used for IPsec and IKE traffic is not yet known by the > home agent at this point. > > The mobile node updates the IKE SA in one of two ways. If the K flag > was set in the binding acknowledgement message, the mobile node > SHOULD send an empty informational message, How does the MIPv6 modules manages to tell the IKE module to do that? > which results in the IKE > module in the home agent to dynamically update the SA information. > The IKE implementation in the home agent is REQUIRED to support this > feature. You mean on the MN, the HA or both? > Alternatively, the IKE SA should be re-negotiated. Note > that updating the IKE SA MUST take place after the mobile node has > sent the binding update and received the acknowledgement from the > home agent. > > It is important to note that the mobile node's IPv4 care-of address > seen by the DSMIPv6 module in the home agent upon receiving the > binding update may differ from the IPv4 care-of address seen by the > IKE module and the care-of address used for forwarding IPsec tunnel > mode traffic. Hence, it is probable that different modules in the > home agent will have a different care-of address that should be used > for encapsulating traffic to the mobile node. What does last sentence means? > After successfully processing the binding update, the home agent > sends the binding acknowledgement to the mobile node's care-of > address as received in the outer header of the packet containing the > binding update. Note that if the BU was rejected, the BAck is sent > to the same address where the BU was received from. This may require > special treatment in IP forwarding and/or IPsec processing which > resembles sending of BUs in the mobile node (described above). > > Upon receiving the binding acknowledgement, the mobile node updates > its local tunnel mode Security Association information to include the > tunnel header IP source address, which is the mobile node's address > and the tunnel header IP destination, which is the home agent's > address. The mobile node may also need to enable or disable UDP > encapsulation for outgoing ESP packets for the purpose of NAT > traversal and the sending of keep alives. How? > The mobile node MAY use [RFC4555] to update its IKE SA with the home > agent. Using MOBIKE requires negotiating this capability with the > home agent when establishing the SA. In this case, the mobile node > and the home agent MUST NOT update their IPsec SAs locally as this > step is performed by MOBIKE. Furthermore, the use of MOBIKE allows > the mobile node to update the SA independently of the binding update > exchange. Hence, there is no need for the mobile node to wait for a > binding acknowledgement before performing MOBIKE. The use of MOBIKE > is OPTIONAL in this specification. How IKE module and MIPv6 do synchronize on which address to use? More precisely, how is MIPv6 module expected to tell IKE implementation to use the correct address for update in MOBIKE context. > 6.2. IKE negotiation messages between the mobile node and Home Agent > > This specification defines a number of possible data encapsulation > formats depending on the mobile node's connectivity to the visited > network. When connected to an IPv6-enabled network, the tunnelling > formats are clear. However, when connected to an IPv4-only network, > care should be taken when negotiating the IKE association and the > consequential tunnelling formats used for secure and insecure > traffic. This section illustrates the IKE message exchange between > the mobile node and home agent when the mobile node is located in an > IPv4-only network. Two different IKE negotiations are considered: > > o IKEv2 operation for securing DSMIPv6 Signaling. > > o IKEv2 operation for securing Data over IPv4 > > 6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling > > A mobile node connected to an IPv4-only network SHOULD follow the > procedures described below in order to establish an SA for the > protection of binding update and binding acknowledgement messages. > > Mobile Node Home Agent > ----------- ---------- > IPv4(source_addr=V4ADDR, dest_addr=HAADDR) > UDP (500, 500) HDR, SAi1, KEi, Ni > NAT-D, NAT-D --> > > <- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) > UDP(500,X) HDR, SAr1, KEr, Nr, [CERTREQ] > NAT-D, NAT-D > > IPv4(source_addr=V4ADDR, dest_addr=HAADDR) > UDP (4500,4500) HDR, SK > {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, N(USE_TRANSPORT_MODE), > SAi2, TSi, TSr} > --> > > <-- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) > UDP (4500,Y) HDR, SK > {IDr, [CERT,] AUTH, N(USE_TRANSPORT_MODE), > SAr2, TSi, TSr} > > > The corresponding SPD entries are shown below. > > Mobile node SPD-S: > > IF local_address = home_address_1 & > > remote_address = home_agent_1 & > > proto = MH & local_mh_type = BU & remote_mh_type = BAck Then use > SA ESP transport mode > > Initiate using IDi = user_1 to address home_agent_1 > > Home Agent SPD-S: > > IF local_address = home_agent_1 & > > remote_address = home_address_1 & > > proto = MH & local_mh_type = BAck & remote_mh_type = BU Then use > SA ESP transport mode > > where home_address_1 is the mobile node's registered IPv6 home > address and home_agent_1 is the IP address of the home agent Maybe it is a dumb question: How will the IKE daemon know how to contact the HA (i mean decide to use V4ADDR as source and HAADDR as destination)? > The above should result in BU/BA messages with the following BU > received by the home agent. > > IPv4 header (src=V4ADDR, dst=HA_V4ADDR) > > UDP header (sport=Z, dport=DSMIPv6) > > IPv6 header (src=V6HOA, dst=HAADDR) > > ESP Header in Transport Mode > > Mobility header > > BU [IPv4 HAO] > > IPv4 CoA option > > (+ other as needed) > > At the home agent, following UDP de-capsulation, the binding update > is delivered to the IPsec module as shown below: > > IPv6 header (src=V6HOA, dst=HAADDR) > > ESP Header in Transport Mode > > Mobility header > > BU [IPv4 HAO] > > IPv4 CoA option > > (+other as needed) > > In addition, V4ADDR and the sport (Z) need to be passed with the > packet to ensure correct processing. > > Following IPsec processing, the binding update is delivered to the > DSMIPv6 home agent module as follows: > > IPv6 header (src=V6HOA, dst=HAADDR) > > Mobility Header > > BU [IPv4 HAO] > > IPv4 CoA option > > (+other as needed) > > In addition, V4ADDR and the sport (Z) need to be passed with the > packet to ensure correct processing. > > The binding acknowledgement sent by the home agent module to the > IPsec module is as follows: > > IPv6 header (src=HAADDR, dst=V6HOA) > > Mobility Header > > BA ([IPv4 ACK], NAT DET) > > (+ other as needed) > > In addition, V4ADDR, the sport from the BU (Z), and an indication > that vanilla UDP encapsulation must be used, need to be passed with > the packet to ensure correct processing. > > The binding acknowledgement sent by the home agent to the mobile node > is as follows: > > IPv4 header (src= HA_V4ADDR, dst=V4ADDR) > > UDP Header (sport=DSMIPv6, dport=Z) > > IPv6 header (src=HAADDR, dst=V6HOA) > > ESP Header in Transport Mode > > Mobility Header > > BA ([IPv4 ACK], NAT DET) > > 6.2.2. IKEv2 Operation for Securing Data over IPv4 > > To secure data traffic when the mobile node is located in an IPv4- > only network, the mobile node MUST establish a child_SA for that > purpose. The procedure is as follows: > > Mobile Node Home Agent > ----------- ---------- > IPv4(source_addr=V4ADDR, dest_addr=HAADDR) > UDP (4500,4500) < non-ESP Marker > HDR, SK > {[N], SA, Ni, [KEi], TSi, TSr} --> > > <--IPv4(source_addr=HAADDR, dest_addr=V4ADDR) > UDP (4500,Y) < non-ESP Marker > HDR, SK > SA, Nr, [KEr], TSi, TSr} > > > If no NAT is detected, the encapsulation used will be: > > IPv4 (source_addr=v4CoA, dest_addr=HAAddr) > > ESP > > IP (source_addr=HoA, set_addr=CNAddr) > > Upper_layer_HDR > > where IP=IPv4 or IPv6 and HoA=v4HoA or v6HoA > > If a NAT were detected, the encapsulation used will be: > > IPv4 (source_addr=v4Addr, dest_addr=HAAddr) > > UDP (sport=Y, dport=4500) > > ESP > > IP (source_addr=HoA, set_addr=CNAddr) > > Upper_layer_HDR > > Where v4CoA may be the external IPv4 address of the NAT, IP is either > an IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA. > The above format shows the packet as seen by the home agent. > > The SPD, whether a NAT were detected or not, is set as follows. Note > that this rule is designed to match all data from the MN to nodes > other than the home agent. This is done so that this rule does not > overlap with the earlier rule securing BU/BA signaling between the MN > and the HA. > > Mobile Node SPD-S: > > IF local_address = home_address & > > remote_address != home_agent & > > proto=any, then use SA ESP tunnel mode > > Initiate using IDi = user_1 to address home_agent_1 > > home agent SPD-S: > > IF local_address != home_agent & > > remote_address = home_address & > > proto=any, then use SA ESP tunnel mode > > Where home_address is the MN's registered IPv6 or IPv4 home address > and home_agent is the IPv6 or the IPv4 address of the home agent. Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 3 11:21:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FBA43A69F5; Wed, 3 Dec 2008 11:21:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACE223A69E2 for ; Wed, 3 Dec 2008 11:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 tLPqD8+naOVG for ; Wed, 3 Dec 2008 11:21:13 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 053013A69F5 for ; Wed, 3 Dec 2008 11:21:05 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so996202qwe.31 for ; Wed, 03 Dec 2008 11:21:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=aoV/Dw459ECA5hu40n8QiBM/nx9AUDUs9eo2qpOT9Pg=; b=YYUxywssxMJk3ZI9CIJmdnKm1Zqjor0iY4bfz1rIbOyQosWRYstbPoNWU4nt1vFiTl ZEbp5+4AM1rBVothnU2sX4Qj4vkHl+KZD8sUL4CDq50LTNc8VmGd1Xu/fkDjaiQGBPI8 FhKQyHZxFDIQE0km8MBc9q666MrxOdHdyA5GM= 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=wfC3PGgDQU9bx7tVJp8GptTMIa2On4C0ujl7htWZNYk5lAmzEzKJcv1NltiGhaqZDB +iK6X/B67rf1GhBkc14i4GWGv4R2bsPWoOpupit3yHQVBbZhF205q+xoNI2aFl8nB6rm UlUGx0QAmD6xe+xO/bwO01Q9TdYtogIdgrj0g= Received: by 10.214.25.1 with SMTP id 1mr13848628qay.322.1228332061182; Wed, 03 Dec 2008 11:21:01 -0800 (PST) Received: by 10.214.181.8 with HTTP; Wed, 3 Dec 2008 11:21:01 -0800 (PST) Message-ID: Date: Wed, 3 Dec 2008 11:21:01 -0800 From: "fan zhao" To: "Julien Laganier" In-Reply-To: <49365395.1060301@googlemail.com> MIME-Version: 1.0 Content-Disposition: inline References: <200811251254.47129.julien.laganier.IETF@googlemail.com> <200811261406.57408.julien.laganier.IETF@googlemail.com> <49365395.1060301@googlemail.com> Cc: netlmm@ietf.org, mext@ietf.org Subject: Re: [MEXT] [netlmm] question on the DHCP-PD X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, Thanks for your reply. The reason that I was proposing that the HNP option be included in the MIP BU is to reduce overhead during binding registration when the MN configures multiple IP addresses from the home network prefix. If the WG believes this is not necessary, I am fine with it. On the other hand, the DHCP PD is a separate issue. I will start a separate thread and without ccing to NETLMM ML. Sincerely, fan On Wed, Dec 3, 2008 at 1:38 AM, Julien Laganier wrote: > Fan, > > fan zhao wrote: >> >> On Wed, Nov 26, 2008 at 5:06 AM, Julien Laganier wrote: >>> >>> On Wednesday 26 November 2008, fan zhao wrote: >>>> >>>> wrote: >>>>> >>>>> On Friday 21 November 2008, fan zhao wrote: >>>>>> >>>>>> My question is when the MN connects to a source access network >>>>>> using PMIP (or other type of network >>>>>> based mobility protocol), it obtains a home network prefix. Then >>>>>> the MN handovers to a target access >>>>>> network (i.e. the foreign link for the MN) using the Mobile IPv6. >>>>>> The handover procedure is as follows. >>>>>> >>>>>> 1) The MN obtains a care-of address from the target access >>>>>> network. 2) The MN discovers the home agent if it does not know. >>>>>> 3) The MN sets up the IPsec SA with the HA if it does not have the >>>>>> SA with the HA before. >>>>>> 4) During the step 3), the MN requests the HNP allocated from the >>>>>> HA based on RFC 4877/5026. >>>>>> 5) The MN realizes it is on the foreign link, then it needs to >>>>>> send the BU to the HA. >>>>>> Since the Mobile IPv6 BU can only register the binding between the >>>>>> CoA and one single home address, >>>>>> in order to register the binding between the HNP and the CoA, the >>>>>> MN needs to use >>>>>> the NEMO extensions, for example, by setting up the 'R' bit and >>>>>> using the implicit mode. >>>>> >>>>> There's no need to involve NEMO. You are confusing the notion of >>>>> Home Network Prefix with that of a NEMO Mobile Network Prefix: The >>>>> Home Network Prefix is a prefix advertized on the Home Link (by the >>>>> HA or a router in MIPv6 case, or a MAG in PMIPv6 case), while a >>>>> NEMO Mobile Network Prefix is a prefix delegated to a Mobile Router >>>>> and advertised in the Mobile Network. These are different cases. >>>> >>>> I completely agree with you on this. The home agent needs to know and >>>> set up the states for both the home network prefix and the mobile >>>> network prefix even though they may be the same. >>> >>> The whole point is: The case where the Home Network Prefix and the >>> Mobile Network Prefix are the same doesn't make any sense in the >>> context of NEMO. >>> >>> The Home Network Prefix is advertized and used on the point-to-point >>> link between the MAG and the MN - or MR in the case we're discussing. >> >> That is correct in the PMIP domain. However, when the MN handovers to >> a foreign access network with the MIP used, the Home Network Prefix can >> be associated with the MN's logical/physical interface, right? > > Why? The MN has Home Address(es) configured within the Home Network Prefix. > If it goes away from home, it register said Home Address(es) with its Home > Agent. > > Without putting PMIPv6 in the picture, this is what happens with plain > Mobile IPv6, i.e. the MN does not create a binding for the whole Home > Network Prefix advertized on the Home Link, it simply creates binding for > its Home Address(es). > > Since the mechanism work just fine for a Mobile Node moving from a PMIPv6 > Home Link to a foreign access network and thus needs to use MIPv6, there's > no reason for "the Home Network Prefix [to] be associated with the MN's > logical/physical interface", as you put it. > >> Note that the case what I talked about is that a plain mobile IP terminal >> (not a MR) handovers between the PMIP and CMIP access network. > > I understand that perfectly. I am saying that MIPv6 as-is handles both the > case of a MN doing a handover from a MIPv6 home link to a foreign network, > and that of a MN doing a handover from a PMIPv6 home link to a foreign > network. > > Thus there's no need to extend MIPv6, PMIPv6, or involve NEMO, and DHCP PD > in the picture. > > I am not going to reply to the rest of your note since I do not agree a > protocol extension is required. > > Regards, > > --julien > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 3 11:27: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 69B3228C113; Wed, 3 Dec 2008 11:27:40 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CAEB28C120 for ; Wed, 3 Dec 2008 11:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 d36AC96PIgEY for ; Wed, 3 Dec 2008 11:27:37 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 0822028C0F4 for ; Wed, 3 Dec 2008 11:27:36 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so997198qwe.31 for ; Wed, 03 Dec 2008 11:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=I3Q3/yU2670JkGk8bOrFeTbS2OOW/+we5kyfNwtFjwo=; b=V7UHCxcl+YUGVzwnkqV23w6I0RxK2yR6i3tBKrUqy0HXdS256NR2bnURYaafx77fvV D+ZS12Gq08UvBKidUV5NmHkwOzycvIczHcOVaecLu0Mg44O1TdzvW/U2VDLjR1s8tWfw dZNKPEZ7DaUMCkJN6556zDSTJ8F2VZvQ59V7k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=RK0Q4BvnNJVVzaCLxbhl+Qd4JVzL1r8E7G7RdJMLuT30YAg5ORZCr6vCvjUibPHeDj nludlXa6tRbRh566wTdmGk6xICYe2LTaheU+f9MRL2JGyUTYoOOTWvTLLcSbHsUq2AZh 7fGU3xzrUOgxVqUks6f+h4XXjZHnlx7FwKWFU= Received: by 10.214.10.20 with SMTP id 20mr13879307qaj.158.1228332452598; Wed, 03 Dec 2008 11:27:32 -0800 (PST) Received: by 10.214.181.8 with HTTP; Wed, 3 Dec 2008 11:27:32 -0800 (PST) Message-ID: Date: Wed, 3 Dec 2008 11:27:32 -0800 From: "fan zhao" To: mext@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <200811251254.47129.julien.laganier.IETF@googlemail.com> <200811261406.57408.julien.laganier.IETF@googlemail.com> Subject: Re: [MEXT] [netlmm] question on the DHCP-PD X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, We had some disscusion on the DHCP PD. Now I rephrased the problem to be discussed as follows. During initial attach, when the MR powers up on a foreign link, it performs the bootstrapping and obtains a home prefix (A:B:C:0::/64) based on rfc 5026 during the IKE and configures a home address from that home prefix. Based on the NEMO basic support protocol, the home address/prefix can be part of the mobile network prefix (e.g. A:B:C::/48). The MR then runs DHCP PD to request such mobile network prefix; however since the HA already allocates part of the mobile network prefix (A:B:C:0::/64) to the MR during bootstrapping, the DHCP server will reject such request, right? Do I understand correctly? Thanks. Sincerely, fan On Wed, Nov 26, 2008 at 11:59 AM, fan zhao wrote: > Hi Julien, > > Thanks. Please see below. > > On Wed, Nov 26, 2008 at 5:06 AM, Julien Laganier > wrote: >> Hi Fan, >> >> On Wednesday 26 November 2008, fan zhao wrote: >>> wrote: >>> > On Friday 21 November 2008, fan zhao wrote: >>> >> >>> >> My question is when the MN connects to a source access network >>> >> using PMIP (or other type of network >>> >> based mobility protocol), it obtains a home network prefix. Then >>> >> the MN handovers to a target access >>> >> network (i.e. the foreign link for the MN) using the Mobile IPv6. >>> >> The handover procedure is as follows. >>> >> >>> >> 1) The MN obtains a care-of address from the target access >>> >> network. 2) The MN discovers the home agent if it does not know. >>> >> 3) The MN sets up the IPsec SA with the HA if it does not have the >>> >> SA with the HA before. >>> >> 4) During the step 3), the MN requests the HNP allocated from the >>> >> HA based on RFC 4877/5026. >>> >> 5) The MN realizes it is on the foreign link, then it needs to >>> >> send the BU to the HA. >>> >> Since the Mobile IPv6 BU can only register the binding between the >>> >> CoA and one single home address, >>> >> in order to register the binding between the HNP and the CoA, the >>> >> MN needs to use >>> >> the NEMO extensions, for example, by setting up the 'R' bit and >>> >> using the implicit mode. >>> > >>> > There's no need to involve NEMO. You are confusing the notion of >>> > Home Network Prefix with that of a NEMO Mobile Network Prefix: The >>> > Home Network Prefix is a prefix advertized on the Home Link (by the >>> > HA or a router in MIPv6 case, or a MAG in PMIPv6 case), while a >>> > NEMO Mobile Network Prefix is a prefix delegated to a Mobile Router >>> > and advertised in the Mobile Network. These are different cases. >>> >>> I completely agree with you on this. The home agent needs to know and >>> set up the states for both the home network prefix and the mobile >>> network prefix even though they may be the same. >> >> The whole point is: The case where the Home Network Prefix and the >> Mobile Network Prefix are the same doesn't make any sense in the >> context of NEMO. >> >> The Home Network Prefix is advertized and used on the point-to-point >> link between the MAG and the MN - or MR in the case we're discussing. > That is correct in the PMIP domain. However, when the MN handovers to > a foreign access network with the MIP used, the Home Network Prefix can > be associated with the MN's logical/physical interface, right? > Note that the case what I talked about is that a plain mobile IP terminal > (not a MR) handovers between the PMIP and CMIP access network. > >> >> If the Mobile Network Prefix is the same as the Home Network Prefix, it >> can't be advertized or used on a different link than the point-to-point >> link between the MAG and the MN/MR - otherwise you get what's called a >> multilink subnet and that is not allowed. > I agree that when the MN attaches to the PMIP domain, it cannot advertise > the same prefix on another link. However, in the case we are discussing, the > MN performs HO from the PMIP domain, the MAG detects that and stops > advertising the Home network prefix on the P2P link, the MN configures > a care-of > address on one interface and continues to use the Home network prefix. > I do not see any issue with that. > >> >> Thus if the Mobile Network Prefix and the Home Network Prefix are the >> same, the Mobile Network Prefix must only be advertized and used on the >> point-to-point link bewteen MAG and MN/MR. > I am not considering the case when the MR attaches to the PMIP domain. > In fact, I do not think any NEMO extension is needed when the _MN_ attaches > to the PMIP domain. What I concern is that the behavior of the MN when > it handovers to the target access using MIP. I mentioned the PMIP in the > example just because with the PMIP protocol, multiple IP addresses can > be configured from the home network prefix therefore, there is a need to > perserve the whole IP prefix during HO. The NEMO extension is the only > way to register a prefix with the HA. Such prefix is the mobile network prefix > and the prefix delegation needs to be performed. That is why I raised > the problem regarding the DHCP PD. > > Another way to allow the whole prefix to be registered during BU is to use > the Home Network Prefix option defined in 8.3 of RFC 5213. This can be > documented in the RFC 3775bis. What do you think? > With this approach, the NEMO extensions are not needed. > > However, the question regarding the DHCP PD still needs to be discussed. > Let us consider the case of initial attach, not the handover. > When the MR powers up on a foreign link, it performs the bootstrapping and > obtains a home prefix (A:B:C:0::/64) based on rfc 5026 during the IKE > and configures > a home address from that home prefix. Based on the NEMO basic support > protocol, the home address/prefix can be part of the mobile network prefix > (e.g. A:B:C::/48). The MR then runs DHCP PD to request such mobile network > prefix; however since the HA already allocates part of the mobile network prefix > (A:B:C:0::/64) to the MR during bootstrapping, the DHCP server will reject > such request, right? Do I understand correctly? What do you think? Thanks. > > Sincerely, > fan > >> >> Since the point-to-point link has only two nodes attached to it, the MAG >> and the MN/MR, given that MAG isn't mobile, you end up with a Mobile >> Network Prefix that is only advertized to and used by a single node, >> i.e. the MN/MR. > >> >> In that situation you obviously don't need to use NEMO since MIPv6 & >> PMIPv6 handle quite well the mobility of a single node - the MN. >> >> --julien >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 3 17:31:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEC563A689C; Wed, 3 Dec 2008 17:31:50 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A31C3A67EF for ; Wed, 3 Dec 2008 17:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AR49EJhLrALr for ; Wed, 3 Dec 2008 17:31:47 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id F13223A6820 for ; Wed, 3 Dec 2008 17:30:47 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1L8330-00067n-RK; Thu, 04 Dec 2008 12:30:37 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Thu, 04 Dec 2008 12:30:24 +1100 From: Hesham Soliman To: Arnaud Ebalard Message-ID: Thread-Topic: Comments on draft-ietf-mext-nemo-v4traversal-06.txt Thread-Index: AclVr+EKuz4Lx9cYUE6YNFDSQOZFvg== In-Reply-To: <87abbdm7my.fsf_-_@natisbad.org> Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org No it didn't slip through, I'm waiting to collect all comments for the next rev. Hesham On 4/12/08 5:32 AM, "Arnaud Ebalard" wrote: > Hi Hesham, > > Four weeks ago, I posted the following comments, questions and > corrections on version 6 of draft-ietf-mext-nemo-v4traversal w/o > any response so far. Did my email slipped through? > > >> 2.1. Motivation for Using Mobile IPv6 Only >> >> IPv6 offers a number of improvements over today's IPv4, primarily due >> to its large address space. Mobile IPv6 offers a number of >> improvements over Mobile IPv4 [RFC3344], mainly due to capabilities >> inherited from IPv6. For instance, route optimization and dynamic >> home agent discovery can only be achieved with Mobile IPv6. >> >> One of the advantages of the large address space provided by IPv6 is >> that it allows mobile nodes to obtain a globally unique care-of >> address wherever they are. Hence, there is no need for Network >> Address Translator (NAT) traversal techniques designed for Mobile >> IPv4. This allows Mobile IPv6 to be a significantly simpler and more >> bandwidth efficient mobility management protocol. At the same time, >> during the transition towards IPv6, NAT traversal for existing >> private IPv4 networks needs to be considered. This specification >> introduces NAT traversal for this purpose. >> >> The above benefits make the case for using Mobile IPv6 only for dual >> stack mobile nodes in order to allow for a long lasting mobility >> solution and minimize the need to changing the mobility stack due to >> the introduction of IPv6 within a deployed network. > > Perhaps it is just my english, but I fail to understand last paragraph. > >> 3.2. Mobile Prefix Solicitation and Advertisement >> >> According to [RFC3775], the mobile node can send a Mobile Prefix >> Solicitation and receive a Mobile Prefix Advertisement containing all >> prefixes advertised on the home link. >> >> A dual stack mobile node MAY send a Mobile Prefix Solicitation >> message encapsulated in IPv4 (i.e., IPv6 in IPv4) in the case where >> the mobile node has no access to IPv6 within the local network. >> Securing these messages requires the mobile node to have a security >> association with the home agent, using IPsec (AH or ESP) and based on >> the mobile node's IPv4 care-of address as described in [RFC3775]. >> Since the mobile node needs to encapsulate all IPv6 traffic sent to >> the home agent into IPv4 while located in an IPv4-only visited >> network, this SA would match all packets if the selectors were based >> on the information in the outer header. That is, the SA selectors >> being the protocol number (protocol is always IP in IP), as well as, >> source and destination addresses are all common to all packets. > > Possibly me but last sentence seems incorrect. If not, what is its > meaning? > >> If >> this effect is not desired, the mobile node can base the SA on the >> information in the inner header (i.e., using the home agent's IPv6 >> address, the mobile node's home address and the ICMP protocol >> number). This security association would use transport mode ESP >> protection. > > Not clear, IMHO. > >> 3.3.1. Foreign Network Supports IPv6 >> >> In this case, the mobile node is able to configure a globally unique >> IPv6 address. The mobile node will send a binding update to the IPv6 >> address of its home agent, as defined in [RFC3775]. The binding >> update MAY include the IPv4 home address option introduced in this >> document. After receiving the binding update, the home agent creates >> two binding cache entries, one for the mobile node's IPv4 home >> address, and another for the mobile node's IPv6 home address. Both >> entries will point to the mobile node's IPv6 care-of address. Hence, >> whenever a packet is addressed to the mobile node's IPv4 or IPv6 home >> addresses, the home agent will tunnel it in IPv6 to the mobile node's >> IPv6 care-of address included in the binding update. Effectively, >> the mobile node establishes two different tunnels, one for its IPv4 >> traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6) >> with a single binding update. >> >> In this scenario, the only addition to [RFC3775] is the inclusion of >> the IPv4 home address option in the binding update message. >> >> After accepting the binding update and creating the corresponding >> binding cache entries, the home agent MUST send a binding >> acknowledgement to the mobile node as defined in [RFC3775]. In >> addition, if the binding update included an IPv4 home address option, >> the binding acknowledgement MUST include the IPv4 address >> acknowledgment option as described later in this specification. This >> option informs the mobile node whether the binding was accepted for >> the IPv4 home address. If this option is not included in the binding >> acknowledgement and the IPv4 home address option was included in the >> binding update, the mobile node MUST assume that the home agent does >> not support the IPv4 home address option and therefore SHOULD NOT >> include the option in future binding updates to that home agent >> address. >> >> When a mobile node acquires both IPv4 and IPv6 care-of addresses at >> the foreign network, it SHOULD prioritize the IPv6 care-of address >> for it MIPv6 its binding. > > Last sentence seems incorrect. > >> 4.1.2. The IPv4 Care-of Address Option >> >> This option is included in the Mobility Header including the binding >> update message sent from the mobile node to a home agent or Mobility >> Anchor Point. The alignment requirement for this option is 4n. >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Length | Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | IPv4 Care-of address | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Figure 2: The IPv4 CoA Option >> >> Type >> >> TBD >> >> Length >> >> 6 >> >> Reserved >> >> This field is set to zero by the sender and ignored by the >> receiver. >> >> >> >> >> Soliman Expires May 7, 2009 [Page 15] >> >> Internet-Draft dsmipv6 November 2008 >> >> >> IPv4 Care-of Address >> >> This field contains the mobile node's IPv4 care- of address. The > > care-of > > >> 5.2. NAT Detection >> >> This section deals with NAT detection for the purpose of >> encapsulating packets between the mobile node and the home agent. >> Mobile IPv6 uses IKEv2 to establish te IPsec security association >> between the mobile node and the home agent. > > IKE is not mandatory, it is only optional. Or did I missed a reference > document? > > What about 'may use IKE ...' > >> IKEv2 has its own NAT detection mechanism. However, IKEv2's NAT >> detection is only used for the purpose of setting up the IPsec SA >> for secure traffic. The interactions between the two NAT traversal >> mechanisms are described in Section 6 >> >> NAT detection is done when the initial binding update message is sent >> from the mobile node to the home agent. When located in an IPv4-only >> foreign link, the mobile node sends the binding update message >> encapsulated in UDP and IPv4. The source address of the IPv6 packet >> is the mobile node's IPv6 home address. The destination address is >> the IPv6 address of the home agent. The IPv4 header contains the >> IPv4 care-of address in the source address field and the IPv4 address >> of the home agent in the destination address field. >> >> When the home agent receives the encapsulated binding update, it >> compares the IPv4 address of the source address field in the IPv4 >> header with the IPv4 address included in the IPv4 care-of address >> option. If the two addresses match, no NAT device was in the path. >> Otherwise, a NAT device was in the path and the NAT detection option >> is included in the binding acknowledgement. The binding >> acknowledgement, and all future packets, are then encapsulated in UDP >> and IPv4. The source address in the IPv4 header is the IPv4 address >> of the home agent. The destination address is the IPv4 address >> received in the IPv4 header encapsulating the binding update (this >> address will be different from the IPv4 care-of address when a NAT is >> in the path). The source port in the packet is the home agent's >> source port. The destination port is the source port received in the >> binding update message. Note that the home agent stores the port >> numbers and associates them with the mobile node's tunnel in order to >> forward future packets. >> >> Upon receiving the binding acknowledgement with the NAT detection >> option, the mobile node sets the tunnel to the home agent to UDP >> encapsulation. Hence, all future packets to the home agent are >> tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source >> address in the IPv6 header is the mobile node's IPv6 home address and >> the destination address is the correspondent node's IPv6 address. >> All tunneled IPv4 packets will contain the mobile node's IPv4 home >> address in the source address field of the inner IPv4 packet and the >> correspondent node's IPv4 address in the destination address field. >> The outer IPv4 header is the same whether the inner packet is IPv4 or >> IPv6. >> >> If no NAT device was detected in the path between the mobile node and >> the home agent then IPv6 packets are tunneled in an IPv4 header, >> unless the home agent forces UDP encapsulation using the F flag. The >> content of the inner and outer headers are identical to the UDP >> encapsulation case. > > What if filtering somewhere prevents IP over IP but is fine with UDP > encapsulated traffic. If the HA decides to go for IP over IP (i.e. does > not force the F flag), this will not work. > > >> 5.4.1. Selecting a Care-of address >> >> When a mobile node is in a dual stacked visited network, it will have >> a choice between an IPv4 and an IPv6 care-of address. The mobile >> node SHOULD prefer the IPv6 care-of address and bind it to its home >> address(es). If a mobile node attempted to bind the IPv6 care-of >> address to its home address(es) and the binding update timed out, the >> mobile node SHOULD: >> >> o Resend the binding update using the exponential back-off algorithm >> described in [RFC3775]. >> >> o If after three attempts in total a binding acknowledgement was not >> received, the mobile node SHOULD send a new binding update using >> the IPv4 care-of address. The exponential backoff algorithm >> described in [RFC3775] should be used for re-transmission of the >> binding update if needed. >> >> This procedure should be used to avoid scenarios where IPv6 >> connectivity may not be as reliable as IPv4. This may take place >> during early deployments of IPv6, or simply due to temporary outages >> affecting IPv6 routing. >> >> It is RECOMMENDED that upon movement the mobile node does not change >> the IP address family chosen for the previous binding update unless >> the mobile node is aware that it has moved to a different >> administrative domain where previous problems with IPv6 routing may >> not be present. Repeating the above procedure upon every movement >> can cause significant degradation of the mobile node's applications' >> performace due to extended periods of packet losses after handover if >> the routing outage is still in effect. >> >> When using an IPv4 care-of address and IP in IP encapsulation, if the >> mobile node implementation is made aware by upper layers of >> persistent packet losses , it may attempt to resend the binding >> update with the F flag set, requesting UDP encapsulation for all >> packets. This may avoid packet losses due to situations where local >> firewalling policies prevent the use of IP in IP encapsulation. >> >> The effect of these address selection mechanism is to allow the >> follwing preferences: > > following > >> 6. Security Considerations >> >> This specification allows a mobile node to send one binding update >> for its IPv6 and IPv4 home addresses. This is a slight deviation >> from [RFC3775] which requires one binding update per home address. >> However, like [RFC3775], the IPsec security association needed to >> authenticate the binding update is still based on the mobile node's >> IPv6 home address. Therefore, in order to authorize the mobile >> node's IPv4 home address binding, the home agent MUST store the IPv4 >> address corresponding to the IPv6 address that is allocated to a >> mobile node. Therefore, it is sufficient for the home agent to know >> that the IPsec verification for the packet containing the binding >> update was valid provided that it knows which IPv4 home address is >> associated with which IPv6 home address. Hence, the security of the >> IPv4 home address binding is the same as the IPv6 binding. >> >> In effect, associating the mobile node's IPv4 home address with its >> IPv6 home address moves the authorization of the binding update for >> the IPv4 address to the Mobile IPv6 implementation, which infers it >> from the fact that the mobile node has an IPv6 home address and the >> right credentials for sending an authentic binding update for the >> IPv6 address. > > ok. > >> In cases where this specification is used for NAT traversal, it is >> important to note that it has the same vulnerabilities associated >> with [RFC3519]. An attacker is able to hijack the mobile node's >> session with the home agent if it can modify the contents of the >> outer IPv4 header. The contents of the header are not authenticated >> and there is no way for the home agent to verify their validity. >> Hence, a man in the middle attack where a change in the contents of >> the IPv4 header can cause a legitimate mobile node's traffic to be >> diverted to an illegitimate receiver independently of the >> authenticity of the binding update message. >> >> In this specification, the binding update message MUST be protected >> using ESP transport mode. > > Just to be sure: IP / UDP / IPv6 / ESP / MH ? > >> When the mobile node is located in an >> IPv4-only network, the binding update message is encapsulated in UDP >> as described earlier. However, UDP SHOULD NOT be used to encapsulate >> the binding update message when the mobile node is located in an >> IPv6-enabled network. If protection of payload traffic is needed >> when the mobile node is located in an IPv4-only network, >> encapsulation is done using tunnel mode ESP over port 4500 as >> described in [RFC3948]. During the IKE negotiation with the home >> agent, if the mobile node and home agent support the use of port >> 4500, the mobile node MUST establish the security association over >> port 4500, regardless of the presence of a NAT. This is done to >> avoid the switching between ports 500 and 4500 and the potential >> traffic disruption resulting from this switch. > > Is this summary correct for a MIPv6 MN that uses IPsec for both > signaling and data (payload) on an IPv4 network: > > - signaling: IP / UDP / IPv6 / ESP / MH > - data: IP / UDP / ESP / IPv6 / L4 > >> 6.1. Handover Interactions for IPsec and IKE >> >> After the mobile node detects movement it configures a new care-of >> address. If the mobile node is in an IPv4-only network, it removes >> binding update list entries for correspondent nodes since route >> optimisation cannot be supported. This may cause inbound packet >> losses as remote correspondent nodes are unaware of such movement. >> To avoid confusion in the correspondent node, the mobile node SHOULD >> deregister its binding with each correspondent node by sending a >> deregistration binding update. The deregistration binding update >> message is tunnelled to the home agent and onto the correspondent >> node. This is done after the mobile node updates the home agent with >> its new location as discussed below. >> >> The mobile node sends the binding update message to the home agent. >> If the mobile node is in an IPv6-enabled network, the binding update >> is sent without IPv4/UDP encapsulation. If the mobile node is in an >> IPv4-only network, then after IPsec processing of the BU message, it >> encapsulates the BU in UDP/IPv4 as discussed in sections 5.2 and 5.4. >> In order to be able to send the binding update while in an IPv4-only >> network, the mobile node needs to use the new IPv4 care-of address in >> the outer header, which is different from the care-of address used in >> the existing tunnel. This should be done without permanently >> updating the tunnel within the mobile node's implementation in order >> to allow the mobile node to receive packets on the old care-of >> address until the binding acknowledgement is received. The method >> used to achieve this effect is implementation dependent and is >> outside the scope of this specification. This implies that the IP >> forwarding function (which selects the interface or tunnel through >> which a packet is sent) is not based solely on the destination >> address: some IPv6 packets destined to the home agent are sent via >> the existing tunnel, while BUs are sent using the new care-of >> address. Since BUs are protected by IPsec, the forwarding function >> cannot necessarily determine the correct treatment from the packet >> headers. Thus, the DSMIPv6 implementation has to attach additional >> information to BUs, and this information has to be preserved after >> IPsec processing and made available to the forwarding function, or >> additional DSMIP processing added to the forwarding function. >> Depending on the mobile node's implementation, meeting this >> requirement may require changes to the IPsec implementation. >> >> Upon receiving the binding update message encapsulated in UDP/IPv4, > > IPv4/UDP > >> the home agent processes it as follows. In order to allow the >> DSMIPv6 implementation in the home agent to detect the presence of a >> NAT on the path to the mobile node, it needs to compare the outer >> IPv4 source address with the IPv4 address in the IPv4 care-of address >> option. This implies that the information in the outer header will >> be preserved after IPsec processing and made available to the DSMIPv6 >> implementation in the home agent. Depending on the home agent's >> implementation, meeting this requirement may require changes to the >> IPsec implementation. >> >> The home agent updates its tunnel mode security association to >> include the mobile node's care-of address as the remote tunnel header >> address, and 4500 as the port number. The IPv4 address and port >> number are likely to be wrong; the mobile node provides the correct >> information in a separate exchange as described below. When the >> mobile node is located in a private IPv4 network (which is detected >> as described above), the new address and port number are allocated by >> the NAT. The home agent will also enable or disable UDP >> encapsulation for outgoing ESP packets for the purpose of NAT >> traversal. >> >> If the Key Management Mobility Capability (K) bit was set in the >> binding update, and the home agent supports this feature, the home >> agent updates its IKE security associations to include the mobile >> node's care-of address as the peer address and 4500 as the port >> number. > > How? > >> The home agent may also need to change NAT traversal fields >> in the IKE_SA to enable the dynamic update of the IP address and port >> number based on the reception of authenticated IKE messages, or > > Following standard IKE procedure (i.e. 2.23 of RFC 4306) or is something > else expected? > >> authenticated packets using tunnel mode ESP. > > How? > >> The dynamic updates are described in section 2.23 of RFC 4306. > > For IKE, yes. For other cases, it is not. > >> As described above, when the >> mobile node is located in a private IPv4 network, the address and >> port number used for IPsec and IKE traffic is not yet known by the >> home agent at this point. >> >> The mobile node updates the IKE SA in one of two ways. If the K flag >> was set in the binding acknowledgement message, the mobile node >> SHOULD send an empty informational message, > > How does the MIPv6 modules manages to tell the IKE module to do that? > >> which results in the IKE >> module in the home agent to dynamically update the SA information. >> The IKE implementation in the home agent is REQUIRED to support this >> feature. > > You mean on the MN, the HA or both? > >> Alternatively, the IKE SA should be re-negotiated. Note >> that updating the IKE SA MUST take place after the mobile node has >> sent the binding update and received the acknowledgement from the >> home agent. >> >> It is important to note that the mobile node's IPv4 care-of address >> seen by the DSMIPv6 module in the home agent upon receiving the >> binding update may differ from the IPv4 care-of address seen by the >> IKE module and the care-of address used for forwarding IPsec tunnel >> mode traffic. Hence, it is probable that different modules in the >> home agent will have a different care-of address that should be used >> for encapsulating traffic to the mobile node. > > What does last sentence means? > >> After successfully processing the binding update, the home agent >> sends the binding acknowledgement to the mobile node's care-of >> address as received in the outer header of the packet containing the >> binding update. Note that if the BU was rejected, the BAck is sent >> to the same address where the BU was received from. This may require >> special treatment in IP forwarding and/or IPsec processing which >> resembles sending of BUs in the mobile node (described above). >> >> Upon receiving the binding acknowledgement, the mobile node updates >> its local tunnel mode Security Association information to include the >> tunnel header IP source address, which is the mobile node's address >> and the tunnel header IP destination, which is the home agent's >> address. The mobile node may also need to enable or disable UDP >> encapsulation for outgoing ESP packets for the purpose of NAT >> traversal and the sending of keep alives. > > How? > >> The mobile node MAY use [RFC4555] to update its IKE SA with the home >> agent. Using MOBIKE requires negotiating this capability with the >> home agent when establishing the SA. In this case, the mobile node >> and the home agent MUST NOT update their IPsec SAs locally as this >> step is performed by MOBIKE. Furthermore, the use of MOBIKE allows >> the mobile node to update the SA independently of the binding update >> exchange. Hence, there is no need for the mobile node to wait for a >> binding acknowledgement before performing MOBIKE. The use of MOBIKE >> is OPTIONAL in this specification. > > How IKE module and MIPv6 do synchronize on which address to use? More > precisely, how is MIPv6 module expected to tell IKE implementation to > use the correct address for update in MOBIKE context. > >> 6.2. IKE negotiation messages between the mobile node and Home Agent >> >> This specification defines a number of possible data encapsulation >> formats depending on the mobile node's connectivity to the visited >> network. When connected to an IPv6-enabled network, the tunnelling >> formats are clear. However, when connected to an IPv4-only network, >> care should be taken when negotiating the IKE association and the >> consequential tunnelling formats used for secure and insecure >> traffic. This section illustrates the IKE message exchange between >> the mobile node and home agent when the mobile node is located in an >> IPv4-only network. Two different IKE negotiations are considered: >> >> o IKEv2 operation for securing DSMIPv6 Signaling. >> >> o IKEv2 operation for securing Data over IPv4 >> >> 6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling >> >> A mobile node connected to an IPv4-only network SHOULD follow the >> procedures described below in order to establish an SA for the >> protection of binding update and binding acknowledgement messages. >> >> Mobile Node Home Agent >> ----------- ---------- >> IPv4(source_addr=V4ADDR, dest_addr=HAADDR) >> UDP (500, 500) HDR, SAi1, KEi, Ni >> NAT-D, NAT-D --> >> >> <- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) >> UDP(500,X) HDR, SAr1, KEr, Nr, [CERTREQ] >> NAT-D, NAT-D >> >> IPv4(source_addr=V4ADDR, dest_addr=HAADDR) >> UDP (4500,4500) HDR, SK >> {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, N(USE_TRANSPORT_MODE), >> SAi2, TSi, TSr} >> --> >> >> <-- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) >> UDP (4500,Y) HDR, SK >> {IDr, [CERT,] AUTH, N(USE_TRANSPORT_MODE), >> SAr2, TSi, TSr} >> >> >> The corresponding SPD entries are shown below. >> >> Mobile node SPD-S: >> >> IF local_address = home_address_1 & >> >> remote_address = home_agent_1 & >> >> proto = MH & local_mh_type = BU & remote_mh_type = BAck Then use >> SA ESP transport mode >> >> Initiate using IDi = user_1 to address home_agent_1 >> >> Home Agent SPD-S: >> >> IF local_address = home_agent_1 & >> >> remote_address = home_address_1 & >> >> proto = MH & local_mh_type = BAck & remote_mh_type = BU Then use >> SA ESP transport mode >> >> where home_address_1 is the mobile node's registered IPv6 home >> address and home_agent_1 is the IP address of the home agent > > Maybe it is a dumb question: How will the IKE daemon know how to contact > the HA (i mean decide to use V4ADDR as source and HAADDR as > destination)? > >> The above should result in BU/BA messages with the following BU >> received by the home agent. >> >> IPv4 header (src=V4ADDR, dst=HA_V4ADDR) >> >> UDP header (sport=Z, dport=DSMIPv6) >> >> IPv6 header (src=V6HOA, dst=HAADDR) >> >> ESP Header in Transport Mode >> >> Mobility header >> >> BU [IPv4 HAO] >> >> IPv4 CoA option >> >> (+ other as needed) >> >> At the home agent, following UDP de-capsulation, the binding update >> is delivered to the IPsec module as shown below: >> >> IPv6 header (src=V6HOA, dst=HAADDR) >> >> ESP Header in Transport Mode >> >> Mobility header >> >> BU [IPv4 HAO] >> >> IPv4 CoA option >> >> (+other as needed) >> >> In addition, V4ADDR and the sport (Z) need to be passed with the >> packet to ensure correct processing. >> >> Following IPsec processing, the binding update is delivered to the >> DSMIPv6 home agent module as follows: >> >> IPv6 header (src=V6HOA, dst=HAADDR) >> >> Mobility Header >> >> BU [IPv4 HAO] >> >> IPv4 CoA option >> >> (+other as needed) >> >> In addition, V4ADDR and the sport (Z) need to be passed with the >> packet to ensure correct processing. >> >> The binding acknowledgement sent by the home agent module to the >> IPsec module is as follows: >> >> IPv6 header (src=HAADDR, dst=V6HOA) >> >> Mobility Header >> >> BA ([IPv4 ACK], NAT DET) >> >> (+ other as needed) >> >> In addition, V4ADDR, the sport from the BU (Z), and an indication >> that vanilla UDP encapsulation must be used, need to be passed with >> the packet to ensure correct processing. >> >> The binding acknowledgement sent by the home agent to the mobile node >> is as follows: >> >> IPv4 header (src= HA_V4ADDR, dst=V4ADDR) >> >> UDP Header (sport=DSMIPv6, dport=Z) >> >> IPv6 header (src=HAADDR, dst=V6HOA) >> >> ESP Header in Transport Mode >> >> Mobility Header >> >> BA ([IPv4 ACK], NAT DET) >> >> 6.2.2. IKEv2 Operation for Securing Data over IPv4 >> >> To secure data traffic when the mobile node is located in an IPv4- >> only network, the mobile node MUST establish a child_SA for that >> purpose. The procedure is as follows: >> >> Mobile Node Home Agent >> ----------- ---------- >> IPv4(source_addr=V4ADDR, dest_addr=HAADDR) >> UDP (4500,4500) < non-ESP Marker > HDR, SK >> {[N], SA, Ni, [KEi], TSi, TSr} --> >> >> <--IPv4(source_addr=HAADDR, dest_addr=V4ADDR) >> UDP (4500,Y) < non-ESP Marker > HDR, SK >> SA, Nr, [KEr], TSi, TSr} >> >> >> If no NAT is detected, the encapsulation used will be: >> >> IPv4 (source_addr=v4CoA, dest_addr=HAAddr) >> >> ESP >> >> IP (source_addr=HoA, set_addr=CNAddr) >> >> Upper_layer_HDR >> >> where IP=IPv4 or IPv6 and HoA=v4HoA or v6HoA >> >> If a NAT were detected, the encapsulation used will be: >> >> IPv4 (source_addr=v4Addr, dest_addr=HAAddr) >> >> UDP (sport=Y, dport=4500) >> >> ESP >> >> IP (source_addr=HoA, set_addr=CNAddr) >> >> Upper_layer_HDR >> >> Where v4CoA may be the external IPv4 address of the NAT, IP is either >> an IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA. >> The above format shows the packet as seen by the home agent. >> >> The SPD, whether a NAT were detected or not, is set as follows. Note >> that this rule is designed to match all data from the MN to nodes >> other than the home agent. This is done so that this rule does not >> overlap with the earlier rule securing BU/BA signaling between the MN >> and the HA. >> >> Mobile Node SPD-S: >> >> IF local_address = home_address & >> >> remote_address != home_agent & >> >> proto=any, then use SA ESP tunnel mode >> >> Initiate using IDi = user_1 to address home_agent_1 >> >> home agent SPD-S: >> >> IF local_address != home_agent & >> >> remote_address = home_address & >> >> proto=any, then use SA ESP tunnel mode >> >> Where home_address is the MN's registered IPv6 or IPv4 home address >> and home_agent is the IPv6 or the IPv4 address of the home agent. > > > Cheers, > > a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 4 00:36: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 7164C28C128; Thu, 4 Dec 2008 00:36:50 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 927783A69C3 for ; Thu, 4 Dec 2008 00:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=0.164, 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 wgphFgPTHO7B for ; Thu, 4 Dec 2008 00:36:48 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 9090028C11C for ; Thu, 4 Dec 2008 00:36:48 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.136.114])by smtp01.uc3m.es (Postfix) with ESMTP id EC290AF369F; Thu, 4 Dec 2008 09:36:40 +0100 (CET) Message-ID: <49379699.4020501@it.uc3m.es> Date: Thu, 04 Dec 2008 09:36:41 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Alexandru Petrescu , 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:-14.0545 TC:1F TRN:32 TV:5.5.1026(16318.004) 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: Re: access to ETSI standards] X-BeenThere: mext@ietf.org X-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: Re: access to ETSI standards Fecha: Wed, 3 Dec 2008 22:07:26 +0100 De: Andreas Festag Para: marcelo bagnulo braun CC: Julien Laganier , Soeren Hess , Martin Arndt Referencias: <4932D0F1.3010308@it.uc3m.es> Dear Marcelo, As for ETSI work, I can say that in TC ITS WG4 (Media) there is currently an ongoing effort to prepare a "European profile standard of IEEE 802.11". The intention is to determine those features of the 802.11 standard that are relevant for its deployment in Europe, in particular for IEEE 802.11p. It is important to note that this profile standard does not rewrite the current 802.11 standard but represents rather a subset and possibly some extensions. In general, all ETSI standards are publicly available and free-of-charge, access is assured after completion of the standard. I expect that the "European profile standard of IEEE 802.11" will be completed in the 1st half year (Soeren, please correct if I am wrong). Kind regards, Andreas On 30.11.2008, at 18:44, marcelo bagnulo braun wrote: > Hi, > > As you may have seen, there are members of the MEXT wg that are > asking to have access to the standards related to the link layer > technology used in the automotive scenario. I was wondering if you > could provide some guidance about this. > > Thanks, marcelo > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 4 02:31: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 6ADF03A6851; Thu, 4 Dec 2008 02:31:37 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBD873A6851 for ; Thu, 4 Dec 2008 02:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwAbLjoHPE-M for ; Thu, 4 Dec 2008 02:31:35 -0800 (PST) Received: from nw-smtp-05.wineasy.se (nw-smtp-05.wineasy.se [195.42.210.229]) by core3.amsl.com (Postfix) with ESMTP id 5E6523A6839 for ; Thu, 4 Dec 2008 02:31:35 -0800 (PST) Received: from [10.1.2.47] (static-213.88.172.99.addr.tdcsong.se [213.88.172.99]) by nw-smtp-05.wineasy.se (Postfix) with ESMTP id 417AC760F83; Thu, 4 Dec 2008 11:31:30 +0100 (CET) From: Joel Hortelius To: Hesham Soliman In-Reply-To: References: Organization: Interpeak Date: Thu, 04 Dec 2008 11:35:02 +0000 Message-Id: <1228390502.16329.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I'd still like to request that the prefix flag is introduced in the Home Address Acknowledgement reply, and that it's set to match the flag in the request. This would allow the prefix length to always be set to the correct prefix for that particular address providing all relevant information during the initial exchange. It would make it much easier to handle configuration of interfaces/addresses of mobile nodes without having to retrieve the information from an external source, it'd also make it easier to deal with the DHCP server support in draft-ietf-netlmm-pmip6-ipv4-support-06, where the default gateway is provided as an extra option, but the subnet is unknown since it'll always be 32 in the ack since the P flag is 0. Regards, Joel Hortelius. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 4 03:20: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 8E2CC3A69D4; Thu, 4 Dec 2008 03:20:43 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069D93A69D4 for ; Thu, 4 Dec 2008 03:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 uVsPCsOAjXdC for ; Thu, 4 Dec 2008 03:20:41 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 4139A3A6832 for ; Thu, 4 Dec 2008 03:20:40 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1L8CG0-0006Up-Lv; Thu, 04 Dec 2008 22:20:33 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Thu, 04 Dec 2008 22:20:26 +1100 From: Hesham Soliman To: Joel Hortelius Message-ID: Thread-Topic: [MEXT] Comments on draft-ietf-mext-nemo-v4traversal-06.txt Thread-Index: AclWAk5HYXCsJDJNOEqXKTUVW5uZnw== In-Reply-To: <1228390502.16329.10.camel@localhost.localdomain> Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > I'd still like to request that the prefix flag is introduced in the Home > Address Acknowledgement reply, and that it's set to match the flag in > the request. This would allow the prefix length to always be set to the > correct prefix for that particular address providing all relevant > information during the initial exchange. => I don't understand this. The P flag is not for the pref-len. The pref-len is returned in the Ack. Can you clarify what you mean? Hesham > > It would make it much easier to handle configuration of > interfaces/addresses of mobile nodes without having to retrieve the > information from an external source, it'd also make it easier to deal > with the DHCP server support in draft-ietf-netlmm-pmip6-ipv4-support-06, > where the default gateway is provided as an extra option, but the subnet > is unknown since it'll always be 32 in the ack since the P flag is 0. > > Regards, > Joel Hortelius. > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 4 03:41:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E3913A69FD; Thu, 4 Dec 2008 03:41:15 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1161C3A69FD for ; Thu, 4 Dec 2008 03:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-+7McUWyzXw for ; Thu, 4 Dec 2008 03:41:13 -0800 (PST) Received: from nw-smtp-05.wineasy.se (nw-smtp-05.wineasy.se [195.42.210.229]) by core3.amsl.com (Postfix) with ESMTP id 6175E3A699E for ; Thu, 4 Dec 2008 03:40:47 -0800 (PST) Received: from [10.1.2.47] (static-213.88.172.99.addr.tdcsong.se [213.88.172.99]) by nw-smtp-05.wineasy.se (Postfix) with ESMTP id 4F4EB761234; Thu, 4 Dec 2008 12:40:42 +0100 (CET) From: Joel Hortelius To: Hesham Soliman In-Reply-To: References: Organization: Interpeak Date: Thu, 04 Dec 2008 12:44:13 +0000 Message-Id: <1228394653.16329.26.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org As I understand the specification; If you allocate a single v4 home address, the P flag is 0, the prefix length is 32, - In the ack, the home address is specified, the prefix length is 32. If you allocate a prefix, P is 1, prefix length is requested value, in the ack the prefix length is the requested value. My wish is that the acknowledgement would contain the P flag as well, indicating that this is indeed a prefix allocation, and if the P flag is cleared, its a single home address. The prefix length would be the correct value in both cases, i.e. prefix length in the P=1 case, and the subnet the home address belongs to when P=0. It would provide me with information that would be very helpful, that I'd otherwise would have to try invent some external mechanism or configuration in order to retrieve since it's very useful to have both regarding interface configuration in the mobile node and DHCP configuration in NETLMM/PMIPV6/V4. I also have a question regarding: 3.1.1 & 4.5; 3.1.1: Pref The length of the prefix allocated to the mobile node. If only a single address is allocated, this field MUST be set to 32. In the first binding update requesting a prefix, the field contains the prefix length requested. However, in the following binding updates, this field must contain the length of the prefix allocated. A value of zero is invalid and MUST be considered an error. 4.5: - If the IPv4 home address option contained the unspecified IPv4 address, the home agent SHOULD dynamically allocate an IPv4 home address to the mobile node. If none is available, the home agent MUST return error code 132 in the status field of the IPv4 address acknowledgement option. If a prefix were requested, the home agent MUST allocate a prefix with the requested length; otherwise the home agent MUST indicate failure of the operation with the appropriate error code. Reading 3.1.1 I get the feeling that the prefix length can be altered in the ack by the home agent. But reading 4.5 it's indicated that the home agent MUST allocate the prefix using the requested length? Regards, /J. On Thu, 2008-12-04 at 22:20 +1100, Hesham Soliman wrote: > > I'd still like to request that the prefix flag is introduced in the Home > > Address Acknowledgement reply, and that it's set to match the flag in > > the request. This would allow the prefix length to always be set to the > > correct prefix for that particular address providing all relevant > > information during the initial exchange. > > => I don't understand this. The P flag is not for the pref-len. The pref-len > is returned in the Ack. Can you clarify what you mean? > > Hesham > > > > > It would make it much easier to handle configuration of > > interfaces/addresses of mobile nodes without having to retrieve the > > information from an external source, it'd also make it easier to deal > > with the DHCP server support in draft-ietf-netlmm-pmip6-ipv4-support-06, > > where the default gateway is provided as an extra option, but the subnet > > is unknown since it'll always be 32 in the ack since the P flag is 0. > > > > Regards, > > Joel Hortelius. > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 4 06:37: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 AE0473A6AB2; Thu, 4 Dec 2008 06:37:40 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C69043A6AB3 for ; Thu, 4 Dec 2008 06:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 Y5YHMG+9hDpz for ; Thu, 4 Dec 2008 06:37:38 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id BACED3A6AB2 for ; Thu, 4 Dec 2008 06:37:37 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1L8FKc-0001Br-PA; Fri, 05 Dec 2008 01:37:31 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Fri, 05 Dec 2008 01:37:27 +1100 From: Hesham Soliman To: Joel Hortelius Message-ID: Thread-Topic: [MEXT] Comments on draft-ietf-mext-nemo-v4traversal-06.txt Thread-Index: AclWHdQkY72Lis4rW0ORlaaEfRSAxg== In-Reply-To: <1228394653.16329.26.camel@localhost.localdomain> Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On 4/12/08 11:44 PM, "Joel Hortelius" wrote: > As I understand the specification; If you allocate a single v4 home > address, the P flag is 0, the prefix length is 32, - In the ack, the > home address is specified, the prefix length is 32. => Yes. > > If you allocate a prefix, P is 1, prefix length is requested value, in > the ack the prefix length is the requested value. > > My wish is that the acknowledgement would contain the P flag as well, > indicating that this is indeed a prefix allocation, and if the P flag is > cleared, its a single home address. => But that's redundant information, you already know that from the pref-len field. The prefix length would be the > correct value in both cases, i.e. prefix length in the P=1 case, and the > subnet the home address belongs to when P=0. > > It would provide me with information that would be very helpful, that > I'd otherwise would have to try invent some external mechanism or > configuration in order to retrieve since it's very useful to have both > regarding interface configuration in the mobile node and DHCP > configuration in NETLMM/PMIPV6/V4. => I'm sorry, I have no idea what you're referring to. If the home address is not derived from the prefix then you will have two IPv4 HoA options in the BU. Otherwise there is one option with a prefix that is used to derive the HoA or just a /32 address. I really don't understand what valuable information you're after from the P flag. > > I also have a question regarding: > 3.1.1 & 4.5; > > 3.1.1: > Pref The length of the prefix allocated to the mobile > node. If only a single address is allocated, > this field MUST be set to 32. In the first > binding update requesting a prefix, the field > contains the prefix length requested. However, > in the following binding updates, this field > must contain the length of the prefix allocated. > > A value of zero is invalid and MUST be > considered an error. > > 4.5: > - If the IPv4 home address option contained the unspecified IPv4 > address, the home agent SHOULD dynamically allocate an IPv4 home > address to the mobile node. If none is available, the home agent > MUST return error code 132 in the status field of the IPv4 address > acknowledgement option. If a prefix were requested, the home agent > MUST allocate a prefix with the requested length; otherwise the > home agent MUST indicate failure of the operation with the > appropriate error code. > > Reading 3.1.1 I get the feeling that the prefix length can be altered in the > ack by the home agent. > But reading 4.5 it's indicated that the home agent MUST allocate the prefix > using the requested > length? => Yes you're right, I think 4.5 should be a SHOULD. The MUST is unnecessarily strong. I'll make that change. Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 4 06:57:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9862D3A6B16; Thu, 4 Dec 2008 06:57:46 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E316B3A684B for ; Thu, 4 Dec 2008 06:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OikCAgti1ft for ; Thu, 4 Dec 2008 06:57:43 -0800 (PST) Received: from nw-smtp-05.wineasy.se (nw-smtp-05.wineasy.se [195.42.210.229]) by core3.amsl.com (Postfix) with ESMTP id 8E84D3A6B0B for ; Thu, 4 Dec 2008 06:57:43 -0800 (PST) Received: from [10.1.2.47] (static-213.88.172.99.addr.tdcsong.se [213.88.172.99]) by nw-smtp-05.wineasy.se (Postfix) with ESMTP id 3C7D0760595; Thu, 4 Dec 2008 15:57:38 +0100 (CET) From: Joel Hortelius To: Hesham Soliman In-Reply-To: References: Organization: Interpeak Date: Thu, 04 Dec 2008 16:01:09 +0000 Message-Id: <1228406469.16329.42.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Fri, 2008-12-05 at 01:37 +1100, Hesham Soliman wrote: > > > On 4/12/08 11:44 PM, "Joel Hortelius" wrote: > > > As I understand the specification; If you allocate a single v4 home > > address, the P flag is 0, the prefix length is 32, - In the ack, the > > home address is specified, the prefix length is 32. > > => Yes. > > > > > If you allocate a prefix, P is 1, prefix length is requested value, in > > the ack the prefix length is the requested value. > > > > My wish is that the acknowledgement would contain the P flag as well, > > indicating that this is indeed a prefix allocation, and if the P flag is > > cleared, its a single home address. > > => But that's redundant information, you already know that from the pref-len > field. But the pref-len field in a single Home Address (not a prefix) would always be 32? I'm interested in receiving the prefix len of the subnet the Home Address belongs to > > > The prefix length would be the > > correct value in both cases, i.e. prefix length in the P=1 case, and the > > subnet the home address belongs to when P=0. > > > > It would provide me with information that would be very helpful, that > > I'd otherwise would have to try invent some external mechanism or > > configuration in order to retrieve since it's very useful to have both > > regarding interface configuration in the mobile node and DHCP > > configuration in NETLMM/PMIPV6/V4. > > => I'm sorry, I have no idea what you're referring to. If the home address > is not derived from the prefix then you will have two IPv4 HoA options in > the BU. Otherwise there is one option with a prefix that is used to derive > the HoA or just a /32 address. I really don't understand what valuable > information you're after from the P flag. To be honest, I don't understand how to receive the prefix length of a non-prefix address; In the BU; HoA=0.0.0.0, Pref-len=32, P=0 In the BA: HoA=X.X.X.X, Pref-len=32 If HoA was allocated from a subnet such as X.X.X.0/24, I'd like to receive the /24 as well. Otherwise, in order to receive the /24 I'd have to allocate an entire v4 prefix and derive a home address from that even though I'm only interested in acquiring a single v4 for the mobile node. I may have misunderstood something, of course, but for me the following transaction would make more sense: In the BU; HoA=0.0.0.0, Pref-len=0, P=0 In the BA: HoA=X.X.X.X, Pref-len=24, P=0 It would allow me to retrieve a single v4 HoA, and the size of the subnet it belongs to - making it easier to configure the networks on the MAG/Mobile Node. > > > > > I also have a question regarding: > > 3.1.1 & 4.5; > > > > 3.1.1: > > Pref The length of the prefix allocated to the mobile > > node. If only a single address is allocated, > > this field MUST be set to 32. In the first > > binding update requesting a prefix, the field > > contains the prefix length requested. However, > > in the following binding updates, this field > > must contain the length of the prefix allocated. > > > > A value of zero is invalid and MUST be > > considered an error. > > > > 4.5: > > - If the IPv4 home address option contained the unspecified IPv4 > > address, the home agent SHOULD dynamically allocate an IPv4 home > > address to the mobile node. If none is available, the home agent > > MUST return error code 132 in the status field of the IPv4 address > > acknowledgement option. If a prefix were requested, the home agent > > MUST allocate a prefix with the requested length; otherwise the > > home agent MUST indicate failure of the operation with the > > appropriate error code. > > > > Reading 3.1.1 I get the feeling that the prefix length can be altered in the > > ack by the home agent. > > But reading 4.5 it's indicated that the home agent MUST allocate the prefix > > using the requested > > length? > > => Yes you're right, I think 4.5 should be a SHOULD. The MUST is > unnecessarily strong. I'll make that change. > > Hesham > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 4 14:27: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 605393A67C1; Thu, 4 Dec 2008 14:27:23 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3DC3A67C1 for ; Thu, 4 Dec 2008 14:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 ez0tSNbtngJS for ; Thu, 4 Dec 2008 14:27:21 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 68C7D3A67A4 for ; Thu, 4 Dec 2008 14:27:20 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1L8MfA-0004Xg-QO; Fri, 05 Dec 2008 09:27:13 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Fri, 05 Dec 2008 09:27:08 +1100 From: Hesham Soliman To: Joel Hortelius Message-ID: Thread-Topic: [MEXT] Comments on draft-ietf-mext-nemo-v4traversal-06.txt Thread-Index: AclWX3FUeKpOzWR2Hk6Al80OcUzQZA== In-Reply-To: <1228406469.16329.42.camel@localhost.localdomain> Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org >> >> => But that's redundant information, you already know that from the pref-len >> field. > > But the pref-len field in a single Home Address (not a prefix) would > always be 32? I'm interested in receiving the prefix len of the subnet > the Home Address belongs to > >> >> >> The prefix length would be the >>> correct value in both cases, i.e. prefix length in the P=1 case, and the >>> subnet the home address belongs to when P=0. >>> >>> It would provide me with information that would be very helpful, that >>> I'd otherwise would have to try invent some external mechanism or >>> configuration in order to retrieve since it's very useful to have both >>> regarding interface configuration in the mobile node and DHCP >>> configuration in NETLMM/PMIPV6/V4. >> >> => I'm sorry, I have no idea what you're referring to. If the home address >> is not derived from the prefix then you will have two IPv4 HoA options in >> the BU. Otherwise there is one option with a prefix that is used to derive >> the HoA or just a /32 address. I really don't understand what valuable >> information you're after from the P flag. > > To be honest, I don't understand how to receive the prefix length of a > non-prefix address; => Ah, well, you don't. This specification doesn't give you that. This has nothing to do with the P flag. You're looking for a netmask. We didn't include that in the spec actually. I guess you're asking for a new feature. Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From jbottonn@aenor.pt Fri Dec 5 00:10:52 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 166E03A6C21 for ; Fri, 5 Dec 2008 00:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.371 X-Spam-Level: X-Spam-Status: No, score=-10.371 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lHrLVklIyBJ for ; Fri, 5 Dec 2008 00:10:52 -0800 (PST) Received: from abs-cbn.com (unknown [88.248.2.227]) by core3.amsl.com (Postfix) with SMTP id 87CF63A6C04 for ; Fri, 5 Dec 2008 00:10:48 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081205081050.87CF63A6C04@core3.amsl.com> Date: Fri, 5 Dec 2008 00:10:48 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mext-bounces@ietf.org Fri Dec 5 07:02: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 7052828C16A; Fri, 5 Dec 2008 07:02:53 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9970D28C168 for ; Fri, 5 Dec 2008 07:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.74 X-Spam-Level: X-Spam-Status: No, score=-5.74 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_84=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 ttQ9qhZBeVDF for ; Fri, 5 Dec 2008 07:02:50 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id DFAC528C15F for ; Fri, 5 Dec 2008 07:02:49 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mB5F2HP10772; Fri, 5 Dec 2008 15:02:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 5 Dec 2008 09:02:10 -0600 Message-ID: In-Reply-To: <356714.19242.qm@web111409.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMOusecase Thread-Index: AclVcPZfjYRv8apAT8yIIKydGexk7gBeKU8A References: <570090.92095.qm@web111410.mail.gq1.yahoo.com><496302.84429.qm@web111411.mail.gq1.yahoo.com> <356714.19242.qm@web111409.mail.gq1.yahoo.com> From: "Ahmad Muhanna" To: "Behcet Sarikaya" , "fan zhao" Cc: mext@ietf.org Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMOusecase X-BeenThere: mext@ietf.org X-Mailman-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="===============0554662071==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0554662071== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C956EA.730BAC55" This is a multi-part message in MIME format. ------_=_NextPart_001_01C956EA.730BAC55 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Behcet, =20 Just to clarify one thing here. It seems that we overlooked this use case by not mentioning it in the draft. Looking at the presentation that we made at IETF-70 and IETF-71 it clearly list HA->MR as one of the usecases. Since that was the basis for this draft that was adopted as a wg document, I believe we need to include this in the draft. =20 Please find the Binding Revocation slides for IETF-70 & 71 at the below links: =20 http://www.ietf.org/proceedings/08mar/slides/mext-9.pdf http://www.ietf.org/proceedings/07dec/slides/mext-4.pdf Regards,=20 Ahmad=20 =20 ________________________________ From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Wednesday, December 03, 2008 12:00 PM To: fan zhao Cc: mext@ietf.org Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMOusecase =09 =09 =09 ________________________________ From: fan zhao To: Behcet Sarikaya Cc: mext@ietf.org Sent: Tuesday, December 2, 2008 5:47:35 PM Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase =09 Hi Behcet, =09 There is a difference between binding revocation for MNPs and MNP release. When the binding revocation for MNPs is performed, the MNP information stored in the binding cache entry for the MR is removed, which means that the packets for such MNP will not be tunneled by the HA; however, such MNP is not explicitly released by the binding revocation. This is needed because the mobile network nodes connecting to the MR before may handover to their home network (such as wimax) while the MR still stays in its foreign link (since for example the MR does not have the wimax interface); therefore, such MNP should still be made valid for such mobile network nodes. =09 To release such MNP, the same method to allocate the MNP should be used. For example, if the MNP is allocated by using DHCP, then DHCP needs to be used again to remove such MNP. This is similar to the MIPv6 case where the MN sends the BU with the lifetime=3Dzero or the HA sends the BRI to remove the binding, the home address on the other hand needs to remove by deleting the IPsec SA if this is detach. =09 It makes sense to me using the BR to remove the MNP from the BCE since such MNP is registered by using BU and BR is the opposite way to BU. =09 [behcet ] So it is the MR that knows the situation and MR should initiate MNP release. Doing it with BR would be server-initiated which is something to be considered for prefix renumbering which has nothing to do with the release.=20 =09 Sincerely, fan =09 On Tue, Dec 2, 2008 at 2:50 PM, Behcet Sarikaya wrote: > Hi Fan, > Prefix delegation/authorization function should take care of this. In DHCP > PD there is a way to release the prefixes. > > Regards, > > Behcet > > ________________________________ > From: fan zhao > To: Behcet Sarikaya > Cc: Ahmad Muhanna ; mext@ietf.org > Sent: Tuesday, December 2, 2008 3:41:56 PM > Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO > usecase > > Hi Behcet, > > The binding revocation is designed for DSMIPv6 and DSMIPv6 supports > both mobile host > and mobile router. I do not see any issue. > > Sincerely, > fan > > On Tue, Dec 2, 2008 at 11:52 AM, Behcet Sarikaya > wrote: >> Hi Ahmad, >> Can you please explain how MNP is related to your draft? MNP is something >> that MR needs and is specific to Nemo operation not to MN-HA relationship >> and the binding that comes with it. >> So I don't see any binding to revocate with MNPs? >> >> Regards, >> >> Behcet >> >> ________________________________ >> From: Ahmad Muhanna >> To: Desire Oulai ; mext@ietf.org >> Sent: Monday, December 1, 2008 9:22:35 PM >> Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO >> usecase >> >> Hi Desire, >> >> Added a relative subject. >> >> I guess the usecase is clear and it makes sense to me. >> We can add some text similar to yours to capture this functionality under >> the HA and MN operations after the conclusion of the WGLC.. >> >> BTW: Is there anyone who thinks that we should not add this usecase? >> >> Regards, >> Ahmad >> >> >> >> ________________________________ >> From: Desire Oulai [mailto:desire.oulai@ericsson.com] >> Sent: Monday, December 01, 2008 2:46 PM >> To: mext@ietf.org >> Cc: Muhanna, Ahmad (RICH1:2H10) >> Subject: >> >> Hi Ahmad, All, >> >> The Binding revocation draft does not mention revocation related to NEMO. >> If used as is, the BRI will revoke the binding between the MR's HoA and >> CoA. >> I think it's woth adding another level of revocation: revocation of Mobile >> Network Prefixes. A HA may decide to stop forwarding data to the CoA for >> certain MNPs and BR could be used for that. Here is a proposed text for a >> new section: >> >> "In case of NEMO protocol, the HA follows the same procedure as MIPv6 if >> the >> goal is to revoke the binding between the Mobile Router's HoA and CoA. It >> is >> also possible to have finer granularity of revocation targeting the Mobile >> Network Prefixes assigned to the Mobile Router. In this case, the HA sends >> a >> BRI message including one or more MNP options with the A bit set and the >> Revocation Trigger set to a proper value, e.g. Administrative Reasons. >> When >> receiving this BRI, the MR deletes the MNP(s) from the Prefix Information >> field in the Binding Update List and responds with a BRA message. The BRA >> MUST include the MNP(s) contained in the BRI." >> >> Also, Mobile network Prefix should be addes as valid option in section >> "6.2. >> Binding Revocation Acknowledgement Message". >> >> BR >> Desire >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > =09 ------_=_NextPart_001_01C956EA.730BAC55 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi=20 Behcet,
 
Just=20 to clarify one thing here. It seems that we overlooked this use case by = not=20 mentioning it in the draft.
Looking at the presentation that we made at IETF-70 and IETF-71 = it=20 clearly list HA->MR as one of the usecases.
Since=20 that was the basis for this draft that was adopted as a wg document, I = believe=20 we need to include this in the draft.
 
Please=20 find the Binding Revocation slides for IETF-70 & 71 at the = below=20 links:
 
http://w= ww.ietf.org/proceedings/08mar/slides/mext-9.pdf
http://w= ww.ietf.org/proceedings/07dec/slides/mext-4.pdf

Regards, =
Ahmad

 

From: mext-bounces@ietf.org=20 [mailto:mext-bounces@ietf.org] On Behalf Of Behcet=20 Sarikaya
Sent: Wednesday, December 03, 2008 12:00 = PM
To:=20 fan zhao
Cc: mext@ietf.org
Subject: Re: [MEXT] = Binding=20 Revocation for IPv6 Mobility Supports NEMOusecase



From: fan zhao=20 <fanzhao828@gmail.com>
To: Behcet Sarikaya=20 <sarikaya@ieee.org>
Cc:=20 mext@ietf.org
Sent: = Tuesday,=20 December 2, 2008 5:47:35 PM
Subject: Re: [MEXT] Binding = Revocation=20 for IPv6 Mobility Supports NEMO usecase

Hi = Behcet,

There=20 is a difference between binding revocation for MNPs and
MNP=20 release.
When the binding revocation for MNPs is performed, the=20 MNP
information stored in the binding cache entry for the MR = is
removed,=20 which means that the packets for such MNP will not
be tunneled by = the HA;=20 however, such MNP is not explicitly
released by the binding = revocation.=20 This is needed because
the mobile network nodes connecting to the = MR=20 before
may handover to their home network (such as wimax) = while
the MR=20 still stays in its foreign link (since for example the MR
does not = have the=20 wimax interface); therefore, such MNP
should still be made valid = for such=20 mobile network nodes.

To release such MNP, the same method to = allocate=20 the
MNP should be used. For example, if the MNP is allocated
by = using=20 DHCP, then DHCP needs to be used again to remove
such MNP. This is = similar=20 to the MIPv6 case where the MN
sends the BU with the = lifetime=3Dzero or the=20 HA sends the BRI
to remove the binding, the home address on the = other=20 hand
needs to remove by deleting the IPsec SA if this is = detach.

It=20 makes sense to me using the BR to remove the MNP from
the BCE since = such=20 MNP is registered by using BU and
BR is the opposite way to=20 BU.

[behcet ] So it is the MR that knows=20 the situation and MR = should=20 initiate MNP release. Doing it with BR would be server-initiated which = is=20 something to be considered for prefix renumbering which has nothing to = do with=20 the release.

Sincerely,
fan

On Tue, Dec 2, = 2008 at=20 2:50 PM, Behcet Sarikaya
<behcetsarikaya@yahoo.com&= gt;=20 wrote:
> Hi Fan,
>  Prefix delegation/authorization = function=20 should take care of this. In DHCP
> PD there is a way to release = the=20 prefixes.
>
> Regards,
>
> = Behcet
>
>=20 ________________________________
> From: fan zhao <fanzhao828@gmail.com>
&= gt; To:=20 Behcet Sarikaya <sarikaya@ieee.org>
> = Cc: Ahmad=20 Muhanna <amuhanna@nortel.com>; mext@ietf.org
> Sent: = Tuesday,=20 December 2, 2008 3:41:56 PM
> Subject: Re: [MEXT] Binding = Revocation for=20 IPv6 Mobility Supports NEMO
> usecase
>
> Hi=20 Behcet,
>
> The binding revocation is designed for DSMIPv6 = and=20 DSMIPv6 supports
> both mobile host
> and mobile router. I = do not=20 see any issue.
>
> Sincerely,
> fan
>
> = On Tue,=20 Dec 2, 2008 at 11:52 AM, Behcet Sarikaya
> <behcetsarikaya@yahoo.com&= gt;=20 wrote:
>> Hi Ahmad,
>>  Can you please explain = how MNP=20 is related to your draft? MNP is something
>> that MR needs = and is=20 specific to Nemo operation not to MN-HA relationship
>> and = the=20 binding that comes with it.
>>  So I don't see any = binding to=20 revocate with MNPs?
>>
>> = Regards,
>>
>>=20 Behcet
>>
>> = ________________________________
>>=20 From: Ahmad Muhanna <amuhanna@nortel.com>
>= ;>=20 To: Desire Oulai <desire.oulai@ericsson.com>;=20 mext@ietf.org
>> Sent: = Monday,=20 December 1, 2008 9:22:35 PM
>> Subject: Re: [MEXT] Binding = Revocation=20 for IPv6 Mobility Supports NEMO
>> = usecase
>>
>> Hi=20 Desire,
>>
>> Added a relative=20 subject.
>>
>> I guess the usecase is clear and it = makes=20 sense to me.
>> We can add some text similar to yours to = capture this=20 functionality under
>> the HA and MN operations after the = conclusion=20 of the WGLC..
>>
>> BTW: Is there anyone who thinks = that we=20 should not add this usecase?
>>
>> = Regards,
>>=20 Ahmad
>>
>>
>>
>>=20 ________________________________
>> From: Desire Oulai = [mailto:desire.oulai@ericsson.com]
>>=20 Sent: Monday, December 01, 2008 2:46 PM
>> To: mext@ietf.org
>> Cc: = Muhanna,=20 Ahmad (RICH1:2H10)
>> Subject:
>>
>> Hi = Ahmad,=20 All,
>>
>>  The Binding revocation draft does = not=20 mention revocation related to NEMO.
>> If used as is, the BRI = will=20 revoke the binding between the MR's HoA and
>> = CoA.
>> I=20 think it's woth adding another level of revocation: revocation of=20 Mobile
>> Network Prefixes. A HA may decide to stop = forwarding data=20 to the CoA for
>> certain MNPs and BR could be used for that. = Here is=20 a proposed text for a
>> new section:
>>
>> = "In=20 case of NEMO protocol, the HA follows the same procedure as MIPv6=20 if
>> the
>> goal is to revoke the binding between = the=20 Mobile Router's HoA and CoA. It
>> is
>> also = possible to=20 have finer granularity of revocation targeting the Mobile
>> = Network=20 Prefixes assigned to the Mobile Router. In this case, the HA = sends
>>=20 a
>> BRI message including one or more MNP options with the A = bit set=20 and the
>> Revocation Trigger set to a proper value, e.g.=20 Administrative Reasons.
>> When
>> receiving this = BRI, the=20 MR deletes the MNP(s) from the Prefix Information
>> field in = the=20 Binding Update List and responds with a BRA message. The = BRA
>> MUST=20 include the MNP(s) contained in the BRI."
>>
>> = Also, Mobile=20 network Prefix should be addes as valid option in section
>>=20 "6.2.
>> Binding Revocation Acknowledgement=20 Message".
>>
>> BR
>>=20 Desire
>>
>>=20 _______________________________________________
>> MEXT = mailing=20 list
>> MEXT@ietf.org
>> https://www.ietf.org/mailman/listinfo/mext
>>= ;
>>
>
>

------_=_NextPart_001_01C956EA.730BAC55-- --===============0554662071== 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 --===============0554662071==-- From mext-bounces@ietf.org Fri Dec 5 07:55:10 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24F4928C157; Fri, 5 Dec 2008 07:55:10 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 992EC28C157 for ; Fri, 5 Dec 2008 07:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 44-I0Vk+7r6k for ; Fri, 5 Dec 2008 07:55:07 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with SMTP id 95DA83A6C80 for ; Fri, 5 Dec 2008 07:55:07 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1228492501!28964651!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 6949 invoked from network); 5 Dec 2008 15:55:01 -0000 Received: from unknown (HELO motgate4.mot.com) (136.182.1.14) by server-7.tower-119.messagelabs.com with SMTP; 5 Dec 2008 15:55:01 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id mB5Ft1jK017063; Fri, 5 Dec 2008 08:55:01 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id mB5Ft1dC023776; Fri, 5 Dec 2008 09:55:01 -0600 (CST) Received: from [127.0.0.1] ([10.161.201.117]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id mB5Fsx7w023744; Fri, 5 Dec 2008 09:55:00 -0600 (CST) Message-ID: <49394ED3.1080801@gmail.com> Date: Fri, 05 Dec 2008 16:54:59 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: marcelo bagnulo braun References: <49379699.4020501@it.uc3m.es> In-Reply-To: <49379699.4020501@it.uc3m.es> X-Antivirus: avast! (VPS 081204-0, 04/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext Subject: Re: [MEXT] [Fwd: Re: access to ETSI standards] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org marcelo bagnulo braun wrote: > FYI Where is the url to access ETSI's "European profile standard of IEEE 802.11", in particular for 802.11p? Thank you, Alex > > -------- Mensaje original -------- Asunto: Re: access to ETSI > standards Fecha: Wed, 3 Dec 2008 22:07:26 +0100 De: Andreas > Festag Para: marcelo bagnulo braun > CC: Julien Laganier > , Soeren Hess , > Martin Arndt Referencias: > <4932D0F1.3010308@it.uc3m.es> > > > > Dear Marcelo, > > As for ETSI work, I can say that in TC ITS WG4 (Media) there is > currently an ongoing effort to prepare a "European profile standard > of IEEE 802.11". The intention is to determine those features of the > 802.11 standard that are relevant for its deployment in Europe, in > particular for IEEE 802.11p. It is important to note that this > profile standard does not rewrite the current 802.11 standard but > represents rather a subset and possibly some extensions. In general, > all ETSI standards are publicly available and free-of-charge, access > is assured after completion of the standard. I expect that the > "European profile standard of IEEE 802.11" will be completed in the > 1st half year (Soeren, please correct if I am wrong). > > Kind regards, > > Andreas > > On 30.11.2008, at 18:44, marcelo bagnulo braun wrote: > >> Hi, >> >> As you may have seen, there are members of the MEXT wg that are >> asking to have access to the standards related to the link layer >> technology used in the automotive scenario. I was wondering if you >> could provide some guidance about this. >> >> Thanks, marcelo >> > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 5 07:58: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 B713F3A67AE; Fri, 5 Dec 2008 07:58:59 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5545B3A67AE for ; Fri, 5 Dec 2008 07:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.872 X-Spam-Level: X-Spam-Status: No, score=-5.872 tagged_above=-999 required=5 tests=[AWL=0.727, 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 ifmxj6yNnS-0 for ; Fri, 5 Dec 2008 07:58:57 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 9DAB93A63D3 for ; Fri, 5 Dec 2008 07:58:57 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1228492732!18309276!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 23615 invoked from network); 5 Dec 2008 15:58:52 -0000 Received: from unknown (HELO motgate4.mot.com) (136.182.1.14) by server-10.tower-128.messagelabs.com with SMTP; 5 Dec 2008 15:58:52 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id mB5FwqeX017694; Fri, 5 Dec 2008 08:58:52 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id mB5FwqnJ026446; Fri, 5 Dec 2008 09:58:52 -0600 (CST) Received: from [127.0.0.1] ([10.161.201.117]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id mB5FwpcS026435; Fri, 5 Dec 2008 09:58:51 -0600 (CST) Message-ID: <49394FBA.9080806@gmail.com> Date: Fri, 05 Dec 2008 16:58:50 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Roberto Baldessari References: <547F018265F92642B577B986577D671C4FBFEE@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C4FBFEE@VENUS.office> X-Antivirus: avast! (VPS 081204-0, 04/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext Subject: Re: [MEXT] non-IETF standards for draft-ietf-mext-nemo-ro-automotive-req-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Dear Roberto, Roberto Baldessari wrote: [...] > IEEE 802.11p and IEEE 1609.X are two separate standard drafts. The > 1609 family specifies additional protocols (WSMP) and mechanisms to > be used on top/in combination of/with 802.11p. In Europe 1609 does > not have much consensus for various reasons. ETSI is likely to make a > profile of 802.11p and redefine some functionalities that are offered > by 1609 but in a different way. Further, 11p and 1609 are going to > change. The latest 11p version is D4.02, Sept 2008. Please send me in private 11p D4.02 dated September 2008. > To cut the story short, 1609 is not assumed in the draft. Feel free > to contact me offline if you need more info (I feel we're getting out > of scope of this ML). I need to identify precisely what can be done in IETF MEXT about: 1609, 11p and ETSI European Profile. I will contact you in private about these documents. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 5 08:09:28 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DFDB3A6ABA; Fri, 5 Dec 2008 08:09:28 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0263A6ABA for ; Fri, 5 Dec 2008 08:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 VPuxz9F3prBY for ; Fri, 5 Dec 2008 08:09:25 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 6F0EF3A687B for ; Fri, 5 Dec 2008 08:09:25 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 30C982C00C9A2; Fri, 5 Dec 2008 17:09:20 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SAe6wNob3eu; Fri, 5 Dec 2008 17:09:20 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 0BFD72C0012CA; Fri, 5 Dec 2008 17:09:05 +0100 (CET) Received: from n-festag.office ([10.1.6.229]) by VENUS.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Dec 2008 17:09:04 +0100 Message-Id: <929882D5-118E-492A-A9D9-BFC54A3F73EE@nw.neclab.eu> From: Andreas Festag To: Alexandru Petrescu In-Reply-To: <49394ED3.1080801@gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 5 Dec 2008 17:09:04 +0100 References: <49379699.4020501@it.uc3m.es> <49394ED3.1080801@gmail.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 05 Dec 2008 16:09:05.0016 (UTC) FILETIME=[CBA15780:01C956F3] Cc: mext Subject: Re: [MEXT] [Fwd: Re: access to ETSI standards] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Dear Alexandru, The document will be published after its completion. As for the estimated time: Currently, the draft is being developed and initial versions are under discussions. I expect 1st half of 2009. Kind regards, Andreas On 05.12.2008, at 16:54, Alexandru Petrescu wrote: > marcelo bagnulo braun wrote: >> FYI > > Where is the url to access ETSI's "European profile standard of IEEE > 802.11", in particular for 802.11p? > > Thank you, > > Alex > >> -------- Mensaje original -------- Asunto: Re: access to ETSI >> standards Fecha: Wed, 3 Dec 2008 22:07:26 +0100 De: Andreas >> Festag Para: marcelo bagnulo braun >> CC: Julien Laganier >> , Soeren Hess , >> Martin Arndt Referencias: >> <4932D0F1.3010308@it.uc3m.es> >> Dear Marcelo, >> As for ETSI work, I can say that in TC ITS WG4 (Media) there is >> currently an ongoing effort to prepare a "European profile standard >> of IEEE 802.11". The intention is to determine those features of the >> 802.11 standard that are relevant for its deployment in Europe, in >> particular for IEEE 802.11p. It is important to note that this >> profile standard does not rewrite the current 802.11 standard but >> represents rather a subset and possibly some extensions. In general, >> all ETSI standards are publicly available and free-of-charge, access >> is assured after completion of the standard. I expect that the >> "European profile standard of IEEE 802.11" will be completed in the >> 1st half year (Soeren, please correct if I am wrong). >> Kind regards, >> Andreas >> On 30.11.2008, at 18:44, marcelo bagnulo braun wrote: >>> Hi, >>> As you may have seen, there are members of the MEXT wg that are >>> asking to have access to the standards related to the link layer >>> technology used in the automotive scenario. I was wondering if you >>> could provide some guidance about this. >>> Thanks, marcelo > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 5 08:18:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D554B28C18A; Fri, 5 Dec 2008 08:18:54 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A281E3A6A82 for ; Fri, 5 Dec 2008 08:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.644 X-Spam-Level: X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHr6FIugUsE9 for ; Fri, 5 Dec 2008 08:18:52 -0800 (PST) Received: from web111416.mail.gq1.yahoo.com (web111416.mail.gq1.yahoo.com [67.195.15.222]) by core3.amsl.com (Postfix) with SMTP id 1D18D3A682D for ; Fri, 5 Dec 2008 08:18:52 -0800 (PST) Received: (qmail 87197 invoked by uid 60001); 5 Dec 2008 16:18:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=beiepiBG/8MfET6h0XRHRtTKzlAfTb8C+WynXC82S31mf9HprYYKOm91amFNzS+GjCjO/l6Fywxn8UeQE5WlVPV+YnCG5/dRhBixcVWF50KrJSdXVpHoU7Zh2qHXUjcwOO1F5dqCHX4f5A+NWioBP0KBVTPWnYSaS6Eo86yeB+0=; X-YMail-OSG: iE4FVkIVM1m.LxeCCd9s5BuqEz2DXrN_VJPu2QglhnMRhUef5QAC8zOuIIYy6H2m3zyaVqAf3VHIZXntTzEuzxSO4NIZJahFmQfsw2x7GR16ZRWbRxnhKtUaOH7VMiIHGLf_aSFZna0V2FdgrHjWm4ShruOqgdZFZeAVwAFcU5De4wg- Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Fri, 05 Dec 2008 08:18:47 PST X-Mailer: YahooMailRC/1155.32 YahooMailWebService/0.7.260.1 References: <570090.92095.qm@web111410.mail.gq1.yahoo.com><496302.84429.qm@web111411.mail.gq1.yahoo.com> <356714.19242.qm@web111409.mail.gq1.yahoo.com> Date: Fri, 5 Dec 2008 08:18:47 -0800 (PST) From: Behcet Sarikaya To: Ahmad Muhanna MIME-Version: 1.0 Message-ID: <442560.87107.qm@web111416.mail.gq1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMOusecase 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="===============0075087631==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0075087631== Content-Type: multipart/alternative; boundary="0-1180675062-1228493927=:87107" --0-1180675062-1228493927=:87107 Content-Type: text/plain; charset=us-ascii Hi Ahmad, Currently your draft does not talk about Nemo. If you wish to include MR, I think it is easy: You can say that MIP6, DSMIP6 cases apply to MR acting as MN. PMIP6 case also applies to MR acting as MR not as MAG. BRI sending entity has to make sure that MNPs are removed from the binding cache before sending the revocation. Profiting the occasion, I found a few typos in your draft : typos: sends a BRA message to the LMA following the rules describes -->described 3.4.3. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings -> Revokes Regards, Behcet ________________________________ From: Ahmad Muhanna To: Behcet Sarikaya ; fan zhao Cc: mext@ietf.org Sent: Friday, December 5, 2008 9:02:10 AM Subject: RE: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMOusecase Hi Behcet, Just to clarify one thing here. It seems that we overlooked this use case by not mentioning it in the draft. Looking at the presentation that we made at IETF-70 and IETF-71 it clearly list HA->MR as one of the usecases. Since that was the basis for this draft that was adopted as a wg document, I believe we need to include this in the draft. Please find the Binding Revocation slides for IETF-70 & 71 at the below links: http://www.ietf.org/proceedings/08mar/slides/mext-9.pdf http://www.ietf.org/proceedings/07dec/slides/mext-4.pdf Regards, Ahmad ________________________________ From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Wednesday, December 03, 2008 12:00 PM To: fan zhao Cc: mext@ietf.org Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMOusecase ________________________________ From: fan zhao To: Behcet Sarikaya Cc: mext@ietf.org Sent: Tuesday, December 2, 2008 5:47:35 PM Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase Hi Behcet, There is a difference between binding revocation for MNPs and MNP release. When the binding revocation for MNPs is performed, the MNP information stored in the binding cache entry for the MR is removed, which means that the packets for such MNP will not be tunneled by the HA; however, such MNP is not explicitly released by the binding revocation. This is needed because the mobile network nodes connecting to the MR before may handover to their home network (such as wimax) while the MR still stays in its foreign link (since for example the MR does not have the wimax interface); therefore, such MNP should still be made valid for such mobile network nodes. To release such MNP, the same method to allocate the MNP should be used. For example, if the MNP is allocated by using DHCP, then DHCP needs to be used again to remove such MNP. This is similar to the MIPv6 case where the MN sends the BU with the lifetime=zero or the HA sends the BRI to remove the binding, the home address on the other hand needs to remove by deleting the IPsec SA if this is detach. It makes sense to me using the BR to remove the MNP from the BCE since such MNP is registered by using BU and BR is the opposite way to BU. [behcet ] So it is the MR that knows thesituation and MR should initiate MNP release. Doing it with BR would be server-initiated which is something to be considered for prefix renumbering which has nothing to do with the release. Sincerely, fan On Tue, Dec 2, 2008 at 2:50 PM, Behcet Sarikaya wrote: > Hi Fan, > Prefix delegation/authorization function should take care of this. In DHCP > PD there is a way to release the prefixes. > > Regards, > > Behcet > > ________________________________ > From: fan zhao > To: Behcet Sarikaya > Cc: Ahmad Muhanna ; mext@ietf.org > Sent: Tuesday, December 2, 2008 3:41:56 PM > Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO > usecase > > Hi Behcet, > > The binding revocation is designed for DSMIPv6 and DSMIPv6 supports > both mobile host > and mobile router. I do not see any issue. > > Sincerely, > fan > > On Tue, Dec 2, 2008 at 11:52 AM, Behcet Sarikaya > wrote: >> Hi Ahmad, >> Can you please explain how MNP is related to your draft? MNP is something >> that MR needs and is specific to Nemo operation not to MN-HA relationship >> and the binding that comes with it. >> So I don't see any binding to revocate with MNPs? >> >> Regards, >> >> Behcet >> >> ________________________________ >> From: Ahmad Muhanna >> To: Desire Oulai ; mext@ietf.org >> Sent: Monday, December 1, 2008 9:22:35 PM >> Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO >> usecase >> >> Hi Desire, >> >> Added a relative subject. >> >> I guess the usecase is clear and it makes sense to me. >> We can add some text similar to yours to capture this functionality under >> the HA and MN operations after the conclusion of the WGLC.. >> >> BTW: Is there anyone who thinks that we should not add this usecase? >> >> Regards, >> Ahmad >> >> >> >> ________________________________ >> From: Desire Oulai [mailto:desire.oulai@ericsson.com] >> Sent: Monday, December 01, 2008 2:46 PM >> To: mext@ietf.org >> Cc: Muhanna, Ahmad (RICH1:2H10) >> Subject: >> >> Hi Ahmad, All, >> >> The Binding revocation draft does not mention revocation related to NEMO. >> If used as is, the BRI will revoke the binding between the MR's HoA and >> CoA. >> I think it's woth adding another level of revocation: revocation of Mobile >> Network Prefixes. A HA may decide to stop forwarding data to the CoA for >> certain MNPs and BR could be used for that. Here is a proposed text for a >> new section: >> >> "In case of NEMO protocol, the HA follows the same procedure as MIPv6 if >> the >> goal is to revoke the binding between the Mobile Router's HoA and CoA. It >> is >> also possible to have finer granularity of revocation targeting the Mobile >> Network Prefixes assigned to the Mobile Router. In this case, the HA sends >> a >> BRI message including one or more MNP options with the A bit set and the >> Revocation Trigger set to a proper value, e.g. Administrative Reasons. >> When >> receiving this BRI, the MR deletes the MNP(s) from the Prefix Information >> field in the Binding Update List and responds with a BRA message. The BRA >> MUST include the MNP(s) contained in the BRI." >> >> Also, Mobile network Prefix should be addes as valid option in section >> "6.2. >> Binding Revocation Acknowledgement Message". >> >> BR >> Desire >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > --0-1180675062-1228493927=:87107 Content-Type: text/html; charset=us-ascii
Hi Ahmad,
  Currently your draft does not talk about Nemo. If you wish to include MR, I think it is easy: You can say that MIP6, DSMIP6 cases apply to MR acting as MN.
PMIP6 case also applies to MR acting as MR not as MAG.
BRI sending entity has to make sure that MNPs are removed from the binding cache before sending the revocation.

  Profiting the occasion, I found a few typos in your draft :


typos: sends a BRA message to the LMA following the rules describes
-->described
3.4.3. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings
-> Revokes

Regards,

Behcet

From: Ahmad Muhanna <amuhanna@nortel.com>
To: Behcet Sarikaya <sarikaya@ieee.org>; fan zhao <fanzhao828@gmail.com>
Cc: mext@ietf.org
Sent: Friday, December 5, 2008 9:02:10 AM
Subject: RE: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMOusecase

Hi Behcet,
 
Just to clarify one thing here. It seems that we overlooked this use case by not mentioning it in the draft.
Looking at the presentation that we made at IETF-70 and IETF-71 it clearly list HA->MR as one of the usecases.
Since that was the basis for this draft that was adopted as a wg document, I believe we need to include this in the draft.
 
Please find the Binding Revocation slides for IETF-70 & 71 at the below links:
 

Regards,
Ahmad

 

From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Wednesday, December 03, 2008 12:00 PM
To: fan zhao
Cc: mext@ietf.org
Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMOusecase



From: fan zhao <fanzhao828@gmail.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: mext@ietf.org
Sent: Tuesday, December 2, 2008 5:47:35 PM
Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO usecase

Hi Behcet,

There is a difference between binding revocation for MNPs and
MNP release.
When the binding revocation for MNPs is performed, the MNP
information stored in the binding cache entry for the MR is
removed, which means that the packets for such MNP will not
be tunneled by the HA; however, such MNP is not explicitly
released by the binding revocation. This is needed because
the mobile network nodes connecting to the MR before
may handover to their home network (such as wimax) while
the MR still stays in its foreign link (since for example the MR
does not have the wimax interface); therefore, such MNP
should still be made valid for such mobile network nodes.

To release such MNP, the same method to allocate the
MNP should be used. For example, if the MNP is allocated
by using DHCP, then DHCP needs to be used again to remove
such MNP. This is similar to the MIPv6 case where the MN
sends the BU with the lifetime=zero or the HA sends the BRI
to remove the binding, the home address on the other hand
needs to remove by deleting the IPsec SA if this is detach.

It makes sense to me using the BR to remove the MNP from
the BCE since such MNP is registered by using BU and
BR is the opposite way to BU.

[behcet ] So it is the MR that knows the situation and MR should initiate MNP release. Doing it with BR would be server-initiated which is something to be considered for prefix renumbering which has nothing to do with the release.

Sincerely,
fan

On Tue, Dec 2, 2008 at 2:50 PM, Behcet Sarikaya
<behcetsarikaya@yahoo.com> wrote:
> Hi Fan,
>  Prefix delegation/authorization function should take care of this. In DHCP
> PD there is a way to release the prefixes.
>
> Regards,
>
> Behcet
>
> ________________________________
> From: fan zhao <fanzhao828@gmail.com>
> To: Behcet Sarikaya <sarikaya@ieee.org>
> Cc: Ahmad Muhanna <amuhanna@nortel.com>; mext@ietf.org
> Sent: Tuesday, December 2, 2008 3:41:56 PM
> Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO
> usecase
>
> Hi Behcet,
>
> The binding revocation is designed for DSMIPv6 and DSMIPv6 supports
> both mobile host
> and mobile router. I do not see any issue.
>
> Sincerely,
> fan
>
> On Tue, Dec 2, 2008 at 11:52 AM, Behcet Sarikaya
> <behcetsarikaya@yahoo.com> wrote:
>> Hi Ahmad,
>>  Can you please explain how MNP is related to your draft? MNP is something
>> that MR needs and is specific to Nemo operation not to MN-HA relationship
>> and the binding that comes with it.
>>  So I don't see any binding to revocate with MNPs?
>>
>> Regards,
>>
>> Behcet
>>
>> ________________________________
>> From: Ahmad Muhanna <amuhanna@nortel.com>
>> To: Desire Oulai <desire.oulai@ericsson.com>; mext@ietf.org
>> Sent: Monday, December 1, 2008 9:22:35 PM
>> Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMO
>> usecase
>>
>> Hi Desire,
>>
>> Added a relative subject.
>>
>> I guess the usecase is clear and it makes sense to me.
>> We can add some text similar to yours to capture this functionality under
>> the HA and MN operations after the conclusion of the WGLC..
>>
>> BTW: Is there anyone who thinks that we should not add this usecase?
>>
>> Regards,
>> Ahmad
>>
>>
>>
>> ________________________________
>> From: Desire Oulai [mailto:desire.oulai@ericsson.com]
>> Sent: Monday, December 01, 2008 2:46 PM
>> To: mext@ietf.org
>> Cc: Muhanna, Ahmad (RICH1:2H10)
>> Subject:
>>
>> Hi Ahmad, All,
>>
>>  The Binding revocation draft does not mention revocation related to NEMO.
>> If used as is, the BRI will revoke the binding between the MR's HoA and
>> CoA.
>> I think it's woth adding another level of revocation: revocation of Mobile
>> Network Prefixes. A HA may decide to stop forwarding data to the CoA for
>> certain MNPs and BR could be used for that. Here is a proposed text for a
>> new section:
>>
>> "In case of NEMO protocol, the HA follows the same procedure as MIPv6 if
>> the
>> goal is to revoke the binding between the Mobile Router's HoA and CoA. It
>> is
>> also possible to have finer granularity of revocation targeting the Mobile
>> Network Prefixes assigned to the Mobile Router. In this case, the HA sends
>> a
>> BRI message including one or more MNP options with the A bit set and the
>> Revocation Trigger set to a proper value, e.g. Administrative Reasons.
>> When
>> receiving this BRI, the MR deletes the MNP(s) from the Prefix Information
>> field in the Binding Update List and responds with a BRA message. The BRA
>> MUST include the MNP(s) contained in the BRI."
>>
>> Also, Mobile network Prefix should be addes as valid option in section
>> "6.2.
>> Binding Revocation Acknowledgement Message".
>>
>> BR
>> Desire
>>
>> _______________________________________________
>> MEXT mailing list
>> MEXT@ietf.org
>> https://www.ietf.org/mailman/listinfo/mext
>>
>>
>
>


--0-1180675062-1228493927=:87107-- --===============0075087631== 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 --===============0075087631==-- From mext-bounces@ietf.org Sat Dec 6 02:41: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 7FF903A692A; Sat, 6 Dec 2008 02:41:27 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA5633A692A for ; Sat, 6 Dec 2008 02:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.037 X-Spam-Level: X-Spam-Status: No, score=-5.037 tagged_above=-999 required=5 tests=[AWL=1.562, 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 6yVGaFv9pV5j for ; Sat, 6 Dec 2008 02:41:26 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 076483A684F for ; Sat, 6 Dec 2008 02:41:24 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (181.pool85-53-129.dynamic.orange.es [85.53.129.181])by smtp02.uc3m.es (Postfix) with ESMTP id 4273A634F6Afor ; Sat, 6 Dec 2008 11:41:14 +0100 (CET) Message-ID: <493A56C9.2020901@it.uc3m.es> Date: Sat, 06 Dec 2008 11:41:13 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: mext References: <4925C0B4.4010408@it.uc3m.es> In-Reply-To: <4925C0B4.4010408@it.uc3m.es> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-10.2848 TC:1F TRN:14 TV:5.5.1026(16322.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: Re: [MEXT] Deadline for accetping issues for RFC3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org The period for accepting rfc3775bis is over. We will handle the additional issues that were received up to now and we = will try to close rfc3775bis right after that Regards, marcelo marcelo bagnulo braun escribi=F3: > Hi, > > We are closing the rfc3775bis process. > We are accepting new issues for rfc3775bis until dec 5 2008. > Issues brought later than this will not be considered for this round = > of changes in rfc3775. > > Regards, Julien and marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From marikocsk@aiu.ac.jp Sat Dec 6 08:41:53 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB9FF3A67E6 for ; Sat, 6 Dec 2008 08:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BLUEYON=1.4, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUbfNWHXQpTW for ; Sat, 6 Dec 2008 08:41:53 -0800 (PST) Received: from 82-40-29-47.cable.ubr04.uddi.blueyonder.co.uk (82-40-29-47.cable.ubr04.uddi.blueyonder.co.uk [82.40.29.47]) by core3.amsl.com (Postfix) with SMTP id 383E83A67B3 for ; Sat, 6 Dec 2008 08:41:51 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081206164152.383E83A67B3@core3.amsl.com> Date: Sat, 6 Dec 2008 08:41:51 -0800 (PST) Click to visit Official Web Site! From jbelmontb7@alicorp.com.pe Sat Dec 6 16:24:45 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AC583A693F for ; Sat, 6 Dec 2008 16:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.829 X-Spam-Level: X-Spam-Status: No, score=-21.829 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rb+PgT6eKXKK for ; Sat, 6 Dec 2008 16:24:44 -0800 (PST) Received: from ais.co.th (unknown [89.119.130.138]) by core3.amsl.com (Postfix) with SMTP id 50BC03A68A4 for ; Sat, 6 Dec 2008 16:24:42 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081207002443.50BC03A68A4@core3.amsl.com> Date: Sat, 6 Dec 2008 16:24:42 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From motosycuatriciclos2008_@gmail.com Sat Dec 6 17:30:17 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D48AE3A6866; Sat, 6 Dec 2008 17:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.617 X-Spam-Level: **** X-Spam-Status: No, score=4.617 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 fb2x0td275sf; Sat, 6 Dec 2008 17:30:17 -0800 (PST) Received: from maildcarg4.dc-host.net.ar (maildcarg4.dc-host.net.ar [200.55.6.135]) by core3.amsl.com (Postfix) with ESMTP id 8BDF83A6358; Sat, 6 Dec 2008 17:30:17 -0800 (PST) Received: from localhost ([190.245.9.133]) by maildcarg4.dc-host.net.ar (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0KBH001BQG5UKZC0@maildcarg4.dc-host.net.ar>; Sat, 06 Dec 2008 22:29:57 -0300 (ART) Received: from f3t ([127.0.0.1]) by localhost with SMTP (Code-Crafters Ability Mail Server 2.61); Sat, 06 Dec 2008 23:19:13 +0100 Date: Sat, 06 Dec 2008 23:19:13 +0100 From: "motosycuatriciclos2008@gmail.com" Subject: MOTOS Y CUATRICICLOS PARA EL INTERIOR To: myc Reply-to: "motosycuatriciclos2008@gmail.com" Message-id: <3814-22008126622191378@f3t> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable MOTOS Y CUATRICICLOS * CONCESIONARIA OFICIAL * ZANELLA-MONDIAL- JIANSHE-X-SCREAMS- PHANTER- CERRO EMAIL: motosycuatriciclos2008@gmail=2Ecom BUSCA REVENDEDORES PARA TODO EL PAIS Beneficios:=20 FINANCIACI=D3N HASTA 36 CUOTAS FIJAS PARA SUS CLIENTES con CON RECIBO DE S= UELDO Y/=D3 MONOTRIBUTO, o JUBILACION o PENSION Puede realizar el pago con tarjeta de credito Telefonicamente, tarjetas VI= SA, Mastercard, American Express, Tarjeta Naranja, Cabal y Tarjeta Shoppin= g hasta en 24 cuotas FIJAS y en PESOS SEGUROS: ATM EN RESPONSABILIDAD CIVIL Y ROBO SERVICIO DE GESTOR=CDA Y ASESORAMIENTO PARA PATENTAR LA UNIDAD SOMOS REPRESENTANTES DE LO JACK CASCOS, ACCESORIOS, REPUESTOS (los requisitos son D=2EN=2EI , recibo de sueldo y un servicio)=2E Los precios incluyen iva 21 % y hacemos Factura tipo A o B, facturamos al = cliente de manera directa, con lo cual no tiene que estar inscripto No dude en consultar Email: motosycuatriciclos2008@gmail=2Ecom MSN: motosycuatriciclos2008@gmail=2Ecom From mext-bounces@ietf.org Sun Dec 7 22:09: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 6109E3A6A2D; Sun, 7 Dec 2008 22:09:05 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76DEB3A6A2D for ; Sun, 7 Dec 2008 22:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Hzb8K3rxXCf for ; Sun, 7 Dec 2008 22:09:02 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id C40333A68D0 for ; Sun, 7 Dec 2008 22:09:00 -0800 (PST) Received: from [211.27.108.142] (helo=[10.0.0.21]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1L9ZIX-0007jl-Jz; Mon, 08 Dec 2008 17:08:50 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Mon, 08 Dec 2008 17:08:34 +1100 From: Hesham Soliman To: Arnaud Ebalard Message-ID: Thread-Topic: Comments on draft-ietf-mext-nemo-v4traversal-06.txt Thread-Index: AclY+2a1NYjg1PeITkWKS6zDYuePZA== In-Reply-To: <87abbdm7my.fsf_-_@natisbad.org> Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org >> 2.1. Motivation for Using Mobile IPv6 Only >> >> IPv6 offers a number of improvements over today's IPv4, primarily due >> to its large address space. Mobile IPv6 offers a number of >> improvements over Mobile IPv4 [RFC3344], mainly due to capabilities >> inherited from IPv6. For instance, route optimization and dynamic >> home agent discovery can only be achieved with Mobile IPv6. >> >> One of the advantages of the large address space provided by IPv6 is >> that it allows mobile nodes to obtain a globally unique care-of >> address wherever they are. Hence, there is no need for Network >> Address Translator (NAT) traversal techniques designed for Mobile >> IPv4. This allows Mobile IPv6 to be a significantly simpler and more >> bandwidth efficient mobility management protocol. At the same time, >> during the transition towards IPv6, NAT traversal for existing >> private IPv4 networks needs to be considered. This specification >> introduces NAT traversal for this purpose. >> >> The above benefits make the case for using Mobile IPv6 only for dual >> stack mobile nodes in order to allow for a long lasting mobility >> solution and minimize the need to changing the mobility stack due to >> the introduction of IPv6 within a deployed network. > > Perhaps it is just my english, but I fail to understand last paragraph. => Well, it's a very long sentence! I'll clean up. > >> 3.2. Mobile Prefix Solicitation and Advertisement >> >> According to [RFC3775], the mobile node can send a Mobile Prefix >> Solicitation and receive a Mobile Prefix Advertisement containing all >> prefixes advertised on the home link. >> >> A dual stack mobile node MAY send a Mobile Prefix Solicitation >> message encapsulated in IPv4 (i.e., IPv6 in IPv4) in the case where >> the mobile node has no access to IPv6 within the local network. >> Securing these messages requires the mobile node to have a security >> association with the home agent, using IPsec (AH or ESP) and based on >> the mobile node's IPv4 care-of address as described in [RFC3775]. >> Since the mobile node needs to encapsulate all IPv6 traffic sent to >> the home agent into IPv4 while located in an IPv4-only visited >> network, this SA would match all packets if the selectors were based >> on the information in the outer header. That is, the SA selectors >> being the protocol number (protocol is always IP in IP), as well as, >> source and destination addresses are all common to all packets. > > Possibly me but last sentence seems incorrect. If not, what is its > meaning? => It means that the SA selectors would be the same for all packets. >> When a mobile node acquires both IPv4 and IPv6 care-of addresses at >> the foreign network, it SHOULD prioritize the IPv6 care-of address >> for it MIPv6 its binding. > > Last sentence seems incorrect. => why? It looks good to me. >> IPv4 Care-of Address >> >> This field contains the mobile node's IPv4 care- of address. The > > care-of > > >> 5.2. NAT Detection >> >> This section deals with NAT detection for the purpose of >> encapsulating packets between the mobile node and the home agent. >> Mobile IPv6 uses IKEv2 to establish te IPsec security association >> between the mobile node and the home agent. > > IKE is not mandatory, it is only optional. Or did I missed a reference > document? => Yes it's mandatory. I think there is a reference, if not, it will be added. > > What about 'may use IKE ...' => No I don't think that's right. >> >> If no NAT device was detected in the path between the mobile node and >> the home agent then IPv6 packets are tunneled in an IPv4 header, >> unless the home agent forces UDP encapsulation using the F flag. The >> content of the inner and outer headers are identical to the UDP >> encapsulation case. > > What if filtering somewhere prevents IP over IP but is fine with UDP > encapsulated traffic. If the HA decides to go for IP over IP (i.e. does > not force the F flag), this will not work. => Please see the latest draft. There is a new section on this. Ultimately, if the MN wants to force the F flag and the HA doesn't then the HA wins. This is the nature of the protocol, the HA decides. >> The effect of these address selection mechanism is to allow the >> follwing preferences: > > following > > >> In cases where this specification is used for NAT traversal, it is >> important to note that it has the same vulnerabilities associated >> with [RFC3519]. An attacker is able to hijack the mobile node's >> session with the home agent if it can modify the contents of the >> outer IPv4 header. The contents of the header are not authenticated >> and there is no way for the home agent to verify their validity. >> Hence, a man in the middle attack where a change in the contents of >> the IPv4 header can cause a legitimate mobile node's traffic to be >> diverted to an illegitimate receiver independently of the >> authenticity of the binding update message. >> >> In this specification, the binding update message MUST be protected >> using ESP transport mode. > > Just to be sure: IP / UDP / IPv6 / ESP / MH ? > >> When the mobile node is located in an >> IPv4-only network, the binding update message is encapsulated in UDP >> as described earlier. However, UDP SHOULD NOT be used to encapsulate >> the binding update message when the mobile node is located in an >> IPv6-enabled network. If protection of payload traffic is needed >> when the mobile node is located in an IPv4-only network, >> encapsulation is done using tunnel mode ESP over port 4500 as >> described in [RFC3948]. During the IKE negotiation with the home >> agent, if the mobile node and home agent support the use of port >> 4500, the mobile node MUST establish the security association over >> port 4500, regardless of the presence of a NAT. This is done to >> avoid the switching between ports 500 and 4500 and the potential >> traffic disruption resulting from this switch. > > Is this summary correct for a MIPv6 MN that uses IPsec for both > signaling and data (payload) on an IPv4 network: > > - signaling: IP / UDP / IPv6 / ESP / MH > - data: IP / UDP / ESP / IPv6 / L4 => Yes. >> If the Key Management Mobility Capability (K) bit was set in the >> binding update, and the home agent supports this feature, the home >> agent updates its IKE security associations to include the mobile >> node's care-of address as the peer address and 4500 as the port >> number. > > How? => It's an internal API in the HA. This is not new, the K flag is in RFC 3775. > >> The home agent may also need to change NAT traversal fields >> in the IKE_SA to enable the dynamic update of the IP address and port >> number based on the reception of authenticated IKE messages, or > > Following standard IKE procedure (i.e. 2.23 of RFC 4306) or is something > else expected? => Yes, same as standard IKE. > >> authenticated packets using tunnel mode ESP. > > How? => How what? > >> The dynamic updates are described in section 2.23 of RFC 4306. > > For IKE, yes. For other cases, it is not. => What other cases? We only support IKE. > >> As described above, when the >> mobile node is located in a private IPv4 network, the address and >> port number used for IPsec and IKE traffic is not yet known by the >> home agent at this point. >> >> The mobile node updates the IKE SA in one of two ways. If the K flag >> was set in the binding acknowledgement message, the mobile node >> SHOULD send an empty informational message, > > How does the MIPv6 modules manages to tell the IKE module to do that? => See above, this is an assumed API based in 3775. > >> which results in the IKE >> module in the home agent to dynamically update the SA information. >> The IKE implementation in the home agent is REQUIRED to support this >> feature. > > You mean on the MN, the HA or both? => It says the HA. > >> Alternatively, the IKE SA should be re-negotiated. Note >> that updating the IKE SA MUST take place after the mobile node has >> sent the binding update and received the acknowledgement from the >> home agent. >> >> It is important to note that the mobile node's IPv4 care-of address >> seen by the DSMIPv6 module in the home agent upon receiving the >> binding update may differ from the IPv4 care-of address seen by the >> IKE module and the care-of address used for forwarding IPsec tunnel >> mode traffic. Hence, it is probable that different modules in the >> home agent will have a different care-of address that should be used >> for encapsulating traffic to the mobile node. > > What does last sentence means? => It means that IKE will see a different address for the MN from the HA's module. This is because NAT allocates different IP addresses. >> Upon receiving the binding acknowledgement, the mobile node updates >> its local tunnel mode Security Association information to include the >> tunnel header IP source address, which is the mobile node's address >> and the tunnel header IP destination, which is the home agent's >> address. The mobile node may also need to enable or disable UDP >> encapsulation for outgoing ESP packets for the purpose of NAT >> traversal and the sending of keep alives. > > How? => I'm not really sure what you're asking about, please be specific. > >> The mobile node MAY use [RFC4555] to update its IKE SA with the home >> agent. Using MOBIKE requires negotiating this capability with the >> home agent when establishing the SA. In this case, the mobile node >> and the home agent MUST NOT update their IPsec SAs locally as this >> step is performed by MOBIKE. Furthermore, the use of MOBIKE allows >> the mobile node to update the SA independently of the binding update >> exchange. Hence, there is no need for the mobile node to wait for a >> binding acknowledgement before performing MOBIKE. The use of MOBIKE >> is OPTIONAL in this specification. > > How IKE module and MIPv6 do synchronize on which address to use? More > precisely, how is MIPv6 module expected to tell IKE implementation to > use the correct address for update in MOBIKE context. => We do assume internal APIs between MIPv6 and IKE. Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 8 09:48: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 BDD5428C100; Mon, 8 Dec 2008 09:48:15 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9819E28C0F7 for ; Mon, 8 Dec 2008 09:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.123 X-Spam-Level: X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, J_CHICKENPOX_84=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 w80P1ziVhKjv for ; Mon, 8 Dec 2008 09:48:13 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 308D828C100 for ; Mon, 8 Dec 2008 09:48:12 -0800 (PST) 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 mB8HpV9e025608; Mon, 8 Dec 2008 11:51:31 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Dec 2008 11:48:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 8 Dec 2008 12:48:05 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MEXT Digest, Vol 18, Issue 5 Thread-Index: AclXFH+qdFugPs3ySgi0Ud2h97ZWMQCSAySA References: From: "Desire Oulai" To: , "Ahmad Muhanna" X-OriginalArrivalTime: 08 Dec 2008 17:48:06.0354 (UTC) FILETIME=[202ED320:01C9595D] Cc: mext@ietf.org Subject: Re: [MEXT] MEXT Digest, Vol 18, Issue 5 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Behcet, I did not undersstand your proposal. Do you agree that the HA must be able to revoke a subset of the assigned MNPs using MNP options included in BRI/BRA? BR Desire > ------------------------------ > > Message: 6 > Date: Fri, 5 Dec 2008 08:18:47 -0800 (PST) > From: Behcet Sarikaya > Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports > NEMOusecase > To: Ahmad Muhanna > Cc: mext@ietf.org > Message-ID: <442560.87107.qm@web111416.mail.gq1.yahoo.com> > Content-Type: text/plain; charset="us-ascii" > > Hi Ahmad, > Currently your draft does not talk about Nemo. If you wish > to include MR, I think it is easy: You can say that MIP6, > DSMIP6 cases apply to MR acting as MN. > PMIP6 case also applies to MR acting as MR not as MAG. > BRI sending entity has to make sure that MNPs are removed > from the binding cache before sending the revocation. > > Profiting the occasion, I found a few typos in your draft : > > > typos: sends a BRA message to the LMA following the rules describes > -->described > 3.4.3. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings > > -> Revokes > > Regards, > > Behcet > > > > ________________________________ > From: Ahmad Muhanna > To: Behcet Sarikaya ; fan zhao > > Cc: mext@ietf.org > Sent: Friday, December 5, 2008 9:02:10 AM > Subject: RE: [MEXT] Binding Revocation for IPv6 Mobility > Supports NEMOusecase > > > Hi > Behcet, > > Just > to clarify one thing here. It seems that we overlooked this > use case by not > mentioning it in the draft. > Looking at the presentation that we made at IETF-70 and IETF-71 it > clearly list HA->MR as one of the usecases. > Since > that was the basis for this draft that was adopted as a wg > document, I believe > we need to include this in the draft. > > Please > find the Binding Revocation slides for IETF-70 & 71 at the below > links: > > http://www.ietf.org/proceedings/08mar/slides/mext-9.pdf > http://www.ietf.org/proceedings/07dec/slides/mext-4.pdf > Regards, > Ahmad > > > > ________________________________ > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > On Behalf Of Behcet Sarikaya > Sent: Wednesday, December 03, 2008 12:00 PM > To: fan zhao > Cc: mext@ietf.org > Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility > Supports NEMOusecase > > > > > > > > ________________________________ > From: fan zhao > To: Behcet Sarikaya > Cc: mext@ietf.org > Sent: Tuesday, December 2, 2008 5:47:35 PM > Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility > Supports NEMO usecase > > Hi Behcet, > > There is a difference between binding revocation for MNPs and > MNP release. > When the binding revocation for MNPs is performed, the MNP > information stored in the binding cache entry for the MR is > removed, which means that the packets for such MNP will not > be tunneled by the HA; however, such MNP is not explicitly > released by the binding revocation. This is needed because > the mobile network nodes connecting to the MR before > may handover to their home network (such as wimax) while > the MR still stays in its foreign link (since for example the MR > does not have the wimax interface); therefore, such MNP > should still be made valid for such mobile network nodes. > > To release such MNP, the same method to allocate the > MNP should be used. For example, if the MNP is allocated > by using DHCP, then DHCP needs to be used again to remove > such MNP. This is similar to the MIPv6 case where the MN > sends the BU with the lifetime=zero or the HA sends the BRI > to remove the binding, the home address on the other hand > needs to remove by deleting the IPsec SA if this is detach. > > It makes sense to me using the BR to remove the MNP from > the BCE since such MNP is registered by using BU and > BR is the opposite way to BU. > > [behcet ] So it is the MR that knows thesituation and MR > should initiate MNP release. Doing it with BR would be > server-initiated which is something to be considered for > prefix renumbering which has nothing to do with the release. > > Sincerely, > fan > > On Tue, Dec 2, 2008 at 2:50 PM, Behcet Sarikaya > wrote: > > Hi Fan, > > Prefix delegation/authorization function should take care > of this. In DHCP > > PD there is a way to release the prefixes. > > > > Regards, > > > > Behcet > > > > ________________________________ > > From: fan zhao > > To: Behcet Sarikaya > > Cc: Ahmad Muhanna ; mext@ietf.org > > Sent: Tuesday, December 2, 2008 3:41:56 PM > > Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility > Supports NEMO > > usecase > > > > Hi Behcet, > > > > The binding revocation is designed for DSMIPv6 and DSMIPv6 supports > > both mobile host > > and mobile router. I do not see any issue. > > > > Sincerely, > > fan > > > > On Tue, Dec 2, 2008 at 11:52 AM, Behcet Sarikaya > > wrote: > >> Hi Ahmad, > >> Can you please explain how MNP is related to your draft? > MNP is something > >> that MR needs and is specific to Nemo operation not to > MN-HA relationship > >> and the binding that comes with it. > >> So I don't see any binding to revocate with MNPs? > >> > >> Regards, > >> > >> Behcet > >> > >> ________________________________ > >> From: Ahmad Muhanna > >> To: Desire Oulai ; mext@ietf.org > >> Sent: Monday, December 1, 2008 9:22:35 PM > >> Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility > Supports NEMO > >> usecase > >> > >> Hi Desire, > >> > >> Added a relative subject. > >> > >> I guess the usecase is clear and it makes sense to me. > >> We can add some text similar to yours to capture this > functionality under > >> the HA and MN operations after the conclusion of the WGLC.. > >> > >> BTW: Is there anyone who thinks that we should not add > this usecase? > >> > >> Regards, > >> Ahmad > >> > >> > >> > >> ________________________________ > >> From: Desire Oulai [mailto:desire.oulai@ericsson.com] > >> Sent: Monday, December 01, 2008 2:46 PM > >> To: mext@ietf.org > >> Cc: Muhanna, Ahmad (RICH1:2H10) > >> Subject: > >> > >> Hi Ahmad, All, > >> > >> The Binding revocation draft does not mention revocation > related to NEMO. > >> If used as is, the BRI will revoke the binding between > the MR's HoA and > >> CoA. > >> I think it's woth adding another level of revocation: > revocation of Mobile > >> Network Prefixes. A HA may decide to stop forwarding data > to the CoA for > >> certain MNPs and BR could be used for that. Here is a > proposed text for a > >> new section: > >> > >> "In case of NEMO protocol, the HA follows the same > procedure as MIPv6 if > >> the > >> goal is to revoke the binding between the Mobile Router's > HoA and CoA. It > >> is > >> also possible to have finer granularity of revocation > targeting the Mobile > >> Network Prefixes assigned to the Mobile Router. In this > case, the HA sends > >> a > >> BRI message including one or more MNP options with the A > bit set and the > >> Revocation Trigger set to a proper value, e.g. > Administrative Reasons. > >> When > >> receiving this BRI, the MR deletes the MNP(s) from the > Prefix Information > >> field in the Binding Update List and responds with a BRA > message. The BRA > >> MUST include the MNP(s) contained in the BRI." > >> > >> Also, Mobile network Prefix should be addes as valid > option in section > >> "6.2. > >> Binding Revocation Acknowledgement Message". > >> > >> BR > >> Desire > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > >> > > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > 5cb/attachment-0001.htm> > > ------------------------------ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > End of MEXT Digest, Vol 18, Issue 5 > *********************************** > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 8 11:52:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8693D28C197; Mon, 8 Dec 2008 11:52:15 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9E528C197 for ; Mon, 8 Dec 2008 11:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSEufCk9UXGc for ; Mon, 8 Dec 2008 11:52:12 -0800 (PST) Received: from n2.bullet.mail.gq1.yahoo.com (n2.bullet.mail.gq1.yahoo.com [67.195.9.85]) by core3.amsl.com (Postfix) with SMTP id 6ECFD28C188 for ; Mon, 8 Dec 2008 11:52:12 -0800 (PST) Received: from [67.195.9.82] by n2.bullet.mail.gq1.yahoo.com with NNFMP; 08 Dec 2008 19:52:06 -0000 Received: from [67.195.9.104] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 08 Dec 2008 19:48:59 -0000 Received: from [127.0.0.1] by omp108.mail.gq1.yahoo.com with NNFMP; 08 Dec 2008 19:48:59 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 182524.2605.bm@omp108.mail.gq1.yahoo.com Received: (qmail 72456 invoked by uid 60001); 8 Dec 2008 19:48:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=B9gpnh4rGSFH5Cbw+LsxbKO4zvMvQD28U1F5kZGuOKhEodTo5XGH2opyVJUBjg9AJfznDEfiE9yrh2iSHFL38MJwEJ7YpoZmAE0MIrH9n2xJUZkMOlMjVg/JcI0md84q98m2Oo5ASb5PIUlLJ9bAObvYld+4N+w3+kUaHxqwEys=; X-YMail-OSG: GB40wecVM1l9jgmZrTq0EcdSLVPGFKdDmam5zNwqwwoDIa1TjD4qCVikgUU_0oCcFtMCe.eXiqv2OIN9evwkKb0IQd8evap7CcyExDk1dXbLGdfGo2ynkQzeZJjkoL2BQNmLq5iGsTCzEycqnuqdX4t5d3ouH4zsGEOEFR4GRkgPQys- Received: from [206.16.17.212] by web111401.mail.gq1.yahoo.com via HTTP; Mon, 08 Dec 2008 11:48:58 PST X-Mailer: YahooMailRC/1155.32 YahooMailWebService/0.7.260.1 References: Date: Mon, 8 Dec 2008 11:48:58 -0800 (PST) From: Behcet Sarikaya To: Desire Oulai , Ahmad Muhanna MIME-Version: 1.0 Message-ID: <40713.72398.qm@web111401.mail.gq1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] MEXT Digest, Vol 18, Issue 5 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="===============0869290775==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0869290775== Content-Type: multipart/alternative; boundary="0-1451098314-1228765738=:72398" --0-1451098314-1228765738=:72398 Content-Type: text/plain; charset=us-ascii Hi Desire, Ahmad is to add some text to his draft on Nemo support not for revoking MNPs but on how binding revocation can be used for Nemo. Let's see this new version and discuss. Regards, Behcet ________________________________ From: Desire Oulai To: behcetsarikaya@yahoo.com; Ahmad Muhanna Cc: mext@ietf.org Sent: Monday, December 8, 2008 11:48:05 AM Subject: Re: [MEXT] MEXT Digest, Vol 18, Issue 5 Hi Behcet, I did not undersstand your proposal. Do you agree that the HA must be able to revoke a subset of the assigned MNPs using MNP options included in BRI/BRA? BR Desire > ------------------------------ > > Message: 6 > Date: Fri, 5 Dec 2008 08:18:47 -0800 (PST) > From: Behcet Sarikaya > Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports > NEMOusecase > To: Ahmad Muhanna > Cc: mext@ietf.org > Message-ID: <442560.87107.qm@web111416.mail.gq1.yahoo.com> > Content-Type: text/plain; charset="us-ascii" > > Hi Ahmad, > Currently your draft does not talk about Nemo. If you wish > to include MR, I think it is easy: You can say that MIP6, > DSMIP6 cases apply to MR acting as MN. > PMIP6 case also applies to MR acting as MR not as MAG. > BRI sending entity has to make sure that MNPs are removed > from the binding cache before sending the revocation. > > Profiting the occasion, I found a few typos in your draft : > > > typos: sends a BRA message to the LMA following the rules describes > -->described > 3.4.3. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings > > -> Revokes > > Regards, > > Behcet > > > > ________________________________ > From: Ahmad Muhanna > To: Behcet Sarikaya ; fan zhao > > Cc: mext@ietf.org > Sent: Friday, December 5, 2008 9:02:10 AM > Subject: RE: [MEXT] Binding Revocation for IPv6 Mobility > Supports NEMOusecase > > > Hi > Behcet, > > Just > to clarify one thing here. It seems that we overlooked this > use case by not > mentioning it in the draft. > Looking at the presentation that we made at IETF-70 and IETF-71 it > clearly list HA->MR as one of the usecases. > Since > that was the basis for this draft that was adopted as a wg > document, I believe > we need to include this in the draft. > > Please > find the Binding Revocation slides for IETF-70 & 71 at the below > links: > > http://www.ietf.org/proceedings/08mar/slides/mext-9.pdf > http://www.ietf.org/proceedings/07dec/slides/mext-4.pdf > Regards, > Ahmad > > > > ________________________________ > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > On Behalf Of Behcet Sarikaya > Sent: Wednesday, December 03, 2008 12:00 PM > To: fan zhao > Cc: mext@ietf.org > Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility > Supports NEMOusecase > > > > > > > > ________________________________ > From: fan zhao > To: Behcet Sarikaya > Cc: mext@ietf.org > Sent: Tuesday, December 2, 2008 5:47:35 PM > Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility > Supports NEMO usecase > > Hi Behcet, > > There is a difference between binding revocation for MNPs and > MNP release. > When the binding revocation for MNPs is performed, the MNP > information stored in the binding cache entry for the MR is > removed, which means that the packets for such MNP will not > be tunneled by the HA; however, such MNP is not explicitly > released by the binding revocation. This is needed because > the mobile network nodes connecting to the MR before > may handover to their home network (such as wimax) while > the MR still stays in its foreign link (since for example the MR > does not have the wimax interface); therefore, such MNP > should still be made valid for such mobile network nodes. > > To release such MNP, the same method to allocate the > MNP should be used. For example, if the MNP is allocated > by using DHCP, then DHCP needs to be used again to remove > such MNP. This is similar to the MIPv6 case where the MN > sends the BU with the lifetime=zero or the HA sends the BRI > to remove the binding, the home address on the other hand > needs to remove by deleting the IPsec SA if this is detach. > > It makes sense to me using the BR to remove the MNP from > the BCE since such MNP is registered by using BU and > BR is the opposite way to BU. > > [behcet ] So it is the MR that knows thesituation and MR > should initiate MNP release. Doing it with BR would be > server-initiated which is something to be considered for > prefix renumbering which has nothing to do with the release. > > Sincerely, > fan > > On Tue, Dec 2, 2008 at 2:50 PM, Behcet Sarikaya > wrote: > > Hi Fan, > > Prefix delegation/authorization function should take care > of this. In DHCP > > PD there is a way to release the prefixes. > > > > Regards, > > > > Behcet > > > > ________________________________ > > From: fan zhao > > To: Behcet Sarikaya > > Cc: Ahmad Muhanna ; mext@ietf.org > > Sent: Tuesday, December 2, 2008 3:41:56 PM > > Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility > Supports NEMO > > usecase > > > > Hi Behcet, > > > > The binding revocation is designed for DSMIPv6 and DSMIPv6 supports > > both mobile host > > and mobile router. I do not see any issue. > > > > Sincerely, > > fan > > > > On Tue, Dec 2, 2008 at 11:52 AM, Behcet Sarikaya > > wrote: > >> Hi Ahmad, > >> Can you please explain how MNP is related to your draft? > MNP is something > >> that MR needs and is specific to Nemo operation not to > MN-HA relationship > >> and the binding that comes with it. > >> So I don't see any binding to revocate with MNPs? > >> > >> Regards, > >> > >> Behcet > >> > >> ________________________________ > >> From: Ahmad Muhanna > >> To: Desire Oulai ; mext@ietf.org > >> Sent: Monday, December 1, 2008 9:22:35 PM > >> Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility > Supports NEMO > >> usecase > >> > >> Hi Desire, > >> > >> Added a relative subject. > >> > >> I guess the usecase is clear and it makes sense to me. > >> We can add some text similar to yours to capture this > functionality under > >> the HA and MN operations after the conclusion of the WGLC.. > >> > >> BTW: Is there anyone who thinks that we should not add > this usecase? > >> > >> Regards, > >> Ahmad > >> > >> > >> > >> ________________________________ > >> From: Desire Oulai [mailto:desire.oulai@ericsson.com] > >> Sent: Monday, December 01, 2008 2:46 PM > >> To: mext@ietf.org > >> Cc: Muhanna, Ahmad (RICH1:2H10) > >> Subject: > >> > >> Hi Ahmad, All, > >> > >> The Binding revocation draft does not mention revocation > related to NEMO. > >> If used as is, the BRI will revoke the binding between > the MR's HoA and > >> CoA. > >> I think it's woth adding another level of revocation: > revocation of Mobile > >> Network Prefixes. A HA may decide to stop forwarding data > to the CoA for > >> certain MNPs and BR could be used for that. Here is a > proposed text for a > >> new section: > >> > >> "In case of NEMO protocol, the HA follows the same > procedure as MIPv6 if > >> the > >> goal is to revoke the binding between the Mobile Router's > HoA and CoA. It > >> is > >> also possible to have finer granularity of revocation > targeting the Mobile > >> Network Prefixes assigned to the Mobile Router. In this > case, the HA sends > >> a > >> BRI message including one or more MNP options with the A > bit set and the > >> Revocation Trigger set to a proper value, e.g. > Administrative Reasons. > >> When > >> receiving this BRI, the MR deletes the MNP(s) from the > Prefix Information > >> field in the Binding Update List and responds with a BRA > message. The BRA > >> MUST include the MNP(s) contained in the BRI." > >> > >> Also, Mobile network Prefix should be addes as valid > option in section > >> "6.2. > >> Binding Revocation Acknowledgement Message". > >> > >> BR > >> Desire > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > >> > > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > 5cb/attachment-0001.htm> > > ------------------------------ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > End of MEXT Digest, Vol 18, Issue 5 > *********************************** > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-1451098314-1228765738=:72398 Content-Type: text/html; charset=us-ascii
Hi Desire,

Ahmad is to add some text to his draft on Nemo support not for revoking MNPs but on how binding revocation can be used for Nemo. Let's see this new version and discuss.

Regards,

Behcet
From: Desire Oulai <desire.oulai@ericsson.com>
To: behcetsarikaya@yahoo.com; Ahmad Muhanna <amuhanna@nortel.com>
Cc: mext@ietf.org
Sent: Monday, December 8, 2008 11:48:05 AM
Subject: Re: [MEXT] MEXT Digest, Vol 18, Issue 5

Hi Behcet,

  I did not undersstand your proposal. Do you agree that the HA must be
able to revoke a subset of the assigned MNPs using MNP options included
in BRI/BRA?

BR

Desire

> ------------------------------
>
> Message: 6
> Date: Fri, 5 Dec 2008 08:18:47 -0800 (PST)
> From: Behcet Sarikaya <behcetsarikaya@yahoo.com>
> Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports
>     NEMOusecase
> To: Ahmad Muhanna <amuhanna@nortel.com>
> Cc: mext@ietf.org
> Message-ID: <442560.87107.qm@web111416.mail.gq1.yahoo.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Ahmad,
>  Currently your draft does not talk about Nemo. If you wish
> to include MR, I think it is easy: You can say that MIP6,
> DSMIP6 cases apply to MR acting as MN.
> PMIP6 case also applies to MR acting as MR not as MAG.
> BRI sending entity has to make sure that MNPs are removed
> from the binding cache before sending the revocation.
>
>  Profiting the occasion, I found a few typos in your draft :
>
>
> typos: sends a BRA message to the LMA following the rules describes
> -->described
> 3.4.3.  Mobile Access Gateway Revoke Bulk PMIPv6 Bindings
>
> -> Revokes
>
> Regards,
>
> Behcet
>
>
>
> ________________________________
> From: Ahmad Muhanna <amuhanna@nortel.com>
> To: Behcet Sarikaya <sarikaya@ieee.org>; fan zhao
> <fanzhao828@gmail.com>
> Cc: mext@ietf.org
> Sent: Friday, December 5, 2008 9:02:10 AM
> Subject: RE: [MEXT] Binding Revocation for IPv6 Mobility
> Supports NEMOusecase
>
> 
> Hi
> Behcet,
> 
> Just
> to clarify one thing here. It seems that we overlooked this
> use case by not
> mentioning it in the draft.
> Looking at the presentation that we made at IETF-70 and IETF-71 it
> clearly list HA->MR as one of the usecases.
> Since
> that was the basis for this draft that was adopted as a wg
> document, I believe
> we need to include this in the draft.
> 
> Please
> find the Binding Revocation slides for IETF-70 & 71 at the below
> links:
> 
> http://www.ietf.org/proceedings/08mar/slides/mext-9.pdf
> http://www.ietf.org/proceedings/07dec/slides/mext-4.pdf
> Regards,
> Ahmad
> 
>
>
> ________________________________
>  From: mext-bounces@ietf.org  [mailto:mext-bounces@ietf.org]
> On Behalf Of Behcet  Sarikaya
> Sent: Wednesday, December 03, 2008 12:00 PM
> To: fan zhao
> Cc: mext@ietf.org
> Subject: Re: [MEXT] Binding  Revocation for IPv6 Mobility
> Supports NEMOusecase
>
>
>
>
>
>
>
> ________________________________
>  From: fan zhao  <fanzhao828@gmail.com>
> To: Behcet Sarikaya  <sarikaya@ieee.org>
> Cc: mext@ietf.org
> Sent: Tuesday,  December 2, 2008 5:47:35 PM
> Subject: Re: [MEXT] Binding Revocation  for IPv6 Mobility
> Supports NEMO usecase
>
> Hi Behcet,
>
> There  is a difference between binding revocation for MNPs and
> MNP  release.
> When the binding revocation for MNPs is performed, the  MNP
> information stored in the binding cache entry for the MR is
> removed,  which means that the packets for such MNP will not
> be tunneled by the HA;  however, such MNP is not explicitly
> released by the binding revocation.  This is needed because
> the mobile network nodes connecting to the MR  before
> may handover to their home network (such as wimax) while
> the MR  still stays in its foreign link (since for example the MR
> does not have the  wimax interface); therefore, such MNP
> should still be made valid for such  mobile network nodes.
>
> To release such MNP, the same method to allocate  the
> MNP should be used. For example, if the MNP is allocated
> by using  DHCP, then DHCP needs to be used again to remove
> such MNP. This is similar  to the MIPv6 case where the MN
> sends the BU with the lifetime=zero or the  HA sends the BRI
> to remove the binding, the home address on the other  hand
> needs to remove by deleting the IPsec SA if this is detach.
>
> It  makes sense to me using the BR to remove the MNP from
> the BCE since such  MNP is registered by using BU and
> BR is the opposite way to  BU.
>
> [behcet ] So it is the MR that knows  thesituation and MR
> should  initiate MNP release. Doing it with BR would be
> server-initiated which is  something to be considered for
> prefix renumbering which has nothing to do with  the release.
>
> Sincerely,
> fan
>
> On Tue, Dec 2, 2008 at  2:50 PM, Behcet Sarikaya
> <behcetsarikaya@yahoo.com>  wrote:
> > Hi Fan,
> >  Prefix delegation/authorization function  should take care
> of this. In DHCP
> > PD there is a way to release the  prefixes.
> >
> > Regards,
> >
> > Behcet
> >
> >  ________________________________
> > From: fan zhao <fanzhao828@gmail.com>
> > To:  Behcet Sarikaya <sarikaya@ieee.org>
> > Cc: Ahmad  Muhanna <amuhanna@nortel.com>; mext@ietf.org
> > Sent: Tuesday,  December 2, 2008 3:41:56 PM
> > Subject: Re: [MEXT] Binding Revocation for  IPv6 Mobility
> Supports NEMO
> > usecase
> >
> > Hi  Behcet,
> >
> > The binding revocation is designed for DSMIPv6 and  DSMIPv6 supports
> > both mobile host
> > and mobile router. I do not  see any issue.
> >
> > Sincerely,
> > fan
> >
> > On Tue,  Dec 2, 2008 at 11:52 AM, Behcet Sarikaya
> > <behcetsarikaya@yahoo.com>  wrote:
> >> Hi Ahmad,
> >>  Can you please explain how MNP  is related to your draft?
> MNP is something
> >> that MR needs and is  specific to Nemo operation not to
> MN-HA relationship
> >> and the  binding that comes with it.
> >>  So I don't see any binding to  revocate with MNPs?
> >>
> >> Regards,
> >>
> >>  Behcet
> >>
> >> ________________________________
> >>  From: Ahmad Muhanna <amuhanna@nortel.com>
> >>  To: Desire Oulai <desire.oulai@ericsson.com>; mext@ietf.org
> >> Sent: Monday,  December 1, 2008 9:22:35 PM
> >> Subject: Re: [MEXT] Binding Revocation  for IPv6 Mobility
> Supports NEMO
> >> usecase
> >>
> >> Hi  Desire,
> >>
> >> Added a relative  subject.
> >>
> >> I guess the usecase is clear and it makes  sense to me.
> >> We can add some text similar to yours to capture this 
> functionality under
> >> the HA and MN operations after the conclusion  of the WGLC..
> >>
> >> BTW: Is there anyone who thinks that we  should not add
> this usecase?
> >>
> >> Regards,
> >>  Ahmad
> >>
> >>
> >>
> >>  ________________________________
> >> From: Desire Oulai [mailto:desire.oulai@ericsson.com]
> >>  Sent: Monday, December 01, 2008 2:46 PM
> >> To: mext@ietf.org
> >> Cc: Muhanna,  Ahmad (RICH1:2H10)
> >> Subject:
> >>
> >> Hi Ahmad,  All,
> >>
> >>  The Binding revocation draft does not  mention revocation
> related to NEMO.
> >> If used as is, the BRI will  revoke the binding between
> the MR's HoA and
> >> CoA.
> >> I  think it's woth adding another level of revocation:
> revocation of  Mobile
> >> Network Prefixes. A HA may decide to stop forwarding data 
> to the CoA for
> >> certain MNPs and BR could be used for that. Here is  a
> proposed text for a
> >> new section:
> >>
> >> "In  case of NEMO protocol, the HA follows the same
> procedure as MIPv6  if
> >> the
> >> goal is to revoke the binding between the  Mobile Router's
> HoA and CoA. It
> >> is
> >> also possible to  have finer granularity of revocation
> targeting the Mobile
> >> Network  Prefixes assigned to the Mobile Router. In this
> case, the HA sends
> >>  a
> >> BRI message including one or more MNP options with the A
> bit set  and the
> >> Revocation Trigger set to a proper value, e.g. 
> Administrative Reasons.
> >> When
> >> receiving this BRI, the  MR deletes the MNP(s) from the
> Prefix Information
> >> field in the  Binding Update List and responds with a BRA
> message. The BRA
> >> MUST  include the MNP(s) contained in the BRI."
> >>
> >> Also, Mobile  network Prefix should be addes as valid
> option in section
> >>  "6.2.
> >> Binding Revocation Acknowledgement  Message".
> >>
> >> BR
> >>  Desire
> >>
> >>  _______________________________________________
> >> MEXT mailing  list
> >> MEXT@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mext
> >>
> >>
> >
> >
>
>
>     
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://www.ietf.org/pipermail/mext/attachments/20081205/2037f
> 5cb/attachment-0001.htm>
>
> ------------------------------
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>
>
> End of MEXT Digest, Vol 18, Issue 5
> ***********************************
>
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext

--0-1451098314-1228765738=:72398-- --===============0869290775== 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 --===============0869290775==-- From norina-zarin@ambg.com.my Tue Dec 9 17:15:46 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761AA3A67A8 for ; Tue, 9 Dec 2008 17:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.51 X-Spam-Level: X-Spam-Status: No, score=-4.51 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elTwoEgYaWBk for ; Tue, 9 Dec 2008 17:15:45 -0800 (PST) Received: from cer51-4-88-164-110-6.fbx.proxad.net (cer51-4-88-164-110-6.fbx.proxad.net [88.164.110.6]) by core3.amsl.com (Postfix) with SMTP id E1FC13A6B54 for ; Tue, 9 Dec 2008 17:15:44 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081210011544.E1FC13A6B54@core3.amsl.com> Date: Tue, 9 Dec 2008 17:15:44 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mext-bounces@ietf.org Tue Dec 9 19: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 63B253A687E; Tue, 9 Dec 2008 19:41:04 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13BC43A687E for ; Tue, 9 Dec 2008 19:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.213 X-Spam-Level: X-Spam-Status: No, score=-3.213 tagged_above=-999 required=5 tests=[AWL=0.386, 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 DcsAuJ5S7Oj4 for ; Tue, 9 Dec 2008 19:41:01 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 889BD3A6806 for ; Tue, 9 Dec 2008 19:41:01 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LAFwP-0006fi-V5; Wed, 10 Dec 2008 04:40:50 +0100 From: arno@natisbad.org (Arnaud Ebalard) To: Hesham Soliman 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:081208:mext@ietf.org::y7vp7yyEqVg0AyvY:00005yL0 X-Hashcash: 1:20:081208:hesham@elevatemobile.com::hGTwpOGiVN2NsH7+:00000000000000000000000000000000000005tg0 Date: Tue, 09 Dec 2008 19:38:46 -0800 Message-ID: <871vwg3dix.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] Comments on draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, Sorry for the latency. Some answers to your questions and additional comments below. I hesitated to add the chairs in CC of my reply to clarify the situation (on the API assumption, on the IKE requirement, ...). Don't hesitate if you think my comments make sense. Hesham Soliman writes: >>> 3.2. Mobile Prefix Solicitation and Advertisement >>> >>> According to [RFC3775], the mobile node can send a Mobile Prefix >>> Solicitation and receive a Mobile Prefix Advertisement containing all >>> prefixes advertised on the home link. >>> >>> A dual stack mobile node MAY send a Mobile Prefix Solicitation >>> message encapsulated in IPv4 (i.e., IPv6 in IPv4) in the case where >>> the mobile node has no access to IPv6 within the local network. >>> Securing these messages requires the mobile node to have a security >>> association with the home agent, using IPsec (AH or ESP) and based on >>> the mobile node's IPv4 care-of address as described in [RFC3775]. >>> Since the mobile node needs to encapsulate all IPv6 traffic sent to >>> the home agent into IPv4 while located in an IPv4-only visited >>> network, this SA would match all packets if the selectors were based >>> on the information in the outer header. That is, the SA selectors >>> being the protocol number (protocol is always IP in IP), as well as, >>> source and destination addresses are all common to all packets. >> >> Possibly me but last sentence seems incorrect. If not, what is its >> meaning? > > => It means that the SA selectors would be the same for all packets. ok. Maybe it was me. >>> When a mobile node acquires both IPv4 and IPv6 care-of addresses at >>> the foreign network, it SHOULD prioritize the IPv6 care-of address >>> for it MIPv6 its binding. >> >> Last sentence seems incorrect. > > => why? It looks good to me. s/for it MIPv6 its binding/for its MIPv6 binding/ no? >>> 5.2. NAT Detection >>> >>> This section deals with NAT detection for the purpose of >>> encapsulating packets between the mobile node and the home agent. >>> Mobile IPv6 uses IKEv2 to establish te IPsec security association >>> between the mobile node and the home agent. >> >> IKE is not mandatory, it is only optional. Or did I missed a reference >> document? > > => Yes it's mandatory. I think there is a reference, if not, it will be > added. In MIPv6, support for static keying is mandatory. Dynamic keying is only optional. Otherwise, I definitely need a pointer. Note that I would also prefer having IKE mandatory w/ MIPv6 ... >> What about 'may use IKE ...' > > => No I don't think that's right. Well, if you make IKE a requirement in DSMIPv6, you are indeed right. >>> If no NAT device was detected in the path between the mobile node and >>> the home agent then IPv6 packets are tunneled in an IPv4 header, >>> unless the home agent forces UDP encapsulation using the F flag. The >>> content of the inner and outer headers are identical to the UDP >>> encapsulation case. >> >> What if filtering somewhere prevents IP over IP but is fine with UDP >> encapsulated traffic. If the HA decides to go for IP over IP (i.e. does >> not force the F flag), this will not work. > > => Please see the latest draft. There is a new section on this. Ultimately, > if the MN wants to force the F flag and the HA doesn't then the HA wins. > This is the nature of the protocol, the HA decides. ok. Will try and take a look. >>> If the Key Management Mobility Capability (K) bit was set in the >>> binding update, and the home agent supports this feature, the home >>> agent updates its IKE security associations to include the mobile >>> node's care-of address as the peer address and 4500 as the port >>> number. >> >> How? > > => It's an internal API in the HA. This is not new, the K flag is in RFC > 3775. "internal API" meaning "implementation dependent feature", i.e. not specified in MIPv6 documents. >>> The home agent may also need to change NAT traversal fields >>> in the IKE_SA to enable the dynamic update of the IP address and port >>> number based on the reception of authenticated IKE messages, or >> >> Following standard IKE procedure (i.e. 2.23 of RFC 4306) or is something >> else expected? > > => Yes, same as standard IKE. > >> >>> authenticated packets using tunnel mode ESP. >> >> How? > > => How what? I mean: How is the IKE daemon expected to find out which addresses and ports to use? Can you take as example a MN w/ multiple interfaces? How does it know which ones have been selected by the HA? >>> As described above, when the >>> mobile node is located in a private IPv4 network, the address and >>> port number used for IPsec and IKE traffic is not yet known by the >>> home agent at this point. >>> >>> The mobile node updates the IKE SA in one of two ways. If the K flag >>> was set in the binding acknowledgement message, the mobile node >>> SHOULD send an empty informational message, >> >> How does the MIPv6 modules manages to tell the IKE module to do that? > > => See above, this is an assumed API based in 3775. As stated before, it is left as an implementation dependent issue. In the end, the result of this hypothesis/lack leads to: 1) inability to have different IKE and MIPv6 implementations work together out of the box on a given system. 2) assumption that IKE and MIPv6 modules are implemenented together, i.e. are part of the same module. AFAICT, this is a trend in recent MIPv6 documents that deal with IPsec/IKE. Don't hesitate to correct me on that. >>> which results in the IKE >>> module in the home agent to dynamically update the SA information. >>> The IKE implementation in the home agent is REQUIRED to support this >>> feature. >> >> You mean on the MN, the HA or both? > > => It says the HA. That's what I thought. What's the point in requiring *only* the HA to support that? What is the reason not to require that for the MN too? >>> Alternatively, the IKE SA should be re-negotiated. Note >>> that updating the IKE SA MUST take place after the mobile node has >>> sent the binding update and received the acknowledgement from the >>> home agent. >>> >>> It is important to note that the mobile node's IPv4 care-of address >>> seen by the DSMIPv6 module in the home agent upon receiving the >>> binding update may differ from the IPv4 care-of address seen by the >>> IKE module and the care-of address used for forwarding IPsec tunnel >>> mode traffic. Hence, it is probable that different modules in the >>> home agent will have a different care-of address that should be used >>> for encapsulating traffic to the mobile node. >> >> What does last sentence means? > > => It means that IKE will see a different address for the MN from the HA's > module. This is because NAT allocates different IP addresses. Sorry, I just fail to see how this can work in practice. >>> Upon receiving the binding acknowledgement, the mobile node updates >>> its local tunnel mode Security Association information to include the >>> tunnel header IP source address, which is the mobile node's address >>> and the tunnel header IP destination, which is the home agent's >>> address. The mobile node may also need to enable or disable UDP >>> encapsulation for outgoing ESP packets for the purpose of NAT >>> traversal and the sending of keep alives. >> >> How? > > => I'm not really sure what you're asking about, please be specific. My point is that the whole document is written as if the Mobile IPv6 module and the IKE module were only one single module or as if an extended API existed between the two modules. It is not because 3775 has left some undefined elements that we can base the specs on those (and extend them). What do you think? >>> The mobile node MAY use [RFC4555] to update its IKE SA with the home >>> agent. Using MOBIKE requires negotiating this capability with the >>> home agent when establishing the SA. In this case, the mobile node >>> and the home agent MUST NOT update their IPsec SAs locally as this >>> step is performed by MOBIKE. Furthermore, the use of MOBIKE allows >>> the mobile node to update the SA independently of the binding update >>> exchange. Hence, there is no need for the mobile node to wait for a >>> binding acknowledgement before performing MOBIKE. The use of MOBIKE >>> is OPTIONAL in this specification. >> >> How IKE module and MIPv6 do synchronize on which address to use? More >> precisely, how is MIPv6 module expected to tell IKE implementation to >> use the correct address for update in MOBIKE context. > > => We do assume internal APIs between MIPv6 and IKE. In that case, that should probably be stated *explicitly*. Listing the functions/purposes of this APIs would IMHO clarify the situation (but would still not allow interoperability between various IKE and MIPv6 implementations). In the end, I think the list will have quite some items, and possibly some that are not so simple to handle in the real life. Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 9 20:13: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 DF9723A6808; Tue, 9 Dec 2008 20:13:47 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFEEF3A6808 for ; Tue, 9 Dec 2008 20:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 mqex2tA4LJwA for ; Tue, 9 Dec 2008 20:13:45 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 57CB43A67C0 for ; Tue, 9 Dec 2008 20:13:44 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LAGS4-0004I5-LN; Wed, 10 Dec 2008 15:13:33 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Wed, 10 Dec 2008 15:13:25 +1100 From: Hesham Soliman To: Arnaud Ebalard Message-ID: Thread-Topic: Comments on draft-ietf-mext-nemo-v4traversal-06.txt Thread-Index: AclafaVzSrJG4dLizUa0yCF6Sj6wUg== In-Reply-To: <871vwg3dix.fsf@natisbad.org> Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > Sorry for the latency. Some answers to your questions and additional > comments below. I hesitated to add the chairs in CC of my reply to > clarify the situation (on the API assumption, on the IKE requirement, > ...). Don't hesitate if you think my comments make sense. => It's ok the chairs are on the list and they are all emails. >>>> When a mobile node acquires both IPv4 and IPv6 care-of addresses at >>>> the foreign network, it SHOULD prioritize the IPv6 care-of address >>>> for it MIPv6 its binding. >>> >>> Last sentence seems incorrect. >> >> => why? It looks good to me. > > s/for it MIPv6 its binding/for its MIPv6 binding/ no? => Sure, I was looking for something wrong with the logic and missed the typo. > > >>>> 5.2. NAT Detection >>>> >>>> This section deals with NAT detection for the purpose of >>>> encapsulating packets between the mobile node and the home agent. >>>> Mobile IPv6 uses IKEv2 to establish te IPsec security association >>>> between the mobile node and the home agent. >>> >>> IKE is not mandatory, it is only optional. Or did I missed a reference >>> document? >> >> => Yes it's mandatory. I think there is a reference, if not, it will be >> added. > > In MIPv6, support for static keying is mandatory. Dynamic keying is only > optional. Otherwise, I definitely need a pointer. Note that I would also > prefer having IKE mandatory w/ MIPv6 ... > > >>> What about 'may use IKE ...' >> >> => No I don't think that's right. > > Well, if you make IKE a requirement in DSMIPv6, you are indeed right. => Ok, I think it needs to be. >>> How? >> >> => It's an internal API in the HA. This is not new, the K flag is in RFC >> 3775. > > "internal API" meaning "implementation dependent feature", i.e. not > specified in MIPv6 documents. => Yes of course. > > >>>> The home agent may also need to change NAT traversal fields >>>> in the IKE_SA to enable the dynamic update of the IP address and port >>>> number based on the reception of authenticated IKE messages, or >>> >>> Following standard IKE procedure (i.e. 2.23 of RFC 4306) or is something >>> else expected? >> >> => Yes, same as standard IKE. >> >>> >>>> authenticated packets using tunnel mode ESP. >>> >>> How? >> >> => How what? > > I mean: How is the IKE daemon expected to find out which addresses and > ports to use? Can you take as example a MN w/ multiple interfaces? How > does it know which ones have been selected by the HA? => Are you still talking about the IKE daemon in the HA? It's responding to IKE messages from the MN. I don't understand the question. If you're talking about IKE in the MN, then it's more confusing to me because it *initiates* the communication. >>> How does the MIPv6 modules manages to tell the IKE module to do that? >> >> => See above, this is an assumed API based in 3775. > > As stated before, it is left as an implementation dependent issue. In > the end, the result of this hypothesis/lack leads to: > > 1) inability to have different IKE and MIPv6 implementations work > together out of the box on a given system. > 2) assumption that IKE and MIPv6 modules are implemenented together, > i.e. are part of the same module. AFAICT, this is a trend in recent > MIPv6 documents that deal with IPsec/IKE. > > Don't hesitate to correct me on that. => There is nothing to correct, but there is not much I can do about that in DSMIP. We are using assumptions in MIPv6, so yes we know the above issues and there are pseudo-standard APIs on some platforms for this. > > >>>> which results in the IKE >>>> module in the home agent to dynamically update the SA information. >>>> The IKE implementation in the home agent is REQUIRED to support this >>>> feature. >>> >>> You mean on the MN, the HA or both? >> >> => It says the HA. > > That's what I thought. What's the point in requiring *only* the HA to > support that? What is the reason not to require that for the MN too? => I believe you were quoting text that refers to updates due to the MN's address changes. It is required for the HA as the default mechanism. If the MN supports it then it's fine, if not the MN will need to re-negotiate the SA. So there is no need to mandate it for the MN. >>> What does last sentence means? >> >> => It means that IKE will see a different address for the MN from the HA's >> module. This is because NAT allocates different IP addresses. > > Sorry, I just fail to see how this can work in practice. => Ok, I'm guessing (because you didn't say) that this is related to the API concern you have. My point on that is that it's a bit too late to worry about it since it's already out there in implementations. It may need to be extended to support this spec but we're not inventing a new concept. >>> How? >> >> => I'm not really sure what you're asking about, please be specific. > > My point is that the whole document is written as if the Mobile IPv6 > module and the IKE module were only one single module or as if an > extended API existed between the two modules. It is not because 3775 has > left some undefined elements that we can base the specs on those (and > extend them). What do you think? => I think that this API was already assumed 5 years ago during the security rehash of MIPv6. This is not a new assumption in this spec. >> >> => We do assume internal APIs between MIPv6 and IKE. > > In that case, that should probably be stated *explicitly*. Listing the > functions/purposes of this APIs would IMHO clarify the situation (but > would still not allow interoperability between various IKE and MIPv6 > implementations). In the end, I think the list will have quite some > items, and possibly some that are not so simple to handle in the real > life. => Please see above. It's not a new concept. Hesham > > Cheers, > > a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 9 21:19: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 3B3823A680C; Tue, 9 Dec 2008 21:19:29 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE743A680C for ; Tue, 9 Dec 2008 21:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.261 X-Spam-Level: X-Spam-Status: No, score=-3.261 tagged_above=-999 required=5 tests=[AWL=0.338, 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 4lUG-y5-N7ZT for ; Tue, 9 Dec 2008 21:19:27 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 74CEC3A67F4 for ; Tue, 9 Dec 2008 21:19:27 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LAHTh-0006hi-B7; Wed, 10 Dec 2008 06:19:17 +0100 From: arno@natisbad.org (Arnaud Ebalard) To: Hesham Soliman 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:081210:mext@ietf.org::IiS9TgOQj7X+9PLb:00001w0S X-Hashcash: 1:20:081210:hesham@elevatemobile.com::WxqnLDVcztSZPEGS:00000000000000000000000000000000000001y5s Date: Tue, 09 Dec 2008 21:17:13 -0800 In-Reply-To: (Hesham Soliman's message of "Wed, 10 Dec 2008 15:13:25 +1100") Message-ID: <87wse81uee.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] Comments on draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Hesham Soliman writes: >> Well, if you make IKE a requirement in DSMIPv6, you are indeed right. > > => Ok, I think it needs to be. ok. >>>> How? >>> >>> => It's an internal API in the HA. This is not new, the K flag is in RFC >>> 3775. >> >> "internal API" meaning "implementation dependent feature", i.e. not >> specified in MIPv6 documents. > > => Yes of course. ok, but that's just not clearly stated in the document. >>>>> The home agent may also need to change NAT traversal fields >>>>> in the IKE_SA to enable the dynamic update of the IP address and port >>>>> number based on the reception of authenticated IKE messages, or >>>> >>>> Following standard IKE procedure (i.e. 2.23 of RFC 4306) or is something >>>> else expected? >>> >>> => Yes, same as standard IKE. >>> >>>> >>>>> authenticated packets using tunnel mode ESP. >>>> >>>> How? >>> >>> => How what? >> >> I mean: How is the IKE daemon expected to find out which addresses and >> ports to use? Can you take as example a MN w/ multiple interfaces? How >> does it know which ones have been selected by the HA? > > => Are you still talking about the IKE daemon in the HA? It's responding to > IKE messages from the MN. I don't understand the question. Sorry for the confusion. I wrote HA while thinking MIPv6 module: the correct last sentence is: How does it know which one has been selected by the MIPv6 module? > If you're talking about IKE in the MN, then it's more confusing to me > because it *initiates* the communication. IKE needs to be modified to guess the right address, that's all I say. In the same fashion as *expected* in 3775/3776 for initial transport mode negotiation. I think you just suppose "the API" also provides that. >>>> How does the MIPv6 modules manages to tell the IKE module to do that? >>> >>> => See above, this is an assumed API based in 3775. >> >> As stated before, it is left as an implementation dependent issue. In >> the end, the result of this hypothesis/lack leads to: >> >> 1) inability to have different IKE and MIPv6 implementations work >> together out of the box on a given system. >> 2) assumption that IKE and MIPv6 modules are implemenented together, >> i.e. are part of the same module. AFAICT, this is a trend in recent >> MIPv6 documents that deal with IPsec/IKE. >> >> Don't hesitate to correct me on that. > > => There is nothing to correct, but there is not much I can do about that in > DSMIP. We are using assumptions in MIPv6, so yes we know the above issues > and there are pseudo-standard APIs on some platforms for this. Well, I don't expect DSMIP document to provide the API but stating explicitly it is not defined (or that some drafts are available at various places) would help, IMHO. You will agree that the document adds additonal requirements for that API, w/o making them explicit. >>>>> which results in the IKE >>>>> module in the home agent to dynamically update the SA information. >>>>> The IKE implementation in the home agent is REQUIRED to support this >>>>> feature. >>>> >>>> You mean on the MN, the HA or both? >>> >>> => It says the HA. >> >> That's what I thought. What's the point in requiring *only* the HA to >> support that? What is the reason not to require that for the MN too? > > => I believe you were quoting text that refers to updates due to the MN's > address changes. It is required for the HA as the default mechanism. If the > MN supports it then it's fine, if not the MN will need to re-negotiate the > SA. So there is no need to mandate it for the MN. Let me rephrase it: Why is it a MUST on the HA (i.e. *arguments*) and some kind of 'can' for the MN? How were those levels of support decided? Based on which *technical* arguments? > => Ok, I'm guessing (because you didn't say) that this is related to the API > concern you have. My point on that is that it's a bit too late to worry > about it since it's already out there in implementations. What can I say: I worked on the API (MIGRATE), made a followup draft correcting problems found during the implementation, implemented support for racoon, UMIP, additions for Linux Kernel and helped strongSwan people during their implementation of my draft. > It may need to be extended to support this spec but we're not > inventing a new concept. ;-) >> My point is that the whole document is written as if the Mobile IPv6 >> module and the IKE module were only one single module or as if an >> extended API existed between the two modules. It is not because 3775 has >> left some undefined elements that we can base the specs on those (and >> extend them). What do you think? > > => I think that this API was already assumed 5 years ago during the security > rehash of MIPv6. This is not a new assumption in this spec. >From the discussion I had w/ Julien some time ago on the need for that kind of API, I am not that sure. And I don't think we should issue specs with floating assumptions. We cannot expect future implementors were there 5 or 6 years ago reading the list, can we? Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 9 21:57: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 B76643A6846; Tue, 9 Dec 2008 21:57:24 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EADF3A6846 for ; Tue, 9 Dec 2008 21:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 tDjwIMD8Ew3e for ; Tue, 9 Dec 2008 21:57:22 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 1C3673A6358 for ; Tue, 9 Dec 2008 21:57:21 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LAI4O-0007vz-MQ; Wed, 10 Dec 2008 16:57:13 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Wed, 10 Dec 2008 16:57:07 +1100 From: Hesham Soliman To: Arnaud Ebalard Message-ID: Thread-Topic: Comments on draft-ietf-mext-nemo-v4traversal-06.txt Thread-Index: AclajCINUeU21w2f00KOajnyyPrhww== In-Reply-To: <87wse81uee.fsf@natisbad.org> Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org >>> "internal API" meaning "implementation dependent feature", i.e. not >>> specified in MIPv6 documents. >> >> => Yes of course. > > ok, but that's just not clearly stated in the document. => I'm trying to make it clear that the document is not inventing this API but inheriting it. In order for anyone to be able to implement this document they need to read 3775/6, 4877 and understand the interactions with IPsec. If people do that, then they *already* know that an API exists. For example, did you see any reference of this API in nemo specs? Any reference in any other MIPv6 specs that are dependent on the specs above? There is a reason for that: they all depend on the original MIPv6 specs. >>>> >>>> => How what? >>> >>> I mean: How is the IKE daemon expected to find out which addresses and >>> ports to use? Can you take as example a MN w/ multiple interfaces? How >>> does it know which ones have been selected by the HA? >> >> => Are you still talking about the IKE daemon in the HA? It's responding to >> IKE messages from the MN. I don't understand the question. > > Sorry for the confusion. I wrote HA while thinking MIPv6 module: the > correct last sentence is: How does it know which one has been selected > by the MIPv6 module? > > >> If you're talking about IKE in the MN, then it's more confusing to me >> because it *initiates* the communication. > > IKE needs to be modified to guess the right address, that's all I say. In > the same fashion as *expected* in 3775/3776 for initial transport mode > negotiation. I think you just suppose "the API" also provides that. => There is no guessing in the MN, it's provided the home address as part of the src address selection. If you're talking about running IKE for NAT traversal and securing all traffic then it re-uses the SAs for the home address. > > >>>>> How does the MIPv6 modules manages to tell the IKE module to do that? >>>> >>>> => See above, this is an assumed API based in 3775. >>> >>> As stated before, it is left as an implementation dependent issue. In >>> the end, the result of this hypothesis/lack leads to: >>> >>> 1) inability to have different IKE and MIPv6 implementations work >>> together out of the box on a given system. >>> 2) assumption that IKE and MIPv6 modules are implemenented together, >>> i.e. are part of the same module. AFAICT, this is a trend in recent >>> MIPv6 documents that deal with IPsec/IKE. >>> >>> Don't hesitate to correct me on that. >> >> => There is nothing to correct, but there is not much I can do about that in >> DSMIP. We are using assumptions in MIPv6, so yes we know the above issues >> and there are pseudo-standard APIs on some platforms for this. > > Well, I don't expect DSMIP document to provide the API but stating > explicitly it is not defined (or that some drafts are available at > various places) would help, IMHO. > > You will agree that the document adds additonal requirements for that > API, w/o making them explicit. => They are all in the security considerations discussion in great detail. I'm not sure what you're asking us to add. Please send the text that you think we need to add to that section. >>> That's what I thought. What's the point in requiring *only* the HA to >>> support that? What is the reason not to require that for the MN too? >> >> => I believe you were quoting text that refers to updates due to the MN's >> address changes. It is required for the HA as the default mechanism. If the >> MN supports it then it's fine, if not the MN will need to re-negotiate the >> SA. So there is no need to mandate it for the MN. > > Let me rephrase it: Why is it a MUST on the HA (i.e. *arguments*) and some > kind of 'can' for the MN? How were those levels of support decided? Based > on which *technical* arguments? => Because the ideal scenario is to support this mechanism in order to minimise traffic disruption. Therefore, we had to propose this as the default for the HA. The mechanism itself is a SHOULD in the IKE spec. You need to specify a default common to all MNs. Now, if an MN doesn't support it or doesn't care then there is nothing we can do about that. There is no point in mandating something when ignoring that mandate makes a difference to only one side of the protocol and has no impact on the node it communicates with. > > >> => Ok, I'm guessing (because you didn't say) that this is related to the API >> concern you have. My point on that is that it's a bit too late to worry >> about it since it's already out there in implementations. > > What can I say: I worked on the API (MIGRATE), made a followup draft > correcting problems found during the implementation, implemented support > for racoon, UMIP, additions for Linux Kernel and helped strongSwan > people during their implementation of my draft. => Ok, so what are you asking me to do? >> => I think that this API was already assumed 5 years ago during the security >> rehash of MIPv6. This is not a new assumption in this spec. > > From the discussion I had w/ Julien some time ago on the need for that > kind of API, I am not that sure. And I don't think we should issue specs > with floating assumptions. We cannot expect future implementors were > there 5 or 6 years ago reading the list, can we? => Of course not, but we can expect them to read the specs that we're dependent on because they have to do that in order to implement the spec. I personally don't want this API at all in MIPv6 but there is no point in discussing this here. The point is this: What are you asking the WG to add to the spec? Can you send text? Hesham > > Cheers, > > a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 9 23:47:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC3D53A6910; Tue, 9 Dec 2008 23:47:46 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011A33A6910 for ; Tue, 9 Dec 2008 23:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 uupMLbx5YbUh for ; Tue, 9 Dec 2008 23:47:43 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 953423A6818 for ; Tue, 9 Dec 2008 23:47:43 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LAJnA-0006lN-Ju; Wed, 10 Dec 2008 08:47:33 +0100 From: arno@natisbad.org (Arnaud Ebalard) To: Hesham Soliman 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:081210:hesham@elevatemobile.com::WgYqiJUCL3ak+wPK:00000000000000000000000000000000000000I2S X-Hashcash: 1:20:081210:mext@ietf.org::iO+sNpoqFXasZFd2:000022KC Date: Tue, 09 Dec 2008 23:45:27 -0800 In-Reply-To: (Hesham Soliman's message of "Wed, 10 Dec 2008 16:57:07 +1100") Message-ID: <87skow1njc.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] Comments on draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Hesham Soliman writes: >>>> "internal API" meaning "implementation dependent feature", i.e. not >>>> specified in MIPv6 documents. >>> >>> => Yes of course. >> >> ok, but that's just not clearly stated in the document. > > => I'm trying to make it clear that the document is not inventing this API > but inheriting it. In order for anyone to be able to implement this document > they need to read 3775/6, 4877 and understand the interactions with IPsec. > If people do that, then they *already* know that an API exists. No. They know that there is a need for tight interactions between IPsec/IKE and MIPv6: for bootstrapping, for tunnel endpoint updates, for internal IKE daemon structures updates. All they get is a pointer to the old MIGRATE draft in 4877 as a possible hint for solving the second point: Such address changes can be implemented, for instance, through an API from the Mobile IPv6 implementation to the IPsec implementation. One such API is described in [12]. > For example, did you see any reference of this API in nemo specs? No, because NEMO does not need to extend it. Does it? > Any reference in any other MIPv6 specs that are dependent on the specs > above? No, but are there some among those that extend the API? > There is a reason for that: they all depend on the original MIPv6 specs. Or they do not have additional needs associated w/ the API. >>>> I mean: How is the IKE daemon expected to find out which addresses and >>>> ports to use? Can you take as example a MN w/ multiple interfaces? How >>>> does it know which ones have been selected by the HA? >>> >>> => Are you still talking about the IKE daemon in the HA? It's responding to >>> IKE messages from the MN. I don't understand the question. >> >> Sorry for the confusion. I wrote HA while thinking MIPv6 module: the >> correct last sentence is: How does it know which one has been selected >> by the MIPv6 module? >> >> >>> If you're talking about IKE in the MN, then it's more confusing to me >>> because it *initiates* the communication. >> >> IKE needs to be modified to guess the right address, that's all I say. In >> the same fashion as *expected* in 3775/3776 for initial transport mode >> negotiation. I think you just suppose "the API" also provides that. > > => There is no guessing in the MN, it's provided the home address as part of > the src address selection. If you're talking about running IKE for NAT > traversal and securing all traffic then it re-uses the SAs for the home > address. Sorry, but I fail to understand the whole paragraph. What I say is the following: when a common Mobile Node negotiates its initial transport mode SA (for securing signaling traffic, i.e. BU/BA w/ the HA), it needs to perform the IKE negotiation using the CoA. A common IKE implementation is not expected to do that (SP uses the HoA, which is not available at that time) and need to be modified to support that. One possible solution is to have the right address (CoA) provided to the IKE daemon by the MIPv6 module. Obviously, you are aware of that. Now what are the exact steps on a DSMIPv6-compliant MN using IKE when it starts operating in an IPv4-only network? I just reread 6.2.1 and it still seems unclear to me how the IKE implementation will decide that it should use a V4ADDR and then which V4ADDR it will use. Does the IKE implementation take the first v4 address available to do that? What if it has multiple interfaces with privates IPv4 address? It is possible I missed some part in the document that explain that precisely. >> You will agree that the document adds additonal requirements for that >> API, w/o making them explicit. > > => They are all in the security considerations discussion in great detail. Some of my comments/questions were about those elements of the security consideration section. > I'm not sure what you're asking us to add. Please send the text that you > think we need to add to that section. ok. I will *try* and find some time this WE to provide some text. >>>> That's what I thought. What's the point in requiring *only* the HA to >>>> support that? What is the reason not to require that for the MN too? >>> >>> => I believe you were quoting text that refers to updates due to the MN's >>> address changes. It is required for the HA as the default mechanism. If the >>> MN supports it then it's fine, if not the MN will need to re-negotiate the >>> SA. So there is no need to mandate it for the MN. >> >> Let me rephrase it: Why is it a MUST on the HA (i.e. *arguments*) and some >> kind of 'can' for the MN? How were those levels of support decided? Based >> on which *technical* arguments? > > => Because the ideal scenario is to support this mechanism in order to > minimise traffic disruption. Therefore, we had to propose this as the > default for the HA. The mechanism itself is a SHOULD in the IKE spec. > You need to specify a default common to all MNs. Now, if an MN doesn't > support it or doesn't care then there is nothing we can do about that. There > is no point in mandating something when ignoring that mandate makes a > difference to only one side of the protocol and has no impact on the node it > communicates with. It does not seem logical to me. Sorry. It just creates a situation where client will undergo traffic disruption with a compliant implementation even if the one on the HA support the feature. >>> => Ok, I'm guessing (because you didn't say) that this is related to the API >>> concern you have. My point on that is that it's a bit too late to worry >>> about it since it's already out there in implementations. >> >> What can I say: I worked on the API (MIGRATE), made a followup draft >> correcting problems found during the implementation, implemented support >> for racoon, UMIP, additions for Linux Kernel and helped strongSwan >> people during their implementation of my draft. > > => Ok, so what are you asking me to do? I don't know. What about taking a look at the draft [1] and see if the API can easily be used/extended for some of the needs you have in the doc. I let you decide. [1]: http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00 >>> => I think that this API was already assumed 5 years ago during the security >>> rehash of MIPv6. This is not a new assumption in this spec. >> >> From the discussion I had w/ Julien some time ago on the need for that >> kind of API, I am not that sure. And I don't think we should issue specs >> with floating assumptions. We cannot expect future implementors were >> there 5 or 6 years ago reading the list, can we? > > => Of course not, but we can expect them to read the specs that we're > dependent on because they have to do that in order to implement the > spec. yes, I agree. > I personally don't want this API at all in MIPv6 but there is no point in > discussing this here. I don't think this would make sense to add the API in MIPv6 either. But support for IPsec tunnel endpoints update upon movement is required by 3775. Bootstrapping w/ IKE does not work w/o it and updates of internal IKE structures is also a need. In the end, for things to work smoothly, it is needed. > The point is this: What are you asking the WG to add to the spec? Can > you send text? As written previously, I will try and take a look this WE, and then send some text. Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From jboondd@agl.com Wed Dec 10 09:22:29 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740EE3A6993 for ; Wed, 10 Dec 2008 09:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.744 X-Spam-Level: X-Spam-Status: No, score=-0.744 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0sH2gdFF5AW for ; Wed, 10 Dec 2008 09:22:28 -0800 (PST) Received: from 189-10-229-76.paemt701.dsl.brasiltelecom.net.br (189-10-229-76.paemt701.dsl.brasiltelecom.net.br [189.10.229.76]) by core3.amsl.com (Postfix) with SMTP id 22DD33A677E for ; Wed, 10 Dec 2008 09:22:25 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081210172226.22DD33A677E@core3.amsl.com> Date: Wed, 10 Dec 2008 09:22:25 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From jaravena@alusa.cl Wed Dec 10 16:38: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 4E4573A690F for ; Wed, 10 Dec 2008 16:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.506 X-Spam-Level: X-Spam-Status: No, score=-18.506 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HOST_EQ_DHCP=1.295, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYA5PXYjrJOF for ; Wed, 10 Dec 2008 16:38:15 -0800 (PST) Received: from alphanr.com (unknown [187.5.67.40]) by core3.amsl.com (Postfix) with SMTP id 7411E3A685C for ; Wed, 10 Dec 2008 16:38:12 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081211003813.7411E3A685C@core3.amsl.com> Date: Wed, 10 Dec 2008 16:38:12 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mext-bounces@ietf.org Wed Dec 10 17:20: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 C15893A6983; Wed, 10 Dec 2008 17:20:59 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58AC3A6934 for ; Wed, 10 Dec 2008 17:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUKHMAPg-xUl for ; Wed, 10 Dec 2008 17:20:56 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 765623A6B84 for ; Wed, 10 Dec 2008 17:20:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=pstupar@qualcomm.com; q=dns/txt; s=qcdkim; t=1228958441; x=1260494441; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:from:to:cc:x-originalarrivaltime: x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20Comments=20on=20draft-ietf-mext-b inding-revocation-02|Date:=20Thu,=2011=20Dec=202008=2001: 19:19=20-0000|Message-ID:=20|X-MS-Has-Attach:=20 |X-MS-TNEF-Correlator:=20|Thread-Topic:=20Comments=20on =20draft-ietf-mext-binding-revocation-02|Thread-Index:=20 AclbLn3taqHuU6TUSgeN3dxQhl2ykQ=3D=3D|From:=20"Stupar,=20P atrick"=20|To:=20|Cc:=20|X-OriginalArrivalTime:=2011=20D ec=202008=2001:20:35.0748=20(UTC)=20FILETIME=3D[AB4F1640: 01C95B2E]|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,546 0"=3B=20a=3D"13834178"; bh=B4C79wjEXe6QPRt8CMko9qJynpGg4QHfV1yYUFNkbxU=; b=tFlQh5eA1cEj/QPTdrpx5uDb6TbETuOxjOIUY9GIGKbCElAkVvAsxjRm sLED546S/dUgodtH0Hguazy7BuD33089pN9x5KW6DILtewOa9A7snQPf1 o1os3lvUGTLdJsYw3L/HMCfvr7CrOVj55q8p2pnqQWfmv0wjwvw7Q75Do k=; X-IronPort-AV: E=McAfee;i="5100,188,5460"; a="13834178" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Dec 2008 17:20:40 -0800 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBB1KeU9016480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Dec 2008 17:20:40 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBB1KZK3027041; Wed, 10 Dec 2008 17:20:40 -0800 Received: from EUEX02.eu.qualcomm.com ([10.222.228.34]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Dec 2008 17:20:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Dec 2008 01:19:19 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-mext-binding-revocation-02 Thread-Index: AclbLn3taqHuU6TUSgeN3dxQhl2ykQ== From: "Stupar, Patrick" To: X-OriginalArrivalTime: 11 Dec 2008 01:20:35.0748 (UTC) FILETIME=[AB4F1640:01C95B2E] Cc: mext@ietf.org Subject: [MEXT] Comments on draft-ietf-mext-binding-revocation-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, I have reviewed binding revocation draft and have the following comments/questions. - In MIPv6, Binding Update and Binding Ack have two different MH type values. Why isn't the same approach taken for BRI and BRA and only one value is used? - BRI has a revocation trigger field which is used for two main usages. One is the provisioning of the reason why the revocation was sent (e.g. inter-MAG handoff) and the other is related to specific binding revocation procedures (e.g. IPV4 HoA Binding only, Per-Peer Policy). I think it would be cleaner if the two concepts remain separated in the messages, for instance defining additional flags for Per-peer policy or IPv4 HoA Binding only. - In the draft you refer to MAG identity, where is this term defined? I wasn't able to find it in RFC 5213. Some other comments related to specific sections: - page 21: in the first section after the bullet list, there is the following sentence: "As described in Section 7.3, the LMA SHOULD retransmit this BRI to the MAG before deleting the mobile node IP tunnel to the mobile access gateway until it receives a matching Binding Revocation Acknowledgement or the BRIMaxRetransmitNumber is reached. " But this doesn't always apply, e.g. in case of inter-mag handoffs. What am I missing? - why is the A bit setting mandatory in case of IPv4 HoA binding only revocation? - section 10.1.1: "BRI MUST be formatted as in Section 6.1 and if the (P) bit is set, the mobile access gateway must validate that the impacted binding have the proxy binding flag set." MAG is not supposed to have any proxy binding flag or is it? How can it validate this flag? -section 11.1 " If the Acknowledgement (A) bit is set in the Binding Revocation Indication and the MN has the BCE in registered state, the mobile node MUST send a Binding Revocation Acknowledgement." MN has no BCE, it has a binding update list. -section 11.1 "If the Revocation Trigger field value is "Administrative Reason", the mobile node MUST NOT try to re-register with the home agent before contacting its home operator." I don't think that BRI specs have to mandate the MN to contact the home operator, the text at the end of section 11.1 is enough IMO. I have some typos and editorial corrections as well, I will send them off-list. Regards, Patrick _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 10 18:19: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 DC89F3A69C7; Wed, 10 Dec 2008 18:19:30 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2025E3A691C for ; Wed, 10 Dec 2008 18:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.915 X-Spam-Level: * X-Spam-Status: No, score=1.915 tagged_above=-999 required=5 tests=[AWL=2.409, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 VmpNFZQYQ9IM for ; Wed, 10 Dec 2008 18:19:29 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 08AFC3A687F for ; Wed, 10 Dec 2008 18:19:29 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KBO00K43X40KB@szxga03-in.huawei.com> for mext@ietf.org; Thu, 11 Dec 2008 10:19:13 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KBO0020TX40NS@szxga03-in.huawei.com> for mext@ietf.org; Thu, 11 Dec 2008 10:19:12 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KBO00AAJX3Z81@szxml06-in.huawei.com> for mext@ietf.org; Thu, 11 Dec 2008 10:19:12 +0800 (CST) Date: Thu, 11 Dec 2008 10:19:10 +0800 From: Yungui Wang To: marcelo bagnulo braun , mext , Julien Laganier , Ralph Droms Message-id: <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <491039B9.6090400@it.uc3m.es> Subject: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1217967101==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1217967101== Content-type: multipart/alternative; boundary="Boundary_(ID_6qWArhwFcju/qGpBk5BDjQ)" This is a multi-part message in MIME format. --Boundary_(ID_6qWArhwFcju/qGpBk5BDjQ) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hello Here is one comment about using MR-HA tunnel for DHCP-PD. In this draft, the MR registration processing needs 3 round trip between MR and HA. i. BU to HA; (getting and binding MR_HoA) ii. DHCPv6 message over MR-HA tunnel. (getting MNP) iii. BU to HA; (binding MNP) While, if PD is combined within BU, it is only 1 round trip. >From implementation of viewpoint, the later seems well done prior of the former. Maybe I have lost something, can anyone tell me the story why we gave up the latter in the new version? Thanks. B.R. Yungui ----- Original Message ----- From: marcelo bagnulo braun To: mext ; Julien Laganier ; Ralph Droms Sent: Tuesday, November 04, 2008 8:02 PM Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt Hi, We now start the WGLC for: DHCPv6 Prefix Delegation for NEMO draft-ietf-mext-nemo-pd-01.txt http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt Please send comments about the draft till the November 19. Regards, Julien and marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --Boundary_(ID_6qWArhwFcju/qGpBk5BDjQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Hello
 
Here is one comment about using MR-HA tunnel for DHCP-PD.
 
In this draft, the MR registration processing needs 3 round trip between MR and HA.
i. BU to HA; (getting and binding MR_HoA)
ii. DHCPv6 message over MR-HA tunnel. (getting MNP)
iii. BU to HA; (binding MNP)
While, if PD is combined within BU, it is only 1 round trip.
 
From implementation of viewpoint, the later seems well done prior of the former. Maybe I have lost something, can anyone tell me the story why we gave up the latter in the new version? Thanks.
 
B.R.
Yungui
 
 
----- Original Message -----
Sent: Tuesday, November 04, 2008 8:02 PM
Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt

Hi,

We now start the WGLC for:

DHCPv6 Prefix Delegation for NEMO
draft-ietf-mext-nemo-pd-01.txt

http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt


Please send comments about the draft till the November 19.

Regards, Julien and marcelo


_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
--Boundary_(ID_6qWArhwFcju/qGpBk5BDjQ)-- --===============1217967101== 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 --===============1217967101==-- From mext-bounces@ietf.org Wed Dec 10 19:29:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178C53A6904; Wed, 10 Dec 2008 19:29:25 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4BE3A6904 for ; Wed, 10 Dec 2008 19:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSeCvIk6OB22 for ; Wed, 10 Dec 2008 19:29:22 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 52CA13A67D0 for ; Wed, 10 Dec 2008 19:29:21 -0800 (PST) Received: from [211.27.108.142] (helo=[10.0.0.21]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LAcEg-0003YR-5R; Thu, 11 Dec 2008 14:29:10 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Thu, 11 Dec 2008 14:29:01 +1100 From: Hesham Soliman To: Arnaud Ebalard Message-ID: Thread-Topic: Comments on draft-ietf-mext-nemo-v4traversal-06.txt Thread-Index: AclbQJv/NfLhblMGu0Kj33c9UMrarg== In-Reply-To: <87skow1njc.fsf@natisbad.org> Mime-version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org >> => I'm trying to make it clear that the document is not inventing this API >> but inheriting it. In order for anyone to be able to implement this document >> they need to read 3775/6, 4877 and understand the interactions with IPsec. >> If people do that, then they *already* know that an API exists. > > No. They know that there is a need for tight interactions between > IPsec/IKE and MIPv6: for bootstrapping, for tunnel endpoint updates, for > internal IKE daemon structures updates. All they get is a pointer to the > old MIGRATE draft in 4877 as a possible hint for solving the second point: > > Such address changes can be implemented, for instance, through an > API from the Mobile IPv6 implementation to the IPsec > implementation. One such API is described in [12]. => That's right, and I think that's all that can be done in standards if we need internal APIs. The IETF typically doesn't standardise APIs, with the except of the pseudo standard socket API. > >> For example, did you see any reference of this API in nemo specs? > > No, because NEMO does not need to extend it. Does it? > >> Any reference in any other MIPv6 specs that are dependent on the specs >> above? > > No, but are there some among those that extend the API? > >> There is a reason for that: they all depend on the original MIPv6 specs. > > Or they do not have additional needs associated w/ the API. => Ok, so I gather from these comments that you're only concerned about clearly identifying the extensions. So if you can go through the security section and let us know if any of the extensions are not clear that would be helpful. >> => There is no guessing in the MN, it's provided the home address as part of >> the src address selection. If you're talking about running IKE for NAT >> traversal and securing all traffic then it re-uses the SAs for the home >> address. > > Sorry, but I fail to understand the whole paragraph. What I say is the > following: when a common Mobile Node negotiates its initial transport > mode SA (for securing signaling traffic, i.e. BU/BA w/ the HA), it needs > to perform the IKE negotiation using the CoA. A common IKE > implementation is not expected to do that (SP uses the HoA, which is > not available at that time) and need to be modified to support that. One > possible solution is to have the right address (CoA) provided to the IKE > daemon by the MIPv6 module. Obviously, you are aware of that. Now what > are the exact steps on a DSMIPv6-compliant MN using IKE when it starts > operating in an IPv4-only network? I just reread 6.2.1 and it still > seems unclear to me how the IKE implementation will decide that it > should use a V4ADDR and then which V4ADDR it will use. > > Does the IKE implementation take the first v4 address available to do > that? What if it has multiple interfaces with privates IPv4 address? > > It is possible I missed some part in the document that explain that > precisely. => You didn't miss it, it's not in the draft. The issue of the "right" CoA is a policy issue that needs to be addressed by src address selection. If the MN is multihomed then there must be a number of factors involved in making this decision, none of them can be attributed to DSMIPv6. Of course once an SA is established, then that information needs to be passed to MIPv6 in order choose the right CoA. The initial choice between a number of CoAs is basically irrelevant to DSMIPv6. Do you think DSMIPv6 needs to specify which CoA should be chosen and how? I don't think that would fit into the scope of the spec. You can make the same argument about a multihomed IPv6 MN and reach the same conclusion, no? > >> => Because the ideal scenario is to support this mechanism in order to >> minimise traffic disruption. Therefore, we had to propose this as the >> default for the HA. The mechanism itself is a SHOULD in the IKE spec. >> You need to specify a default common to all MNs. Now, if an MN doesn't >> support it or doesn't care then there is nothing we can do about that. There >> is no point in mandating something when ignoring that mandate makes a >> difference to only one side of the protocol and has no impact on the node it >> communicates with. > > It does not seem logical to me. Sorry. It just creates a situation where > client will undergo traffic disruption with a compliant implementation > even if the one on the HA support the feature. => Yes of course but that can always happen for many features in MIPv6. It makes no sense to mandate something that, when not followed, has no impact on interoperability. We need to mandate the support in the HA, so MN's can assume a certain level of support and therefore interoperable implementations. If the HA initiated the requests we would have mandated the support in the MN. > >>>> => Ok, I'm guessing (because you didn't say) that this is related to the >>>> API >>>> concern you have. My point on that is that it's a bit too late to worry >>>> about it since it's already out there in implementations. >>> >>> What can I say: I worked on the API (MIGRATE), made a followup draft >>> correcting problems found during the implementation, implemented support >>> for racoon, UMIP, additions for Linux Kernel and helped strongSwan >>> people during their implementation of my draft. >> >> => Ok, so what are you asking me to do? > > I don't know. What about taking a look at the draft [1] and see if the > API can easily be used/extended for some of the needs you have in the > doc. I let you decide. > > [1]: http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00 => I'm happy to discuss that with you in a separate thread, but I fail to see how this will improve the quality of DSMIPv6, which is our highest priority now. I.e., if, for whatever reason, the changes needed don't fit into your draft, that will not give me any indication as to how to improve DSMIPv6. Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 11 01:50: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 39FA43A6C3A; Thu, 11 Dec 2008 01:50:24 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31C433A6C3A for ; Thu, 11 Dec 2008 01:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4b3nGjjRBFAe for ; Thu, 11 Dec 2008 01:50:22 -0800 (PST) Received: from mail-ew0-f31.google.com (mail-ew0-f31.google.com [209.85.219.31]) by core3.amsl.com (Postfix) with ESMTP id 8B1983A6C37 for ; Thu, 11 Dec 2008 01:50:21 -0800 (PST) Received: by ewy12 with SMTP id 12so707264ewy.13 for ; Thu, 11 Dec 2008 01:50:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=KzzRjDJGrdmELRsWRGp5XnYDpnXVgDaEv5tuJVGo7s0=; b=B1Iqf32hEpE05NiMTPPwuqXA5vCDCO8bnw4ni2jXpyUBd7UxNtfsVBr7oYhsVRAijI XAc6AVOvA4dTeK5UOpoWATr/iKDd1l2D/XvwBszVWh2H+3mqDm1/BXNfmCJh8fmpyCS7 beY17zZns25JcUrftgUl7gF8LGiPZEWJlhEtE= 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=L4j7n9XHa0MyxAKX/Bo0PQv84j44HSEjjK5xWxK2mdZLBVpMv6qmZTwgmZeRJAwp76 VWvkHzY9OSlf6tacXBMVyi0uxUxrda2QMyW7N+A3ydOZPjl08lZ7BW4fwjbSGz0I4/rq 8ISkuSlQhLFucVvzE14jFW1/l6rCQ3jXjCsDQ= Received: by 10.210.42.13 with SMTP id p13mr2983549ebp.10.1228989013189; Thu, 11 Dec 2008 01:50:13 -0800 (PST) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id p10sm1002745gvf.7.2008.12.11.01.50.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Dec 2008 01:50:12 -0800 (PST) To: Yungui Wang Date: Thu, 11 Dec 2008 10:50:19 +0100 User-Agent: KMail/1.9.10 References: <491039B9.6090400@it.uc3m.es> <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> In-Reply-To: <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200812111050.19715.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org We had this discussion for a long time abd it has concluded some time ago already: WG consensus is to use DHCP PD. (w/o questioning the value of optimizing RTTs for a procedure which isn't in a critical path, e.g., handover) --julien On Thursday 11 December 2008, Yungui Wang wrote: > Hello > > Here is one comment about using MR-HA tunnel for DHCP-PD. > > In this draft, the MR registration processing needs 3 round trip > between MR and HA. i. BU to HA; (getting and binding MR_HoA) > ii. DHCPv6 message over MR-HA tunnel. (getting MNP) > iii. BU to HA; (binding MNP) > While, if PD is combined within BU, it is only 1 round trip. > > From implementation of viewpoint, the later seems well done prior of > the former. Maybe I have lost something, can anyone tell me the story > why we gave up the latter in the new version? Thanks. > > B.R. > Yungui > > > ----- Original Message ----- > From: marcelo bagnulo braun > To: mext ; Julien Laganier ; Ralph Droms > Sent: Tuesday, November 04, 2008 8:02 PM > Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt > > > Hi, > > We now start the WGLC for: > > DHCPv6 Prefix Delegation for NEMO > draft-ietf-mext-nemo-pd-01.txt > > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt > > > Please send comments about the draft till the November 19. > > Regards, Julien and marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext -- --julien [ New email address: julien.laganier.IETF@googlemail.com ] _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 11 02:22: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 B54ED3A6A6F; Thu, 11 Dec 2008 02:22:20 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A9CE3A67EF for ; Tue, 9 Dec 2008 22:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.617 X-Spam-Level: ** X-Spam-Status: No, score=2.617 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, 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 LqYdQ-vwYla4 for ; Tue, 9 Dec 2008 22:50:18 -0800 (PST) Received: from ricky.india.internal.net (unknown [59.145.147.70]) by core3.amsl.com (Postfix) with ESMTP id 265EF3A6358 for ; Tue, 9 Dec 2008 22:50:16 -0800 (PST) Received: from Magesh (magesh.india.internal.net.16.172.in-addr.arpa [172.16.8.41] (may be forged)) by ricky.india.internal.net (8.12.10/8.12.10) with ESMTP id mBA6f9xA029247; Wed, 10 Dec 2008 12:11:09 +0530 Message-Id: <200812100641.mBA6f9xA029247@ricky.india.internal.net> From: "Magesh Shanmugam" To: "'Ahmad Muhanna'" Date: Wed, 10 Dec 2008 12:24:30 +0530 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AclalCYuhfjQHuocScae7Wmc5lzMKA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Cyberoam-Version: 9.5.4.86 X-Cyberoam-smtpxy-version: 0.0.4.2 X-Cyberoam-AV-Status: Clean X-Cyberoam-Proto: SMTP X-Cyberoam-AV-Policy: None X-Cyberoam-AS-Policy: Global Spam Policy X-Mailman-Approved-At: Thu, 11 Dec 2008 02:22:19 -0800 Cc: mext@ietf.org Subject: [MEXT] Global Binding Revocation initiated by MAG X-BeenThere: mext@ietf.org X-Mailman-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="===============2045061306==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============2045061306== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C95AC2.4C4782C0" This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C95AC2.4C4782C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ahmad In PMIPv6 domain, when MAG initiates Global Binding Revocation (G bit set), it will send the MAG identity in the MN-ID option (as per section 3.1 of binding-revocation draft-02). As per RFC 5213, while creating Binding Cache Entry @ LMA, we have MN-ID, HNP(s), Proxy Care of Address, etc in the received PBU message which will be updated in the BC entry after validation. MAG-ID will not be stored in the Binding Cache Entry when individual binding session(s) are processed and validated by LMA. When MAG triggers Global Binding Revocation, it will send the MAG-ID in the MN-ID option. Since LMA won't maintain the MAG-ID for each binding session (i.e. in BC entry), it will be tough for the LMA to identify all the binding(s) from the specific MAG. Instead of having MAG-ID in the MN-ID option for Global Revocation, if we use Proxy Care of Address (through the source IP address of the BRI message or Alternate Care of Address mobility option, if source address is different from proxy care of address), it will be easy for LMA to retrieve all the binding(s), since Proxy Care of Address is stored in the Binding Cache entry. Thanks S Magesh ------=_NextPart_000_002B_01C95AC2.4C4782C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ahmad
 
In = PMIPv6 domain,=20 when MAG initiates Global Binding Revocation (G bit set), it will send = the MAG=20 identity in the MN-ID option (as per section 3.1 of binding-revocation=20 draft-02).
 
As per = RFC 5213,=20 while creating Binding Cache Entry @ LMA, we have MN-ID, HNP(s), Proxy = Care of=20 Address, etc in the received PBU message which will be updated in=20 the
BC = entry after=20 validation.  MAG-ID will not be stored in the Binding Cache Entry = when=20 individual binding session(s) are processed and validated by LMA. =20
When = MAG triggers=20 Global=20 Binding Revocation, it will send the MAG-ID in the MN-ID option.  = Since LMA=20 won't maintain the MAG-ID for each binding session (i.e. in BC entry),=20
it = will be tough for=20 the LMA to identify all the binding(s) from the specific MAG. =20
 
Instead of having=20 MAG-ID in the MN-ID option for Global Revocation, if we use Proxy Care = of=20 Address (through the source IP address of the BRI message or=20
Alternate Care of=20 Address mobility option, if source address is different from proxy care = of=20 address), it will be easy for LMA to retrieve all the binding(s),=20
since = Proxy Care of=20 Address is stored in the Binding Cache entry.
 
Thanks
S=20 Magesh
------=_NextPart_000_002B_01C95AC2.4C4782C0-- --===============2045061306== 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 --===============2045061306==-- From mext-bounces@ietf.org Thu Dec 11 06:08: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 902493A6A6F; Thu, 11 Dec 2008 06:08:27 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2D0A3A69E2 for ; Thu, 11 Dec 2008 06:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 kBjBv7vxVHD6 for ; Thu, 11 Dec 2008 06:08:24 -0800 (PST) Received: from ws000774.tietoenator.com (ws000774.tietoenator.com [193.12.181.129]) by core3.amsl.com (Postfix) with ESMTP id 6CB0A3A6A2B for ; Thu, 11 Dec 2008 06:08:24 -0800 (PST) X-AuditID: c10cb581-00000f2c000004d8-c4-49411ece2cd4 Received: from stingray.eu.tieto.com ([192.176.143.13]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 15:08:14 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Dec 2008 15:08:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Dec 2008 15:08:16 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Subject: Multiple CoA draft 10 -- two proposals and some comments Thread-Index: AclbmelbVEZqE1eBQTKM/5HFe6iu1g== From: To: X-OriginalArrivalTime: 11 Dec 2008 14:08:16.0873 (UTC) FILETIME=[E9E0FD90:01C95B99] X-Brightmail-Tracker: AAAAAA== Subject: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Assume a mobile node with home address HoA has two interfaces, both attached to foreign links. After exchange of binding update and binding acknowledgement, the home agent's binding cache (at least the snip of it related to HoA) will look like this HoA, BID= 7, CoA1, other parameters like period of validity... HoA, BID=10, CoA2, other parameters ... The draft uses HoA=2001:db8::EUI. Draft 10, section 5.1 states, that a BID value must be unique for a home address and care-of address pair. This is satisfied above, but it means, that the mobile station is not allowed to change the second entry such that it also uses CoA1 as care-of address. Proposal: I think it has merit to be able to allow more than one BID value per pair of home address and care-of address. Consider flow bindings (defined in draft-ietf-mext-flow-binding) where a flow may refer to a BID, and thus there is a simple way to move flows between interfaces: only updating the binding cache. Draft 10, section 4.2 (and other places) defines the H flag, which when set means the mobile node wants to use both its home link and one or more of its foreign links. The H flag is really an instruction to the home agent, that in addition to all the bidings currently defined is shall have an extra binding where packets shall not be tunneled. Proposal: The mobile node should be able to define a binding saying HoA BID=0 HoA This is a kind of default binding to be used when any of the other HoA- bindings cannot be used. I think the H flag is an indirect way of saying there is an extra binding, whereas the binding above is direct. It also avoids continuously setting the H flag when both home link and foreign links are active. Other comments o Figure 1: In general I think it simpler for human readers to have the elements of the primary key to a database given first, therefore I suggest binding [2001:db8::EUI BID1 care-of address1] to be used allover. o Figure 4: looks as if position 6 is followed by position 17. o Section 4.2, O flag. The O flag is carried in an Binding Identification mobility option, but really it a kind of global value to be understood by the receiver as "clean all HoA entries". If it really is too much to introduce a new mobility option, isn't it enough to set the O flag in the first Binding Identification mobility option? o Section 4.2, Care-of address and section 6.2 bullet 6, sub-bullet 2. If the care-of address is omitted, the care-of address is to be taken from the source address of the IPv6 header. When the binding update arrives at the home agent, the IPv6 header's source address is exactly the care-of address used by the mobile node, but when the home agent is actually able to understand the contents of the binding update, then the IPv6 headers source address has been swapped with the address found in the Destination Option extension header, and thus the care-of address is now found in the Destination Option extension header. o Section 5.6.2, bullet 2. The term link-local address is used, but I think this should be changed to be like in all the other places, using link-layer address. o Section 6.2, bullet 7, sub-bullet 1: I think the condition should read "If one of the 'O' flags is set, then all of the 'O' flags must be set, else [MCOA MALFORMED] is returned." But as suggested above, I don't think there is reason to enforce an all-or-none 'O' flags. o Section 8.2, para 2. The text says, that the IPv4 Address Acknowledgement mobility option is included only if the mobile node requested a home address. When I read draft-ietf-mext-nemo-v4traversal, section 4.2.1, the IPv4 Address Acknowledgement mobility option is included always, indicating the home agent created a binding cache entry for the IPv4 home address. Christian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 11 08:26:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A5463A6B1D; Thu, 11 Dec 2008 08:26:48 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 244EC3A6782 for ; Thu, 11 Dec 2008 08:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXEkpgMSILh3 for ; Thu, 11 Dec 2008 08:26:46 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.190]) by core3.amsl.com (Postfix) with ESMTP id ABFC73A6867 for ; Thu, 11 Dec 2008 08:26:45 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id w1so645694mue.9 for ; Thu, 11 Dec 2008 08:26:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=+3T3NO81hRykmoQ5Ab7AJUVDVP1553UG0/2qyHIJPug=; b=l8RLvpviU8M/8NnyZKC0v+Xn61oqX4GixFf0ZiDV9d6GAup+atuHW/JVmjGspUKdg8 TzIyWhBXxZVIZGTYgjKPbfahH33xcq5hnxETFWZCZLW+wU+/5DojqH2nO8LuVvIjjQP9 2aCt8pOav2Htve3aFB7vIOGdSZAsnoyDsimwE= 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=KXiVimX/VPoWx/7+/mFmOC/bIxB6WZrxAuirElEKW+8F41YDmmwD2e4li4wx/AlhLC Z91fzPiUs04XuK6WS/Z+kzXEhEGNXrQnfgV2dHGDnf5f27G+qT5IijeT4fHbN4qSN+eJ azdy1x3LRslXBQUaVbPlvT3rY9RFmLWJCIG+8= Received: by 10.103.92.10 with SMTP id u10mr1163413mul.22.1229012798440; Thu, 11 Dec 2008 08:26:38 -0800 (PST) Received: from ?163.117.183.49? ([163.117.183.49]) by mx.google.com with ESMTPS id u26sm1683903mug.58.2008.12.11.08.26.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Dec 2008 08:26:36 -0800 (PST) From: Ryuji Wakikawa To: Julien Laganier In-Reply-To: <200812111050.19715.julien.laganier.IETF@googlemail.com> References: <491039B9.6090400@it.uc3m.es> <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> <200812111050.19715.julien.laganier.IETF@googlemail.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 11 Dec 2008 17:26:33 +0100 X-Mailer: Apple Mail (2.929.2) Cc: mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien and Yungui, Actually, it's not only 3 round trip and is not optimization problem.. This is a big issue of DHCP-PD. Let me explain the issue clearly. According to the NEMO-DHCP-PD spec, before receiving a prefix, a mobile router must create a tunnel with its HA. For this purpose, the mobile router needs to act as a RFC3775 compliant mobile host before starting DHCP-PD. Why? If there is no prefix, the mobile router cannot sends a NEMO-BU (i.e. R-flag set) to its Home Agent. If there is no valid prefix for the mobile router, HA returns BA with "Invalid Prefix" status value which is treated as the fatal error in RFC3963. Well, RFC3963 allows for a mobile router to act as a mobile host, but we didn't assume that a mobile router switches its mode between RFC3775-mobile-host and RFC3963-mobile-router dynamically. For instance, RFC3963 said in section 6.2, "If the Home Agent has a valid binding cache entry for the Mobile Router, and if the Binding Update has the Mobile Router Flag (R) set to a value different from that in the existing binding cache entry, then the Home Agent MUST reject the Binding Update and send a Binding Acknowledgement with status set to 139 (Registration type change disallowed). However, if the Binding Update is a de-registration Binding Update, the Home Agent ignores the value of the Mobile Router Flag (R)." At the end, how the boostrapping goes? 1. MR acts as a MN and sends MIP6-BU (Rflag unset) to establish a tunnel for DHCP-PD 2. MR starting DHCP-PD 3. After DHCP-PD completion, MR de-registers the RFC3775-binding 4. MR sends NEMO-BU (R-flag finally set) for its mobile network prefix acquired by DHCP-PD I don't think this is right way to go.... I now changed my mind that the use of BU/BA is more straightforward for NEMO prefix delegation. ryuji On 2008/12/11, at 10:50, Julien Laganier wrote: > We had this discussion for a long time abd it has concluded some time > ago already: WG consensus is to use DHCP PD. > > (w/o questioning the value of optimizing RTTs for a procedure which > isn't in a critical path, e.g., handover) > > --julien > > On Thursday 11 December 2008, Yungui Wang wrote: >> Hello >> >> Here is one comment about using MR-HA tunnel for DHCP-PD. >> >> In this draft, the MR registration processing needs 3 round trip >> between MR and HA. i. BU to HA; (getting and binding MR_HoA) >> ii. DHCPv6 message over MR-HA tunnel. (getting MNP) >> iii. BU to HA; (binding MNP) >> While, if PD is combined within BU, it is only 1 round trip. >> >> From implementation of viewpoint, the later seems well done prior of >> the former. Maybe I have lost something, can anyone tell me the story >> why we gave up the latter in the new version? Thanks. >> >> B.R. >> Yungui >> >> >> ----- Original Message ----- >> From: marcelo bagnulo braun >> To: mext ; Julien Laganier ; Ralph Droms >> Sent: Tuesday, November 04, 2008 8:02 PM >> Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt >> >> >> Hi, >> >> We now start the WGLC for: >> >> DHCPv6 Prefix Delegation for NEMO >> draft-ietf-mext-nemo-pd-01.txt >> >> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt >> >> >> Please send comments about the draft till the November 19. >> >> Regards, Julien and marcelo >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > > > -- > --julien > > [ New email address: julien.laganier.IETF@googlemail.com ] > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 11 08:45: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 B70943A68C0; Thu, 11 Dec 2008 08:45:47 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF423A68C0 for ; Thu, 11 Dec 2008 08:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNo2MXlbp9bS for ; Thu, 11 Dec 2008 08:45:46 -0800 (PST) Received: from mail-fx0-f19.google.com (mail-fx0-f19.google.com [209.85.220.19]) by core3.amsl.com (Postfix) with ESMTP id 72EC13A684C for ; Thu, 11 Dec 2008 08:45:45 -0800 (PST) Received: by fxm12 with SMTP id 12so414678fxm.13 for ; Thu, 11 Dec 2008 08:45:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=f8Qunt9/sGh+qJKPnYckyLFiEIwcjV1cPSJ7Hy3pHWs=; b=mH2vUVHTe0ytFWlkfJPGNpohUxLMYb9J+42JxU1bjQnMFEp2b5LWwD5jxx35AZG9sU FNJW+f/FTD0XR9Jc8YjFMHuaDoTYSDtjMjfbX6+kmWORVXgqmD5bSWwbBtyqIHzNv5pE AIhduJ5yIthEEAvWqN13SfITiBHl0Cu9JP8MQ= 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=pQ8sysYXDpnZDXXLtDCq50j5exGHTtYfCTi69Pf+X0YLA5UzrY/mxQSp9T/5NH67Uo pjjAftukJCgZGufgMEpTfxjMww1XQUtGdtIg+yiVcJ118kEE8kXM66iH8kJ9k8PlUbf/ 7p0Zbpj9oDrQ+q3xC6pxUFPLgakAJShd/Yr2o= Received: by 10.103.161.16 with SMTP id n16mr1174688muo.79.1229013938457; Thu, 11 Dec 2008 08:45:38 -0800 (PST) Received: from ?163.117.183.49? ([163.117.183.49]) by mx.google.com with ESMTPS id b9sm936416mug.26.2008.12.11.08.45.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Dec 2008 08:45:36 -0800 (PST) From: Ryuji Wakikawa To: Romain KUNTZ In-Reply-To: <4B8E03A1-432A-49F9-8DA0-98EF582620FD@lsiit.u-strasbg.fr> References: <491039B9.6090400@it.uc3m.es> <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> <200812111050.19715.julien.laganier.IETF@googlemail.com> <4B8E03A1-432A-49F9-8DA0-98EF582620FD@lsiit.u-strasbg.fr> Message-Id: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 11 Dec 2008 17:45:33 +0100 X-Mailer: Apple Mail (2.929.2) Cc: Julien Laganier , mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On 2008/12/11, at 17:36, Romain KUNTZ wrote: > Hi Ryuji, > > On 2008/12/11, at 17:26, Ryuji Wakikawa wrote: >> For this purpose, the mobile router needs to act as a RFC3775 >> compliant mobile host before starting DHCP-PD. Why? If there is no >> prefix, the mobile router cannot sends a NEMO-BU (i.e. R-flag set) to >> its Home Agent. If there is no valid prefix for the mobile router, HA >> returns BA with "Invalid Prefix" status value which is treated as the >> fatal error in RFC3963. > > I'd say the MR still sends a BU with the R-flag set and without the > MNP option, which will be considered as registration in Implicit > mode by the HA. Implicit mode requires some mapping between a mobile network prefix and a mobile router. Implicit: In this mode, the Mobile Router does not include a Mobile Network Prefix Option in the Binding Update. The Home Agent can use any mechanism (not defined in this document) to determine the Mobile Network Prefix(es) owned by the Mobile Router and to set up forwarding for the Mobile Network. One example would be manual configuration at the Home Agent mapping the Mobile Router's Home Address to the information required for setting up forwarding for the Mobile Network. In RFC3963, we didn't consider a MR who doesn't have any mobile network prefix sends BU with R-flag set. In implicit mode, if there is no prefix for the MR, HA will reject the BU. regards, ryuji > > > Cheers, > romain > > > >> On 2008/12/11, at 10:50, Julien Laganier wrote: >> >>> We had this discussion for a long time abd it has concluded some >>> time >>> ago already: WG consensus is to use DHCP PD. >>> >>> (w/o questioning the value of optimizing RTTs for a procedure which >>> isn't in a critical path, e.g., handover) >>> >>> --julien >>> >>> On Thursday 11 December 2008, Yungui Wang wrote: >>>> Hello >>>> >>>> Here is one comment about using MR-HA tunnel for DHCP-PD. >>>> >>>> In this draft, the MR registration processing needs 3 round trip >>>> between MR and HA. i. BU to HA; (getting and binding MR_HoA) >>>> ii. DHCPv6 message over MR-HA tunnel. (getting MNP) >>>> iii. BU to HA; (binding MNP) >>>> While, if PD is combined within BU, it is only 1 round trip. >>>> >>>> From implementation of viewpoint, the later seems well done prior >>>> of >>>> the former. Maybe I have lost something, can anyone tell me the >>>> story >>>> why we gave up the latter in the new version? Thanks. >>>> >>>> B.R. >>>> Yungui >>>> >>>> >>>> ----- Original Message ----- >>>> From: marcelo bagnulo braun >>>> To: mext ; Julien Laganier ; Ralph Droms >>>> Sent: Tuesday, November 04, 2008 8:02 PM >>>> Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt >>>> >>>> >>>> Hi, >>>> >>>> We now start the WGLC for: >>>> >>>> DHCPv6 Prefix Delegation for NEMO >>>> draft-ietf-mext-nemo-pd-01.txt >>>> >>>> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt >>>> >>>> >>>> Please send comments about the draft till the November 19. >>>> >>>> Regards, Julien and marcelo >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> >>> -- >>> --julien >>> >>> [ New email address: julien.laganier.IETF@googlemail.com ] >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 11 08:49:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 486FE3A6BEC; Thu, 11 Dec 2008 08:49:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ACDF3A6BEC for ; Thu, 11 Dec 2008 08:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 QNR0dCVZUFjM for ; Thu, 11 Dec 2008 08:49:14 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id D308B3A6931 for ; Thu, 11 Dec 2008 08:49:13 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so603770fga.41 for ; Thu, 11 Dec 2008 08:49:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=5q5TcB+dPWrW4bQssP/K5l6ujUuXpJOCoEAtjeTroaM=; b=lFExSCBalEAAUDzB1W2QlIx3W/mVkDAwzIc3oBPj3Uy1lRpH+45B3ayGevVl6per9E Pa/dcb9VB0bpm8Kdl6unS2BDt4b4aip9/7gLvqKyouSr8eHAzqxzgIPXT8pWw2g32TWo wePQxiPF/l0MsMrryHGiDbhzn17b/MjyKUPVQ= 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=nQi3gBd19jQ9MnECavu62sVsFWC7u4qh8FwqUs5hK+JLtNfhsQ2QupZLMl/ih9UNDX yJuW9/ahpiWMDa62nbJHfT2waAqb0t/rJof8TDhcU0At472dM44coOnZSg9dlNnWPBt6 E6SlWwihMUNy8vIrNxs6iFeFmwagsRjIAM2SA= Received: by 10.103.252.5 with SMTP id e5mr1188899mus.54.1229014147393; Thu, 11 Dec 2008 08:49:07 -0800 (PST) Received: from ?163.117.183.49? ([163.117.183.49]) by mx.google.com with ESMTPS id j9sm4412405mue.49.2008.12.11.08.49.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Dec 2008 08:49:06 -0800 (PST) From: Ryuji Wakikawa To: Romain KUNTZ In-Reply-To: <4B8E03A1-432A-49F9-8DA0-98EF582620FD@lsiit.u-strasbg.fr> References: <491039B9.6090400@it.uc3m.es> <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> <200812111050.19715.julien.laganier.IETF@googlemail.com> <4B8E03A1-432A-49F9-8DA0-98EF582620FD@lsiit.u-strasbg.fr> Message-Id: <5ABF4AC2-F69D-4545-BEC8-B62E569FB020@gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 11 Dec 2008 17:49:02 +0100 X-Mailer: Apple Mail (2.929.2) Cc: Julien Laganier , mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Romain One more comment. The implicit and explicit modes cannot be switched dynamically, neither. Section 5.2 A Mobile Router MUST implement at least one mode and MAY implement both. In the latter case, local configuration on the Mobile Router decides which mode to use. This is out of scope for this document. If the Mobile Router Flag is set, the Home Registration Flag (H) MUST be set. If the Mobile Router has a valid binding cache entry at the Home Agent, subsequent Binding Updates for the same Home Address should have the same value as the value in the binding cache for the Mobile Router Flag (R). In explicit mode, the Mobile Router MUST include prefix information in all Binding Updates, including those sent to refresh existing binding cache entries, if it wants forwarding enabled for the corresponding Mobile Network Prefixes. regards, ryuji On 2008/12/11, at 17:36, Romain KUNTZ wrote: > Hi Ryuji, > > On 2008/12/11, at 17:26, Ryuji Wakikawa wrote: >> For this purpose, the mobile router needs to act as a RFC3775 >> compliant mobile host before starting DHCP-PD. Why? If there is no >> prefix, the mobile router cannot sends a NEMO-BU (i.e. R-flag set) to >> its Home Agent. If there is no valid prefix for the mobile router, HA >> returns BA with "Invalid Prefix" status value which is treated as the >> fatal error in RFC3963. > > I'd say the MR still sends a BU with the R-flag set and without the > MNP option, which will be considered as registration in Implicit > mode by the HA. > > Cheers, > romain > > > >> On 2008/12/11, at 10:50, Julien Laganier wrote: >> >>> We had this discussion for a long time abd it has concluded some >>> time >>> ago already: WG consensus is to use DHCP PD. >>> >>> (w/o questioning the value of optimizing RTTs for a procedure which >>> isn't in a critical path, e.g., handover) >>> >>> --julien >>> >>> On Thursday 11 December 2008, Yungui Wang wrote: >>>> Hello >>>> >>>> Here is one comment about using MR-HA tunnel for DHCP-PD. >>>> >>>> In this draft, the MR registration processing needs 3 round trip >>>> between MR and HA. i. BU to HA; (getting and binding MR_HoA) >>>> ii. DHCPv6 message over MR-HA tunnel. (getting MNP) >>>> iii. BU to HA; (binding MNP) >>>> While, if PD is combined within BU, it is only 1 round trip. >>>> >>>> From implementation of viewpoint, the later seems well done prior >>>> of >>>> the former. Maybe I have lost something, can anyone tell me the >>>> story >>>> why we gave up the latter in the new version? Thanks. >>>> >>>> B.R. >>>> Yungui >>>> >>>> >>>> ----- Original Message ----- >>>> From: marcelo bagnulo braun >>>> To: mext ; Julien Laganier ; Ralph Droms >>>> Sent: Tuesday, November 04, 2008 8:02 PM >>>> Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt >>>> >>>> >>>> Hi, >>>> >>>> We now start the WGLC for: >>>> >>>> DHCPv6 Prefix Delegation for NEMO >>>> draft-ietf-mext-nemo-pd-01.txt >>>> >>>> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt >>>> >>>> >>>> Please send comments about the draft till the November 19. >>>> >>>> Regards, Julien and marcelo >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> >>> -- >>> --julien >>> >>> [ New email address: julien.laganier.IETF@googlemail.com ] >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 11 09:05:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F9653A6C53; Thu, 11 Dec 2008 09:05:25 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 414F23A6C53 for ; Thu, 11 Dec 2008 09:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.821 X-Spam-Level: X-Spam-Status: No, score=-103.821 tagged_above=-999 required=5 tests=[AWL=-1.222, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUu0TBIlp2pD for ; Thu, 11 Dec 2008 09:05:23 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 32BF83A68F0 for ; Thu, 11 Dec 2008 09:05:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1229015117; x=1260551117; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20"Christian.Kaas-Petersen@tieto.com"=20,=0D=0A=20=20=20=20=20=20=20=20"me xt@ietf.org"=20|Date:=20Thu,=2011=20Dec=20 2008=2009:05:21=20-0800|Subject:=20RE:=20[MEXT]=20Subject :=20Multiple=20CoA=20draft=2010=20--=20two=20proposals=20 and=20some=0D=0A=09comments|Thread-Topic:=20[MEXT]=20Subj ect:=20Multiple=20CoA=20draft=2010=20--=20two=20proposals =20and=0D=0A=20some=09comments|Thread-Index:=20AclbmelbVE ZqE1eBQTKM/5HFe6iu1gAGJDlQ|Message-ID:=20<057632CE4CE10D4 5A1A3D6D19206C3A3D6E2973D@NASANEXMB08.na.qualcomm.com> |References:=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5460"=3B=20a=3D"13851026"; bh=KY7fOJFhdz8s25tR2LtNYj2iyBb2G/NhrY8ZDvOkYHE=; b=NEXQhkd+p6wOSwTojyBRPtv2I6djxXXQhCJ+FsdABhqA2/KOOUI3ca6M so3fs9hbKCzQHgTgM/FU7lUtys0pEgkhifTWu24t9HBJMAv4pSP34pm6C r0aokF0sC6IPUnlkGOPyAYQuAYn3gRr2kacBL/Up4KIoOb/92eUXFbFc0 Q=; X-IronPort-AV: E=McAfee;i="5100,188,5460"; a="13851026" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Dec 2008 09:05:17 -0800 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBBH5GOp023378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Dec 2008 09:05:17 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBBH5GZd023178 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 11 Dec 2008 09:05:16 -0800 (PST) Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.132]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Thu, 11 Dec 2008 09:05:16 -0800 From: "Giaretta, Gerardo" To: "Christian.Kaas-Petersen@tieto.com" , "mext@ietf.org" Date: Thu, 11 Dec 2008 09:05:21 -0800 Thread-Topic: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments Thread-Index: AclbmelbVEZqE1eBQTKM/5HFe6iu1gAGJDlQ Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D6E2973D@NASANEXMB08.na.qualcomm.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Christian, > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Christian.Kaas-Petersen@tieto.com > Sent: Thursday, December 11, 2008 6:08 AM > To: mext@ietf.org > Subject: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some > comments > > Assume a mobile node with home address HoA has two interfaces, > both attached to foreign links. After exchange of binding update > and binding acknowledgement, the home agent's binding cache (at > least the snip of it related to HoA) will look like this > > HoA, BID= 7, CoA1, other parameters like period of validity... > HoA, BID=10, CoA2, other parameters ... > > The draft uses HoA=2001:db8::EUI. > > Draft 10, section 5.1 states, that a BID value must be unique for a > home address and care-of address pair. This is satisfied above, but > it means, that the mobile station is not allowed to change the > second entry such that it also uses CoA1 as care-of address. > > Proposal: I think it has merit to be able to allow more than > one BID value per pair of home address and care-of address. Consider > flow bindings (defined in draft-ietf-mext-flow-binding) where > a flow may refer to a BID, and thus there is a simple way to move > flows between interfaces: only updating the binding cache. > I guess you mean only updating the CoA of the BCE/BID. I think this is a very valid point and it should be allowed. I did not realize this was not possible while reading the draft. I agree this is a necessary feature when coupling MCoA with flow bindings. Thanks Gerardo > Draft 10, section 4.2 (and other places) defines the H flag, which when > set means the mobile node wants to use both its home link and one or > more of its foreign links. The H flag is really an instruction to the > home agent, that in addition to all the bidings currently defined > is shall have an extra binding where packets shall not be tunneled. > > Proposal: The mobile node should be able to define a binding saying > > HoA BID=0 HoA > > This is a kind of default binding to be used when any of the other HoA- > bindings cannot be used. I think the H flag is an indirect way of > saying there is an extra binding, whereas the binding above is direct. > It also avoids continuously setting the H flag when both home link > and foreign links are active. > > > Other comments > > o Figure 1: In general I think it simpler for human readers to have > the elements of the primary key to a database given first, > therefore I suggest > > binding [2001:db8::EUI BID1 care-of address1] > > to be used allover. > > o Figure 4: looks as if position 6 is followed by position 17. > > o Section 4.2, O flag. The O flag is carried in an Binding > Identification mobility option, but really it a kind of global > value to be understood by the receiver as "clean all HoA entries". > If it really is too much to introduce a new mobility option, > isn't it enough to set the O flag in the first Binding > Identification mobility option? > > o Section 4.2, Care-of address and section 6.2 bullet 6, sub-bullet 2. > If the care-of address is omitted, the care-of address is to be > taken from the source address of the IPv6 header. > When the binding update arrives at the home agent, the > IPv6 header's source address is exactly the care-of > address used by the mobile node, but when the home agent is > actually able to understand the contents of the binding update, > then the IPv6 headers source address has been swapped with the > address found in the Destination Option extension header, > and thus the care-of address is now found in the Destination > Option extension header. > > o Section 5.6.2, bullet 2. The term link-local address is used, but I > think this should be changed to be like in all the other places, > using link-layer address. > > o Section 6.2, bullet 7, sub-bullet 1: I think the condition should > read > "If one of the 'O' flags is set, then all of the 'O' flags must be > set, else [MCOA MALFORMED] is returned." But as suggested above, > I don't think there is reason to enforce an all-or-none 'O' flags. > > o Section 8.2, para 2. The text says, that the IPv4 Address > Acknowledgement mobility option is included only if the mobile node > requested a home address. When I read > draft-ietf-mext-nemo-v4traversal, > section 4.2.1, the IPv4 Address Acknowledgement mobility option > is included always, indicating the home agent created a binding cache > entry for the IPv4 home address. > > 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 Dec 11 09:30: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 31DD828C10D; Thu, 11 Dec 2008 09:30:55 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF2E528C10D for ; Thu, 11 Dec 2008 09:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAPgW3NVWnt6 for ; Thu, 11 Dec 2008 09:30:53 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with SMTP id B56463A69A0 for ; Thu, 11 Dec 2008 09:30:52 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1229016644!26220199!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 3365 invoked from network); 11 Dec 2008 17:30:45 -0000 Received: from unknown (HELO motgate3.mot.com) (136.182.1.13) by server-2.tower-119.messagelabs.com with SMTP; 11 Dec 2008 17:30:45 -0000 Received: from il27exr01.cig.mot.com ([10.17.196.70]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id mBBHUiAi018082; Thu, 11 Dec 2008 10:30:44 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr01.cig.mot.com (8.13.1/Vontu) with SMTP id mBBHUi8U008340; Thu, 11 Dec 2008 11:30:44 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il27exr01.cig.mot.com (8.13.1/8.13.0) with ESMTP id mBBHUgMW008327; Thu, 11 Dec 2008 11:30:43 -0600 (CST) Message-ID: <49414E42.9040106@gmail.com> Date: Thu, 11 Dec 2008 18:30:42 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Ryuji Wakikawa References: <491039B9.6090400@it.uc3m.es> <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> <200812111050.19715.julien.laganier.IETF@googlemail.com> In-Reply-To: X-Antivirus: avast! (VPS 081210-0, 10/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ryuji Wakikawa wrote: > Hi Julien and Yungui, > > Actually, it's not only 3 round trip and is not optimization problem.. > This is a big issue of DHCP-PD. > > Let me explain the issue clearly. > > According to the NEMO-DHCP-PD spec, before receiving a prefix, > a mobile router must create a tunnel with its HA. Not sure about this necessity? Where does this nemo-dhcp-pd draft say so? If one considers the MR to co-locate a DHCP Relay with a DHCP Client (section 3.3) then the Relay would unicast non-tunnelled with the HA-DHCPServer (not multicast, and not tunnel) the DHCP messages. > For this purpose, the mobile router needs to act as a RFC3775 > compliant mobile host before starting DHCP-PD. Why? If there is no > prefix, the mobile router cannot sends a NEMO-BU (i.e. R-flag set) to > its Home Agent. Well the MR can send a BU with R-flag set without having a prefix allocated to it via DHCP-PD, by considering the NEMO implicit mode. IT is sufficient for the HA to know the prefix it is allocated to that MR. It is obvious that we disagree on the sequence of the exchanged messages (DHCP, BU/BAck) and I think we need to draw a diagram with the message exchanges that we consider. I could draw mine. Alex If there is no valid prefix for the mobile router, HA > returns BA with "Invalid Prefix" status value which is treated as the > fatal error in RFC3963. > > Well, RFC3963 allows for a mobile router to act as a mobile host, but > we didn't assume that a mobile router switches its mode between > RFC3775-mobile-host and RFC3963-mobile-router dynamically. > > For instance, RFC3963 said in section 6.2, > "If the Home Agent has a valid binding cache entry for the Mobile > Router, and if the Binding Update has the Mobile Router Flag (R) set > to a value different from that in the existing binding cache entry, > then the Home Agent MUST reject the Binding Update and send a Binding > Acknowledgement with status set to 139 (Registration type change > disallowed). However, if the Binding Update is a de-registration > Binding Update, the Home Agent ignores the value of the Mobile Router > Flag (R)." > > At the end, how the boostrapping goes? > > 1. MR acts as a MN and sends MIP6-BU (Rflag unset) to establish a > tunnel for DHCP-PD > 2. MR starting DHCP-PD > 3. After DHCP-PD completion, MR de-registers the RFC3775-binding > 4. MR sends NEMO-BU (R-flag finally set) for its mobile network prefix > acquired by DHCP-PD > > I don't think this is right way to go.... > > I now changed my mind that the use of BU/BA is more straightforward > for NEMO prefix delegation. > > ryuji > > > On 2008/12/11, at 10:50, Julien Laganier wrote: > >> We had this discussion for a long time abd it has concluded some time >> ago already: WG consensus is to use DHCP PD. >> >> (w/o questioning the value of optimizing RTTs for a procedure which >> isn't in a critical path, e.g., handover) >> >> --julien >> >> On Thursday 11 December 2008, Yungui Wang wrote: >>> Hello >>> >>> Here is one comment about using MR-HA tunnel for DHCP-PD. >>> >>> In this draft, the MR registration processing needs 3 round trip >>> between MR and HA. i. BU to HA; (getting and binding MR_HoA) >>> ii. DHCPv6 message over MR-HA tunnel. (getting MNP) >>> iii. BU to HA; (binding MNP) >>> While, if PD is combined within BU, it is only 1 round trip. >>> >>> From implementation of viewpoint, the later seems well done prior of >>> the former. Maybe I have lost something, can anyone tell me the story >>> why we gave up the latter in the new version? Thanks. >>> >>> B.R. >>> Yungui >>> >>> >>> ----- Original Message ----- >>> From: marcelo bagnulo braun >>> To: mext ; Julien Laganier ; Ralph Droms >>> Sent: Tuesday, November 04, 2008 8:02 PM >>> Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt >>> >>> >>> Hi, >>> >>> We now start the WGLC for: >>> >>> DHCPv6 Prefix Delegation for NEMO >>> draft-ietf-mext-nemo-pd-01.txt >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt >>> >>> >>> Please send comments about the draft till the November 19. >>> >>> Regards, Julien and marcelo >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> >> >> -- >> --julien >> >> [ New email address: julien.laganier.IETF@googlemail.com ] >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 11 09:34:57 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDEA628C1B5; Thu, 11 Dec 2008 09:34:57 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEBEC28C1B5 for ; Thu, 11 Dec 2008 09:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 a+uuEHjGcD0Y for ; Thu, 11 Dec 2008 09:34:56 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id DD1DC3A69A0 for ; Thu, 11 Dec 2008 09:34:55 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1229016888!7367215!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27783 invoked from network); 11 Dec 2008 17:34:48 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-153.messagelabs.com with SMTP; 11 Dec 2008 17:34:48 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBBHYlpq000166; Thu, 11 Dec 2008 10:34:47 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id mBBHYlWL021765; Thu, 11 Dec 2008 11:34:47 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id mBBHYkrc021741; Thu, 11 Dec 2008 11:34:46 -0600 (CST) Message-ID: <49414F35.6040305@gmail.com> Date: Thu, 11 Dec 2008 18:34:45 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Yungui Wang References: <491039B9.6090400@it.uc3m.es> <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> In-Reply-To: <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> X-Antivirus: avast! (VPS 081210-0, 10/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Yungui Wang wrote: > Hello > > Here is one comment about using MR-HA tunnel for DHCP-PD. > > In this draft, the MR registration processing needs 3 round trip > between MR and HA. i. BU to HA; (getting and binding MR_HoA) I think there's an error. RFC3775 MN and RFC3963 MR will not get any HoA with the BU, but yes indeed will bind that HoA to its current CoA, at the HA. > ii. DHCPv6 message over MR-HA tunnel. (getting MNP) I'm not sure the DHCPv6 messages need to happen through the tunnel, or maybe straight one-header DHCP messages. > iii. BU to HA; (binding MNP) While, if PD is combined within BU, it > is only 1 round trip. I see the optimization necessity, but as Julien and others already said I agree this would not need an optimization perspective since it happens at the beginning ('bootstrapping') unique phase, not upon each handover, thus not on a supposedly critical path. > From implementation of viewpoint, the later seems well done prior of > the former. Maybe I have lost something, can anyone tell me the > story why we gave up the latter in the new version? Thanks. I'm interested in implementation. Any implementation experience one may have of running DHCPv6 PD and Mobile IPv6/NEMOv6 is great to be reported here, please do so - what would your (someone's) implementation suggests? Alex > > B.R. Yungui > > > ----- Original Message ----- > > *From:* marcelo bagnulo braun *To:* mext > ; Julien Laganier > ; Ralph Droms > *Sent:* Tuesday, November 04, 2008 8:02 PM > *Subject:* [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt > > Hi, > > We now start the WGLC for: > > DHCPv6 Prefix Delegation for NEMO draft-ietf-mext-nemo-pd-01.txt > > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt > > > Please send comments about the draft till the November 19. > > Regards, Julien and marcelo > > > _______________________________________________ MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > ------------------------------------------------------------------------ > > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From lfuentesm@aguasandinas.cl Thu Dec 11 13:21:23 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 738A43A67F1 for ; Thu, 11 Dec 2008 13:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmXltgQROlVC for ; Thu, 11 Dec 2008 13:21:23 -0800 (PST) Received: from shpd-92-101-140-117.vologda.ru (shpd-92-101-140-117.vologda.ru [92.101.140.117]) by core3.amsl.com (Postfix) with SMTP id 413753A679F for ; Thu, 11 Dec 2008 13:21:21 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081211212122.413753A679F@core3.amsl.com> Date: Thu, 11 Dec 2008 13:21:21 -0800 (PST)
Visit site now!

From mext-bounces@ietf.org Thu Dec 11 14:08:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A92F23A67AB; Thu, 11 Dec 2008 14:08:51 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B5A83A67AB for ; Thu, 11 Dec 2008 14:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.077 X-Spam-Level: X-Spam-Status: No, score=-6.077 tagged_above=-999 required=5 tests=[AWL=0.521, 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 9xikGbiiNg54 for ; Thu, 11 Dec 2008 14:08:49 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id EB7583A66B4 for ; Thu, 11 Dec 2008 14:08:48 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mBBM8db28469; Thu, 11 Dec 2008 22:08:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Dec 2008 16:07:41 -0600 Message-ID: In-Reply-To: <200812100641.mBA6f9xA029247@ricky.india.internal.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Global Binding Revocation initiated by MAG Thread-Index: AclalCYuhfjQHuocScae7Wmc5lzMKABQuirA References: <200812100641.mBA6f9xA029247@ricky.india.internal.net> From: "Ahmad Muhanna" To: "Magesh Shanmugam" Cc: mext@ietf.org Subject: Re: [MEXT] Global Binding Revocation initiated by MAG X-BeenThere: mext@ietf.org X-Mailman-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="===============1864952059==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1864952059== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95BDC.E3E37155" This is a multi-part message in MIME format. ------_=_NextPart_001_01C95BDC.E3E37155 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Magesh, =20 Sorry for the late response. Had to travel for a short trip. =20 I see what you are saying here. May be what we need to do is to take one step back and look into the reason for the Global revocation. =20 The intention is to allow one of the PMIPv6 domain nodes (MAG or LMA) to inform the other to revoke all bindings that is served by these two nodes or a partial number of these binding, for example proxy MIP6 bindings that have their MN-ID which belong to a specific realm, e.g., (*@abc.com).=20 =20 When the 'G' bit is used for a partial Global revocation, "Revoking Node Local Policy", the draft requires that another identifier MUST be included in the BRI which is used to identify these proxy bindings. I believe that we do not have any problem in that one. Right? =20 When the 'G' bit is used for a Global revocation and in line with the above logic, we need to communicate the MAG-ID. I understand that currently we do not have a mobility option specific to carry MAG-ID, however, we defined a very specific scenario where the 'G' bit is set and the R. Trigger is set to "per-peer policy". Only in this case, the draft currently allow the MAG to include its ID in the MN-ID option. Sending the BRI and BRA is assumed to follow the exact procedure for PBU and PBA with respect to the source and dest. IP addresses. =20 On the other hand, I see your point of defining a default mechanism to be used by the received Node to identify all these proxy Bindings. IMO, we need probably to have a generic approach that applicable to all cases. for example, a MAG may have more than one pCoA with a specific LMA. As a suggestion, I would recommend, in this case ONLY that the pCoA always be included in the Alternate CoA option in the BRI. Additionally, when the MAG share more than one pCoA, the MAG MUST include each pCoA in a separate Alternate-CoA option. =20 Does sound acceptable?=20 =20 As a side note, implementations may have their own mechanism where the MAG-ID is somehow known to the LMA, for example, and that implementation would identify all of the proxy Binding that are served at that MAG using the MAG-ID, but that is out of scope. Regards,=20 Ahmad=20 =20 ________________________________ From: Magesh Shanmugam [mailto:mshanmugam@intellinet-india.com]=20 Sent: Wednesday, December 10, 2008 12:55 AM To: Muhanna, Ahmad (RICH1:2H10) Cc: mext@ietf.org Subject: Global Binding Revocation initiated by MAG =09 =09 Ahmad =20 In PMIPv6 domain, when MAG initiates Global Binding Revocation (G bit set), it will send the MAG identity in the MN-ID option (as per section 3.1 of binding-revocation draft-02). =20 As per RFC 5213, while creating Binding Cache Entry @ LMA, we have MN-ID, HNP(s), Proxy Care of Address, etc in the received PBU message which will be updated in the BC entry after validation. MAG-ID will not be stored in the Binding Cache Entry when individual binding session(s) are processed and validated by LMA. =20 When MAG triggers Global Binding Revocation, it will send the MAG-ID in the MN-ID option. Since LMA won't maintain the MAG-ID for each binding session (i.e. in BC entry),=20 it will be tough for the LMA to identify all the binding(s) from the specific MAG. =20 =20 Instead of having MAG-ID in the MN-ID option for Global Revocation, if we use Proxy Care of Address (through the source IP address of the BRI message or=20 Alternate Care of Address mobility option, if source address is different from proxy care of address), it will be easy for LMA to retrieve all the binding(s),=20 since Proxy Care of Address is stored in the Binding Cache entry. =20 Thanks S Magesh ------_=_NextPart_001_01C95BDC.E3E37155 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Magesh,
 
Sorry=20 for the late response. Had to travel for a short = trip.
 
I see=20 what you are saying here. May be what we need to do is to take one step = back and=20 look into the reason for the Global revocation.
 
The=20 intention is to allow one of the PMIPv6 domain nodes (MAG or LMA) to = inform the=20 other to revoke all bindings that is served by these two nodes or a = partial=20 number of these binding, for example proxy MIP6 bindings that have their = MN-ID=20 which belong to a specific realm, e.g., (*@abc.com).
 
When=20 the 'G' bit is used for a partial Global revocation, "Revoking Node = Local=20 Policy", the draft requires that another identifier MUST be included in = the BRI=20 which is used to identify these proxy bindings. I believe that we do not = have=20 any problem in that one. Right?
 
When=20 the 'G' bit is used for a Global revocation and in line with the above = logic, we=20 need to communicate the MAG-ID. I understand that currently we do not = have a=20 mobility option specific to carry MAG-ID, however, we defined a very = specific=20 scenario where the 'G' bit is set and the R. Trigger is set to "per-peer = policy". Only in this case, the draft currently allow the MAG to include = its ID=20 in the MN-ID option. Sending the BRI and BRA is assumed to follow the = exact=20 procedure for PBU and PBA with respect to the source and dest. IP=20 addresses.
 
On the=20 other hand, I see your point of defining a default mechanism to be used = by the=20 received Node to identify all these proxy Bindings. IMO, we need = probably to=20 have a generic approach that applicable to all cases. for example, a MAG = may=20 have more than one pCoA with a specific LMA. As a suggestion, I would = recommend,=20 in this case ONLY that the pCoA always be included in the Alternate = CoA=20 option in the BRI. Additionally, when the MAG share more than one = pCoA, the=20 MAG MUST include each pCoA in a separate Alternate-CoA=20 option.
 
Does sound acceptable?=20
 
As a=20 side note, implementations may have their own mechanism where the MAG-ID = is=20 somehow known to the LMA, for example, and that implementation would = identify=20 all of the proxy Binding that are served at that MAG using the = MAG-ID, but=20 that is out of scope.

Regards, =
Ahmad

 

From: Magesh Shanmugam=20 [mailto:mshanmugam@intellinet-india.com]
Sent: Wednesday, = December=20 10, 2008 12:55 AM
To: Muhanna, Ahmad = (RICH1:2H10)
Cc:=20 mext@ietf.org
Subject: Global Binding Revocation initiated = by=20 MAG

Ahmad
 
In = PMIPv6 domain,=20 when MAG initiates Global Binding Revocation (G bit set), it will send = the MAG=20 identity in the MN-ID option (as per section 3.1 of binding-revocation = draft-02).
 
As = per RFC 5213,=20 while creating Binding Cache Entry @ LMA, we have MN-ID, HNP(s), Proxy = Care of=20 Address, etc in the received PBU message which will be updated in=20 the
BC = entry after=20 validation.  MAG-ID will not be stored in the Binding Cache Entry = when=20 individual binding session(s) are processed and validated by = LMA. =20
When = MAG triggers=20 Global=20 Binding Revocation, it will send the MAG-ID in the MN-ID option.  = Since=20 LMA won't maintain the MAG-ID for each binding session (i.e. in BC = entry),=20
it = will be tough=20 for the LMA to identify all the binding(s) from the specific MAG. =20
 
Instead of having=20 MAG-ID in the MN-ID option for Global Revocation, if we use Proxy Care = of=20 Address (through the source IP address of the BRI message or=20
Alternate Care of=20 Address mobility option, if source address is different from proxy = care of=20 address), it will be easy for LMA to retrieve all the binding(s),=20
since Proxy Care=20 of Address is stored in the Binding Cache entry.
 
Thanks
S=20 Magesh
------_=_NextPart_001_01C95BDC.E3E37155-- --===============1864952059== 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 --===============1864952059==-- From kowalew@agemont.it Thu Dec 11 15:32:22 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AC873A699C for ; Thu, 11 Dec 2008 15:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.871 X-Spam-Level: *** X-Spam-Status: No, score=3.871 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CLUBINTERNET=0.781, HELO_EQ_DSL=1.129, HELO_EQ_FR=0.35, HOST_EQ_CLUBINTERNET=0.663, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2cdcDOcXGe0 for ; Thu, 11 Dec 2008 15:32:21 -0800 (PST) Received: from lya14-1-87-88-1-227.dsl.club-internet.fr (lya14-1-87-88-1-227.dsl.club-internet.fr [87.88.1.227]) by core3.amsl.com (Postfix) with SMTP id 2EB163A6A77 for ; Thu, 11 Dec 2008 15:32:19 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081211233220.2EB163A6A77@core3.amsl.com> Date: Thu, 11 Dec 2008 15:32:19 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mext-bounces@ietf.org Thu Dec 11 17:34: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 BDF0E3A6ABC; Thu, 11 Dec 2008 17:34:37 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A2A3A6ABC for ; Thu, 11 Dec 2008 17:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.143 X-Spam-Level: X-Spam-Status: No, score=-6.143 tagged_above=-999 required=5 tests=[AWL=0.456, 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 OwgUYE-sqXly for ; Thu, 11 Dec 2008 17:34:34 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id AE40E3A6A19 for ; Thu, 11 Dec 2008 17:34:34 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mBC1YJc29910; Fri, 12 Dec 2008 01:34:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Dec 2008 19:34:05 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-mext-binding-revocation-02 Thread-Index: AclbLn3taqHuU6TUSgeN3dxQhl2ykQArrD7g References: From: "Ahmad Muhanna" To: "Stupar, Patrick" Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Patrick, Thanks for your review. Please see responses inline. Regards, Ahmad > -----Original Message----- > From: Stupar, Patrick [mailto:pstupar@qualcomm.com] > Sent: Wednesday, December 10, 2008 7:19 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext@ietf.org > Subject: Comments on draft-ietf-mext-binding-revocation-02 > > Hi Ahmad, > > I have reviewed binding revocation draft and have the > following comments/questions. > > - In MIPv6, Binding Update and Binding Ack have two different > MH type values. Why isn't the same approach taken for BRI and > BRA and only one value is used? [Ahmad] This was discussed on the mailing list for a long time and agreed that using one MH type will help in preserving the MH type space. I believe the "Heartbeat Mechanism for PMIPv6" is a wg doc in Netlmm and use one MH type for the Request and Response. On the other hand, do see an issue or problem in having a single MH type for both messages? > > - BRI has a revocation trigger field which is used for two > main usages. > One is the provisioning of the reason why the revocation was > sent (e.g. > inter-MAG handoff) and the other is related to specific > binding revocation procedures (e.g. IPV4 HoA Binding only, > Per-Peer Policy). I think it would be cleaner if the two > concepts remain separated in the messages, for instance > defining additional flags for Per-peer policy or > IPv4 HoA Binding only. [Ahmad] I see what you are saying. However, as you said, the Revocation Trigger field is defined to give the reason which caused the revoking node to send the BRI message. Thus far, I believe all of the defined values are inline with that definition or reasoning. For example: When the LMA sets the R. Trigger value to "IPv4 HoA Binding Only" it means that the reason behind sending this BRI message is to revoke the IPv4 HoA address in the case that the MN is assigned two proxy HoA(v4 & v6) for the same pCoA. I do not see this as a policy decision, because it is no difference from the MAG sending a BRI with R. Trigger value is set to for example, "Access Network Session Termination" As for the R. Trigger value of "Per-Peer Policy", This is only restricted to Global Revocation when the (G) bit is set. I still believe that "Per-Peer policy" also indicate the reason that allowed the LMA to send this Global BRI. Do you have a different name for this R. Trigger value that would fit better? > > - In the draft you refer to MAG identity, where is this term > defined? I wasn't able to find it in RFC 5213. [Ahmad] Actually, under section 4.1. "Peer Authorization Database (PAD) Example Entries", you can find the MAG-ID is defined there as mag_identity_1. It is the same concept here. However, I agree that we do not have a mobility option which is specific for carrying MAG-ID but the draft is using the MN-ID in a very specific scenario. How the LMA would check if this MAG is authorized for Global revocation is out of scope. > > > Some other comments related to specific sections: > > - page 21: in the first section after the bullet list, there > is the following sentence: > "As described in Section 7.3, the LMA SHOULD retransmit this BRI to > the MAG before deleting the mobile node IP tunnel to the mobile > access gateway until it receives a matching Binding Revocation > Acknowledgement or the BRIMaxRetransmitNumber is reached. " > But this doesn't always apply, e.g. in case of inter-mag > handoffs. What am I missing? [Ahmad] Yes, I see what you are saying here. It seems that the text needs some tweaking. Do you have any suggestion? > > - why is the A bit setting mandatory in case of IPv4 HoA > binding only revocation? [Ahmad] May be if you tell me why not, we could change it? > > - section 10.1.1: > "BRI MUST be formatted as in Section 6.1 and if the (P) bit is set, > the mobile access gateway must validate that the > impacted binding > have the proxy binding flag set." > MAG is not supposed to have any proxy binding flag or is it? > How can it validate this flag? [Ahmad] Good catch. There is another incident below it too. What about the following text for both bullets: " o BRI MUST be formatted as in Section 6.1 and the (P) bit is set. o If the Global (G) bit is set and the Revocation Trigger field is set to "Per-Peer policy", the mobile access gateway identify all bindings that are registered at the LMA and hosted at the MAG. This Binding Revocation Indication does not include any other mobility options. In this case, the MAG MUST send a BRA with the appropriate status code to the LMA. " > > > -section 11.1 > " If the Acknowledgement (A) bit is set in the Binding Revocation > Indication and the MN has the BCE in registered state, > the mobile > node MUST send a Binding Revocation Acknowledgement." > > MN has no BCE, it has a binding update list. [Ahmad] Right. Thx. What about the following: o If the Acknowledgement (A) bit is set in the Binding Revocation Indication and the MN has a Binding Update List entry for the source of the BRI message, the mobile node MUST send a Binding Revocation Acknowledgement. However, in all other cases when the (A) bit is set in the BRI, the mobile node SHOULD send a Binding Revocation Acknowledgement. In all cases, the mobile node MUST follow Section 11.2 when send a BRA using the appropriate status code. > > -section 11.1 > "If the Revocation Trigger field value is "Administrative Reason", > the mobile node MUST NOT try to re-register with the home agent > before contacting its home operator." > > I don't think that BRI specs have to mandate the MN to > contact the home operator, the text at the end of section > 11.1 is enough IMO. > [Ahmad] I see your point, It seems a very strong requirement and for a well behaved MN implementation, it may not be a problem to remove the whole bullet. However, for a non-well behaved MN, it may be necessary to keep something. What about if we demote MUST NOT to SHOULD NOT. Would that work? NEW TEXT: o If the Revocation Trigger field value is "Administrative Reason", the mobile node SHOULD NOT try to re-register with the home agent before contacting its home operator. TEXT at end of 11.1 that Patrick is referring to: The Revocation Trigger field value in the received Binding Revocation Indication could be used by the mobile node to define what action the mobile node could do to be able to register again and receive its IP mobility service, e.g. contacting its home operator. > I have some typos and editorial corrections as well, I will > send them off-list. [Ahmad] Please send them. Thanks for your review and good comments! > > Regards, > > Patrick > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 11 18:30: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 A82C63A6AF2; Thu, 11 Dec 2008 18:30:15 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD5363A6AA6 for ; Thu, 11 Dec 2008 18:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAfA9EsspT52 for ; Thu, 11 Dec 2008 18:30:12 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 8621F3A67EA for ; Thu, 11 Dec 2008 18:30:12 -0800 (PST) Received: by qyk4 with SMTP id 4so1473306qyk.13 for ; Thu, 11 Dec 2008 18:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=FZkQ9JS2k4gXhBGNqUGtOrz/8+uzjX38wPkM1XshII0=; b=PTez2U5iZ9/5xxDnd7oKNeJvY7Q4v+iSys/eapAudXLmW6mCd+C4OMhS1+fKYSQokB bJ1dl0Ow6urd9YKzEXTQKoLf6Q7k4w15iqGmq7YNtzYA4ZX2v6yMyoSX9MyMalyh3ejp Hk0xRAbBT6n0rOwXNNJ43E02L7Y/4ywFBafuo= 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=cIOfDeJeINNpEEzlAE0IRSNJTqJfhe5Cc0JLNkPdkpZwpOjT06ek4MdcLMpgzZFdgE ztFdWZoErgHdJ/wjgl58e1Shz2kGUJtLvAfJPtHW02pJJf39zvlM4IcWQFFQXHJGqHPs ck13fkrRsUNkwRCh9oDBaNAnTFcr6T7vryUY0= Received: by 10.214.10.20 with SMTP id 20mr4626284qaj.158.1229049003742; Thu, 11 Dec 2008 18:30:03 -0800 (PST) Received: by 10.215.14.1 with HTTP; Thu, 11 Dec 2008 18:30:03 -0800 (PST) Message-ID: Date: Thu, 11 Dec 2008 18:30:03 -0800 From: "fan zhao" To: "Alexandru Petrescu" In-Reply-To: <49414E42.9040106@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <491039B9.6090400@it.uc3m.es> <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> <200812111050.19715.julien.laganier.IETF@googlemail.com> <49414E42.9040106@gmail.com> Cc: Julien Laganier , mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Alex, Please see below. On Thu, Dec 11, 2008 at 9:30 AM, Alexandru Petrescu wrote: > Ryuji Wakikawa wrote: >> >> Hi Julien and Yungui, >> >> Actually, it's not only 3 round trip and is not optimization problem.. >> This is a big issue of DHCP-PD. >> >> Let me explain the issue clearly. >> >> According to the NEMO-DHCP-PD spec, before receiving a prefix, >> a mobile router must create a tunnel with its HA. > > Not sure about this necessity? Where does this nemo-dhcp-pd draft say so? Please see section 3.2. Use of MR-HA tunnel for DHCPv6 messages. > > If one considers the MR to co-locate a DHCP Relay with a DHCP Client > (section 3.3) then the Relay would unicast non-tunnelled with the > HA-DHCPServer (not multicast, and not tunnel) the DHCP messages. > >> For this purpose, the mobile router needs to act as a RFC3775 >> compliant mobile host before starting DHCP-PD. Why? If there is no >> prefix, the mobile router cannot sends a NEMO-BU (i.e. R-flag set) to >> its Home Agent. > > Well the MR can send a BU with R-flag set without having a prefix allocated > to it via DHCP-PD, by considering the NEMO implicit mode. IT is sufficient > for the HA to know the prefix it is allocated to that MR. I think Ryuji has addressed this in his previous emails. > > It is obvious that we disagree on the sequence of the exchanged messages > (DHCP, BU/BAck) and I think we need to draw a diagram with the message > exchanges that we consider. I could draw mine. Please do. Thanks a lot. Sincerely, fan > > Alex > > If there is no valid prefix for the mobile router, HA >> >> returns BA with "Invalid Prefix" status value which is treated as the >> fatal error in RFC3963. >> >> Well, RFC3963 allows for a mobile router to act as a mobile host, but >> we didn't assume that a mobile router switches its mode between >> RFC3775-mobile-host and RFC3963-mobile-router dynamically. >> >> For instance, RFC3963 said in section 6.2, >> "If the Home Agent has a valid binding cache entry for the Mobile >> Router, and if the Binding Update has the Mobile Router Flag (R) set >> to a value different from that in the existing binding cache entry, >> then the Home Agent MUST reject the Binding Update and send a Binding >> Acknowledgement with status set to 139 (Registration type change >> disallowed). However, if the Binding Update is a de-registration >> Binding Update, the Home Agent ignores the value of the Mobile Router >> Flag (R)." >> >> At the end, how the boostrapping goes? >> >> 1. MR acts as a MN and sends MIP6-BU (Rflag unset) to establish a >> tunnel for DHCP-PD >> 2. MR starting DHCP-PD >> 3. After DHCP-PD completion, MR de-registers the RFC3775-binding >> 4. MR sends NEMO-BU (R-flag finally set) for its mobile network prefix >> acquired by DHCP-PD >> >> I don't think this is right way to go.... >> >> I now changed my mind that the use of BU/BA is more straightforward >> for NEMO prefix delegation. >> >> ryuji >> >> >> On 2008/12/11, at 10:50, Julien Laganier wrote: >> >>> We had this discussion for a long time abd it has concluded some time >>> ago already: WG consensus is to use DHCP PD. >>> >>> (w/o questioning the value of optimizing RTTs for a procedure which >>> isn't in a critical path, e.g., handover) >>> >>> --julien >>> >>> On Thursday 11 December 2008, Yungui Wang wrote: >>>> >>>> Hello >>>> >>>> Here is one comment about using MR-HA tunnel for DHCP-PD. >>>> >>>> In this draft, the MR registration processing needs 3 round trip >>>> between MR and HA. i. BU to HA; (getting and binding MR_HoA) >>>> ii. DHCPv6 message over MR-HA tunnel. (getting MNP) >>>> iii. BU to HA; (binding MNP) >>>> While, if PD is combined within BU, it is only 1 round trip. >>>> >>>> From implementation of viewpoint, the later seems well done prior of >>>> the former. Maybe I have lost something, can anyone tell me the story >>>> why we gave up the latter in the new version? Thanks. >>>> >>>> B.R. >>>> Yungui >>>> >>>> >>>> ----- Original Message ----- >>>> From: marcelo bagnulo braun >>>> To: mext ; Julien Laganier ; Ralph Droms >>>> Sent: Tuesday, November 04, 2008 8:02 PM >>>> Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt >>>> >>>> >>>> Hi, >>>> >>>> We now start the WGLC for: >>>> >>>> DHCPv6 Prefix Delegation for NEMO >>>> draft-ietf-mext-nemo-pd-01.txt >>>> >>>> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt >>>> >>>> >>>> Please send comments about the draft till the November 19. >>>> >>>> Regards, Julien and marcelo >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> >>> -- >>> --julien >>> >>> [ New email address: julien.laganier.IETF@googlemail.com ] >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 11 18:43:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58A7A3A69F4; Thu, 11 Dec 2008 18:43:54 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D87B3A69F4 for ; Thu, 11 Dec 2008 18:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.71 X-Spam-Level: X-Spam-Status: No, score=0.71 tagged_above=-999 required=5 tests=[AWL=1.204, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 WT6C-CWXosTc for ; Thu, 11 Dec 2008 18:43:46 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 6C8683A67DB for ; Thu, 11 Dec 2008 18:43:45 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KBQ002FESWG44@szxga01-in.huawei.com> for mext@ietf.org; Fri, 12 Dec 2008 10:43:28 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KBQ002OQSWGC3@szxga01-in.huawei.com> for mext@ietf.org; Fri, 12 Dec 2008 10:43:28 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KBQ00D7XSWCPE@szxml04-in.huawei.com> for mext@ietf.org; Fri, 12 Dec 2008 10:43:28 +0800 (CST) Date: Fri, 12 Dec 2008 10:43:24 +0800 From: Yungui Wang To: Ryuji Wakikawa , Julien Laganier Message-id: <00f401c95c03$67a1bd00$150ca40a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <491039B9.6090400@it.uc3m.es> <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> <200812111050.19715.julien.laganier.IETF@googlemail.com> Cc: mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2024979224==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============2024979224== Content-type: multipart/alternative; boundary="Boundary_(ID_ainypSXzKgERtQN8CxtxcQ)" This is a multi-part message in MIME format. --Boundary_(ID_ainypSXzKgERtQN8CxtxcQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Ryuji and all Thanks for your detailed explanation. My concern is MNP and MR_HoA can be assigned to MR at the same time, special for the aggregated prefix. While, in the mip-split case, the HoA is assigned to MR through BU/BA procedure. Thus, the MNP assigned through BU/BA procedure can be supported too. That's my simple logic. Complying with rfc3775 which allows the HoA assignment via either split or integrated bootstrapping, maybe we could consider to fix rfc3963 and let it more open - not limit which mechanism used for PD. B.R. Yungui ----- Original Message ----- From: Ryuji Wakikawa To: Julien Laganier Cc: Yungui Wang ; mext ; Sri Gundavelli ; Vijay Devarapalli Sent: Friday, December 12, 2008 12:26 AM Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt Hi Julien and Yungui, Actually, it's not only 3 round trip and is not optimization problem.. This is a big issue of DHCP-PD. Let me explain the issue clearly. According to the NEMO-DHCP-PD spec, before receiving a prefix, a mobile router must create a tunnel with its HA. For this purpose, the mobile router needs to act as a RFC3775 compliant mobile host before starting DHCP-PD. Why? If there is no prefix, the mobile router cannot sends a NEMO-BU (i.e. R-flag set) to its Home Agent. If there is no valid prefix for the mobile router, HA returns BA with "Invalid Prefix" status value which is treated as the fatal error in RFC3963. Well, RFC3963 allows for a mobile router to act as a mobile host, but we didn't assume that a mobile router switches its mode between RFC3775-mobile-host and RFC3963-mobile-router dynamically. For instance, RFC3963 said in section 6.2, "If the Home Agent has a valid binding cache entry for the Mobile Router, and if the Binding Update has the Mobile Router Flag (R) set to a value different from that in the existing binding cache entry, then the Home Agent MUST reject the Binding Update and send a Binding Acknowledgement with status set to 139 (Registration type change disallowed). However, if the Binding Update is a de-registration Binding Update, the Home Agent ignores the value of the Mobile Router Flag (R)." At the end, how the boostrapping goes? 1. MR acts as a MN and sends MIP6-BU (Rflag unset) to establish a tunnel for DHCP-PD 2. MR starting DHCP-PD 3. After DHCP-PD completion, MR de-registers the RFC3775-binding 4. MR sends NEMO-BU (R-flag finally set) for its mobile network prefix acquired by DHCP-PD I don't think this is right way to go.... I now changed my mind that the use of BU/BA is more straightforward for NEMO prefix delegation. ryuji On 2008/12/11, at 10:50, Julien Laganier wrote: > We had this discussion for a long time abd it has concluded some time > ago already: WG consensus is to use DHCP PD. > > (w/o questioning the value of optimizing RTTs for a procedure which > isn't in a critical path, e.g., handover) > > --julien > > On Thursday 11 December 2008, Yungui Wang wrote: >> Hello >> >> Here is one comment about using MR-HA tunnel for DHCP-PD. >> >> In this draft, the MR registration processing needs 3 round trip >> between MR and HA. i. BU to HA; (getting and binding MR_HoA) >> ii. DHCPv6 message over MR-HA tunnel. (getting MNP) >> iii. BU to HA; (binding MNP) >> While, if PD is combined within BU, it is only 1 round trip. >> >> From implementation of viewpoint, the later seems well done prior of >> the former. Maybe I have lost something, can anyone tell me the story >> why we gave up the latter in the new version? Thanks. >> >> B.R. >> Yungui >> >> >> ----- Original Message ----- >> From: marcelo bagnulo braun >> To: mext ; Julien Laganier ; Ralph Droms >> Sent: Tuesday, November 04, 2008 8:02 PM >> Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt >> >> >> Hi, >> >> We now start the WGLC for: >> >> DHCPv6 Prefix Delegation for NEMO >> draft-ietf-mext-nemo-pd-01.txt >> >> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt >> >> >> Please send comments about the draft till the November 19. >> >> Regards, Julien and marcelo >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > > > -- > --julien > > [ New email address: julien.laganier.IETF@googlemail.com ] > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext --Boundary_(ID_ainypSXzKgERtQN8CxtxcQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Ryuji and all
 
Thanks for your detailed explanation.
 
My concern is MNP and MR_HoA can be assigned to MR at the same time, special for the aggregated prefix. While, in the mip-split case, the HoA is assigned to MR through BU/BA procedure.  Thus, the MNP assigned through BU/BA procedure can be supported too. That's my simple logic.
Complying with rfc3775 which allows the HoA assignment via either split or integrated bootstrapping,  maybe we could consider to fix rfc3963 and let it more open - not limit which mechanism used for PD. 
 
 
B.R.
Yungui
 
----- Original Message -----
Sent: Friday, December 12, 2008 12:26 AM
Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt

Hi Julien and Yungui,

Actually, it's not only 3 round trip and is not optimization problem..
This is a big issue of DHCP-PD.

Let me explain the issue clearly.

According to the NEMO-DHCP-PD spec, before receiving a prefix,
a mobile router must create a tunnel with its HA.

For this purpose, the mobile router needs to act as a RFC3775
compliant mobile host before starting DHCP-PD.  Why? If there is no
prefix, the mobile router cannot sends a NEMO-BU (i.e. R-flag set) to
its Home Agent. If there is no valid prefix for the mobile router, HA
returns BA with "Invalid Prefix" status value which is treated as the
fatal error in RFC3963.

Well, RFC3963 allows for a mobile router to act as a mobile host, but
we didn't assume that a mobile router switches its mode between
RFC3775-mobile-host and RFC3963-mobile-router dynamically.

For instance, RFC3963 said in section 6.2,
"If the Home Agent has a valid binding cache entry for the Mobile
Router, and if the Binding Update has the Mobile Router Flag (R) set
to a value different from that in the existing binding cache entry,
then the Home Agent MUST reject the Binding Update and send a Binding
Acknowledgement with status set to 139 (Registration type change
disallowed). However, if the Binding Update is a de-registration
Binding Update, the Home Agent ignores the value of the Mobile Router
Flag (R)."

At the end, how the boostrapping goes?

1. MR acts as a MN and sends MIP6-BU (Rflag unset) to establish a
    tunnel for DHCP-PD
2. MR starting DHCP-PD
3. After DHCP-PD completion, MR de-registers the RFC3775-binding
4. MR sends NEMO-BU (R-flag finally set) for its mobile network prefix
    acquired by DHCP-PD

I don't think this is right way to go....

I now changed my mind that the use of BU/BA is more straightforward
for NEMO prefix delegation.

ryuji


On 2008/12/11, at 10:50, Julien Laganier wrote:

> We had this discussion for a long time abd it has concluded some time
> ago already: WG consensus is to use DHCP PD.
>
> (w/o questioning the value of optimizing RTTs for a procedure which
> isn't in a critical path, e.g., handover)
>
> --julien
>
> On Thursday 11 December 2008, Yungui Wang wrote:
>> Hello
>>
>> Here is one comment about using MR-HA tunnel for DHCP-PD.
>>
>> In this draft, the MR registration processing needs 3 round trip
>> between MR and HA. i. BU to HA; (getting and binding MR_HoA)
>> ii. DHCPv6 message over MR-HA tunnel. (getting MNP)
>> iii. BU to HA; (binding MNP)
>> While, if PD is combined within BU, it is only 1 round trip.
>>
>> From implementation of viewpoint, the later seems well done prior of
>> the former. Maybe I have lost something, can anyone tell me the story
>> why we gave up the latter in the new version? Thanks.
>>
>> B.R.
>> Yungui
>>
>>
>> ----- Original Message -----
>>  From: marcelo bagnulo braun
>>  To: mext ; Julien Laganier ; Ralph Droms
>>  Sent: Tuesday, November 04, 2008 8:02 PM
>>  Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt
>>
>>
>>  Hi,
>>
>>  We now start the WGLC for:
>>
>>  DHCPv6 Prefix Delegation for NEMO
>>  draft-ietf-mext-nemo-pd-01.txt
>>
>>  http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt
>>
>>
>>  Please send comments about the draft till the November 19.
>>
>>  Regards, Julien and marcelo
>>
>>
>>  _______________________________________________
>>  MEXT mailing list
>>  MEXT@ietf.org
>>  https://www.ietf.org/mailman/listinfo/mext
>
>
>
> --
> --julien
>
> [ New email address: julien.laganier.IETF@googlemail.com ]
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext

--Boundary_(ID_ainypSXzKgERtQN8CxtxcQ)-- --===============2024979224== 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 --===============2024979224==-- From mext-bounces@ietf.org Thu Dec 11 18:49:28 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34F73A67DB; Thu, 11 Dec 2008 18:49:28 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD2BA3A67DB for ; Thu, 11 Dec 2008 18:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqrvh1TlP07Z for ; Thu, 11 Dec 2008 18:49:26 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 933B93A6774 for ; Thu, 11 Dec 2008 18:49:26 -0800 (PST) Received: by qyk4 with SMTP id 4so1478503qyk.13 for ; Thu, 11 Dec 2008 18:49:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=9WBQQeTEWfr3nXBKyp8eiCI+bi0vYcoL8IeNV/k7R8I=; b=dGHFnQJMNw6bpBikuoYaE9tfEgi4ljvILtXh6MQfKNSEa/Wj7dV5DwQ139XjHe0BOP rJhFKRKBFhiiP7uhF1JP9buJtAaLPutsPNGNh+6spSE6mav6Zzvsrjyjl2T+Iqz28fqn GCeAS6VRDKS5+chqvyJEu0YVJABMHyWnEAezc= 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=Ddo+XmTDOT1GpF/pzOHbL20qXH+8yBJo3EgFAR7wHr9NtDeVhygCtUtJqcQ9daDqRB TR7GKD6sBPiQihE9YOwYmN2tW+CVD49yLnoYRmZc62zubt60uIJAsv9xX7iTHbRzZhSt UVUOyFH3jAVIhEwhNRwcB/t1ctkpcCOqizL58= Received: by 10.214.78.19 with SMTP id a19mr4626587qab.268.1229050159938; Thu, 11 Dec 2008 18:49:19 -0800 (PST) Received: by 10.215.14.1 with HTTP; Thu, 11 Dec 2008 18:49:19 -0800 (PST) Message-ID: Date: Thu, 11 Dec 2008 18:49:19 -0800 From: "fan zhao" To: "Yungui Wang" In-Reply-To: <00f401c95c03$67a1bd00$150ca40a@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline References: <491039B9.6090400@it.uc3m.es> <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> <200812111050.19715.julien.laganier.IETF@googlemail.com> <00f401c95c03$67a1bd00$150ca40a@china.huawei.com> Cc: Julien Laganier , mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Yungui, The HoA is assigned to the mobile node during the IPsec SA establishment procedure. Please see RFC 4877 and RFC 5026. I agree with you that it is logical to assign the MNP and MR_HoA to MR at the same time. Sincerely, fan On Thu, Dec 11, 2008 at 6:43 PM, Yungui Wang wrote: > Hi Ryuji and all > > Thanks for your detailed explanation. > > My concern is MNP and MR_HoA can be assigned to MR at the same time, special > for the aggregated prefix. While, in the mip-split case, the HoA is assigned > to MR through BU/BA procedure. Thus, the MNP assigned through BU/BA > procedure can be supported too. That's my simple logic. > Complying with rfc3775 which allows the HoA assignment via either split or > integrated bootstrapping, maybe we could consider to fix rfc3963 and let it > more open - not limit which mechanism used for PD. > > > B.R. > Yungui > > ----- Original Message ----- > > From: Ryuji Wakikawa > To: Julien Laganier > Cc: Yungui Wang ; mext ; Sri Gundavelli ; Vijay Devarapalli > Sent: Friday, December 12, 2008 12:26 AM > Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for > draft-ietf-mext-nemo-pd-01.txt > Hi Julien and Yungui, > > Actually, it's not only 3 round trip and is not optimization problem.. > This is a big issue of DHCP-PD. > > Let me explain the issue clearly. > > According to the NEMO-DHCP-PD spec, before receiving a prefix, > a mobile router must create a tunnel with its HA. > > For this purpose, the mobile router needs to act as a RFC3775 > compliant mobile host before starting DHCP-PD. Why? If there is no > prefix, the mobile router cannot sends a NEMO-BU (i.e. R-flag set) to > its Home Agent. If there is no valid prefix for the mobile router, HA > returns BA with "Invalid Prefix" status value which is treated as the > fatal error in RFC3963. > > Well, RFC3963 allows for a mobile router to act as a mobile host, but > we didn't assume that a mobile router switches its mode between > RFC3775-mobile-host and RFC3963-mobile-router dynamically. > > For instance, RFC3963 said in section 6.2, > "If the Home Agent has a valid binding cache entry for the Mobile > Router, and if the Binding Update has the Mobile Router Flag (R) set > to a value different from that in the existing binding cache entry, > then the Home Agent MUST reject the Binding Update and send a Binding > Acknowledgement with status set to 139 (Registration type change > disallowed). However, if the Binding Update is a de-registration > Binding Update, the Home Agent ignores the value of the Mobile Router > Flag (R)." > > At the end, how the boostrapping goes? > > 1. MR acts as a MN and sends MIP6-BU (Rflag unset) to establish a > tunnel for DHCP-PD > 2. MR starting DHCP-PD > 3. After DHCP-PD completion, MR de-registers the RFC3775-binding > 4. MR sends NEMO-BU (R-flag finally set) for its mobile network prefix > acquired by DHCP-PD > > I don't think this is right way to go.... > > I now changed my mind that the use of BU/BA is more straightforward > for NEMO prefix delegation. > > ryuji > > > On 2008/12/11, at 10:50, Julien Laganier wrote: > >> We had this discussion for a long time abd it has concluded some time >> ago already: WG consensus is to use DHCP PD. >> >> (w/o questioning the value of optimizing RTTs for a procedure which >> isn't in a critical path, e.g., handover) >> >> --julien >> >> On Thursday 11 December 2008, Yungui Wang wrote: >>> Hello >>> >>> Here is one comment about using MR-HA tunnel for DHCP-PD. >>> >>> In this draft, the MR registration processing needs 3 round trip >>> between MR and HA. i. BU to HA; (getting and binding MR_HoA) >>> ii. DHCPv6 message over MR-HA tunnel. (getting MNP) >>> iii. BU to HA; (binding MNP) >>> While, if PD is combined within BU, it is only 1 round trip. >>> >>> From implementation of viewpoint, the later seems well done prior of >>> the former. Maybe I have lost something, can anyone tell me the story >>> why we gave up the latter in the new version? Thanks. >>> >>> B.R. >>> Yungui >>> >>> >>> ----- Original Message ----- >>> From: marcelo bagnulo braun >>> To: mext ; Julien Laganier ; Ralph Droms >>> Sent: Tuesday, November 04, 2008 8:02 PM >>> Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt >>> >>> >>> Hi, >>> >>> We now start the WGLC for: >>> >>> DHCPv6 Prefix Delegation for NEMO >>> draft-ietf-mext-nemo-pd-01.txt >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt >>> >>> >>> Please send comments about the draft till the November 19. >>> >>> Regards, Julien and marcelo >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> >> >> -- >> --julien >> >> [ New email address: julien.laganier.IETF@googlemail.com ] >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 11 19:01: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 6B5C73A67B5; Thu, 11 Dec 2008 19:01:12 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6003A67B5 for ; Thu, 11 Dec 2008 19:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.757 X-Spam-Level: X-Spam-Status: No, score=-0.757 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 8zNn3waK9lNA for ; Thu, 11 Dec 2008 19:01:10 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 5F8CE3A6774 for ; Thu, 11 Dec 2008 19:01:10 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id mBC312qj029963; Fri, 12 Dec 2008 12:01:02 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id mBC312003361; Fri, 12 Dec 2008 12:01:02 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili06) with ESMTP id mBC312p19126; Fri, 12 Dec 2008 12:01:02 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.115]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 11:00:40 +0800 Message-ID: <4941D3D1.10307@sg.panasonic.com> Date: Fri, 12 Dec 2008 11:00:33 +0800 From: Benjamin Lim User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Christian.Kaas-Petersen@tieto.com References: In-Reply-To: X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 12 Dec 2008 03:00:40.0165 (UTC) FILETIME=[D0A22950:01C95C05] Cc: mext@ietf.org Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Christian, Comment to one of your question. Christian.Kaas-Petersen@tieto.com wrote: > Draft 10, section 4.2 (and other places) defines the H flag, which when > set means the mobile node wants to use both its home link and one or > more of its foreign links. The H flag is really an instruction to the > home agent, that in addition to all the bidings currently defined > is shall have an extra binding where packets shall not be tunneled. > > Proposal: The mobile node should be able to define a binding saying > > HoA BID=0 HoA > > This is a kind of default binding to be used when any of the other HoA- > bindings cannot be used. I think the H flag is an indirect way of > saying there is an extra binding, whereas the binding above is direct. > It also avoids continuously setting the H flag when both home link > and foreign links are active. [Ben] I cannot understand the reasoning for this. Does not the use of the H flag can achieve the same purpose as the 'default' binding as you mention? Is there some issue for the H flag to require this change you are proposing? Also, note that this draft underwent one IESG review and changing a working mechanism now does not seem to garden any logic. Regards, Benjamin Lim _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From jan-willem.devriess@3cint.com Thu Dec 11 19:08:34 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F030F3A67EA for ; Thu, 11 Dec 2008 19:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XdhyzAEdqjZ for ; Thu, 11 Dec 2008 19:08:34 -0800 (PST) Received: from pc-53-208-46-190.cm.vtr.net (pc-53-208-46-190.cm.vtr.net [190.46.208.53]) by core3.amsl.com (Postfix) with SMTP id 47BC03A67B5 for ; Thu, 11 Dec 2008 19:08:31 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081212030833.47BC03A67B5@core3.amsl.com> Date: Thu, 11 Dec 2008 19:08:31 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mext-bounces@ietf.org Thu Dec 11 19:39: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 3C6573A694A; Thu, 11 Dec 2008 19:39:42 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC6303A694A for ; Thu, 11 Dec 2008 19:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.309 X-Spam-Level: X-Spam-Status: No, score=0.309 tagged_above=-999 required=5 tests=[AWL=0.803, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 lqt1EWTdH+Fk for ; Thu, 11 Dec 2008 19:39:40 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 801B43A67EA for ; Thu, 11 Dec 2008 19:39:39 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KBQ002UOVHM44@szxga01-in.huawei.com> for mext@ietf.org; Fri, 12 Dec 2008 11:39:22 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KBQ002NCVHMC3@szxga01-in.huawei.com> for mext@ietf.org; Fri, 12 Dec 2008 11:39:22 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KBQ00DMZVHLK2@szxml06-in.huawei.com> for mext@ietf.org; Fri, 12 Dec 2008 11:39:22 +0800 (CST) Date: Fri, 12 Dec 2008 11:39:19 +0800 From: Yungui Wang To: Alexandru Petrescu , fan zhao Message-id: <01be01c95c0b$376b3be0$150ca40a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <491039B9.6090400@it.uc3m.es> <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> <49414F35.6040305@gmail.com> Cc: Julien Laganier , mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1914800178==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1914800178== Content-type: multipart/alternative; boundary="Boundary_(ID_aWvrkXTXKL20EZtfMeL+FQ)" This is a multi-part message in MIME format. --Boundary_(ID_aWvrkXTXKL20EZtfMeL+FQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thanks for your pointed error and welcome your clear PD information flow w/o tunnel. B.R. Yungui ----- Original Message ----- From: Alexandru Petrescu To: Yungui Wang Cc: marcelo bagnulo braun ; mext ; Julien Laganier ; Ralph Droms Sent: Friday, December 12, 2008 1:34 AM Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt Yungui Wang wrote: > Hello > > Here is one comment about using MR-HA tunnel for DHCP-PD. > > In this draft, the MR registration processing needs 3 round trip > between MR and HA. i. BU to HA; (getting and binding MR_HoA) I think there's an error. RFC3775 MN and RFC3963 MR will not get any HoA with the BU, but yes indeed will bind that HoA to its current CoA, at the HA. > ii. DHCPv6 message over MR-HA tunnel. (getting MNP) I'm not sure the DHCPv6 messages need to happen through the tunnel, or maybe straight one-header DHCP messages. > iii. BU to HA; (binding MNP) While, if PD is combined within BU, it > is only 1 round trip. I see the optimization necessity, but as Julien and others already said I agree this would not need an optimization perspective since it happens at the beginning ('bootstrapping') unique phase, not upon each handover, thus not on a supposedly critical path. > From implementation of viewpoint, the later seems well done prior of > the former. Maybe I have lost something, can anyone tell me the > story why we gave up the latter in the new version? Thanks. I'm interested in implementation. Any implementation experience one may have of running DHCPv6 PD and Mobile IPv6/NEMOv6 is great to be reported here, please do so - what would your (someone's) implementation suggests? Alex > > B.R. Yungui > > > ----- Original Message ----- > > *From:* marcelo bagnulo braun *To:* mext > ; Julien Laganier > ; Ralph Droms > *Sent:* Tuesday, November 04, 2008 8:02 PM > *Subject:* [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt > > Hi, > > We now start the WGLC for: > > DHCPv6 Prefix Delegation for NEMO draft-ietf-mext-nemo-pd-01.txt > > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt > > > Please send comments about the draft till the November 19. > > Regards, Julien and marcelo > > > _______________________________________________ MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > ------------------------------------------------------------------------ > > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --Boundary_(ID_aWvrkXTXKL20EZtfMeL+FQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Thanks for your pointed error and welcome your clear PD information flow w/o tunnel.
 
B.R.
Yungui
 
----- Original Message -----
Sent: Friday, December 12, 2008 1:34 AM
Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt

Yungui Wang wrote:
> Hello
>
> Here is one comment about using MR-HA tunnel for DHCP-PD.
>
> In this draft, the MR registration processing needs 3 round trip
> between MR and HA. i. BU to HA; (getting and binding MR_HoA)

I think there's an error.  RFC3775 MN and RFC3963 MR will not get any
HoA with the BU, but yes indeed will bind that HoA to its current CoA,
at the HA.

> ii. DHCPv6 message over MR-HA tunnel. (getting MNP)

I'm not sure the DHCPv6 messages need to happen through the tunnel, or
maybe straight one-header DHCP messages.

> iii. BU to HA; (binding MNP) While, if PD is combined within BU, it
> is only 1 round trip.

I see the optimization necessity, but as Julien and others already said
I agree this would not need an optimization perspective since it happens
at the beginning ('bootstrapping') unique phase, not upon each handover,
thus not on a supposedly critical path.

> From implementation of viewpoint, the later seems well done prior of
>  the former. Maybe I have lost something, can anyone tell me the
> story why we gave up the latter in the new version? Thanks.

I'm interested in implementation.  Any implementation experience one may
have of running DHCPv6 PD and Mobile IPv6/NEMOv6 is great to be reported
here, please do so - what would your (someone's) implementation suggests?

Alex

>
> B.R. Yungui
>
>
> ----- Original Message -----
>
> *From:* marcelo bagnulo braun <mailto:marcelo@it.uc3m.es> *To:* mext
> <mailto:mext@ietf.org> ; Julien Laganier
> <mailto:julien.laganier.ietf@googlemail.com> ; Ralph Droms
> <mailto:rdroms@cisco.com> *Sent:* Tuesday, November 04, 2008 8:02 PM
> *Subject:* [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt
>
> Hi,
>
> We now start the WGLC for:
>
> DHCPv6 Prefix Delegation for NEMO draft-ietf-mext-nemo-pd-01.txt
>
> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt
>
>
> Please send comments about the draft till the November 19.
>
> Regards, Julien and marcelo
>
>
> _______________________________________________ MEXT mailing list
> MEXT@ietf.org <mailto:MEXT@ietf.org>
> https://www.ietf.org/mailman/listinfo/mext
>
>
> ------------------------------------------------------------------------
>
>
> _______________________________________________ MEXT mailing list
> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext

--Boundary_(ID_aWvrkXTXKL20EZtfMeL+FQ)-- --===============1914800178== 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 --===============1914800178==-- From mext-bounces@ietf.org Thu Dec 11 21:45:32 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C3A63A68DE; Thu, 11 Dec 2008 21:45:32 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DB9D3A68DE for ; Thu, 11 Dec 2008 21:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.166 X-Spam-Level: * X-Spam-Status: No, score=1.166 tagged_above=-999 required=5 tests=[AWL=1.602, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, 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 7jSLBo1beEIF for ; Thu, 11 Dec 2008 21:45:29 -0800 (PST) Received: from ricky.india.internal.net (unknown [59.145.147.70]) by core3.amsl.com (Postfix) with ESMTP id A38353A67B1 for ; Thu, 11 Dec 2008 21:45:27 -0800 (PST) Received: from Magesh (magesh.india.internal.net.16.172.in-addr.arpa [172.16.8.41] (may be forged)) by ricky.india.internal.net (8.12.10/8.12.10) with ESMTP id mBC5a8xA028935; Fri, 12 Dec 2008 11:06:08 +0530 Message-Id: <200812120536.mBC5a8xA028935@ricky.india.internal.net> From: "Magesh Shanmugam" To: "'Ahmad Muhanna'" Date: Fri, 12 Dec 2008 11:20:02 +0530 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AclalCYuhfjQHuocScae7Wmc5lzMKABQuirAABEpJpA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: X-Cyberoam-Version: 9.5.4.86 X-Cyberoam-smtpxy-version: 0.0.4.2 X-Cyberoam-AV-Status: Clean X-Cyberoam-Proto: SMTP X-Cyberoam-AV-Policy: None X-Cyberoam-AS-Policy: Global Spam Policy Cc: mext@ietf.org Subject: Re: [MEXT] Global Binding Revocation initiated by MAG X-BeenThere: mext@ietf.org X-Mailman-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="===============0451231480==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0451231480== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0114_01C95C4B.952C2290" This is a multi-part message in MIME format. ------=_NextPart_000_0114_01C95C4B.952C2290 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ahmad Thanks for the response. Please see my comments inline. Regards S Magesh _____ From: Ahmad Muhanna [mailto:amuhanna@nortel.com] Sent: Friday, December 12, 2008 3:38 AM To: Magesh Shanmugam Cc: mext@ietf.org Subject: RE: Global Binding Revocation initiated by MAG Magesh, Sorry for the late response. Had to travel for a short trip. I see what you are saying here. May be what we need to do is to take one step back and look into the reason for the Global revocation. The intention is to allow one of the PMIPv6 domain nodes (MAG or LMA) to inform the other to revoke all bindings that is served by these two nodes or a partial number of these binding, for example proxy MIP6 bindings that have their MN-ID which belong to a specific realm, e.g., (*@abc.com). When the 'G' bit is used for a partial Global revocation, "Revoking Node Local Policy", the draft requires that another identifier MUST be included in the BRI which is used to identify these proxy bindings. I believe that we do not have any problem in that one. Right? [Magesh] I agree with your above statement. When the 'G' bit is used for a Global revocation and in line with the above logic, we need to communicate the MAG-ID. I understand that currently we do not have a mobility option specific to carry MAG-ID, however, we defined a very specific scenario where the 'G' bit is set and the R. Trigger is set to "per-peer policy". Only in this case, the draft currently allow the MAG to include its ID in the MN-ID option. Sending the BRI and BRA is assumed to follow the exact procedure for PBU and PBA with respect to the source and dest. IP addresses. [Magesh] I'm not in favour of having a new mobility option for carrying the MAG-ID, my concern is if MAG-ID is carried in the BRI message, how does LMA knows all the binding session(s) related to that particular MAG (your point here is implementation dependent). Since from RFC5213 , it is clear that Binding Cache & Policy Profile does not maintain the MAG-ID, i feel it is better to add a statement in Binding Revocation draft regarding the way MAG-ID is handled by LMA for identifying all the binding session(s). In the vice versa case (i.e. LMA sending Global Revocation to MAG with Revocation Trigger set to "Per-Peer Policy" ), the BRI triggered by LMA will not have any mobility option(s). When MAG receives the BRI, based on the LMAA (i.e. source address in the received BRI message), it will retrieve all the binding session(s) and revoke them. I just need the same kind of procedure when MAG sends BRI with status set to "Per-Peer Policy". On the other hand, I see your point of defining a default mechanism to be used by the received Node to identify all these proxy Bindings. IMO, we need probably to have a generic approach that applicable to all cases. for example, a MAG may have more than one pCoA with a specific LMA. As a suggestion, I would recommend, in this case ONLY that the pCoA always be included in the Alternate CoA option in the BRI. Additionally, when the MAG share more than one pCoA, the MAG MUST include each pCoA in a separate Alternate-CoA option. Does sound acceptable? As a side note, implementations may have their own mechanism where the MAG-ID is somehow known to the LMA, for example, and that implementation would identify all of the proxy Binding that are served at that MAG using the MAG-ID, but that is out of scope. Regards, Ahmad _____ From: Magesh Shanmugam [mailto:mshanmugam@intellinet-india.com] Sent: Wednesday, December 10, 2008 12:55 AM To: Muhanna, Ahmad (RICH1:2H10) Cc: mext@ietf.org Subject: Global Binding Revocation initiated by MAG Ahmad In PMIPv6 domain, when MAG initiates Global Binding Revocation (G bit set), it will send the MAG identity in the MN-ID option (as per section 3.1 of binding-revocation draft-02). As per RFC 5213, while creating Binding Cache Entry @ LMA, we have MN-ID, HNP(s), Proxy Care of Address, etc in the received PBU message which will be updated in the BC entry after validation. MAG-ID will not be stored in the Binding Cache Entry when individual binding session(s) are processed and validated by LMA. When MAG triggers Global Binding Revocation, it will send the MAG-ID in the MN-ID option. Since LMA won't maintain the MAG-ID for each binding session (i.e. in BC entry), it will be tough for the LMA to identify all the binding(s) from the specific MAG. Instead of having MAG-ID in the MN-ID option for Global Revocation, if we use Proxy Care of Address (through the source IP address of the BRI message or Alternate Care of Address mobility option, if source address is different from proxy care of address), it will be easy for LMA to retrieve all the binding(s), since Proxy Care of Address is stored in the Binding Cache entry. Thanks S Magesh ------=_NextPart_000_0114_01C95C4B.952C2290 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ahmad
 
Thanks for the response.  Please see my = comments=20 inline.
 
Regards
S Magesh

From: Ahmad Muhanna = [mailto:amuhanna@nortel.com]=20
Sent: Friday, December 12, 2008 3:38 AM
To: Magesh=20 Shanmugam
Cc: mext@ietf.org
Subject: RE: Global = Binding=20 Revocation initiated by MAG

Magesh,
 
Sorry=20 for the late response. Had to travel for a short = trip.
 
I see=20 what you are saying here. May be what we need to do is to take one step = back and=20 look into the reason for the Global revocation.
 
The=20 intention is to allow one of the PMIPv6 domain nodes (MAG or LMA) to = inform the=20 other to revoke all bindings that is served by these two nodes or a = partial=20 number of these binding, for example proxy MIP6 bindings that have their = MN-ID=20 which belong to a specific realm, e.g., (*@abc.com).
 
When=20 the 'G' bit is used for a partial Global revocation, "Revoking Node = Local=20 Policy", the draft requires that another identifier MUST be included in = the BRI=20 which is used to identify these proxy bindings. I believe that we do not = have=20 any problem in that one. Right?
 
[Magesh] I agree with your above=20 statement.
 
When=20 the 'G' bit is used for a Global revocation and in line with the above = logic, we=20 need to communicate the MAG-ID. I understand that currently we do not = have a=20 mobility option specific to carry MAG-ID, however, we defined a very = specific=20 scenario where the 'G' bit is set and the R. Trigger is set to "per-peer = policy". Only in this case, the draft currently allow the MAG to include = its ID=20 in the MN-ID option. Sending the BRI and BRA is assumed to follow the = exact=20 procedure for PBU and PBA with respect to the source and dest. IP=20 addresses.
 
[Magesh] I'm not in favour of = having a new=20 mobility option for carrying the MAG-ID, my concern is if MAG-ID is = carried in=20 the BRI message, how does LMA knows all the binding session(s) related = to that=20 particular MAG (your point here is implementation dependent).  = Since from=20 RFC5213 , it is clear that Binding Cache & Policy Profile does = not=20 maintain the MAG-ID, i feel it is better to add a statement in Binding=20 Revocation draft regarding the way MAG-ID is handled by LMA for = identifying all=20 the binding session(s).
 
In the vice versa case (i.e. LMA = sending Global=20 Revocation to MAG with Revocation Trigger set to "Per-Peer Policy" ), = the BRI=20 triggered by LMA will not have any mobility option(s).  When MAG = receives=20 the
BRI, based on the LMAA (i.e. = source address in=20 the received BRI message), it will retrieve all the binding session(s) = and=20 revoke them.  I just need the same kind of procedure when MAG sends = BRI=20 with status set to "Per-Peer Policy".
 
On the=20 other hand, I see your point of defining a default mechanism to be used = by the=20 received Node to identify all these proxy Bindings. IMO, we need = probably to=20 have a generic approach that applicable to all cases. for example, a MAG = may=20 have more than one pCoA with a specific LMA. As a suggestion, I would = recommend,=20 in this case ONLY that the pCoA always be included in the Alternate = CoA=20 option in the BRI. Additionally, when the MAG share more than one = pCoA, the=20 MAG MUST include each pCoA in a separate Alternate-CoA=20 option.
 
Does sound acceptable?=20
 
As a=20 side note, implementations may have their own mechanism where the MAG-ID = is=20 somehow known to the LMA, for example, and that implementation would = identify=20 all of the proxy Binding that are served at that MAG using the = MAG-ID, but=20 that is out of scope.

Regards, =
Ahmad

 

From: Magesh Shanmugam=20 [mailto:mshanmugam@intellinet-india.com]
Sent: Wednesday, = December=20 10, 2008 12:55 AM
To: Muhanna, Ahmad = (RICH1:2H10)
Cc:=20 mext@ietf.org
Subject: Global Binding Revocation initiated = by=20 MAG

Ahmad
 
In = PMIPv6 domain,=20 when MAG initiates Global Binding Revocation (G bit set), it will send = the MAG=20 identity in the MN-ID option (as per section 3.1 of binding-revocation = draft-02).
 
As = per RFC 5213,=20 while creating Binding Cache Entry @ LMA, we have MN-ID, HNP(s), Proxy = Care of=20 Address, etc in the received PBU message which will be updated in=20 the
BC = entry after=20 validation.  MAG-ID will not be stored in the Binding Cache Entry = when=20 individual binding session(s) are processed and validated by = LMA. =20
When = MAG triggers=20 Global=20 Binding Revocation, it will send the MAG-ID in the MN-ID option.  = Since=20 LMA won't maintain the MAG-ID for each binding session (i.e. in BC = entry),=20
it = will be tough=20 for the LMA to identify all the binding(s) from the specific MAG. =20
 
Instead of having=20 MAG-ID in the MN-ID option for Global Revocation, if we use Proxy Care = of=20 Address (through the source IP address of the BRI message or=20
Alternate Care of=20 Address mobility option, if source address is different from proxy = care of=20 address), it will be easy for LMA to retrieve all the binding(s),=20
since Proxy Care=20 of Address is stored in the Binding Cache entry.
 
Thanks
S=20 Magesh
------=_NextPart_000_0114_01C95C4B.952C2290-- --===============0451231480== 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 --===============0451231480==-- From mext-bounces@ietf.org Thu Dec 11 21:59:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6580F3A6AB9; Thu, 11 Dec 2008 21:59:54 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BF843A6AB9 for ; Thu, 11 Dec 2008 21:59:53 -0800 (PST) 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 C+XLxGO+5Ycg for ; Thu, 11 Dec 2008 21:59:51 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C30A73A6AA6 for ; Thu, 11 Dec 2008 21:59:51 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6F0AC20E8F; Fri, 12 Dec 2008 06:59:44 +0100 (CET) X-AuditID: c1b4fb3c-ae75fbb00000304c-70-4941fdd0d72b Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5BD7420E33; Fri, 12 Dec 2008 06:59:44 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Dec 2008 06:59:44 +0100 Received: from [127.0.0.1] ([147.214.130.137]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Dec 2008 06:59:44 +0100 Message-ID: <4941FDCE.9050609@ericsson.com> Date: Fri, 12 Dec 2008 06:59:42 +0100 From: Conny Larsson User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Christian.Kaas-Petersen@tieto.com References: In-Reply-To: X-OriginalArrivalTime: 12 Dec 2008 05:59:44.0165 (UTC) FILETIME=[D48E7550:01C95C1E] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Christian, Christian.Kaas-Petersen@tieto.com wrote: > Assume a mobile node with home address HoA has two interfaces, > both attached to foreign links. After exchange of binding update > and binding acknowledgement, the home agent's binding cache (at > least the snip of it related to HoA) will look like this > > HoA, BID= 7, CoA1, other parameters like period of validity... > HoA, BID=10, CoA2, other parameters ... > > The draft uses HoA=2001:db8::EUI. > > Draft 10, section 5.1 states, that a BID value must be unique for a > home address and care-of address pair. This is satisfied above, but > it means, that the mobile station is not allowed to change the > second entry such that it also uses CoA1 as care-of address. > > Proposal: I think it has merit to be able to allow more than > one BID value per pair of home address and care-of address. Consider > flow bindings (defined in draft-ietf-mext-flow-binding) where > a flow may refer to a BID, and thus there is a simple way to move > flows between interfaces: only updating the binding cache. > I agree with Gerardo. When reading the draft I did not catch this one but I agree that the behaviour should be as you have described it above. Regards Conny _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 11 22:27:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA823A6937; Thu, 11 Dec 2008 22:27:54 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1383A6937 for ; Thu, 11 Dec 2008 22:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 bInFIrsx-qb1 for ; Thu, 11 Dec 2008 22:27:52 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 54EF13A6800 for ; Thu, 11 Dec 2008 22:27:51 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LB1Uz-0002rd-VJ; Fri, 12 Dec 2008 17:27:43 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Fri, 12 Dec 2008 17:27:34 +1100 From: Hesham Soliman To: "mext@ietf.org" Message-ID: Thread-Topic: Removing bindings for IPv4 only - please comment Thread-Index: AclcIrfbppqowVDjTEy3HFmjbORgHQ== Mime-version: 1.0 Cc: Jari Arkko , Julien Laganier Subject: [MEXT] Removing bindings for IPv4 only - please comment X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, Gerardo requested that we consider the issue of removing an IPv4-only bindings in the spec. We discussed this with the chairs and it seemed like a simple add-on to the spec. I'm still wondering if this is the same thing that Karen asked for earlier and we decided to do it separately. If it is, then I don't understand why we didn't consider the following solution (can't remember if I suggested it before). I've added the following text to the draft, please let me know if you have any comments ASAP. I want to submit this version on the weekend if possible. All the IESG comments have been included. It's pretty straight forward and follows standard MIPv6 logic.
Mobile nodes will remove bindings from the home agent's binding cache whenever they move to the home link, or simply when mobility support is not needed. De-registering the IPv6 home address is described in . The same mechanism applies in this specification. Mobile nodes may remove the binding for the IPv4 home address only, by sending a binding update that does not include the IPv4 home address option. Upon receiving this binding update, the home agent will replace the existing cache entries with the content of the new message. This ensures that the IPv4 home address binding is removed, while maintining an IPv6 binding. Note that the mobile node cannot remove the IPv6 home address binding while maintaining an IPv4 home address binding. A binding update message with a lifetime of zero, will remove all bindings for the mobile node.
Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 11 23:59: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 8E8473A6A9C; Thu, 11 Dec 2008 23:59:45 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F3433A6A9C for ; Thu, 11 Dec 2008 23:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.244 X-Spam-Level: X-Spam-Status: No, score=-6.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTRDvluqxN6e for ; Thu, 11 Dec 2008 23:59:43 -0800 (PST) Received: from tietoe03.tietoenator.com (datnt07.tieto.com [194.110.47.24]) by core3.amsl.com (Postfix) with ESMTP id 1ED3F3A69EC for ; Thu, 11 Dec 2008 23:59:41 -0800 (PST) X-AuditID: c26e2f18-00001a2400000510-37-49421a181ce2 Received: from stingray.eu.tieto.com ([192.176.143.13]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 10:00:24 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Dec 2008 08:59:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Dec 2008 08:59:32 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Removing bindings for IPv4 only - please comment Thread-Index: AclcIrfbppqowVDjTEy3HFmjbORgHQAC7YeQ References: From: To: , X-OriginalArrivalTime: 12 Dec 2008 07:59:34.0700 (UTC) FILETIME=[927306C0:01C95C2F] X-Brightmail-Tracker: AAAAAA== Cc: julien.laganier.ietf@googlemail.com, jari.arkko@piuha.net Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Fine with the addition. The original suggestion of Karen, now described in draft-premec-mext-extended-home-link, is something different, namely maintaining both IPv4 and IPv6 home addresses on a home link which gives native support for either IPv4 or IPv6. Suppose the home link supports only IPv4. The home agent will remove the entry for the v4HoA address, retaining the entry for the v6HoA, and this entry will indicate packets for v6HoA will have to be IP-in-IP tunneled to v4HoA. Christian > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Hesham Soliman > Sent: 12. december 2008 07:28 > To: mext@ietf.org > Cc: Jari Arkko; Julien Laganier > Subject: [MEXT] Removing bindings for IPv4 only - please comment > > Hi all, > > Gerardo requested that we consider the issue of removing an > IPv4-only bindings in the spec. We discussed this with the > chairs and it seemed like a simple add-on to the spec. I'm > still wondering if this is the same thing that Karen asked > for earlier and we decided to do it separately. If it is, > then I don't understand why we didn't consider the following > solution (can't remember if I suggested it before). > > I've added the following text to the draft, please let me > know if you have any comments ASAP. I want to submit this > version on the weekend if possible. > All the IESG comments have been included. It's pretty > straight forward and follows standard MIPv6 logic. > >
> > Mobile nodes will remove bindings from the home agent's > binding cache whenever they move to the home link, or simply > when mobility support is not needed. > > De-registering the IPv6 home address is described in target="RFC3775"/>. The same mechanism applies in this > specification. Mobile nodes may remove the binding for the > IPv4 home address only, by sending a binding update that does > not include the IPv4 home address option. Upon receiving this > binding update, the home agent will replace the existing > cache entries with the content of the new message. This > ensures that the > IPv4 home address binding is removed, while maintining an > IPv6 binding. > > Note that the mobile node cannot remove the IPv6 home > address binding while maintaining an IPv4 home address binding. > > A binding update message with a lifetime of zero, will > remove all bindings for the mobile node.
> > Hesham > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From lanaizf8201@aageneva.com Fri Dec 12 00:41:05 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECDE63A6AD6 for ; Fri, 12 Dec 2008 00:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.525 X-Spam-Level: X-Spam-Status: No, score=-7.525 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzhJpcWsiWe5 for ; Fri, 12 Dec 2008 00:41:05 -0800 (PST) Received: from akzonobel.com (unknown [93.177.138.28]) by core3.amsl.com (Postfix) with SMTP id EE71A3A6994 for ; Fri, 12 Dec 2008 00:40:58 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081212084100.EE71A3A6994@core3.amsl.com> Date: Fri, 12 Dec 2008 00:40:58 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mext-bounces@ietf.org Fri Dec 12 01:48: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 5F5553A6A13; Fri, 12 Dec 2008 01:48:00 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413903A6A13 for ; Fri, 12 Dec 2008 01:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eF9ZSRaOo71 for ; Fri, 12 Dec 2008 01:47:58 -0800 (PST) Received: from ws000774.tietoenator.com (ws000774.tietoenator.com [193.12.181.129]) by core3.amsl.com (Postfix) with ESMTP id BC97A3A69A0 for ; Fri, 12 Dec 2008 01:47:57 -0800 (PST) X-AuditID: c10cb581-000010a0000004d8-f7-4942333d384d Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 10:47:41 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Dec 2008 10:47:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Dec 2008 10:47:47 +0100 Message-ID: In-Reply-To: <4941D3D1.10307@sg.panasonic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments Thread-Index: AclcBiX5xmZdJad+SnaT9v3Cx1o+9wANsYhg References: <4941D3D1.10307@sg.panasonic.com> From: To: X-OriginalArrivalTime: 12 Dec 2008 09:47:48.0178 (UTC) FILETIME=[B0DD2320:01C95C3E] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Thanks for the comment. I understand the draft has been reviewed carefully. I'll give some more details on my proposal, as follows. I might of course have misunderstood the text of the draft, so please correct me. Assume the situation, see draft 10, Figure 3, Topology B, slightly edited to illustrate the situation when the mobile node is away. +----+ | CN | +--+-+ | +---+------+ Router +----+ +------+ Internet |-------R | HA | | +----+-----+ | +--+-+ CoA2| | | | Home Link +--+--+ | --+---------+------ | MN +========+ +-----+ CoA1 In this situation, the mobile node could have populated (using binding updates) the home agent's binding cache as follows v6HoA BID= 7 CoA1 v6HoA BID= 8 CoA1 v6HoA BID=11 CoA2 v6HoA BID=13 CoA2 Should the home agent receive a packet destined for v6HoA, which it cannot map to one of the BID values 7, 8, 11, or 13, the home agent will drop such a packet. Now the mobile node attaches to the home link (the figure below is now the unedited Figure 3, Topology B) +----+ | CN | +--+-+ | +---+------+ Router +----+ +------+ Internet |-------R | HA | | +----+-----+ | +--+-+ CoA2| | | | Home Link +--+--+ | --+-+-------+------ | MN +========+ | +--+--+ CoA1 | | | +---------------------------+ The mobile node wants to move two bindings to the home link. Thus naively the mobile node wants the home agent to have the following binding cache. v6HoA BID= 7 CoA1 v6HoA BID= 8 v6HoA v6HoA BID=11 CoA2 v6HoA BID=13 v6HoA This naive approach should not be used, because the home agent should not keep bindings when packets are not be tunneled. On the other hand, this situation is different to previous mobility solutions by allowing being at home and away at the same time. The proposal given in draft 10 is, that as long as the mobile node wants to use its attachment to the home link, it must set the H-bit in all binding identification options using foreign links. In the end, the home agent will have the following binding cache v6HoA BID= 7 CoA1 v6HoA BID=11 CoA2 plus the H-bit information. Thus when the home agent receives a packet destined for v6HoA which cannot be mapped to BID values 7 or 11, such a packet will be sent on the home link. The presence of the H-bit is like having a final default entry in the binding cache. The H-bit must be sent in all updates to the bindings as long as access to the home link is maintained. The proposal was therefore to add this final entry explicitly, allowing the mobile node to send a binding update with contents "v6HoA BID=0 v6HoA". The binding identifier "v6HoA BID=0 v6HoA" could be sent only once when attachment to the home link was established, and removed when the attachment was removed. First time the H-bit is set it means "I now want to use also my home link" whereas all following packets set the H-bit meaning "I still want to use my home link". It is this sort of keepalive mechanism for the home link I find a little surprising. Christian > -----Original Message----- > From: Benjamin Lim [mailto:benjamin.limck@sg.panasonic.com] > Sent: 12. december 2008 04:01 > To: Kaas-Petersen Christian > Cc: mext@ietf.org > Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two > proposals and some comments > > Hi Christian, > > Comment to one of your question. > > Christian.Kaas-Petersen@tieto.com wrote: > > Draft 10, section 4.2 (and other places) defines the H > flag, which when > > set means the mobile node wants to use both its home link and one or > > more of its foreign links. The H flag is really an > instruction to the > > home agent, that in addition to all the bidings currently defined > > is shall have an extra binding where packets shall not be > tunneled. > > > > Proposal: The mobile node should be able to define a binding saying > > > > HoA BID=0 HoA > > > > This is a kind of default binding to be used when any of > the other HoA- > > bindings cannot be used. I think the H flag is an indirect way of > > saying there is an extra binding, whereas the binding above > is direct. > > It also avoids continuously setting the H flag when both home link > > and foreign links are active. > [Ben] I cannot understand the reasoning for this. Does not the use of > the H flag can achieve the same purpose as the 'default' > binding as you > mention? Is there some issue for the H flag to require this > change you > are proposing? Also, note that this draft underwent one IESG > review and > changing a working mechanism now does not seem to garden any logic. > > Regards, > Benjamin Lim > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 12 02:52: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 D9FC13A6A82; Fri, 12 Dec 2008 02:52:04 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616C33A6A82 for ; Fri, 12 Dec 2008 02:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DziJS8qnET0P for ; Fri, 12 Dec 2008 02:52:02 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 3784E3A6994 for ; Fri, 12 Dec 2008 02:52:02 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so204491eyd.31 for ; Fri, 12 Dec 2008 02:51:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=NDYysfM+2dagug/qCGfWQCSWpyeDdcN6Id59sOE4TsE=; b=fw5kBtUobYDo3+yfNJXez+CCc816/hceeiiXxkx2nm7l4Hvw/4qksULFsxFV3bq4kl ll9Sj1Vk7sTH4lEGsProm5U/5QGIMscg/fFmWsikxyyCN7McvduBlaT/j/QWekvftcTq OSFmSy8HLhRlkm5n6plfRcVHAbUovUfnX8Onw= 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=O0iXBFHmhqpmp9qNottAet2V0kdeAxGvttukdrwz6p3G1PAy2QVsINAEeIu1fTEWFo R/JvdkZpZ1Py4nWzopnb/9OfDUjh8G2kkuY63BHlS5tHV5Bufku6hMCfWBEh/OWnCz1a 06DHo8v2pHXVdEzevDl8vTNfneIsfQDKxooXo= Received: by 10.210.133.2 with SMTP id g2mr3921862ebd.101.1229079114253; Fri, 12 Dec 2008 02:51:54 -0800 (PST) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id t2sm1058778gve.30.2008.12.12.02.51.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Dec 2008 02:51:53 -0800 (PST) To: Ryuji Wakikawa Date: Fri, 12 Dec 2008 11:52:03 +0100 User-Agent: KMail/1.9.10 References: <491039B9.6090400@it.uc3m.es> <200812111050.19715.julien.laganier.IETF@googlemail.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200812121152.04045.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Ryuji, On Thursday 11 December 2008, Ryuji Wakikawa wrote: > > Actually, it's not only 3 round trip and is not optimization > problem.. This is a big issue of DHCP-PD. > > Let me explain the issue clearly. > > According to the NEMO-DHCP-PD spec, before receiving a prefix, > a mobile router must create a tunnel with its HA. There would be no issue at all with the MR being configured as both a DHCP client and relay, and the HA as a DHCP server: the DHCP messages would be unicasted bewteen MR and HA without tunneling. I thought that was what we agreed on and I'm seeing now the draft still talks about multicasting into the tunnel... I think the tunneling story (Sec. 3.2) should be removed from the draft, and the DHCP relay configuration mode made the mandatory method for a NEMO MR to obtain a prefix dynamically, i.e. put a couple of SHOULD words here and there in Sec. 3.3. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mark.laplantz@alsautomotive.com Fri Dec 12 03:18:44 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D90F3A6AAB for ; Fri, 12 Dec 2008 03:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.386 X-Spam-Level: X-Spam-Status: No, score=-1.386 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNd7vk4h44+3 for ; Fri, 12 Dec 2008 03:18:43 -0800 (PST) Received: from host86-164-49-55.range86-164.btcentralplus.com (host86-164-49-55.range86-164.btcentralplus.com [86.164.49.55]) by core3.amsl.com (Postfix) with SMTP id 882E93A695E for ; Fri, 12 Dec 2008 03:18:42 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081212111842.882E93A695E@core3.amsl.com> Date: Fri, 12 Dec 2008 03:18:42 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mext-bounces@ietf.org Fri Dec 12 04:25: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 579BC3A6990; Fri, 12 Dec 2008 04:25:35 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 935C13A681C for ; Fri, 12 Dec 2008 04:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIUeD0KX4Lfh for ; Fri, 12 Dec 2008 04:25:33 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id CB0283A6990 for ; Fri, 12 Dec 2008 04:25:33 -0800 (PST) Received: from [IPv6:2001:660:4701:1001:21b:63ff:fe94:5dc0] (unknown [IPv6:2001:660:4701:1001:21b:63ff:fe94:5dc0]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 9B1794C58A; Fri, 12 Dec 2008 21:25:19 +0900 (JST) Message-Id: From: Romain KUNTZ To: Julien Laganier In-Reply-To: <200812121152.04045.julien.laganier.IETF@googlemail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 12 Dec 2008 13:25:16 +0100 References: <491039B9.6090400@it.uc3m.es> <200812111050.19715.julien.laganier.IETF@googlemail.com> <200812121152.04045.julien.laganier.IETF@googlemail.com> X-Mailer: Apple Mail (2.929.2) Cc: mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, On 2008/12/12, at 11:52, Julien Laganier wrote: > On Thursday 11 December 2008, Ryuji Wakikawa wrote: >> >> Actually, it's not only 3 round trip and is not optimization >> problem.. This is a big issue of DHCP-PD. >> >> Let me explain the issue clearly. >> >> According to the NEMO-DHCP-PD spec, before receiving a prefix, >> a mobile router must create a tunnel with its HA. > > There would be no issue at all with the MR being configured as both a > DHCP client and relay, and the HA as a DHCP server: the DHCP messages > would be unicasted bewteen MR and HA without tunneling. Do you then suggest to do the prefix delegation procedure before the NEMO registration? I think this raises multiple issues. First the DHCP relay would use the CoA as source address of the message, but the DHCPv6 server may need to know the MR's HoA if it is configured with static assignment of the MNP. Furthermore, once the MR registers its allocated MNP to the HA, the HA cannot verify that the MNP that is in the BU was the one that the DHCP server allocated to that MR. To do so, the DHCP server would need to give the HoA/MNP pair to the HA, so that it can perform a check at registration. By using the MR-HA tunnel, the relay message is sent using the HoA. Also, the use of an IPsec tunnel will secure the message exchange between the MR and the HA. As for the issues raised by Ryuji, I'll reply in another mail. Cheers, romain _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 12 04:37: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 125563A696A; Fri, 12 Dec 2008 04:37:06 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934233A696A for ; Fri, 12 Dec 2008 04:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLItSEdaop6G for ; Fri, 12 Dec 2008 04:37:03 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id A77F03A67D4 for ; Fri, 12 Dec 2008 04:37:02 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LB7GH-0000vg-BY; Fri, 12 Dec 2008 23:36:53 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Fri, 12 Dec 2008 23:36:47 +1100 From: Hesham Soliman To: , Message-ID: Thread-Topic: [MEXT] Removing bindings for IPv4 only - please comment Thread-Index: AclcIrfbppqowVDjTEy3HFmjbORgHQAC7YeQAAn3hrs= In-Reply-To: Mime-version: 1.0 Cc: julien.laganier.ietf@googlemail.com, jari.arkko@piuha.net Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > Fine with the addition. The original suggestion of Karen, now > described in draft-premec-mext-extended-home-link, is something > different, namely maintaining both IPv4 and IPv6 home addresses > on a home link which gives native support for either IPv4 or IPv6. > Suppose the home link supports only IPv4. The home agent will > remove the entry for the v4HoA address, retaining the entry > for the v6HoA, and this entry will indicate packets for v6HoA > will have to be IP-in-IP tunneled to v4HoA. => Right, but this is what the text I sent does. It removes the v4 binding and keeps the IPv6 binding. If the link is IPv4 only then it will bind the v6 HoA to that IPv4 address. Hesham > > Christian > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Hesham Soliman >> Sent: 12. december 2008 07:28 >> To: mext@ietf.org >> Cc: Jari Arkko; Julien Laganier >> Subject: [MEXT] Removing bindings for IPv4 only - please comment >> >> Hi all, >> >> Gerardo requested that we consider the issue of removing an >> IPv4-only bindings in the spec. We discussed this with the >> chairs and it seemed like a simple add-on to the spec. I'm >> still wondering if this is the same thing that Karen asked >> for earlier and we decided to do it separately. If it is, >> then I don't understand why we didn't consider the following >> solution (can't remember if I suggested it before). >> >> I've added the following text to the draft, please let me >> know if you have any comments ASAP. I want to submit this >> version on the weekend if possible. >> All the IESG comments have been included. It's pretty >> straight forward and follows standard MIPv6 logic. >> >>
>> >> Mobile nodes will remove bindings from the home agent's >> binding cache whenever they move to the home link, or simply >> when mobility support is not needed. >> >> De-registering the IPv6 home address is described in > target="RFC3775"/>. The same mechanism applies in this >> specification. Mobile nodes may remove the binding for the >> IPv4 home address only, by sending a binding update that does >> not include the IPv4 home address option. Upon receiving this >> binding update, the home agent will replace the existing >> cache entries with the content of the new message. This >> ensures that the >> IPv4 home address binding is removed, while maintining an >> IPv6 binding. >> >> Note that the mobile node cannot remove the IPv6 home >> address binding while maintaining an IPv4 home address binding. >> >> A binding update message with a lifetime of zero, will >> remove all bindings for the mobile node.
>> >> Hesham >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 12 04:41: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 ADAED3A681C; Fri, 12 Dec 2008 04:41:17 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6983A67D4 for ; Fri, 12 Dec 2008 04:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.204 X-Spam-Level: * X-Spam-Status: No, score=1.204 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_52=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbK-mtPfHW3F for ; Fri, 12 Dec 2008 04:41:16 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 145413A681C for ; Fri, 12 Dec 2008 04:41:16 -0800 (PST) Received: from [IPv6:2001:660:4701:1001:21b:63ff:fe94:5dc0] (unknown [IPv6:2001:660:4701:1001:21b:63ff:fe94:5dc0]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 64DB74C536; Fri, 12 Dec 2008 21:41:05 +0900 (JST) Message-Id: <27D6A7A2-B696-484F-8A52-DDAF6ED6C422@lsiit.u-strasbg.fr> From: Romain KUNTZ To: Ryuji Wakikawa In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 12 Dec 2008 13:41:02 +0100 References: <491039B9.6090400@it.uc3m.es> <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> <200812111050.19715.julien.laganier.IETF@googlemail.com> <4B8E03A1-432A-49F9-8DA0-98EF582620FD@lsiit.u-strasbg.fr> X-Mailer: Apple Mail (2.929.2) Cc: Julien Laganier , mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ryuji, On 2008/12/11, at 17:45, Ryuji Wakikawa wrote: >> I'd say the MR still sends a BU with the R-flag set and without the >> MNP option, which will be considered as registration in Implicit >> mode by the HA. > > Implicit mode requires some mapping between a mobile network prefix > and a mobile router. The DHCPv6 server will do such mapping. More below: > Implicit: > > In this mode, the Mobile Router does not include a Mobile > Network Prefix Option in the Binding Update. The Home Agent > can use any mechanism (not defined in this document) to > determine the Mobile Network Prefix(es) owned by the Mobile > Router and to set up forwarding for the Mobile Network. One We have an implementation of NEMO+DHCPv6PD, and here the "mechanism to determine the Mobile Network Prefix(es) owned by the Mobile Router" is a simple message from the DHCPv6 server to the HA that advertises the MNP/HoA pair to the HA. This paragraph does not say that such information must be retrieved at the home registration (but actually this is stated later in the RFC :-) see below) > example would be manual configuration at the Home Agent > mapping > the Mobile Router's Home Address to the information required > for setting up forwarding for the Mobile Network. As stated in the sentence, This is an example so it does not exclude DHCPv6PD. > In RFC3963, we didn't consider a MR who doesn't have any mobile > network prefix sends BU with R-flag set. > In implicit mode, if there is no prefix for the MR, HA will reject > the BU From section 6.2: [...] - If there is no option in the Binding Update carrying prefix information, the Home Agent uses manual pre-configured information to determine the prefixes assigned to the Mobile Router and to set up forwarding for the Mobile Network. If there is no information that the Home Agent can use, it MUST reject the Binding Update and send a Binding Acknowledgement with status set to 143 (Forwarding Setup failed). [...] In our implementation, at home registration the HA checks with the DHCP server if a prefix is available for this HoA. If so, registration is done (but not forwarding). Once the DHCPv6 server has delegated a prefix to the MR, it informs the HA that it can setup forwarding for the delegated MNP. The RFC does not explicitely says that forwarding must be setup at home registration, but it says that the HA must check wether such information is available. What is really missing in the NEMO DHCPv6PD draft is IMHO details on what (and how) the HA and DHCPv6 server need to agree. Cheers, romain _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 12 05:05: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 C79A83A6B04; Fri, 12 Dec 2008 05:05:38 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E66123A6B04 for ; Fri, 12 Dec 2008 05:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 fBXqFDe3CZcl for ; Fri, 12 Dec 2008 05:05:36 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 0F34F3A6AC0 for ; Fri, 12 Dec 2008 05:05:35 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LB7hv-0000dS-8O; Sat, 13 Dec 2008 00:05:27 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Sat, 13 Dec 2008 00:05:25 +1100 From: Hesham Soliman To: , Message-ID: Thread-Topic: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments Thread-Index: AclbmelbVEZqE1eBQTKM/5HFe6iu1gAwGK5u In-Reply-To: Mime-version: 1.0 Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On 12/12/08 1:08 AM, "Christian.Kaas-Petersen@tieto.com" wrote: > Assume a mobile node with home address HoA has two interfaces, > both attached to foreign links. After exchange of binding update > and binding acknowledgement, the home agent's binding cache (at > least the snip of it related to HoA) will look like this > > HoA, BID= 7, CoA1, other parameters like period of validity... > HoA, BID=10, CoA2, other parameters ... > > The draft uses HoA=2001:db8::EUI. > > Draft 10, section 5.1 states, that a BID value must be unique for a > home address and care-of address pair. This is satisfied above, but > it means, that the mobile station is not allowed to change the > second entry such that it also uses CoA1 as care-of address. => But why would the MN want to do that? The scenario you're suggesting means that there is effectively one binding, so why do we need to allocated two BIDs to the same CoA? If there is a reason then I think your proposal is fine, although it will be tricky to implement. But I'd like to see a plausible scenario first. > Draft 10, section 4.2 (and other places) defines the H flag, which when > set means the mobile node wants to use both its home link and one or > more of its foreign links. The H flag is really an instruction to the > home agent, that in addition to all the bidings currently defined > is shall have an extra binding where packets shall not be tunneled. > > Proposal: The mobile node should be able to define a binding saying > > HoA BID=0 HoA > > This is a kind of default binding to be used when any of the other HoA- > bindings cannot be used. I think the H flag is an indirect way of > saying there is an extra binding, whereas the binding above is direct. > It also avoids continuously setting the H flag when both home link > and foreign links are active. => This is basically asking for a permanent binding. Again, I'd like to understand why this is needed, compared to what the draft says now. Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 12 06:33: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 E8E343A6B1B; Fri, 12 Dec 2008 06:33:11 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F6F3A6B22 for ; Fri, 12 Dec 2008 06:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnjphYK56fCz for ; Fri, 12 Dec 2008 06:33:09 -0800 (PST) Received: from ws000774.tietoenator.com (ws000774.tietoenator.com [193.12.181.129]) by core3.amsl.com (Postfix) with ESMTP id 37B293A6B1A for ; Fri, 12 Dec 2008 06:33:09 -0800 (PST) X-AuditID: c10cb581-00000318000004d8-eb-494276147b1d Received: from stingray.eu.tieto.com ([192.176.143.13]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 15:32:52 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Dec 2008 15:32:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Dec 2008 15:32:58 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Removing bindings for IPv4 only - please comment Thread-Index: AclcIrfbppqowVDjTEy3HFmjbORgHQAC7YeQAAn3hrsAA5HPwA== References: From: To: , X-OriginalArrivalTime: 12 Dec 2008 14:32:59.0840 (UTC) FILETIME=[88358C00:01C95C66] X-Brightmail-Tracker: AAAAAA== Cc: julien.laganier.ietf@googlemail.com, jari.arkko@piuha.net Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 understood the text as a useful clarification. I understood it this way. When a mobile node moves to an IPv6 foreign network, and there obtains the v6CoA address, it sends a binding update BU src = v6CoA Destination Option with v6HoA lifetime > 0 Alternate Care-of Address v6CoA IPv4 Home Address v4HoA to the home agent, and the home agent will in its binding cache insert two entries (1) v6HoA -> v6CoA (2) v4HoA -> v6CoA The clarification to me was then, that the mobile node, while at this foreign IPv6 network, could ask the home agent to remove both of the bindings by sending BU src = v6CoA Destination Option with v6HoA lifetime = 0 or could ask the home agent to remove the IPv4 binding (retaining the IPv6 binding) by sending BU src = v6CoA Destination Option with v6HoA lifetime > 0 Alternate Care-of Address v6CoA I'll go back to the situation where the binding cache has entries (1) and (2). If the mobile node moves to an IPv6-only link where it gets only the v6HoA address, and wants to continue using v4HoA, then the home agent's binding cache should be provided with the entry (a) v4HoA -> v6HoA Or the other situation, the mobile node moves to an IPv4-only link getting only v4HoA, the binding cache should be provided with the entry (b) v6HoA -> v4HoA Maybe you could help me sorting out: what is the contents of the binding updates to be sent to the home agent in the two situations? And are both situations covered with the DSMIP specification? Christian > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: 12. december 2008 13:37 > To: Kaas-Petersen Christian; mext@ietf.org > Cc: jari.arkko@piuha.net; julien.laganier.ietf@googlemail.com > Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment > > > > Fine with the addition. The original suggestion of Karen, now > > described in draft-premec-mext-extended-home-link, is something > > different, namely maintaining both IPv4 and IPv6 home > addresses on a > > home link which gives native support for either IPv4 or IPv6. > > Suppose the home link supports only IPv4. The home agent > will remove > > the entry for the v4HoA address, retaining the entry for the v6HoA, > > and this entry will indicate packets for v6HoA will have to be > > IP-in-IP tunneled to v4HoA. > > => Right, but this is what the text I sent does. It removes > the v4 binding and keeps the IPv6 binding. If the link is > IPv4 only then it will bind the > v6 HoA to that IPv4 address. > > Hesham > > > > > Christian > > > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > On Behalf > >> Of Hesham Soliman > >> Sent: 12. december 2008 07:28 > >> To: mext@ietf.org > >> Cc: Jari Arkko; Julien Laganier > >> Subject: [MEXT] Removing bindings for IPv4 only - please comment > >> > >> Hi all, > >> > >> Gerardo requested that we consider the issue of removing > an IPv4-only > >> bindings in the spec. We discussed this with the chairs > and it seemed > >> like a simple add-on to the spec. I'm still wondering if > this is the > >> same thing that Karen asked for earlier and we decided to do it > >> separately. If it is, then I don't understand why we > didn't consider > >> the following solution (can't remember if I suggested it before). > >> > >> I've added the following text to the draft, please let me > know if you > >> have any comments ASAP. I want to submit this version on > the weekend > >> if possible. > >> All the IESG comments have been included. It's pretty straight > >> forward and follows standard MIPv6 logic. > >> > >>
> >> > >> Mobile nodes will remove bindings from the home agent's binding > >> cache whenever they move to the home link, or simply when mobility > >> support is not needed. > >> > >> De-registering the IPv6 home address is described in >> target="RFC3775"/>. The same mechanism applies in this > specification. > >> Mobile nodes may remove the binding for the > >> IPv4 home address only, by sending a binding update that does not > >> include the IPv4 home address option. Upon receiving this binding > >> update, the home agent will replace the existing cache > entries with > >> the content of the new message. This ensures that the > >> IPv4 home address binding is removed, while maintining an > >> IPv6 binding. > >> > >> Note that the mobile node cannot remove the IPv6 home address > >> binding while maintaining an IPv4 home address binding. > >> > >> A binding update message with a lifetime of zero, will > remove all > >> bindings for the mobile node.
> >> > >> Hesham > >> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 12 06:57: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 4230228C123; Fri, 12 Dec 2008 06:57:41 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 987C33A67F7 for ; Fri, 12 Dec 2008 06:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.193 X-Spam-Level: X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.405, 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 ghK3W+9Eg9kt for ; Fri, 12 Dec 2008 06:57:39 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 70CAF3A6B1B for ; Fri, 12 Dec 2008 06:57:39 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mBCEvRK23638; Fri, 12 Dec 2008 14:57:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Dec 2008 08:57:14 -0600 Message-ID: In-Reply-To: <200812120536.mBC5a8xA028935@ricky.india.internal.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Global Binding Revocation initiated by MAG Thread-Index: AclalCYuhfjQHuocScae7Wmc5lzMKABQuirAABEpJpAAE1wksA== References: <200812120536.mBC5a8xA028935@ricky.india.internal.net> From: "Ahmad Muhanna" To: "Magesh Shanmugam" Cc: mext@ietf.org Subject: Re: [MEXT] Global Binding Revocation initiated by MAG X-BeenThere: mext@ietf.org X-Mailman-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="===============1668921772==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1668921772== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95C69.EBAA8A17" This is a multi-part message in MIME format. ------_=_NextPart_001_01C95C69.EBAA8A17 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Magesh, please see inline. Regards,=20 Ahmad ________________________________ =09 When the 'G' bit is used for a Global revocation and in line with the above logic, we need to communicate the MAG-ID. I understand that currently we do not have a mobility option specific to carry MAG-ID, however, we defined a very specific scenario where the 'G' bit is set and the R. Trigger is set to "per-peer policy". Only in this case, the draft currently allow the MAG to include its ID in the MN-ID option. Sending the BRI and BRA is assumed to follow the exact procedure for PBU and PBA with respect to the source and dest. IP addresses. =20 [Magesh] I'm not in favour of having a new mobility option for carrying the MAG-ID, my concern is if MAG-ID is carried in the BRI message, how does LMA knows all the binding session(s) related to that particular MAG (your point here is implementation dependent). Since from RFC5213 , it is clear that Binding Cache & Policy Profile does not maintain the MAG-ID, i feel it is better to add a statement in Binding Revocation draft regarding the way MAG-ID is handled by LMA for identifying all the binding session(s). =20 In the vice versa case (i.e. LMA sending Global Revocation to MAG with Revocation Trigger set to "Per-Peer Policy" ), the BRI triggered by LMA will not have any mobility option(s). When MAG receives the BRI, based on the LMAA (i.e. source address in the received BRI message), it will retrieve all the binding session(s) and revoke them. I just need the same kind of procedure when MAG sends BRI with status set to "Per-Peer Policy".=20 =20 [Ahmad] As I said earlier in my reply. If the case of the LMA is sufficient to you, then the case of the MAG is sufficient too. Because, in every BRI sent from the MAG to the LMA, the MAG follow the same procedure as in sending a PBU. i.e. src address =3D pCoA. However, as I said earlier, that could be NOT enough in case the MAG has multiple pCoAs. In this case, my suggestion is: Whenever MAG sends a BRI with the (G) bit is set and the R. Trigger is set to "per-Peer Policy", the MAG must identify the pCoA(s) by including them in Alternate CoA options in the BRI. =20 Is that logic acceptable to you or you have a problem with that? =20 Regards, Ahmad =20 =20 ------_=_NextPart_001_01C95C69.EBAA8A17 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Magesh,
please=20 see inline.

Regards, =
Ahmad


When=20 the 'G' bit is used for a Global revocation and in line with the above = logic,=20 we need to communicate the MAG-ID. I understand that currently we do = not have=20 a mobility option specific to carry MAG-ID, however, we defined a very = specific scenario where the 'G' bit is set and the R. Trigger is set = to=20 "per-peer policy". Only in this case, the draft currently allow the = MAG to=20 include its ID in the MN-ID option. Sending the BRI and BRA is assumed = to=20 follow the exact procedure for PBU and PBA with respect to the source = and=20 dest. IP addresses.
 
[Magesh] I'm not in favour of = having a new=20 mobility option for carrying the MAG-ID, my concern is if MAG-ID is = carried in=20 the BRI message, how does LMA knows all the binding session(s) related = to that=20 particular MAG (your point here is implementation dependent).  = Since from=20 RFC5213 , it is clear that Binding Cache & Policy = Profile does not=20 maintain the MAG-ID, i feel it is better to add a statement in Binding = Revocation draft regarding the way MAG-ID is handled by LMA for = identifying=20 all the binding session(s).
 
In the vice versa case (i.e. LMA = sending=20 Global Revocation to MAG with Revocation Trigger set to "Per-Peer = Policy" ),=20 the BRI triggered by LMA will not have any mobility option(s).  = When MAG=20 receives the
BRI, based on the = LMAA (i.e.=20 source address in the received BRI message), it will retrieve all the = binding=20 session(s) and revoke them.  I just need the same kind of = procedure when=20 MAG sends BRI with status set to "Per-Peer Policy". 
&nbs= p;
[Ahmad]<= /DIV>
As I = said earlier in my=20 reply. If the case of the LMA is sufficient to you, then the case = of the=20 MAG is sufficient too. Because, in every BRI sent from the MAG to = the=20 LMA, the MAG follow the same procedure as in sending a PBU. i.e. src = address =3D=20 pCoA. However, as I said earlier, that could be NOT enough = in case=20 the MAG has multiple pCoAs. In this case, my suggestion is: = Whenever MAG=20 sends a BRI with the (G) bit is set and the R. Trigger is set to = "per-Peer=20 Policy", the MAG must identify the pCoA(s) by including them in = Alternate=20 CoA options in the = BRI.
&nbs= p;
Is that logic = acceptable to you=20 or you have a problem with=20 that?
&nbs= p;
Regards,
Ahmad
 
 
------_=_NextPart_001_01C95C69.EBAA8A17-- --===============1668921772== 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 --===============1668921772==-- From mext-bounces@ietf.org Fri Dec 12 07:12: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 2C6EB3A6B22; Fri, 12 Dec 2008 07:12:53 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DCE43A6B1B for ; Fri, 12 Dec 2008 07:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLnnD3ittF59 for ; Fri, 12 Dec 2008 07:12:50 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 90FCD28C123 for ; Fri, 12 Dec 2008 07:12:50 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LB9h2-0002F6-HV; Sat, 13 Dec 2008 02:12:41 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Sat, 13 Dec 2008 02:12:35 +1100 From: Hesham Soliman To: , Message-ID: Thread-Topic: [MEXT] Removing bindings for IPv4 only - please comment Thread-Index: AclcIrfbppqowVDjTEy3HFmjbORgHQAC7YeQAAn3hrsAA5HPwAAB3yfL In-Reply-To: Mime-version: 1.0 Cc: julien.laganier.ietf@googlemail.com, jari.arkko@piuha.net Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 understood the text as a useful clarification. I understood it > this way. When a mobile node moves to an IPv6 foreign network, > and there obtains the v6CoA address, it sends a binding update > > BU > src = v6CoA > Destination Option with v6HoA > lifetime > 0 > Alternate Care-of Address v6CoA > IPv4 Home Address v4HoA > > to the home agent, and the home agent will in its binding cache insert > two entries > > (1) v6HoA -> v6CoA > (2) v4HoA -> v6CoA => That's the current draft yes. I'm not sure why you're referring to IPv6 foreign networks only. The same applies to IPv4 networks. > > The clarification to me was then, that the mobile node, while at this > foreign IPv6 network, could ask the home agent to remove both of the > bindings by sending > > BU > src = v6CoA > Destination Option with v6HoA > lifetime = 0 > > or could ask the home agent to remove the IPv4 binding (retaining > the IPv6 binding) by sending > > BU > src = v6CoA > Destination Option with v6HoA > lifetime > 0 > Alternate Care-of Address v6CoA > > I'll go back to the situation where the binding cache has entries (1) > and (2). If the mobile node moves to an IPv6-only link where it gets > only the v6HoA address, and wants to continue using v4HoA, then the > home agent's binding cache should be provided with the entry > > (a) v4HoA -> v6HoA => This wasn't part of the text I sent. > > Or the other situation, the mobile node moves to an IPv4-only link > getting only v4HoA, the binding cache should be provided with the entry > > (b) v6HoA -> v4HoA => For b) you would send src = v4addr dst = HA src = V6HoA dst = V6HA BU message v4 alt CoA option containing v4addr Hesham > > Maybe you could help me sorting out: what is the contents of > the binding updates to be sent to the home agent in the two > situations? And are both situations covered with the DSMIP > specification? > > Christian > > >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: 12. december 2008 13:37 >> To: Kaas-Petersen Christian; mext@ietf.org >> Cc: jari.arkko@piuha.net; julien.laganier.ietf@googlemail.com >> Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment >> >> >>> Fine with the addition. The original suggestion of Karen, now >>> described in draft-premec-mext-extended-home-link, is something >>> different, namely maintaining both IPv4 and IPv6 home >> addresses on a >>> home link which gives native support for either IPv4 or IPv6. >>> Suppose the home link supports only IPv4. The home agent >> will remove >>> the entry for the v4HoA address, retaining the entry for the v6HoA, >>> and this entry will indicate packets for v6HoA will have to be >>> IP-in-IP tunneled to v4HoA. >> >> => Right, but this is what the text I sent does. It removes >> the v4 binding and keeps the IPv6 binding. If the link is >> IPv4 only then it will bind the >> v6 HoA to that IPv4 address. >> >> Hesham >> >>> >>> Christian >>> >>>> -----Original Message----- >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] >> On Behalf >>>> Of Hesham Soliman >>>> Sent: 12. december 2008 07:28 >>>> To: mext@ietf.org >>>> Cc: Jari Arkko; Julien Laganier >>>> Subject: [MEXT] Removing bindings for IPv4 only - please comment >>>> >>>> Hi all, >>>> >>>> Gerardo requested that we consider the issue of removing >> an IPv4-only >>>> bindings in the spec. We discussed this with the chairs >> and it seemed >>>> like a simple add-on to the spec. I'm still wondering if >> this is the >>>> same thing that Karen asked for earlier and we decided to do it >>>> separately. If it is, then I don't understand why we >> didn't consider >>>> the following solution (can't remember if I suggested it before). >>>> >>>> I've added the following text to the draft, please let me >> know if you >>>> have any comments ASAP. I want to submit this version on >> the weekend >>>> if possible. >>>> All the IESG comments have been included. It's pretty straight >>>> forward and follows standard MIPv6 logic. >>>> >>>>
>>>> >>>> Mobile nodes will remove bindings from the home agent's binding >>>> cache whenever they move to the home link, or simply when mobility >>>> support is not needed. >>>> >>>> De-registering the IPv6 home address is described in >>> target="RFC3775"/>. The same mechanism applies in this >> specification. >>>> Mobile nodes may remove the binding for the >>>> IPv4 home address only, by sending a binding update that does not >>>> include the IPv4 home address option. Upon receiving this binding >>>> update, the home agent will replace the existing cache >> entries with >>>> the content of the new message. This ensures that the >>>> IPv4 home address binding is removed, while maintining an >>>> IPv6 binding. >>>> >>>> Note that the mobile node cannot remove the IPv6 home address >>>> binding while maintaining an IPv4 home address binding. >>>> >>>> A binding update message with a lifetime of zero, will >> remove all >>>> bindings for the mobile node.
>>>> >>>> Hesham >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >> >> >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 12 10:34: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 368AB28C152; Fri, 12 Dec 2008 10:34:53 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB7A28C152 for ; Fri, 12 Dec 2008 10:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmBQDirjv7vo for ; Fri, 12 Dec 2008 10:34:51 -0800 (PST) Received: from web111414.mail.gq1.yahoo.com (web111414.mail.gq1.yahoo.com [67.195.15.210]) by core3.amsl.com (Postfix) with SMTP id 0524128C131 for ; Fri, 12 Dec 2008 10:34:50 -0800 (PST) Received: (qmail 90184 invoked by uid 60001); 12 Dec 2008 18:34:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=l6ZY/UP48Fcs/Yw5S0BFMebYGUPj5L2/LzNP1Z+63P/+pnByIv1v7GePnpowlHdhVoPYZ0zu1MLZDxTAFHUhq7QTqx4UJOWbpu4pKZNf3T8WfZDD/mDm+LjdDC62FtaLVyWOxu0bUsF4YkoXf+Swl/StO4tqAbLGDTrPWegEXYQ=; X-YMail-OSG: 9.bij9UVM1lhFDOdFbAv9TNmois5kymfXKTJzQzgFNAaBstwpyvge7IkAW3tRN1nKK.Mjz9lUrlaqQrsWHb2ssJ5H6YNNq4kqSoWvHWk7TRZPE25HdLSs3cuhoRVwlNAXRbWpAN054xRw3C.9TDxhkdkVbCjeLCUgCkkO.UmUzFqvQZZPk2y8oakf3relq4_Fr2GX5kUZXeHl9U- Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Fri, 12 Dec 2008 10:34:44 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <491039B9.6090400@it.uc3m.es> <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> <200812111050.19715.julien.laganier.IETF@googlemail.com> <4B8E03A1-432A-49F9-8DA0-98EF582620FD@lsiit.u-strasbg.fr> <27D6A7A2-B696-484F-8A52-DDAF6ED6C422@lsiit.u-strasbg.fr> Date: Fri, 12 Dec 2008 10:34:44 -0800 (PST) From: Behcet Sarikaya To: Romain KUNTZ MIME-Version: 1.0 Message-ID: <444189.90178.qm@web111414.mail.gq1.yahoo.com> Cc: mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2080408703==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============2080408703== Content-Type: multipart/alternative; boundary="0-624983617-1229106884=:90178" --0-624983617-1229106884=:90178 Content-Type: text/plain; charset=us-ascii Hi Romain, ________________________________ From: Romain KUNTZ To: Ryuji Wakikawa Cc: Julien Laganier ; mext Sent: Friday, December 12, 2008 6:41:02 AM Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt Hi Ryuji, On 2008/12/11, at 17:45, Ryuji Wakikawa wrote: >> I'd say the MR still sends a BU with the R-flag set and without the MNP option, which will be considered as registration in Implicit mode by the HA. > > Implicit mode requires some mapping between a mobile network prefix and a mobile router. The DHCPv6 server will do such mapping. More below: > Implicit: > > In this mode, the Mobile Router does not include a Mobile > Network Prefix Option in the Binding Update. The Home Agent > can use any mechanism (not defined in this document) to > determine the Mobile Network Prefix(es) owned by the Mobile > Router and to set up forwarding for the Mobile Network. One We have an implementation of NEMO+DHCPv6PD, and here the "mechanism to determine the Mobile Network Prefix(es) owned by the Mobile Router" is a simple message from the DHCPv6 server to the HA that advertises the MNP/HoA pair to the HA. [behcet] I am curious what is this message? Can you please give more details? This paragraph does not say that such information must be retrieved at the home registration (but actually this is stated later in the RFC :-) see below) > example would be manual configuration at the Home Agent mapping > the Mobile Router's Home Address to the information required > for setting up forwarding for the Mobile Network. As stated in the sentence, This is an example so it does not exclude DHCPv6PD. > In RFC3963, we didn't consider a MR who doesn't have any mobile network prefix sends BU with R-flag set. > In implicit mode, if there is no prefix for the MR, HA will reject the BU >From section 6.2: [...] - If there is no option in the Binding Update carrying prefix information, the Home Agent uses manual pre-configured information to determine the prefixes assigned to the Mobile Router and to set up forwarding for the Mobile Network. If there is no information that the Home Agent can use, it MUST reject the Binding Update and send a Binding Acknowledgement with status set to 143 (Forwarding Setup failed). [...] In our implementation, at home registration the HA checks with the DHCP server if a prefix is available for this HoA. If so, registration is done (but not forwarding). Once the DHCPv6 server has delegated a prefix to the MR, it informs the HA that it can setup forwarding for the delegated MNP. [behcet] I have a question: If HA were a requesting router (not a delegating router as in Nemo-pd draft), how would you change your implementation architecture? I have a feeling that you are using HA as a requesting router . If HA is a requesting router, all you need at the HA is DHCP Client (and possibly colocated with relay if the delegating router is not on-link) So I believe, in fact you are agreeing with Ryuji. Regards, Behcet --0-624983617-1229106884=:90178 Content-Type: text/html; charset=us-ascii
Hi Romain,

From: Romain KUNTZ <kuntz@lsiit.u-strasbg.fr>
To: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
Cc: Julien Laganier <julien.laganier.ietf@googlemail.com>; mext <mext@ietf.org>
Sent: Friday, December 12, 2008 6:41:02 AM
Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt

Hi Ryuji,

On 2008/12/11, at 17:45, Ryuji Wakikawa wrote:
>> I'd say the MR still sends a BU with the R-flag set and without the MNP option, which will be considered as registration in Implicit mode by the HA.
>
> Implicit mode requires some mapping between a mobile network prefix and a mobile router.

The DHCPv6 server will do such mapping. More below:

>      Implicit:
>
>        In this mode, the Mobile Router does not include a Mobile
>        Network Prefix Option in the Binding Update.  The Home Agent
>        can use any mechanism (not defined in this document) to
>        determine the Mobile Network Prefix(es) owned by the Mobile
>        Router and to set up forwarding for the Mobile Network.  One

We have an implementation of NEMO+DHCPv6PD, and here the "mechanism to determine the Mobile Network Prefix(es) owned by the Mobile Router" is a simple message from the DHCPv6 server to the HA that advertises the MNP/HoA pair to the HA.

[behcet] I am curious what is this message? Can you please give more details?

This paragraph does not say that such information must be retrieved at the home registration (but actually this is stated later in the RFC :-) see below)

>        example would be manual configuration at the Home Agent mapping
>        the Mobile Router's Home Address to the information required
>        for setting up forwarding for the Mobile Network.

As stated in the sentence, This is an example so it does not exclude DHCPv6PD.

> In RFC3963, we didn't consider a MR who doesn't  have any mobile network prefix sends BU with R-flag set.
> In implicit mode, if there is no  prefix for the MR, HA will reject the BU

From section 6.2:

[...]
  -  If there is no option in the Binding Update carrying prefix
      information, the Home Agent uses manual pre-configured information
      to determine the prefixes assigned to the Mobile Router and to set
      up forwarding for the Mobile Network.  If there is no information
      that the Home Agent can use, it MUST reject the Binding Update and
      send a Binding Acknowledgement with status set to 143 (Forwarding
      Setup failed).
[...]

In our implementation, at home registration the HA checks with the DHCP server if a prefix is available for this HoA. If so, registration is done (but not forwarding). Once the DHCPv6 server has delegated a prefix to the MR, it informs the HA that it can setup forwarding for the delegated MNP.

[behcet] I have a question: If HA were a requesting router (not a delegating router as in Nemo-pd draft), how would you change your implementation architecture?
I have a feeling that you are using HA as a requesting router . If HA is a requesting router, all you need at the HA is DHCP Client (and possibly colocated with relay if the delegating router is not on-link)
So I believe, in fact you are agreeing with Ryuji.



Regards,

Behcet

--0-624983617-1229106884=:90178-- --===============2080408703== 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 --===============2080408703==-- From mext-bounces@ietf.org Fri Dec 12 11:26: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 7BC343A6B15; Fri, 12 Dec 2008 11:26:12 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE6183A6B15 for ; Fri, 12 Dec 2008 11:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.699 X-Spam-Level: X-Spam-Status: No, score=-103.699 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6YRfjq7pEVF for ; Fri, 12 Dec 2008 11:26:10 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id A7F793A6B03 for ; Fri, 12 Dec 2008 11:26:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1229109964; x=1260645964; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Hesham=20Soliman=20,=0D =0A=20=20=20=20=20=20=20=20"Christian.Kaas-Petersen@tieto .com"=20,=0D=0A=20=20 =20=20=20=20=20=20"mext@ietf.org"=20|Date: =20Fri,=2012=20Dec=202008=2011:25:45=20-0800|Subject:=20R E:=20[MEXT]=20Subject:=20Multiple=20CoA=20draft=2010=20-- =20two=20proposals=20and=20some=0D=0A=20comments |Thread-Topic:=20[MEXT]=20Subject:=20Multiple=20CoA=20dra ft=2010=20--=20two=20proposals=20and=0D=0A=20some=20comme nts|Thread-Index:=20AclbmelbVEZqE1eBQTKM/5HFe6iu1gAwGK5uA A0V7tA=3D|Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3 D6E298C1@NASANEXMB08.na.qualcomm.com>|References:=20=0D=0A=20 |In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5461"=3B=20a=3D"13889129"; bh=iUwmIsIw2rQaB8njPXu22O8yA43251X98mbSn4Ebjgs=; b=PGmcAIKheByXKmOlkwYeQEdljJc1G42FTNPXSuVNK8mWYxc+m9WD5H2i bLOxPKCRs88BXDUU3c6KAei3dvMe7hKDE3b6Ph5AuiSFdh/S8A9HGgVKX Lu8iwwo/C6/DJtmkCzMKVs8pq1w9O7rCc1fqVBFprVy2tfjvBChAj4dro I=; X-IronPort-AV: E=McAfee;i="5100,188,5461"; a="13889129" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Dec 2008 11:25:49 -0800 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBCJPnMC027586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 12 Dec 2008 11:25:49 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBCJPdpG020344 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 12 Dec 2008 11:25:46 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.132]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Fri, 12 Dec 2008 11:25:42 -0800 From: "Giaretta, Gerardo" To: Hesham Soliman , "Christian.Kaas-Petersen@tieto.com" , "mext@ietf.org" Date: Fri, 12 Dec 2008 11:25:45 -0800 Thread-Topic: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments Thread-Index: AclbmelbVEZqE1eBQTKM/5HFe6iu1gAwGK5uAA0V7tA= Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D6E298C1@NASANEXMB08.na.qualcomm.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham and Christain, See below some comments > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Hesham > Soliman > Sent: Friday, December 12, 2008 5:05 AM > To: Christian.Kaas-Petersen@tieto.com; mext@ietf.org > Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some > comments > > > > > On 12/12/08 1:08 AM, "Christian.Kaas-Petersen@tieto.com" > wrote: > > > Assume a mobile node with home address HoA has two interfaces, > > both attached to foreign links. After exchange of binding update > > and binding acknowledgement, the home agent's binding cache (at > > least the snip of it related to HoA) will look like this > > > > HoA, BID= 7, CoA1, other parameters like period of validity... > > HoA, BID=10, CoA2, other parameters ... > > > > The draft uses HoA=2001:db8::EUI. > > > > Draft 10, section 5.1 states, that a BID value must be unique for a > > home address and care-of address pair. This is satisfied above, but > > it means, that the mobile station is not allowed to change the > > second entry such that it also uses CoA1 as care-of address. > > => But why would the MN want to do that? The scenario you're suggesting > means that there is effectively one binding, so why do we need to allocated > two BIDs to the same CoA? If there is a reason then I think your proposal is > fine, although it will be tricky to implement. But I'd like to see a > plausible scenario first. > Suppose the MN is connected to access 1 and access2 and has two flow bindings with two different CoA HoA, BID=1, CoA1, FID1, FID4, FID6 HoA, BID=2, CoA2 FID2, FID3, FID5 When the MN loses access 2 coverage it can do two things to keep the flows active: - send a BU with HoA, BID=1, FID2, FID3, FID5 to add those flows to the first binding - send a BU with HoA, BID=2, CoA1 to update the CoA of the second binding The second has advantages in terms of signaling overhead. This is true in particular if then the MN moves back to access2 and wants to re-establish the flow bindings as previously. In that case just a new CoA update is needed instead of re-registering the flows again. If the second approach is used you will have up giving two different BIDs for which the CoA is the same. But this should not be an issue as the bindings are treated independently, they just happen to point to the same CoA Gerardo > > Draft 10, section 4.2 (and other places) defines the H flag, which when > > set means the mobile node wants to use both its home link and one or > > more of its foreign links. The H flag is really an instruction to the > > home agent, that in addition to all the bidings currently defined > > is shall have an extra binding where packets shall not be tunneled. > > > > Proposal: The mobile node should be able to define a binding saying > > > > HoA BID=0 HoA > > > > This is a kind of default binding to be used when any of the other HoA- > > bindings cannot be used. I think the H flag is an indirect way of > > saying there is an extra binding, whereas the binding above is direct. > > It also avoids continuously setting the H flag when both home link > > and foreign links are active. > > => This is basically asking for a permanent binding. Again, I'd like to > understand why this is needed, compared to what the draft says now. > > Hesham > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 12 11:29: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 EEC1F3A698A; Fri, 12 Dec 2008 11:29:25 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B73943A698A for ; Fri, 12 Dec 2008 11:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOe1TBEKQEql for ; Fri, 12 Dec 2008 11:29:23 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 9B63C3A68E8 for ; Fri, 12 Dec 2008 11:29:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1229110157; x=1260646157; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20"Christian.Kaas-Petersen@tieto.com"=20,=0D=0A=20=20=20=20=20=20=20=20"be njamin.limck@sg.panasonic.com"=20|CC:=20"mext@ietf.org"=20|Date: =20Fri,=2012=20Dec=202008=2011:29:19=20-0800|Subject:=20R E:=20[MEXT]=20Subject:=20Multiple=20CoA=20draft=2010=20-- =20two=20proposals=20and=20some=0D=0A=09comments |Thread-Topic:=20[MEXT]=20Subject:=20Multiple=20CoA=20dra ft=2010=20--=20two=20proposals=20and=0D=0A=20some=09comme nts|Thread-Index:=20AclcBiX5xmZdJad+SnaT9v3Cx1o+9wANsYhgA BSnFhA=3D|Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3 D6E298C3@NASANEXMB08.na.qualcomm.com>|References:=20=0D=0A=09<4941D3D1.10307@sg.panasonic.com>=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5461"=3B=20a=3D"13913674"; bh=8t8DzG7Lb0bsQwq/NliG2h5Chmf74w07VpImmvD2ACk=; b=HTnIxKCDE6HtuE2VUsQ/1wLIrUp5uiFbAjD75uJzQftfAc0VPEbtP7c0 KGssGZ9VRxSCxBRQOFe4U+OWRrSt16hcIVbxg4EJfv3YyRkaMFp1SowfV XrnC/SWoIAhu1xv10vL9R1O0QqGn0Cjl5CB3ukv2x36wY0kOGqEBkPKeX 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5461"; a="13913674" 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; 12 Dec 2008 11:29:17 -0800 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBCJTGG3029439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 12 Dec 2008 11:29:17 -0800 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBCJTFAI018818 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 12 Dec 2008 11:29:16 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.132]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Fri, 12 Dec 2008 11:29:15 -0800 From: "Giaretta, Gerardo" To: "Christian.Kaas-Petersen@tieto.com" , "benjamin.limck@sg.panasonic.com" Date: Fri, 12 Dec 2008 11:29:19 -0800 Thread-Topic: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments Thread-Index: AclcBiX5xmZdJad+SnaT9v3Cx1o+9wANsYhgABSnFhA= Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D6E298C3@NASANEXMB08.na.qualcomm.com> References: <4941D3D1.10307@sg.panasonic.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I think Christian has a valid point here. In particular this is useful/needed when flow bindings is used and one interface is in the home link. In the way Christina is proposing, the MN could explicitly associate some flows to the interface which is on the home link. In the way the draft it is written now, the home link becomes always the default route. Basically the current draft does not support the scenario where the MN wants to have FID1 in the interface in the home link and a match all entry for the interface in the foreign link. To allow this, a BID needs to be allocated to the interface in the HoA. Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Christian.Kaas-Petersen@tieto.com > Sent: Friday, December 12, 2008 1:48 AM > To: benjamin.limck@sg.panasonic.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some > comments > > Thanks for the comment. > > I understand the draft has been reviewed carefully. > I'll give some more details on my proposal, as follows. > I might of course have misunderstood the text of the draft, so > please correct me. > > Assume the situation, see draft 10, Figure 3, Topology B, slightly > edited to illustrate the situation when the mobile node is away. > > > +----+ > | CN | > +--+-+ > | > +---+------+ Router +----+ > +------+ Internet |-------R | HA | > | +----+-----+ | +--+-+ > CoA2| | | | Home Link > +--+--+ | --+---------+------ > | MN +========+ > +-----+ CoA1 > > > In this situation, the mobile node could have populated (using binding > updates) the home agent's binding cache as follows > > v6HoA BID= 7 CoA1 > v6HoA BID= 8 CoA1 > v6HoA BID=11 CoA2 > v6HoA BID=13 CoA2 > > Should the home agent receive a packet destined for v6HoA, which > it cannot map to one of the BID values 7, 8, 11, or 13, the > home agent will drop such a packet. > > Now the mobile node attaches to the home link (the figure below is > now the unedited Figure 3, Topology B) > > > +----+ > | CN | > +--+-+ > | > +---+------+ Router +----+ > +------+ Internet |-------R | HA | > | +----+-----+ | +--+-+ > CoA2| | | | Home Link > +--+--+ | --+-+-------+------ > | MN +========+ | > +--+--+ CoA1 | > | | > +---------------------------+ > > > The mobile node wants to move two bindings to the home link. Thus > naively the mobile node wants the home agent to have the following > binding cache. > > v6HoA BID= 7 CoA1 > v6HoA BID= 8 v6HoA > v6HoA BID=11 CoA2 > v6HoA BID=13 v6HoA > > This naive approach should not be used, because the home agent should > not keep bindings when packets are not be tunneled. > On the other hand, this situation is different to previous > mobility solutions by allowing being at home and away at the same time. > > The proposal given in draft 10 is, that as long as the mobile > node wants to use its attachment to the home link, it must set the > H-bit in all binding identification options using foreign links. > In the end, the home agent will have the following binding cache > > v6HoA BID= 7 CoA1 > v6HoA BID=11 CoA2 > > plus the H-bit information. Thus when the home agent receives a packet > destined for v6HoA which cannot be mapped to BID values 7 or 11, such > a packet will be sent on the home link. The presence of the H-bit > is like having a final default entry in the binding cache. The H-bit > must be sent in all updates to the bindings as long as access > to the home link is maintained. The proposal was therefore to > add this final entry explicitly, allowing the mobile node to send > a binding update with contents "v6HoA BID=0 v6HoA". > The binding identifier "v6HoA BID=0 v6HoA" could be sent only once > when attachment to the home link was established, and removed when > the attachment was removed. > > First time the H-bit is set it means "I now want to use also my > home link" whereas all following packets set the H-bit meaning > "I still want to use my home link". It is this sort of keepalive > mechanism for the home link I find a little surprising. > > Christian > > > > -----Original Message----- > > From: Benjamin Lim [mailto:benjamin.limck@sg.panasonic.com] > > Sent: 12. december 2008 04:01 > > To: Kaas-Petersen Christian > > Cc: mext@ietf.org > > Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two > > proposals and some comments > > > > Hi Christian, > > > > Comment to one of your question. > > > > Christian.Kaas-Petersen@tieto.com wrote: > > > Draft 10, section 4.2 (and other places) defines the H > > flag, which when > > > set means the mobile node wants to use both its home link and one or > > > more of its foreign links. The H flag is really an > > instruction to the > > > home agent, that in addition to all the bidings currently defined > > > is shall have an extra binding where packets shall not be > > tunneled. > > > > > > Proposal: The mobile node should be able to define a binding saying > > > > > > HoA BID=0 HoA > > > > > > This is a kind of default binding to be used when any of > > the other HoA- > > > bindings cannot be used. I think the H flag is an indirect way of > > > saying there is an extra binding, whereas the binding above > > is direct. > > > It also avoids continuously setting the H flag when both home link > > > and foreign links are active. > > [Ben] I cannot understand the reasoning for this. Does not the use of > > the H flag can achieve the same purpose as the 'default' > > binding as you > > mention? Is there some issue for the H flag to require this > > change you > > are proposing? Also, note that this draft underwent one IESG > > review and > > changing a working mechanism now does not seem to garden any logic. > > > > 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 Dec 12 12:47: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 CCFD528C21D; Fri, 12 Dec 2008 12:47:55 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5517228C21D for ; Fri, 12 Dec 2008 12:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.657 X-Spam-Level: X-Spam-Status: No, score=-105.657 tagged_above=-999 required=5 tests=[AWL=0.942, 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 YsZryAlrGkBn for ; Fri, 12 Dec 2008 12:47:52 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id C2ADF28C218 for ; Fri, 12 Dec 2008 12:47:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1229114867; x=1260650867; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Hesham=20Soliman=20,=20" mext@ietf.org"=20|CC:=20marcelo=20bagnulo =20braun=20,=0D=0A=20=20=20=20=20=20 =20=20Julien=20Laganier=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20Jari=20Arkko =20|Date:=20Fri,=2012=20Dec=202008 =2012:47:33=20-0800|Subject:=20RE:=20Removing=20bindings =20for=20IPv4=20only=20-=20please=20comment|Thread-Topic: =20Removing=20bindings=20for=20IPv4=20only=20-=20please =20comment|Thread-Index:=20AclcIrfbppqowVDjTEy3HFmjbORgHQ AeBgSg|Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3D6E 298D8@NASANEXMB08.na.qualcomm.com>|References:=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5461"=3B=20a=3D"13917084"; bh=+UlySbE74vLaN5c5rt6xWHP6THW3lqOR1QuJh9rC7f8=; b=EwqGz3p61NIBJkHhZLAlc+6dTR/TAqqrtWM2m+9zDR/pMpYpKebHUd8W JUmaOCWq7tjMG/M0IqoT0FWpDryKbIjeAMyDR9bs6p4IrYW1gY7rcNqqz m+JQIDlq2iOf/tNcxVqGw4RK6vGe4AhUwU7Ng6x3utIyHueC5Wfg4esPF 0=; X-IronPort-AV: E=McAfee;i="5300,2777,5461"; a="13917084" 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; 12 Dec 2008 12:47:46 -0800 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBCKlkag008725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 12 Dec 2008 12:47:46 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBCKlcVh004436 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 12 Dec 2008 12:47:41 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.132]) by nasanexhub01.na.qualcomm.com ([10.46.93.121]) with mapi; Fri, 12 Dec 2008 12:47:38 -0800 From: "Giaretta, Gerardo" To: Hesham Soliman , "mext@ietf.org" Date: Fri, 12 Dec 2008 12:47:33 -0800 Thread-Topic: Removing bindings for IPv4 only - please comment Thread-Index: AclcIrfbppqowVDjTEy3HFmjbORgHQAeBgSg Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D6E298D8@NASANEXMB08.na.qualcomm.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Jari Arkko , Julien Laganier Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Thanks Hesham - I think this text covers the case I was referring to Gerardo > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Thursday, December 11, 2008 10:28 PM > To: mext@ietf.org > Cc: Giaretta, Gerardo; marcelo bagnulo braun; Julien Laganier; Jari Arkko > Subject: Removing bindings for IPv4 only - please comment > > Hi all, > > Gerardo requested that we consider the issue of removing an IPv4-only > bindings in the spec. We discussed this with the chairs and it seemed like a > simple add-on to the spec. I'm still wondering if this is the same thing > that Karen asked for earlier and we decided to do it separately. If it is, > then I don't understand why we didn't consider the following solution (can't > remember if I suggested it before). > > I've added the following text to the draft, please let me know if you have > any comments ASAP. I want to submit this version on the weekend if possible. > All the IESG comments have been included. It's pretty straight forward and > follows standard MIPv6 logic. > >
> > Mobile nodes will remove bindings from the home agent's binding cache > whenever they move to the home link, or simply when mobility support is not > needed. > > De-registering the IPv6 home address is described in target="RFC3775"/>. The same mechanism applies in this specification. Mobile > nodes may remove the binding for the IPv4 home address only, by sending a > binding update that does not include the IPv4 home address option. Upon > receiving this binding update, the home agent will replace the existing > cache entries with the content of the new message. This ensures that the > IPv4 home address binding is removed, while maintining an IPv6 binding. > > Note that the mobile node cannot remove the IPv6 home address binding > while maintaining an IPv4 home address binding. > > A binding update message with a lifetime of zero, will remove all > bindings for the mobile node. >
> > Hesham > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 12 18:06: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 B7A313A68A4; Fri, 12 Dec 2008 18:06:22 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39DA3A68A4 for ; Fri, 12 Dec 2008 18:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fboz5ucjCp4Q for ; Fri, 12 Dec 2008 18:06:20 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id A5B7A3A67A8 for ; Fri, 12 Dec 2008 18:06:19 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LBJtQ-0003Mk-O1; Sat, 13 Dec 2008 13:06:09 +1100 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Sat, 13 Dec 2008 13:06:03 +1100 From: Hesham Soliman To: "Giaretta, Gerardo" , "Christian.Kaas-Petersen@tieto.com" , "mext@ietf.org" Message-ID: Thread-Topic: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments Thread-Index: AclbmelbVEZqE1eBQTKM/5HFe6iu1gAwGK5uAA0V7tAADi16Lg== In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D6E298C1@NASANEXMB08.na.qualcomm.com> Mime-version: 1.0 Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org >> >> => But why would the MN want to do that? The scenario you're suggesting >> means that there is effectively one binding, so why do we need to allocated >> two BIDs to the same CoA? If there is a reason then I think your proposal is >> fine, although it will be tricky to implement. But I'd like to see a >> plausible scenario first. >> > > Suppose the MN is connected to access 1 and access2 and has two flow bindings > with two different CoA > > HoA, BID=1, CoA1, FID1, FID4, FID6 > HoA, BID=2, CoA2 FID2, FID3, FID5 > > When the MN loses access 2 coverage it can do two things to keep the flows > active: > - send a BU with HoA, BID=1, FID2, FID3, FID5 to add those flows to the first > binding > - send a BU with HoA, BID=2, CoA1 to update the CoA of the second binding > > The second has advantages in terms of signaling overhead. This is true in > particular if then the MN moves back to access2 and wants to re-establish the > flow bindings as previously. In that case just a new CoA update is needed > instead of re-registering the flows again. => That's right, I guessed this is why you and Christian were asking for it. But I think it's strange to have a binding id if it's not unique because it's basically replicating the binding in case we need to change the CoA. It makes things more complex and error prone in the implementation for a small difference of bytes that will be sent. After all, you're not eliminating the need to send another BU, you're just sending a smaller BU. So if you're lucky, you'll save tens of bytes. It's not worth it IMHO. Hesham > > If the second approach is used you will have up giving two different BIDs for > which the CoA is the same. But this should not be an issue as the bindings are > treated independently, they just happen to point to the same CoA > > Gerardo > >>> Draft 10, section 4.2 (and other places) defines the H flag, which when >>> set means the mobile node wants to use both its home link and one or >>> more of its foreign links. The H flag is really an instruction to the >>> home agent, that in addition to all the bidings currently defined >>> is shall have an extra binding where packets shall not be tunneled. >>> >>> Proposal: The mobile node should be able to define a binding saying >>> >>> HoA BID=0 HoA >>> >>> This is a kind of default binding to be used when any of the other HoA- >>> bindings cannot be used. I think the H flag is an indirect way of >>> saying there is an extra binding, whereas the binding above is direct. >>> It also avoids continuously setting the H flag when both home link >>> and foreign links are active. >> >> => This is basically asking for a permanent binding. Again, I'd like to >> understand why this is needed, compared to what the draft says now. >> >> Hesham >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From k.kijanka@alstor.com.pl Sat Dec 13 00:24:04 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAEEE3A6840 for ; Sat, 13 Dec 2008 00:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.776 X-Spam-Level: X-Spam-Status: No, score=-3.776 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_FONT_LOW_CONTRAST=0.124, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DA1bIJUNAh82 for ; Sat, 13 Dec 2008 00:24:04 -0800 (PST) Received: from 101.10.117.87.donpac.ru (101.10.117.87.donpac.ru [87.117.10.101]) by core3.amsl.com (Postfix) with SMTP id B502B3A67AD for ; Sat, 13 Dec 2008 00:24:01 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081213082402.B502B3A67AD@core3.amsl.com> Date: Sat, 13 Dec 2008 00:24:01 -0800 (PST)
Go to site!

Your woman won't forget her pleasure



Mancini:Minister, Lionel Jospin for 5 years. In 2001, France
 From mistimebhcm@aautomate.com Sat Dec 13 01:50:27 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84EB13A6841 for ; Sat, 13 Dec 2008 01:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.628 X-Spam-Level: X-Spam-Status: No, score=-12.628 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_LOW_CONTRAST=0.124, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxlL8ZqgkuHB for ; Sat, 13 Dec 2008 01:50:26 -0800 (PST) Received: from accenture.com (unknown [96.235.176.184]) by core3.amsl.com (Postfix) with SMTP id 0BCCE3A687E for ; Sat, 13 Dec 2008 01:50:25 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081213095026.0BCCE3A687E@core3.amsl.com> Date: Sat, 13 Dec 2008 01:50:25 -0800 (PST)
Go to site!

Replace your pant snake with python



The United States Army's Surgeon General Lt. Gen. Kevinyears. According to the Bangkok Post he is likely to
 From mext-bounces@ietf.org Sat Dec 13 04: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 C70D43A691A; Sat, 13 Dec 2008 04:45:02 -0800 (PST) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8D6C03A691A; Sat, 13 Dec 2008 04:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081213124501.8D6C03A691A@core3.amsl.com> Date: Sat, 13 Dec 2008 04:45:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-v4traversal-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobile IPv6 Support for Dual Stack Hosts and Routers (DSMIPv6) Author(s) : H. Soliman Filename : draft-ietf-mext-nemo-v4traversal-07.txt Pages : 50 Date : 2008-12-13 The current Mobile IPv6 and NEMO specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-nemo-v4traversal-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-13043440.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 mail@advancedtechies.com Sat Dec 13 05:09:37 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FECD3A690A for ; Sat, 13 Dec 2008 05:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.155 X-Spam-Level: X-Spam-Status: No, score=-9.155 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpcyzLmyOluk for ; Sat, 13 Dec 2008 05:09:36 -0800 (PST) Received: from alltel.net (unknown [122.162.95.52]) by core3.amsl.com (Postfix) with SMTP id 2A2B63A67E1 for ; Sat, 13 Dec 2008 05:09:33 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081213130935.2A2B63A67E1@core3.amsl.com> Date: Sat, 13 Dec 2008 05:09:33 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mext-bounces@ietf.org Sat Dec 13 22:14:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA6F43A6977; Sat, 13 Dec 2008 22:14:03 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358D43A6977 for ; Sat, 13 Dec 2008 22:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 ZEbHltK0T6g0 for ; Sat, 13 Dec 2008 22:14:01 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 6DD4B3A693B for ; Sat, 13 Dec 2008 22:14:00 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LBkEh-0008DA-Kd for ; Sun, 14 Dec 2008 17:13:52 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Sun, 14 Dec 2008 17:13:50 +1100 From: Hesham Soliman To: "mext@ietf.org" Message-ID: Thread-Topic: New DSMIPv6 draft Thread-Index: AcldsyGKuoCKV6LIOUGBA0hMt9LFYA== Mime-version: 1.0 Subject: [MEXT] New DSMIPv6 draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Folks, v7 of DSMIPv6 is now available, please take a look to see if your comments were addressed and let me know. This version handles IESG comments received so far. There is a couple of comments from Brian Carpenter on the references section that are awaiting Jari's advice. Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Dec 14 19:53:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 070073A6807; Sun, 14 Dec 2008 19:53:03 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E215C3A685D for ; Sun, 14 Dec 2008 19:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.29 X-Spam-Level: X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApM4CC5NrhDe for ; Sun, 14 Dec 2008 19:53:00 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id B4CD13A65A5 for ; Sun, 14 Dec 2008 19:52:59 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id mBF3qllo027041; Mon, 15 Dec 2008 12:52:48 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id mBF3qlK15289; Mon, 15 Dec 2008 12:52:47 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili01) with ESMTP id mBF3qjr24549; Mon, 15 Dec 2008 12:52:45 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.115]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Dec 2008 11:52:20 +0800 Message-ID: <4945D472.5040108@sg.panasonic.com> Date: Mon, 15 Dec 2008 11:52:18 +0800 From: Benjamin Lim User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Christian.Kaas-Petersen@tieto.com References: <4941D3D1.10307@sg.panasonic.com> In-Reply-To: X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 15 Dec 2008 03:52:20.0347 (UTC) FILETIME=[87B9A4B0:01C95E68] Cc: mext@ietf.org Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Christian, Thanks for providing details. Pls see inline for my comments. Christian.Kaas-Petersen@tieto.com wrote: > Thanks for the comment. > > I understand the draft has been reviewed carefully. > I'll give some more details on my proposal, as follows. > I might of course have misunderstood the text of the draft, so > please correct me. > > Assume the situation, see draft 10, Figure 3, Topology B, slightly > edited to illustrate the situation when the mobile node is away. > > > +----+ > | CN | > +--+-+ > | > +---+------+ Router +----+ > +------+ Internet |-------R | HA | > | +----+-----+ | +--+-+ > CoA2| | | | Home Link > +--+--+ | --+---------+------ > | MN +========+ > +-----+ CoA1 > > > In this situation, the mobile node could have populated (using binding > updates) the home agent's binding cache as follows > > v6HoA BID= 7 CoA1 > v6HoA BID= 8 CoA1 > v6HoA BID=11 CoA2 > v6HoA BID=13 CoA2 [Ben] Is there a reason why you would want to create duplicate entires for CoAs in the BCE? I agree you can implement it this way, but I cannot see the reasoning for it. Unless this is the 'navie' approach you are talking about that MN creates these duplicate entires in anticipation that it might want to use simultaneous home and foreign link. > > Should the home agent receive a packet destined for v6HoA, which > it cannot map to one of the BID values 7, 8, 11, or 13, the > home agent will drop such a packet. [Ben] I am not sure where you pull this assumption of HA dropping packets so long there is no match. I do not think that such assumption is valid as even the flow filtering draft mentions a default binding to be maintain and thus if a flow does not match any FID at HA, it is possible for that flow to be routed using the default entry in the BCE. > > Now the mobile node attaches to the home link (the figure below is > now the unedited Figure 3, Topology B) > > > +----+ > | CN | > +--+-+ > | > +---+------+ Router +----+ > +------+ Internet |-------R | HA | > | +----+-----+ | +--+-+ > CoA2| | | | Home Link > +--+--+ | --+-+-------+------ > | MN +========+ | > +--+--+ CoA1 | > | | > +---------------------------+ > > > The mobile node wants to move two bindings to the home link. Thus > naively the mobile node wants the home agent to have the following > binding cache. > > v6HoA BID= 7 CoA1 > v6HoA BID= 8 v6HoA > v6HoA BID=11 CoA2 > v6HoA BID=13 v6HoA > > This naive approach should not be used, because the home agent should > not keep bindings when packets are not be tunneled. > On the other hand, this situation is different to previous > mobility solutions by allowing being at home and away at the same time. > > The proposal given in draft 10 is, that as long as the mobile > node wants to use its attachment to the home link, it must set the > H-bit in all binding identification options using foreign links. > In the end, the home agent will have the following binding cache > > v6HoA BID= 7 CoA1 > v6HoA BID=11 CoA2 > > plus the H-bit information. Thus when the home agent receives a packet > destined for v6HoA which cannot be mapped to BID values 7 or 11, such > a packet will be sent on the home link. The presence of the H-bit > is like having a final default entry in the binding cache. The H-bit > must be sent in all updates to the bindings as long as access > to the home link is maintained. The proposal was therefore to > add this final entry explicitly, allowing the mobile node to send > a binding update with contents "v6HoA BID=0 v6HoA". > The binding identifier "v6HoA BID=0 v6HoA" could be sent only once > when attachment to the home link was established, and removed when > the attachment was removed. [Ben] By sending the above BID once when attaching and removing it when attachment is gone seems to imply infinite lifetime for the home link attachment. The purpose of lifetime is a way to let HA know that MN is still on that link (by forcing MN to refresh the lifetime). I am not sure if there are deployments that allow MN to obtain infinite lifetime. Even for 3GPP when PMIP is used for home link by MN, the MAG still have to refresh the PBU based on the lifetime. Regards, Benjamin Lim > > First time the H-bit is set it means "I now want to use also my > home link" whereas all following packets set the H-bit meaning > "I still want to use my home link". It is this sort of keepalive > mechanism for the home link I find a little surprising. > > Christian > > >> -----Original Message----- >> From: Benjamin Lim [mailto:benjamin.limck@sg.panasonic.com] >> Sent: 12. december 2008 04:01 >> To: Kaas-Petersen Christian >> Cc: mext@ietf.org >> Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two >> proposals and some comments >> >> Hi Christian, >> >> Comment to one of your question. >> >> Christian.Kaas-Petersen@tieto.com wrote: >>> Draft 10, section 4.2 (and other places) defines the H >> flag, which when >>> set means the mobile node wants to use both its home link and one or >>> more of its foreign links. The H flag is really an >> instruction to the >>> home agent, that in addition to all the bidings currently defined >>> is shall have an extra binding where packets shall not be >> tunneled. >>> Proposal: The mobile node should be able to define a binding saying >>> >>> HoA BID=0 HoA >>> >>> This is a kind of default binding to be used when any of >> the other HoA- >>> bindings cannot be used. I think the H flag is an indirect way of >>> saying there is an extra binding, whereas the binding above >> is direct. >>> It also avoids continuously setting the H flag when both home link >>> and foreign links are active. >> [Ben] I cannot understand the reasoning for this. Does not the use of >> the H flag can achieve the same purpose as the 'default' >> binding as you >> mention? Is there some issue for the H flag to require this >> change you >> are proposing? Also, note that this draft underwent one IESG >> review and >> changing a working mechanism now does not seem to garden any logic. >> >> Regards, >> Benjamin Lim >> >> >> > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 15 01:46: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 615C43A6829; Mon, 15 Dec 2008 01:46:34 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E123A6829 for ; Mon, 15 Dec 2008 01:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.095 X-Spam-Level: X-Spam-Status: No, score=-0.095 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24QTccjbMu6c for ; Mon, 15 Dec 2008 01:46:32 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id BD9C53A67CC for ; Mon, 15 Dec 2008 01:46:31 -0800 (PST) Received: from [192.168.0.20] (bro67-5-88-177-196-175.fbx.proxad.net [88.177.196.175]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id E876B4C13A; Mon, 15 Dec 2008 18:46:18 +0900 (JST) Message-Id: From: Romain KUNTZ To: Behcet Sarikaya In-Reply-To: <444189.90178.qm@web111414.mail.gq1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 15 Dec 2008 10:45:58 +0100 References: <491039B9.6090400@it.uc3m.es> <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> <200812111050.19715.julien.laganier.IETF@googlemail.com> <4B8E03A1-432A-49F9-8DA0-98EF582620FD@lsiit.u-strasbg.fr> <27D6A7A2-B696-484F-8A52-DDAF6ED6C422@lsiit.u-strasbg.fr> <444189.90178.qm@web111414.mail.gq1.yahoo.com> X-Mailer: Apple Mail (2.929.2) Cc: mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0416402550==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0416402550== Content-Type: multipart/alternative; boundary=Apple-Mail-6--228428415 --Apple-Mail-6--228428415 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Behcet, On 2008/12/12, at 19:34, Behcet Sarikaya wrote: > We have an implementation of NEMO+DHCPv6PD, and here the "mechanism > to determine the Mobile Network Prefix(es) owned by the Mobile > Router" is a simple message from the DHCPv6 server to the HA that > advertises the MNP/HoA pair to the HA. > > [behcet] I am curious what is this message? Can you please give more > details? The DHCPv6 server is co-located with the HA on the same computer. I use a UNIX socket for inter-processus communication with a simple TLV message. > In our implementation, at home registration the HA checks with the > DHCP server if a prefix is available for this HoA. If so, > registration is done (but not forwarding). Once the DHCPv6 server > has delegated a prefix to the MR, it informs the HA that it can > setup forwarding for the delegated MNP. > > [behcet] I have a question: If HA were a requesting router (not a > delegating router as in Nemo-pd draft), how would you change your > implementation architecture? > I have a feeling that you are using HA as a requesting router . In our testbed, the HA is a delegating router, and the client & relay are located at the HA. DHCP messages are exchanged through the MR-HA tunnel. If the HA were a requesting router, I guess the testbed, implementation and interaction with the mobility daemon would be completely different, so I can't really tell how I would change the current one. > If HA is a requesting router, all you need at the HA is DHCP Client > (and possibly colocated with relay if the delegating router is not > on-link) I guess you refer to the solution exposed in draft-sarikaya-mext- prefix-delegation? This one suppose that the prefix delegation at the MR happens with BU/BAck messages, which is not the case in our implementation. Note that I do not discuss here which solution is the best, but only present feedback from implementation of one of the solution. If I had chosen the delegation through the BU/BAck, I would certainly have coupled it with a DHCP server as you describe in your draft. > So I believe, in fact you are agreeing with Ryuji. Agreeing on what point ? Regards, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr LSIIT - Networks and Protocols Team http://clarinet.u-strasbg.fr/~kuntz/ --Apple-Mail-6--228428415 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Behcet,

On 2008/12/12, at 19:34, Behcet Sarikaya = wrote:
We have an = implementation of NEMO+DHCPv6PD, and here the "mechanism to determine = the Mobile Network Prefix(es) owned by the Mobile Router" is a simple = message from the DHCPv6 server to the HA that advertises the MNP/HoA = pair to the HA.

[behcet] = I am curious what is this message? Can you please give more = details?

= The DHCPv6 server is co-located with the HA on the same computer. I use = a UNIX socket for inter-processus communication with a simple TLV = message. 

In our = implementation, at home registration the HA checks with the DHCP server = if a prefix is available for this HoA. If so, registration is done (but = not forwarding). Once the DHCPv6 server has delegated a prefix to the = MR, it informs the HA that it can setup forwarding for the delegated = MNP.

[behcet] I have a question: If HA were a requesting = router (not a delegating router as in Nemo-pd draft), how would you = change your implementation architecture? 
I have a feeling that = you are using HA as a requesting router . =

<= div>
In our testbed, the HA is a delegating router, and the client = & relay are located at the HA. DHCP messages are exchanged through = the MR-HA tunnel.

If the HA were a requesting = router, I guess the testbed, implementation and interaction with the = mobility daemon would be completely different, so I can't really tell = how I would change the current = one.


If HA is a requesting router, all you need at the HA is DHCP = Client (and possibly colocated with relay if the delegating router is = not on-link) 

I guess you refer to = the solution exposed in draft-sarikaya-mext-prefix-delegation? This = one suppose that the prefix delegation at the MR happens with BU/BAck = messages, which is not the case in our = implementation.

Note that I do not discuss here = which solution is the best, but only present feedback from = implementation of one of the solution. If I had chosen the delegation = through the BU/BAck, I would certainly have coupled it with a DHCP = server as you describe in your = draft.


So I believe, in fact you are agreeing with = Ryuji.

<= /div>Agreeing on what point = ? 


Regards,
=
kuntz@lsiit.u-strasbg.fr
LSIIT - Networks and Protocols Team

= --Apple-Mail-6--228428415-- --===============0416402550== 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 --===============0416402550==-- From mext-bounces@ietf.org Mon Dec 15 01:49:10 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D1D3A67CC; Mon, 15 Dec 2008 01:49:10 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 350C03A67CC for ; Mon, 15 Dec 2008 01:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.539 X-Spam-Level: X-Spam-Status: No, score=-5.539 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=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 FmgdGky54DAZ for ; Mon, 15 Dec 2008 01:49:08 -0800 (PST) Received: from ws000774.tietoenator.com (ws000774.tietoenator.com [193.12.181.129]) by core3.amsl.com (Postfix) with ESMTP id 7A0AA3A67B5 for ; Mon, 15 Dec 2008 01:49:07 -0800 (PST) X-AuditID: c10cb581-000015d8000004d8-ed-4946280418c2 Received: from camaro.eu.tieto.com ([192.176.143.42]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Dec 2008 10:48:52 +0100 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Dec 2008 10:48:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 Dec 2008 10:48:34 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Removing bindings for IPv4 only - please comment Thread-Index: AclcIrfbppqowVDjTEy3HFmjbORgHQAC7YeQAAn3hrsAA5HPwAAB3yfLAIq2CbA= References: From: To: , X-OriginalArrivalTime: 15 Dec 2008 09:48:56.0194 (UTC) FILETIME=[58A4CE20:01C95E9A] X-Brightmail-Tracker: AAAAAA== Cc: julien.laganier.ietf@googlemail.com, jari.arkko@piuha.net Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Thanks for the response. Just a detail: The binding update specified in your response, is that with or without the UDP header using DSMIP ports? I agree the mobile node could equally well move to an IPv4 foreign link, and in that case the home agent would have the bindings (1') v6HoA -> v4CoA (2') v4HoA -> v4CoA just the binding update would be different, namely BU IPv4 Header src = v4CoA UDP Header with DSMIP ports IPv6 Header src = v6HoA lifetime > 0 IPv4 Home Address v4HoA IPv4 Care-of Address v4CoA So, going back to the original mail, Karens original suggestion was a way to handle both of the two situations: (a) an IPv6-only home link continuing IPv4 communication, and (b) an IPv4-only home link continuing IPv6 communication. (b) is now part of DSMIP, while (a) should be dealt with in draft-premec-mext-extended-home-link. In a sense, in case (b) the IPv4-only home link is treated like any other IPv4-only foreign link. Suppose IPv6 payload traffic is IPsec protected between v4CoA and v4HA. Is the IPv4-only home link really like a truly foreign link so IPsec protection should be used, or is the IPv4-only home more like a home link where IPv6 payload traffic is not IPsec protected, thus only IPv6-in-IPv4 tunnel encapsulation is to be used? Christian > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: 12. december 2008 16:13 > To: Kaas-Petersen Christian; mext@ietf.org > Cc: jari.arkko@piuha.net; julien.laganier.ietf@googlemail.com > Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment > > > > > > I understood the text as a useful clarification. I > understood it this > > way. When a mobile node moves to an IPv6 foreign network, > and there > > obtains the v6CoA address, it sends a binding update > > > > BU > > src = v6CoA > > Destination Option with v6HoA > > lifetime > 0 > > Alternate Care-of Address v6CoA > > IPv4 Home Address v4HoA > > > > to the home agent, and the home agent will in its binding > cache insert > > two entries > > > > (1) v6HoA -> v6CoA > > (2) v4HoA -> v6CoA > > => That's the current draft yes. I'm not sure why you're > referring to IPv6 foreign networks only. The same applies to > IPv4 networks. > > > > > The clarification to me was then, that the mobile node, > while at this > > foreign IPv6 network, could ask the home agent to remove > both of the > > bindings by sending > > > > BU > > src = v6CoA > > Destination Option with v6HoA > > lifetime = 0 > > > > or could ask the home agent to remove the IPv4 binding > (retaining the > > IPv6 binding) by sending > > > > BU > > src = v6CoA > > Destination Option with v6HoA > > lifetime > 0 > > Alternate Care-of Address v6CoA > > > > > > I'll go back to the situation where the binding cache has > entries (1) > > and (2). If the mobile node moves to an IPv6-only link > where it gets > > only the v6HoA address, and wants to continue using v4HoA, then the > > home agent's binding cache should be provided with the entry > > > > (a) v4HoA -> v6HoA > > => This wasn't part of the text I sent. > > > > > Or the other situation, the mobile node moves to an IPv4-only link > > getting only v4HoA, the binding cache should be provided with the > > entry > > > > (b) v6HoA -> v4HoA > > => For b) you would send > > src = v4addr > dst = HA > src = V6HoA > dst = V6HA > BU message > v4 alt CoA option containing v4addr > > > Hesham > > > > > > Maybe you could help me sorting out: what is the contents of the > > binding updates to be sent to the home agent in the two > situations? > > And are both situations covered with the DSMIP specification? > > > > Christian > > > > > >> -----Original Message----- > >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] > >> Sent: 12. december 2008 13:37 > >> To: Kaas-Petersen Christian; mext@ietf.org > >> Cc: jari.arkko@piuha.net; julien.laganier.ietf@googlemail.com > >> Subject: Re: [MEXT] Removing bindings for IPv4 only - > please comment > >> > >> > >>> Fine with the addition. The original suggestion of Karen, now > >>> described in draft-premec-mext-extended-home-link, is something > >>> different, namely maintaining both IPv4 and IPv6 home > >> addresses on a > >>> home link which gives native support for either IPv4 or IPv6. > >>> Suppose the home link supports only IPv4. The home agent > >> will remove > >>> the entry for the v4HoA address, retaining the entry for > the v6HoA, > >>> and this entry will indicate packets for v6HoA will have to be > >>> IP-in-IP tunneled to v4HoA. > >> > >> => Right, but this is what the text I sent does. It removes the v4 > >> binding and keeps the IPv6 binding. If the link is > >> IPv4 only then it will bind the > >> v6 HoA to that IPv4 address. > >> > >> Hesham > >> > >>> > >>> Christian > >>> > >>>> -----Original Message----- > >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > >> On Behalf > >>>> Of Hesham Soliman > >>>> Sent: 12. december 2008 07:28 > >>>> To: mext@ietf.org > >>>> Cc: Jari Arkko; Julien Laganier > >>>> Subject: [MEXT] Removing bindings for IPv4 only - please comment > >>>> > >>>> Hi all, > >>>> > >>>> Gerardo requested that we consider the issue of removing > >> an IPv4-only > >>>> bindings in the spec. We discussed this with the chairs > >> and it seemed > >>>> like a simple add-on to the spec. I'm still wondering if > >> this is the > >>>> same thing that Karen asked for earlier and we decided to do it > >>>> separately. If it is, then I don't understand why we > >> didn't consider > >>>> the following solution (can't remember if I suggested it before). > >>>> > >>>> I've added the following text to the draft, please let me > >> know if you > >>>> have any comments ASAP. I want to submit this version on > >> the weekend > >>>> if possible. > >>>> All the IESG comments have been included. It's pretty straight > >>>> forward and follows standard MIPv6 logic. > >>>> > >>>>
> >>>> > >>>> Mobile nodes will remove bindings from the home > agent's binding > >>>> cache whenever they move to the home link, or simply > when mobility > >>>> support is not needed. > >>>> > >>>> De-registering the IPv6 home address is described in >>>> target="RFC3775"/>. The same mechanism applies in this > >> specification. > >>>> Mobile nodes may remove the binding for the > >>>> IPv4 home address only, by sending a binding update that > does not > >>>> include the IPv4 home address option. Upon receiving > this binding > >>>> update, the home agent will replace the existing cache > >> entries with > >>>> the content of the new message. This ensures that the > >>>> IPv4 home address binding is removed, while maintining an > >>>> IPv6 binding. > >>>> > >>>> Note that the mobile node cannot remove the IPv6 home address > >>>> binding while maintaining an IPv4 home address binding. > >>>> > >>>> A binding update message with a lifetime of zero, will > >> remove all > >>>> bindings for the mobile node.
> >>>> > >>>> Hesham > >>>> > >>>> > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext > >>>> > >> > >> > >> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 15 02:12:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B57293A6832; Mon, 15 Dec 2008 02:12:03 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D267E3A67CC for ; Mon, 15 Dec 2008 02:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.656 X-Spam-Level: X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3zUp+ND4Qat for ; Mon, 15 Dec 2008 02:12:01 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 37CC63A6800 for ; Mon, 15 Dec 2008 02:12:00 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LCAQX-0007Bg-Jn; Mon, 15 Dec 2008 21:11:50 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Mon, 15 Dec 2008 21:11:41 +1100 From: Hesham Soliman To: , Message-ID: Thread-Topic: [MEXT] Removing bindings for IPv4 only - please comment Thread-Index: AclcIrfbppqowVDjTEy3HFmjbORgHQAC7YeQAAn3hrsAA5HPwAAB3yfLAIq2CbAAAaeFlA== In-Reply-To: Mime-version: 1.0 Cc: julien.laganier.ietf@googlemail.com, jari.arkko@piuha.net Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > Thanks for the response. Just a detail: The binding update > specified in your response, is that with or without the UDP > header using DSMIP ports? => Yes of course with UDP, it's always in UDP when the MN is in an IPv4 network. > > I agree the mobile node could equally > well move to an IPv4 foreign link, and in that case the home > agent would have the bindings > > (1') v6HoA -> v4CoA > (2') v4HoA -> v4CoA > > just the binding update would be different, namely > > BU > IPv4 Header src = v4CoA > UDP Header with DSMIP ports > IPv6 Header src = v6HoA > lifetime > 0 > IPv4 Home Address v4HoA > IPv4 Care-of Address v4CoA > > So, going back to the original mail, Karens original suggestion > was a way to handle both of the two situations: > > (a) an IPv6-only home link continuing IPv4 communication, and => You can't deregister the IPv6 home address and maintain any type of SA with the HA. I.e. no v6HoA = no binding. > (b) an IPv4-only home link continuing IPv6 communication. => That's the text I sent. > > (b) is now part of DSMIP, while (a) should be dealt with in > draft-premec-mext-extended-home-link. > > In a sense, in case (b) the IPv4-only home link is treated like > any other IPv4-only foreign link. Suppose IPv6 payload traffic is > IPsec protected between v4CoA and v4HA. Is the IPv4-only home > link really like a truly foreign link so IPsec protection should > be used, or is the IPv4-only home more like a home > link where IPv6 payload traffic is not IPsec protected, thus only > IPv6-in-IPv4 tunnel encapsulation is to be used? => There is no correlation between the home link and IPsec. You can protect IPv6 traffic with IPsec anywhere. I assume you want to only protect it to the HA, which would be fine in the scenario above because it thinks it's not home anyway. Hesham > > Christian > > >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: 12. december 2008 16:13 >> To: Kaas-Petersen Christian; mext@ietf.org >> Cc: jari.arkko@piuha.net; julien.laganier.ietf@googlemail.com >> Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment >> >> >> >> >>> I understood the text as a useful clarification. I >> understood it this >>> way. When a mobile node moves to an IPv6 foreign network, >> and there >>> obtains the v6CoA address, it sends a binding update >>> >>> BU >>> src = v6CoA >>> Destination Option with v6HoA >>> lifetime > 0 >>> Alternate Care-of Address v6CoA >>> IPv4 Home Address v4HoA >>> >>> to the home agent, and the home agent will in its binding >> cache insert >>> two entries >>> >>> (1) v6HoA -> v6CoA >>> (2) v4HoA -> v6CoA >> >> => That's the current draft yes. I'm not sure why you're >> referring to IPv6 foreign networks only. The same applies to >> IPv4 networks. >> >>> >>> The clarification to me was then, that the mobile node, >> while at this >>> foreign IPv6 network, could ask the home agent to remove >> both of the >>> bindings by sending >>> >>> BU >>> src = v6CoA >>> Destination Option with v6HoA >>> lifetime = 0 >>> >>> or could ask the home agent to remove the IPv4 binding >> (retaining the >>> IPv6 binding) by sending >>> >>> BU >>> src = v6CoA >>> Destination Option with v6HoA >>> lifetime > 0 >>> Alternate Care-of Address v6CoA >> >> >>> >>> I'll go back to the situation where the binding cache has >> entries (1) >>> and (2). If the mobile node moves to an IPv6-only link >> where it gets >>> only the v6HoA address, and wants to continue using v4HoA, then the >>> home agent's binding cache should be provided with the entry >>> >>> (a) v4HoA -> v6HoA >> >> => This wasn't part of the text I sent. >> >>> >>> Or the other situation, the mobile node moves to an IPv4-only link >>> getting only v4HoA, the binding cache should be provided with the >>> entry >>> >>> (b) v6HoA -> v4HoA >> >> => For b) you would send >> >> src = v4addr >> dst = HA >> src = V6HoA >> dst = V6HA >> BU message >> v4 alt CoA option containing v4addr >> >> >> Hesham >> >> >>> >>> Maybe you could help me sorting out: what is the contents of the >>> binding updates to be sent to the home agent in the two >> situations? >>> And are both situations covered with the DSMIP specification? >>> >>> Christian >>> >>> >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: 12. december 2008 13:37 >>>> To: Kaas-Petersen Christian; mext@ietf.org >>>> Cc: jari.arkko@piuha.net; julien.laganier.ietf@googlemail.com >>>> Subject: Re: [MEXT] Removing bindings for IPv4 only - >> please comment >>>> >>>> >>>>> Fine with the addition. The original suggestion of Karen, now >>>>> described in draft-premec-mext-extended-home-link, is something >>>>> different, namely maintaining both IPv4 and IPv6 home >>>> addresses on a >>>>> home link which gives native support for either IPv4 or IPv6. >>>>> Suppose the home link supports only IPv4. The home agent >>>> will remove >>>>> the entry for the v4HoA address, retaining the entry for >> the v6HoA, >>>>> and this entry will indicate packets for v6HoA will have to be >>>>> IP-in-IP tunneled to v4HoA. >>>> >>>> => Right, but this is what the text I sent does. It removes the v4 >>>> binding and keeps the IPv6 binding. If the link is >>>> IPv4 only then it will bind the >>>> v6 HoA to that IPv4 address. >>>> >>>> Hesham >>>> >>>>> >>>>> Christian >>>>> >>>>>> -----Original Message----- >>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] >>>> On Behalf >>>>>> Of Hesham Soliman >>>>>> Sent: 12. december 2008 07:28 >>>>>> To: mext@ietf.org >>>>>> Cc: Jari Arkko; Julien Laganier >>>>>> Subject: [MEXT] Removing bindings for IPv4 only - please comment >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Gerardo requested that we consider the issue of removing >>>> an IPv4-only >>>>>> bindings in the spec. We discussed this with the chairs >>>> and it seemed >>>>>> like a simple add-on to the spec. I'm still wondering if >>>> this is the >>>>>> same thing that Karen asked for earlier and we decided to do it >>>>>> separately. If it is, then I don't understand why we >>>> didn't consider >>>>>> the following solution (can't remember if I suggested it before). >>>>>> >>>>>> I've added the following text to the draft, please let me >>>> know if you >>>>>> have any comments ASAP. I want to submit this version on >>>> the weekend >>>>>> if possible. >>>>>> All the IESG comments have been included. It's pretty straight >>>>>> forward and follows standard MIPv6 logic. >>>>>> >>>>>>
>>>>>> >>>>>> Mobile nodes will remove bindings from the home >> agent's binding >>>>>> cache whenever they move to the home link, or simply >> when mobility >>>>>> support is not needed. >>>>>> >>>>>> De-registering the IPv6 home address is described in >>>>> target="RFC3775"/>. The same mechanism applies in this >>>> specification. >>>>>> Mobile nodes may remove the binding for the >>>>>> IPv4 home address only, by sending a binding update that >> does not >>>>>> include the IPv4 home address option. Upon receiving >> this binding >>>>>> update, the home agent will replace the existing cache >>>> entries with >>>>>> the content of the new message. This ensures that the >>>>>> IPv4 home address binding is removed, while maintining an >>>>>> IPv6 binding. >>>>>> >>>>>> Note that the mobile node cannot remove the IPv6 home address >>>>>> binding while maintaining an IPv4 home address binding. >>>>>> >>>>>> A binding update message with a lifetime of zero, will >>>> remove all >>>>>> bindings for the mobile node.
>>>>>> >>>>>> Hesham >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>> >>>> >>>> >> >> >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mjgrkfgg@advancemold.com Mon Dec 15 02:28: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 53BD83A68DE for ; Mon, 15 Dec 2008 02:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.419 X-Spam-Level: X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUaLnxgcZdsI for ; Mon, 15 Dec 2008 02:28:18 -0800 (PST) Received: from host-64-139-238-41.nctv.com (host-64-139-238-41.nctv.com [64.139.238.41]) by core3.amsl.com (Postfix) with SMTP id 43ABC3A6836 for ; Mon, 15 Dec 2008 02:28:16 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081215102817.43ABC3A6836@core3.amsl.com> Date: Mon, 15 Dec 2008 02:28:16 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mext-bounces@ietf.org Mon Dec 15 03:28:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A604E3A68D4; Mon, 15 Dec 2008 03:28:25 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE48B3A68D4 for ; Mon, 15 Dec 2008 03:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 STIWOzvQ2Ygg for ; Mon, 15 Dec 2008 03:28:22 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with SMTP id 89AB73A68A5 for ; Mon, 15 Dec 2008 03:28:22 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1229340494!37358186!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 24082 invoked from network); 15 Dec 2008 11:28:14 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-119.messagelabs.com with SMTP; 15 Dec 2008 11:28:14 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBFBSECe007510; Mon, 15 Dec 2008 04:28:14 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id mBFBSDu5023911; Mon, 15 Dec 2008 05:28:13 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id mBFBSC80023900; Mon, 15 Dec 2008 05:28:13 -0600 (CST) Message-ID: <49463F4C.6040306@gmail.com> Date: Mon, 15 Dec 2008 12:28:12 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Ryuji Wakikawa References: <491039B9.6090400@it.uc3m.es> <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> <200812111050.19715.julien.laganier.IETF@googlemail.com> <4B8E03A1-432A-49F9-8DA0-98EF582620FD@lsiit.u-strasbg.fr> In-Reply-To: X-Antivirus: avast! (VPS 081214-0, 14/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU X-BeenThere: mext@ietf.org X-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 Ryuji Wakikawa wrote: > > On 2008/12/11, at 17:36, Romain KUNTZ wrote: > >> Hi Ryuji, >> >> On 2008/12/11, at 17:26, Ryuji Wakikawa wrote: >>> For this purpose, the mobile router needs to act as a RFC3775 >>> compliant mobile host before starting DHCP-PD. Why? If there is >>> no prefix, the mobile router cannot sends a NEMO-BU (i.e. R-flag >>> set) to its Home Agent. If there is no valid prefix for the >>> mobile router, HA returns BA with "Invalid Prefix" status value >>> which is treated as the fatal error in RFC3963. >> >> I'd say the MR still sends a BU with the R-flag set and without the >> MNP option, which will be considered as registration in Implicit >> mode by the HA. > > Implicit mode requires some mapping between a mobile network prefix > and a mobile router. For clarification: yes the Implicit mode requires a mapping between the Mobile Network Prefix and the Home Address of the Mobile Router. This mapping exists already in the routing table of (at least) the HA, otherwise HA can't reach the MR when MR at home. It is not a mapping that should be found or created, it exists already. Alex > > Implicit: > > In this mode, the Mobile Router does not include a Mobile Network > Prefix Option in the Binding Update. The Home Agent can use any > mechanism (not defined in this document) to determine the Mobile > Network Prefix(es) owned by the Mobile Router and to set up > forwarding for the Mobile Network. One example would be manual > configuration at the Home Agent mapping the Mobile Router's Home > Address to the information required for setting up forwarding for the > Mobile Network. > > > In RFC3963, we didn't consider a MR who doesn't have any mobile > network prefix sends BU with R-flag set. In implicit mode, if there > is no prefix for the MR, HA will reject the BU. > > regards, ryuji > > >> >> >> Cheers, romain >> >> >> >>> On 2008/12/11, at 10:50, Julien Laganier wrote: >>> >>>> We had this discussion for a long time abd it has concluded >>>> some time ago already: WG consensus is to use DHCP PD. >>>> >>>> (w/o questioning the value of optimizing RTTs for a procedure >>>> which isn't in a critical path, e.g., handover) >>>> >>>> --julien >>>> >>>> On Thursday 11 December 2008, Yungui Wang wrote: >>>>> Hello >>>>> >>>>> Here is one comment about using MR-HA tunnel for DHCP-PD. >>>>> >>>>> In this draft, the MR registration processing needs 3 round >>>>> trip between MR and HA. i. BU to HA; (getting and binding >>>>> MR_HoA) ii. DHCPv6 message over MR-HA tunnel. (getting MNP) >>>>> iii. BU to HA; (binding MNP) While, if PD is combined within >>>>> BU, it is only 1 round trip. >>>>> >>>>> From implementation of viewpoint, the later seems well done >>>>> prior of the former. Maybe I have lost something, can anyone >>>>> tell me the story why we gave up the latter in the new >>>>> version? Thanks. >>>>> >>>>> B.R. Yungui >>>>> >>>>> >>>>> ----- Original Message ----- From: marcelo bagnulo braun To: >>>>> mext ; Julien Laganier ; Ralph Droms Sent: Tuesday, November >>>>> 04, 2008 8:02 PM Subject: [MEXT] WGLC for >>>>> draft-ietf-mext-nemo-pd-01.txt >>>>> >>>>> >>>>> Hi, >>>>> >>>>> We now start the WGLC for: >>>>> >>>>> DHCPv6 Prefix Delegation for NEMO >>>>> draft-ietf-mext-nemo-pd-01.txt >>>>> >>>>> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt >>>>> >>>>> >>>>> >>>>> Please send comments about the draft till the November 19. >>>>> >>>>> Regards, Julien and marcelo >>>>> >>>>> >>>>> _______________________________________________ MEXT mailing >>>>> list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >>>>> >>>> >>>> >>>> >>>> -- --julien >>>> >>>> [ New email address: julien.laganier.IETF@googlemail.com ] >>>> _______________________________________________ MEXT mailing >>>> list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >>> >>> _______________________________________________ MEXT mailing list >>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >>> >> > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 15 03:28: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 2CEFC3A692D; Mon, 15 Dec 2008 03:28:52 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ACD63A68A5 for ; Mon, 15 Dec 2008 03:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 VFJgymGWIBmJ for ; Mon, 15 Dec 2008 03:28:50 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 22B5D3A695C for ; Mon, 15 Dec 2008 03:28:49 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1229340522!24200820!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9614 invoked from network); 15 Dec 2008 11:28:42 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-128.messagelabs.com with SMTP; 15 Dec 2008 11:28:42 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBFBSgou007572; Mon, 15 Dec 2008 04:28:42 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id mBFBSfxG024106; Mon, 15 Dec 2008 05:28:41 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id mBFBSeGW024094; Mon, 15 Dec 2008 05:28:41 -0600 (CST) Message-ID: <49463F68.7060203@gmail.com> Date: Mon, 15 Dec 2008 12:28:40 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Ryuji Wakikawa References: <491039B9.6090400@it.uc3m.es> <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> <200812111050.19715.julien.laganier.IETF@googlemail.com> <4B8E03A1-432A-49F9-8DA0-98EF582620FD@lsiit.u-strasbg.fr> <5ABF4AC2-F69D-4545-BEC8-B62E569FB020@gmail.com> In-Reply-To: <5ABF4AC2-F69D-4545-BEC8-B62E569FB020@gmail.com> X-Antivirus: avast! (VPS 081214-0, 14/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ryuji Wakikawa wrote: > Romain > > One more comment. > > The implicit and explicit modes cannot be switched dynamically, neither. Yes, I fully agree. (just for clarification). Alex > > Section 5.2 > A Mobile Router MUST implement at least one mode and MAY implement > both. In the latter case, local configuration on the Mobile Router > decides which mode to use. This is out of scope for this document. > > If the Mobile Router Flag is set, the Home Registration Flag (H) MUST > be set. > > If the Mobile Router has a valid binding cache entry at the Home > Agent, subsequent Binding Updates for the same Home Address should > have the same value as the value in the binding cache for the Mobile > Router Flag (R). In explicit mode, the Mobile Router MUST include > prefix information in all Binding Updates, including those sent to > refresh existing binding cache entries, if it wants forwarding > enabled for the corresponding Mobile Network Prefixes. > > regards, > ryuji > > On 2008/12/11, at 17:36, Romain KUNTZ wrote: > >> Hi Ryuji, >> >> On 2008/12/11, at 17:26, Ryuji Wakikawa wrote: >>> For this purpose, the mobile router needs to act as a RFC3775 >>> compliant mobile host before starting DHCP-PD. Why? If there is no >>> prefix, the mobile router cannot sends a NEMO-BU (i.e. R-flag set) to >>> its Home Agent. If there is no valid prefix for the mobile router, HA >>> returns BA with "Invalid Prefix" status value which is treated as the >>> fatal error in RFC3963. >> >> I'd say the MR still sends a BU with the R-flag set and without the >> MNP option, which will be considered as registration in Implicit mode >> by the HA. >> >> Cheers, >> romain >> >> >> >>> On 2008/12/11, at 10:50, Julien Laganier wrote: >>> >>>> We had this discussion for a long time abd it has concluded some time >>>> ago already: WG consensus is to use DHCP PD. >>>> >>>> (w/o questioning the value of optimizing RTTs for a procedure which >>>> isn't in a critical path, e.g., handover) >>>> >>>> --julien >>>> >>>> On Thursday 11 December 2008, Yungui Wang wrote: >>>>> Hello >>>>> >>>>> Here is one comment about using MR-HA tunnel for DHCP-PD. >>>>> >>>>> In this draft, the MR registration processing needs 3 round trip >>>>> between MR and HA. i. BU to HA; (getting and binding MR_HoA) >>>>> ii. DHCPv6 message over MR-HA tunnel. (getting MNP) >>>>> iii. BU to HA; (binding MNP) >>>>> While, if PD is combined within BU, it is only 1 round trip. >>>>> >>>>> From implementation of viewpoint, the later seems well done prior of >>>>> the former. Maybe I have lost something, can anyone tell me the story >>>>> why we gave up the latter in the new version? Thanks. >>>>> >>>>> B.R. >>>>> Yungui >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: marcelo bagnulo braun >>>>> To: mext ; Julien Laganier ; Ralph Droms >>>>> Sent: Tuesday, November 04, 2008 8:02 PM >>>>> Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt >>>>> >>>>> >>>>> Hi, >>>>> >>>>> We now start the WGLC for: >>>>> >>>>> DHCPv6 Prefix Delegation for NEMO >>>>> draft-ietf-mext-nemo-pd-01.txt >>>>> >>>>> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt >>>>> >>>>> >>>>> Please send comments about the draft till the November 19. >>>>> >>>>> Regards, Julien and marcelo >>>>> >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>>> >>>> -- >>>> --julien >>>> >>>> [ New email address: julien.laganier.IETF@googlemail.com ] >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 15 03:49: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 871E53A698E; Mon, 15 Dec 2008 03:49:52 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C3963A69DD for ; Mon, 15 Dec 2008 03:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 XlFx98FqkvvA for ; Mon, 15 Dec 2008 03:49:50 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by core3.amsl.com (Postfix) with ESMTP id 892FF3A6844 for ; Mon, 15 Dec 2008 03:49:50 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b11so519607nfh.39 for ; Mon, 15 Dec 2008 03:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:from; bh=jCYU18pyGsW2L5IvTEh9zISD3TaCP1d+KLtyKYWNCA0=; b=TqhLPZ9cSrBYiu/XK3EvKGbZbotn6X8y0ufVPoMrktS5Hgba7dvEMca+yWY8GTvLgW 1RgfVFMH7wFsDZi7JQxWY7fWBGWdr3rDen7cF8kBtBR9lD2i10HUU4REHvNyKCJ9xSXi JiSTNhGAa/jYVN3WhQMpKLygmn8wvM/VC8Fs4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:cc:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; b=OGq4bngo0dqY9M1+MaNW3xezUox5FI+17Ffx0QiWgPp9uLqMA4wHpkm9uxmQm864eB 9vIRiGOu36x2LvBbrMj4G/U9f3Z6YzqrppZkb+7/lj6Jsr/g9BWZMOXFc+qkKf661inI EEb7UbaoMDkZcACr6Fd0JfkzeSeuBo1SdCNt8= Received: by 10.210.82.2 with SMTP id f2mr7635318ebb.82.1229341782861; Mon, 15 Dec 2008 03:49:42 -0800 (PST) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id p10sm125251gvf.7.2008.12.15.03.49.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Dec 2008 03:49:41 -0800 (PST) To: mext@ietf.org Date: Mon, 15 Dec 2008 12:50:01 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200812151250.02020.julien.laganier.IETF@googlemail.com> From: Julien Laganier Subject: [MEXT] DRAFT meeting minutes X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello, Below are the draft meeting minutes for the two MEXT sessions at IETF-73. Please let us note your comments by Dec. 18th, if any: --julien & marcelo, MEXT chairs _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 15 03:53: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 302ED3A69B1; Mon, 15 Dec 2008 03:53:11 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B93233A69B1 for ; Mon, 15 Dec 2008 03:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 0R3YYtDKd4c0 for ; Mon, 15 Dec 2008 03:53:08 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with SMTP id 5324C3A68D4 for ; Mon, 15 Dec 2008 03:53:08 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1229341981!29342553!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19497 invoked from network); 15 Dec 2008 11:53:01 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with SMTP; 15 Dec 2008 11:53:01 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBFBqvSD012496; Mon, 15 Dec 2008 04:52:57 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id mBFBquHv029589; Mon, 15 Dec 2008 05:52:56 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id mBFBqs20029539; Mon, 15 Dec 2008 05:52:54 -0600 (CST) Message-ID: <49464516.9020505@gmail.com> Date: Mon, 15 Dec 2008 12:52:54 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: fan zhao References: <491039B9.6090400@it.uc3m.es> <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> <200812111050.19715.julien.laganier.IETF@googlemail.com> <49414E42.9040106@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 081214-0, 14/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext Subject: Re: [MEXT] DHCPv6-PD for NEMOv6 MR (was: using MR-HA tunnel vs. combining BU ) X-BeenThere: mext@ietf.org X-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 fan zhao wrote: > Hi Alex, > > Please see below. > > On Thu, Dec 11, 2008 at 9:30 AM, Alexandru Petrescu > wrote: >> Ryuji Wakikawa wrote: >>> Hi Julien and Yungui, >>> >>> Actually, it's not only 3 round trip and is not optimization problem.. >>> This is a big issue of DHCP-PD. >>> >>> Let me explain the issue clearly. >>> >>> According to the NEMO-DHCP-PD spec, before receiving a prefix, >>> a mobile router must create a tunnel with its HA. >> Not sure about this necessity? Where does this nemo-dhcp-pd draft say so? > Please see section 3.2. Use of MR-HA tunnel for DHCPv6 messages. Well, yes in a sense, but it depends. The DHCPv6 messages that have dst a multicast address are actually only one - the DHCPv6 Solicit I believe. It is multicasted when the DHCP Client doesn't know the address of the DHCP Server. Or, if we consider the HA to be the DHCP Server, and if the MR has already discovered the address of the HA (maybe with DHAAD) then this multicasted Solicit isn't necessary - DHCPv6 Request/Reply exchanges are sufficient, and they're unicasted. [...] >> It is obvious that we disagree on the sequence of the exchanged messages >> (DHCP, BU/BAck) and I think we need to draw a diagram with the message >> exchanges that we consider. I could draw mine. > > Please do. Thanks a lot. HEre's a diagram of messages exchanged for MR and HA, for prefix delegation, which I believe makes some sense at least to me. If you think DHAAD/MPD shouldn't be used then I may agree, but I don't know the names of the DNS messages. If somebody else agrees please say so, or otherwise say why not, or draw a separate diagrap - we hopefully could join them together. Problem: MR needs to find out its HoA and its Mobile Network Prefix. MR HA | DHAAD Address Request | |-------------------------------o| (anycast'ed) | DHAAD Reply | |<------------------------------ | | Mobile Prefix Solicitation | |------------------------------->| | Mobile Prefix Advertisement | |<-------------------------------| (MR forms | | its HoA) | DHCPv6 Request | |------------------------------->| (unicast'ed, | DHCPv6 Reply (contains MNP) | non-tunneled) |<-------------------------------| (MR knows | | its MNP) | BU R-flag (eventually MNP) | |------------------------------->| | BAck | |<------------------------------ | | | | ------------------------------ | |<..............................>| (tunnelled traffic) | ------------------------------ | | | | | | | | | | | | | | | | | | | Thanks, Alex > > Sincerely, > fan > >> Alex >> >> If there is no valid prefix for the mobile router, HA >>> returns BA with "Invalid Prefix" status value which is treated as the >>> fatal error in RFC3963. >>> >>> Well, RFC3963 allows for a mobile router to act as a mobile host, but >>> we didn't assume that a mobile router switches its mode between >>> RFC3775-mobile-host and RFC3963-mobile-router dynamically. >>> >>> For instance, RFC3963 said in section 6.2, >>> "If the Home Agent has a valid binding cache entry for the Mobile >>> Router, and if the Binding Update has the Mobile Router Flag (R) set >>> to a value different from that in the existing binding cache entry, >>> then the Home Agent MUST reject the Binding Update and send a Binding >>> Acknowledgement with status set to 139 (Registration type change >>> disallowed). However, if the Binding Update is a de-registration >>> Binding Update, the Home Agent ignores the value of the Mobile Router >>> Flag (R)." >>> >>> At the end, how the boostrapping goes? >>> >>> 1. MR acts as a MN and sends MIP6-BU (Rflag unset) to establish a >>> tunnel for DHCP-PD >>> 2. MR starting DHCP-PD >>> 3. After DHCP-PD completion, MR de-registers the RFC3775-binding >>> 4. MR sends NEMO-BU (R-flag finally set) for its mobile network prefix >>> acquired by DHCP-PD >>> >>> I don't think this is right way to go.... >>> >>> I now changed my mind that the use of BU/BA is more straightforward >>> for NEMO prefix delegation. >>> >>> ryuji >>> >>> >>> On 2008/12/11, at 10:50, Julien Laganier wrote: >>> >>>> We had this discussion for a long time abd it has concluded some time >>>> ago already: WG consensus is to use DHCP PD. >>>> >>>> (w/o questioning the value of optimizing RTTs for a procedure which >>>> isn't in a critical path, e.g., handover) >>>> >>>> --julien >>>> >>>> On Thursday 11 December 2008, Yungui Wang wrote: >>>>> Hello >>>>> >>>>> Here is one comment about using MR-HA tunnel for DHCP-PD. >>>>> >>>>> In this draft, the MR registration processing needs 3 round trip >>>>> between MR and HA. i. BU to HA; (getting and binding MR_HoA) >>>>> ii. DHCPv6 message over MR-HA tunnel. (getting MNP) >>>>> iii. BU to HA; (binding MNP) >>>>> While, if PD is combined within BU, it is only 1 round trip. >>>>> >>>>> From implementation of viewpoint, the later seems well done prior of >>>>> the former. Maybe I have lost something, can anyone tell me the story >>>>> why we gave up the latter in the new version? Thanks. >>>>> >>>>> B.R. >>>>> Yungui >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: marcelo bagnulo braun >>>>> To: mext ; Julien Laganier ; Ralph Droms >>>>> Sent: Tuesday, November 04, 2008 8:02 PM >>>>> Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt >>>>> >>>>> >>>>> Hi, >>>>> >>>>> We now start the WGLC for: >>>>> >>>>> DHCPv6 Prefix Delegation for NEMO >>>>> draft-ietf-mext-nemo-pd-01.txt >>>>> >>>>> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt >>>>> >>>>> >>>>> Please send comments about the draft till the November 19. >>>>> >>>>> Regards, Julien and marcelo >>>>> >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>>> -- >>>> --julien >>>> >>>> [ New email address: julien.laganier.IETF@googlemail.com ] >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> >> ______________________________________________________________________ >> 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 >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 15 03:57: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 12FB13A69DD; Mon, 15 Dec 2008 03:57:36 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFE023A6998 for ; Mon, 15 Dec 2008 03:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 9j0D58KQlMLD for ; Mon, 15 Dec 2008 03:57:33 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 799983A68D4 for ; Mon, 15 Dec 2008 03:57:33 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-153.messagelabs.com!1229342245!28470571!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14211 invoked from network); 15 Dec 2008 11:57:25 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-153.messagelabs.com with SMTP; 15 Dec 2008 11:57:25 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBFBvP17013219; Mon, 15 Dec 2008 04:57:25 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id mBFBvPoF011036; Mon, 15 Dec 2008 05:57:25 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id mBFBvNTQ011029; Mon, 15 Dec 2008 05:57:24 -0600 (CST) Message-ID: <49464623.3000906@gmail.com> Date: Mon, 15 Dec 2008 12:57:23 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Yungui Wang References: <491039B9.6090400@it.uc3m.es> <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> <200812111050.19715.julien.laganier.IETF@googlemail.com> <00f401c95c03$67a1bd00$150ca40a@china.huawei.com> In-Reply-To: <00f401c95c03$67a1bd00$150ca40a@china.huawei.com> X-Antivirus: avast! (VPS 081214-0, 14/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Yungui Wang wrote: > Hi Ryuji and all > > Thanks for your detailed explanation. > > My concern is MNP and MR_HoA can be assigned to MR at the same time, > special for the aggregated prefix. While, in the mip-split case, the > HoA is assigned to MR through BU/BA procedure. Just for clarification, I don't think the mip-split bootstrapping procedure (rfc5026) assigns a HoA through BU/BAck exchanges - I think it uses IKEv2 messages, or CGA 'auto' configuration. > Thus, the MNP assigned through BU/BA procedure can be supported too. > That's my simple logic. For better understanding, one would draw a diagram of message exchanges to see how the HoA and MNP are assigned, and see the constraints, etc. We could discuss with it. > Complying with rfc3775 which allows the HoA assignment via either > split or integrated bootstrapping, maybe we could consider to fix > rfc3963 and let it more open - not limit which mechanism used for PD. Hmmm... maybe... Alex > > > > B.R. Yungui > > ----- Original Message ----- > > *From:* Ryuji Wakikawa *To:* Julien > Laganier *Cc:* Yungui > Wang ; mext ; Sri > Gundavelli ; Vijay Devarapalli > *Sent:* Friday, December 12, 2008 12:26 > AM *Subject:* Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: > WGLC for draft-ietf-mext-nemo-pd-01.txt > > Hi Julien and Yungui, > > Actually, it's not only 3 round trip and is not optimization > problem.. This is a big issue of DHCP-PD. > > Let me explain the issue clearly. > > According to the NEMO-DHCP-PD spec, before receiving a prefix, a > mobile router must create a tunnel with its HA. > > For this purpose, the mobile router needs to act as a RFC3775 > compliant mobile host before starting DHCP-PD. Why? If there is no > prefix, the mobile router cannot sends a NEMO-BU (i.e. R-flag set) to > its Home Agent. If there is no valid prefix for the mobile router, > HA returns BA with "Invalid Prefix" status value which is treated as > the fatal error in RFC3963. > > Well, RFC3963 allows for a mobile router to act as a mobile host, but > we didn't assume that a mobile router switches its mode between > RFC3775-mobile-host and RFC3963-mobile-router dynamically. > > For instance, RFC3963 said in section 6.2, "If the Home Agent has a > valid binding cache entry for the Mobile Router, and if the Binding > Update has the Mobile Router Flag (R) set to a value different from > that in the existing binding cache entry, then the Home Agent MUST > reject the Binding Update and send a Binding Acknowledgement with > status set to 139 (Registration type change disallowed). However, if > the Binding Update is a de-registration Binding Update, the Home > Agent ignores the value of the Mobile Router Flag (R)." > > At the end, how the boostrapping goes? > > 1. MR acts as a MN and sends MIP6-BU (Rflag unset) to establish a > tunnel for DHCP-PD 2. MR starting DHCP-PD 3. After DHCP-PD > completion, MR de-registers the RFC3775-binding 4. MR sends NEMO-BU > (R-flag finally set) for its mobile network prefix acquired by > DHCP-PD > > I don't think this is right way to go.... > > I now changed my mind that the use of BU/BA is more straightforward > for NEMO prefix delegation. > > ryuji > > > On 2008/12/11, at 10:50, Julien Laganier wrote: > >> We had this discussion for a long time abd it has concluded some >> time ago already: WG consensus is to use DHCP PD. >> >> (w/o questioning the value of optimizing RTTs for a procedure which >> isn't in a critical path, e.g., handover) >> >> --julien >> >> On Thursday 11 December 2008, Yungui Wang wrote: >>> Hello >>> >>> Here is one comment about using MR-HA tunnel for DHCP-PD. >>> >>> In this draft, the MR registration processing needs 3 round trip >>> between MR and HA. i. BU to HA; (getting and binding MR_HoA) ii. >>> DHCPv6 message over MR-HA tunnel. (getting MNP) iii. BU to HA; >>> (binding MNP) While, if PD is combined within BU, it is only 1 >>> round trip. >>> >>> From implementation of viewpoint, the later seems well done prior >>> of the former. Maybe I have lost something, can anyone tell me >>> the > story >>> why we gave up the latter in the new version? Thanks. >>> >>> B.R. Yungui >>> >>> >>> ----- Original Message ----- From: marcelo bagnulo braun To: mext >>> ; Julien Laganier ; Ralph Droms Sent: Tuesday, November 04, 2008 >>> 8:02 PM Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt >>> >>> >>> Hi, >>> >>> We now start the WGLC for: >>> >>> DHCPv6 Prefix Delegation for NEMO draft-ietf-mext-nemo-pd-01.txt >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt >>> >>> >>> >>> >>> Please send comments about the draft till the November 19. >>> >>> Regards, Julien and marcelo >>> >>> >>> _______________________________________________ MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> >> >> -- --julien >> >> [ New email address: julien.laganier.IETF@googlemail.com > ] >> _______________________________________________ MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > > ------------------------------------------------------------------------ > > > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 15 04:00: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 AD9783A6930; Mon, 15 Dec 2008 04:00:59 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ADBD3A6930 for ; Mon, 15 Dec 2008 04:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpqNtm77qtE7 for ; Mon, 15 Dec 2008 04:00:58 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 2EBAF3A6885 for ; Mon, 15 Dec 2008 04:00:58 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-153.messagelabs.com!1229342450!28470678!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 15451 invoked from network); 15 Dec 2008 12:00:51 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-153.messagelabs.com with SMTP; 15 Dec 2008 12:00:51 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBFC0jhN013849; Mon, 15 Dec 2008 05:00:45 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id mBFC0jmY007288; Mon, 15 Dec 2008 06:00:45 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id mBFC0ipH007277; Mon, 15 Dec 2008 06:00:44 -0600 (CST) Message-ID: <494646EB.4050203@gmail.com> Date: Mon, 15 Dec 2008 13:00:43 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Julien Laganier References: <491039B9.6090400@it.uc3m.es> <200812111050.19715.julien.laganier.IETF@googlemail.com> <200812121152.04045.julien.laganier.IETF@googlemail.com> In-Reply-To: <200812121152.04045.julien.laganier.IETF@googlemail.com> X-Antivirus: avast! (VPS 081214-0, 14/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien Laganier wrote: > Hello Ryuji, > > On Thursday 11 December 2008, Ryuji Wakikawa wrote: >> Actually, it's not only 3 round trip and is not optimization >> problem.. This is a big issue of DHCP-PD. >> >> Let me explain the issue clearly. >> >> According to the NEMO-DHCP-PD spec, before receiving a prefix, a >> mobile router must create a tunnel with its HA. > > There would be no issue at all with the MR being configured as both a > DHCP client and relay, and the HA as a DHCP server: the DHCP > messages would be unicasted bewteen MR and HA without tunneling. I somehow agree. Just to say that if the goal is to have DHCP unicasted messages (avoid the DHCP Solicit) then it is sufficient for the MR to know the address of the DHCP Server in advance (presumably the HA) and send it a straight unicast DHCP Request. I doubt the necessity of having a DHCP Relay co-located with the DHCP Client (although I agree it is a suggestive illustration). > I thought that was what we agreed on and I'm seeing now the draft > still talks about multicasting into the tunnel... I agree, I have the same surprise. > I think the tunneling story (Sec. 3.2) should be removed from the > draft, and the DHCP relay configuration mode made the mandatory > method for a NEMO MR to obtain a prefix dynamically, i.e. put a > couple of SHOULD words here and there in Sec. 3.3. I agree to have unicast DHCP exchanges but not sure about the co-location Relay/Client. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 15 04:08:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B16CA3A6989; Mon, 15 Dec 2008 04:08:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFDE13A6969 for ; Mon, 15 Dec 2008 04:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 CKTnQoSGj8S8 for ; Mon, 15 Dec 2008 04:08:14 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 00C403A682F for ; Mon, 15 Dec 2008 04:08:13 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1229342886!9271730!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 31530 invoked from network); 15 Dec 2008 12:08:06 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-153.messagelabs.com with SMTP; 15 Dec 2008 12:08:06 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBFC809F015095; Mon, 15 Dec 2008 05:08:00 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id mBFC801C010577; Mon, 15 Dec 2008 06:08:00 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id mBFC7x95010564; Mon, 15 Dec 2008 06:07:59 -0600 (CST) Message-ID: <4946489F.8090509@gmail.com> Date: Mon, 15 Dec 2008 13:07:59 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Romain KUNTZ References: <491039B9.6090400@it.uc3m.es> <200812111050.19715.julien.laganier.IETF@googlemail.com> <200812121152.04045.julien.laganier.IETF@googlemail.com> In-Reply-To: X-Antivirus: avast! (VPS 081214-0, 14/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Romain KUNTZ wrote: > Hi, > > On 2008/12/12, at 11:52, Julien Laganier wrote: >> On Thursday 11 December 2008, Ryuji Wakikawa wrote: >>> >>> Actually, it's not only 3 round trip and is not optimization >>> problem.. This is a big issue of DHCP-PD. >>> >>> Let me explain the issue clearly. >>> >>> According to the NEMO-DHCP-PD spec, before receiving a prefix, a >>> mobile router must create a tunnel with its HA. >> >> There would be no issue at all with the MR being configured as both >> a DHCP client and relay, and the HA as a DHCP server: the DHCP >> messages would be unicasted bewteen MR and HA without tunneling. > > > Do you then suggest to do the prefix delegation procedure before the > NEMO registration? I think this raises multiple issues. > > First the DHCP relay would use the CoA as source address of the > message, but the DHCPv6 server may need to know the MR's HoA if it is > configured with static assignment of the MNP. I see indeed a potential worry. But in a DHCP deployment the DHCP Server is not configured with the address of the Relay (nor of the Client) - it simply replies to the address received as src field in the Request - that could be the CoA. Should be tried first I believe. > Furthermore, once the MR registers its allocated MNP to the HA, the > HA cannot verify that the MNP that is in the BU was the one that the > DHCP server allocated to that MR. To do so, the DHCP server would > need to give the HoA/MNP pair to the HA, so that it can perform a > check at registration. Why would the HA need to verify the received MNP in the BU is the same as the MNP sent in the DHCP Reply? Is there anything wrong with a security model? > By using the MR-HA tunnel, the relay message is sent using the HoA. > Also, the use of an IPsec tunnel will secure the message exchange > between the MR and the HA. I'm not sure about the security model (or threat analysis) here. We don't know the security analysis of the very first steps - the bootstrapping. If we use rfc5026 'split' bootstrapping with DNS then we may have a flawed security chain prior to this DHCP PD exchange. There may also be possible to say that if bootstrapping is used with IKEv2 and the HoA is assigned with it, then the MNP could too. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 15 04: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 AD34F3A69BC; Mon, 15 Dec 2008 04:27:33 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B823A69BC for ; Mon, 15 Dec 2008 04:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[AWL=-0.648, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=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 Co4bwPVTF+hI for ; Mon, 15 Dec 2008 04:27:31 -0800 (PST) Received: from tietoe03.tietoenator.com (mail1.tieto.com [194.110.47.24]) by core3.amsl.com (Postfix) with ESMTP id B71A33A69B7 for ; Mon, 15 Dec 2008 04:27:30 -0800 (PST) X-AuditID: c26e2f18-00001fa400000510-39-49464d5c2f03 Received: from camaro.eu.tieto.com ([192.176.143.42]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Dec 2008 14:28:12 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Dec 2008 13:27:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 Dec 2008 13:27:21 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Removing bindings for IPv4 only - please comment Thread-Index: AclcIrfbppqowVDjTEy3HFmjbORgHQAC7YeQAAn3hrsAA5HPwAAB3yfLAIq2CbAAAaeFlAAEaW3g References: From: To: , X-OriginalArrivalTime: 15 Dec 2008 12:27:22.0021 (UTC) FILETIME=[7A8EE550:01C95EB0] X-Brightmail-Tracker: AAAAAA== Cc: jari.arkko@piuha.net, julien.laganier.ietf@googlemail.com Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 am often reminded of the scarcity of resources on the radio link between the mobile phone/node and the radio base station. Suppose an operator wants to offer IPv4 and IPv6 services, but is deploying only IPv6 PDP contexts on the radio link, the home link. If I understand MIP/DSMIP correct, when a mobile node is away, ie attched to an IPv6-only foreign link, it can have IPv6 and IPv4 connections, but when it attaches to an IPv6-only link where it obtains its v6 home address, it cannot continue IPv4 connections. Christian > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Hesham Soliman > Sent: 15. december 2008 11:12 > To: Kaas-Petersen Christian; mext@ietf.org > Cc: julien.laganier.ietf@googlemail.com; jari.arkko@piuha.net > Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment > > > > Thanks for the response. Just a detail: The binding update > specified > > in your response, is that with or without the UDP header > using DSMIP > > ports? > > => Yes of course with UDP, it's always in UDP when the MN is > in an IPv4 network. > > > > > I agree the mobile node could equally > > well move to an IPv4 foreign link, and in that case the home agent > > would have the bindings > > > > (1') v6HoA -> v4CoA > > (2') v4HoA -> v4CoA > > > > just the binding update would be different, namely > > > > BU > > IPv4 Header src = v4CoA > > UDP Header with DSMIP ports > > IPv6 Header src = v6HoA > > lifetime > 0 > > IPv4 Home Address v4HoA > > IPv4 Care-of Address v4CoA > > > > So, going back to the original mail, Karens original > suggestion was a > > way to handle both of the two situations: > > > > (a) an IPv6-only home link continuing IPv4 communication, and > > => You can't deregister the IPv6 home address and maintain > any type of SA with the HA. I.e. no v6HoA = no binding. > > > (b) an IPv4-only home link continuing IPv6 communication. > > => That's the text I sent. > > > > > (b) is now part of DSMIP, while (a) should be dealt with in > > draft-premec-mext-extended-home-link. > > > > In a sense, in case (b) the IPv4-only home link is treated like any > > other IPv4-only foreign link. Suppose IPv6 payload traffic > is IPsec > > protected between v4CoA and v4HA. Is the IPv4-only home > link really > > like a truly foreign link so IPsec protection should be used, or is > > the IPv4-only home more like a home link where IPv6 payload > traffic is > > not IPsec protected, thus only > > IPv6-in-IPv4 tunnel encapsulation is to be used? > > => There is no correlation between the home link and IPsec. > You can protect > IPv6 traffic with IPsec anywhere. I assume you want to only > protect it to the HA, which would be fine in the scenario > above because it thinks it's not home anyway. > > Hesham > > > > > Christian > > > > > >> -----Original Message----- > >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] > >> Sent: 12. december 2008 16:13 > >> To: Kaas-Petersen Christian; mext@ietf.org > >> Cc: jari.arkko@piuha.net; julien.laganier.ietf@googlemail.com > >> Subject: Re: [MEXT] Removing bindings for IPv4 only - > please comment > >> > >> > >> > >> > >>> I understood the text as a useful clarification. I > >> understood it this > >>> way. When a mobile node moves to an IPv6 foreign network, > >> and there > >>> obtains the v6CoA address, it sends a binding update > >>> > >>> BU > >>> src = v6CoA > >>> Destination Option with v6HoA > >>> lifetime > 0 > >>> Alternate Care-of Address v6CoA > >>> IPv4 Home Address v4HoA > >>> > >>> to the home agent, and the home agent will in its binding > >> cache insert > >>> two entries > >>> > >>> (1) v6HoA -> v6CoA > >>> (2) v4HoA -> v6CoA > >> > >> => That's the current draft yes. I'm not sure why you're > referring to > >> IPv6 foreign networks only. The same applies to > >> IPv4 networks. > >> > >>> > >>> The clarification to me was then, that the mobile node, > >> while at this > >>> foreign IPv6 network, could ask the home agent to remove > >> both of the > >>> bindings by sending > >>> > >>> BU > >>> src = v6CoA > >>> Destination Option with v6HoA > >>> lifetime = 0 > >>> > >>> or could ask the home agent to remove the IPv4 binding > >> (retaining the > >>> IPv6 binding) by sending > >>> > >>> BU > >>> src = v6CoA > >>> Destination Option with v6HoA > >>> lifetime > 0 > >>> Alternate Care-of Address v6CoA > >> > >> > >>> > >>> I'll go back to the situation where the binding cache has > >> entries (1) > >>> and (2). If the mobile node moves to an IPv6-only link > >> where it gets > >>> only the v6HoA address, and wants to continue using > v4HoA, then the > >>> home agent's binding cache should be provided with the entry > >>> > >>> (a) v4HoA -> v6HoA > >> > >> => This wasn't part of the text I sent. > >> > >>> > >>> Or the other situation, the mobile node moves to an > IPv4-only link > >>> getting only v4HoA, the binding cache should be provided with the > >>> entry > >>> > >>> (b) v6HoA -> v4HoA > >> > >> => For b) you would send > >> > >> src = v4addr > >> dst = HA > >> src = V6HoA > >> dst = V6HA > >> BU message > >> v4 alt CoA option containing v4addr > >> > >> > >> Hesham > >> > >> > >>> > >>> Maybe you could help me sorting out: what is the contents of the > >>> binding updates to be sent to the home agent in the two > >> situations? > >>> And are both situations covered with the DSMIP specification? > >>> > >>> Christian > >>> > >>> > >>>> -----Original Message----- > >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] > >>>> Sent: 12. december 2008 13:37 > >>>> To: Kaas-Petersen Christian; mext@ietf.org > >>>> Cc: jari.arkko@piuha.net; julien.laganier.ietf@googlemail.com > >>>> Subject: Re: [MEXT] Removing bindings for IPv4 only - > >> please comment > >>>> > >>>> > >>>>> Fine with the addition. The original suggestion of Karen, now > >>>>> described in draft-premec-mext-extended-home-link, is something > >>>>> different, namely maintaining both IPv4 and IPv6 home > >>>> addresses on a > >>>>> home link which gives native support for either IPv4 or IPv6. > >>>>> Suppose the home link supports only IPv4. The home agent > >>>> will remove > >>>>> the entry for the v4HoA address, retaining the entry for > >> the v6HoA, > >>>>> and this entry will indicate packets for v6HoA will have to be > >>>>> IP-in-IP tunneled to v4HoA. > >>>> > >>>> => Right, but this is what the text I sent does. It > removes the v4 > >>>> binding and keeps the IPv6 binding. If the link is > >>>> IPv4 only then it will bind the > >>>> v6 HoA to that IPv4 address. > >>>> > >>>> Hesham > >>>> > >>>>> > >>>>> Christian > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > >>>> On Behalf > >>>>>> Of Hesham Soliman > >>>>>> Sent: 12. december 2008 07:28 > >>>>>> To: mext@ietf.org > >>>>>> Cc: Jari Arkko; Julien Laganier > >>>>>> Subject: [MEXT] Removing bindings for IPv4 only - > please comment > >>>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> Gerardo requested that we consider the issue of removing > >>>> an IPv4-only > >>>>>> bindings in the spec. We discussed this with the chairs > >>>> and it seemed > >>>>>> like a simple add-on to the spec. I'm still wondering if > >>>> this is the > >>>>>> same thing that Karen asked for earlier and we decided > to do it > >>>>>> separately. If it is, then I don't understand why we > >>>> didn't consider > >>>>>> the following solution (can't remember if I suggested > it before). > >>>>>> > >>>>>> I've added the following text to the draft, please let me > >>>> know if you > >>>>>> have any comments ASAP. I want to submit this version on > >>>> the weekend > >>>>>> if possible. > >>>>>> All the IESG comments have been included. It's pretty straight > >>>>>> forward and follows standard MIPv6 logic. > >>>>>> > >>>>>>
> >>>>>> > >>>>>> Mobile nodes will remove bindings from the home > >> agent's binding > >>>>>> cache whenever they move to the home link, or simply > >> when mobility > >>>>>> support is not needed. > >>>>>> > >>>>>> De-registering the IPv6 home address is described in >>>>>> target="RFC3775"/>. The same mechanism applies in this > >>>> specification. > >>>>>> Mobile nodes may remove the binding for the > >>>>>> IPv4 home address only, by sending a binding update that > >> does not > >>>>>> include the IPv4 home address option. Upon receiving > >> this binding > >>>>>> update, the home agent will replace the existing cache > >>>> entries with > >>>>>> the content of the new message. This ensures that the > >>>>>> IPv4 home address binding is removed, while maintining an > >>>>>> IPv6 binding. > >>>>>> > >>>>>> Note that the mobile node cannot remove the IPv6 > home address > >>>>>> binding while maintaining an IPv4 home address binding. > >>>>>> > >>>>>> A binding update message with a lifetime of zero, will > >>>> remove all > >>>>>> bindings for the mobile node.
> >>>>>> > >>>>>> Hesham > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> MEXT mailing list > >>>>>> MEXT@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>> > >>>> > >>>> > >>>> > >> > >> > >> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 15 07:17: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 02DB23A695B; Mon, 15 Dec 2008 07:17:41 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8EEB3A688D for ; Mon, 15 Dec 2008 07:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeUyVxfYcV0e for ; Mon, 15 Dec 2008 07:17:38 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 3EF393A695B for ; Mon, 15 Dec 2008 07:17:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=pstupar@qualcomm.com; q=dns/txt; s=qcdkim; t=1229354251; x=1260890251; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:references:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20Comments=20on=20draft-ietf- mext-binding-revocation-02|Date:=20Mon,=2015=20Dec=202008 =2015:16:32=20-0000|Message-ID:=20|In-Reply-To:=20< C5A96676FCD00745B64AE42D5FCC9B6E1C2CF213@zrc2hxm0.corp.no rtel.com>|X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20Comments=20on=20draft-ietf-mext-binding- revocation-02|Thread-Index:=20AclbLn3taqHuU6TUSgeN3dxQhl2 ykQArrD7gALKdDZA=3D|References:=20=20 |From:=20"Stupar,=20Patrick"=20|To: =20"Ahmad=20Muhanna"=20|Cc:=20|X-OriginalArrivalTime:=2015=20Dec=202008=2015:1 7:30.0888=20(UTC)=20FILETIME=3D[3F846080:01C95EC8] |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5464"=3B=20 a=3D"13956171"; bh=B9c8mscml/2XztNEFJIqHh5VFAhIz3nxI1nROoO4Uu4=; b=yf37inDEvpPdzv4h/GCwMSUU8nYOl38HuwfC0K/Ih3gmU1SnybFGen5b IqnuHr1JFSRX7zh8tCXRPmxr6SWdzZ1WhkuXZUVQGap86rwWJFCzmgipF NOPNPrexnsu2Y+Xiu0LJEfqxcUC+EHCTU8dCtoyOrf2LcHTVgQtYw2rIS E=; X-IronPort-AV: E=McAfee;i="5300,2777,5464"; a="13956171" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Dec 2008 07:17:31 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBFFHVXe001338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Dec 2008 07:17:31 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBFFHUKY006862; Mon, 15 Dec 2008 07:17:30 -0800 Received: from EUEX02.eu.qualcomm.com ([10.222.228.33]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Dec 2008 07:17:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 Dec 2008 15:16:32 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-mext-binding-revocation-02 Thread-Index: AclbLn3taqHuU6TUSgeN3dxQhl2ykQArrD7gALKdDZA= References: From: "Stupar, Patrick" To: "Ahmad Muhanna" X-OriginalArrivalTime: 15 Dec 2008 15:17:30.0888 (UTC) FILETIME=[3F846080:01C95EC8] Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, Please see answers inline Best Regards, Patrick > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Friday, December 12, 2008 2:34 AM > To: Stupar, Patrick > Cc: mext@ietf.org > Subject: RE: Comments on draft-ietf-mext-binding-revocation-02 > > Hi Patrick, > Thanks for your review. Please see responses inline. > > Regards, > Ahmad > > > > -----Original Message----- > > From: Stupar, Patrick [mailto:pstupar@qualcomm.com] > > Sent: Wednesday, December 10, 2008 7:19 PM > > To: Muhanna, Ahmad (RICH1:2H10) > > Cc: mext@ietf.org > > Subject: Comments on draft-ietf-mext-binding-revocation-02 > > > > Hi Ahmad, > > > > I have reviewed binding revocation draft and have the > > following comments/questions. > > > > - In MIPv6, Binding Update and Binding Ack have two different > > MH type values. Why isn't the same approach taken for BRI and > > BRA and only one value is used? > > [Ahmad] > This was discussed on the mailing list for a long time and agreed that > using one MH type will help in preserving the MH type space. I believe > the "Heartbeat Mechanism for PMIPv6" is a wg doc in Netlmm and use one > MH type for the Request and Response. On the other hand, do see an > issue > or problem in having a single MH type for both messages? [Patrick] If the WG is worried about MH type space then I am fine with the proposed message format. > > > > > - BRI has a revocation trigger field which is used for two > > main usages. > > One is the provisioning of the reason why the revocation was > > sent (e.g. > > inter-MAG handoff) and the other is related to specific > > binding revocation procedures (e.g. IPV4 HoA Binding only, > > Per-Peer Policy). I think it would be cleaner if the two > > concepts remain separated in the messages, for instance > > defining additional flags for Per-peer policy or > > IPv4 HoA Binding only. > > [Ahmad] > I see what you are saying. However, as you said, the Revocation Trigger > field is defined to give the reason which caused the revoking node to > send the BRI message. Thus far, I believe all of the defined values are > inline with that definition or reasoning. For example: When the LMA > sets > the R. Trigger value to "IPv4 HoA Binding Only" it means that the > reason > behind sending this BRI message is to revoke the IPv4 HoA address in > the > case that the MN is assigned two proxy HoA(v4 & v6) for the same pCoA. > I > do not see this as a policy decision, because it is no difference from > the MAG sending a BRI with R. Trigger value is set to for example, > "Access Network Session Termination" > > As for the R. Trigger value of "Per-Peer Policy", This is only > restricted to Global Revocation when the (G) bit is set. I still > believe > that "Per-Peer policy" also indicate the reason that allowed the LMA to > send this Global BRI. Do you have a different name for this R. Trigger > value that would fit better? > [Patrick]IMHO "IPv4 HoA Binding Only" is not the reason that triggered the BRI, it's the action that the MN is requested to perform. Anyhow, my concerns were not related to the list of reasons in the revocation trigger, but to the fact that some values of the field imply some actions and other values don't. My suggestion is that the actions are taken by MN and HA based on flags (e.g. Global Revocation) and not on the revocation trigger. Only the case of "IPv4 HoA Binding Only" lacks of a proper flag. > > > > - In the draft you refer to MAG identity, where is this term > > defined? I wasn't able to find it in RFC 5213. > > [Ahmad] > Actually, under section 4.1. "Peer Authorization Database (PAD) Example > Entries", you can find the MAG-ID is defined there as mag_identity_1. > It > is the same concept here. However, I agree that we do not have a > mobility option which is specific for carrying MAG-ID but the draft is > using the MN-ID in a very specific scenario. How the LMA would check if > this MAG is authorized for Global revocation is out of scope. > [Patrick] what I meant here is that in section 2 of RFC5213 there is the definition of MN identity and that I would expect something similar for the MAG in BRI draft. For MN identity, RFC5213 claims that MAC address or NAI can be used. Are there similar guidelines for MAG identity? > > > > > > Some other comments related to specific sections: > > > > - page 21: in the first section after the bullet list, there > > is the following sentence: > > "As described in Section 7.3, the LMA SHOULD retransmit this BRI to > > the MAG before deleting the mobile node IP tunnel to the mobile > > access gateway until it receives a matching Binding Revocation > > Acknowledgement or the BRIMaxRetransmitNumber is reached. " > > But this doesn't always apply, e.g. in case of inter-mag > > handoffs. What am I missing? > > [Ahmad] > Yes, I see what you are saying here. It seems that the text needs some > tweaking. > Do you have any suggestion? [Patrick] How about referring to the BCE? Proposed text: "As described in Section 7.3, the LMA SHOULD retransmit this BRI to the MAG before deleting BCE until it receives a matching Binding Revocation Acknowledgement or the BRIMaxRetransmitNumber is reached. " Though I am not sure this text is helpful as it is already captured later in the draft. > > > > > - why is the A bit setting mandatory in case of IPv4 HoA > > binding only revocation? > > [Ahmad] > May be if you tell me why not, we could change it? [Patrick] I have nothing against it. But that "MUST" implies that a BRI with the "IPv4 HoA Binding Only" value in the revocation trigger field and A bit not set is not properly formatted. What does the MAG do in this case? > > > > > - section 10.1.1: > > "BRI MUST be formatted as in Section 6.1 and if the (P) bit is set, > > the mobile access gateway must validate that the > > impacted binding > > have the proxy binding flag set." > > MAG is not supposed to have any proxy binding flag or is it? > > How can it validate this flag? > > [Ahmad] > Good catch. There is another incident below it too. > What about the following text for both bullets: > " > o BRI MUST be formatted as in Section 6.1 and the (P) bit is set. > > o If the Global (G) bit is set and the Revocation Trigger field is > set to "Per-Peer policy", the mobile access gateway identify all > bindings that are registered at the LMA and hosted at the MAG. > This Binding Revocation Indication does not include any other > mobility options. In this case, the MAG MUST send a BRA with the > appropriate status code to the LMA. > " > [Patrick] fine with me, thanks > > > > > > -section 11.1 > > " If the Acknowledgement (A) bit is set in the Binding Revocation > > Indication and the MN has the BCE in registered state, > > the mobile > > node MUST send a Binding Revocation Acknowledgement." > > > > MN has no BCE, it has a binding update list. > [Ahmad] > Right. Thx. What about the following: > > o If the Acknowledgement (A) bit is set in the Binding Revocation > Indication and the MN has a Binding Update List entry for the > source > of the BRI message, the mobile node MUST send a Binding > Revocation > > Acknowledgement. However, in all other cases when the (A) bit is > set > in the BRI, the mobile node SHOULD send a Binding Revocation > Acknowledgement. > In all cases, the mobile node MUST follow Section 11.2 when send > a BRA using the appropriate status code. > [Patrick] I would perform the check based on the HoA and CoA contained in the BRI. Proposed text: o If the Acknowledgement (A) bit is set in the Binding Revocation Indication and the MN has a Binding Update List entry for the Care of address and the Home Address Contained in the BRI message, the mobile node MUST send a Binding Revocation Acknowledgement. However, in all other cases when the (A) bit is set in the BRI, the mobile node SHOULD send a Binding Revocation Acknowledgement. In all cases, the mobile node MUST follow Section 11.2 when send a BRA using the appropriate status code. > > > > -section 11.1 > > "If the Revocation Trigger field value is "Administrative Reason", > > the mobile node MUST NOT try to re-register with the home agent > > before contacting its home operator." > > > > I don't think that BRI specs have to mandate the MN to > > contact the home operator, the text at the end of section > > 11.1 is enough IMO. > > > [Ahmad] > I see your point, It seems a very strong requirement and for a well > behaved MN implementation, it may not be a problem to remove the whole > bullet. However, for a non-well behaved MN, it may be necessary to keep > something. What about if we demote MUST NOT to SHOULD NOT. Would that > work? > > [Patrick] I was not worried about the "MUST" or "SHOULD", but by the fact that IMO the action to be taken after receiving a BRI with that value in the trigger field is implementation dependant as already described later in the draft > NEW TEXT: > o If the Revocation Trigger field value is "Administrative Reason", > the mobile node SHOULD NOT try to re-register with the home agent > before contacting its home operator. > > TEXT at end of 11.1 that Patrick is referring to: > > The Revocation Trigger field value in the received Binding > Revocation > Indication could be used by the mobile node to define what action > the > mobile node could do to be able to register again and receive its IP > mobility service, e.g. contacting its home operator. > > > I have some typos and editorial corrections as well, I will > > send them off-list. > > [Ahmad] > Please send them. Thanks for your review and good comments! > > > > > Regards, > > > > Patrick > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mayfieldnn@advancedmicrosensors.com Mon Dec 15 07:42:26 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BE2D28C0EB for ; Mon, 15 Dec 2008 07:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.994 X-Spam-Level: X-Spam-Status: No, score=-31.994 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfbAvqKvV1Vm for ; Mon, 15 Dec 2008 07:42:26 -0800 (PST) Received: from alston.com (unknown [89.142.60.45]) by core3.amsl.com (Postfix) with SMTP id DCAEC3A679C for ; Mon, 15 Dec 2008 07:42:24 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081215154224.DCAEC3A679C@core3.amsl.com> Date: Mon, 15 Dec 2008 07:42:24 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From kathy.dixon@alliedpetroleum.co.nz Mon Dec 15 09:24:12 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E9063A6A29 for ; Mon, 15 Dec 2008 09:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -32.096 X-Spam-Level: X-Spam-Status: No, score=-32.096 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubCxjRQUuKYR for ; Mon, 15 Dec 2008 09:24:12 -0800 (PST) Received: from akebono-brake.co.jp (unknown [189.35.181.204]) by core3.amsl.com (Postfix) with SMTP id 965E23A6804 for ; Mon, 15 Dec 2008 09:24:09 -0800 (PST) To: Subject: , December 84% off From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081215172410.965E23A6804@core3.amsl.com> Date: Mon, 15 Dec 2008 09:24:09 -0800 (PST) Click here to view as a webpage From mext-bounces@ietf.org Mon Dec 15 10:10:14 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357C928C12F; Mon, 15 Dec 2008 10:10:14 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7E563A67F7 for ; Mon, 15 Dec 2008 10:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfUA5aMhuPLP for ; Mon, 15 Dec 2008 10:10:11 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 58B7C3A6804 for ; Mon, 15 Dec 2008 10:10:11 -0800 (PST) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 0AF1EB475A9; Mon, 15 Dec 2008 19:04:17 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: mext Organization: Universidad Carlos III de Madrid Date: Mon, 15 Dec 2008 19:04:16 +0100 Message-Id: <1229364256.18243.44.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: draft-ietf-mext-nemo-ro-automotive-req-01@tools.ietf.org Subject: [MEXT] Comments on draft-ietf-mext-nemo-ro-automotive-req-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1758826813==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1758826813== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-29atsTzh4AiAjMF02AT7" --=-29atsTzh4AiAjMF02AT7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Dear authors, I've read the draft and I find it quite useful, thanks! I've have some minor comments to add to which have been already said on the ML: - About sections 3.1 and 3.2: To me, all 3.2.x sections seems pretty much the same than 3.1.x. IMHO, it'd be better to just point out the differences or describe only an abstract architecture and the describe the minor particularities of each. - About Req. 6: To me this is completely solution space and it shouldn't be a requirement. Besides, it makes C2C-CC and CALM differ in terms of NEMO RO requirements, which is not very nice, IMHO, for this kind of document (standard wide). Thanks! Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2009: 2nd Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-29atsTzh4AiAjMF02AT7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAklGnCAACgkQNdy6TdFwT2fVDACgz7yYQDNyTnjx3tQmqPVTwTwB pqoAnjuNpTNoOHPUX9srvxfy46WVjlY7 =YpNj -----END PGP SIGNATURE----- --=-29atsTzh4AiAjMF02AT7-- --===============1758826813== 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 --===============1758826813==-- From miranda@air-worldwide.com Mon Dec 15 12:27:40 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B84428C162 for ; Mon, 15 Dec 2008 12:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -51.237 X-Spam-Level: X-Spam-Status: No, score=-51.237 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, HTML_FONT_LOW_CONTRAST=0.124, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, J_CHICKENPOX_57=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7D-ndtE32-8d for ; Mon, 15 Dec 2008 12:27:39 -0800 (PST) Received: from 86-41-206-75-dynamic.b-ras1.lmk.limerick.eircom.net (86-41-215-108-dynamic.b-ras1.lmk.limerick.eircom.net [86.41.215.108]) by core3.amsl.com (Postfix) with SMTP id 5EC7928C145 for ; Mon, 15 Dec 2008 12:27:37 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081215202738.5EC7928C145@core3.amsl.com> Date: Mon, 15 Dec 2008 12:27:37 -0800 (PST)
Check it now!

Don't hurry to leave, you'll find a lot of useful things here!


was great.trading, Soros told the committee, should not affect the markets,
the yen. Accordingly, the Soros Fund took a large short position in thefinancial theories to explain why the legislators were barking up the From jbdfinger@amtelecom.net Mon Dec 15 14:05:37 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C41B13A6A4F for ; Mon, 15 Dec 2008 14:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.871 X-Spam-Level: X-Spam-Status: No, score=-11.871 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9YoILky1WJq for ; Mon, 15 Dec 2008 14:05:31 -0800 (PST) Received: from agcomm.com (unknown [190.146.208.207]) by core3.amsl.com (Postfix) with SMTP id 06A9E28C111 for ; Mon, 15 Dec 2008 14:05:20 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081215220522.06A9E28C111@core3.amsl.com> Date: Mon, 15 Dec 2008 14:05:20 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mext-bounces@ietf.org Mon Dec 15 18:19: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 EBD313A67AE; Mon, 15 Dec 2008 18:19:54 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE493A6944 for ; Mon, 15 Dec 2008 18:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDaTg9BRooUD for ; Mon, 15 Dec 2008 18:19:52 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 8418F3A6405 for ; Mon, 15 Dec 2008 18:19:52 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 Dec 2008 21:19:41 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMOusecase Thread-Index: AclT9cv5JA+1h7g/RR26VTnK4EnOsAANh5DwAr3xviA= References: From: "Vijay Devarapalli" To: "Ahmad Muhanna" , "Desire Oulai" , Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMOusecase X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 and others, Its not clear what would cause the home agent to stop forwarding for a particular mobile network prefix and revoke that prefix using a BRI message. It can done, but is it really required? If the mobile network prefix is assigned to the mobile router using binding acknowledgement, then I can see the BRI message being used to revoke a particular prefix. But if DHCP prefix delegation is used for assigning the prefixes, does it make sense to the BRI message for revoking a prefix? Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Ahmad Muhanna > Sent: Monday, December 01, 2008 7:23 PM > To: Desire Oulai; mext@ietf.org > Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility > Supports NEMOusecase > > Hi Desire, > > Added a relative subject. > > I guess the usecase is clear and it makes sense to me. > We can add some text similar to yours to capture this > functionality under the HA and MN operations after the > conclusion of the WGLC.. > > BTW: Is there anyone who thinks that we should not add this usecase? > > Regards, > Ahmad > > > > > ________________________________ > > From: Desire Oulai [mailto:desire.oulai@ericsson.com] > Sent: Monday, December 01, 2008 2:46 PM > To: mext@ietf.org > Cc: Muhanna, Ahmad (RICH1:2H10) > Subject: > > > > Hi Ahmad, All, > > The Binding revocation draft does not mention > revocation related to NEMO. If used as is, the BRI will > revoke the binding between the MR's HoA and CoA. I think it's > woth adding another level of revocation: revocation of Mobile > Network Prefixes. A HA may decide to stop forwarding data to > the CoA for certain MNPs and BR could be used for that. Here > is a proposed text for a new section: > > "In case of NEMO protocol, the HA follows the same > procedure as MIPv6 if the goal is to revoke the binding > between the Mobile Router's HoA and CoA. It is also possible > to have finer granularity of revocation targeting the Mobile > Network Prefixes assigned to the Mobile Router. In this case, > the HA sends a BRI message including one or more MNP options > with the A bit set and the Revocation Trigger set to a proper > value, e.g. Administrative Reasons. When receiving this BRI, > the MR deletes the MNP(s) from the Prefix Information field > in the Binding Update List and responds with a BRA message. > The BRA MUST include the MNP(s) contained in the BRI." > > Also, Mobile network Prefix should be addes as valid > option in section "6.2. Binding Revocation Acknowledgement Message". > > BR > Desire > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 16 00:05: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 2C5443A6A56; Tue, 16 Dec 2008 00:05:55 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E68728C0EF for ; Tue, 16 Dec 2008 00:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLohXXICQagx for ; Tue, 16 Dec 2008 00:05:52 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id F01F73A6358 for ; Tue, 16 Dec 2008 00:05:51 -0800 (PST) Received: from [58.163.110.146] by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LCUvy-0007Ms-Gm; Tue, 16 Dec 2008 19:05:40 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Tue, 16 Dec 2008 19:05:29 +1100 From: Hesham Soliman To: , Message-ID: Thread-Topic: [MEXT] Removing bindings for IPv4 only - please comment Thread-Index: AclcIrfbppqowVDjTEy3HFmjbORgHQAC7YeQAAn3hrsAA5HPwAAB3yfLAIq2CbAAAaeFlAAEaW3gACl43XQ= In-Reply-To: Mime-version: 1.0 Cc: jari.arkko@piuha.net, julien.laganier.ietf@googlemail.com Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 15/12/08 11:27 PM, "Christian.Kaas-Petersen@tieto.com" wrote: > I am often reminded of the scarcity of resources on the > radio link between the mobile phone/node and the > radio base station. Suppose an operator wants to offer > IPv4 and IPv6 services, but is deploying only > IPv6 PDP contexts on the radio link, the home link. => Be careful with those rumours :) The PDP is not really related to radio scarcity, it's a logical entity, just like a radio bearer is a logical entity. > > If I understand MIP/DSMIP correct, when a mobile node > is away, ie attched to an IPv6-only foreign link, > it can have IPv6 and IPv4 connections, but when it > attaches to an IPv6-only link where it obtains its > v6 home address, it cannot continue IPv4 connections. => Sure it can to use its IPv4 home address in an IPv6-only foreign link. If you mean: When it attaches to an IPv6-only *home link* then yes, it can't use IPv4 home addresses. But when that happens, the operator will obviously think IPv4 will not be missed. I don't think supporting v4 and v6 on the same link adds any burden on the radio link resources. Hesham > > Christian > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Hesham Soliman >> Sent: 15. december 2008 11:12 >> To: Kaas-Petersen Christian; mext@ietf.org >> Cc: julien.laganier.ietf@googlemail.com; jari.arkko@piuha.net >> Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment >> >> >>> Thanks for the response. Just a detail: The binding update >> specified >>> in your response, is that with or without the UDP header >> using DSMIP >>> ports? >> >> => Yes of course with UDP, it's always in UDP when the MN is >> in an IPv4 network. >> >>> >>> I agree the mobile node could equally >>> well move to an IPv4 foreign link, and in that case the home agent >>> would have the bindings >>> >>> (1') v6HoA -> v4CoA >>> (2') v4HoA -> v4CoA >>> >>> just the binding update would be different, namely >>> >>> BU >>> IPv4 Header src = v4CoA >>> UDP Header with DSMIP ports >>> IPv6 Header src = v6HoA >>> lifetime > 0 >>> IPv4 Home Address v4HoA >>> IPv4 Care-of Address v4CoA >>> >>> So, going back to the original mail, Karens original >> suggestion was a >>> way to handle both of the two situations: >>> >>> (a) an IPv6-only home link continuing IPv4 communication, and >> >> => You can't deregister the IPv6 home address and maintain >> any type of SA with the HA. I.e. no v6HoA = no binding. >> >>> (b) an IPv4-only home link continuing IPv6 communication. >> >> => That's the text I sent. >> >>> >>> (b) is now part of DSMIP, while (a) should be dealt with in >>> draft-premec-mext-extended-home-link. >>> >>> In a sense, in case (b) the IPv4-only home link is treated like any >>> other IPv4-only foreign link. Suppose IPv6 payload traffic >> is IPsec >>> protected between v4CoA and v4HA. Is the IPv4-only home >> link really >>> like a truly foreign link so IPsec protection should be used, or is >>> the IPv4-only home more like a home link where IPv6 payload >> traffic is >>> not IPsec protected, thus only >>> IPv6-in-IPv4 tunnel encapsulation is to be used? >> >> => There is no correlation between the home link and IPsec. >> You can protect >> IPv6 traffic with IPsec anywhere. I assume you want to only >> protect it to the HA, which would be fine in the scenario >> above because it thinks it's not home anyway. >> >> Hesham >> >>> >>> Christian >>> >>> >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: 12. december 2008 16:13 >>>> To: Kaas-Petersen Christian; mext@ietf.org >>>> Cc: jari.arkko@piuha.net; julien.laganier.ietf@googlemail.com >>>> Subject: Re: [MEXT] Removing bindings for IPv4 only - >> please comment >>>> >>>> >>>> >>>> >>>>> I understood the text as a useful clarification. I >>>> understood it this >>>>> way. When a mobile node moves to an IPv6 foreign network, >>>> and there >>>>> obtains the v6CoA address, it sends a binding update >>>>> >>>>> BU >>>>> src = v6CoA >>>>> Destination Option with v6HoA >>>>> lifetime > 0 >>>>> Alternate Care-of Address v6CoA >>>>> IPv4 Home Address v4HoA >>>>> >>>>> to the home agent, and the home agent will in its binding >>>> cache insert >>>>> two entries >>>>> >>>>> (1) v6HoA -> v6CoA >>>>> (2) v4HoA -> v6CoA >>>> >>>> => That's the current draft yes. I'm not sure why you're >> referring to >>>> IPv6 foreign networks only. The same applies to >>>> IPv4 networks. >>>> >>>>> >>>>> The clarification to me was then, that the mobile node, >>>> while at this >>>>> foreign IPv6 network, could ask the home agent to remove >>>> both of the >>>>> bindings by sending >>>>> >>>>> BU >>>>> src = v6CoA >>>>> Destination Option with v6HoA >>>>> lifetime = 0 >>>>> >>>>> or could ask the home agent to remove the IPv4 binding >>>> (retaining the >>>>> IPv6 binding) by sending >>>>> >>>>> BU >>>>> src = v6CoA >>>>> Destination Option with v6HoA >>>>> lifetime > 0 >>>>> Alternate Care-of Address v6CoA >>>> >>>> >>>>> >>>>> I'll go back to the situation where the binding cache has >>>> entries (1) >>>>> and (2). If the mobile node moves to an IPv6-only link >>>> where it gets >>>>> only the v6HoA address, and wants to continue using >> v4HoA, then the >>>>> home agent's binding cache should be provided with the entry >>>>> >>>>> (a) v4HoA -> v6HoA >>>> >>>> => This wasn't part of the text I sent. >>>> >>>>> >>>>> Or the other situation, the mobile node moves to an >> IPv4-only link >>>>> getting only v4HoA, the binding cache should be provided with the >>>>> entry >>>>> >>>>> (b) v6HoA -> v4HoA >>>> >>>> => For b) you would send >>>> >>>> src = v4addr >>>> dst = HA >>>> src = V6HoA >>>> dst = V6HA >>>> BU message >>>> v4 alt CoA option containing v4addr >>>> >>>> >>>> Hesham >>>> >>>> >>>>> >>>>> Maybe you could help me sorting out: what is the contents of the >>>>> binding updates to be sent to the home agent in the two >>>> situations? >>>>> And are both situations covered with the DSMIP specification? >>>>> >>>>> Christian >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>>> Sent: 12. december 2008 13:37 >>>>>> To: Kaas-Petersen Christian; mext@ietf.org >>>>>> Cc: jari.arkko@piuha.net; julien.laganier.ietf@googlemail.com >>>>>> Subject: Re: [MEXT] Removing bindings for IPv4 only - >>>> please comment >>>>>> >>>>>> >>>>>>> Fine with the addition. The original suggestion of Karen, now >>>>>>> described in draft-premec-mext-extended-home-link, is something >>>>>>> different, namely maintaining both IPv4 and IPv6 home >>>>>> addresses on a >>>>>>> home link which gives native support for either IPv4 or IPv6. >>>>>>> Suppose the home link supports only IPv4. The home agent >>>>>> will remove >>>>>>> the entry for the v4HoA address, retaining the entry for >>>> the v6HoA, >>>>>>> and this entry will indicate packets for v6HoA will have to be >>>>>>> IP-in-IP tunneled to v4HoA. >>>>>> >>>>>> => Right, but this is what the text I sent does. It >> removes the v4 >>>>>> binding and keeps the IPv6 binding. If the link is >>>>>> IPv4 only then it will bind the >>>>>> v6 HoA to that IPv4 address. >>>>>> >>>>>> Hesham >>>>>> >>>>>>> >>>>>>> Christian >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] >>>>>> On Behalf >>>>>>>> Of Hesham Soliman >>>>>>>> Sent: 12. december 2008 07:28 >>>>>>>> To: mext@ietf.org >>>>>>>> Cc: Jari Arkko; Julien Laganier >>>>>>>> Subject: [MEXT] Removing bindings for IPv4 only - >> please comment >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Gerardo requested that we consider the issue of removing >>>>>> an IPv4-only >>>>>>>> bindings in the spec. We discussed this with the chairs >>>>>> and it seemed >>>>>>>> like a simple add-on to the spec. I'm still wondering if >>>>>> this is the >>>>>>>> same thing that Karen asked for earlier and we decided >> to do it >>>>>>>> separately. If it is, then I don't understand why we >>>>>> didn't consider >>>>>>>> the following solution (can't remember if I suggested >> it before). >>>>>>>> >>>>>>>> I've added the following text to the draft, please let me >>>>>> know if you >>>>>>>> have any comments ASAP. I want to submit this version on >>>>>> the weekend >>>>>>>> if possible. >>>>>>>> All the IESG comments have been included. It's pretty straight >>>>>>>> forward and follows standard MIPv6 logic. >>>>>>>> >>>>>>>>
>>>>>>>> >>>>>>>> Mobile nodes will remove bindings from the home >>>> agent's binding >>>>>>>> cache whenever they move to the home link, or simply >>>> when mobility >>>>>>>> support is not needed. >>>>>>>> >>>>>>>> De-registering the IPv6 home address is described in >>>>>>> target="RFC3775"/>. The same mechanism applies in this >>>>>> specification. >>>>>>>> Mobile nodes may remove the binding for the >>>>>>>> IPv4 home address only, by sending a binding update that >>>> does not >>>>>>>> include the IPv4 home address option. Upon receiving >>>> this binding >>>>>>>> update, the home agent will replace the existing cache >>>>>> entries with >>>>>>>> the content of the new message. This ensures that the >>>>>>>> IPv4 home address binding is removed, while maintining an >>>>>>>> IPv6 binding. >>>>>>>> >>>>>>>> Note that the mobile node cannot remove the IPv6 >> home address >>>>>>>> binding while maintaining an IPv4 home address binding. >>>>>>>> >>>>>>>> A binding update message with a lifetime of zero, will >>>>>> remove all >>>>>>>> bindings for the mobile node.
>>>>>>>> >>>>>>>> Hesham >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 16 01:27: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 777003A6840; Tue, 16 Dec 2008 01:27:13 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980443A6840 for ; Tue, 16 Dec 2008 01:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.564 X-Spam-Level: X-Spam-Status: No, score=-1.564 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id no5udfD0OB51 for ; Tue, 16 Dec 2008 01:27:11 -0800 (PST) Received: from mail-ew0-f17.google.com (mail-ew0-f17.google.com [209.85.219.17]) by core3.amsl.com (Postfix) with ESMTP id 8D3573A67AD for ; Tue, 16 Dec 2008 01:27:10 -0800 (PST) Received: by ewy10 with SMTP id 10so3547208ewy.13 for ; Tue, 16 Dec 2008 01:27:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=NlIywtt+EGLJ5AN0epfgSeKp3qrxm8kD4M7hiNNPAcI=; b=Bx7/kT8Yr1BRJatzxj25OMOXBeIKlYkQBAh/RPGK9joN+h4MiHdWWy++Am+tyIFfcL x87mp68AsKu25wPfI+vxG8y4pxNaQqPsFCRcLa2zJO3W1i8GKwoTzLWO1wMG/6nwu5+m ZENALlzvkZ72SmfvOdQKgJ0ULMHCAjUMw6IrI= 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=pdtkcPMW05DQtOCR4A4yOXzk1YsC8dgKsZ4bbJbZReF+MBLXaXtGpC9wP4ldtsZuZo 4QmVBJGlvCQlcrJCAKjrOWLWdERx5oB4AzISeLJmmzux/0VU1vN5lj2MrglA+MqXR2qF qV/alouvJwuyJmMwJNCpF4NJvW5OPUvQTemPY= Received: by 10.210.113.16 with SMTP id l16mr8990809ebc.38.1229419622028; Tue, 16 Dec 2008 01:27:02 -0800 (PST) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id q9sm1617464gve.33.2008.12.16.01.26.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 01:27:00 -0800 (PST) To: Christian.Kaas-Petersen@tieto.com Date: Tue, 16 Dec 2008 10:27:22 +0100 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200812161027.23138.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: mext@ietf.org, jari.arkko@piuha.net Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Christian, On Monday 15 December 2008, Christian.Kaas-Petersen@tieto.com wrote: > I am often reminded of the scarcity of resources on the > radio link between the mobile phone/node and the > radio base station. Suppose an operator wants to offer > IPv4 and IPv6 services, but is deploying only > IPv6 PDP contexts on the radio link, the home link. Under the conditions you're assuming, i.e., deploying only IPv6 PDP contexts on the radio/home link, offering IPv4 service will require to tunnel IPv4 in IPv6, and thus the tunneling overhead will waste the scarce radio link resources beyweem the mobile node and the radio base station... Thus I'm not sure I understand this scenario. What I understand however is that there is a scenario in which an operator has legacy radio/home links that can handle IPv4 PDP contexts only, but not IPv6 PDP contexts, but want to offer both Iv4 and IPv6. In this situation the operator has to tunnel IPv6 in IPv4, thus the mobile node would be at home for IPv4, but away from home for IPv6... --julien > If I understand MIP/DSMIP correct, when a mobile node > is away, ie attched to an IPv6-only foreign link, > it can have IPv6 and IPv4 connections, but when it > attaches to an IPv6-only link where it obtains its > v6 home address, it cannot continue IPv4 connections. > > Christian > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of Hesham Soliman > > Sent: 15. december 2008 11:12 > > To: Kaas-Petersen Christian; mext@ietf.org > > Cc: julien.laganier.ietf@googlemail.com; jari.arkko@piuha.net > > Subject: Re: [MEXT] Removing bindings for IPv4 only - please > > comment > > > > > Thanks for the response. Just a detail: The binding update > > > > specified > > > > > in your response, is that with or without the UDP header > > > > using DSMIP > > > > > ports? > > > > => Yes of course with UDP, it's always in UDP when the MN is > > in an IPv4 network. > > > > > I agree the mobile node could equally > > > well move to an IPv4 foreign link, and in that case the home > > > agent would have the bindings > > > > > > (1') v6HoA -> v4CoA > > > (2') v4HoA -> v4CoA > > > > > > just the binding update would be different, namely > > > > > > BU > > > IPv4 Header src = v4CoA > > > UDP Header with DSMIP ports > > > IPv6 Header src = v6HoA > > > lifetime > 0 > > > IPv4 Home Address v4HoA > > > IPv4 Care-of Address v4CoA > > > > > > So, going back to the original mail, Karens original > > > > suggestion was a > > > > > way to handle both of the two situations: > > > > > > (a) an IPv6-only home link continuing IPv4 communication, and > > > > => You can't deregister the IPv6 home address and maintain > > any type of SA with the HA. I.e. no v6HoA = no binding. > > > > > (b) an IPv4-only home link continuing IPv6 communication. > > > > => That's the text I sent. > > > > > (b) is now part of DSMIP, while (a) should be dealt with in > > > draft-premec-mext-extended-home-link. > > > > > > In a sense, in case (b) the IPv4-only home link is treated like > > > any other IPv4-only foreign link. Suppose IPv6 payload traffic > > > > is IPsec > > > > > protected between v4CoA and v4HA. Is the IPv4-only home > > > > link really > > > > > like a truly foreign link so IPsec protection should be used, or > > > is the IPv4-only home more like a home link where IPv6 payload > > > > traffic is > > > > > not IPsec protected, thus only > > > IPv6-in-IPv4 tunnel encapsulation is to be used? > > > > => There is no correlation between the home link and IPsec. > > You can protect > > IPv6 traffic with IPsec anywhere. I assume you want to only > > protect it to the HA, which would be fine in the scenario > > above because it thinks it's not home anyway. > > > > Hesham > > > > > Christian > > > > > >> -----Original Message----- > > >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] > > >> Sent: 12. december 2008 16:13 > > >> To: Kaas-Petersen Christian; mext@ietf.org > > >> Cc: jari.arkko@piuha.net; julien.laganier.ietf@googlemail.com > > >> Subject: Re: [MEXT] Removing bindings for IPv4 only - > > > > please comment > > > > >>> I understood the text as a useful clarification. I > > >> > > >> understood it this > > >> > > >>> way. When a mobile node moves to an IPv6 foreign network, > > >> > > >> and there > > >> > > >>> obtains the v6CoA address, it sends a binding update > > >>> > > >>> BU > > >>> src = v6CoA > > >>> Destination Option with v6HoA > > >>> lifetime > 0 > > >>> Alternate Care-of Address v6CoA > > >>> IPv4 Home Address v4HoA > > >>> > > >>> to the home agent, and the home agent will in its binding > > >> > > >> cache insert > > >> > > >>> two entries > > >>> > > >>> (1) v6HoA -> v6CoA > > >>> (2) v4HoA -> v6CoA > > >> > > >> => That's the current draft yes. I'm not sure why you're > > > > referring to > > > > >> IPv6 foreign networks only. The same applies to > > >> IPv4 networks. > > >> > > >>> The clarification to me was then, that the mobile node, > > >> > > >> while at this > > >> > > >>> foreign IPv6 network, could ask the home agent to remove > > >> > > >> both of the > > >> > > >>> bindings by sending > > >>> > > >>> BU > > >>> src = v6CoA > > >>> Destination Option with v6HoA > > >>> lifetime = 0 > > >>> > > >>> or could ask the home agent to remove the IPv4 binding > > >> > > >> (retaining the > > >> > > >>> IPv6 binding) by sending > > >>> > > >>> BU > > >>> src = v6CoA > > >>> Destination Option with v6HoA > > >>> lifetime > 0 > > >>> Alternate Care-of Address v6CoA > > >>> > > >>> > > >>> > > >>> I'll go back to the situation where the binding cache has > > >> > > >> entries (1) > > >> > > >>> and (2). If the mobile node moves to an IPv6-only link > > >> > > >> where it gets > > >> > > >>> only the v6HoA address, and wants to continue using > > > > v4HoA, then the > > > > >>> home agent's binding cache should be provided with the entry > > >>> > > >>> (a) v4HoA -> v6HoA > > >> > > >> => This wasn't part of the text I sent. > > >> > > >>> Or the other situation, the mobile node moves to an > > > > IPv4-only link > > > > >>> getting only v4HoA, the binding cache should be provided with > > >>> the entry > > >>> > > >>> (b) v6HoA -> v4HoA > > >> > > >> => For b) you would send > > >> > > >> src = v4addr > > >> dst = HA > > >> src = V6HoA > > >> dst = V6HA > > >> BU message > > >> v4 alt CoA option containing v4addr > > >> > > >> > > >> Hesham > > >> > > >>> Maybe you could help me sorting out: what is the contents of > > >>> the binding updates to be sent to the home agent in the two > > >> > > >> situations? > > >> > > >>> And are both situations covered with the DSMIP specification? > > >>> > > >>> Christian > > >>> > > >>>> -----Original Message----- > > >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] > > >>>> Sent: 12. december 2008 13:37 > > >>>> To: Kaas-Petersen Christian; mext@ietf.org > > >>>> Cc: jari.arkko@piuha.net; julien.laganier.ietf@googlemail.com > > >>>> Subject: Re: [MEXT] Removing bindings for IPv4 only - > > >> > > >> please comment > > >> > > >>>>> Fine with the addition. The original suggestion of Karen, > > >>>>> now described in draft-premec-mext-extended-home-link, is > > >>>>> something different, namely maintaining both IPv4 and IPv6 > > >>>>> home > > >>>> > > >>>> addresses on a > > >>>> > > >>>>> home link which gives native support for either IPv4 or IPv6. > > >>>>> Suppose the home link supports only IPv4. The home agent > > >>>> > > >>>> will remove > > >>>> > > >>>>> the entry for the v4HoA address, retaining the entry for > > >> > > >> the v6HoA, > > >> > > >>>>> and this entry will indicate packets for v6HoA will have to > > >>>>> be IP-in-IP tunneled to v4HoA. > > >>>> > > >>>> => Right, but this is what the text I sent does. It > > > > removes the v4 > > > > >>>> binding and keeps the IPv6 binding. If the link is > > >>>> IPv4 only then it will bind the > > >>>> v6 HoA to that IPv4 address. > > >>>> > > >>>> Hesham > > >>>> > > >>>>> Christian > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > > >>>> > > >>>> On Behalf > > >>>> > > >>>>>> Of Hesham Soliman > > >>>>>> Sent: 12. december 2008 07:28 > > >>>>>> To: mext@ietf.org > > >>>>>> Cc: Jari Arkko; Julien Laganier > > >>>>>> Subject: [MEXT] Removing bindings for IPv4 only - > > > > please comment > > > > >>>>>> Hi all, > > >>>>>> > > >>>>>> Gerardo requested that we consider the issue of removing > > >>>> > > >>>> an IPv4-only > > >>>> > > >>>>>> bindings in the spec. We discussed this with the chairs > > >>>> > > >>>> and it seemed > > >>>> > > >>>>>> like a simple add-on to the spec. I'm still wondering if > > >>>> > > >>>> this is the > > >>>> > > >>>>>> same thing that Karen asked for earlier and we decided > > > > to do it > > > > >>>>>> separately. If it is, then I don't understand why we > > >>>> > > >>>> didn't consider > > >>>> > > >>>>>> the following solution (can't remember if I suggested > > > > it before). > > > > >>>>>> I've added the following text to the draft, please let me > > >>>> > > >>>> know if you > > >>>> > > >>>>>> have any comments ASAP. I want to submit this version on > > >>>> > > >>>> the weekend > > >>>> > > >>>>>> if possible. > > >>>>>> All the IESG comments have been included. It's pretty > > >>>>>> straight forward and follows standard MIPv6 logic. > > >>>>>> > > >>>>>>
> > >>>>>> > > >>>>>> Mobile nodes will remove bindings from the home > > >> > > >> agent's binding > > >> > > >>>>>> cache whenever they move to the home link, or simply > > >> > > >> when mobility > > >> > > >>>>>> support is not needed. > > >>>>>> > > >>>>>> De-registering the IPv6 home address is described in > > >>>>>> . The same mechanism applies in this > > >>>> > > >>>> specification. > > >>>> > > >>>>>> Mobile nodes may remove the binding for the > > >>>>>> IPv4 home address only, by sending a binding update that > > >> > > >> does not > > >> > > >>>>>> include the IPv4 home address option. Upon receiving > > >> > > >> this binding > > >> > > >>>>>> update, the home agent will replace the existing cache > > >>>> > > >>>> entries with > > >>>> > > >>>>>> the content of the new message. This ensures that the > > >>>>>> IPv4 home address binding is removed, while maintining an > > >>>>>> IPv6 binding. > > >>>>>> > > >>>>>> Note that the mobile node cannot remove the IPv6 > > > > home address > > > > >>>>>> binding while maintaining an IPv4 home address binding. > > >>>>>> > > >>>>>> A binding update message with a lifetime of zero, will > > >>>> > > >>>> remove all > > >>>> > > >>>>>> bindings for the mobile node.
> > >>>>>> > > >>>>>> Hesham > > >>>>>> > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> MEXT mailing list > > >>>>>> MEXT@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext -- --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From nargik@aetna.com Tue Dec 16 01:32:28 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33DF3A6A59 for ; Tue, 16 Dec 2008 01:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.346 X-Spam-Level: X-Spam-Status: No, score=-17.346 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HTML_FONT_LOW_CONTRAST=0.124, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, J_CHICKENPOX_65=0.6, J_CHICKENPOX_74=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIHCaimyBlNJ for ; Tue, 16 Dec 2008 01:32:27 -0800 (PST) Received: from allianz.es (unknown [122.160.73.126]) by core3.amsl.com (Postfix) with SMTP id 2BCB93A688E for ; Tue, 16 Dec 2008 01:32:25 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081216093226.2BCB93A688E@core3.amsl.com> Date: Tue, 16 Dec 2008 01:32:25 -0800 (PST)
Check it now!

Look inside to find more about these wonderful things!


sovereign country.once.
ruling.where the evolution of a merely "passive tolerance for From mext-bounces@ietf.org Tue Dec 16 05:43:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5791F3A6A77; Tue, 16 Dec 2008 05:43:46 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A5E33A6A77 for ; Tue, 16 Dec 2008 05:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.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 2K-ewa3xDXMw for ; Tue, 16 Dec 2008 05:43:44 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id AC0F63A6A21 for ; Tue, 16 Dec 2008 05:43:43 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LCaD0-0003i0-Vv for ; Wed, 17 Dec 2008 00:43:35 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 17 Dec 2008 00:43:33 +1100 From: Hesham Soliman To: "mext@ietf.org" Message-ID: Thread-Topic: De-resgistering bindings in MCoA draft Thread-Index: AclfhEl8dDTqbt6aLUmsMfjfg0KV8w== Mime-version: 1.0 Subject: [MEXT] De-resgistering bindings in MCoA draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, I have a comment on this aspect of the spec. The removal of BIDs based on zero lifetime is completely inconsistent with the processing of the BU in MIPv6. The lifetime should be for the entire binding cache for the home address. BIDs should be removed by explicitly by requesting a removal operation in the BID fields (or by simply excluding them from the new BU), not by giving them separate lifetimes. I don't see any reason for complicating things this way. This is not how a binding update is supposed to work. The way it works is that one BU replaces the previous one. Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 16 07: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 76A153A69CC; Tue, 16 Dec 2008 07:18:11 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07F653A69CC for ; Tue, 16 Dec 2008 07:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.387 X-Spam-Level: X-Spam-Status: No, score=-6.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 2CfwU3YgFjFu for ; Tue, 16 Dec 2008 07:18:06 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 18D233A6875 for ; Tue, 16 Dec 2008 07:18:05 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id mBGFHq3a023548; Tue, 16 Dec 2008 09:17:56 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Dec 2008 09:17:55 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Dec 2008 10:17:53 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMOusecase Thread-Index: AclT9cv5JA+1h7g/RR26VTnK4EnOsAANh5DwAr3xviAAGmaNgA== References: From: "Desire Oulai" To: "Vijay Devarapalli" X-OriginalArrivalTime: 16 Dec 2008 15:17:55.0019 (UTC) FILETIME=[785039B0:01C95F91] Cc: mext@ietf.org Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMOusecase X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, See inline! BR Desire > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: December 15, 2008 9:20 PM > To: Ahmad Muhanna; Desire Oulai; mext@ietf.org > Subject: RE: [MEXT] Binding Revocation for IPv6 Mobility > Supports NEMOusecase > > Hi Ahmad and others, > > Its not clear what would cause the home agent to stop > forwarding for a particular mobile network prefix and revoke > that prefix using a BRI message. It can done, but is it > really required? [Desire]: An example could be that the HA want to assign an unused MNP to another MR. Another possibility is that the HA want to stop serving as a NEMO HA for the MR without stopping normal MIPv6 services for the MR. In this case, the HA can revoke all the MNPs. > > If the mobile network prefix is assigned to the mobile router > using binding acknowledgement, then I can see the BRI message > being used to revoke a particular prefix. But if DHCP prefix > delegation is used for assigning the prefixes, does it make > sense to the BRI message for revoking a prefix? [Desire]: I agree that using BRI for MNP revocation is more evident when the MNP is assigned using BAck. However, there could be a case where DHCP is used but the selected HA is not the DHCP server or delegating router in case of PD. In this scenario, the HA can send the BRI to revoke the MNP then the MN can start DHCP operation to release the prefix. > > Vijay > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > On Behalf > > Of Ahmad Muhanna > > Sent: Monday, December 01, 2008 7:23 PM > > To: Desire Oulai; mext@ietf.org > > Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports > > NEMOusecase > > > > Hi Desire, > > > > Added a relative subject. > > > > I guess the usecase is clear and it makes sense to me. > > We can add some text similar to yours to capture this functionality > > under the HA and MN operations after the conclusion of the WGLC.. > > > > BTW: Is there anyone who thinks that we should not add this usecase? > > > > Regards, > > Ahmad > > > > > > > > > > ________________________________ > > > > From: Desire Oulai [mailto:desire.oulai@ericsson.com] > > Sent: Monday, December 01, 2008 2:46 PM > > To: mext@ietf.org > > Cc: Muhanna, Ahmad (RICH1:2H10) > > Subject: > > > > > > > > Hi Ahmad, All, > > > > The Binding revocation draft does not mention > revocation related to > > NEMO. If used as is, the BRI will revoke the binding > between the MR's > > HoA and CoA. I think it's woth adding another level of revocation: > > revocation of Mobile Network Prefixes. A HA may decide to stop > > forwarding data to the CoA for certain MNPs and BR could be > used for > > that. Here is a proposed text for a new section: > > > > "In case of NEMO protocol, the HA follows the same > procedure as MIPv6 > > if the goal is to revoke the binding between the Mobile > Router's HoA > > and CoA. It is also possible to have finer granularity of > revocation > > targeting the Mobile Network Prefixes assigned to the > Mobile Router. > > In this case, the HA sends a BRI message including one or more MNP > > options with the A bit set and the Revocation Trigger set > to a proper > > value, e.g. Administrative Reasons. When receiving this BRI, the MR > > deletes the MNP(s) from the Prefix Information field in the Binding > > Update List and responds with a BRA message. > > The BRA MUST include the MNP(s) contained in the BRI." > > > > Also, Mobile network Prefix should be addes as valid option in > > section "6.2. Binding Revocation Acknowledgement Message". > > > > BR > > Desire > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 16 08:07:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1DF3A6A9B; Tue, 16 Dec 2008 08:07:31 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3BA93A6A9B for ; Tue, 16 Dec 2008 08:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+XIpKC6nvUr for ; Tue, 16 Dec 2008 08:07:29 -0800 (PST) Received: from mail-ew0-f17.google.com (mail-ew0-f17.google.com [209.85.219.17]) by core3.amsl.com (Postfix) with ESMTP id D28663A6A95 for ; Tue, 16 Dec 2008 08:07:28 -0800 (PST) Received: by mail-ew0-f17.google.com with SMTP id 10so3749099ewy.13 for ; Tue, 16 Dec 2008 08:07:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=j+s1mov9/gYxqbucU1uSkHQKM36zpYwFQ9PBdmoJepM=; b=X2b2nn4K4xi4xwINnTY+Hp/LVk92h/gniWvtAeTT6DEIBDGqXNduFbY2QtnHil1Jma frIi3cjLMNRJQ8neGncu2EYLcUB7LqJ/GG6kIUbqHMiCMsJ/ohlsx4iL0UyeeiIJfHer j3NLPk2cp7D6buDNPvTzhV+F5i3Nm1ugAfMi8= 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=Urip6JCCT0mQixEOBY9+Xz1P4F7lnE3LpiYIar9Hpcn+4tVow0LIOR/1iJaySdc3nd /4vqOCGfbAVpZK1UkGI09AoThm4tiWCbthifz8YOC4jhfS6O0jWz6XGC06gItWp965uW qztfG5h45BGHqJ88GeQ9sU2+h58zwjshxrbwQ= Received: by 10.210.20.17 with SMTP id 17mr4056641ebt.37.1229443641948; Tue, 16 Dec 2008 08:07:21 -0800 (PST) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id m5sm963723gve.15.2008.12.16.08.07.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 08:07:20 -0800 (PST) To: mext@ietf.org, "Eddy, Wesley M. (GRC-RCN0)[VZ]" , "Ivancic, William D. (GRC-RHN0)" Date: Tue, 16 Dec 2008 17:07:46 +0100 User-Agent: KMail/1.9.10 References: <200812151250.02020.julien.laganier.IETF@googlemail.com> In-Reply-To: <200812151250.02020.julien.laganier.IETF@googlemail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200812161707.47309.julien.laganier.IETF@googlemail.com> From: Julien Laganier Subject: Re: [MEXT] DRAFT meeting minutes X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Monday 15 December 2008, Julien Laganier wrote: > Hello, > > Below are the draft meeting minutes for the two MEXT sessions at > IETF-73. Please let us note your comments by Dec. 18th, if any: > > BTW, we forgot to tell, but for those of you that have not checked out our meeting minutes already: The MEXT meeting minutes are based on great notes taken by Wes and Will. Thanks Wes and Will, we appreciate your support! --julien & marcelo, MEXT chairs _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 16 08:55: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 0ECAE28C135; Tue, 16 Dec 2008 08:55:22 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E0528C145 for ; Tue, 16 Dec 2008 08:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxOv6trI55DV for ; Tue, 16 Dec 2008 08:55:20 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 5AF9228C155 for ; Tue, 16 Dec 2008 08:55:18 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Dec 2008 11:55:06 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMOusecase Thread-Index: AclT9cv5JA+1h7g/RR26VTnK4EnOsAANh5DwAr3xviAAGmaNgAAENgcg From: "Vijay Devarapalli" To: "Desire Oulai" Cc: mext@ietf.org Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports NEMOusecase X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Desire, > > Its not clear what would cause the home agent to stop > forwarding for a > > particular mobile network prefix and revoke that prefix using a BRI > > message. It can done, but is it really required? > [Desire]: An example could be that the HA want to assign an > unused MNP to another MR. Unused MNP? Once a MNP is allocted to the mobile router, it is free to use it as it wants. There is no such thing as an unued NMP. The home agent does not re-cycle that. > Another possibility is that the HA > want to stop serving as a NEMO HA for the MR without stopping > normal MIPv6 services for the MR. In this case, the HA can > revoke all the MNPs. Switching from NEMO HA to MIPv6 HA shouldn't be allowed. If this happens, the mobile router should be forced to bootstrap an appropriate HA again. Not force the mobile router to operate as a mobile node. Vijay > > If the mobile network prefix is assigned to the mobile router using > > binding acknowledgement, then I can see the BRI message > being used to > > revoke a particular prefix. But if DHCP prefix delegation > is used for > > assigning the prefixes, does it make sense to the BRI message for > > revoking a prefix? > [Desire]: I agree that using BRI for MNP revocation is more > evident when the MNP is assigned using BAck. However, there > could be a case where DHCP is used but the selected HA is not > the DHCP server or delegating router in case of PD. In this > scenario, the HA can send the BRI to revoke the MNP then the > MN can start DHCP operation to release the prefix. > > > > Vijay > > > > > -----Original Message----- > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > > On Behalf > > > Of Ahmad Muhanna > > > Sent: Monday, December 01, 2008 7:23 PM > > > To: Desire Oulai; mext@ietf.org > > > Subject: Re: [MEXT] Binding Revocation for IPv6 Mobility Supports > > > NEMOusecase > > > > > > Hi Desire, > > > > > > Added a relative subject. > > > > > > I guess the usecase is clear and it makes sense to me. > > > We can add some text similar to yours to capture this > functionality > > > under the HA and MN operations after the conclusion of the WGLC.. > > > > > > BTW: Is there anyone who thinks that we should not add > this usecase? > > > > > > Regards, > > > Ahmad > > > > > > > > > > > > > > > ________________________________ > > > > > > From: Desire Oulai [mailto:desire.oulai@ericsson.com] > > > Sent: Monday, December 01, 2008 2:46 PM > > > To: mext@ietf.org > > > Cc: Muhanna, Ahmad (RICH1:2H10) > > > Subject: > > > > > > > > > > > > Hi Ahmad, All, > > > > > > The Binding revocation draft does not mention > > revocation related to > > > NEMO. If used as is, the BRI will revoke the binding > > between the MR's > > > HoA and CoA. I think it's woth adding another level of > revocation: > > > revocation of Mobile Network Prefixes. A HA may decide to stop > > > forwarding data to the CoA for certain MNPs and BR could be > > used for > > > that. Here is a proposed text for a new section: > > > > > > "In case of NEMO protocol, the HA follows the same > > procedure as MIPv6 > > > if the goal is to revoke the binding between the Mobile > > Router's HoA > > > and CoA. It is also possible to have finer granularity of > > revocation > > > targeting the Mobile Network Prefixes assigned to the > > Mobile Router. > > > In this case, the HA sends a BRI message including one or > more MNP > > > options with the A bit set and the Revocation Trigger set > > to a proper > > > value, e.g. Administrative Reasons. When receiving this > BRI, the MR > > > deletes the MNP(s) from the Prefix Information field in > the Binding > > > Update List and responds with a BRA message. > > > The BRA MUST include the MNP(s) contained in the BRI." > > > > > > Also, Mobile network Prefix should be addes as valid option in > > > section "6.2. Binding Revocation Acknowledgement Message". > > > > > > BR > > > Desire > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 16 09:28: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 18A523A6AA9; Tue, 16 Dec 2008 09:28:05 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21D5128C0DC for ; Tue, 16 Dec 2008 09:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.73 X-Spam-Level: X-Spam-Status: No, score=-105.73 tagged_above=-999 required=5 tests=[AWL=0.869, 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 c3AcGspw5oH6 for ; Tue, 16 Dec 2008 09:28:03 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 38D8E3A6AA9 for ; Tue, 16 Dec 2008 09:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1229448476; x=1260984476; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Hesham=20Soliman=20,=20" mext@ietf.org"=20|Date:=20Tue,=2016=20Dec =202008=2009:27:49=20-0800|Subject:=20RE:=20De-resgisteri ng=20bindings=20in=20MCoA=20draft|Thread-Topic:=20De-resg istering=20bindings=20in=20MCoA=20draft|Thread-Index:=20A clfhEl8dDTqbt6aLUmsMfjfg0KV8wAHGYuQ|Message-ID:=20<057632 CE4CE10D45A1A3D6D19206C3A3D85E51B8@NASANEXMB08.na.qualcom m.com>|References:=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5465"=3B=20a=3D"13995630"; bh=cFjZ8MWZRfAimA4xTvfqCS8Sm9e1FXGgFWr6IaGOLbE=; b=VtXTIx2cbQ1+8F+Rgx4QrMs8gBUpDtKBCc5oYbZ0rouw9rcuRQXZLzyG WlEffsiVVMG7yyqFjXTeJc0KRlkitB56gp88QhBJEwyzwDunYBbLIzXsI Q1qUzm5meiRrqEV3qCfbnAaE5W2LKPq8Fz6h2sm8bGBFRcOu+Kqle9Tvg g=; X-IronPort-AV: E=McAfee;i="5300,2777,5465"; a="13995630" 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; 16 Dec 2008 09:27:56 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBGHRtI0010972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Dec 2008 09:27:56 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBGHRlkl022310 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 16 Dec 2008 09:27:55 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Tue, 16 Dec 2008 09:27:51 -0800 From: "Giaretta, Gerardo" To: Hesham Soliman , "mext@ietf.org" Date: Tue, 16 Dec 2008 09:27:49 -0800 Thread-Topic: De-resgistering bindings in MCoA draft Thread-Index: AclfhEl8dDTqbt6aLUmsMfjfg0KV8wAHGYuQ Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D85E51B8@NASANEXMB08.na.qualcomm.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [MEXT] De-resgistering bindings in MCoA draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, I agree we need to clarify better how lifetime and multiple bindings are handled, considering also the interactions with flow bindings. It's right that based on RFC 3775 one BU replaces the previous one, but we need to understand how this applies to multiple bindings. Saying that every BU replaces the previous one in this context implies that the MN needs to include at any BU all the BIDs (and if flow bindings are supported all the FIDs). This is not acceptable as it makes bulk registration mandatory and increases the signaling overhead to an unacceptable value. The current solution in the draft works but there may be cleaner solutions. One cleaner solution would be to treat every BID as logically separate with its own lifetime. In this case if the BID is present in the BU the lifetime of the BU itself is ignored. This approach would keep the principle "one BID replaces the previous one" alive. It is still true that if a BU does not include any BID, then it replaces the entire HoA BCE (i.e. removing or updating all the BIDs). Another possibility is that we assume all BIDs have the same lifetime, which is the lifetime in the BU. However to remove a BID the MN explicitly indicates that with a flag in the BID option. This changes a bit the nature of the MIPv6 signaling. I think the first approach seems the cleanest one. What do you think? Cheers Gerardo > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Hesham > Soliman > Sent: Tuesday, December 16, 2008 5:44 AM > To: mext@ietf.org > Subject: [MEXT] De-resgistering bindings in MCoA draft > > Hi, > > I have a comment on this aspect of the spec. The removal of BIDs based on > zero lifetime is completely inconsistent with the processing of the BU in > MIPv6. The lifetime should be for the entire binding cache for the home > address. BIDs should be removed by explicitly by requesting a removal > operation in the BID fields (or by simply excluding them from the new BU), > not by giving them separate lifetimes. I don't see any reason for > complicating things this way. This is not how a binding update is supposed > to work. The way it works is that one BU replaces the previous one. > > Hesham > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 16 14:03: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 8B46728C1AB; Tue, 16 Dec 2008 14:03:13 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6906A28C1C5 for ; Tue, 16 Dec 2008 14:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.926 X-Spam-Level: X-Spam-Status: No, score=-0.926 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_40=-0.185, 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 v3ykYWFqiLrE for ; Tue, 16 Dec 2008 14:03:11 -0800 (PST) Received: from n56.bullet.mail.sp1.yahoo.com (n56.bullet.mail.sp1.yahoo.com [98.136.44.52]) by core3.amsl.com (Postfix) with SMTP id 5FFAA28C1AB for ; Tue, 16 Dec 2008 14:03:11 -0800 (PST) Received: from [216.252.122.218] by n56.bullet.mail.sp1.yahoo.com with NNFMP; 16 Dec 2008 22:03:04 -0000 Received: from [67.195.9.81] by t3.bullet.sp1.yahoo.com with NNFMP; 16 Dec 2008 22:03:04 -0000 Received: from [67.195.9.97] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 16 Dec 2008 22:03:03 -0000 Received: from [127.0.0.1] by omp101.mail.gq1.yahoo.com with NNFMP; 16 Dec 2008 22:03:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 846079.84994.bm@omp101.mail.gq1.yahoo.com Received: (qmail 87125 invoked by uid 60001); 16 Dec 2008 22:03:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=hne1Ogx9Fy7+2/qiXKi8FHL7Yyqy3XMntrYiGB/yWo617Z8k2CLyI2lqguHaGFrZV9178vtiBwoSRsoXGQ1q1EdfKey3vR3+w7WR+MNWMw9m6lzj+03hHgo02p9+aVr2dX5K1IlUNtCi70VqSB62kwRWvWBgirT6HHA9PSGbES0=; X-YMail-OSG: 7gvyOz8VM1lfz9r4RtjSByCFi4dFqnPdVZMVAdxn_Hgrq96E8AlYQiTA37q8B1kh7j_OmMdwwEN43tT1BLURInP3M.JsWzBiMhm4zk0WUzszL_khtir814gxpruqgi7pd33ILBMRnyzrODSr3IWSS5lNNYgx1hPH.X80tUhFgHRh01UhgCRnsuf8g7PNQMlKkT.8WIKqwyYw8Ds- Received: from [206.16.17.212] by web111402.mail.gq1.yahoo.com via HTTP; Tue, 16 Dec 2008 14:03:03 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <491039B9.6090400@it.uc3m.es> <02d201c95b36$dacf4c70$150ca40a@china.huawei.com> <200812111050.19715.julien.laganier.IETF@googlemail.com> <4B8E03A1-432A-49F9-8DA0-98EF582620FD@lsiit.u-strasbg.fr> <27D6A7A2-B696-484F-8A52-DDAF6ED6C422@lsiit.u-strasbg.fr> <444189.90178.qm@web111414.mail.gq1.yahoo.com> Date: Tue, 16 Dec 2008 14:03:03 -0800 (PST) From: Behcet Sarikaya To: Romain KUNTZ MIME-Version: 1.0 Message-ID: <742028.86808.qm@web111402.mail.gq1.yahoo.com> Cc: mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0392512032==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0392512032== Content-Type: multipart/alternative; boundary="0-2060188226-1229464983=:86808" --0-2060188226-1229464983=:86808 Content-Type: text/plain; charset=us-ascii ________________________________ From: Romain KUNTZ To: Behcet Sarikaya Cc: mext Sent: Monday, December 15, 2008 3:45:58 AM Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt Hi Behcet, On 2008/12/12, at 19:34, Behcet Sarikaya wrote: We have an implementation of NEMO+DHCPv6PD, and here the "mechanism to determine the Mobile Network Prefix(es) owned by the Mobile Router" is a simple message from the DHCPv6 server to the HA that advertises the MNP/HoA pair to the HA. [behcet] I am curious what is this message? Can you please give more details? The DHCPv6 server is co-located with the HA on the same computer. I use a UNIX socket for inter-processus communication with a simple TLV message. In our implementation, at home registration the HA checks with the DHCP server if a prefix is available for this HoA. If so, registration is done (but not forwarding). Once the DHCPv6 server has delegated a prefix to the MR, it informs the HA that it can setup forwarding for the delegated MNP. [behcet] I have a question: If HA were a requesting router (not a delegating router as in Nemo-pd draft), how would you change your implementation architecture? I have a feeling that you are using HA as a requesting router . In our testbed, the HA is a delegating router, and the client & relay are located at the HA. DHCP messages are exchanged through the MR-HA tunnel. If the HA were a requesting router, I guess the testbed, implementation and interaction with the mobility daemon would be completely different, so I can't really tell how I would change the current one. If HA is a requesting router, all you need at the HA is DHCP Client (and possibly colocated with relay if the delegating router is not on-link) I guess you refer to the solution exposed in draft-sarikaya-mext-prefix-delegation? This one suppose that the prefix delegation at the MR happens with BU/BAck messages, which is not the case in our implementation. Note that I do not discuss here which solution is the best, but only present feedback from implementation of one of the solution. If I had chosen the delegation through the BU/BAck, I would certainly have coupled it with a DHCP server as you describe in your draft. [behcet] and that would be much simpler implementation on HA simply requiring DHCP Client with PD capability. Such an implementation has other applications as well such as PMIP, so it could be reused. MR would be much simpler too. Regards, Behcet --0-2060188226-1229464983=:86808 Content-Type: text/html; charset=us-ascii


From: Romain KUNTZ <kuntz@lsiit.u-strasbg.fr>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: mext <mext@ietf.org>
Sent: Monday, December 15, 2008 3:45:58 AM
Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt

Hi Behcet,

On 2008/12/12, at 19:34, Behcet Sarikaya wrote:
We have an implementation of NEMO+DHCPv6PD, and here the "mechanism to determine the Mobile Network Prefix(es) owned by the Mobile Router" is a simple message from the DHCPv6 server to the HA that advertises the MNP/HoA pair to the HA.

[behcet] I am curious what is this message? Can you please give more details?

The DHCPv6 server is co-located with the HA on the same computer. I use a UNIX socket for inter-processus communication with a simple TLV message. 

In our implementation, at home registration the HA checks with the DHCP server if a prefix is available for this HoA. If so, registration is done (but not forwarding). Once the DHCPv6 server has delegated a prefix to the MR, it informs the HA that it can setup forwarding for the delegated MNP.

[behcet] I have a question: If HA were a requesting router (not a delegating router as in Nemo-pd draft), how would you change your implementation architecture? 
I have a feeling that you are using HA as a requesting router .

In our testbed, the HA is a delegating router, and the client & relay are located at the HA. DHCP messages are exchanged through the MR-HA tunnel.

If the HA were a requesting router, I guess the testbed, implementation and interaction with the mobility daemon would be completely different, so I can't really tell how I would change the current one.


If HA is a requesting router, all you need at the HA is DHCP Client (and possibly colocated with relay if the delegating router is not on-link) 

I guess you refer to the solution exposed in draft-sarikaya-mext-prefix-delegation? This one suppose that the prefix delegation at the MR happens with BU/BAck messages, which is not the case in our implementation.

Note that I do not discuss here which solution is the best, but only present feedback from implementation of one of the solution. If I had chosen the delegation through the BU/BAck, I would certainly have coupled it with a DHCP server as you describe in your draft.

[behcet] and that would be much simpler implementation on HA simply requiring DHCP Client with PD capability. Such an implementation has other applications as well such as PMIP, so it could be reused. MR would be much simpler too.

Regards,

Behcet


--0-2060188226-1229464983=:86808-- --===============0392512032== 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 --===============0392512032==-- From kendrickdd@amhaire.com Tue Dec 16 14:36:29 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34AA428C13E for ; Tue, 16 Dec 2008 14:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.495 X-Spam-Level: X-Spam-Status: No, score=-43.495 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQg9O15QhX0U for ; Tue, 16 Dec 2008 14:36:29 -0800 (PST) Received: from alliance-francaise.or.th (unknown [189.60.159.176]) by core3.amsl.com (Postfix) with SMTP id E92F628C13D for ; Tue, 16 Dec 2008 14:36:27 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081216223627.E92F628C13D@core3.amsl.com> Date: Tue, 16 Dec 2008 14:36:27 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mext-bounces@ietf.org Tue Dec 16 14:42: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 21F3928C116; Tue, 16 Dec 2008 14:42:29 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38B5A28C116 for ; Tue, 16 Dec 2008 14:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 RivEdx8TP180 for ; Tue, 16 Dec 2008 14:42:27 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 197AB3A682B for ; Tue, 16 Dec 2008 14:42:26 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LCicK-0005pc-8E; Wed, 17 Dec 2008 09:42:16 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 17 Dec 2008 09:42:10 +1100 From: Hesham Soliman To: "Giaretta, Gerardo" , "mext@ietf.org" Message-ID: Thread-Topic: De-resgistering bindings in MCoA draft Thread-Index: AclfhEl8dDTqbt6aLUmsMfjfg0KV8wAHGYuQAAu2EE0= In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D85E51B8@NASANEXMB08.na.qualcomm.com> Mime-version: 1.0 Subject: Re: [MEXT] De-resgistering bindings in MCoA draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Gerardo, > Hi Hesham, > > I agree we need to clarify better how lifetime and multiple bindings are > handled, considering also the interactions with flow bindings. > > It's right that based on RFC 3775 one BU replaces the previous one, but we > need to understand how this applies to multiple bindings. Saying that every BU > replaces the previous one in this context implies that the MN needs to include > at any BU all the BIDs (and if flow bindings are supported all the FIDs). This > is not acceptable as it makes bulk registration mandatory and increases the > signaling overhead to an unacceptable value. => That's why the FIDs are not included in full for refreshes or deletes. We only send the index. I understand your reasoning, but I think in practice there will rarely be a case where you have more than 2, or max 3 BIDs. So, it's hardly going to be overloading the LTE links. Anyway, assuming that this is an issue, please see my suggestion below. > > The current solution in the draft works but there may be cleaner solutions. > > One cleaner solution would be to treat every BID as logically separate with > its own lifetime. In this case if the BID is present in the BU the lifetime of > the BU itself is ignored. This approach would keep the principle "one BID > replaces the previous one" alive. It is still true that if a BU does not > include any BID, then it replaces the entire HoA BCE (i.e. removing or > updating all the BIDs). > > Another possibility is that we assume all BIDs have the same lifetime, which > is the lifetime in the BU. However to remove a BID the MN explicitly indicates > that with a flag in the BID option. This changes a bit the nature of the MIPv6 > signaling. => Not sure how the second approach works to avoid sending all BIDs. There is a simple way to address this I think. All BIDs have the BU's lifetime (which is how it should work). You send a list of BIDs that need to be refreshed in each BU. Just the numbers for the BIDs themselves. If a number is not in the list then it is effectively removed. The list is essentially a compression mechanism for the BID option. You only need to send the full option if you're changing some of the option's attributes. > > I think the first approach seems the cleanest one. What do you think? => I don't like having different lifetimes for the same HoA bindings. It makes life unnecessarily complex. I can't find any scenario where the MN will want to explicitly have different lifetimes for different flow bindings or CoA bindings. Hesham > > Cheers > Gerardo > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of >> Hesham >> Soliman >> Sent: Tuesday, December 16, 2008 5:44 AM >> To: mext@ietf.org >> Subject: [MEXT] De-resgistering bindings in MCoA draft >> >> Hi, >> >> I have a comment on this aspect of the spec. The removal of BIDs based on >> zero lifetime is completely inconsistent with the processing of the BU in >> MIPv6. The lifetime should be for the entire binding cache for the home >> address. BIDs should be removed by explicitly by requesting a removal >> operation in the BID fields (or by simply excluding them from the new BU), >> not by giving them separate lifetimes. I don't see any reason for >> complicating things this way. This is not how a binding update is supposed >> to work. The way it works is that one BU replaces the previous one. >> >> Hesham >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 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 2A8FC3A6992; Tue, 16 Dec 2008 15:03:35 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55C7A28C182 for ; Tue, 16 Dec 2008 15:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.712 X-Spam-Level: X-Spam-Status: No, score=-105.712 tagged_above=-999 required=5 tests=[AWL=0.887, 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 mZsTy0Z4RYNk for ; Tue, 16 Dec 2008 15:03:33 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 141C33A68CB for ; Tue, 16 Dec 2008 15:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1229468606; x=1261004606; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Hesham=20Soliman=20,=20" mext@ietf.org"=20|Date:=20Tue,=2016=20Dec =202008=2015:03:35=20-0800|Subject:=20RE:=20De-resgisteri ng=20bindings=20in=20MCoA=20draft|Thread-Topic:=20De-resg istering=20bindings=20in=20MCoA=20draft|Thread-Index:=20A clfhEl8dDTqbt6aLUmsMfjfg0KV8wAHGYuQAAu2EE0AAH00oA=3D=3D |Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3D85E5240@ NASANEXMB08.na.qualcomm.com>|References:=20<057632CE4CE10 D45A1A3D6D19206C3A3D85E51B8@NASANEXMB08.na.qualcomm.com> =0D=0A=20 |In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5466"=3B=20a=3D"14010422"; bh=JPcxJNVga4s4OorRNVZed1cMP9FyE27mgBX2pLRv0HQ=; b=qsPzrdvHfZftmbvsaKLwBrVnCVrDS6qG5ugkwrdr2i6sTQcNpQGK1vRx 6zutgQpzOO3FyDrD3h/tqHKTa8f76ZUITjGijkUQdbeUD3H9NZvEoXIxL iz1oj0GJki0fDqR4uq/OFSUuzwwVe8Hm3HCznTBHrLbdHXDZF/A1/0V0K c=; X-IronPort-AV: E=McAfee;i="5300,2777,5466"; a="14010422" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Dec 2008 15:03:25 -0800 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBGN3P8r013263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Dec 2008 15:03:25 -0800 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBGN3Pah020829 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 16 Dec 2008 15:03:25 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Tue, 16 Dec 2008 15:03:24 -0800 From: "Giaretta, Gerardo" To: Hesham Soliman , "mext@ietf.org" Date: Tue, 16 Dec 2008 15:03:35 -0800 Thread-Topic: De-resgistering bindings in MCoA draft Thread-Index: AclfhEl8dDTqbt6aLUmsMfjfg0KV8wAHGYuQAAu2EE0AAH00oA== Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D85E5240@NASANEXMB08.na.qualcomm.com> References: <057632CE4CE10D45A1A3D6D19206C3A3D85E51B8@NASANEXMB08.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [MEXT] De-resgistering bindings in MCoA draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Tuesday, December 16, 2008 2:42 PM > To: Giaretta, Gerardo; mext@ietf.org > Subject: Re: De-resgistering bindings in MCoA draft > > > Hi Gerardo, > > > Hi Hesham, > > > > I agree we need to clarify better how lifetime and multiple bindings are > > handled, considering also the interactions with flow bindings. > > > > It's right that based on RFC 3775 one BU replaces the previous one, but we > > need to understand how this applies to multiple bindings. Saying that every > BU > > replaces the previous one in this context implies that the MN needs to > include > > at any BU all the BIDs (and if flow bindings are supported all the FIDs). > This > > is not acceptable as it makes bulk registration mandatory and increases the > > signaling overhead to an unacceptable value. > > => That's why the FIDs are not included in full for refreshes or deletes. We > only send the index. I understand your reasoning, but I think in practice > there will rarely be a case where you have more than 2, or max 3 BIDs. So, > it's hardly going to be overloading the LTE links. Anyway, assuming that > this is an issue, please see my suggestion below. > Yes, let's assume that as it is an issue if we want to apply this to 3GPP. > > > > The current solution in the draft works but there may be cleaner solutions. > > > > One cleaner solution would be to treat every BID as logically separate with > > its own lifetime. In this case if the BID is present in the BU the lifetime > of > > the BU itself is ignored. This approach would keep the principle "one BID > > replaces the previous one" alive. It is still true that if a BU does not > > include any BID, then it replaces the entire HoA BCE (i.e. removing or > > updating all the BIDs). > > > > Another possibility is that we assume all BIDs have the same lifetime, which > > is the lifetime in the BU. However to remove a BID the MN explicitly > indicates > > that with a flag in the BID option. This changes a bit the nature of the > MIPv6 > > signaling. > > => Not sure how the second approach works to avoid sending all BIDs. A Refresh BU will always include all BIDs. But adding a BID and removing a BID would not require all BIDs. > There is a simple way to address this I think. All BIDs have the BU's > lifetime (which is how it should work). > You send a list of BIDs that need to be refreshed in each BU. Just the > numbers for the BIDs themselves. If a number is not in the list then it is > effectively removed. The issue I have in general with bulk registration (and your proposal is extending the lifetime of all BIDs with one BU so it is basically a compressed bulk registration) is that it may be considered not optimal from a security point of view. Basically the usage of bulk registration has the same issues we have identified for the Alternate CoA option and it allows the MN to start redirecting attacks. This is why I am also concerned about including all the BIDs. The MN could be required to always send the BU for one BID from the CoA that needs to be registered for that BID. > The list is essentially a compression mechanism for the BID option. You only > need to send the full option if you're changing some of the option's > attributes. > > > > > > I think the first approach seems the cleanest one. What do you think? > > => I don't like having different lifetimes for the same HoA bindings. It > makes life unnecessarily complex. I can't find any scenario where the MN > will want to explicitly have different lifetimes for different flow bindings > or CoA bindings. > I don't care much if the lifetime is the same or not. I agree with you there is not a clear scenario where different lifetimes are needed. However I think we should find a clean solution which does not imply always the usage of bulk registration. To me the cleanest way is to associated a specific lifetime to each BID, but I am open to suggestions. Gerardo > Hesham > > > > > > Cheers > > Gerardo > > > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > >> Hesham > >> Soliman > >> Sent: Tuesday, December 16, 2008 5:44 AM > >> To: mext@ietf.org > >> Subject: [MEXT] De-resgistering bindings in MCoA draft > >> > >> Hi, > >> > >> I have a comment on this aspect of the spec. The removal of BIDs based on > >> zero lifetime is completely inconsistent with the processing of the BU in > >> MIPv6. The lifetime should be for the entire binding cache for the home > >> address. BIDs should be removed by explicitly by requesting a removal > >> operation in the BID fields (or by simply excluding them from the new BU), > >> not by giving them separate lifetimes. I don't see any reason for > >> complicating things this way. This is not how a binding update is supposed > >> to work. The way it works is that one BU replaces the previous one. > >> > >> Hesham > >> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 16 15:11:56 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5E3A28C1B7; Tue, 16 Dec 2008 15:11:55 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ECDB28C1B7 for ; Tue, 16 Dec 2008 15:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 p-cyZooH78pi for ; Tue, 16 Dec 2008 15:11:53 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 4797728C13E for ; Tue, 16 Dec 2008 15:11:52 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LCj4o-000768-1P; Wed, 17 Dec 2008 10:11:42 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 17 Dec 2008 10:11:37 +1100 From: Hesham Soliman To: "Giaretta, Gerardo" , "mext@ietf.org" Message-ID: Thread-Topic: [MEXT] De-resgistering bindings in MCoA draft Thread-Index: AclfhEl8dDTqbt6aLUmsMfjfg0KV8wAHGYuQAAu2EE0AAH00oAAAihqO In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D85E5240@NASANEXMB08.na.qualcomm.com> Mime-version: 1.0 Subject: Re: [MEXT] De-resgistering bindings in MCoA draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org >>> Another possibility is that we assume all BIDs have the same lifetime, which >>> is the lifetime in the BU. However to remove a BID the MN explicitly >> indicates >>> that with a flag in the BID option. This changes a bit the nature of the >> MIPv6 >>> signaling. >> >> => Not sure how the second approach works to avoid sending all BIDs. > > A Refresh BU will always include all BIDs. But adding a BID and removing a BID > would not require all BIDs. => But I thought you were trying to avoid including all BIDs in every refresh. > >> There is a simple way to address this I think. All BIDs have the BU's >> lifetime (which is how it should work). >> You send a list of BIDs that need to be refreshed in each BU. Just the >> numbers for the BIDs themselves. If a number is not in the list then it is >> effectively removed. > > The issue I have in general with bulk registration (and your proposal is > extending the lifetime of all BIDs with one BU so it is basically a compressed > bulk registration) is that it may be considered not optimal from a security > point of view. Basically the usage of bulk registration has the same issues we > have identified for the Alternate CoA option and it allows the MN to start > redirecting attacks. This is why I am also concerned about including all the > BIDs. => But that's an issue against bulk registrations in general. If we have bulk registrations in the draft then this proposal is fine. If we remove bulk registrations from the draft then there is no point in this discussion because we have to send one BU for each BID anyway. If we allow each BID to have the lifetime of the BU then problem solved. But I thought you'd be concerned about removing bulk registrations because if you think that: A. There will be a lot of BIDs (which is what you mentioned earlier for the bandwidth argument) B. Bandwidth is an issue. Then sending one BU per BID would be an issue. >>> I think the first approach seems the cleanest one. What do you think? >> >> => I don't like having different lifetimes for the same HoA bindings. It >> makes life unnecessarily complex. I can't find any scenario where the MN >> will want to explicitly have different lifetimes for different flow bindings >> or CoA bindings. >> > > I don't care much if the lifetime is the same or not. I agree with you there > is not a clear scenario where different lifetimes are needed. However I think > we should find a clean solution which does not imply always the usage of bulk > registration. To me the cleanest way is to associated a specific lifetime to > each BID, but I am open to suggestions. => Well, if we have bulk registrations, then I think the cleanest way is to send a few bytes to refresh them. If we don't have bulk registrations then there is no problem to discuss I think. Hesham > > Gerardo > > >> Hesham >> >> >>> >>> Cheers >>> Gerardo >>> >>>> -----Original Message----- >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of >>>> Hesham >>>> Soliman >>>> Sent: Tuesday, December 16, 2008 5:44 AM >>>> To: mext@ietf.org >>>> Subject: [MEXT] De-resgistering bindings in MCoA draft >>>> >>>> Hi, >>>> >>>> I have a comment on this aspect of the spec. The removal of BIDs based on >>>> zero lifetime is completely inconsistent with the processing of the BU in >>>> MIPv6. The lifetime should be for the entire binding cache for the home >>>> address. BIDs should be removed by explicitly by requesting a removal >>>> operation in the BID fields (or by simply excluding them from the new BU), >>>> not by giving them separate lifetimes. I don't see any reason for >>>> complicating things this way. This is not how a binding update is supposed >>>> to work. The way it works is that one BU replaces the previous one. >>>> >>>> Hesham >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ > MEXT mailing list > You got attachement! (https://www.codealias.info/~zrelli/attachements/) _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 16 21:54:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D7E83A6AB2; Tue, 16 Dec 2008 21:54:44 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DCA63A6AB6 for ; Tue, 16 Dec 2008 21:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.699 X-Spam-Level: X-Spam-Status: No, score=-103.699 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqxyKxES8zbT for ; Tue, 16 Dec 2008 21:54:41 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 070713A67D0 for ; Tue, 16 Dec 2008 21:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1229493274; x=1261029274; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Hesham=20Soliman=20,=20" mext@ietf.org"=20|Date:=20Tue,=2016=20Dec =202008=2021:51:35=20-0800|Subject:=20RE:=20[MEXT]=20De-r esgistering=20bindings=20in=20MCoA=20draft|Thread-Topic: =20[MEXT]=20De-resgistering=20bindings=20in=20MCoA=20draf t|Thread-Index:=20AclfhEl8dDTqbt6aLUmsMfjfg0KV8wAHGYuQAAu 2EE0AAH00oAAAihqOAA34EnA=3D|Message-ID:=20<057632CE4CE10D 45A1A3D6D19206C3A3D85D72AF@NASANEXMB08.na.qualcomm.com> |References:=20<057632CE4CE10D45A1A3D6D19206C3A3D85E5240@ NASANEXMB08.na.qualcomm.com>,|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20 en-US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5100,188,5466"=3B=20a=3D"13996082"; bh=j625vzwhXWuPmxSE3E/Zhs7vTA5ZafQkaxaUZbFGRGc=; b=gdE2anwz/IuYzFqMQZk4p3OghzAfYIfSs+UpW0xXUPbgi/XfFy6F1vo5 VV2c8i+P0Ic+xURpPcaRGJ1C9aJIsVaH2heUh7aPkjoCcxE7hAJStlbZP YqrY73mES2hgXg1+Pw8pob0YDUBeS0KbjDOMwM0tmhmQQMFBLD32wYKYS 8=; X-IronPort-AV: E=McAfee;i="5100,188,5466"; a="13996082" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Dec 2008 21:54:33 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBH5sXB7032529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Dec 2008 21:54:33 -0800 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBH5sXZo022472 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 16 Dec 2008 21:54:33 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub06.na.qualcomm.com ([129.46.134.254]) with mapi; Tue, 16 Dec 2008 21:54:33 -0800 From: "Giaretta, Gerardo" To: Hesham Soliman , "mext@ietf.org" Date: Tue, 16 Dec 2008 21:51:35 -0800 Thread-Topic: [MEXT] De-resgistering bindings in MCoA draft Thread-Index: AclfhEl8dDTqbt6aLUmsMfjfg0KV8wAHGYuQAAu2EE0AAH00oAAAihqOAA34EnA= Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D85D72AF@NASANEXMB08.na.qualcomm.com> References: <057632CE4CE10D45A1A3D6D19206C3A3D85E5240@NASANEXMB08.na.qualcomm.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [MEXT] De-resgistering bindings in MCoA draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, I think the point is that we should enable also a solution which does not rely on bulk registration. This is because bulk registration may not be allowed in some systems as I mentioned below and also as mentioned in the draft. In case bulk registration is not used, each BU will contain only one BID. The lifetime of this BID is indicated in the main BU message. This implies that logically at the HA's BC and at the MN's BUL there are different lifetimes for each BID. If this is the case then the current solution of the draft to put lifetime=0 in the BU to deregister one BID makes sense. What do you think? Gerardo ________________________________________ From: Hesham Soliman [hesham@elevatemobile.com] Sent: Tuesday, December 16, 2008 3:11 PM To: Giaretta, Gerardo; mext@ietf.org Subject: Re: [MEXT] De-resgistering bindings in MCoA draft >>> Another possibility is that we assume all BIDs have the same lifetime, which >>> is the lifetime in the BU. However to remove a BID the MN explicitly >> indicates >>> that with a flag in the BID option. This changes a bit the nature of the >> MIPv6 >>> signaling. >> >> => Not sure how the second approach works to avoid sending all BIDs. > > A Refresh BU will always include all BIDs. But adding a BID and removing a BID > would not require all BIDs. => But I thought you were trying to avoid including all BIDs in every refresh. > >> There is a simple way to address this I think. All BIDs have the BU's >> lifetime (which is how it should work). >> You send a list of BIDs that need to be refreshed in each BU. Just the >> numbers for the BIDs themselves. If a number is not in the list then it is >> effectively removed. > > The issue I have in general with bulk registration (and your proposal is > extending the lifetime of all BIDs with one BU so it is basically a compressed > bulk registration) is that it may be considered not optimal from a security > point of view. Basically the usage of bulk registration has the same issues we > have identified for the Alternate CoA option and it allows the MN to start > redirecting attacks. This is why I am also concerned about including all the > BIDs. => But that's an issue against bulk registrations in general. If we have bulk registrations in the draft then this proposal is fine. If we remove bulk registrations from the draft then there is no point in this discussion because we have to send one BU for each BID anyway. If we allow each BID to have the lifetime of the BU then problem solved. But I thought you'd be concerned about removing bulk registrations because if you think that: A. There will be a lot of BIDs (which is what you mentioned earlier for the bandwidth argument) B. Bandwidth is an issue. Then sending one BU per BID would be an issue. >>> I think the first approach seems the cleanest one. What do you think? >> >> => I don't like having different lifetimes for the same HoA bindings. It >> makes life unnecessarily complex. I can't find any scenario where the MN >> will want to explicitly have different lifetimes for different flow bindings >> or CoA bindings. >> > > I don't care much if the lifetime is the same or not. I agree with you there > is not a clear scenario where different lifetimes are needed. However I think > we should find a clean solution which does not imply always the usage of bulk > registration. To me the cleanest way is to associated a specific lifetime to > each BID, but I am open to suggestions. => Well, if we have bulk registrations, then I think the cleanest way is to send a few bytes to refresh them. If we don't have bulk registrations then there is no problem to discuss I think. Hesham > > Gerardo > > >> Hesham >> >> >>> >>> Cheers >>> Gerardo >>> >>>> -----Original Message----- >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of >>>> Hesham >>>> Soliman >>>> Sent: Tuesday, December 16, 2008 5:44 AM >>>> To: mext@ietf.org >>>> Subject: [MEXT] De-resgistering bindings in MCoA draft >>>> >>>> Hi, >>>> >>>> I have a comment on this aspect of the spec. The removal of BIDs based on >>>> zero lifetime is completely inconsistent with the processing of the BU in >>>> MIPv6. The lifetime should be for the entire binding cache for the home >>>> address. BIDs should be removed by explicitly by requesting a removal >>>> operation in the BID fields (or by simply excluding them from the new BU), >>>> not by giving them separate lifetimes. I don't see any reason for >>>> complicating things this way. This is not how a binding update is supposed >>>> to work. The way it works is that one BU replaces the previous one. >>>> >>>> Hesham >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ > MEXT mailing list > You got attachement! (https://www.codealias.info/~zrelli/attachements/) _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 16 21:59: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 B02383A6AE9; Tue, 16 Dec 2008 21:59:26 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E7823A6AEB for ; Tue, 16 Dec 2008 21:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id einUg-wWt2CO for ; Tue, 16 Dec 2008 21:59:24 -0800 (PST) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.231]) by core3.amsl.com (Postfix) with ESMTP id 212D73A6AD0 for ; Tue, 16 Dec 2008 21:59:24 -0800 (PST) Received: by qb-out-0506.google.com with SMTP id d11so1859317qbd.41 for ; Tue, 16 Dec 2008 21:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:cc :subject:in-reply-to:references:user-agent:organization:mime-version :content-type; bh=EdxltWT4HAvOYDZ/q8pZki5a1TPTCGxqgB24ajJySEk=; b=GZcKE6Dx00PLzJnpp44BREQVDOb6JO2+8KH0EawpedqTzrrfwmFVLPl7AyKgURVJiE PxGDYgZ5Fp6gugOFbpj+vlz1B4UI6rk830zLptn3/9aT7d3Lof1fzdql6k18X+cNqd8s gtfecO4sRDKN7jU13KwJ0jDwUdYSPLM5TtAek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:organization:mime-version:content-type; b=mw5Lvy4iX4UYPcWr/UPRuP4hYTDK3O/H/Lk/fxmw5JjTlJyqCAHZffUHiHnvCA9BCy lXj+dX3rRHTdFViw8J3gKucKlX1boyG2YrNc4pG02pxUbE22/M0atcj98EEbGWQtVOkV jj7kfe6r1eWFho+gH540UFiJMoShhJCAp2Isc= Received: by 10.142.234.16 with SMTP id g16mr144718wfh.264.1229493555857; Tue, 16 Dec 2008 21:59:15 -0800 (PST) Received: from ryuji-wakikawa-no-macbook-pro.local.sfc.wide.ad.jp (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 24sm1856061wff.37.2008.12.16.21.59.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 21:59:15 -0800 (PST) Date: Wed, 17 Dec 2008 13:58:30 +0900 Message-ID: From: Ryuji Wakikawa To: Hesham Soliman In-Reply-To: References: User-Agent: Wanderlust/2.14.1 (Bad Medicine-pre) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin9) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: "mext@ietf.org" Subject: Re: [MEXT] De-resgistering bindings in MCoA draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hesham, When you use the bulk registration, all bindings share the same lifetime specified in BU message. This is what you proposed here. We also have specified Overwrite flag to explicitly replace all the bindings corresponding to the home address. When MN does not use the bulk registration, each binding registering with BID is treated as a regular binding. Each binding will have individual lifetime. It is not the operation of BID removal, but of a binding removal. Removing a binding with zero lifetime is consisitent with MIP6. ryuji At Wed, 17 Dec 2008 00:43:33 +1100, Hesham Soliman wrote: > > Hi, > > I have a comment on this aspect of the spec. The removal of BIDs based on > zero lifetime is completely inconsistent with the processing of the BU in > MIPv6. The lifetime should be for the entire binding cache for the home > address. BIDs should be removed by explicitly by requesting a removal > operation in the BID fields (or by simply excluding them from the new BU), > not by giving them separate lifetimes. I don't see any reason for > complicating things this way. This is not how a binding update is supposed > to work. The way it works is that one BU replaces the previous one. > > Hesham > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 16 21:59: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 4C7BC3A6AEF; Tue, 16 Dec 2008 21:59:34 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 349D53A6AED for ; Tue, 16 Dec 2008 21:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u98PyA+mvVHX for ; Tue, 16 Dec 2008 21:59:32 -0800 (PST) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.231]) by core3.amsl.com (Postfix) with ESMTP id E5C4A3A67F5 for ; Tue, 16 Dec 2008 21:59:31 -0800 (PST) Received: by qb-out-0506.google.com with SMTP id d11so1859317qbd.41 for ; Tue, 16 Dec 2008 21:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:cc :subject:in-reply-to:references:user-agent:organization:mime-version :content-type; bh=3t2ItrSuDrg3IQ/hSaCA8eLbmT7m+5VaoncEzJ+nOUo=; b=t+zLWnK07J9i4VKcs2QIbyl4tkcN4E4jC6MpaJIRK4XT6ESg1RIIwhxhzG7khiNbGN gYSmci29QYaFv47vXq3YNbykgNb1JNRs39OP0gCOnBGU8n/A1i46RldlLE7tiDKl4P/D om4DYwMHd6aYZxH+RYk/vTZ4Nhe5xQqcVjPds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:organization:mime-version:content-type; b=dJSo44GdOg8E/1Rq+Vq91kYweNjQ9Zpg6pjTxqccz9eXSlR2yy3mY8tCzAGzeMNiWO Vxj6Jntj42R6yLxXVPXdRdeKZtTTXCc7laIRyHC8UJvW/5prKxK4bDP/WOVbZ/lIVuJt BPi9BRO3pelFEhxKrqphRmyY8BPCj4PB/5hmQ= Received: by 10.142.162.5 with SMTP id k5mr155780wfe.15.1229493564640; Tue, 16 Dec 2008 21:59:24 -0800 (PST) Received: from ryuji-wakikawa-no-macbook-pro.local.sfc.wide.ad.jp (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 30sm10490697wfd.4.2008.12.16.21.59.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 21:59:23 -0800 (PST) Date: Wed, 17 Dec 2008 14:13:42 +0900 Message-ID: From: Ryuji Wakikawa To: Hesham Soliman In-Reply-To: References: <057632CE4CE10D45A1A3D6D19206C3A3D85E51B8@NASANEXMB08.na.qualcomm.com> User-Agent: Wanderlust/2.14.1 (Bad Medicine-pre) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin9) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: "mext@ietf.org" Subject: Re: [MEXT] De-resgistering bindings in MCoA draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi At Wed, 17 Dec 2008 09:42:10 +1100, Hesham Soliman wrote: > > > Hi Gerardo, > > > Hi Hesham, > > > > I agree we need to clarify better how lifetime and multiple bindings are > > handled, considering also the interactions with flow bindings. > > > > It's right that based on RFC 3775 one BU replaces the previous one, but we > > need to understand how this applies to multiple bindings. Saying that every BU > > replaces the previous one in this context implies that the MN needs to include > > at any BU all the BIDs (and if flow bindings are supported all the FIDs). This > > is not acceptable as it makes bulk registration mandatory and increases the > > signaling overhead to an unacceptable value. > > => That's why the FIDs are not included in full for refreshes or deletes. We > only send the index. I understand your reasoning, but I think in practice > there will rarely be a case where you have more than 2, or max 3 BIDs. So, > it's hardly going to be overloading the LTE links. Anyway, assuming that > this is an issue, please see my suggestion below. > > > > > The current solution in the draft works but there may be cleaner solutions. > > > > One cleaner solution would be to treat every BID as logically separate with > > its own lifetime. In this case if the BID is present in the BU the lifetime of > > the BU itself is ignored. This approach would keep the principle "one BID > > replaces the previous one" alive. It is still true that if a BU does not > > include any BID, then it replaces the entire HoA BCE (i.e. removing or > > updating all the BIDs). > > > > Another possibility is that we assume all BIDs have the same lifetime, which > > is the lifetime in the BU. However to remove a BID the MN explicitly indicates > > that with a flag in the BID option. This changes a bit the nature of the MIPv6 > > signaling. > > => Not sure how the second approach works to avoid sending all BIDs. > There is a simple way to address this I think. All BIDs have the BU's > lifetime (which is how it should work). > You send a list of BIDs that need to be refreshed in each BU. Just the > numbers for the BIDs themselves. If a number is not in the list then it is > effectively removed. > The list is essentially a compression mechanism for the BID option. You only > need to send the full option if you're changing some of the option's > attributes. > > > > > > I think the first approach seems the cleanest one. What do you think? > > => I don't like having different lifetimes for the same HoA bindings. It > makes life unnecessarily complex. I can't find any scenario where the MN > will want to explicitly have different lifetimes for different flow bindings > or CoA bindings. If you use the bulk registration, you only have one lifetime for every bindings. in section 5.3 "To use bulk registration, the mobile node includes a Binding Identifier Mobility option for each BID and Care-of address pair it wants to register in the same Binding Update message. This is shown in Figure 7. The rest of the fields and options in the Binding Update such as Lifetime, Sequence Number, and the flags in the Binding Update are common across all care-of addresses." regards, ryuji > Hesham > > > > > > Cheers > > Gerardo > > > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > >> Hesham > >> Soliman > >> Sent: Tuesday, December 16, 2008 5:44 AM > >> To: mext@ietf.org > >> Subject: [MEXT] De-resgistering bindings in MCoA draft > >> > >> Hi, > >> > >> I have a comment on this aspect of the spec. The removal of BIDs based on > >> zero lifetime is completely inconsistent with the processing of the BU in > >> MIPv6. The lifetime should be for the entire binding cache for the home > >> address. BIDs should be removed by explicitly by requesting a removal > >> operation in the BID fields (or by simply excluding them from the new BU), > >> not by giving them separate lifetimes. I don't see any reason for > >> complicating things this way. This is not how a binding update is supposed > >> to work. The way it works is that one BU replaces the previous one. > >> > >> Hesham > >> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 16 21:59: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 D0A003A6AF3; Tue, 16 Dec 2008 21:59:42 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D18223A67F5 for ; Tue, 16 Dec 2008 21:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiQUCFXwkQ8U for ; Tue, 16 Dec 2008 21:59:38 -0800 (PST) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.231]) by core3.amsl.com (Postfix) with ESMTP id 3FA0C3A6AF5 for ; Tue, 16 Dec 2008 21:59:36 -0800 (PST) Received: by qb-out-0506.google.com with SMTP id d11so1859317qbd.41 for ; Tue, 16 Dec 2008 21:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:cc :subject:in-reply-to:references:user-agent:organization:mime-version :content-type; bh=8/elgEfNpGmaqNCcgW10Ka8l8VcCyXA3J8Zabc0GYdQ=; b=OrE+lbwyBBlWnMYJnqUfrbgfTekz5oIQLUc6pT7Mj84iAQfluqUL32g8A//LXjgER4 sQFgzrDlPYPgtWpPbU4njGJ/SFfPP9izdjGmiL+NKA0glNocBXH/ZyXjN5RxosHHmm3x 4P1S/S9ifKYTEj3O0/04B62wL6wUTcKSKmX2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:organization:mime-version:content-type; b=UpxTvyYhl1tlPPnO/qxGmHx8Ac03KJzOPcC9EEauq1z0Ujsf4PIon4YLyWpxzNbPTA 7benRg894Cg1/jfJD0Rhc1PrT2lxqmM2aAkw3URq4rBWD9u0koXw4V6hsPrMGHSf9v8B DF55IMFU3bGdY5bPSkoM5C8JXRlZqeDJjJBN8= Received: by 10.143.4.16 with SMTP id g16mr151483wfi.124.1229493568914; Tue, 16 Dec 2008 21:59:28 -0800 (PST) Received: from ryuji-wakikawa-no-macbook-pro.local.sfc.wide.ad.jp (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 22sm2766820wfg.50.2008.12.16.21.59.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 21:59:28 -0800 (PST) Date: Wed, 17 Dec 2008 14:13:55 +0900 Message-ID: From: Ryuji Wakikawa To: "Giaretta, Gerardo" In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D85E5240@NASANEXMB08.na.qualcomm.com> References: <057632CE4CE10D45A1A3D6D19206C3A3D85E51B8@NASANEXMB08.na.qualcomm.com> <057632CE4CE10D45A1A3D6D19206C3A3D85E5240@NASANEXMB08.na.qualcomm.com> User-Agent: Wanderlust/2.14.1 (Bad Medicine-pre) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin9) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: "mext@ietf.org" Subject: Re: [MEXT] De-resgistering bindings in MCoA draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Gerardo, At Tue, 16 Dec 2008 15:03:35 -0800, Giaretta, Gerardo wrote: > > Hi Hesham, > > > -----Original Message----- > > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > > Sent: Tuesday, December 16, 2008 2:42 PM > > To: Giaretta, Gerardo; mext@ietf.org > > Subject: Re: De-resgistering bindings in MCoA draft > > > > > > Hi Gerardo, > > > > > Hi Hesham, > > > > > > I agree we need to clarify better how lifetime and multiple bindings are > > > handled, considering also the interactions with flow bindings. > > > > > > It's right that based on RFC 3775 one BU replaces the previous one, but we > > > need to understand how this applies to multiple bindings. Saying that every > > BU > > > replaces the previous one in this context implies that the MN needs to > > include > > > at any BU all the BIDs (and if flow bindings are supported all the FIDs). > > This > > > is not acceptable as it makes bulk registration mandatory and increases the > > > signaling overhead to an unacceptable value. > > > > => That's why the FIDs are not included in full for refreshes or deletes. We > > only send the index. I understand your reasoning, but I think in practice > > there will rarely be a case where you have more than 2, or max 3 BIDs. So, > > it's hardly going to be overloading the LTE links. Anyway, assuming that > > this is an issue, please see my suggestion below. > > > > Yes, let's assume that as it is an issue if we want to apply this to 3GPP. > > > > > > > The current solution in the draft works but there may be cleaner solutions. > > > > > > One cleaner solution would be to treat every BID as logically separate with > > > its own lifetime. In this case if the BID is present in the BU the lifetime > > of > > > the BU itself is ignored. This approach would keep the principle "one BID > > > replaces the previous one" alive. It is still true that if a BU does not > > > include any BID, then it replaces the entire HoA BCE (i.e. removing or > > > updating all the BIDs). > > > > > > Another possibility is that we assume all BIDs have the same lifetime, which > > > is the lifetime in the BU. However to remove a BID the MN explicitly > > indicates > > > that with a flag in the BID option. This changes a bit the nature of the > > MIPv6 > > > signaling. > > > > => Not sure how the second approach works to avoid sending all BIDs. > > A Refresh BU will always include all BIDs. But adding a BID and removing a BID would not require all BIDs. > > > There is a simple way to address this I think. All BIDs have the BU's > > lifetime (which is how it should work). > > You send a list of BIDs that need to be refreshed in each BU. Just the > > numbers for the BIDs themselves. If a number is not in the list then it is > > effectively removed. > > The issue I have in general with bulk registration (and your proposal is extending the lifetime of all BIDs with one BU so it is basically a compressed bulk registration) is that it may be considered not optimal from a security point of view. Basically the usage of bulk registration has the same issues we have identified for the Alternate CoA option and it allows the MN to start redirecting attacks. This is why I am also concerned about including all the BIDs. > > The MN could be required to always send the BU for one BID from the CoA that needs to be registered for that BID. > > > The list is essentially a compression mechanism for the BID option. You only > > need to send the full option if you're changing some of the option's > > attributes. > > > > > > > > > > I think the first approach seems the cleanest one. What do you think? > > > > => I don't like having different lifetimes for the same HoA bindings. It > > makes life unnecessarily complex. I can't find any scenario where the MN > > will want to explicitly have different lifetimes for different flow bindings > > or CoA bindings. > > > > I don't care much if the lifetime is the same or not. I agree with > you there is not a clear scenario where different lifetimes are > needed. However I think we should find a clean solution which does > not imply always the usage of bulk registration. To me the cleanest > way is to associated a specific lifetime to each BID, but I am open > to suggestions. In MCoA, we have two modes to register multiple bindings - Bulk the use single lifetime for all bindings - No Bulk spseparate lifetime per binding. I think this solves both Hesham and your issues. The confusion here is that we only mention the case of the non-bulk mode in Section 5.4 "Binding deregistration". I can add some texts how the binding removal can be done for the bulk mode. ryuji > Gerardo > > > > Hesham > > > > > > > > > > Cheers > > > Gerardo > > > > > >> -----Original Message----- > > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > > >> Hesham > > >> Soliman > > >> Sent: Tuesday, December 16, 2008 5:44 AM > > >> To: mext@ietf.org > > >> Subject: [MEXT] De-resgistering bindings in MCoA draft > > >> > > >> Hi, > > >> > > >> I have a comment on this aspect of the spec. The removal of BIDs based on > > >> zero lifetime is completely inconsistent with the processing of the BU in > > >> MIPv6. The lifetime should be for the entire binding cache for the home > > >> address. BIDs should be removed by explicitly by requesting a removal > > >> operation in the BID fields (or by simply excluding them from the new BU), > > >> not by giving them separate lifetimes. I don't see any reason for > > >> complicating things this way. This is not how a binding update is supposed > > >> to work. The way it works is that one BU replaces the previous one. > > >> > > >> Hesham > > >> > > >> > > >> _______________________________________________ > > >> MEXT mailing list > > >> MEXT@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 16 21:59: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 895573A6AF9; Tue, 16 Dec 2008 21:59:43 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A1723A6AF3 for ; Tue, 16 Dec 2008 21:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkgAoEeE8pqr for ; Tue, 16 Dec 2008 21:59:41 -0800 (PST) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.231]) by core3.amsl.com (Postfix) with ESMTP id 1C9983A6AF4 for ; Tue, 16 Dec 2008 21:59:40 -0800 (PST) Received: by qb-out-0506.google.com with SMTP id d11so1859317qbd.41 for ; Tue, 16 Dec 2008 21:59:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:cc :subject:in-reply-to:references:user-agent:organization:mime-version :content-type; bh=soxX4ugil7hUnbRAUabx0Es6HWKjVdV9TK9oTB64H2o=; b=NR53Tj/iZ1LlNtmbsAPoBksJ9bwZzx4gBaLyRBtZeRd04Uf5Ro5VKSZMTyIF/XGW1V 5TMWAEpsQeydesSKqbKrn+XRC2GI6GUSX+BadoMuQEF4BPpeIybCz3i5stliPhlRox5q vkAz7GaaLih203I1U24ZTZ5BvN05i0cXpvB6s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:organization:mime-version:content-type; b=GSZLSJzH4nUMypLlP18w5FsG/M7lhRqN09BDf8opjQOWEP3UITfioKCso/nk+cTvxA COqb5xsNr6A/I5mdNQyTN/6UNbNatNUhNnbB9t/rXYDrdnW1Sw1aDV/QUw7i8SS1YKNo MdAgx0mm2eyQwAVNbBuFsEC6dFeSurM6s/4AE= Received: by 10.142.54.11 with SMTP id c11mr155505wfa.14.1229493572811; Tue, 16 Dec 2008 21:59:32 -0800 (PST) Received: from ryuji-wakikawa-no-macbook-pro.local.sfc.wide.ad.jp (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 22sm3478575wfi.18.2008.12.16.21.59.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 21:59:32 -0800 (PST) Date: Wed, 17 Dec 2008 14:14:05 +0900 Message-ID: From: Ryuji Wakikawa To: Hesham Soliman In-Reply-To: References: <057632CE4CE10D45A1A3D6D19206C3A3D85E5240@NASANEXMB08.na.qualcomm.com> User-Agent: Wanderlust/2.14.1 (Bad Medicine-pre) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin9) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: "mext@ietf.org" Subject: Re: [MEXT] De-resgistering bindings in MCoA draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, For lacking the CoA verification in the bulk-registration, we have some texts in Security Consideration. HA can reject the bulk registration if it wants strict CoA verification. We support the bulk registration, but operators can always disable this feature. ryuji At Wed, 17 Dec 2008 10:11:37 +1100, Hesham Soliman wrote: > > > >>> Another possibility is that we assume all BIDs have the same lifetime, which > >>> is the lifetime in the BU. However to remove a BID the MN explicitly > >> indicates > >>> that with a flag in the BID option. This changes a bit the nature of the > >> MIPv6 > >>> signaling. > >> > >> => Not sure how the second approach works to avoid sending all BIDs. > > > > A Refresh BU will always include all BIDs. But adding a BID and removing a BID > > would not require all BIDs. > > => But I thought you were trying to avoid including all BIDs in every > refresh. > > > > >> There is a simple way to address this I think. All BIDs have the BU's > >> lifetime (which is how it should work). > >> You send a list of BIDs that need to be refreshed in each BU. Just the > >> numbers for the BIDs themselves. If a number is not in the list then it is > >> effectively removed. > > > > The issue I have in general with bulk registration (and your proposal is > > extending the lifetime of all BIDs with one BU so it is basically a compressed > > bulk registration) is that it may be considered not optimal from a security > > point of view. Basically the usage of bulk registration has the same issues we > > have identified for the Alternate CoA option and it allows the MN to start > > redirecting attacks. This is why I am also concerned about including all the > > BIDs. > > => But that's an issue against bulk registrations in general. If we have > bulk registrations in the draft then this proposal is fine. If we remove > bulk registrations from the draft then there is no point in this discussion > because we have to send one BU for each BID anyway. If we allow each BID to > have the lifetime of the BU then problem solved. > But I thought you'd be concerned about removing bulk registrations because > if you think that: > A. There will be a lot of BIDs (which is what you mentioned earlier for the > bandwidth argument) > B. Bandwidth is an issue. > > Then sending one BU per BID would be an issue. > > >>> I think the first approach seems the cleanest one. What do you think? > >> > >> => I don't like having different lifetimes for the same HoA bindings. It > >> makes life unnecessarily complex. I can't find any scenario where the MN > >> will want to explicitly have different lifetimes for different flow bindings > >> or CoA bindings. > >> > > > > I don't care much if the lifetime is the same or not. I agree with you there > > is not a clear scenario where different lifetimes are needed. However I think > > we should find a clean solution which does not imply always the usage of bulk > > registration. To me the cleanest way is to associated a specific lifetime to > > each BID, but I am open to suggestions. > > => Well, if we have bulk registrations, then I think the cleanest way is to > send a few bytes to refresh them. If we don't have bulk registrations then > there is no problem to discuss I think. > > Hesham > > > > > Gerardo > > > > > >> Hesham > >> > >> > >>> > >>> Cheers > >>> Gerardo > >>> > >>>> -----Original Message----- > >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > >>>> Hesham > >>>> Soliman > >>>> Sent: Tuesday, December 16, 2008 5:44 AM > >>>> To: mext@ietf.org > >>>> Subject: [MEXT] De-resgistering bindings in MCoA draft > >>>> > >>>> Hi, > >>>> > >>>> I have a comment on this aspect of the spec. The removal of BIDs based on > >>>> zero lifetime is completely inconsistent with the processing of the BU in > >>>> MIPv6. The lifetime should be for the entire binding cache for the home > >>>> address. BIDs should be removed by explicitly by requesting a removal > >>>> operation in the BID fields (or by simply excluding them from the new BU), > >>>> not by giving them separate lifetimes. I don't see any reason for > >>>> complicating things this way. This is not how a binding update is supposed > >>>> to work. The way it works is that one BU replaces the previous one. > >>>> > >>>> Hesham > >>>> > >>>> > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext > >> > > > > _______________________________________________ > > MEXT mailing list > > You got attachement! (https://www.codealias.info/~zrelli/attachements/) > > > _______________________________________________ > MEXT mailing 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 Dec 16 22:27:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EEF63A691E; Tue, 16 Dec 2008 22:27:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC7A13A691E for ; Tue, 16 Dec 2008 22:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 jRqONprRERfp for ; Tue, 16 Dec 2008 22:27:13 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id A09813A689C for ; Tue, 16 Dec 2008 22:27:13 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3585911wfd.31 for ; Tue, 16 Dec 2008 22:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:cc :subject:in-reply-to:references:user-agent:organization:mime-version :content-type:content-transfer-encoding; bh=mdrz3oFNJZa39KmJZuAHriBvhSrszqbDLKtIOcKORQU=; b=JtsBQ3d7PqXlIWdi+dFOW/l1VJER1oUiCcONhOAki72uLxjMq+lM5XhgCaCeB/g16L dA9XBepA3RZ1tmVUEF2yz7e0aCOi14eg4b/RzyOHjrePtdsLoBSqhR0yJPFPwIKdCyAb Hp/MnxobrmOjBonweTCZgMIAv9jKVsgGlkCAc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:organization:mime-version:content-type :content-transfer-encoding; b=wR837XwoP38yU0sv/OrQxDQE/3UHccpmSa6lhkMc56ywYo1eIxvkOE2iR0lDZem//6 urYadLhepuInDxTLdbapAj+gWD+6yCkSmV9SAwSiTUImqZ5F4FmXGSBRRTyN0yl2qCI8 7V8NxEynr0TLhvwWuykmaTh0NF82nWNF5/9ik= Received: by 10.142.177.7 with SMTP id z7mr152638wfe.281.1229495225824; Tue, 16 Dec 2008 22:27:05 -0800 (PST) Received: from ryuji-wakikawa-no-macbook-pro.local.sfc.wide.ad.jp (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 32sm14918762wfa.40.2008.12.16.22.27.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 22:27:04 -0800 (PST) Date: Wed, 17 Dec 2008 15:27:01 +0900 Message-ID: From: Ryuji Wakikawa To: In-Reply-To: References: User-Agent: Wanderlust/2.14.1 (Bad Medicine-pre) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin9) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: mext@ietf.org Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Christian, thanks for comments. At Thu, 11 Dec 2008 15:08:16 +0100, wrote: > > Assume a mobile node with home address HoA has two interfaces, > both attached to foreign links. After exchange of binding update > and binding acknowledgement, the home agent's binding cache (at > least the snip of it related to HoA) will look like this > > HoA, BID= 7, CoA1, other parameters like period of validity... > HoA, BID=10, CoA2, other parameters ... > > The draft uses HoA=2001:db8::EUI. > > Draft 10, section 5.1 states, that a BID value must be unique for a > home address and care-of address pair. This is satisfied above, but > it means, that the mobile station is not allowed to change the > second entry such that it also uses CoA1 as care-of address. > > Proposal: I think it has merit to be able to allow more than > one BID value per pair of home address and care-of address. Consider > flow bindings (defined in draft-ietf-mext-flow-binding) where > a flow may refer to a BID, and thus there is a simple way to move > flows between interfaces: only updating the binding cache. Do you want these bindings? HoA, BID= 7, CoA1, other parameters like period of validity... HoA, BID=10, CoA1, other parameters ... >From the protocol operational view, we don't have any issue to relax the BID assignment for this purpose. > Draft 10, section 4.2 (and other places) defines the H flag, which when > set means the mobile node wants to use both its home link and one or > more of its foreign links. The H flag is really an instruction to the > home agent, that in addition to all the bidings currently defined > is shall have an extra binding where packets shall not be tunneled. > > Proposal: The mobile node should be able to define a binding saying > > HoA BID=0 HoA > > This is a kind of default binding to be used when any of the other HoA- > bindings cannot be used. I think the H flag is an indirect way of > saying there is an extra binding, whereas the binding above is direct. > It also avoids continuously setting the H flag when both home link > and foreign links are active. This was originally proposed by Keigo from Panasonic and has been discussed it. You can check the discussion on ML archives. > > Other comments > > o Figure 1: In general I think it simpler for human readers to have > the elements of the primary key to a database given first, > therefore I suggest > > binding [2001:db8::EUI BID1 care-of address1] > > to be used allover. OK, will fix this. > > o Figure 4: looks as if position 6 is followed by position 17. this is typo. i'll fix this. > o Section 4.2, O flag. The O flag is carried in an Binding > Identification mobility option, but really it a kind of global > value to be understood by the receiver as "clean all HoA entries". > If it really is too much to introduce a new mobility option, > isn't it enough to set the O flag in the first Binding > Identification mobility option? I'm updating the document after last call. the O flag is now defined in the BU itself, since this is global value for all bindings as you pointedout. > o Section 4.2, Care-of address and section 6.2 bullet 6, sub-bullet 2. > If the care-of address is omitted, the care-of address is to be > taken from the source address of the IPv6 header. > When the binding update arrives at the home agent, the > IPv6 header's source address is exactly the care-of > address used by the mobile node, but when the home agent is > actually able to understand the contents of the binding update, > then the IPv6 headers source address has been swapped with the > address found in the Destination Option extension header, > and thus the care-of address is now found in the Destination > Option extension header. In section 6.1.7 of RFc3775, it said "The care-of address is specified either by the Source Address field in the IPv6 header or by the Alternate Care-of Address option, if present. " So, I will fix this to the care-of address is to be taken from the source address of the IPv6 header "of the Binding Update". > o Section 5.6.2, bullet 2. The term link-local address is used, but I > think this should be changed to be like in all the other places, > using link-layer address. yes, thanks. > o Section 6.2, bullet 7, sub-bullet 1: I think the condition should > read > "If one of the 'O' flags is set, then all of the 'O' flags must be > set, else [MCOA MALFORMED] is returned." But as suggested above, > I don't think there is reason to enforce an all-or-none 'O' flags. right, see above. > o Section 8.2, para 2. The text says, that the IPv4 Address > Acknowledgement mobility option is included only if the mobile node > requested a home address. When I read > draft-ietf-mext-nemo-v4traversal, > section 4.2.1, the IPv4 Address Acknowledgement mobility option > is included always, indicating the home agent created a binding cache > entry for the IPv4 home address. correct. I will check dsmip and update it. thanks ryuji > 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 info@prescottshedandgarage.com Tue Dec 16 22:28:57 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 629A63A695E for ; Tue, 16 Dec 2008 22:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, 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 6y2+aEI7yeyd for ; Tue, 16 Dec 2008 22:28:57 -0800 (PST) Received: from web804.biz.mail.mud.yahoo.com (web804.biz.mail.mud.yahoo.com [209.191.90.77]) by core3.amsl.com (Postfix) with SMTP id 3602F3A691E for ; Tue, 16 Dec 2008 22:28:57 -0800 (PST) Received: (qmail 27076 invoked by uid 60001); 17 Dec 2008 06:22:07 -0000 X-YMail-OSG: K.XhxpYVM1moZqhOpgFwDp89GkdJsimO6N9YdqnyLHWKaDUjGfQdb2EQAJFhuCwV7xYMTwLSZy7p6yIGz6i7Bdam5PkLO1d.o0LBU7iQHG.vZRMlVXiCobot9VhjqVSfbSN6ue6yN5NwqqSaRjpF26z82wwICd9.0XE57YHT.fptpxWUYjY.0D4lKO4e.DCs8RkfGMSEHIFpiw8nPW8zPuFKEN0tXHETCZ3XWTPZDA-- Received: from [24.116.33.74] by web804.biz.mail.mud.yahoo.com via HTTP; Tue, 16 Dec 2008 22:22:07 PST X-Mailer: YahooMailWebService/0.7.247.3 Date: Tue, 16 Dec 2008 22:22:07 -0800 (PST) From: "Prescott Shed and Garage.com" Reply-To: info@PrescottShedandGarage.com Subject: Built on Site To: office@warber.com, sqzqmnbq@pars.com, from_user@zipmail.com, nemo-admin@ietf.org, nemo-archive@ietf.org, nemo-request@ietf.org, nemo-web-archive@ietf.org, nomcom@ietf.org, 200511101315.jaadfpaw017291@localhost.localdomain, 200511101318.jaadirdq017609@localhost.localdomain, 200511101323.jaadn1xc017928@localhost.localdomain, 200511101326.jaadqigo018245@localhost.localdomain, 200511101334.jaadylr5018564@localhost.localdomain, 200511101411.jaaeb1si018884@localhost.localdomain, 200511101416.jaaegx8e019201@localhost.localdomain, 200511101441.jaaef2le019668@localhost.localdomain, 200511101459.jaaex8xd020056@localhost.localdomain, parker@lse.fullfeed.com, 200511111226.jabcqn3d024473@localhost.localdomain, dona@bilver.uucp, 1992apr16.040150.19150@bilver.uucp, www.roofer@roofmag.com, help@franchisesolutions.com, offshore@netbox.com, reggie@pop.erols.com, webmaster@selfhelplaw.com, anotherworld@mail.liberty.com, courage@istar.ca, barry@infoprovider.com, kei@algonet.se, toons@gte.net, agdoc@email.msn.com, sportwerk@aol.com, refrep@mnsinc.com, jpaul@pd.stlnet.com, tradex@squirrel.com.au, nort@rnet.com, berri@leonardo.net, robertb@tcidb.net, rcheery@concentric.net, doming1@ix.netcom.com, glang@goodnewsbooks.com, catholic@qni.com, tbrooks@west-teq.net, creature@escape.com, miket@printco.com, bjndgkmcenletabppkdx@excite.com, 20050302072103.820d920243@mrtg.unt.edu.ar, 2a-z4a-z5a-z1a-z7a-z8a-z3a-z7a-z9a-zo3a-z5a-z3a-z7a-z8a-z7a-z3a-z9a-z7a-z1a-z3a-z9a-z@terra.es, 20050302203343.4e4d620243@mrtg.unt.edu.ar, slxaaecddgehdjmxgvhzxa@fibertel.com.ar, 20050303204035.edef520243@mrtg.unt.edu.ar, campe@thor.uucp, daemon@fps.com, ottkcmvqivnc@informatik.th-darmstadt.de, izdnldsgjbsiupyowqvjd@deltanet.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-897346875-1229494927=:25936" Message-ID: <602679.25936.qm@web804.biz.mail.mud.yahoo.com> --0-897346875-1229494927=:25936 Content-Type: text/plain; charset=us-ascii http://www.prescottshedandgarage.com/saturday --0-897346875-1229494927=:25936 Content-Type: text/html; charset=us-ascii
http://www.prescottshedandgarage.com/saturday
--0-897346875-1229494927=:25936-- From mext-bounces@ietf.org Tue Dec 16 22:31: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 BB78C3A695E; Tue, 16 Dec 2008 22:31:57 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68E4D3A691E for ; Tue, 16 Dec 2008 22:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H62nYlxllUlh for ; Tue, 16 Dec 2008 22:31:55 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 503E03A695E for ; Tue, 16 Dec 2008 22:31:55 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so3377923rvf.49 for ; Tue, 16 Dec 2008 22:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:cc :subject:in-reply-to:references:user-agent:organization:mime-version :content-type; bh=Fp6wxP9298Tjo0q+moJif3p+NcfU0ZN62mHZQ0ZTFBM=; b=Rsa/q4tj1OEcI22s3XuXB+WqbMialMKSFJ3wP+ICBt3IOGwagyV+eFP3tQwCw9rQKG /0xKlSXwWE4G9DzsoLYRlp16FcIKfCfkA+bDKtbHGu5iDs1DJv3lL32KpXAA4DGDAg08 n2b/VKtQDdrGl1/1av8oNfhF1dbgtY+LWj188= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:organization:mime-version:content-type; b=j8VStzIYrGR/a0GxT5klBhxt0EIyQqKSfLQfMWw9YJF00se0wBtG6TncuVx18fsP25 Cx2hdX3MA2BuS87BRHF21iJeu166k8kZOdKTZxyXY/6HVxtqQwvSkBVy60RXZl0wHIqP A/YRXFyrWRWYjewCWKJ+I9wtJBjvDTmon5IxM= Received: by 10.142.144.16 with SMTP id r16mr152652wfd.316.1229495507071; Tue, 16 Dec 2008 22:31:47 -0800 (PST) Received: from ryuji-wakikawa-no-macbook-pro.local.sfc.wide.ad.jp (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 20sm10426013wfi.7.2008.12.16.22.31.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 22:31:46 -0800 (PST) Date: Wed, 17 Dec 2008 15:31:43 +0900 Message-ID: From: Ryuji Wakikawa To: "Giaretta, Gerardo" In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D6E2973D@NASANEXMB08.na.qualcomm.com> References: <057632CE4CE10D45A1A3D6D19206C3A3D6E2973D@NASANEXMB08.na.qualcomm.com> User-Agent: Wanderlust/2.14.1 (Bad Medicine-pre) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin9) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: "mext@ietf.org" , "Christian.Kaas-Petersen@tieto.com" Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Gerardo, At Thu, 11 Dec 2008 09:05:21 -0800, Giaretta, Gerardo wrote: > > Hi Christian, > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > > Christian.Kaas-Petersen@tieto.com > > Sent: Thursday, December 11, 2008 6:08 AM > > To: mext@ietf.org > > Subject: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some > > comments > > > > Assume a mobile node with home address HoA has two interfaces, > > both attached to foreign links. After exchange of binding update > > and binding acknowledgement, the home agent's binding cache (at > > least the snip of it related to HoA) will look like this > > > > HoA, BID= 7, CoA1, other parameters like period of validity... > > HoA, BID=10, CoA2, other parameters ... > > > > The draft uses HoA=2001:db8::EUI. > > > > Draft 10, section 5.1 states, that a BID value must be unique for a > > home address and care-of address pair. This is satisfied above, but > > it means, that the mobile station is not allowed to change the > > second entry such that it also uses CoA1 as care-of address. > > > > Proposal: I think it has merit to be able to allow more than > > one BID value per pair of home address and care-of address. Consider > > flow bindings (defined in draft-ietf-mext-flow-binding) where > > a flow may refer to a BID, and thus there is a simple way to move > > flows between interfaces: only updating the binding cache. > > > > I guess you mean only updating the CoA of the BCE/BID. I think this is a very valid point and it should be allowed. I did not realize this was not possible while reading the draft. I agree this is a necessary feature when coupling MCoA with flow bindings. it is allowed, though this is not clear from the current spec. Christian's point is whether we allow multiple bindings (BID) which HoA and CoA are same. regards, ryuji > Thanks > Gerardo > > > Draft 10, section 4.2 (and other places) defines the H flag, which when > > set means the mobile node wants to use both its home link and one or > > more of its foreign links. The H flag is really an instruction to the > > home agent, that in addition to all the bidings currently defined > > is shall have an extra binding where packets shall not be tunneled. > > > > Proposal: The mobile node should be able to define a binding saying > > > > HoA BID=0 HoA > > > > This is a kind of default binding to be used when any of the other HoA- > > bindings cannot be used. I think the H flag is an indirect way of > > saying there is an extra binding, whereas the binding above is direct. > > It also avoids continuously setting the H flag when both home link > > and foreign links are active. > > > > > > Other comments > > > > o Figure 1: In general I think it simpler for human readers to have > > the elements of the primary key to a database given first, > > therefore I suggest > > > > binding [2001:db8::EUI BID1 care-of address1] > > > > to be used allover. > > > > o Figure 4: looks as if position 6 is followed by position 17. > > > > o Section 4.2, O flag. The O flag is carried in an Binding > > Identification mobility option, but really it a kind of global > > value to be understood by the receiver as "clean all HoA entries". > > If it really is too much to introduce a new mobility option, > > isn't it enough to set the O flag in the first Binding > > Identification mobility option? > > > > o Section 4.2, Care-of address and section 6.2 bullet 6, sub-bullet 2. > > If the care-of address is omitted, the care-of address is to be > > taken from the source address of the IPv6 header. > > When the binding update arrives at the home agent, the > > IPv6 header's source address is exactly the care-of > > address used by the mobile node, but when the home agent is > > actually able to understand the contents of the binding update, > > then the IPv6 headers source address has been swapped with the > > address found in the Destination Option extension header, > > and thus the care-of address is now found in the Destination > > Option extension header. > > > > o Section 5.6.2, bullet 2. The term link-local address is used, but I > > think this should be changed to be like in all the other places, > > using link-layer address. > > > > o Section 6.2, bullet 7, sub-bullet 1: I think the condition should > > read > > "If one of the 'O' flags is set, then all of the 'O' flags must be > > set, else [MCOA MALFORMED] is returned." But as suggested above, > > I don't think there is reason to enforce an all-or-none 'O' flags. > > > > o Section 8.2, para 2. The text says, that the IPv4 Address > > Acknowledgement mobility option is included only if the mobile node > > requested a home address. When I read > > draft-ietf-mext-nemo-v4traversal, > > section 4.2.1, the IPv4 Address Acknowledgement mobility option > > is included always, indicating the home agent created a binding cache > > entry for the IPv4 home address. > > > > 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 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 16 22:43: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 6E88D3A6AB2; Tue, 16 Dec 2008 22:43:48 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5E913A6AB2 for ; Tue, 16 Dec 2008 22:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.638 X-Spam-Level: X-Spam-Status: No, score=-105.638 tagged_above=-999 required=5 tests=[AWL=0.961, 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 Q1qUKUV5Gydy for ; Tue, 16 Dec 2008 22:43:45 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 638F83A67DA for ; Tue, 16 Dec 2008 22:43:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1229496218; x=1261032218; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Ryuji=20Wakikawa=20,=0D =0A=20=20=20=20=20=20=20=20"Christian.Kaas-Petersen@tieto .com"=20|CC:=20"mext@i etf.org"=20|Date:=20Tue,=2016=20Dec=202008 =2022:42:23=20-0800|Subject:=20RE:=20[MEXT]=20Subject:=20 Multiple=20CoA=20draft=2010=20--=20two=20proposals=20and =09some=0D=0A=09comments|Thread-Topic:=20[MEXT]=20Subject :=20Multiple=20CoA=20draft=2010=20--=20two=20proposals=20 and=0D=0A=09some=09comments|Thread-Index:=20AclgEIBkZB35K RU0T9SfOi275Q/1vwAAh3zk|Message-ID:=20<057632CE4CE10D45A1 A3D6D19206C3A3D85D72B3@NASANEXMB08.na.qualcomm.com> |References:=20,|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5466"=3B=20a=3D"14021269"; bh=9sZOBhoxPeO4MINwNRgv9qHo0JCLw4jkoEiWo8e0ZkY=; b=RJvKajMskq6PzkTVGAOVinvDdX3bcb9GZIU4R/9oSPwhCR0iKVNQJpT7 4hsyje+W8BAgb6eIiyR28TmzcsfV/AIyQcKXdutM/bYEUzk6MB4jaST6W mub49ml9rGGTBXHfWbyGzCNv4bdRYN0+rF84n4qYfyngaLmnq/QX3Wauv 0=; X-IronPort-AV: E=McAfee;i="5300,2777,5466"; a="14021269" 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; 16 Dec 2008 22:43:38 -0800 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBH6hbIn005388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Dec 2008 22:43:38 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBH6hb0D009761 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 16 Dec 2008 22:43:37 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub01.na.qualcomm.com ([10.46.93.121]) with mapi; Tue, 16 Dec 2008 22:43:35 -0800 From: "Giaretta, Gerardo" To: Ryuji Wakikawa , "Christian.Kaas-Petersen@tieto.com" Date: Tue, 16 Dec 2008 22:42:23 -0800 Thread-Topic: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments Thread-Index: AclgEIBkZB35KRU0T9SfOi275Q/1vwAAh3zk Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D85D72B3@NASANEXMB08.na.qualcomm.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ryuji, one point related to Christian's comments is that we need a BID also for the interface which is on the home link. This is needed in order to associate FIDs to that interface. The rules to create/update/delete that BID should be the same as for any other binding Gerardo ________________________________________ From: mext-bounces@ietf.org [mext-bounces@ietf.org] On Behalf Of Ryuji Wakikawa [ryuji.wakikawa@gmail.com] Sent: Tuesday, December 16, 2008 10:27 PM To: Christian.Kaas-Petersen@tieto.com Cc: mext@ietf.org Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments Hi Christian, thanks for comments. At Thu, 11 Dec 2008 15:08:16 +0100, wrote: > > Assume a mobile node with home address HoA has two interfaces, > both attached to foreign links. After exchange of binding update > and binding acknowledgement, the home agent's binding cache (at > least the snip of it related to HoA) will look like this > > HoA, BID= 7, CoA1, other parameters like period of validity... > HoA, BID=10, CoA2, other parameters ... > > The draft uses HoA=2001:db8::EUI. > > Draft 10, section 5.1 states, that a BID value must be unique for a > home address and care-of address pair. This is satisfied above, but > it means, that the mobile station is not allowed to change the > second entry such that it also uses CoA1 as care-of address. > > Proposal: I think it has merit to be able to allow more than > one BID value per pair of home address and care-of address. Consider > flow bindings (defined in draft-ietf-mext-flow-binding) where > a flow may refer to a BID, and thus there is a simple way to move > flows between interfaces: only updating the binding cache. Do you want these bindings? HoA, BID= 7, CoA1, other parameters like period of validity... HoA, BID=10, CoA1, other parameters ... >From the protocol operational view, we don't have any issue to relax the BID assignment for this purpose. > Draft 10, section 4.2 (and other places) defines the H flag, which when > set means the mobile node wants to use both its home link and one or > more of its foreign links. The H flag is really an instruction to the > home agent, that in addition to all the bidings currently defined > is shall have an extra binding where packets shall not be tunneled. > > Proposal: The mobile node should be able to define a binding saying > > HoA BID=0 HoA > > This is a kind of default binding to be used when any of the other HoA- > bindings cannot be used. I think the H flag is an indirect way of > saying there is an extra binding, whereas the binding above is direct. > It also avoids continuously setting the H flag when both home link > and foreign links are active. This was originally proposed by Keigo from Panasonic and has been discussed it. You can check the discussion on ML archives. > > Other comments > > o Figure 1: In general I think it simpler for human readers to have > the elements of the primary key to a database given first, > therefore I suggest > > binding [2001:db8::EUI BID1 care-of address1] > > to be used allover. OK, will fix this. > > o Figure 4: looks as if position 6 is followed by position 17. this is typo. i'll fix this. > o Section 4.2, O flag. The O flag is carried in an Binding > Identification mobility option, but really it a kind of global > value to be understood by the receiver as "clean all HoA entries". > If it really is too much to introduce a new mobility option, > isn't it enough to set the O flag in the first Binding > Identification mobility option? I'm updating the document after last call. the O flag is now defined in the BU itself, since this is global value for all bindings as you pointedout. > o Section 4.2, Care-of address and section 6.2 bullet 6, sub-bullet 2. > If the care-of address is omitted, the care-of address is to be > taken from the source address of the IPv6 header. > When the binding update arrives at the home agent, the > IPv6 header's source address is exactly the care-of > address used by the mobile node, but when the home agent is > actually able to understand the contents of the binding update, > then the IPv6 headers source address has been swapped with the > address found in the Destination Option extension header, > and thus the care-of address is now found in the Destination > Option extension header. In section 6.1.7 of RFc3775, it said "The care-of address is specified either by the Source Address field in the IPv6 header or by the Alternate Care-of Address option, if present. " So, I will fix this to the care-of address is to be taken from the source address of the IPv6 header "of the Binding Update". > o Section 5.6.2, bullet 2. The term link-local address is used, but I > think this should be changed to be like in all the other places, > using link-layer address. yes, thanks. > o Section 6.2, bullet 7, sub-bullet 1: I think the condition should > read > "If one of the 'O' flags is set, then all of the 'O' flags must be > set, else [MCOA MALFORMED] is returned." But as suggested above, > I don't think there is reason to enforce an all-or-none 'O' flags. right, see above. > o Section 8.2, para 2. The text says, that the IPv4 Address > Acknowledgement mobility option is included only if the mobile node > requested a home address. When I read > draft-ietf-mext-nemo-v4traversal, > section 4.2.1, the IPv4 Address Acknowledgement mobility option > is included always, indicating the home agent created a binding cache > entry for the IPv4 home address. correct. I will check dsmip and update it. thanks ryuji > 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 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From macek@afullcup.com Tue Dec 16 23:11:03 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 578593A6AF1 for ; Tue, 16 Dec 2008 23:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.102 X-Spam-Level: X-Spam-Status: No, score=-4.102 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViwDAyh0FAAO for ; Tue, 16 Dec 2008 23:10:57 -0800 (PST) Received: from 12-215-45-8.client.mchsi.com (12-215-45-8.client.mchsi.com [12.215.45.8]) by core3.amsl.com (Postfix) with SMTP id ED3D33A6904 for ; Tue, 16 Dec 2008 23:10:56 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081217071056.ED3D33A6904@core3.amsl.com> Date: Tue, 16 Dec 2008 23:10:56 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mext-bounces@ietf.org Tue Dec 16 23:12: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 861BE3A6AB6; Tue, 16 Dec 2008 23:12:48 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F4AC3A6904 for ; Tue, 16 Dec 2008 23:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJDfqKHAGdPI for ; Tue, 16 Dec 2008 23:12:46 -0800 (PST) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 820CF3A6AB6 for ; Tue, 16 Dec 2008 23:12:46 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LCqaD-0001B9-2f; Wed, 17 Dec 2008 18:12:37 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 17 Dec 2008 18:12:32 +1100 From: Hesham Soliman To: Ryuji Wakikawa Message-ID: Thread-Topic: [MEXT] De-resgistering bindings in MCoA draft Thread-Index: AclgFtQNdz5IUFyjjUi+qBJ9ZOJgpg== In-Reply-To: Mime-version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] De-resgistering bindings in MCoA draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > When MN does not use the bulk registration, each binding registering > with BID is treated as a regular binding. Each binding will have > individual lifetime. It is not the operation of BID removal, but of a binding > removal. => It's the same thing, you won't remove a BID and keep the binding. > Removing a binding with zero lifetime is consisitent with MIP6. => Yes but that's not the issue, the issue here is having multiple bindings for the same home address that have different lifetimes. Hesham > > ryuji > > > > > > At Wed, 17 Dec 2008 00:43:33 +1100, > Hesham Soliman wrote: >> >> Hi, >> >> I have a comment on this aspect of the spec. The removal of BIDs based on >> zero lifetime is completely inconsistent with the processing of the BU in >> MIPv6. The lifetime should be for the entire binding cache for the home >> address. BIDs should be removed by explicitly by requesting a removal >> operation in the BID fields (or by simply excluding them from the new BU), >> not by giving them separate lifetimes. I don't see any reason for >> complicating things this way. This is not how a binding update is supposed >> to work. The way it works is that one BU replaces the previous one. >> >> Hesham >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 16 23:17: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 368513A68BA; Tue, 16 Dec 2008 23:17:48 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48B933A68BA for ; Tue, 16 Dec 2008 23:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZloVSy4p30Xw for ; Tue, 16 Dec 2008 23:17:46 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 51F863A68A6 for ; Tue, 16 Dec 2008 23:17:46 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so3389563rvf.49 for ; Tue, 16 Dec 2008 23:17:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:cc :subject:in-reply-to:references:user-agent:organization:mime-version :content-type:content-transfer-encoding; bh=9PL2jU5tOw+/F5u2PxkhbOa9qUhoFga5UzK7QhCZz2w=; b=fGkMQ1kgBqCbpY7zGwKvp9NVqm/u/2uNwqkUyQUWjO7y7N4F7nmsROfOlP9IwxP172 Jcww+82tJ3hubKeXaCvRXFHpNaXBt7x2ueWPWDffANAGb/Ge7CmsEZLwhqDC5Gh6GOHa Wg9ZvfB0u9f2sqScfh1/nMkyJ3a2SfhF0psPQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:organization:mime-version:content-type :content-transfer-encoding; b=P2AS+X4BSmxiXaD3+XDrHaU1SuAA7VThatTBBHNZE9vCbqmsEjRwo/ujPZJanwooQt 1ZH+M7zAP2eGNhVFQKD3LQt5mtQX6lRdUoS5UUHvHjkNzrvTsoOz//dX3NCwSI1EyTwq MhrOTJ2Oah3kSarF6a/fXckZSIU4mBeArjtr8= Received: by 10.142.174.8 with SMTP id w8mr179704wfe.76.1229498257674; Tue, 16 Dec 2008 23:17:37 -0800 (PST) Received: from ryuji-wakikawa-no-macbook-pro.local.sfc.wide.ad.jp (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 22sm12818146wfd.33.2008.12.16.23.17.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 23:17:36 -0800 (PST) Date: Wed, 17 Dec 2008 16:17:32 +0900 Message-ID: From: Ryuji Wakikawa To: Hesham Soliman In-Reply-To: References: <057632CE4CE10D45A1A3D6D19206C3A3D6E298C1@NASANEXMB08.na.qualcomm.com> User-Agent: Wanderlust/2.14.1 (Bad Medicine-pre) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin9) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: "mext@ietf.org" , "Christian.Kaas-Petersen@tieto.com" Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham At Sat, 13 Dec 2008 13:06:03 +1100, Hesham Soliman wrote: > > >> > >> => But why would the MN want to do that? The scenario you're suggesting > >> means that there is effectively one binding, so why do we need to allocated > >> two BIDs to the same CoA? If there is a reason then I think your proposal is > >> fine, although it will be tricky to implement. But I'd like to see a > >> plausible scenario first. > >> > > > > Suppose the MN is connected to access 1 and access2 and has two flow bindings > > with two different CoA > > > > HoA, BID=1, CoA1, FID1, FID4, FID6 > > HoA, BID=2, CoA2 FID2, FID3, FID5 > > > > When the MN loses access 2 coverage it can do two things to keep the flows > > active: > > - send a BU with HoA, BID=1, FID2, FID3, FID5 to add those flows to the first > > binding > > - send a BU with HoA, BID=2, CoA1 to update the CoA of the second binding > > > > The second has advantages in terms of signaling overhead. This is true in > > particular if then the MN moves back to access2 and wants to re-establish the > > flow bindings as previously. In that case just a new CoA update is needed > > instead of re-registering the flows again. > > => That's right, I guessed this is why you and Christian were asking for it. > But I think it's strange to have a binding id if it's not unique because > it's basically replicating the binding in case we need to change the CoA. It > makes things more complex and error prone in the implementation for a small > difference of bytes that will be sent. After all, you're not eliminating the > need to send another BU, you're just sending a smaller BU. So if you're > lucky, you'll save tens of bytes. It's not worth it IMHO. >From protocol point of view, except for error handling, there are no big issues and extentions to the current spec.. However, this feature is basically proposed for the flow binding optimization. Shall we relax this restriction (change MUST to SHOULD) to keep the flow binding optimization? regards, ryuji > Hesham > > > > > If the second approach is used you will have up giving two different BIDs for > > which the CoA is the same. But this should not be an issue as the bindings are > > treated independently, they just happen to point to the same CoA > > > > Gerardo > > > >>> Draft 10, section 4.2 (and other places) defines the H flag, which when > >>> set means the mobile node wants to use both its home link and one or > >>> more of its foreign links. The H flag is really an instruction to the > >>> home agent, that in addition to all the bidings currently defined > >>> is shall have an extra binding where packets shall not be tunneled. > >>> > >>> Proposal: The mobile node should be able to define a binding saying > >>> > >>> HoA BID=0 HoA > >>> > >>> This is a kind of default binding to be used when any of the other HoA- > >>> bindings cannot be used. I think the H flag is an indirect way of > >>> saying there is an extra binding, whereas the binding above is direct. > >>> It also avoids continuously setting the H flag when both home link > >>> and foreign links are active. > >> > >> => This is basically asking for a permanent binding. Again, I'd like to > >> understand why this is needed, compared to what the draft says now. > >> > >> Hesham > >> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 16 23:22: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 2112A28C135; Tue, 16 Dec 2008 23:22:00 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A81B28C135 for ; Tue, 16 Dec 2008 23:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO+n5i8C-QUk for ; Tue, 16 Dec 2008 23:21:57 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id BFC6028C133 for ; Tue, 16 Dec 2008 23:21:57 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3603217wfd.31 for ; Tue, 16 Dec 2008 23:21:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=6rvg/mIv1n6IuWsuhFSeaiI6CjIyvy4k4L1fjWm4+iE=; b=krNCbJkpZ+Nmb7ooGvfKFbuguL3+t/fFeVLcJYBoG6syr2FC9BfWYtHhZjJL3dO5kC 3CxTUEdk2AuScfT4WklmIqdTKTHtwpoBgtyAyGngAENGYeu0Enh+ODlmquHAV0WfozGv VUPtJqcR0XGgJjp8eYjDvczYP7WoBwjnWIYS8= 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=f6d2m57q6BkgSh//FyqNTZ/rZCQdYeVWY+lx+4EMGclAptNhJHLEMRDEImNn0FHAhi VQOMfJvd1k1RKO+iWEnOtevjQz9gNL79qkJ/greizGLv22XGMM9jSwcSNvgiWSB5tS+1 UkKQgGtbxKZST/utVQYOaFZ1p234BTfE1xfrM= Received: by 10.142.140.14 with SMTP id n14mr181717wfd.63.1229498510023; Tue, 16 Dec 2008 23:21:50 -0800 (PST) Received: from ?172.17.105.34? (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 32sm3457342wfc.19.2008.12.16.23.21.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 23:21:49 -0800 (PST) From: Ryuji Wakikawa To: Hesham Soliman In-Reply-To: References: Message-Id: <7CFB267E-E7BA-4FC5-BC4D-09796E0242AF@gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 17 Dec 2008 16:21:45 +0900 X-Mailer: Apple Mail (2.930.3) Cc: "mext@ietf.org" Subject: Re: [MEXT] De-resgistering bindings in MCoA draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham We slightly changed the semantics of MIP6, because both HoA and BID is now used as a key to search/manage binding cache/binding update list. I don't see any issues assigning individual lifetime to BID bindings for the same HoA, if there is reason (i.e. no bulk registration). regards, ryuji On 2008/12/17, at 16:12, Hesham Soliman wrote: > >> When MN does not use the bulk registration, each binding registering >> with BID is treated as a regular binding. Each binding will have >> individual lifetime. It is not the operation of BID removal, but of >> a binding >> removal. > > => It's the same thing, you won't remove a BID and keep the binding. > >> Removing a binding with zero lifetime is consisitent with MIP6. > > => Yes but that's not the issue, the issue here is having multiple > bindings > for the same home address that have different lifetimes. > > Hesham > >> >> ryuji >> >> >> >> >> >> At Wed, 17 Dec 2008 00:43:33 +1100, >> Hesham Soliman wrote: >>> >>> Hi, >>> >>> I have a comment on this aspect of the spec. The removal of BIDs >>> based on >>> zero lifetime is completely inconsistent with the processing of >>> the BU in >>> MIPv6. The lifetime should be for the entire binding cache for the >>> home >>> address. BIDs should be removed by explicitly by requesting a >>> removal >>> operation in the BID fields (or by simply excluding them from the >>> new BU), >>> not by giving them separate lifetimes. I don't see any reason for >>> complicating things this way. This is not how a binding update is >>> supposed >>> to work. The way it works is that one BU replaces the previous one. >>> >>> Hesham >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 16 23:32: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 B72F13A69D9; Tue, 16 Dec 2008 23:32:22 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9283A69D9 for ; Tue, 16 Dec 2008 23:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 diqZBKUY-WJ3 for ; Tue, 16 Dec 2008 23:32:20 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 6856C3A68BA for ; Tue, 16 Dec 2008 23:32:20 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so3393033rvf.49 for ; Tue, 16 Dec 2008 23:32:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=kUP0N0gGZ01qm/WLqsI6Rm/q3arjdp0+B0nQIe+Vqvw=; b=HvJa4hclLr/FLiCClaVu3UMYK7h4CG2EvpdfQWTxCcxSVp868TDKxO3/i4euIvkuED qVzdXal6lL77P++zDa1VIbouTIN12TPwjkwenQZy/0KrMcQgLVYe+JVBAlOncr9jnkxl yPU2RMwl9sFMTiZ+PmqpqPv8lLLkMsJY2JI80= 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=jnTOChfQ3SQ4nd2iLPVXbQpNlOBVIg2/lp8Ww0KbCsCkcyCG2HDlapxK6YCyH1KZoS O0t1I0Ay17qf9x5qKSC3sjmaNnqNFwfy8dGL+amtT3kCS+4CHLYYCuOJhbMF/xgqV0RU m/JiTH4d6gNu72cqPWJoUNAMtu9qhX0HXqqFM= Received: by 10.142.70.16 with SMTP id s16mr181363wfa.151.1229499132943; Tue, 16 Dec 2008 23:32:12 -0800 (PST) Received: from ?172.17.105.34? (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 28sm14107150wfg.48.2008.12.16.23.32.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 23:32:12 -0800 (PST) From: Ryuji Wakikawa To: "Giaretta, Gerardo" In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D85D72B3@NASANEXMB08.na.qualcomm.com> References: , <057632CE4CE10D45A1A3D6D19206C3A3D85D72B3@NASANEXMB08.na.qualcomm.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 17 Dec 2008 16:32:08 +0900 X-Mailer: Apple Mail (2.930.3) Cc: "mext@ietf.org" , "Christian.Kaas-Petersen@tieto.com" Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Gerardo, Yes, I was reading the mail threads. sorry to catch up this thread late. I was in Europe;-) I understand the reasons of BID for the home attached interface. MN keeps sending the BU (w/ non zero lifetime) from the home link? It sounds like we'll remove de-registration operation from RFC-3775? As a result, HA will have a home binding for the interface attached to home link, but will not operate proxy ND and encapsulation for that binding. I don't know this is reasonable modification to RFC-3775. My understanding was that, when MN is at home, most of traffic should be sent directly from the home link. I didn't see any strong reasons to use the interface attached to foreign links. Why not setting special flows which need to be sent from the foreign link by flow binding and rest of traffic are just sent from the home link. We don't need BID for the home attached interface. This is what I expected. Do you think there is a case where MN attaches to home link by multiple interfaces? regards, ryuji On 2008/12/17, at 15:42, Giaretta, Gerardo wrote: > Hi Ryuji, > > one point related to Christian's comments is that we need a BID also > for the interface which is on the home link. This is needed in order > to associate FIDs to that interface. The rules to create/update/ > delete that BID should be the same as for any other binding > > Gerardo > > ________________________________________ > From: mext-bounces@ietf.org [mext-bounces@ietf.org] On Behalf Of > Ryuji Wakikawa [ryuji.wakikawa@gmail.com] > Sent: Tuesday, December 16, 2008 10:27 PM > To: Christian.Kaas-Petersen@tieto.com > Cc: mext@ietf.org > Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals > and some comments > > Hi Christian, > > thanks for comments. > > At Thu, 11 Dec 2008 15:08:16 +0100, > wrote: >> >> Assume a mobile node with home address HoA has two interfaces, >> both attached to foreign links. After exchange of binding update >> and binding acknowledgement, the home agent's binding cache (at >> least the snip of it related to HoA) will look like this >> >> HoA, BID= 7, CoA1, other parameters like period of validity... >> HoA, BID=10, CoA2, other parameters ... >> >> The draft uses HoA=2001:db8::EUI. >> >> Draft 10, section 5.1 states, that a BID value must be unique for a >> home address and care-of address pair. This is satisfied above, but >> it means, that the mobile station is not allowed to change the >> second entry such that it also uses CoA1 as care-of address. >> >> Proposal: I think it has merit to be able to allow more than >> one BID value per pair of home address and care-of address. Consider >> flow bindings (defined in draft-ietf-mext-flow-binding) where >> a flow may refer to a BID, and thus there is a simple way to move >> flows between interfaces: only updating the binding cache. > > > Do you want these bindings? > HoA, BID= 7, CoA1, other parameters like period of validity... > HoA, BID=10, CoA1, other parameters ... > > From the protocol operational view, we don't have any issue to relax > the BID assignment for this purpose. > >> Draft 10, section 4.2 (and other places) defines the H flag, which >> when >> set means the mobile node wants to use both its home link and one or >> more of its foreign links. The H flag is really an instruction to >> the >> home agent, that in addition to all the bidings currently defined >> is shall have an extra binding where packets shall not be tunneled. >> >> Proposal: The mobile node should be able to define a binding saying >> >> HoA BID=0 HoA >> >> This is a kind of default binding to be used when any of the other >> HoA- >> bindings cannot be used. I think the H flag is an indirect way of >> saying there is an extra binding, whereas the binding above is >> direct. >> It also avoids continuously setting the H flag when both home link >> and foreign links are active. > > This was originally proposed by Keigo from Panasonic and has been > discussed it. > You can check the discussion on ML archives. > >> >> Other comments >> >> o Figure 1: In general I think it simpler for human readers to have >> the elements of the primary key to a database given first, >> therefore I suggest >> >> binding [2001:db8::EUI BID1 care-of address1] >> >> to be used allover. > > OK, will fix this. > >> >> o Figure 4: looks as if position 6 is followed by position 17. > > this is typo. i'll fix this. > >> o Section 4.2, O flag. The O flag is carried in an Binding >> Identification mobility option, but really it a kind of global >> value to be understood by the receiver as "clean all HoA entries". >> If it really is too much to introduce a new mobility option, >> isn't it enough to set the O flag in the first Binding >> Identification mobility option? > > I'm updating the document after last call. the O flag is now defined > in the BU itself, since this is global value for all bindings as you > pointedout. > >> o Section 4.2, Care-of address and section 6.2 bullet 6, sub-bullet >> 2. >> If the care-of address is omitted, the care-of address is to be >> taken from the source address of the IPv6 header. >> When the binding update arrives at the home agent, the >> IPv6 header's source address is exactly the care-of >> address used by the mobile node, but when the home agent is >> actually able to understand the contents of the binding update, >> then the IPv6 headers source address has been swapped with the >> address found in the Destination Option extension header, >> and thus the care-of address is now found in the Destination >> Option extension header. > > In section 6.1.7 of RFc3775, it said > "The care-of address is specified either by the Source Address field > in the IPv6 header or by the Alternate Care-of Address option, if > present. " > > So, I will fix this to > > the care-of address is to be taken from the source address of the > IPv6 header "of the Binding Update". > > >> o Section 5.6.2, bullet 2. The term link-local address is used, >> but I >> think this should be changed to be like in all the other places, >> using link-layer address. > > yes, thanks. > >> o Section 6.2, bullet 7, sub-bullet 1: I think the condition should >> read >> "If one of the 'O' flags is set, then all of the 'O' flags must be >> set, else [MCOA MALFORMED] is returned." But as suggested above, >> I don't think there is reason to enforce an all-or-none 'O' flags. > > right, see above. > >> o Section 8.2, para 2. The text says, that the IPv4 Address >> Acknowledgement mobility option is included only if the mobile node >> requested a home address. When I read >> draft-ietf-mext-nemo-v4traversal, >> section 4.2.1, the IPv4 Address Acknowledgement mobility option >> is included always, indicating the home agent created a binding >> cache >> entry for the IPv4 home address. > > correct. I will check dsmip and update it. > > thanks > ryuji > > >> 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 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 16 23:53: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 D20713A68AC; Tue, 16 Dec 2008 23:53:59 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906AF3A68AC for ; Tue, 16 Dec 2008 23:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEH6jfvJdnzq for ; Tue, 16 Dec 2008 23:53:57 -0800 (PST) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.238]) by core3.amsl.com (Postfix) with ESMTP id 823ED3A6825 for ; Tue, 16 Dec 2008 23:53:57 -0800 (PST) Received: by qb-out-0506.google.com with SMTP id d11so1883370qbd.41 for ; Tue, 16 Dec 2008 23:53:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=8+UTWrMX0YeafGsU0DiCNIiPWlWJNImJ1gTGoC8tc0Q=; b=NpnjuPJ0oHe4Chv/o6ijucD2OGzkZkeGptHAC/fQ5e50Nbx0lBIyQM7QtE+Vd10Rek 0RW0/aeC206NTbH3W5/PLGxpGgNgNKvfbFozme/zTymGY7v6o1JNG5Iw/0iJ6Z3jOXoV tDkCGTAF6BEzBDrTSBmiTI1EoWGFrkxcwN1MY= 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=TIjSOsrVPb1gipWH6Or8Z7Uyl0SybBfndZY1Ev40UNPA02YLT0UpOFRYTURBfJPWlz 6RqoDyJFNInEAHTtyDSe9ZjnkJhGcsdpOI0McZ0KRjvwtQFBOX4sT11GLHIOHV4hVOEi 5RDB2r7jbXHc/YO3pkmHaQACi/riy3+dVm/p0= Received: by 10.142.14.18 with SMTP id 18mr189535wfn.72.1229500428921; Tue, 16 Dec 2008 23:53:48 -0800 (PST) Received: from ?172.17.105.34? (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 9sm10600089wfc.16.2008.12.16.23.53.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Dec 2008 23:53:48 -0800 (PST) From: Ryuji Wakikawa To: Alexandru Petrescu In-Reply-To: <494646EB.4050203@gmail.com> References: <491039B9.6090400@it.uc3m.es> <200812111050.19715.julien.laganier.IETF@googlemail.com> <200812121152.04045.julien.laganier.IETF@googlemail.com> <494646EB.4050203@gmail.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 17 Dec 2008 16:53:44 +0900 X-Mailer: Apple Mail (2.930.3) Cc: Julien Laganier , mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien and Alex, On 2008/12/15, at 21:00, Alexandru Petrescu wrote: > Julien Laganier wrote: >> Hello Ryuji, >> On Thursday 11 December 2008, Ryuji Wakikawa wrote: >>> Actually, it's not only 3 round trip and is not optimization >>> problem.. This is a big issue of DHCP-PD. >>> Let me explain the issue clearly. >>> According to the NEMO-DHCP-PD spec, before receiving a prefix, a >>> mobile router must create a tunnel with its HA. >> There would be no issue at all with the MR being configured as both a >> DHCP client and relay, and the HA as a DHCP server: the DHCP >> messages would be unicasted bewteen MR and HA without tunneling. > > I somehow agree. Just to say that if the goal is to have DHCP > unicasted > messages (avoid the DHCP Solicit) then it is sufficient for the MR to > know the address of the DHCP Server in advance (presumably the HA) and > send it a straight unicast DHCP Request. I doubt the necessity of > having a DHCP Relay co-located with the DHCP Client (although I > agree it > is a suggestive illustration). > >> I thought that was what we agreed on and I'm seeing now the draft >> still talks about multicasting into the tunnel... > > I agree, I have the same surprise. I guess the reason of using tunnel is security. We don't have any secured mechanism for protecting DHCP unicast message. In NEMO nor MIP, IPsec SA is not created for DHCP-unicast messages. MR cannot trust the unprotected DHCP message for its MNP.. regards, ryuji > > >> I think the tunneling story (Sec. 3.2) should be removed from the >> draft, and the DHCP relay configuration mode made the mandatory >> method for a NEMO MR to obtain a prefix dynamically, i.e. put a >> couple of SHOULD words here and there in Sec. 3.3. > > I agree to have unicast DHCP exchanges but not sure about the > co-location Relay/Client. > > 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 Dec 17 01:04:31 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E4543A6AC8; Wed, 17 Dec 2008 01:04:31 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77CCC3A6AC8 for ; Wed, 17 Dec 2008 01:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 V+2sFbHNq+l4 for ; Wed, 17 Dec 2008 01:04:29 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 90DB93A681D for ; Wed, 17 Dec 2008 01:04:29 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1229504661!12668718!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 13068 invoked from network); 17 Dec 2008 09:04:21 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 17 Dec 2008 09:04:21 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBH94Kl7023780; Wed, 17 Dec 2008 02:04:20 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id mBH94KQv013213; Wed, 17 Dec 2008 03:04:20 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.125]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id mBH94JOx013198; Wed, 17 Dec 2008 03:04:19 -0600 (CST) Message-ID: <4948C092.4050507@gmail.com> Date: Wed, 17 Dec 2008 10:04:18 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Ryuji Wakikawa References: <491039B9.6090400@it.uc3m.es> <200812111050.19715.julien.laganier.IETF@googlemail.com> <200812121152.04045.julien.laganier.IETF@googlemail.com> <494646EB.4050203@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 081216-0, 16/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU X-BeenThere: mext@ietf.org X-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 Ryuji Wakikawa wrote: > Julien and Alex, > > On 2008/12/15, at 21:00, Alexandru Petrescu wrote: > >> Julien Laganier wrote: >>> Hello Ryuji, On Thursday 11 December 2008, Ryuji Wakikawa wrote: >>>> Actually, it's not only 3 round trip and is not optimization >>>> problem.. This is a big issue of DHCP-PD. Let me explain the >>>> issue clearly. According to the NEMO-DHCP-PD spec, before >>>> receiving a prefix, a mobile router must create a tunnel with >>>> its HA. >>> There would be no issue at all with the MR being configured as >>> both a DHCP client and relay, and the HA as a DHCP server: the >>> DHCP messages would be unicasted bewteen MR and HA without >>> tunneling. >> >> I somehow agree. Just to say that if the goal is to have DHCP >> unicasted messages (avoid the DHCP Solicit) then it is sufficient >> for the MR to know the address of the DHCP Server in advance >> (presumably the HA) and send it a straight unicast DHCP Request. I >> doubt the necessity of having a DHCP Relay co-located with the >> DHCP Client (although I agree it is a suggestive illustration). >> >>> I thought that was what we agreed on and I'm seeing now the draft >>> still talks about multicasting into the tunnel... >> >> I agree, I have the same surprise. > > I guess the reason of using tunnel is security. We don't have any > secured mechanism for protecting DHCP unicast message. We have two choices: (1) an authentication option for DHCP messages (RFC3118) carried in the payload and (2) if IKE is run prior to the DHCP exchanges then they could be protected by transport ESP I believe. Alex > In NEMO nor MIP, IPsec SA is not created for DHCP-unicast messages. > > MR cannot trust the unprotected DHCP message for its MNP.. > > regards, ryuji > >> >> >>> I think the tunneling story (Sec. 3.2) should be removed from the >>> draft, and the DHCP relay configuration mode made the mandatory >>> method for a NEMO MR to obtain a prefix dynamically, i.e. put a >>> couple of SHOULD words here and there in Sec. 3.3. >> >> I agree to have unicast DHCP exchanges but not sure about the >> co-location Relay/Client. >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 17 01:11: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 C96F73A6A97; Wed, 17 Dec 2008 01:11:27 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 557F53A6A88 for ; Wed, 17 Dec 2008 01:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbtfUbTgpUrK for ; Wed, 17 Dec 2008 01:11:20 -0800 (PST) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.238]) by core3.amsl.com (Postfix) with ESMTP id 9D24D3A6A9E for ; Wed, 17 Dec 2008 01:11:20 -0800 (PST) Received: by qb-out-0506.google.com with SMTP id d11so1898261qbd.41 for ; Wed, 17 Dec 2008 01:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=gvVNTL0GhajoLpXsLGrXiXl9o1LYXE0Gpd6l1VXluNM=; b=FlzwX0ykkK653IFE7rME3wcv9wpbgcB+vBI5bqgq6QwBHXbbff2a1YkgDh+7R5iSxS G73rMSha0YIiHzjvLNgmUJaizuY6YzWwnvlG5kACToL3la/WSTRsJ2Nu4SX/nDukpxun Fh5FpkB5nF3r2jAGPGryZuTc6cFvHcGboqhDI= 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=dOgbMBU0iBD7oKh/9S+rI+5sscptwnxhHJtF8UXvtB50TKOFZ6BMl/KCgeVEvUWXc9 rN9jyB/Z/bYH3+liSzSt4GDLjRvY0CaDb2p+4JaskC7fOdb19te6egY6lnPiTYLcUJIu 0DzWT03+9OEfjH2qvkLoLkyFxjJ2jPZXdsqp8= Received: by 10.143.18.21 with SMTP id v21mr204503wfi.336.1229505072142; Wed, 17 Dec 2008 01:11:12 -0800 (PST) Received: from ?172.17.105.34? (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 31sm3799824wff.3.2008.12.17.01.11.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Dec 2008 01:11:11 -0800 (PST) From: Ryuji Wakikawa To: Alexandru Petrescu In-Reply-To: <4948C092.4050507@gmail.com> References: <491039B9.6090400@it.uc3m.es> <200812111050.19715.julien.laganier.IETF@googlemail.com> <200812121152.04045.julien.laganier.IETF@googlemail.com> <494646EB.4050203@gmail.com> <4948C092.4050507@gmail.com> Message-Id: <5DD1480D-293A-4A7F-A7A2-16DF02A95E89@gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 17 Dec 2008 18:11:08 +0900 X-Mailer: Apple Mail (2.930.3) Cc: Julien Laganier , mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU X-BeenThere: mext@ietf.org X-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 On 2008/12/17, at 18:04, Alexandru Petrescu wrote: > Ryuji Wakikawa wrote: >> Julien and Alex, >> On 2008/12/15, at 21:00, Alexandru Petrescu wrote: >>> Julien Laganier wrote: >>>> Hello Ryuji, On Thursday 11 December 2008, Ryuji Wakikawa wrote: >>>>> Actually, it's not only 3 round trip and is not optimization >>>>> problem.. This is a big issue of DHCP-PD. Let me explain the >>>>> issue clearly. According to the NEMO-DHCP-PD spec, before >>>>> receiving a prefix, a mobile router must create a tunnel with >>>>> its HA. >>>> There would be no issue at all with the MR being configured as >>>> both a DHCP client and relay, and the HA as a DHCP server: the >>>> DHCP messages would be unicasted bewteen MR and HA without >>>> tunneling. >>> I somehow agree. Just to say that if the goal is to have DHCP >>> unicasted messages (avoid the DHCP Solicit) then it is sufficient >>> for the MR to know the address of the DHCP Server in advance >>> (presumably the HA) and send it a straight unicast DHCP Request. I >>> doubt the necessity of having a DHCP Relay co-located with the >>> DHCP Client (although I agree it is a suggestive illustration). >>>> I thought that was what we agreed on and I'm seeing now the draft >>>> still talks about multicasting into the tunnel... >>> I agree, I have the same surprise. >> I guess the reason of using tunnel is security. We don't have any >> secured mechanism for protecting DHCP unicast message. > > We have two choices: (1) an authentication option for DHCP messages > (RFC3118) carried in the payload and (2) if IKE is run prior to the > DHCP > exchanges then they could be protected by transport ESP I believe. The authentication option is just for authentication and not encryption. It might not be strong enough for MNP delegation compared to other signaling protection. When MN obtains HoA by IKE (before DHCP), SA for DHCP can be also established at that time. We should avoid running multiple IKEs for NEMO signaling. This comes back to the same issue of the use of tunneling. (i.e. # of round trip time). btw, we should not mandate IKE for NEMO-PD.. regards, ryuji > > > Alex > >> In NEMO nor MIP, IPsec SA is not created for DHCP-unicast messages. >> MR cannot trust the unprotected DHCP message for its MNP.. >> regards, ryuji >>>> I think the tunneling story (Sec. 3.2) should be removed from the >>>> draft, and the DHCP relay configuration mode made the mandatory >>>> method for a NEMO MR to obtain a prefix dynamically, i.e. put a >>>> couple of SHOULD words here and there in Sec. 3.3. >>> I agree to have unicast DHCP exchanges but not sure about the co- >>> location Relay/Client. >>> Alex >>> ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security >>> System. For more information please visit http://www.messagelabs.com/email >>> >>> ______________________________________________________________________ > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 17 01:22: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 BE5983A6AF2; Wed, 17 Dec 2008 01:22:33 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49DEF3A6AF2 for ; Wed, 17 Dec 2008 01:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 qKr2+39p7tmi for ; Wed, 17 Dec 2008 01:22:20 -0800 (PST) Received: from mail-ew0-f17.google.com (mail-ew0-f17.google.com [209.85.219.17]) by core3.amsl.com (Postfix) with ESMTP id 95C7B3A6AC8 for ; Wed, 17 Dec 2008 01:22:20 -0800 (PST) Received: by ewy10 with SMTP id 10so4176209ewy.13 for ; Wed, 17 Dec 2008 01:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=EzrOY48csvAKdiqW7aEAsKF4sXj/aASa3APtEcrSbTg=; b=OmmjY+kOjfsZvVqkgSaO9gL3qi+HRtdtQ6z64E4hoHNNztIlE4s7d9/Y19kVm7+Yxq EALNxZAi89KM33wv/h4QNY3eMI7k60cXAdnHDulbFBWQFgPp77wOMMKPyXhzeVsA7ptb Z1GSa1IqtvFbBGFee+b+LzcHJnwspQ12oYWRA= 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=IxRe+vLPEFTu4Z6cPzDsJz8nYVPRp3TQj1IYO3aYwNfQqDfmO9uyZOaW2q083bIKEW kGibL8RKmgeQ/m7JCWNQ8njMqt4l8E9oiXqUgEvfSR9MAd/Q5+027T/dXkTxYqgh0/ys Vcor2ewbW/0nXXoNpVdW24/PK2Rle/8o9kArE= Received: by 10.210.54.17 with SMTP id c17mr573187eba.57.1229505731439; Wed, 17 Dec 2008 01:22:11 -0800 (PST) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id g11sm2814894gve.16.2008.12.17.01.22.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Dec 2008 01:22:10 -0800 (PST) To: Ryuji Wakikawa Date: Wed, 17 Dec 2008 10:22:05 +0100 User-Agent: KMail/1.9.10 References: <491039B9.6090400@it.uc3m.es> <494646EB.4050203@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200812171022.06418.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ryuji, On Wednesday 17 December 2008, Ryuji Wakikawa wrote: > I guess the reason of using tunnel is security. > We don't have any secured mechanism for protecting DHCP unicast > message. In NEMO nor MIP, IPsec SA is not created for DHCP-unicast > messages. > > MR cannot trust the unprotected DHCP message for its MNP.. With MIPv6 there's already the requirement that a certain number of IPsec SAs are cinfigured between the MN and the HA, thus I don't see any problem with requiring a few more to protect DHCP signaling exchanged between the MR and HA. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 17 02:00:54 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373B73A6B03; Wed, 17 Dec 2008 02:00:54 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21913A6B01 for ; Wed, 17 Dec 2008 02:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 c34H8vLb2G8C for ; Wed, 17 Dec 2008 02:00:47 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id EF02C3A6859 for ; Wed, 17 Dec 2008 02:00:46 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-153.messagelabs.com!1229508038!11582619!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 1490 invoked from network); 17 Dec 2008 10:00:38 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-153.messagelabs.com with SMTP; 17 Dec 2008 10:00:38 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBHA0Xle005696; Wed, 17 Dec 2008 03:00:33 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id mBHA0Wxv007551; Wed, 17 Dec 2008 04:00:32 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id mBHA0VgR007537; Wed, 17 Dec 2008 04:00:32 -0600 (CST) Message-ID: <4948CDBD.9060201@gmail.com> Date: Wed, 17 Dec 2008 11:00:29 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Ryuji Wakikawa References: <491039B9.6090400@it.uc3m.es> <200812111050.19715.julien.laganier.IETF@googlemail.com> <200812121152.04045.julien.laganier.IETF@googlemail.com> <494646EB.4050203@gmail.com> <4948C092.4050507@gmail.com> <5DD1480D-293A-4A7F-A7A2-16DF02A95E89@gmail.com> In-Reply-To: <5DD1480D-293A-4A7F-A7A2-16DF02A95E89@gmail.com> X-Antivirus: avast! (VPS 081216-0, 16/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: Julien Laganier , mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU X-BeenThere: mext@ietf.org X-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 Ryuji Wakikawa wrote: > > On 2008/12/17, at 18:04, Alexandru Petrescu wrote: > >> Ryuji Wakikawa wrote: >>> Julien and Alex, >>> On 2008/12/15, at 21:00, Alexandru Petrescu wrote: >>>> Julien Laganier wrote: >>>>> Hello Ryuji, On Thursday 11 December 2008, Ryuji Wakikawa wrote: >>>>>> Actually, it's not only 3 round trip and is not optimization >>>>>> problem.. This is a big issue of DHCP-PD. Let me explain the issue >>>>>> clearly. According to the NEMO-DHCP-PD spec, before receiving a >>>>>> prefix, a mobile router must create a tunnel with its HA. >>>>> There would be no issue at all with the MR being configured as both >>>>> a DHCP client and relay, and the HA as a DHCP server: the DHCP >>>>> messages would be unicasted bewteen MR and HA without tunneling. >>>> I somehow agree. Just to say that if the goal is to have DHCP >>>> unicasted messages (avoid the DHCP Solicit) then it is sufficient >>>> for the MR to know the address of the DHCP Server in advance >>>> (presumably the HA) and send it a straight unicast DHCP Request. I >>>> doubt the necessity of having a DHCP Relay co-located with the >>>> DHCP Client (although I agree it is a suggestive illustration). >>>>> I thought that was what we agreed on and I'm seeing now the draft >>>>> still talks about multicasting into the tunnel... >>>> I agree, I have the same surprise. >>> I guess the reason of using tunnel is security. We don't have any >>> secured mechanism for protecting DHCP unicast message. >> >> We have two choices: (1) an authentication option for DHCP messages >> (RFC3118) carried in the payload and (2) if IKE is run prior to the DHCP >> exchanges then they could be protected by transport ESP I believe. > > The authentication option is just for authentication and not encryption. > It might not be strong enough for MNP delegation compared to other > signaling protection. We may need to specifically point out the needs of hiding the MNP, rather than needing encryption just because it's better in a sense (and worse in another). > When MN obtains HoA by IKE (before DHCP), SA for DHCP can be also > established at that time. We should avoid running multiple IKEs for NEMO > signaling. I agree the IKE prior to DHCP could be used to further protect DHCP exchanges. > This comes back to the same issue of the use of tunneling. (i.e. # of > round trip time). > btw, we should not mandate IKE for NEMO-PD.. I think I personally wouldn't mandate IKE either, make it more as an option. [I also think the entire picture of bootstrapping for MIP6 (HoA, HA address, MNP, SAs) is all very unclear from the standpoint of requirements and of threat analysis; but that's another point.] Alex > > regards, > ryuji > > > >> >> >> Alex >> >>> In NEMO nor MIP, IPsec SA is not created for DHCP-unicast messages. >>> MR cannot trust the unprotected DHCP message for its MNP.. >>> regards, ryuji >>>>> I think the tunneling story (Sec. 3.2) should be removed from the >>>>> draft, and the DHCP relay configuration mode made the mandatory >>>>> method for a NEMO MR to obtain a prefix dynamically, i.e. put a >>>>> couple of SHOULD words here and there in Sec. 3.3. >>>> I agree to have unicast DHCP exchanges but not sure about the >>>> co-location Relay/Client. >>>> Alex >>>> ______________________________________________________________________ >>>> This email has been scanned by the MessageLabs Email Security >>>> System. For more information please visit >>>> http://www.messagelabs.com/email ______________________________________________________________________ >>>> >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 17 03:05: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 D0B323A6B14; Wed, 17 Dec 2008 03:05:53 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 133473A682E for ; Wed, 17 Dec 2008 03:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.275 X-Spam-Level: X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=0.324, 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 mAzOpP0J2RM4 for ; Wed, 17 Dec 2008 03:05:46 -0800 (PST) Received: from tietoe03.tietoenator.com (datnt07.tieto.com [194.110.47.24]) by core3.amsl.com (Postfix) with ESMTP id 4F5F83A6B14 for ; Wed, 17 Dec 2008 03:05:45 -0800 (PST) X-AuditID: c26e2f18-000013b800000510-d4-4948dd344218 Received: from stingray.eu.tieto.com ([192.176.143.13]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Dec 2008 13:06:28 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 12:05:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Dec 2008 12:05:36 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comment on DSMIP draft 7 Thread-Index: AclgN2N8VL7Wn3HJR6SNtzXedYvshw== From: To: X-OriginalArrivalTime: 17 Dec 2008 11:05:36.0990 (UTC) FILETIME=[63C20FE0:01C96037] X-Brightmail-Tracker: AAAAAA== Subject: [MEXT] Comment on DSMIP draft 7 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 In another mail (commenting on the home binding as specified in MCoA draft) you have the sentence: "The way it [a binding update] works is that one BU replaces the previous one." Thus the home agent has in its binding cache one entry per home address, more specifically per IPv6 home address, and that entry is to be updated in toto when receiving a new binding update sent from the mobile node with that home address. This is certainly how the binding updates of DSMIP are supposed to work. When describing this way of working, I'll suggest the following wording from the DSMIP draft 7 edited. The quotes give the impression that the home agent handles two bindings, one for the IPv6 home address and another for the IPv4 home address, but really there is just one binding using the IPv6 home address as the key to entry, and that entry may store an IPv4 home address as an additional piece of information. * "create a binding cache entry for each address" (section 3.3) * "the home agent creates two binding cache entries, one for the mobile node's IPv4 home address, and another for the mobile node's IPv6 care-of address" (section 3.3.1) * "both entries will point to the" (section 3.3.1) * "creating the corresponding binding cache entries" (section 3.3.1) * "If an IPv4 home address option were included, the home agent MUST create another entry for that address." (section 3.3.2.1) * "All entries MUST point to the mobile node's IPv4 care-of address." (section 3.3.2.1 and 3.3.2.2) * "After accepting the binding updates and creating the corresponding entries" (section 3.3.2.2) * "Upon receiving this binding update, the home agent will replace the existing cache entries with the content of the new message" (section 5.4.2.1) * "If the binding update is accepted for both IPv4 and IPv6 home addresses, the home agent creates separate binding cache entries, one for each home address." (section 5.5) Also, the binding cache is a logical entity which can be implemented any way consistent with external behavior, so in practice in an implementation there could be two entries, but the specification should speak of one entry. It may be considered, whether also the binding update list really is best thought of as having one entry, for example the following quote * "If the mobility header includes an IPv4 address acknowledgement option indicating success, the mobile node should create two entries in its binding update list, one for the IPv6 home address and another for the IPv4 home address" (section 5.4.2) Christian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 17 05:57: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 75A6E3A6AF4; Wed, 17 Dec 2008 05:57:33 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F94E3A6AF4 for ; Wed, 17 Dec 2008 05:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqwTSjf117yr for ; Wed, 17 Dec 2008 05:57:27 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 83F033A6999 for ; Wed, 17 Dec 2008 05:57:26 -0800 (PST) Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LCwtm-0001Fm-AZ; Thu, 18 Dec 2008 00:57:14 +1100 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 18 Dec 2008 00:57:10 +1100 From: Hesham Soliman To: , Message-ID: Thread-Topic: [MEXT] Comment on DSMIP draft 7 Thread-Index: AclgN2N8VL7Wn3HJR6SNtzXedYvshwAF/djN In-Reply-To: Mime-version: 1.0 Subject: Re: [MEXT] Comment on DSMIP draft 7 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 17/12/08 10:05 PM, "Christian.Kaas-Petersen@tieto.com" wrote: > Hi Hesham > > In another mail (commenting on the home binding as specified in > MCoA draft) you have the sentence: "The way it [a binding update] > works is that one BU replaces the previous one." Thus the home > agent has in its binding cache one entry per home address, => I think the words after "thus" are not really a consequence of the sentence you quote. Those are two separate issues, one is about the BU operation and another is about the number of entries for each home address. > more specifically per IPv6 home address, and that entry is to be > updated in toto when receiving a new binding update sent from the > mobile node with that home address. => Yes but the BCE is a conceptual entity described in RFC 3775. How it gets implemented is a different story. Following that conceptual entity's description in 3775, DSMIPv6 describes how the same concepts can apply. > > This is certainly how the binding updates of DSMIP are supposed to > work. When describing this way of working, I'll suggest the > following wording from the DSMIP draft 7 edited. > The quotes give the impression that the home > agent handles two bindings, one for the IPv6 home address and another > for the IPv4 home address, but really there is just one binding > using the IPv6 home address as the key to entry, and that entry > may store an IPv4 home address as an additional piece of information. => There are two logical bindings, which can be implemented as two linked entries, or one hierarchical entry, it's the same thing. As I said above, the logical contruct is based on how 3775 decribes the binding cache. > > * "create a binding cache entry for each address" (section 3.3) > > * "the home agent creates two binding cache entries, one > for the mobile node's IPv4 home address, and another > for the mobile node's IPv6 care-of address" (section 3.3.1) > > * "both entries will point to the" (section 3.3.1) > > * "creating the corresponding binding cache entries" (section 3.3.1) > > * "If an IPv4 home address option were included, the home agent > MUST create another entry for that address." (section 3.3.2.1) > > * "All entries MUST point to the mobile node's IPv4 care-of address." > (section 3.3.2.1 and 3.3.2.2) > > * "After accepting the binding updates and creating the corresponding > entries" (section 3.3.2.2) > > * "Upon receiving this binding update, the home agent will replace the > existing cache entries with the content of the new message" > (section 5.4.2.1) > > * "If the binding update is accepted for both IPv4 and IPv6 home > addresses, the home agent creates separate binding cache entries, > one for each home address." (section 5.5) => We've discussed this before in the DT for many weeks. I think we shouldn't change this now. > > Also, the binding cache is a logical entity which can be implemented > any way consistent with external behavior, so in practice in > an implementation there could be two entries, but the specification > should speak of one entry. => Why should it speak of one entry when there are two home addresses? Please see above. Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 17 07:29: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 BE5A13A695E; Wed, 17 Dec 2008 07:29:26 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCDCC28C193; Tue, 16 Dec 2008 13:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.593 X-Spam-Level: X-Spam-Status: No, score=-6.593 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, GUARANTEED_100_PERCENT=0.012, 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 l+m2ezXfdwmo; Tue, 16 Dec 2008 13:33:03 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id EFF0728C14E; Tue, 16 Dec 2008 13:33:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,232,1228089600"; d="scan'208";a="56403944" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 16 Dec 2008 21:32:56 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBGLWte0025133; Tue, 16 Dec 2008 13:32:55 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBGLWtwP012902; Tue, 16 Dec 2008 21:32:55 GMT From: "Dan Wing" To: "'Hesham Soliman'" , "'Colin Perkins'" References: <5B953275-471A-40FF-B923-EB697AA96CA8@csperkins.org> Date: Tue, 16 Dec 2008 13:32:55 -0800 Message-ID: <3cad01c95fc5$dbe9d2e0$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 thread-index: AclToDehY9f7D5O2B0SDZCHZLI7C0gMJX5Pg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2909; t=1229463176; x=1230327176; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20tsv-dir=20review=20of=20draft-ietf-mext -nemo-v4traversal-06.txt |Sender:=20; bh=/HKdDckFLRnrJDUPuMQqsWkg3DhnKqSTDTzfys23lZE=; b=1eWFPe5pQcpovdqx9bGK9YNPJh1lBtOxrRtgCEwyDG/fRBVcLvet7S7DY8 Ilbo3Oy9hQl4y0ZR0U99KyNcdSmMA1WceBTaiBZMj7QhpaxMHATkO8q1C+et eMrlCe55Yt; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Mailman-Approved-At: Wed, 17 Dec 2008 07:29:25 -0800 Cc: mext@ietf.org, ietf@ietf.org, 'TSV Dir' Subject: Re: [MEXT] tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On > Behalf Of Hesham Soliman > Sent: Monday, December 01, 2008 2:33 AM > To: Colin Perkins > Cc: TSV Dir; ietf@ietf.org; mext@ietf.org > Subject: Re: tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt > > Thanks Colin, > > I agree with your rationale but I wonder if we need to > support every broken > device out there. In any case, if we have to, I prefer to > require encryption > than to add the XORED address option. I'd like to hear what > people in MEXT > think about this, comments from MEXT? (catching up on email after a long vacation; sorry for the delay.) FYI, Teredo also found NATs that meddled with IP addresses on 32 bit boundaries. From RFC4380, Other investigation in the behavior of NAT also outlined the "probabilistic rewrite" behavior. Some brands of NAT will examine all packets for "embedded addresses", IP addresses, and port numbers present in application payloads. They will systematically replace 32-bit values that match a local address by the corresponding mapped address. The Teredo specification includes an "obfuscation" procedure in order to avoid this behavior. -d > Hesham > > > On 1/12/08 9:13 PM, "Colin Perkins" wrote: > > > On 1 Dec 2008, at 09:00, Hesham Soliman wrote: > >>>> => Well, I'm not sure how a NAT can do that. You mean > the NAT will > >>>> parse the binding update message deep inside the IPv6 extension > >>>> header in the inner IP packet? This is where the original address > >>>> is preserved. To do that, a NAT would have to understand the > >>>> various MIPv6 options, and if it did, it would know not to do > >>>> that :) The inner header is IPv6, so a NAT should not touch that. > >>> > >>> My understanding from the STUN work is that NATs have > been observed > >>> which rewrite any sequence of four aligned bytes matching > the source > >>> IP address, irrespective of its location within the > packet (section > >>> 15.2 of RFC 5389). > >> > >> => Sounds freightning! May be we need to mandate encryption and > >> hope that no 4-byte sequence matched the IP address? What do they > >> do with encrypted packets? How do they know they're encrypted? > > > > One would assume these broken devices will potentially corrupt > > encrypted packets, the same as they will potentially corrupt any > > other packet. Hiding the source address when it appears in the > > payload (either by encryption, or using some trivial obfuscation as > > does STUN) simply reduces the probability of such corruption so it's > > no longer 100% guaranteed that the payload will be mangled. > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 17 07:59:37 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4D733A6AC5; Wed, 17 Dec 2008 07:59:37 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E5B93A6AC5 for ; Wed, 17 Dec 2008 07:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.688 X-Spam-Level: X-Spam-Status: No, score=-103.688 tagged_above=-999 required=5 tests=[AWL=-1.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ND3hk2P+R4x for ; Wed, 17 Dec 2008 07:59:36 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 136423A68D3 for ; Wed, 17 Dec 2008 07:59:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1229529569; x=1261065569; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Ryuji=20Wakikawa=20,=0D =0A=20=20=20=20=20=20=20=20Hesham=20Soliman=0D=0A=09|CC:=20"Christian.Kaas-Petersen@tiet o.com"=20,=0D=0A=20=20 =20=20=20=20=20=20"mext@ietf.org"=20|Date: =20Wed,=2017=20Dec=202008=2007:59:21=20-0800|Subject:=20R E:=20[MEXT]=20Subject:=20Multiple=20CoA=20draft=2010=20-- =20two=20proposals=20and=20some=0D=0A=20comments |Thread-Topic:=20[MEXT]=20Subject:=20Multiple=20CoA=20dra ft=2010=20--=20two=20proposals=20and=0D=0A=20some=20comme nts|Thread-Index:=20AclgF43poZT+o9tDTRi3lVTFBZ+T3AASM6uQ |Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3D85E52BA@ NASANEXMB08.na.qualcomm.com>|References:=20<057632CE4CE10 D45A1A3D6D19206C3A3D6E298C1@NASANEXMB08.na.qualcomm.com> =0D=0A=09=0D=0A =20|In-Reply-To: =20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5466"=3B=20a=3D"14005903"; bh=rQtHES7vX4E5PO1H1SzwYVdWfV7nkpx5CQUWzC3UUQ4=; b=oehUBggsmil7n5H0/hocreR/ILzgYNWXZWgZE2wR+w/q4K6CfUZZW5/m 9cnbbZXRsppEP9hVKczM/BSrO18U7DY0WcY88o82EHfKrTjUDU6GuYeQQ io6iPsKHxESA4hBON6f40ii2H2yBVQdRkYigeqPShGdYNRBBFy2U5e2fp 4=; X-IronPort-AV: E=McAfee;i="5100,188,5466"; a="14005903" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Dec 2008 07:59:28 -0800 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBHFxS50030854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Dec 2008 07:59:28 -0800 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBHFxPr7031482 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 17 Dec 2008 07:59:25 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub06.na.qualcomm.com ([129.46.134.254]) with mapi; Wed, 17 Dec 2008 07:59:25 -0800 From: "Giaretta, Gerardo" To: Ryuji Wakikawa , Hesham Soliman Date: Wed, 17 Dec 2008 07:59:21 -0800 Thread-Topic: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments Thread-Index: AclgF43poZT+o9tDTRi3lVTFBZ+T3AASM6uQ Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D85E52BA@NASANEXMB08.na.qualcomm.com> References: <057632CE4CE10D45A1A3D6D19206C3A3D6E298C1@NASANEXMB08.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "mext@ietf.org" , "Christian.Kaas-Petersen@tieto.com" Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ryuji, > -----Original Message----- > From: Ryuji Wakikawa [mailto:ryuji.wakikawa@gmail.com] > Sent: Tuesday, December 16, 2008 11:18 PM > To: Hesham Soliman > Cc: Giaretta, Gerardo; Christian.Kaas-Petersen@tieto.com; mext@ietf.org > Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some > comments > > > Hi Hesham > > At Sat, 13 Dec 2008 13:06:03 +1100, > Hesham Soliman wrote: > > > > >> > > >> => But why would the MN want to do that? The scenario you're suggesting > > >> means that there is effectively one binding, so why do we need to > allocated > > >> two BIDs to the same CoA? If there is a reason then I think your proposal > is > > >> fine, although it will be tricky to implement. But I'd like to see a > > >> plausible scenario first. > > >> > > > > > > Suppose the MN is connected to access 1 and access2 and has two flow > bindings > > > with two different CoA > > > > > > HoA, BID=1, CoA1, FID1, FID4, FID6 > > > HoA, BID=2, CoA2 FID2, FID3, FID5 > > > > > > When the MN loses access 2 coverage it can do two things to keep the flows > > > active: > > > - send a BU with HoA, BID=1, FID2, FID3, FID5 to add those flows to the > first > > > binding > > > - send a BU with HoA, BID=2, CoA1 to update the CoA of the second binding > > > > > > The second has advantages in terms of signaling overhead. This is true in > > > particular if then the MN moves back to access2 and wants to re-establish > the > > > flow bindings as previously. In that case just a new CoA update is needed > > > instead of re-registering the flows again. > > > > => That's right, I guessed this is why you and Christian were asking for it. > > But I think it's strange to have a binding id if it's not unique because > > it's basically replicating the binding in case we need to change the CoA. It > > makes things more complex and error prone in the implementation for a small > > difference of bytes that will be sent. After all, you're not eliminating the > > need to send another BU, you're just sending a smaller BU. So if you're > > lucky, you'll save tens of bytes. It's not worth it IMHO. > > From protocol point of view, except for error handling, there are no > big issues and extentions to the current spec.. > > However, this feature is basically proposed for the flow binding optimization. > > Shall we relax this restriction (change MUST to SHOULD) to keep the > flow binding optimization? > What is exactly the text you propose to change in the draft? Thanks Gerardo > regards, > ryuji > > > Hesham > > > > > > > > If the second approach is used you will have up giving two different BIDs > for > > > which the CoA is the same. But this should not be an issue as the bindings > are > > > treated independently, they just happen to point to the same CoA > > > > > > Gerardo > > > > > >>> Draft 10, section 4.2 (and other places) defines the H flag, which when > > >>> set means the mobile node wants to use both its home link and one or > > >>> more of its foreign links. The H flag is really an instruction to the > > >>> home agent, that in addition to all the bidings currently defined > > >>> is shall have an extra binding where packets shall not be tunneled. > > >>> > > >>> Proposal: The mobile node should be able to define a binding saying > > >>> > > >>> HoA BID=0 HoA > > >>> > > >>> This is a kind of default binding to be used when any of the other HoA- > > >>> bindings cannot be used. I think the H flag is an indirect way of > > >>> saying there is an extra binding, whereas the binding above is direct. > > >>> It also avoids continuously setting the H flag when both home link > > >>> and foreign links are active. > > >> > > >> => This is basically asking for a permanent binding. Again, I'd like to > > >> understand why this is needed, compared to what the draft says now. > > >> > > >> Hesham > > >> > > >> > > >> _______________________________________________ > > >> MEXT mailing list > > >> MEXT@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 17 08:47: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 D48CF3A6B18; Wed, 17 Dec 2008 08:47:18 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 114113A6B18 for ; Wed, 17 Dec 2008 08:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.634 X-Spam-Level: X-Spam-Status: No, score=-105.634 tagged_above=-999 required=5 tests=[AWL=0.965, 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 CVIKQv1Gv8LA for ; Wed, 17 Dec 2008 08:47:15 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id EB5F03A6863 for ; Wed, 17 Dec 2008 08:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1229532428; x=1261068428; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Ryuji=20Wakikawa=20|CC: =20"Christian.Kaas-Petersen@tieto.com"=20,=0D=0A=20=20=20=20=20=20=20=20"mext@i etf.org"=20|Date:=20Wed,=2017=20Dec=202008 =2008:47:12=20-0800|Subject:=20RE:=20[MEXT]=20Subject:=20 Multiple=20CoA=20draft=2010=20--=20two=20proposals=20and =09some=0D=0A=20comments|Thread-Topic:=20[MEXT]=20Subject :=20Multiple=20CoA=20draft=2010=20--=20two=20proposals=20 and=0D=0A=09some=20comments|Thread-Index:=20AclgGZYZizX4H 0ZnQJ6HVfpI0KgkagATMbHA|Message-ID:=20<057632CE4CE10D45A1 A3D6D19206C3A3D85E52C0@NASANEXMB08.na.qualcomm.com> |References:=20,=0D=0A=20<057632CE4CE10D45A1A3D6D19206C3A3D85D72B3@ NASANEXMB08.na.qualcomm.com>=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en -US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5466"=3B=20a=3D"14031675"; bh=AqZN0JxWXGa+0J1t8mwZo69Uwh4prjWJexmFBIMSEHQ=; b=Sa09qI0wJhKnbikkMr72SVdiODDD8NVmG2xxMWa0xY4O5q/edl5K5wMC yFV4A7V28UF7Iul0Ba5mSiH3ecCIxnVyVqFn55GZY1rFL+BwlKe8l3ftf cN6d62s7kfTp5hfGcxwhiRQJHcb6sF7CC+qismNAzDEHZdJ+OQ4ENA7o2 Q=; X-IronPort-AV: E=McAfee;i="5300,2777,5466"; a="14031675" 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; 17 Dec 2008 08:47:07 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBHGl7lm003910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Dec 2008 08:47:07 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBHGl6Fj006044 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 17 Dec 2008 08:47:07 -0800 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub01.na.qualcomm.com ([10.46.93.121]) with mapi; Wed, 17 Dec 2008 08:47:06 -0800 From: "Giaretta, Gerardo" To: Ryuji Wakikawa Date: Wed, 17 Dec 2008 08:47:12 -0800 Thread-Topic: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments Thread-Index: AclgGZYZizX4H0ZnQJ6HVfpI0KgkagATMbHA Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3D85E52C0@NASANEXMB08.na.qualcomm.com> References: , <057632CE4CE10D45A1A3D6D19206C3A3D85D72B3@NASANEXMB08.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "mext@ietf.org" , "Christian.Kaas-Petersen@tieto.com" Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ryuji, > -----Original Message----- > From: Ryuji Wakikawa [mailto:ryuji.wakikawa@gmail.com] > Sent: Tuesday, December 16, 2008 11:32 PM > To: Giaretta, Gerardo > Cc: Christian.Kaas-Petersen@tieto.com; mext@ietf.org > Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some > comments > > Hi Gerardo, > > Yes, I was reading the mail threads. sorry to catch up this thread > late. I was in Europe;-) > > I understand the reasons of BID for the home attached interface. > > MN keeps sending the BU (w/ non zero lifetime) from the home link? > It sounds like we'll remove de-registration operation from RFC-3775? > The point is that the MN does no de-register as in RFC-3775 if there are other active interfaces. The MN will de-register only when only the interface on the home link is active. > As a result, HA will have a home binding for the interface attached to > home link, > but will not operate proxy ND and encapsulation for that binding. If the HA is the default router, the HA will still intercept all packets as defined in the draft. It is true that there will be no encapsulation, but again this is already mentioned in the draft. > I don't know this is reasonable modification to RFC-3775. > > My understanding was that, when MN is at home, most of traffic should > be sent directly from the home link. > I didn't see any strong reasons to use the interface attached to > foreign links. > Why not setting special flows which need to be sent from the foreign > link by flow binding and > rest of traffic are just sent from the home link. We don't need BID > for the home attached interface. > This is what I expected. > > Do you think there is a case where MN attaches to home link by > multiple interfaces? > Think about this scenario: the MN has a cellular interface and a WLAN interface. Cellular is the home link. MN wants to do VoIP over cellular and all other traffic over WLAN. In this case the MN will register a match-all filter for WLAN BID and more specific FIDs for the "home binding". This is the main scenario studied in 3GPP for example. In my opinion, allocating a BID for the HoA in the home link sounds like the cleanest way of solving this scenario. However I am open to other suggestions as soon as the scenario is supported :-) Gerardo > regards, > ryuji > > > > > > On 2008/12/17, at 15:42, Giaretta, Gerardo wrote: > > > Hi Ryuji, > > > > one point related to Christian's comments is that we need a BID also > > for the interface which is on the home link. This is needed in order > > to associate FIDs to that interface. The rules to create/update/ > > delete that BID should be the same as for any other binding > > > > Gerardo > > > > ________________________________________ > > From: mext-bounces@ietf.org [mext-bounces@ietf.org] On Behalf Of > > Ryuji Wakikawa [ryuji.wakikawa@gmail.com] > > Sent: Tuesday, December 16, 2008 10:27 PM > > To: Christian.Kaas-Petersen@tieto.com > > Cc: mext@ietf.org > > Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals > > and some comments > > > > Hi Christian, > > > > thanks for comments. > > > > At Thu, 11 Dec 2008 15:08:16 +0100, > > wrote: > >> > >> Assume a mobile node with home address HoA has two interfaces, > >> both attached to foreign links. After exchange of binding update > >> and binding acknowledgement, the home agent's binding cache (at > >> least the snip of it related to HoA) will look like this > >> > >> HoA, BID= 7, CoA1, other parameters like period of validity... > >> HoA, BID=10, CoA2, other parameters ... > >> > >> The draft uses HoA=2001:db8::EUI. > >> > >> Draft 10, section 5.1 states, that a BID value must be unique for a > >> home address and care-of address pair. This is satisfied above, but > >> it means, that the mobile station is not allowed to change the > >> second entry such that it also uses CoA1 as care-of address. > >> > >> Proposal: I think it has merit to be able to allow more than > >> one BID value per pair of home address and care-of address. Consider > >> flow bindings (defined in draft-ietf-mext-flow-binding) where > >> a flow may refer to a BID, and thus there is a simple way to move > >> flows between interfaces: only updating the binding cache. > > > > > > Do you want these bindings? > > HoA, BID= 7, CoA1, other parameters like period of validity... > > HoA, BID=10, CoA1, other parameters ... > > > > From the protocol operational view, we don't have any issue to relax > > the BID assignment for this purpose. > > > >> Draft 10, section 4.2 (and other places) defines the H flag, which > >> when > >> set means the mobile node wants to use both its home link and one or > >> more of its foreign links. The H flag is really an instruction to > >> the > >> home agent, that in addition to all the bidings currently defined > >> is shall have an extra binding where packets shall not be tunneled. > >> > >> Proposal: The mobile node should be able to define a binding saying > >> > >> HoA BID=0 HoA > >> > >> This is a kind of default binding to be used when any of the other > >> HoA- > >> bindings cannot be used. I think the H flag is an indirect way of > >> saying there is an extra binding, whereas the binding above is > >> direct. > >> It also avoids continuously setting the H flag when both home link > >> and foreign links are active. > > > > This was originally proposed by Keigo from Panasonic and has been > > discussed it. > > You can check the discussion on ML archives. > > > >> > >> Other comments > >> > >> o Figure 1: In general I think it simpler for human readers to have > >> the elements of the primary key to a database given first, > >> therefore I suggest > >> > >> binding [2001:db8::EUI BID1 care-of address1] > >> > >> to be used allover. > > > > OK, will fix this. > > > >> > >> o Figure 4: looks as if position 6 is followed by position 17. > > > > this is typo. i'll fix this. > > > >> o Section 4.2, O flag. The O flag is carried in an Binding > >> Identification mobility option, but really it a kind of global > >> value to be understood by the receiver as "clean all HoA entries". > >> If it really is too much to introduce a new mobility option, > >> isn't it enough to set the O flag in the first Binding > >> Identification mobility option? > > > > I'm updating the document after last call. the O flag is now defined > > in the BU itself, since this is global value for all bindings as you > > pointedout. > > > >> o Section 4.2, Care-of address and section 6.2 bullet 6, sub-bullet > >> 2. > >> If the care-of address is omitted, the care-of address is to be > >> taken from the source address of the IPv6 header. > >> When the binding update arrives at the home agent, the > >> IPv6 header's source address is exactly the care-of > >> address used by the mobile node, but when the home agent is > >> actually able to understand the contents of the binding update, > >> then the IPv6 headers source address has been swapped with the > >> address found in the Destination Option extension header, > >> and thus the care-of address is now found in the Destination > >> Option extension header. > > > > In section 6.1.7 of RFc3775, it said > > "The care-of address is specified either by the Source Address field > > in the IPv6 header or by the Alternate Care-of Address option, if > > present. " > > > > So, I will fix this to > > > > the care-of address is to be taken from the source address of the > > IPv6 header "of the Binding Update". > > > > > >> o Section 5.6.2, bullet 2. The term link-local address is used, > >> but I > >> think this should be changed to be like in all the other places, > >> using link-layer address. > > > > yes, thanks. > > > >> o Section 6.2, bullet 7, sub-bullet 1: I think the condition should > >> read > >> "If one of the 'O' flags is set, then all of the 'O' flags must be > >> set, else [MCOA MALFORMED] is returned." But as suggested above, > >> I don't think there is reason to enforce an all-or-none 'O' flags. > > > > right, see above. > > > >> o Section 8.2, para 2. The text says, that the IPv4 Address > >> Acknowledgement mobility option is included only if the mobile node > >> requested a home address. When I read > >> draft-ietf-mext-nemo-v4traversal, > >> section 4.2.1, the IPv4 Address Acknowledgement mobility option > >> is included always, indicating the home agent created a binding > >> cache > >> entry for the IPv4 home address. > > > > correct. I will check dsmip and update it. > > > > thanks > > ryuji > > > > > >> 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 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From jerry.goetzo@alcoa.com Wed Dec 17 10:46:42 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2123A6AF1 for ; Wed, 17 Dec 2008 10:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.455 X-Spam-Level: X-Spam-Status: No, score=-12.455 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFYnY+CU+t9u for ; Wed, 17 Dec 2008 10:46:36 -0800 (PST) Received: from 33.asp020.com (unknown [200.181.197.27]) by core3.amsl.com (Postfix) with SMTP id 9C7AD3A6768 for ; Wed, 17 Dec 2008 10:46:26 -0800 (PST) To: Subject: RE: We have found your lost message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081217184634.9C7AD3A6768@core3.amsl.com> Date: Wed, 17 Dec 2008 10:46:26 -0800 (PST)
Go to site!
From mbacit@affinityadvancedsolutions.com Wed Dec 17 11:54:57 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7274228C1D5 for ; Wed, 17 Dec 2008 11:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.709 X-Spam-Level: X-Spam-Status: No, score=-26.709 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oS2c0zeyDsE1 for ; Wed, 17 Dec 2008 11:54:57 -0800 (PST) Received: from 201-34-24-138.cbace702.dsl.brasiltelecom.net.br (201-34-24-138.cbace702.dsl.brasiltelecom.net.br [201.34.24.138]) by core3.amsl.com (Postfix) with SMTP id 6ECF13A68AA for ; Wed, 17 Dec 2008 11:54:54 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081217195455.6ECF13A68AA@core3.amsl.com> Date: Wed, 17 Dec 2008 11:54:54 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From massi.anastasi@accenture.com Wed Dec 17 12:04:24 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8119C28C1EE for ; Wed, 17 Dec 2008 12:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.27 X-Spam-Level: X-Spam-Status: No, score=-34.27 tagged_above=-999 required=5 tests=[BAYES_60=1, DNS_FROM_RFC_BOGUSMX=1.482, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hKDr8broM7w for ; Wed, 17 Dec 2008 12:04:24 -0800 (PST) Received: from 86-40-233-210-dynamic.b-ras3.mvw.galway.eircom.net (86-40-233-210-dynamic.b-ras3.mvw.galway.eircom.net [86.40.233.210]) by core3.amsl.com (Postfix) with SMTP id 338CB28C1E4 for ; Wed, 17 Dec 2008 12:04:22 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081217200423.338CB28C1E4@core3.amsl.com> Date: Wed, 17 Dec 2008 12:04:22 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From kama1@agt.net Wed Dec 17 12:53: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 F0A9A3A67C1 for ; Wed, 17 Dec 2008 12:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.468 X-Spam-Level: X-Spam-Status: No, score=-14.468 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7lq8QefLbXU for ; Wed, 17 Dec 2008 12:53:01 -0800 (PST) Received: from 201-10-139-113.gnace701.dsl.brasiltelecom.net.br (201-10-139-113.gnace701.dsl.brasiltelecom.net.br [201.10.139.113]) by core3.amsl.com (Postfix) with SMTP id 868BC3A67E1 for ; Wed, 17 Dec 2008 12:52:58 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081217205259.868BC3A67E1@core3.amsl.com> Date: Wed, 17 Dec 2008 12:52:58 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mext-bounces@ietf.org Wed Dec 17 14:50:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFBA03A689F; Wed, 17 Dec 2008 14:50:25 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCBE93A689F for ; Wed, 17 Dec 2008 14:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.387, 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 sakgT8C3qvtN for ; Wed, 17 Dec 2008 14:50:24 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 09DFA3A688C for ; Wed, 17 Dec 2008 14:50:23 -0800 (PST) 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 mBHMs4T6015119; Wed, 17 Dec 2008 16:54:04 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Dec 2008 16:50:14 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Dec 2008 17:50:13 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bulk Binding Refresh or Deregistration after Separate Binding Registration in MCoA Thread-Index: Aclggn6CdfCGCk4KQSioh+lZo4g0EAAFe1QQ References: From: "Desire Oulai" To: "Ryuji Wakikawa" X-OriginalArrivalTime: 17 Dec 2008 22:50:14.0898 (UTC) FILETIME=[D35ADD20:01C96099] Cc: mext@ietf.org Subject: [MEXT] Bulk Binding Refresh or Deregistration after Separate Binding Registration in MCoA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi ryuji, As you mentionned in another thread, bulk registration could face security problems. However, is it possible for a MN to do separate binding registration then do bulk binding refresh or bulk deregistration? BR Desire _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 17 22:37:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D35313A6B68; Wed, 17 Dec 2008 22:37:16 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2FFF3A6B6A for ; Wed, 17 Dec 2008 22:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPEtaxjkkSRG for ; Wed, 17 Dec 2008 22:37:15 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id 068CD3A6B68 for ; Wed, 17 Dec 2008 22:37:14 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so265216rvf.49 for ; Wed, 17 Dec 2008 22:37:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=2FcGfICuo7XWf2lTTu1Hk7qU863kCI1b3kXas8uR5lI=; b=tnfSWtHGv/E5clRubw/H4ITptTe+/AVTp5w8RCcmcRd4tteoYZNuq3EexdI4MXBjkL TagXM81/LhK1D3NmwDuTKvZEDQyAPYPM2S58lO7cx3rXVzur1mguOhL9hQwM0hfxQBh3 EjAbFLQNaSdAx6VucaFlgN/eYVvVxO9gb2R/Q= 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=lI5gvR1fvws4ruELwRc1N+3G7DdeS63J2zBhZL4ctYMoL96DEPBj1VpoORYpA2sIxk V7N1Q4KMW6m0c7c0cFGpvXDYjxoQrZR3/+AAvDAFVLS4bzSTafsyrP5mwfDRtx9U/ZJW cwa8ZcREQ52zlZn/LqmjW//yopsUD7Bk65z7I= Received: by 10.142.165.14 with SMTP id n14mr659154wfe.280.1229582227004; Wed, 17 Dec 2008 22:37:07 -0800 (PST) Received: from ?172.17.105.34? (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 32sm13636869wfc.39.2008.12.17.22.37.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Dec 2008 22:37:06 -0800 (PST) From: Ryuji Wakikawa To: Desire Oulai In-Reply-To: References: Message-Id: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 18 Dec 2008 15:37:03 +0900 X-Mailer: Apple Mail (2.930.3) Cc: mext@ietf.org Subject: Re: [MEXT] Bulk Binding Refresh or Deregistration after Separate Binding Registration in MCoA X-BeenThere: mext@ietf.org X-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 Desire, On 2008/12/18, at 7:50, Desire Oulai wrote: > Hi ryuji, > > As you mentionned in another thread, bulk registration could face > security problems. right. HA cannot verify the reachability of all CoAs. > However, is it possible for a MN to do separate > binding registration then do bulk binding refresh or bulk > deregistration? Yes, MN can switch to bulk registration after the separate registration. regards, ryuji > > > BR > > Desire _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 17 22:52: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 DA3493A6863; Wed, 17 Dec 2008 22:52:52 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC0F3A6783 for ; Wed, 17 Dec 2008 22:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.43 X-Spam-Level: X-Spam-Status: No, score=-0.43 tagged_above=-999 required=5 tests=[AWL=-0.340, 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 lRz1EQ6fCFCU for ; Wed, 17 Dec 2008 22:52:51 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 3B5743A6863 for ; Wed, 17 Dec 2008 22:52:50 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id mBI6qY2U014368; Thu, 18 Dec 2008 15:52:34 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id mBI6qZq29100; Thu, 18 Dec 2008 15:52:35 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili03) with ESMTP id mBI6qYY11105; Thu, 18 Dec 2008 15:52:34 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.115]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Dec 2008 14:52:07 +0800 Message-ID: <4949F309.40305@sg.panasonic.com> Date: Thu, 18 Dec 2008 14:51:53 +0800 From: Benjamin Lim User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ryuji Wakikawa References: In-Reply-To: X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 18 Dec 2008 06:52:07.0569 (UTC) FILETIME=[24A65810:01C960DD] Cc: Desire Oulai , mext@ietf.org Subject: Re: [MEXT] Bulk Binding Refresh or Deregistration after Separate Binding Registration in MCoA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ryuji, Ryuji Wakikawa wrote: >> However, is it possible for a MN to do separate >> binding registration then do bulk binding refresh or bulk >> deregistration? > > Yes, MN can switch to bulk registration after the separate registration. [Ben] So does the HA accept this bulk registration BU from the MN based on the fact that MN has previously done separate binding registration? Or does it do some form of CoA verification? Regards, Benjamin Lim > > regards, > ryuji > > >> >> >> BR >> >> Desire > > _______________________________________________ > MEXT mailing 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 Dec 17 23:09: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 AE3AB3A6783; Wed, 17 Dec 2008 23:09:58 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55EC43A6783 for ; Wed, 17 Dec 2008 23:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 KUd4eJsUNYpI for ; Wed, 17 Dec 2008 23:09:55 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id D60BF3A6403 for ; Wed, 17 Dec 2008 23:09:54 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LDD0w-0005FA-AF; Thu, 18 Dec 2008 08:09:42 +0100 From: arno@natisbad.org (Arnaud Ebalard) To: Hesham Soliman 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:081217:mext@ietf.org::9jbir4cUtYwQdAEs:00001Nl/ X-Hashcash: 1:20:081217:hesham@elevatemobile.com::slyQRebQ6mhuJgpO:00000000000000000000000000000000000002nNc Date: Wed, 17 Dec 2008 23:07:29 -0800 Message-ID: <87skom2c7i.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] Comments on draft-ietf-mext-nemo-v4traversal-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Hesham, Sorry for the late reply. Some additional comments below and then some text proposals for the draft (w/ a question). Hesham Soliman writes: >>> => I'm trying to make it clear that the document is not inventing this API >>> but inheriting it. In order for anyone to be able to implement this document >>> they need to read 3775/6, 4877 and understand the interactions with IPsec. >>> If people do that, then they *already* know that an API exists. >> >> No. They know that there is a need for tight interactions between >> IPsec/IKE and MIPv6: for bootstrapping, for tunnel endpoint updates, for >> internal IKE daemon structures updates. All they get is a pointer to the >> old MIGRATE draft in 4877 as a possible hint for solving the second point: >> >> Such address changes can be implemented, for instance, through an >> API from the Mobile IPv6 implementation to the IPsec >> implementation. One such API is described in [12]. > > => That's right, and I think that's all that can be done in standards if we > need internal APIs. The IETF typically doesn't standardise APIs, with the > except of the pseudo standard socket API. which includes PF_KEY but I basically agree w/ you. >> Or they do not have additional needs associated w/ the API. > > => Ok, so I gather from these comments that you're only concerned about > clearly identifying the extensions. So if you can go through the security > section and let us know if any of the extensions are not clear that would be > helpful. that would be possible if we had an initial *defined* set of extensions and a specific API. At best, RFC 3775 introduce the need for an API between MIPv6, IKE and the IPsec stack. See my small proposal below. It's probably not perfect but at least this make clear that *work* is required and that it is left as an implementation issue. >>> => There is no guessing in the MN, it's provided the home address as part of >>> the src address selection. If you're talking about running IKE for NAT >>> traversal and securing all traffic then it re-uses the SAs for the home >>> address. >> >> Sorry, but I fail to understand the whole paragraph. What I say is the >> following: when a common Mobile Node negotiates its initial transport >> mode SA (for securing signaling traffic, i.e. BU/BA w/ the HA), it needs >> to perform the IKE negotiation using the CoA. A common IKE >> implementation is not expected to do that (SP uses the HoA, which is >> not available at that time) and need to be modified to support that. One >> possible solution is to have the right address (CoA) provided to the IKE >> daemon by the MIPv6 module. Obviously, you are aware of that. Now what >> are the exact steps on a DSMIPv6-compliant MN using IKE when it starts >> operating in an IPv4-only network? I just reread 6.2.1 and it still >> seems unclear to me how the IKE implementation will decide that it >> should use a V4ADDR and then which V4ADDR it will use. >> >> Does the IKE implementation take the first v4 address available to do >> that? What if it has multiple interfaces with privates IPv4 address? >> >> It is possible I missed some part in the document that explain that >> precisely. > > => You didn't miss it, it's not in the draft. The issue of the "right" CoA > is a policy issue that needs to be addressed by src address selection. If > the MN is multihomed then there must be a number of factors involved in > making this decision, none of them can be attributed to DSMIPv6. Well, the MIPv6 module is usually expected to be the one selecting the CoA so I respectfully disagree w/ you on that point. Once a CoA has been selected (based on some preferences, policies, connectivity price, capabilities, ...), I think failing to let the small number of apps (IKE for instance) that need to use that CoA instead of the HoA is just leaving room for trouble. > Of course once an SA is established, then that information needs to be > passed to MIPv6 in order choose the right CoA. The CoA is selected by the MIPv6 module, before SA are negotiated. Basically, this is the first BU which triggers the negotiation of the SA. IKE has nothing to do with CoA selection. It is just there to negotiate the protection. > The initial choice between a number of CoAs is basically irrelevant to > DSMIPv6. Well, considering what is in section 5.4 of the draft, and more precisely in 5.4.1 ("Selecting a Care-of address"), I disagree. > Do you think DSMIPv6 needs to specify which CoA should be chosen It does, when there are IPv6 and IPv4 addresses available. > and how? I don't think that would fit into the scope of the spec. I don't know. Maybe this is a local matter (based on various policies) but that local matter may become a problem if there is no sync between IKE and MIPv6. Coming back to IKE, MIPv6 is expected to do that for IKE. The problem is introduced in section 1 of RFC 3776: Great care is needed when using IKE [4] to establish security associations to Mobile IPv6 home agents. The right kind of addresses must be used for transporting IKE. This is necessary to avoid circular dependencies in which the use of a Binding Update triggers the need for an IKE exchange that cannot complete prior to the Binding Update having been completed. And later section 5.3.1 of RFC3776 for the negotiation of the SA protecting BU/BA contains this: We require IKE version 1 to be run using the care-of addresses but still negotiate IPsec SAs that use home addresses. Section 4.4 contains: o In addition to the rules above, if dynamic keying is used, the key management protocol MUST use the care-of address as the source address in the protocol exchanges with the mobile node's home agent. Those are also in RFC 4877. > You can make the same argument about a multihomed IPv6 MN and reach > the same conclusion, no? Yes. Exactly. >>> => Because the ideal scenario is to support this mechanism in order to >>> minimise traffic disruption. Therefore, we had to propose this as the >>> default for the HA. The mechanism itself is a SHOULD in the IKE spec. >>> You need to specify a default common to all MNs. Now, if an MN doesn't >>> support it or doesn't care then there is nothing we can do about that. There >>> is no point in mandating something when ignoring that mandate makes a >>> difference to only one side of the protocol and has no impact on the node it >>> communicates with. >> >> It does not seem logical to me. Sorry. It just creates a situation where >> client will undergo traffic disruption with a compliant implementation >> even if the one on the HA support the feature. > > => Yes of course but that can always happen for many features in MIPv6. It > makes no sense to mandate something that, when not followed, has no impact > on interoperability. We need to mandate the support in the HA, so MN's can > assume a certain level of support and therefore interoperable > implementations. If the HA initiated the requests we would have mandated the > support in the MN. Still not convinced, but if I am the only one complaining, I will stop arguing on that. >>>>> => Ok, I'm guessing (because you didn't say) that this is related to the >>>>> API >>>>> concern you have. My point on that is that it's a bit too late to worry >>>>> about it since it's already out there in implementations. >>>> >>>> What can I say: I worked on the API (MIGRATE), made a followup draft >>>> correcting problems found during the implementation, implemented support >>>> for racoon, UMIP, additions for Linux Kernel and helped strongSwan >>>> people during their implementation of my draft. >>> >>> => Ok, so what are you asking me to do? >> >> I don't know. What about taking a look at the draft [1] and see if the >> API can easily be used/extended for some of the needs you have in the >> doc. I let you decide. >> >> [1]: http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00 > > => I'm happy to discuss that with you in a separate thread, but I fail to > see how this will improve the quality of DSMIPv6, which is our highest > priority now. I.e., if, for whatever reason, the changes needed don't fit > into your draft, that will not give me any indication as to how to improve > DSMIPv6. ack. Below is the text proposals for the draft (based on version 07): > 6. Security Considerations > > This specification allows a mobile node to send one binding update > for its IPv6 and IPv4 home addresses. This is a slight deviation > from [RFC3775] which requires one binding update per home address. > However, like [RFC3775], the IPsec security association needed to > authenticate the binding update is still based on the mobile node's > IPv6 home address. Therefore, in order to authorize the mobile > node's IPv4 home address binding, the home agent MUST store the IPv4 > address corresponding to the IPv6 address that is allocated to a > mobile node. Therefore, it is sufficient for the home agent to know > that the IPsec verification for the packet containing the binding > update was valid provided that it knows which IPv4 home address is > associated with which IPv6 home address. Hence, the security of the > IPv4 home address binding is the same as the IPv6 binding. > > In effect, associating the mobile node's IPv4 home address with its > IPv6 home address moves the authorization of the binding update for > the IPv4 address to the Mobile IPv6 implementation, which infers it > from the fact that the mobile node has an IPv6 home address and the > right credentials for sending an authentic binding update for the > IPv6 address. > > This specification requires the use of IKEv2 as the default mechanism > for dynamic keying. Maybe it is just my english but, it reads: "when dynamic keying is used, IKEv2 MUST be used". From previous discussions, I thought the level of requirement to be different and read "DSMIPv6 implementations are required to use IPsec with dynamic keying using IKEv2". > In cases where this specification is used for NAT traversal, it is > important to note that it has the same vulnerabilities associated > with [RFC3519]. An attacker is able to hijack the mobile node's > session with the home agent if it can modify the contents of the > outer IPv4 header. The contents of the header are not authenticated > and there is no way for the home agent to verify their validity. > Hence, a man in the middle attack where a change in the contents of > the IPv4 header can cause a legitimate mobile node's traffic to be > diverted to an illegitimate receiver independently of the > authenticity of the binding update message. > > In this specification, the binding update message MUST be protected > using ESP transport mode. When the mobile node is located in an > IPv4-only network, the binding update message is encapsulated in UDP > as described earlier. However, UDP SHOULD NOT be used to encapsulate > the binding update message when the mobile node is located in an > IPv6-enabled network. If protection of payload traffic is needed > when the mobile node is located in an IPv4-only network, > encapsulation is done using tunnel mode ESP over port 4500 as > described in [RFC3948]. During the IKE negotiation with the home > agent, if the mobile node and home agent support the use of port > 4500, the mobile node MUST establish the security association over > port 4500, regardless of the presence of a NAT. This is done to > avoid the switching between ports 500 and 4500 and the potential > traffic disruption resulting from this switch. > > Handovers within private IPv4 networks or from IPv6 to IPv4 networks > will have impacts on the security association between the mobile node > and the home agent. The following section presents the expected > behaviour of the mobile node and home agent in those situations. The > details of the IKE negotiations and messages are illustrated in > Section 6.2 > > 6.1. Handover Interactions for IPsec and IKE > > After the mobile node detects movement it configures a new care-of > address. If the mobile node is in an IPv4-only network, it removes > binding update list entries for correspondent nodes since route > optimisation cannot be supported. This may cause inbound packet > losses as remote correspondent nodes are unaware of such movement. > To avoid confusion in the correspondent node, the mobile node SHOULD > deregister its binding with each correspondent node by sending a > deregistration binding update. The deregistration binding update > message is tunnelled to the home agent and onto the correspondent > node. This is done after the mobile node updates the home agent with > its new location as discussed below. > > The mobile node sends the binding update message to the home agent. > If the mobile node is in an IPv6-enabled network, the binding update > is sent without IPv4/UDP encapsulation. If the mobile node is in an > IPv4-only network, then after IPsec processing of the BU message, it > encapsulates the BU in UDP/IPv4 as discussed in sections 5.2 and 5.4. > In order to be able to send the binding update while in an IPv4-only > network, the mobile node needs to use the new IPv4 care-of address in > the outer header, which is different from the care-of address used in > the existing tunnel. This should be done without permanently > updating the tunnel within the mobile node's implementation in order > to allow the mobile node to receive packets on the old care-of > address until the binding acknowledgement is received. The method > used to achieve this effect is implementation dependent and is > outside the scope of this specification. This implies that the IP > forwarding function (which selects the interface or tunnel through > which a packet is sent) is not based solely on the destination > address: some IPv6 packets destined to the home agent are sent via > the existing tunnel, while BUs are sent using the new care-of > address. Since BUs are protected by IPsec, the forwarding function > cannot necessarily determine the correct treatment from the packet > headers. Thus, the DSMIPv6 implementation has to attach additional > information to BUs, and this information has to be preserved after > IPsec processing and made available to the forwarding function, or > additional DSMIP processing added to the forwarding function. > Depending on the mobile node's implementation, meeting this > requirement may require changes to the IPsec implementation. > > Upon receiving the binding update message encapsulated in UDP/IPv4, > the home agent processes it as follows. In order to allow the > DSMIPv6 implementation in the home agent to detect the presence of a > NAT on the path to the mobile node, it needs to compare the outer > IPv4 source address with the IPv4 address in the IPv4 care-of address > option. This implies that the information in the outer header will > be preserved after IPsec processing and made available to the DSMIPv6 > implementation in the home agent. Depending on the home agent's > implementation, meeting this requirement may require changes to the > IPsec implementation. > > The home agent updates its tunnel mode security association to > include the mobile node's care-of address as the remote tunnel header > address, and 4500 as the port number. The IPv4 address and port > number are likely to be wrong; the mobile node provides the correct > information in a separate exchange as described below. When the > mobile node is located in a private IPv4 network (which is detected > as described above), the new address and port number are allocated by > the NAT. The home agent will also enable or disable UDP > encapsulation for outgoing ESP packets for the purpose of NAT > traversal. > > If the Key Management Mobility Capability (K) bit was set in the > binding update, and the home agent supports this feature, the home > agent updates its IKE security associations to include the mobile > node's care-of address as the peer address and 4500 as the port > number. The home agent may also need to change NAT traversal fields > in the IKE_SA to enable the dynamic update of the IP address and port > number based on the reception of authenticated IKE messages, or > authenticated packets using tunnel mode ESP. The dynamic updates are > described in section 2.23 of RFC 4306. As described above, when the > mobile node is located in a private IPv4 network, the address and > port number used for IPsec and IKE traffic is not yet known by the > home agent at this point. > > The mobile node updates the IKE SA in one of two ways. If the K flag > was set in the binding acknowledgement message, the mobile node > SHOULD send an empty informational message, which results in the IKE > module in the home agent to dynamically update the SA information. > The IKE implementation in the home agent is REQUIRED to support this > feature. Alternatively, the IKE SA should be re-negotiated. Note > that updating the IKE SA MUST take place after the mobile node has > sent the binding update and received the acknowledgement from the > home agent. > > It is important to note that the mobile node's IPv4 care-of address > seen by the DSMIPv6 module in the home agent upon receiving the > binding update may differ from the IPv4 care-of address seen by the > IKE module and the care-of address used for forwarding IPsec tunnel > mode traffic. Hence, it is probable that different modules in the > home agent will have a different care-of address that should be used > for encapsulating traffic to the mobile node. > > After successfully processing the binding update, the home agent > sends the binding acknowledgement to the mobile node's care-of > address as received in the outer header of the packet containing the > binding update. Note that if the BU was rejected, the BAck is sent > to the same address where the BU was received from. This may require > special treatment in IP forwarding and/or IPsec processing which > resembles sending of BUs in the mobile node (described above). > > Upon receiving the binding acknowledgement, the mobile node updates > its local tunnel mode Security Association information to include the > tunnel header IP source address, which is the mobile node's address > and the tunnel header IP destination, which is the home agent's > address. The mobile node may also need to enable or disable UDP > encapsulation for outgoing ESP packets for the purpose of NAT > traversal and the sending of keep alives. > > The mobile node MAY use [RFC4555] to update its IKE SA with the home > agent. Using MOBIKE requires negotiating this capability with the > home agent when establishing the SA. In this case, the mobile node > and the home agent MUST NOT update their IPsec SAs locally as this > step is performed by MOBIKE. Furthermore, the use of MOBIKE allows > the mobile node to update the SA independently of the binding update > exchange. Hence, there is no need for the mobile node to wait for a > binding acknowledgement before performing MOBIKE. The use of MOBIKE > is OPTIONAL in this specification. What about inserting the following text here ?: "Note that providing the features described in this subsection is expected to require very tight interactions between MIPv6 and IKE. It may require substantial extensions of the API expected by [RFC3775] to be in place between the MIPv6 module, the IPsec stack and the IKE daemon. This possible extensions (and the expected level of interactions with the features provided by the IKE module) are outside the scope of this specification and are left as implementation dependent issues." Note that I first inserted small disclaimers w/ specific comments at various places in the subsection but this made the whole thing more difficult to read w/o providing any additional interest. I dropped that for a single more generic block. If you think previous text proposal should be extended in some way, just tell me. Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 17 23:10: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 3A6A728C1E8; Wed, 17 Dec 2008 23:10:29 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBDCA28C1E8 for ; Wed, 17 Dec 2008 23:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 4YHF22Raovnh for ; Wed, 17 Dec 2008 23:10:27 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id EF2D228C17C for ; Wed, 17 Dec 2008 23:10:26 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LDD1S-0005FI-1Q; Thu, 18 Dec 2008 08:10:14 +0100 X-Hashcash: 1:20:081218:mext@ietf.org::ilWNsG/Je+bVVCW9:000081fZ From: arno@natisbad.org (Arnaud Ebalard) To: IETF MEXT WG ML References: <200812151644.31817.julien.laganier.IETF@googlemail.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:081217:anand.bedekar@motorola.com::qTWkUvSLeeQzvIf/:000000000000000000000000000000000000NKf X-Hashcash: 1:20:081217:brian.haley@hp.com::diNr66bZHHDGdmKG:00000000000000000000000000000000000000000000WEg X-Hashcash: 1:20:081217:marcelo@it.uc3m.es::LJ9NQMi34OVTsNA7:00000000000000000000000000000000000000000000ybX X-Hashcash: 1:20:081217:tsirtsis@qualcomm.com::vzxbwxW1kzdqZOyh:00000000000000000000000000000000000000001cT3 X-Hashcash: 1:20:081217:jouni.korhonen@iki.fi::yjl8PCWOx6toU9kd:00000000000000000000000000000000000000001zPN X-Hashcash: 1:20:081217:julien.laganier.ietf@googlemail.com::bYKL4d8p+U+yKlO0:000000000000000000000000002d10 X-Hashcash: 1:20:081217:kleung@cisco.com::YlcR1qsOudUmFh3K:02nke Date: Wed, 17 Dec 2008 23:08:01 -0800 Message-ID: <87ljue2c6m.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: Julien Laganier Subject: Re: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, I have reviewed draft-ietf-mext-binding-revocation-02. My comments are below. Note that I did not covered parts related to PMIPv6 (RFC5213). > 3.2. Client MIPv6 and DSMIP6 Use Case > > Binding revocation mechanism is applicable to Client Mobile IPv6 and > DSMIPv6 session(s) when the home agent needs to inform the mobile > node that its binding registration has been revoked, e.g. for an > administrative reason. This mechanism enables the home domain to > dynamically allow the user to act upon the revocation message in > order to not have an unexpectedly interrupted mobile IPv6 services. Well, when it receives the information, it's already too late, isn't it? > 3.4. Proxy MIPv6 Use Case > > Since the Mobile node does not participate in the mobility mechanism > in the case of PMIPv6, there are many scenarios where Binding > Revocation mechanism is needed to clean resources and make sure that > the mobility entities, e.g. MAG and LMA, are always synchronized > with respect to the status of the existing proxy mobile IPv6 > bindings. The binding revocation mechanism is generic enough that > can be used in all applicable PMIPv6 scenarios and deployment ^^^^^^^^^^^ ^^^^ "so that it can be" or "to be used" > 4. Security Model > > The binding revocation protocol described here uses the same security > association between the MN and the HA or the MAG and the LMA that has > been used to exchange the corresponding Client MIPv6 or Proxy MIPv6 > BU and BA when the mobile node binding was created. If IPsec is > used, the SPD of the respected IPsec SA MUST allow the Binding > Revocation Signaling MH type in order to allow BRI and BRA > messages to be exchanged. What about replacing last sentence by following text: "If IPsec is used, the traffic selectors associated with the SP protecting BU and BA MUST be extended to include Binding Revocation Signaling MH type ." What about also including some rationale for this choice, w/ sth like the following ? : "Extending the traffic selectors of the SP in order to reuse the SA protecting BU and BA (instead of creating new ones) provides the insurance that those SA will be up and running when the revoking entity will need to send a Binding Revocation Signaling message". If you decide to keep current text, "respected" should be replaced by "respective", IMO. Last question on that paragraph: The last sentence start with "If". Why? I mean, this is mandated by 3775. Is it for PMIPv6? > 6. Binding Revocation Message > > This section defines a Binding Revocation Message that use a MH type > with a Binding Revocation type field that follow the MH > format described in section 6.1. [RFC3775]. The value in the ^^^^^^^^^^^^^^^^ 6.1 of [RFC3775] or just 6.1? > 6.1. Binding Revocation Indication Message > > The Binding Revocation Indication (BRI) message is a Binding > Revocation Message which has a MH type and a Binding > Revocation Type value of 1. It is used by the revoking mobility node > to inform the receiving mobility entity that the IP mobility service > of a specific binding or bindings have been revoked. Binding > Revocation Indication message is sent as described in Section 8.1, > Section 9.1.1, and Section 10.2.1. > > When the value 1 is indicated in the B. R. type field of the Binding > Revocation Message, the format of the Binding Revocation Message Data > follows the Binding Revocation Indication message as in Figure 5 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | B.R. Type = 1 | R. Trigger | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # |P|A|G| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Mobility options . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > Figure 5: Binding Revocation Indication Message > > > Revocation Trigger > > 8-bit unsigned integer indicting the event which triggered the ^^^^^^^^^^ indicating > 6.2. Binding Revocation Acknowledgement Message > > The Binding Revocation Acknowledgement (BRA) message is a Binding > Revocation Message which has a MH type and a Binding > Revocation Type value of 2. It is used to acknowledge the receipt of > a Binding Revocation Indication message described in Section 6.1. > This packet is sent as described in Section 9.2.2, Section 10.1.2, > and Section 11.2. > > When the value 2 is indicated in the Binding Revocation type field of > the Binding Revocation Message, the format of the Binding Revocation > Message Data follows the Binding Revocation Acknowledgement message > as in Figure 6 > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | B.R. Type = 2 | Status | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # |P|G| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Mobility options . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 6: Binding Revocation Acknowledgement Message > > > Status > > 8-bit unsigned integer indicating the result of processing the > Binding Revocation Indication message by the receiving mobility > entity. The following status values are currently defined. > > 0 success. > 1 partial success. > 2 Binding Does NOT Exist. > 3 IPv4 HoA Binding Does NOT Exist. > 4 Global Revocation NOT Authorized. > 5 CAN NOT Identify Binding. > 6 Revocation Failed, MN is Attached. The Binding Revocation Trigger values in Section 6.1 look more self-explanatory. They are also mainly informational, right? Here, it is not clear what "partial success" (1) or "Revocation failed, MN is attached" mean, and what both entities should expect when those are sent. Maybe the rationale that were associated with those values when the list was first created should be included in the document, along with the expected behaviors (Are those status value just informational?) Or did I missed some other section that provides that in the draft? > 8. Home Agent Operation > > 8.1. Sending Binding Revocation Indication > > When an event requires the home agent to terminate a mobile node > mobile IPv6 registration, e.g. for administrative reason, the home > agent sends a Binding Revocation Indication message to the mobile > node to inform the mobile node that its specified binding has been > revoked and it will no longer be able to receive an IP connectivity > via its binding with the home agent. > > To terminate a mobile node registration and its current binding with > the home agent, the home agent sends a packet to the mobile node > containing a Binding Revocation Indication, with the packet > constructed as follows: > > o The Acknowledge (A) bit MAY be set in the BRI to request the > mobile node to send a Binding Revocation Acknowledgement upon > receipt of the BRI. > > > > > > Muhanna, et al. Expires May 29, 2009 [Page 18] > > Internet-Draft Binding Revocation for IPv6 Mobility November 2008 > > > o The Revocation Trigger field MUST be set in the Binding Revocation > Indication to indicate to the mobile node the reason for revoking > its IP mobility binding with the home agent. The Revocation > Trigger may be used by the mobile node to take further steps if > necessary. > > o The Binding Revocation Indication MUST be sent using a type 2 > routing header which contains the mobile node's registered home > address for the binding being revoked. > > o The care-of address for the binding MUST be used as the > destination address in the packet's IPv6 header, unless an > Alternate Care-of Address mobility option is included in the > Binding Revocation Indication. > > o The packet MAY contain an IPv4 Home Address option which contains > the mobile node's registered IPv4 home address for the binding > being revoked. > > > The Acknowledge (A) bit in the Binding Revocation Indication requests > the mobile node to return a Binding Revocation Acknowledgement in > response to this Binding Revocation Indication. As described in > Section 7.3, the home agent SHOULD retransmit this Binding Revocation > Indication to the mobile node before terminating its IP connection > until it receives a matching Binding Revocation Acknowledgement or > the BRIMaxRetransmitNumber has been reached. > > When the home agent send a BRI to the mobile node with the (A) bit is ^^^^ sends > set, the home agent sets a flag in the mobile node BCE to indicate > that revocation is in progress and starts the MINDelayBRIs timer. > The home agent maintains the mobile node BCE in this state until it > receives a Binding Revocation Acknowledgement or the > BRIMaxRetransmitNumber is reached. What does "maintains the node BCE in this sate"? I mean, does this mean that the mobile node is not able to perform movement during that time? If the revoking entity sends a BRI just when the mobile node perform a handover (i.e. sends a BU), then locking the BCE state will prevent the CoA update to happen on the revoking entity and the retransmitted packets to be sent to the MN. > 9. Local Mobility Anchor Operation not reviewed. > 10. Mobile Access Gateway Operation nott reviewed. > 11. Mobile Node Operation > > 11.1. Receiving Binding Revocation Indication > > Upon receiving a packet carrying a Binding Revocation Indication, the > mobile node MUST validate the packet according to Section 7.2 and the > following tests: > > o The mobile node MUST verify that the IP address in the type 2 > routing header is its Home Address. > > o If the Acknowledgement (A) bit is set in the Binding Revocation > Indication and the MN has the BCE in registered state, the mobile > node MUST send a Binding Revocation Acknowledgement. However, in > all other cases when the (A) bit is set in the BRI, the mobile > node SHOULD send a Binding Revocation Acknowledgement. In all > cases, the mobile node MUST follow Section 11.2 when send a BRA > using the appropriate status code. ^^^^^^^^^^ and send > 11.2. Sending Binding Revocation Acknowledgement > > When the mobile node receive a valid Binding Revocation Indication ^^^^^^^ receives > with the (A) bit is set from its home agent and while having this > BCE ^^ to be removed General comment: in the draft, the few times "Type 2 Header" is used, it should probably be replaced by "Type 2 Routing Header" for consistency. Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 18 01:46: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 F1E9F3A69C9; Thu, 18 Dec 2008 01:46:58 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DF3728C1B8 for ; Thu, 18 Dec 2008 01:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[AWL=0.348, 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 h1MfDod8PSUq for ; Thu, 18 Dec 2008 01:46:56 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id B5C623A6876 for ; Thu, 18 Dec 2008 01:46:56 -0800 (PST) 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 mBI9oZkb009031; Thu, 18 Dec 2008 03:50:38 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Dec 2008 03:46:45 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Dec 2008 04:46:43 -0500 Message-ID: In-Reply-To: <4949F309.40305@sg.panasonic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Bulk Binding Refresh or Deregistration after Separate Binding Registration in MCoA Thread-Index: Aclg3TwWb3vEJfLzQ8e/bj9BPJpPqgAF6wGg References: <4949F309.40305@sg.panasonic.com> From: "Desire Oulai" To: "Benjamin Lim" , "Ryuji Wakikawa" X-OriginalArrivalTime: 18 Dec 2008 09:46:45.0375 (UTC) FILETIME=[89E8A8F0:01C960F5] Cc: mext@ietf.org Subject: Re: [MEXT] Bulk Binding Refresh or Deregistration after Separate Binding Registration in MCoA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Benjamin, If initial bindings are done by separate registration, we can assume that CoA verification is done as each BU as the corresponding CoA as source address. Therefore, the MN can perform bulk re-registration or deregistration. Ruyji, should we have some text related to this in the draft? BR Desire > -----Original Message----- > From: Benjamin Lim [mailto:benjamin.limck@sg.panasonic.com] > Sent: December 18, 2008 1:52 AM > To: Ryuji Wakikawa > Cc: Desire Oulai; mext@ietf.org > Subject: Re: [MEXT] Bulk Binding Refresh or Deregistration > after Separate Binding Registration in MCoA > > Hi Ryuji, > > Ryuji Wakikawa wrote: > >> However, is it possible for a MN to do separate binding > registration > >> then do bulk binding refresh or bulk deregistration? > > > > Yes, MN can switch to bulk registration after the separate > registration. > [Ben] So does the HA accept this bulk registration BU from > the MN based on the fact that MN has previously done separate > binding registration? > Or does it do some form of CoA verification? > > Regards, > Benjamin Lim > > > > > regards, > > ryuji > > > > > >> > >> > >> BR > >> > >> Desire > > > > _______________________________________________ > > MEXT mailing 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 m.adelaidesilvapereira-7011p@adv.oa.pt Thu Dec 18 04:36:10 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5551A3A68D4 for ; Thu, 18 Dec 2008 04:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.556 X-Spam-Level: X-Spam-Status: No, score=-1.556 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmNNpg7XSEgZ for ; Thu, 18 Dec 2008 04:36:10 -0800 (PST) Received: from 4sportscards.com (unknown [94.178.27.161]) by core3.amsl.com (Postfix) with SMTP id 6854D3A6844 for ; Thu, 18 Dec 2008 04:36:07 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081218123608.6854D3A6844@core3.amsl.com> Date: Thu, 18 Dec 2008 04:36:07 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mext-bounces@ietf.org Thu Dec 18 07:19: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 A64A43A69EE; Thu, 18 Dec 2008 07:19:21 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 867A13A69EE for ; Thu, 18 Dec 2008 07:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[AWL=0.365, 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 U8184y0+IJ2f for ; Thu, 18 Dec 2008 07:19:18 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 840BC3A67F9 for ; Thu, 18 Dec 2008 07:19:18 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mBIFJ6c26312; Thu, 18 Dec 2008 15:19:06 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Dec 2008 09:19:02 -0600 Message-ID: In-Reply-To: <87ljue2c6m.fsf@natisbad.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02 Thread-Index: Aclg37UHct+dctA+Qjat2gfIdbxE2gAORLCw References: <200812151644.31817.julien.laganier.IETF@googlemail.com> <87ljue2c6m.fsf@natisbad.org> From: "Ahmad Muhanna" To: "Arnaud Ebalard" , "IETF MEXT WG ML" Cc: Julien Laganier Subject: Re: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Arnaud, Thanks for the review, please see responses inline. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Arnaud Ebalard > Sent: Thursday, December 18, 2008 1:08 AM > To: IETF MEXT WG ML > Cc: Julien Laganier > Subject: Re: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02 > > Hi, > > I have reviewed draft-ietf-mext-binding-revocation-02. My > comments are below. Note that I did not covered parts related > to PMIPv6 (RFC5213). > > > 3.2. Client MIPv6 and DSMIP6 Use Case > > > > Binding revocation mechanism is applicable to Client > Mobile IPv6 and > > DSMIPv6 session(s) when the home agent needs to inform the mobile > > node that its binding registration has been revoked, e.g. for an > > administrative reason. This mechanism enables the home domain to > > dynamically allow the user to act upon the revocation message in > > order to not have an unexpectedly interrupted mobile > IPv6 services. > > Well, when it receives the information, it's already too > late, isn't it? [Ahmad] What is meant here, the MN will have an instant but graceful indication that its mobility service is being revoked. At that time, the MN will be able to make an out of scope communication to check/enable/etc. the service with its provider, for example. This case is meant to replace/"be compared" the case when the HA deletes the binding and the tunnel without informing the MN. > > > > 3.4. Proxy MIPv6 Use Case > > > > Since the Mobile node does not participate in the > mobility mechanism > > in the case of PMIPv6, there are many scenarios where Binding > > Revocation mechanism is needed to clean resources and > make sure that > > the mobility entities, e.g. MAG and LMA, are always synchronized > > with respect to the status of the existing proxy mobile IPv6 > > bindings. The binding revocation mechanism is generic > enough that > > can be used in all applicable PMIPv6 scenarios and deployment > > ^^^^^^^^^^^ > ^^^^ > > "so that it can be" or "to be used" [Ahmad] I do not see any normative text here but, I think "can be used" is used to give more flexibility; but changing the text to "to be used" is fine with me if necessary. > > > 4. Security Model > > > > The binding revocation protocol described here uses the > same security > > association between the MN and the HA or the MAG and the > LMA that has > > been used to exchange the corresponding Client MIPv6 or > Proxy MIPv6 > > BU and BA when the mobile node binding was created. If IPsec is > > used, the SPD of the respected IPsec SA MUST allow the Binding > > Revocation Signaling MH type in order to > allow BRI and BRA > > messages to be exchanged. > > What about replacing last sentence by following text: > > "If IPsec is used, the traffic selectors associated with the SP > protecting BU and BA MUST be extended to include Binding > Revocation > Signaling MH type ." [Ahmad] Looks good to me. > > What about also including some rationale for this choice, w/ sth > like the following ? : > > "Extending the traffic selectors of the SP in order to > reuse the SA > protecting BU and BA (instead of creating new ones) provides the > insurance that those SA will be up and running when the revoking > entity will need to send a Binding Revocation Signaling message". > [Ahmad] This is good to me too. However, I would make a minor change: replace "provides insurance" with "ensures" and "will need" to "needs" The suggested text would read as follows: "Extending the traffic selectors of the SP in order to reuse the SA protecting BU and BA (instead of creating new ones) ensures that those SA will be up and running when the revoking entity needs to send a Binding Revocation Signaling message". > If you decide to keep current text, "respected" should > be replaced > by "respective", IMO. > > Last question on that paragraph: The last sentence start with > "If". Why? I mean, this is mandated by 3775. Is it for PMIPv6? > > > 6. Binding Revocation Message > > > > This section defines a Binding Revocation Message that > use a MH type > > with a Binding Revocation type field that > follow the MH > > format described in section 6.1. [RFC3775]. The value in the > > ^^^^^^^^^^^^^^^^ > 6.1 of [RFC3775] or just 6.1? > [Ahmad] Sure we can reference [RFC3775]. > > > 6.1. Binding Revocation Indication Message > > > > The Binding Revocation Indication (BRI) message is a Binding > > Revocation Message which has a MH type and a Binding > > Revocation Type value of 1. It is used by the revoking > mobility node > > to inform the receiving mobility entity that the IP > mobility service > > of a specific binding or bindings have been revoked. Binding > > Revocation Indication message is sent as described in > Section 8.1, > > Section 9.1.1, and Section 10.2.1. > > > > When the value 1 is indicated in the B. R. type field of > the Binding > > Revocation Message, the format of the Binding Revocation > Message Data > > follows the Binding Revocation Indication message as in Figure 5 > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | B.R. Type = 1 | > R. Trigger | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Sequence # |P|A|G| > Reserved | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > | > > . > . > > . Mobility options > . > > | > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > Figure 5: Binding Revocation Indication Message > > > > > > Revocation Trigger > > > > 8-bit unsigned integer indicting the event which triggered the > > ^^^^^^^^^^ > indicating [Ahmad] Ok. Thx. > > > 6.2. Binding Revocation Acknowledgement Message > > > > The Binding Revocation Acknowledgement (BRA) message is a Binding > > Revocation Message which has a MH type and a Binding > > Revocation Type value of 2. It is used to acknowledge > the receipt of > > a Binding Revocation Indication message described in Section 6.1. > > This packet is sent as described in Section 9.2.2, > Section 10.1.2, > > and Section 11.2. > > > > When the value 2 is indicated in the Binding Revocation > type field of > > the Binding Revocation Message, the format of the > Binding Revocation > > Message Data follows the Binding Revocation > Acknowledgement message > > as in Figure 6 > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | B.R. Type = 2 | > Status | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Sequence # |P|G| > Reserved | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > | > > . > . > > . Mobility options > . > > . > . > > | > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > Figure 6: Binding Revocation Acknowledgement Message > > > > > > Status > > > > 8-bit unsigned integer indicating the result of processing the > > Binding Revocation Indication message by the > receiving mobility > > entity. The following status values are currently defined. > > > > 0 success. > > 1 partial success. > > 2 Binding Does NOT Exist. > > 3 IPv4 HoA Binding Does NOT Exist. > > 4 Global Revocation NOT Authorized. > > 5 CAN NOT Identify Binding. > > 6 Revocation Failed, MN is Attached. > > The Binding Revocation Trigger values in Section 6.1 look > more self-explanatory. They are also mainly informational, right? [Ahmad] Yes, it is mainly informational. However, whenever any R. Trigger value means a specific action is needed on the side of the receiving mobility node, IMO, it needs to be documented. If we missed any of these, we can go back and do it. > > Here, it is not clear what "partial success" (1) or > "Revocation failed, MN is attached" mean, and what both > entities should expect when those are sent. Maybe the > rationale that were associated with those values when the > list was first created should be included in the document, > along with the expected behaviors (Are those status value just > informational?) > > Or did I missed some other section that provides that in the draft? [Ahmad] I agree it is mainly informational but some of these status is appropriate with certain scenarios. I believe those status values meanings and use are mentioned when these specific scenario are discussed later on. > > > 8. Home Agent Operation > > > > 8.1. Sending Binding Revocation Indication > > > > When an event requires the home agent to terminate a mobile node > > mobile IPv6 registration, e.g. for administrative > reason, the home > > agent sends a Binding Revocation Indication message to the mobile > > node to inform the mobile node that its specified > binding has been > > revoked and it will no longer be able to receive an IP > connectivity > > via its binding with the home agent. > > > > To terminate a mobile node registration and its current > binding with > > the home agent, the home agent sends a packet to the mobile node > > containing a Binding Revocation Indication, with the packet > > constructed as follows: > > > > o The Acknowledge (A) bit MAY be set in the BRI to request the > > mobile node to send a Binding Revocation Acknowledgement upon > > receipt of the BRI. > > > > > > > > > > > > Muhanna, et al. Expires May 29, 2009 > [Page 18] > > > > > Internet-Draft Binding Revocation for IPv6 Mobility > November 2008 > > > > > > o The Revocation Trigger field MUST be set in the > Binding Revocation > > Indication to indicate to the mobile node the reason > for revoking > > its IP mobility binding with the home agent. The Revocation > > Trigger may be used by the mobile node to take > further steps if > > necessary. > > > > o The Binding Revocation Indication MUST be sent using a type 2 > > routing header which contains the mobile node's > registered home > > address for the binding being revoked. > > > > o The care-of address for the binding MUST be used as the > > destination address in the packet's IPv6 header, unless an > > Alternate Care-of Address mobility option is included in the > > Binding Revocation Indication. > > > > o The packet MAY contain an IPv4 Home Address option > which contains > > the mobile node's registered IPv4 home address for the binding > > being revoked. > > > > > > The Acknowledge (A) bit in the Binding Revocation > Indication requests > > the mobile node to return a Binding Revocation Acknowledgement in > > response to this Binding Revocation Indication. As described in > > Section 7.3, the home agent SHOULD retransmit this > Binding Revocation > > Indication to the mobile node before terminating its IP > connection > > until it receives a matching Binding Revocation > Acknowledgement or > > the BRIMaxRetransmitNumber has been reached. > > > > When the home agent send a BRI to the mobile node with > the (A) bit > > is > > ^^^^ > sends [Ahmad] Ok. Thx. > > > set, the home agent sets a flag in the mobile node BCE > to indicate > > that revocation is in progress and starts the MINDelayBRIs timer. > > The home agent maintains the mobile node BCE in this > state until it > > receives a Binding Revocation Acknowledgement or the > > BRIMaxRetransmitNumber is reached. > > What does "maintains the node BCE in this sate"? I mean, does > this mean that the mobile node is not able to perform > movement during that time? [Ahmad] We are talking about a race condition here which should be addressed based on the reason of the BRI and HA local policy. If the MN registration is being revoked for administrative reason, for example, then, IMO, it does not make sense to allow the mobile node to move anyway. > If the revoking entity sends a BRI just when the mobile node > perform a handover (i.e. sends a BU), then locking the BCE > state will prevent the CoA update to happen on the revoking > entity and the retransmitted packets to be sent to the MN. [Ahmad] The revocation in progress flag is set until the HA receives a BRA or the BRIMaxRetransmitNumber expires. We could add some text to address this race condition and mention what the HA may do when this race condition occurs. " In a race condition case, the home agent may receive a BU from the mobile node while the mobile node's BCE has the revocation in progress flag set, the home agent should handle this case based on the reason for sending the Binding Revocation Indication message and its local policy. In this case, If the home agent accepts the BU, it needs to update the mobile node BCE accordingly, e.g. removing the revocation in progress flag. " > > > 9. Local Mobility Anchor Operation > > not reviewed. > > > 10. Mobile Access Gateway Operation > > nott reviewed. > > > 11. Mobile Node Operation > > > > 11.1. Receiving Binding Revocation Indication > > > > Upon receiving a packet carrying a Binding Revocation > Indication, the > > mobile node MUST validate the packet according to > Section 7.2 and the > > following tests: > > > > o The mobile node MUST verify that the IP address in the type 2 > > routing header is its Home Address. > > > > o If the Acknowledgement (A) bit is set in the Binding > Revocation > > Indication and the MN has the BCE in registered > state, the mobile > > node MUST send a Binding Revocation Acknowledgement. > However, in > > all other cases when the (A) bit is set in the BRI, the mobile > > node SHOULD send a Binding Revocation Acknowledgement. In all > > cases, the mobile node MUST follow Section 11.2 when > send a BRA > > using the appropriate status code. > ^^^^^^^^^^ > and send [Ahmad] Yes. Thx. > > 11.2. Sending Binding Revocation Acknowledgement > > > > When the mobile node receive a valid Binding Revocation > Indication > > ^^^^^^^ > receives [Ahmad] Ok. > > > with the (A) bit is set from its home agent and while having this > > BCE > > ^^ > to be removed [Ahmad] Ok. > > > > General comment: in the draft, the few times "Type 2 Header" > is used, it should probably be replaced by "Type 2 Routing > Header" for consistency. [Ahmad] Sure. > > Cheers, > > a+ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 18 07:20: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 36F4428C234; Thu, 18 Dec 2008 07:20:12 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62FC728C234 for ; Thu, 18 Dec 2008 07:20:11 -0800 (PST) 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, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=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 nP5mbVV1Mvm6 for ; Thu, 18 Dec 2008 07:20:10 -0800 (PST) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id 66AE728C0ED for ; Thu, 18 Dec 2008 07:20:09 -0800 (PST) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id mBIFJq7j014276; Thu, 18 Dec 2008 16:19:52 +0100 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 mBIFJpAM032334; Thu, 18 Dec 2008 16:19:51 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Dec 2008 16:19:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Dec 2008 16:19:49 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD6804B2B6AD@zagh223a.ww300.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Removing bindings for IPv4 only - please comment Thread-Index: AclcIrfbppqowVDjTEy3HFmjbORgHQAC7YeQAAn3hrsAA5HPwAAB3yfLAIq2CbAAAaeFlAChNbng References: From: "Premec, Domagoj" To: "Hesham Soliman" , , X-OriginalArrivalTime: 18 Dec 2008 15:19:51.0093 (UTC) FILETIME=[12533650:01C96124] 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::081218161952-0B9D9BA0-7BCE9158/0-0/0-15 X-purgate-size: 10568/0 Cc: jari.arkko@piuha.net, julien.laganier.ietf@googlemail.com Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, > > (a) an IPv6-only home link continuing IPv4 communication, and > > => You can't deregister the IPv6 home address and maintain > any type of SA > with the HA. I.e. no v6HoA = no binding. I thought that it is possible for the MN to have the SA with the HA even when there is no MIP binding. Suppose MN boots up on an IPv6 link and it doesn't know its home link prefix. It establishes the IKEv2 SA with the HA and learns the home network prefix as part of the SA establishment. The MN now compares the MIP6 home prefix attribute with its on link prefix and detects it is on the home link. Being on the home link, the MN doesn't send any BU, but the SA remains valid and can be used anytime to send MIP messages, right? domagoj > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Hesham Soliman > Sent: 15. prosinac 2008 11:12 > To: Christian.Kaas-Petersen@tieto.com; mext@ietf.org > Cc: julien.laganier.ietf@googlemail.com; jari.arkko@piuha.net > Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment > > > > Thanks for the response. Just a detail: The binding update > > specified in your response, is that with or without the UDP > > header using DSMIP ports? > > => Yes of course with UDP, it's always in UDP when the MN is > in an IPv4 > network. > > > > > I agree the mobile node could equally > > well move to an IPv4 foreign link, and in that case the home > > agent would have the bindings > > > > (1') v6HoA -> v4CoA > > (2') v4HoA -> v4CoA > > > > just the binding update would be different, namely > > > > BU > > IPv4 Header src = v4CoA > > UDP Header with DSMIP ports > > IPv6 Header src = v6HoA > > lifetime > 0 > > IPv4 Home Address v4HoA > > IPv4 Care-of Address v4CoA > > > > So, going back to the original mail, Karens original suggestion > > was a way to handle both of the two situations: > > > > (a) an IPv6-only home link continuing IPv4 communication, and > > => You can't deregister the IPv6 home address and maintain > any type of SA > with the HA. I.e. no v6HoA = no binding. > > > (b) an IPv4-only home link continuing IPv6 communication. > > => That's the text I sent. > > > > > (b) is now part of DSMIP, while (a) should be dealt with in > > draft-premec-mext-extended-home-link. > > > > In a sense, in case (b) the IPv4-only home link is treated like > > any other IPv4-only foreign link. Suppose IPv6 payload traffic is > > IPsec protected between v4CoA and v4HA. Is the IPv4-only home > > link really like a truly foreign link so IPsec protection should > > be used, or is the IPv4-only home more like a home > > link where IPv6 payload traffic is not IPsec protected, thus only > > IPv6-in-IPv4 tunnel encapsulation is to be used? > > => There is no correlation between the home link and IPsec. > You can protect > IPv6 traffic with IPsec anywhere. I assume you want to only > protect it to > the HA, which would be fine in the scenario above because it > thinks it's not > home anyway. > > Hesham > > > > > Christian > > > > > >> -----Original Message----- > >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] > >> Sent: 12. december 2008 16:13 > >> To: Kaas-Petersen Christian; mext@ietf.org > >> Cc: jari.arkko@piuha.net; julien.laganier.ietf@googlemail.com > >> Subject: Re: [MEXT] Removing bindings for IPv4 only - > please comment > >> > >> > >> > >> > >>> I understood the text as a useful clarification. I > >> understood it this > >>> way. When a mobile node moves to an IPv6 foreign network, > >> and there > >>> obtains the v6CoA address, it sends a binding update > >>> > >>> BU > >>> src = v6CoA > >>> Destination Option with v6HoA > >>> lifetime > 0 > >>> Alternate Care-of Address v6CoA > >>> IPv4 Home Address v4HoA > >>> > >>> to the home agent, and the home agent will in its binding > >> cache insert > >>> two entries > >>> > >>> (1) v6HoA -> v6CoA > >>> (2) v4HoA -> v6CoA > >> > >> => That's the current draft yes. I'm not sure why you're > >> referring to IPv6 foreign networks only. The same applies to > >> IPv4 networks. > >> > >>> > >>> The clarification to me was then, that the mobile node, > >> while at this > >>> foreign IPv6 network, could ask the home agent to remove > >> both of the > >>> bindings by sending > >>> > >>> BU > >>> src = v6CoA > >>> Destination Option with v6HoA > >>> lifetime = 0 > >>> > >>> or could ask the home agent to remove the IPv4 binding > >> (retaining the > >>> IPv6 binding) by sending > >>> > >>> BU > >>> src = v6CoA > >>> Destination Option with v6HoA > >>> lifetime > 0 > >>> Alternate Care-of Address v6CoA > >> > >> > >>> > >>> I'll go back to the situation where the binding cache has > >> entries (1) > >>> and (2). If the mobile node moves to an IPv6-only link > >> where it gets > >>> only the v6HoA address, and wants to continue using > v4HoA, then the > >>> home agent's binding cache should be provided with the entry > >>> > >>> (a) v4HoA -> v6HoA > >> > >> => This wasn't part of the text I sent. > >> > >>> > >>> Or the other situation, the mobile node moves to an IPv4-only link > >>> getting only v4HoA, the binding cache should be provided with the > >>> entry > >>> > >>> (b) v6HoA -> v4HoA > >> > >> => For b) you would send > >> > >> src = v4addr > >> dst = HA > >> src = V6HoA > >> dst = V6HA > >> BU message > >> v4 alt CoA option containing v4addr > >> > >> > >> Hesham > >> > >> > >>> > >>> Maybe you could help me sorting out: what is the contents of the > >>> binding updates to be sent to the home agent in the two > >> situations? > >>> And are both situations covered with the DSMIP specification? > >>> > >>> Christian > >>> > >>> > >>>> -----Original Message----- > >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] > >>>> Sent: 12. december 2008 13:37 > >>>> To: Kaas-Petersen Christian; mext@ietf.org > >>>> Cc: jari.arkko@piuha.net; julien.laganier.ietf@googlemail.com > >>>> Subject: Re: [MEXT] Removing bindings for IPv4 only - > >> please comment > >>>> > >>>> > >>>>> Fine with the addition. The original suggestion of Karen, now > >>>>> described in draft-premec-mext-extended-home-link, is something > >>>>> different, namely maintaining both IPv4 and IPv6 home > >>>> addresses on a > >>>>> home link which gives native support for either IPv4 or IPv6. > >>>>> Suppose the home link supports only IPv4. The home agent > >>>> will remove > >>>>> the entry for the v4HoA address, retaining the entry for > >> the v6HoA, > >>>>> and this entry will indicate packets for v6HoA will have to be > >>>>> IP-in-IP tunneled to v4HoA. > >>>> > >>>> => Right, but this is what the text I sent does. It > removes the v4 > >>>> binding and keeps the IPv6 binding. If the link is > >>>> IPv4 only then it will bind the > >>>> v6 HoA to that IPv4 address. > >>>> > >>>> Hesham > >>>> > >>>>> > >>>>> Christian > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] > >>>> On Behalf > >>>>>> Of Hesham Soliman > >>>>>> Sent: 12. december 2008 07:28 > >>>>>> To: mext@ietf.org > >>>>>> Cc: Jari Arkko; Julien Laganier > >>>>>> Subject: [MEXT] Removing bindings for IPv4 only - > please comment > >>>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> Gerardo requested that we consider the issue of removing > >>>> an IPv4-only > >>>>>> bindings in the spec. We discussed this with the chairs > >>>> and it seemed > >>>>>> like a simple add-on to the spec. I'm still wondering if > >>>> this is the > >>>>>> same thing that Karen asked for earlier and we decided to do it > >>>>>> separately. If it is, then I don't understand why we > >>>> didn't consider > >>>>>> the following solution (can't remember if I suggested > it before). > >>>>>> > >>>>>> I've added the following text to the draft, please let me > >>>> know if you > >>>>>> have any comments ASAP. I want to submit this version on > >>>> the weekend > >>>>>> if possible. > >>>>>> All the IESG comments have been included. It's pretty straight > >>>>>> forward and follows standard MIPv6 logic. > >>>>>> > >>>>>>
> >>>>>> > >>>>>> Mobile nodes will remove bindings from the home > >> agent's binding > >>>>>> cache whenever they move to the home link, or simply > >> when mobility > >>>>>> support is not needed. > >>>>>> > >>>>>> De-registering the IPv6 home address is described in >>>>>> target="RFC3775"/>. The same mechanism applies in this > >>>> specification. > >>>>>> Mobile nodes may remove the binding for the > >>>>>> IPv4 home address only, by sending a binding update that > >> does not > >>>>>> include the IPv4 home address option. Upon receiving > >> this binding > >>>>>> update, the home agent will replace the existing cache > >>>> entries with > >>>>>> the content of the new message. This ensures that the > >>>>>> IPv4 home address binding is removed, while maintining an > >>>>>> IPv6 binding. > >>>>>> > >>>>>> Note that the mobile node cannot remove the IPv6 > home address > >>>>>> binding while maintaining an IPv4 home address binding. > >>>>>> > >>>>>> A binding update message with a lifetime of zero, will > >>>> remove all > >>>>>> bindings for the mobile node.
> >>>>>> > >>>>>> Hesham > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> MEXT mailing list > >>>>>> MEXT@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>> > >>>> > >>>> > >>>> > >> > >> > >> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From masker90@3abn.org Thu Dec 18 10:34: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 2C21E3A6BA4 for ; Thu, 18 Dec 2008 10:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.871 X-Spam-Level: X-Spam-Status: No, score=-11.871 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MANGLED_OFF=2.3, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGHgGoHjvJfU for ; Thu, 18 Dec 2008 10:34:06 -0800 (PST) Received: from aegon.es (unknown [78.188.38.187]) by core3.amsl.com (Postfix) with SMTP id 1DC983A6B9E for ; Thu, 18 Dec 2008 10:34:04 -0800 (PST) To: Subject: Dear nemo-archive, Dec 85% 0FF From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081218183405.1DC983A6B9E@core3.amsl.com> Date: Thu, 18 Dec 2008 10:34:04 -0800 (PST)
Go to site!
From mext-bounces@ietf.org Fri Dec 19 01:09: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 666EB3A69FE; Fri, 19 Dec 2008 01:09:06 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A9123A67EE for ; Fri, 19 Dec 2008 01:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC9lYpKoisd1 for ; Fri, 19 Dec 2008 01:09:04 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 4D3863A69F2 for ; Fri, 19 Dec 2008 01:09:04 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so984157wfd.31 for ; Fri, 19 Dec 2008 01:08:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:cc :subject:in-reply-to:references:user-agent:organization:mime-version :content-type; bh=FMmIoS+GveUoLqmeqyEXHW6Djf7eaCGsEx2vQc7y2T8=; b=PWXenDEXlfZQab0oVJ0gaLq9EeqCeU8wLdg4QHRfY2Q4dhy+Urzrg+mKmMK5Zmp3OO LWgNfDdhmENw4fjhACbxhL+Mi3o7iiBzAbBV0sztewLWe07VrSvNiB6qVyLCGmMV3Ziz Di6adsaJBE2kXY/s89QnnjCwQkMAj5EZJeYlc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:organization:mime-version:content-type; b=Pz/i8VXqR6lZNM6JZtTCJT6T6ch6vAAKwecMD8aj/ol9rFUHGPPLk61Ac0ECK9bN2v xm5wF1w1FhA9y6OypcevolALRzEm8I90Cg2PKc3LdCFaF2r/cN8eCqTjrko9HF4mFcbl g0ZLD333EBNA+2gDQNlNrTKsCDJQORiHAtwDg= Received: by 10.142.223.20 with SMTP id v20mr1233223wfg.7.1229677736767; Fri, 19 Dec 2008 01:08:56 -0800 (PST) Received: from ryuji-wakikawa-no-macbook-pro.local.sfc.wide.ad.jp (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 30sm7124481wff.12.2008.12.19.01.08.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Dec 2008 01:08:55 -0800 (PST) Date: Fri, 19 Dec 2008 18:08:53 +0900 Message-ID: From: Ryuji Wakikawa To: Benjamin Lim In-Reply-To: <4949F309.40305@sg.panasonic.com> References: <4949F309.40305@sg.panasonic.com> User-Agent: Wanderlust/2.14.1 (Bad Medicine-pre) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin9) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: Desire Oulai , mext@ietf.org Subject: Re: [MEXT] Bulk Binding Refresh or Deregistration after Separate Binding Registration in MCoA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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 Benjamin, At Thu, 18 Dec 2008 14:51:53 +0800, Benjamin Lim wrote: > > Hi Ryuji, > > Ryuji Wakikawa wrote: > >> However, is it possible for a MN to do separate > >> binding registration then do bulk binding refresh or bulk > >> deregistration? > > > > Yes, MN can switch to bulk registration after the separate registration. > [Ben] So does the HA accept this bulk registration BU from the MN based > on the fact that MN has previously done separate binding registration? > Or does it do some form of CoA verification? We don't provide any CoA verification for bulk registration. But you can use separate binding registration before starting bulk registration. regards, ryuji > Regards, > Benjamin Lim > > > > > regards, > > ryuji > > > > > >> > >> > >> BR > >> > >> Desire > > > > _______________________________________________ > > MEXT mailing 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 Dec 19 01:32: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 A4F753A6A0F; Fri, 19 Dec 2008 01:32:11 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD60C3A6A0F for ; Fri, 19 Dec 2008 01:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdz61CRRrS+d for ; Fri, 19 Dec 2008 01:32:10 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 120C23A6851 for ; Fri, 19 Dec 2008 01:32:10 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so992654wfd.31 for ; Fri, 19 Dec 2008 01:32:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=l4r+uEZG7VcBwxlgDJ+x226Ebmeou6QWAV1Tntq5Nto=; b=uHLXo+fGZycW3EtG3vNeW2Ag5EQSX8lLMemsEzZBeUdhzxH/O8fcSRmvltRlSECle5 7Me7keo6sHzVYpDa+iU/SqWAJOY1WWpwy36ojOEO7LbafCjNRxqHfn6zyNh1StAjuG4V EfXBqv0Qu95h9LR4c2HyT3PMam0hcPiahp6Es= 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=GIvDKUPVl28y/yGIFUXwkaLgE4j9O6iEjPSMLVo8CLuFgaojRSWF/9iFTOHFToNIo5 YvOgjrDb2D6gMYoXwljyLHNBuKu3sZYE7q8sQTqBA0pcKPb59X2lLBzvbfH1/VPRYLtD z1QQ/51DVBv6wU1/Ne+krpClELy/wBC5plkZI= Received: by 10.142.71.16 with SMTP id t16mr1227690wfa.273.1229679120147; Fri, 19 Dec 2008 01:32:00 -0800 (PST) Received: from ?172.17.105.34? (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 30sm13720227wfg.5.2008.12.19.01.31.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Dec 2008 01:31:59 -0800 (PST) From: Ryuji Wakikawa To: Desire Oulai In-Reply-To: References: <4949F309.40305@sg.panasonic.com> Message-Id: <4CD962F0-C6D9-40C1-910F-2A7377826BB6@gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 19 Dec 2008 18:31:56 +0900 X-Mailer: Apple Mail (2.930.3) Cc: mext@ietf.org Subject: Re: [MEXT] Bulk Binding Refresh or Deregistration after Separate Binding Registration in MCoA X-BeenThere: mext@ietf.org X-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 Desire, I can add some texts in the Security Consideration Section. ryuji On 2008/12/18, at 18:46, Desire Oulai wrote: > Hi Benjamin, > > If initial bindings are done by separate registration, we can assume > that CoA verification is done as each BU as the corresponding CoA as > source address. Therefore, the MN can perform bulk re-registration or > deregistration. Ruyji, should we have some text related to this in the > draft? > > BR > > Desire > >> -----Original Message----- >> From: Benjamin Lim [mailto:benjamin.limck@sg.panasonic.com] >> Sent: December 18, 2008 1:52 AM >> To: Ryuji Wakikawa >> Cc: Desire Oulai; mext@ietf.org >> Subject: Re: [MEXT] Bulk Binding Refresh or Deregistration >> after Separate Binding Registration in MCoA >> >> Hi Ryuji, >> >> Ryuji Wakikawa wrote: >>>> However, is it possible for a MN to do separate binding >> registration >>>> then do bulk binding refresh or bulk deregistration? >>> >>> Yes, MN can switch to bulk registration after the separate >> registration. >> [Ben] So does the HA accept this bulk registration BU from >> the MN based on the fact that MN has previously done separate >> binding registration? >> Or does it do some form of CoA verification? >> >> Regards, >> Benjamin Lim >> >>> >>> regards, >>> ryuji >>> >>> >>>> >>>> >>>> BR >>>> >>>> Desire >>> >>> _______________________________________________ >>> MEXT mailing 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 Dec 19 01:40:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6450C3A6A0C; Fri, 19 Dec 2008 01:40:44 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46AFF3A6A0C for ; Fri, 19 Dec 2008 01:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JyMbsL1+dbs for ; Fri, 19 Dec 2008 01:40:41 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id 92D173A6882 for ; Fri, 19 Dec 2008 01:40:41 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so789070rvf.49 for ; Fri, 19 Dec 2008 01:40:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=/w8kbH0XMgharLnU3A8Bh2ciXYvk7SzahG0p4Do4V8U=; b=gq/4PFk/GzAOcPQxV8Ga8GmCL+BPYMTaXC53FdRD8Ay3lIQbqB5yR+rJidU0aWigQT 7sj2ShHXk/PTAtmIMOaRtKH27a3hsOJb6Z0W6yXhxI4OyRLuT8H6JwyG8NLUVdcyXXGf q0uzNhm10YIH8QSEXxzfuW8l+rwfwnRKX6EFc= 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=vmWKpcb2pRcD7hKZeyRzTiJwKoH4CNV4EGrzn90X28yI6Zzq8niFO3O4jJT+rsZVb5 UPwDYI8eKMQgg/2UwjYhu0eS/YiFh/GB/D7UXKnZPtzsR3h+QUvEmZ+t2isyp8WkF28+ +X+MzdJ9CA/XlRtXMvH30N5vRpxUAiv/ajWIc= Received: by 10.142.222.21 with SMTP id u21mr1233587wfg.235.1229679633480; Fri, 19 Dec 2008 01:40:33 -0800 (PST) Received: from ?172.17.105.34? (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 29sm9163085wfg.6.2008.12.19.01.40.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Dec 2008 01:40:32 -0800 (PST) From: Ryuji Wakikawa To: "Giaretta, Gerardo" In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3D85E52C0@NASANEXMB08.na.qualcomm.com> References: , <057632CE4CE10D45A1A3D6D19206C3A3D85D72B3@NASANEXMB08.na.qualcomm.com> <057632CE4CE10D45A1A3D6D19206C3A3D85E52C0@NASANEXMB08.na.qualcomm.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 19 Dec 2008 18:40:28 +0900 X-Mailer: Apple Mail (2.930.3) Cc: "mext@ietf.org" , "Christian.Kaas-Petersen@tieto.com" Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Gerardo, On 2008/12/18, at 1:47, Giaretta, Gerardo wrote: > Hi Ryuji, > >> -----Original Message----- >> From: Ryuji Wakikawa [mailto:ryuji.wakikawa@gmail.com] >> Sent: Tuesday, December 16, 2008 11:32 PM >> To: Giaretta, Gerardo >> Cc: Christian.Kaas-Petersen@tieto.com; mext@ietf.org >> Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals >> and some >> comments >> >> Hi Gerardo, >> >> Yes, I was reading the mail threads. sorry to catch up this thread >> late. I was in Europe;-) >> >> I understand the reasons of BID for the home attached interface. >> >> MN keeps sending the BU (w/ non zero lifetime) from the home link? >> It sounds like we'll remove de-registration operation from RFC-3775? >> > > The point is that the MN does no de-register as in RFC-3775 if there > are other active interfaces. The MN will de-register only when only > the interface on the home link is active. OK >> As a result, HA will have a home binding for the interface attached >> to >> home link, >> but will not operate proxy ND and encapsulation for that binding. > > If the HA is the default router, the HA will still intercept all > packets as defined in the draft. It is true that there will be no > encapsulation, but again this is already mentioned in the draft. > >> I don't know this is reasonable modification to RFC-3775. >> >> My understanding was that, when MN is at home, most of traffic should >> be sent directly from the home link. >> I didn't see any strong reasons to use the interface attached to >> foreign links. >> Why not setting special flows which need to be sent from the foreign >> link by flow binding and >> rest of traffic are just sent from the home link. We don't need BID >> for the home attached interface. >> This is what I expected. >> >> Do you think there is a case where MN attaches to home link by >> multiple interfaces? >> > > Think about this scenario: the MN has a cellular interface and a > WLAN interface. Cellular is the home link. > MN wants to do VoIP over cellular and all other traffic over WLAN. > In this case the MN will register a match-all > filter for WLAN BID and more specific FIDs for the "home binding". > This is the main scenario studied in 3GPP for example. > > In my opinion, allocating a BID for the HoA in the home link sounds > like the cleanest way of solving this scenario. > However I am open to other suggestions as soon as the scenario is > supported :-) If we need a BID for the interface attached to the home link, we need a "binding". I think we don't have any other alternative for this purpose. I will update the document for this and will post the new version (including modifications of all other comments during last call). ryuji > > Gerardo > >> regards, >> ryuji >> >> >> >> >> >> On 2008/12/17, at 15:42, Giaretta, Gerardo wrote: >> >>> Hi Ryuji, >>> >>> one point related to Christian's comments is that we need a BID also >>> for the interface which is on the home link. This is needed in order >>> to associate FIDs to that interface. The rules to create/update/ >>> delete that BID should be the same as for any other binding >>> >>> Gerardo >>> >>> ________________________________________ >>> From: mext-bounces@ietf.org [mext-bounces@ietf.org] On Behalf Of >>> Ryuji Wakikawa [ryuji.wakikawa@gmail.com] >>> Sent: Tuesday, December 16, 2008 10:27 PM >>> To: Christian.Kaas-Petersen@tieto.com >>> Cc: mext@ietf.org >>> Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals >>> and some comments >>> >>> Hi Christian, >>> >>> thanks for comments. >>> >>> At Thu, 11 Dec 2008 15:08:16 +0100, >>> wrote: >>>> >>>> Assume a mobile node with home address HoA has two interfaces, >>>> both attached to foreign links. After exchange of binding update >>>> and binding acknowledgement, the home agent's binding cache (at >>>> least the snip of it related to HoA) will look like this >>>> >>>> HoA, BID= 7, CoA1, other parameters like period of validity... >>>> HoA, BID=10, CoA2, other parameters ... >>>> >>>> The draft uses HoA=2001:db8::EUI. >>>> >>>> Draft 10, section 5.1 states, that a BID value must be unique for a >>>> home address and care-of address pair. This is satisfied above, >>>> but >>>> it means, that the mobile station is not allowed to change the >>>> second entry such that it also uses CoA1 as care-of address. >>>> >>>> Proposal: I think it has merit to be able to allow more than >>>> one BID value per pair of home address and care-of address. >>>> Consider >>>> flow bindings (defined in draft-ietf-mext-flow-binding) where >>>> a flow may refer to a BID, and thus there is a simple way to move >>>> flows between interfaces: only updating the binding cache. >>> >>> >>> Do you want these bindings? >>> HoA, BID= 7, CoA1, other parameters like period of validity... >>> HoA, BID=10, CoA1, other parameters ... >>> >>> From the protocol operational view, we don't have any issue to relax >>> the BID assignment for this purpose. >>> >>>> Draft 10, section 4.2 (and other places) defines the H flag, which >>>> when >>>> set means the mobile node wants to use both its home link and one >>>> or >>>> more of its foreign links. The H flag is really an instruction to >>>> the >>>> home agent, that in addition to all the bidings currently defined >>>> is shall have an extra binding where packets shall not be tunneled. >>>> >>>> Proposal: The mobile node should be able to define a binding >>>> saying >>>> >>>> HoA BID=0 HoA >>>> >>>> This is a kind of default binding to be used when any of the other >>>> HoA- >>>> bindings cannot be used. I think the H flag is an indirect way of >>>> saying there is an extra binding, whereas the binding above is >>>> direct. >>>> It also avoids continuously setting the H flag when both home link >>>> and foreign links are active. >>> >>> This was originally proposed by Keigo from Panasonic and has been >>> discussed it. >>> You can check the discussion on ML archives. >>> >>>> >>>> Other comments >>>> >>>> o Figure 1: In general I think it simpler for human readers to have >>>> the elements of the primary key to a database given first, >>>> therefore I suggest >>>> >>>> binding [2001:db8::EUI BID1 care-of address1] >>>> >>>> to be used allover. >>> >>> OK, will fix this. >>> >>>> >>>> o Figure 4: looks as if position 6 is followed by position 17. >>> >>> this is typo. i'll fix this. >>> >>>> o Section 4.2, O flag. The O flag is carried in an Binding >>>> Identification mobility option, but really it a kind of global >>>> value to be understood by the receiver as "clean all HoA entries". >>>> If it really is too much to introduce a new mobility option, >>>> isn't it enough to set the O flag in the first Binding >>>> Identification mobility option? >>> >>> I'm updating the document after last call. the O flag is now defined >>> in the BU itself, since this is global value for all bindings as you >>> pointedout. >>> >>>> o Section 4.2, Care-of address and section 6.2 bullet 6, sub-bullet >>>> 2. >>>> If the care-of address is omitted, the care-of address is to be >>>> taken from the source address of the IPv6 header. >>>> When the binding update arrives at the home agent, the >>>> IPv6 header's source address is exactly the care-of >>>> address used by the mobile node, but when the home agent is >>>> actually able to understand the contents of the binding update, >>>> then the IPv6 headers source address has been swapped with the >>>> address found in the Destination Option extension header, >>>> and thus the care-of address is now found in the Destination >>>> Option extension header. >>> >>> In section 6.1.7 of RFc3775, it said >>> "The care-of address is specified either by the Source Address field >>> in the IPv6 header or by the Alternate Care-of Address option, if >>> present. " >>> >>> So, I will fix this to >>> >>> the care-of address is to be taken from the source address of the >>> IPv6 header "of the Binding Update". >>> >>> >>>> o Section 5.6.2, bullet 2. The term link-local address is used, >>>> but I >>>> think this should be changed to be like in all the other places, >>>> using link-layer address. >>> >>> yes, thanks. >>> >>>> o Section 6.2, bullet 7, sub-bullet 1: I think the condition should >>>> read >>>> "If one of the 'O' flags is set, then all of the 'O' flags must be >>>> set, else [MCOA MALFORMED] is returned." But as suggested above, >>>> I don't think there is reason to enforce an all-or-none 'O' flags. >>> >>> right, see above. >>> >>>> o Section 8.2, para 2. The text says, that the IPv4 Address >>>> Acknowledgement mobility option is included only if the mobile >>>> node >>>> requested a home address. When I read >>>> draft-ietf-mext-nemo-v4traversal, >>>> section 4.2.1, the IPv4 Address Acknowledgement mobility option >>>> is included always, indicating the home agent created a binding >>>> cache >>>> entry for the IPv4 home address. >>> >>> correct. I will check dsmip and update it. >>> >>> thanks >>> ryuji >>> >>> >>>> 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 > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 19 01:50: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 3A5733A6A21; Fri, 19 Dec 2008 01:50:26 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0D13A6A21 for ; Fri, 19 Dec 2008 01:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9hoNSHCsKJC for ; Fri, 19 Dec 2008 01:50:24 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 875C93A6A16 for ; Fri, 19 Dec 2008 01:50:24 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so999332wfd.31 for ; Fri, 19 Dec 2008 01:50:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=eAlxWg1buefbxUsFGa+VlgV0x98da/5zv+cwp8rCbVs=; b=Sf/rE6/SR4T6W5Z+jHM/lo7jaBBjHSD2yYDrejI5rlqpo0RBVYhuUcPGH1BaO0V7qc 9qJeG1LndzQbmNGadU3o4sQ2xYlex7eaZlIOu9Arek/2jWosi7ifLxKim3niT/jckhrG Ejt9WtGVBsCMlFFhhR5EuksMj+6YwodvWh2sE= 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=xqAaFw68TyUYy7SbpLi5YPuN3B3asDyZlZiFaSWVjvH4sL50t3024oJzncw4DcBZP4 FQbnE9FPopYCxDy6HT/uET+xg8RGK+x5o+sU/gtd3IzLGtNaZRxxcMAjW2xcLSs85NzV 9djDdx0ku7BjrRnoquxOLVKKECksHOMhNEFGo= Received: by 10.143.39.16 with SMTP id r16mr1239757wfj.172.1229680216879; Fri, 19 Dec 2008 01:50:16 -0800 (PST) Received: from ?172.17.105.34? (yamate242.jp.toyota-itc.com [61.200.198.242]) by mx.google.com with ESMTPS id 32sm13899805wfa.0.2008.12.19.01.50.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Dec 2008 01:50:16 -0800 (PST) From: Ryuji Wakikawa To: Julien Laganier In-Reply-To: <200812171022.06418.julien.laganier.IETF@googlemail.com> References: <491039B9.6090400@it.uc3m.es> <494646EB.4050203@gmail.com> <200812171022.06418.julien.laganier.IETF@googlemail.com> Message-Id: <1F4169B7-D6AF-4B54-9944-1E0B0ADD561C@gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 19 Dec 2008 18:50:13 +0900 X-Mailer: Apple Mail (2.930.3) Cc: mext Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien, On 2008/12/17, at 18:22, Julien Laganier wrote: > Ryuji, > > On Wednesday 17 December 2008, Ryuji Wakikawa wrote: >> I guess the reason of using tunnel is security. >> We don't have any secured mechanism for protecting DHCP unicast >> message. In NEMO nor MIP, IPsec SA is not created for DHCP-unicast >> messages. >> >> MR cannot trust the unprotected DHCP message for its MNP.. > > With MIPv6 there's already the requirement that a certain number of > IPsec SAs are cinfigured between the MN and the HA, thus I don't see > any problem with requiring a few more to protect DHCP signaling > exchanged between the MR and HA. I answered to Alex's mail about IPsec protection. Again, I think the use of BU/BA for prefix delegation is much simpler and easier. We now have an example to delegate a prefix to a mobile host by PBU/PBA. ryuji > > > --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From ky@ab6x.net Fri Dec 19 03:04:42 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE47828C10F for ; Fri, 19 Dec 2008 03:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.358 X-Spam-Level: X-Spam-Status: No, score=-23.358 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuDMv3k+Ip6h for ; Fri, 19 Dec 2008 03:04:42 -0800 (PST) Received: from 89.0.35.208.dynamic.barak-online.net (89.0.35.208.dynamic.barak-online.net [89.0.35.208]) by core3.amsl.com (Postfix) with SMTP id A811C28C10B for ; Fri, 19 Dec 2008 03:04:37 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081219110438.A811C28C10B@core3.amsl.com> Date: Fri, 19 Dec 2008 03:04:37 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From ltspecial@akcb.com Fri Dec 19 07:41: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 814273A68C5 for ; Fri, 19 Dec 2008 07:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.345 X-Spam-Level: X-Spam-Status: No, score=-25.345 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZceiwKnGoth for ; Fri, 19 Dec 2008 07:41:42 -0800 (PST) Received: from 200-96-227-71.cpece705.dsl.brasiltelecom.net.br (200-96-227-71.cpece705.dsl.brasiltelecom.net.br [200.96.227.71]) by core3.amsl.com (Postfix) with SMTP id 0A9EE3A63CB for ; Fri, 19 Dec 2008 07:41:40 -0800 (PST) To: Subject: Is your cell phone always busy? From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081219154141.0A9EE3A63CB@core3.amsl.com> Date: Fri, 19 Dec 2008 07:41:40 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From jeffcn@adam.com Fri Dec 19 08:33:17 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 873B728C12B for ; Fri, 19 Dec 2008 08:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.862 X-Spam-Level: X-Spam-Status: No, score=-26.862 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aBaoA0n4hUv for ; Fri, 19 Dec 2008 08:33:17 -0800 (PST) Received: from agedwards.com (unknown [212.16.235.114]) by core3.amsl.com (Postfix) with SMTP id E4B2A28C128 for ; Fri, 19 Dec 2008 08:33:14 -0800 (PST) To: Subject: Discount price store: ID 66845 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081219163315.E4B2A28C128@core3.amsl.com> Date: Fri, 19 Dec 2008 08:33:14 -0800 (PST) Dear Customer!
Lovers package at discount price!
Discount price store: ID 45269
http://birddrive.com/

Pfizer is a licensee of the TRUSTe Privacy Program.
© 2001-2008 Pfizer Inc. All rights reserved. From lilanlan_1@263.net Sat Dec 20 00:35:59 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC62A3A6921 for ; Sat, 20 Dec 2008 00:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.997 X-Spam-Level: X-Spam-Status: No, score=-17.997 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MIgGVcNXM3a for ; Sat, 20 Dec 2008 00:35:58 -0800 (PST) Received: from host86-137-72-76.range86-137.btcentralplus.com (host86-137-72-76.range86-137.btcentralplus.com [86.137.72.76]) by core3.amsl.com (Postfix) with SMTP id 0FB633A687C for ; Sat, 20 Dec 2008 00:35:48 -0800 (PST) To: Subject: Dear nemo-archive, Dec 88% 0FF From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081220083556.0FB633A687C@core3.amsl.com> Date: Sat, 20 Dec 2008 00:35:48 -0800 (PST) Dear Customer!
Lovers package at discount price!
Discount price store: ID 25514
http://withtool.com/

Pfizer is a licensee of the TRUSTe Privacy Program.
© 2001-2008 Pfizer Inc. All rights reserved. From mext-bounces@ietf.org Sun Dec 21 11:33: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 A957C3A6938; Sun, 21 Dec 2008 11:33:30 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691673A6938 for ; Sun, 21 Dec 2008 11:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.324 X-Spam-Level: X-Spam-Status: No, score=-3.324 tagged_above=-999 required=5 tests=[AWL=0.275, 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 sHkMy2oSCH5w for ; Sun, 21 Dec 2008 11:33:28 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 039543A68C3 for ; Sun, 21 Dec 2008 11:33:28 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LEU31-0007FK-Fd; Sun, 21 Dec 2008 20:33:08 +0100 From: arno@natisbad.org (Arnaud Ebalard) To: "Ahmad Muhanna" References: <200812151644.31817.julien.laganier.IETF@googlemail.com> <87ljue2c6m.fsf@natisbad.org> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:081221:mext@ietf.org::UDWI4lwj4BoPMjMZ:00000esq X-Hashcash: 1:20:081221:amuhanna@nortel.com::WSfwJD4anyt7t/+9:0000000000000000000000000000000000000000000HVW X-Hashcash: 1:20:081221:julien.laganier.ietf@googlemail.com::FyRh4Y5YFoVVnUpn:000000000000000000000000001Cnz Date: Sun, 21 Dec 2008 11:30:51 -0800 In-Reply-To: (Ahmad Muhanna's message of "Thu, 18 Dec 2008 09:19:02 -0600") Message-ID: <87vdtd72c4.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: Julien Laganier , IETF MEXT WG ML Subject: Re: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, "Ahmad Muhanna" writes: >> > administrative reason. This mechanism enables the home domain to >> > dynamically allow the user to act upon the revocation message in >> > order to not have an unexpectedly interrupted mobile >> IPv6 services. >> >> Well, when it receives the information, it's already too >> late, isn't it? > > [Ahmad] > What is meant here, the MN will have an instant but graceful indication > that its mobility service is being revoked. At that time, the MN will be > able to make an out of scope communication to check/enable/etc. the > service with its provider, for example. This case is meant to > replace/"be compared" the case when the HA deletes the binding and the > tunnel without informing the MN. What about that instead of the last sentence: "This mechanism enables the home domain to dynamically allow the user to act upon the revocation message in order to recover its interrupted mobile IPv6 services." >> > 3.4. Proxy MIPv6 Use Case >> > >> > the mobility entities, e.g. MAG and LMA, are always synchronized >> > with respect to the status of the existing proxy mobile IPv6 >> > bindings. The binding revocation mechanism is generic enough that >> > can be used in all applicable PMIPv6 scenarios and deployment >> >> ^^^^^^^^^^^ >> ^^^^ >> >> "so that it can be" or "to be used" > > [Ahmad] > I do not see any normative text here but, I think "can be used" is used > to give more flexibility; but changing the text to "to be used" is fine > with me if necessary. What I meant is that the structure of the sentence look strange, but maybe it's just my english. >> What about replacing last sentence by following text: >> >> "If IPsec is used, the traffic selectors associated with the SP >> protecting BU and BA MUST be extended to include Binding >> Revocation >> Signaling MH type ." > > [Ahmad] > Looks good to me. ack. >> What about also including some rationale for this choice, w/ sth >> like the following ? : >> >> "Extending the traffic selectors of the SP in order to >> reuse the SA >> protecting BU and BA (instead of creating new ones) provides the >> insurance that those SA will be up and running when the revoking >> entity will need to send a Binding Revocation Signaling message". >> > [Ahmad] > This is good to me too. > However, I would make a minor change: replace "provides insurance" with > "ensures" and "will need" to "needs" > The suggested text would read as follows: > > "Extending the traffic selectors of the SP in order to reuse the SA > protecting BU and BA (instead of creating new ones) ensures that > those SA will be up and running when the revoking entity needs > to send a Binding Revocation Signaling message". ack. >> Last question on that paragraph: The last sentence start with >> "If". Why? I mean, this is mandated by 3775. Is it for PMIPv6? >> >> > 6. Binding Revocation Message >> > >> > This section defines a Binding Revocation Message that >> use a MH type >> > with a Binding Revocation type field that >> follow the MH >> > format described in section 6.1. [RFC3775]. The value in the >> >> ^^^^^^^^^^^^^^^^ >> 6.1 of [RFC3775] or just 6.1? >> > [Ahmad] > Sure we can reference [RFC3775]. it's not what I meant. I meant that "[RFC3775]" sits there in the middle of the sentence. Is it expected? >> > Figure 6: Binding Revocation Acknowledgement Message >> > >> > >> > Status >> > >> > 8-bit unsigned integer indicating the result of processing the >> > Binding Revocation Indication message by the >> receiving mobility >> > entity. The following status values are currently defined. >> > >> > 0 success. >> > 1 partial success. >> > 2 Binding Does NOT Exist. >> > 3 IPv4 HoA Binding Does NOT Exist. >> > 4 Global Revocation NOT Authorized. >> > 5 CAN NOT Identify Binding. >> > 6 Revocation Failed, MN is Attached. >> >> The Binding Revocation Trigger values in Section 6.1 look >> more self-explanatory. They are also mainly informational, right? > > [Ahmad] > Yes, it is mainly informational. However, whenever any R. Trigger value > means a specific action is needed on the side of the receiving mobility > node, IMO, it needs to be documented. If we missed any of these, we can > go back and do it. > >> >> Here, it is not clear what "partial success" (1) or >> "Revocation failed, MN is attached" mean, and what both >> entities should expect when those are sent. Maybe the >> rationale that were associated with those values when the >> list was first created should be included in the document, >> along with the expected behaviors (Are those status value just >> informational?) >> >> Or did I missed some other section that provides that in the draft? > > [Ahmad] > I agree it is mainly informational but some of these status is > appropriate with certain scenarios. I believe those status values > meanings and use are mentioned when these specific scenario are > discussed later on. I may have missed them but "partial success" and "Revocation failed, MN is attached" (at least) are not. >> > set, the home agent sets a flag in the mobile node BCE >> to indicate >> > that revocation is in progress and starts the MINDelayBRIs timer. >> > The home agent maintains the mobile node BCE in this >> state until it >> > receives a Binding Revocation Acknowledgement or the >> > BRIMaxRetransmitNumber is reached. >> >> What does "maintains the node BCE in this sate"? I mean, does >> this mean that the mobile node is not able to perform >> movement during that time? > > [Ahmad] > We are talking about a race condition here which should be addressed > based on the reason of the BRI and HA local policy. If the MN > registration is being revoked for administrative reason, for example, > then, IMO, it does not make sense to allow the mobile node to move > anyway. I understand your point, but the way it is specified in the draft does not leave room for the reverse scenario: the extension provides the ability to warn the user that his access *has been* interrupted but not that it *will be* interrupted soon (i.e. no possible grace period). >> If the revoking entity sends a BRI just when the mobile node >> perform a handover (i.e. sends a BU), then locking the BCE >> state will prevent the CoA update to happen on the revoking >> entity and the retransmitted packets to be sent to the MN. > > [Ahmad] > The revocation in progress flag is set until the HA receives a BRA or > the BRIMaxRetransmitNumber expires. We could add some text to address > this race condition and mention what the HA may do when this race > condition occurs. > > " > In a race condition case, the home agent may receive a BU from the > mobile node while the mobile node's BCE has the revocation in progress > flag set, the home agent should handle this case based on the reason for > sending the Binding Revocation Indication message and its local policy. > In this case, If the home agent accepts the BU, it needs to update the > mobile node BCE accordingly, e.g. removing the revocation in progress > flag. > " ok. >> General comment: in the draft, the few times "Type 2 Header" >> is used, it should probably be replaced by "Type 2 Routing >> Header" for consistency. > > [Ahmad] > Sure. ack. thanks Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From jleahydd@americanhotel.com Mon Dec 22 07:01:29 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479463A69F8 for ; Mon, 22 Dec 2008 07:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.59 X-Spam-Level: X-Spam-Status: No, score=-22.59 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDuPcqvMeNoG for ; Mon, 22 Dec 2008 07:01:23 -0800 (PST) Received: from aide-aux-sourires.com (unknown [189.74.51.54]) by core3.amsl.com (Postfix) with SMTP id DD6D93A69ED for ; Mon, 22 Dec 2008 07:01:19 -0800 (PST) To: Subject: Regain your natural wellness From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081222150121.DD6D93A69ED@core3.amsl.com> Date: Mon, 22 Dec 2008 07:01:19 -0800 (PST) Go toNo.1 stop shop! From kdry@aisd.net Mon Dec 22 09:57:44 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B1443A6A8D for ; Mon, 22 Dec 2008 09:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.764 X-Spam-Level: X-Spam-Status: No, score=-24.764 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lj33gQ35AziO for ; Mon, 22 Dec 2008 09:57:38 -0800 (PST) Received: from amada.co.jp (unknown [189.28.249.94]) by core3.amsl.com (Postfix) with SMTP id A0A043A6820 for ; Mon, 22 Dec 2008 09:57:35 -0800 (PST) To: Subject: Don't miss a chance to become healthier From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081222175736.A0A043A6820@core3.amsl.com> Date: Mon, 22 Dec 2008 09:57:35 -0800 (PST) Go to site now! From mext-bounces@ietf.org Mon Dec 22 17:57: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 598223A67F4; Mon, 22 Dec 2008 17:57:14 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14AC93A67F4 for ; Mon, 22 Dec 2008 17:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=0.332, 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 w9iqpUt1nkw6 for ; Mon, 22 Dec 2008 17:57:12 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id D0E2F3A677E for ; Mon, 22 Dec 2008 17:57:11 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mBN1uwO26896; Tue, 23 Dec 2008 01:56:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 Dec 2008 19:56:56 -0600 Message-ID: In-Reply-To: <87vdtd72c4.fsf@natisbad.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02 Thread-Index: AcljvizTE9GyeLUlQCGSpmp2IjU8eAA2Ovqg References: <200812151644.31817.julien.laganier.IETF@googlemail.com><87ljue2c6m.fsf@natisbad.org> <87vdtd72c4.fsf@natisbad.org> From: "Ahmad Muhanna" To: "Arnaud Ebalard" Cc: Julien Laganier , IETF MEXT WG ML Subject: Re: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Arnaud, > Subject: Re: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02 > > Hi, > > "Ahmad Muhanna" writes: > > > >> > administrative reason. This mechanism enables the > home domain to > >> > dynamically allow the user to act upon the revocation > message in > >> > order to not have an unexpectedly interrupted mobile > >> IPv6 services. > >> > >> Well, when it receives the information, it's already too > late, isn't > >> it? > > > > [Ahmad] > > What is meant here, the MN will have an instant but graceful > > indication that its mobility service is being revoked. At > that time, > > the MN will be able to make an out of scope communication to > > check/enable/etc. the service with its provider, for example. This > > case is meant to replace/"be compared" the case when the HA deletes > > the binding and the tunnel without informing the MN. > > What about that instead of the last sentence: > > "This mechanism enables the home domain to dynamically allow > the user to act upon the revocation message in order to > recover its interrupted mobile IPv6 services." [Ahmad] Ok. > > > >> Last question on that paragraph: The last sentence start with > >> "If". Why? I mean, this is mandated by 3775. Is it for PMIPv6? > >> > >> > 6. Binding Revocation Message > >> > > >> > This section defines a Binding Revocation Message that > >> use a MH type > >> > with a Binding Revocation type field that > >> follow the MH > >> > format described in section 6.1. [RFC3775]. The value in the > >> > >> ^^^^^^^^^^^^^^^^ > >> 6.1 of [RFC3775] or just 6.1? > >> > > [Ahmad] > > Sure we can reference [RFC3775]. > > it's not what I meant. I meant that "[RFC3775]" sits there in > the middle of the sentence. Is it expected? [Ahmad] I see what you meant. What about the following: This section defines the Binding Revocation Message format using a MH Type as illustrated in Figure 4. The value in the Binding Revocation Type field defines whether the Binding Revocation message is a BRI or BRA. If the Binding Revocation type field is set to 1, the Binding Revocation Message is a Binding Revocation Indication message as in Section 6.1. However, if the value is 2, it is a Binding Revocation Acknowledgement message as in Section 6.2. > > > >> > Figure 6: Binding Revocation Acknowledgement Message > >> > > >> > > >> > Status > >> > > >> > 8-bit unsigned integer indicating the result of > processing the > >> > Binding Revocation Indication message by the > >> receiving mobility > >> > entity. The following status values are currently defined. > >> > > >> > 0 success. > >> > 1 partial success. > >> > 2 Binding Does NOT Exist. > >> > 3 IPv4 HoA Binding Does NOT Exist. > >> > 4 Global Revocation NOT Authorized. > >> > 5 CAN NOT Identify Binding. > >> > 6 Revocation Failed, MN is Attached. > >> > >> The Binding Revocation Trigger values in Section 6.1 look more > >> self-explanatory. They are also mainly informational, right? > > > > [Ahmad] > > Yes, it is mainly informational. However, whenever any R. Trigger > > value means a specific action is needed on the side of the > receiving > > mobility node, IMO, it needs to be documented. If we missed any of > > these, we can go back and do it. > > > >> > >> Here, it is not clear what "partial success" (1) or "Revocation > >> failed, MN is attached" mean, and what both entities should expect > >> when those are sent. Maybe the rationale that were associated with > >> those values when the list was first created should be included in > >> the document, along with the expected behaviors (Are those status > >> value just > >> informational?) > >> > >> Or did I missed some other section that provides that in the draft? > > > > [Ahmad] > > I agree it is mainly informational but some of these status is > > appropriate with certain scenarios. I believe those status values > > meanings and use are mentioned when these specific scenario are > > discussed later on. > > I may have missed them but "partial success" and "Revocation > failed, MN is attached" (at least) are not. [Ahmad] Sure. We will make sure that all of these values are described and documented in the new revision. In the meantime, in bthe case of "Partial success", it is the case when the MAG for example, receives a BRI that impact multiple bindings while some of them have been released already, for example. The MAG may set the status to success or partial success. In the case of "Revocation failed, MN is attached", in the case of inter-MAG HO, the LMA may send a BRI message with a Revocation Trigger value of "Inter-MAG HO". In this case, the MAG may need to ensure that the MN is no longer attached. If the MN is still attached, then the MAG could send a BRA with this status value. For example, one of the bullets under section 10.1.1. says: If the Revocation Trigger field value in the received Binding Revocation Indication message indicates an inter-MAG handover and the (A) bit is set, the MAG use the mobility option(s) included in the BRI message to identify the mobile node binding. The mobile access gateway MAY validate that the mobile node is no longer attached to the mobile access gateway before sending a successful Binding Revocation Acknowledgement message to the LMA. However, if the Revocation Trigger field is set to "Inter-MAG - Unknown Handoff", the MAG MUST validate that the mobile node is no longer attached to the MAG before sending a successful BRA message and deleting the resources associated with the mobile node binding. We could add some text to the above to read as follows: ..................................................... However, if the Revocation Trigger field is set to "Inter-MAG - Unknown Handoff" and the (A) bit is set, the MAG MUST validate that the mobile node is no longer attached to the MAG before sending a successful BRA message and deleting the resources associated with the mobile node binding. Otherwise, if the MAG verified that the MN is still attached, the MAG MUST set the status field in the BRA to "Revocation failed - MN is attached" Regards, Ahmad > > >> General comment: in the draft, the few times "Type 2 Header" > >> is used, it should probably be replaced by "Type 2 Routing Header" > >> for consistency. > > > > [Ahmad] > > Sure. > > ack. thanks > > Cheers, > > a+ > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 22 22:52: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 B945B3A6AA4; Mon, 22 Dec 2008 22:52:48 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 703493A6AA4 for ; Mon, 22 Dec 2008 22:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[AWL=0.254, 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 ewtw14VzZdYa for ; Mon, 22 Dec 2008 22:52:46 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 3576D3A67EC for ; Mon, 22 Dec 2008 22:52:46 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LF184-0007tA-27; Tue, 23 Dec 2008 07:52:32 +0100 From: arno@natisbad.org (Arnaud Ebalard) To: "Ahmad Muhanna" References: <200812151644.31817.julien.laganier.IETF@googlemail.com> <87ljue2c6m.fsf@natisbad.org> <87vdtd72c4.fsf@natisbad.org> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:081223:julien.laganier.ietf@googlemail.com::ivJ+KxkdkcT2ibW+:000000000000000000000000001iHX X-Hashcash: 1:20:081223:mext@ietf.org::QOB365OK5BKSLIMt:00005Dcd X-Hashcash: 1:20:081223:amuhanna@nortel.com::3N66q+cKWC9DSko6:000000000000000000000000000000000000000000BHKA Date: Mon, 22 Dec 2008 22:50:20 -0800 In-Reply-To: (Ahmad Muhanna's message of "Mon, 22 Dec 2008 19:56:56 -0600") Message-ID: <87r63zs7v7.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: Julien Laganier , IETF MEXT WG ML Subject: Re: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, "Ahmad Muhanna" writes: >> it's not what I meant. I meant that "[RFC3775]" sits there in >> the middle of the sentence. Is it expected? > > [Ahmad] > I see what you meant. > > What about the following: > > This section defines the Binding Revocation Message format using a > MH Type as illustrated in Figure 4. The value in the > Binding Revocation Type field defines whether the Binding > Revocation message is a BRI or BRA. If the Binding Revocation type > field is set to 1, the Binding Revocation Message is a Binding > Revocation Indication message as in Section 6.1. However, if the > value is 2, it is a Binding Revocation Acknowledgement message as > in Section 6.2. fine with me. thanks. >> >> > 0 success. >> >> > 1 partial success. >> >> > 2 Binding Does NOT Exist. >> >> > 3 IPv4 HoA Binding Does NOT Exist. >> >> > 4 Global Revocation NOT Authorized. >> >> > 5 CAN NOT Identify Binding. >> >> > 6 Revocation Failed, MN is Attached. >> >> >> >> The Binding Revocation Trigger values in Section 6.1 look more >> >> self-explanatory. They are also mainly informational, right? >> > >> > [Ahmad] >> > Yes, it is mainly informational. However, whenever any R. Trigger >> > value means a specific action is needed on the side of the >> receiving >> > mobility node, IMO, it needs to be documented. If we missed any of >> > these, we can go back and do it. >> > >> >> >> >> Here, it is not clear what "partial success" (1) or "Revocation >> >> failed, MN is attached" mean, and what both entities should expect >> >> when those are sent. Maybe the rationale that were associated with >> >> those values when the list was first created should be included in >> >> the document, along with the expected behaviors (Are those status >> >> value just >> >> informational?) >> >> >> >> Or did I missed some other section that provides that in the draft? >> > >> > [Ahmad] >> > I agree it is mainly informational but some of these status is >> > appropriate with certain scenarios. I believe those status values >> > meanings and use are mentioned when these specific scenario are >> > discussed later on. >> >> I may have missed them but "partial success" and "Revocation >> failed, MN is attached" (at least) are not. > > [Ahmad] > Sure. We will make sure that all of these values are described and > documented in the new revision. > > In the meantime, in bthe case of "Partial success", it is the case when > the MAG for example, receives a BRI that impact multiple bindings while > some of them have been released already, for example. The MAG may set > the status to success or partial success. > > In the case of "Revocation failed, MN is attached", in the case of > inter-MAG HO, the LMA may send a BRI message with a Revocation Trigger > value of "Inter-MAG HO". In this case, the MAG may need to ensure that > the MN is no longer attached. If the MN is still attached, then the MAG > could send a BRA with this status value. > > For example, one of the bullets under section 10.1.1. says: > > If the Revocation Trigger field value in the received Binding > Revocation Indication message indicates an inter-MAG handover and > the (A) bit is set, the MAG use the mobility option(s) included in > the BRI message to identify the mobile node binding. The mobile > access gateway MAY validate that the mobile node is no longer > attached to the mobile access gateway before sending a successful > Binding Revocation Acknowledgement message to the LMA. However, > if the Revocation Trigger field is set to "Inter-MAG - Unknown > Handoff", the MAG MUST validate that the mobile node is no longer > attached to the MAG before sending a successful BRA message and > deleting the resources associated with the mobile node binding. > > We could add some text to the above to read as follows: > > ..................................................... However, > if the Revocation Trigger field is set to "Inter-MAG - Unknown > Handoff" and the (A) bit is set, the MAG MUST validate that the > mobile node is no longer attached to the MAG before sending a > successful BRA message and deleting the resources associated > with the mobile node binding. Otherwise, if the MAG verified that > the MN is still attached, the MAG MUST set the status field in the > > BRA to "Revocation failed - MN is attached" Thanks for the clarification. But note that I'm not familiar enough w/ PMIPv6 to be helpful and comment that. Cheers, a+ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From minuetish@a54321.com Tue Dec 23 04:57:54 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C50F3A69D5 for ; Tue, 23 Dec 2008 04:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -45.844 X-Spam-Level: X-Spam-Status: No, score=-45.844 tagged_above=-999 required=5 tests=[BAYES_80=2, HELO_EQ_DE=0.35, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUFWjak7xR7b for ; Tue, 23 Dec 2008 04:57:54 -0800 (PST) Received: from aacamuseum.org (unknown [94.28.242.49]) by core3.amsl.com (Postfix) with SMTP id CAB233A67FF for ; Tue, 23 Dec 2008 04:57:47 -0800 (PST) X-AntiVirus: Checked by Dr.Web [version: 4.44, engine: 4.44.0.09170, virus records: 436467, updated: 12.10.2008] To: Subject: We seek for you all day! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081223125749.CAB233A67FF@core3.amsl.com> Date: Tue, 23 Dec 2008 04:57:47 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mext-bounces@ietf.org Tue Dec 23 05:48: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 BD9BD3A689F; Tue, 23 Dec 2008 05:48:11 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABC0F3A689F for ; Tue, 23 Dec 2008 05:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaGcEkmaDo9y for ; Tue, 23 Dec 2008 05:48:10 -0800 (PST) Received: from tietoe03.tietoenator.com (datnt07.tieto.com [194.110.47.24]) by core3.amsl.com (Postfix) with ESMTP id B44DA3A687C for ; Tue, 23 Dec 2008 05:48:08 -0800 (PST) X-AuditID: c26e2f18-0000151c00000510-be-4950ec4105a3 Received: from camaro.eu.tieto.com ([192.176.143.43]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Dec 2008 15:48:49 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Dec 2008 14:47:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 Dec 2008 14:47:54 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Home-Agent-Switch-Message and Binding-Revocation-Indication-Message Thread-Index: AcllBQ4e4S/LZRz7RCOTXd8Ui3ClCg== From: To: X-OriginalArrivalTime: 23 Dec 2008 13:47:56.0775 (UTC) FILETIME=[0F99CF70:01C96505] X-Brightmail-Tracker: AAAAAA== Subject: [MEXT] Home-Agent-Switch-Message and Binding-Revocation-Indication-Message X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Is there a difference to a mobile node receiving an RFC 5142 specified Home Agent Switch Message # of addresses = 0 and receiving a draft-ietf-mext-binding-revocation specified Binding Revocation Indication Message The packets are different and the responses will be different, but isn't it true the net result in both cases is the same: the home agent will no longer support the mobile node so the mobile node is left alone in the world? Christian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mail@3w-travel.de Tue Dec 23 07:40:08 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C5F28C141 for ; Tue, 23 Dec 2008 07:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.462 X-Spam-Level: X-Spam-Status: No, score=-12.462 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5v78Y03R365 for ; Tue, 23 Dec 2008 07:40:07 -0800 (PST) Received: from 200-161-73-78.dsl.telesp.net.br (200-161-73-78.dsl.telesp.net.br [200.161.73.78]) by core3.amsl.com (Postfix) with SMTP id 88AC628C0E4 for ; Tue, 23 Dec 2008 07:40:06 -0800 (PST) To: Subject: I lost your cell number From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081223154006.88AC628C0E4@core3.amsl.com> Date: Tue, 23 Dec 2008 07:40:06 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From jyokoyam@afs.org Tue Dec 23 10:23:24 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0483A6B34 for ; Tue, 23 Dec 2008 10:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.609 X-Spam-Level: X-Spam-Status: No, score=-11.609 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvrVJUkhnp0w for ; Tue, 23 Dec 2008 10:23:24 -0800 (PST) Received: from ip-85-160-19-99.eurotel.cz (ip-85-160-19-99.eurotel.cz [85.160.19.99]) by core3.amsl.com (Postfix) with SMTP id A32123A6B2B for ; Tue, 23 Dec 2008 10:23:22 -0800 (PST) To: Subject: Can't you answer the call? From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081223182322.A32123A6B2B@core3.amsl.com> Date: Tue, 23 Dec 2008 10:23:22 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From lley@aischool.org Tue Dec 23 11:10:38 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 172713A6856 for ; Tue, 23 Dec 2008 11:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.962 X-Spam-Level: X-Spam-Status: No, score=-0.962 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BLUEYON=1.4, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjxaPLEkhHRa for ; Tue, 23 Dec 2008 11:10:37 -0800 (PST) Received: from 82-39-4-195.cable.ubr01.gate.blueyonder.co.uk (82-39-4-195.cable.ubr01.gate.blueyonder.co.uk [82.39.4.195]) by core3.amsl.com (Postfix) with SMTP id 2560B3A6B24 for ; Tue, 23 Dec 2008 11:10:35 -0800 (PST) To: Subject: Perfection is attainable From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081223191036.2560B3A6B24@core3.amsl.com> Date: Tue, 23 Dec 2008 11:10:35 -0800 (PST) We'll help you to take pride in your masculinity! From lottie.rosen@1216wbeo.com Tue Dec 23 11:40:59 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85F073A6B24 for ; Tue, 23 Dec 2008 11:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.761 X-Spam-Level: X-Spam-Status: No, score=-9.761 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTR0acGmVK4A for ; Tue, 23 Dec 2008 11:40:58 -0800 (PST) Received: from add.mb00.net (77-253-125-232.adsl.inetia.pl [77.253.125.232]) by core3.amsl.com (Postfix) with SMTP id BB6173A6452 for ; Tue, 23 Dec 2008 11:40:54 -0800 (PST) To: Subject: Change your weakness to power From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081223194055.BB6173A6452@core3.amsl.com> Date: Tue, 23 Dec 2008 11:40:54 -0800 (PST) See your gf go hog-wild as you show her your new tool! From mext-bounces@ietf.org Tue Dec 23 15:02: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 259A33A6B31; Tue, 23 Dec 2008 15:02:02 -0800 (PST) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFB843A6B31 for ; Tue, 23 Dec 2008 15:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 ak6Bi9oEIDmr for ; Tue, 23 Dec 2008 15:02:00 -0800 (PST) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 20FF43A69D8 for ; Tue, 23 Dec 2008 15:01:59 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 Dec 2008 18:01:46 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Home-Agent-Switch-Message andBinding-Revocation-Indication-Message Thread-Index: AcllBQ4e4S/LZRz7RCOTXd8Ui3ClCgATU7tg From: "Vijay Devarapalli" To: , Subject: Re: [MEXT] Home-Agent-Switch-Message andBinding-Revocation-Indication-Message X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: 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, > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Christian.Kaas-Petersen@tieto.com > Sent: Tuesday, December 23, 2008 5:48 AM > To: mext@ietf.org > Subject: [MEXT] Home-Agent-Switch-Message > andBinding-Revocation-Indication-Message > > Is there a difference to a mobile node receiving an RFC 5142 specified > > Home Agent Switch Message > # of addresses = 0 > > and receiving a draft-ietf-mext-binding-revocation specified > > Binding Revocation Indication Message > > The packets are different and the responses will be > different, but isn't it true the net result in both cases is > the same: the home agent will no longer support the mobile > node so the mobile node is left alone in the world? Yes, there is no difference. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From kelly@amax.com Tue Dec 23 16:34:16 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA8C28C18E for ; Tue, 23 Dec 2008 16:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.437 X-Spam-Level: X-Spam-Status: No, score=-27.437 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SA6fSzbUfgzy for ; Tue, 23 Dec 2008 16:34:15 -0800 (PST) Received: from 200217098022.user.veloxzone.com.br (200217098022.user.veloxzone.com.br [200.217.98.22]) by core3.amsl.com (Postfix) with SMTP id AB7813A677D for ; Tue, 23 Dec 2008 16:34:04 -0800 (PST) To: Subject: Get armed with huge love cannon From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081224003407.AB7813A677D@core3.amsl.com> Date: Tue, 23 Dec 2008 16:34:04 -0800 (PST) Why not go and gain so needed extra inches for your love tool? From lholder1@aisd.net Thu Dec 25 14:17:40 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D643A6943 for ; Thu, 25 Dec 2008 14:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -32.636 X-Spam-Level: X-Spam-Status: No, score=-32.636 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqFBSWjrZsK4 for ; Thu, 25 Dec 2008 14:17:40 -0800 (PST) Received: from host144-211-static.106-82-b.business.telecomitalia.it (host144-211-static.106-82-b.business.telecomitalia.it [82.106.211.144]) by core3.amsl.com (Postfix) with SMTP id AAF613A6828 for ; Thu, 25 Dec 2008 14:17:37 -0800 (PST) To: Subject: Why did you leave me? From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081225221737.AAF613A6828@core3.amsl.com> Date: Thu, 25 Dec 2008 14:17:37 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From lumber@airtransat.com Fri Dec 26 11:03:47 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BB793A69B9 for ; Fri, 26 Dec 2008 11:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -32.532 X-Spam-Level: X-Spam-Status: No, score=-32.532 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJrG0vlmtt-G for ; Fri, 26 Dec 2008 11:03:47 -0800 (PST) Received: from a1access.net (unknown [88.249.33.87]) by core3.amsl.com (Postfix) with SMTP id AF8A23A67B3 for ; Fri, 26 Dec 2008 11:03:44 -0800 (PST) To: Subject: Can't you answer the call? From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081226190345.AF8A23A67B3@core3.amsl.com> Date: Fri, 26 Dec 2008 11:03:44 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From millerrdd@alum.rpi.edu Fri Dec 26 11:35:26 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EFB73A69D8 for ; Fri, 26 Dec 2008 11:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.144 X-Spam-Level: X-Spam-Status: No, score=-34.144 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMXj75ukonM4 for ; Fri, 26 Dec 2008 11:35:25 -0800 (PST) Received: from adsl196-16-126-217-196.adsl196-12.iam.net.ma (adsl196-16-126-217-196.adsl196-12.iam.net.ma [196.217.126.16]) by core3.amsl.com (Postfix) with SMTP id 217383A67A1 for ; Fri, 26 Dec 2008 11:35:23 -0800 (PST) To: Subject: Undeliverable: Hi From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081226193524.217383A67A1@core3.amsl.com> Date: Fri, 26 Dec 2008 11:35:23 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From khosravi@akzonobel.com Fri Dec 26 17:36:47 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B813A6781 for ; Fri, 26 Dec 2008 17:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -52.59 X-Spam-Level: X-Spam-Status: No, score=-52.59 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83ZFgUiU77Dx for ; Fri, 26 Dec 2008 17:36:47 -0800 (PST) Received: from ahm.honda.com (unknown [189.107.27.168]) by core3.amsl.com (Postfix) with SMTP id CF63C3A67B0 for ; Fri, 26 Dec 2008 17:36:27 -0800 (PST) To: Subject: We need your presence From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081227013629.CF63C3A67B0@core3.amsl.com> Date: Fri, 26 Dec 2008 17:36:27 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From miguel.reza@alsuper.com Sat Dec 27 05:41:31 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AD163A6864 for ; Sat, 27 Dec 2008 05:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.89 X-Spam-Level: X-Spam-Status: No, score=-22.89 tagged_above=-999 required=5 tests=[AWL=-4.547, BAYES_99=3.5, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KsOqrj5lYpH for ; Sat, 27 Dec 2008 05:41:30 -0800 (PST) Received: from 200217141106.user.veloxzone.com.br (200217141106.user.veloxzone.com.br [200.217.141.106]) by core3.amsl.com (Postfix) with SMTP id 36DF23A67E1 for ; Sat, 27 Dec 2008 05:41:26 -0800 (PST) To: Subject: The most popular products for your health From: MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 080418-0, 18/04/2008), Outbound message X-Antivirus-Status: Clean Message-Id: <20081227134128.36DF23A67E1@core3.amsl.com> Date: Sat, 27 Dec 2008 05:41:26 -0800 (PST)

If you are unable to see the message below, click here to view.

We specialize in selling the highest quality remedies. Visit our store now!

PLEASE DO NOT REPLY - This is being sent from an unattended mailbox.

Copyright © 2008 MaxGentleman, Inc. All rights reserved.
5 Trowbridge Drive, Bethel, CT 198420

You have received this message because you
opted in to receives MaxGentleman pecial offers via email.

You can unsubscribe here

 From marianne.caruana@airmalta.com.mt Sat Dec 27 07:13:15 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0E563A6A92 for ; Sat, 27 Dec 2008 07:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.069 X-Spam-Level: X-Spam-Status: No, score=-23.069 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HOST_EQ_DHCP=1.295, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogkJegysdRFl for ; Sat, 27 Dec 2008 07:13:15 -0800 (PST) Received: from alrinc.com (unknown [189.106.96.9]) by core3.amsl.com (Postfix) with SMTP id 884C83A6957 for ; Sat, 27 Dec 2008 07:13:14 -0800 (PST) To: Subject: Returned mail: see transcript for details From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081227151314.884C83A6957@core3.amsl.com> Date: Sat, 27 Dec 2008 07:13:14 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mccormick@amilink.com Sat Dec 27 07:30:21 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DEAA3A6A9B for ; Sat, 27 Dec 2008 07:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.356 X-Spam-Level: X-Spam-Status: No, score=-25.356 tagged_above=-999 required=5 tests=[BAYES_95=3, DNS_FROM_RFC_BOGUSMX=1.482, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ajl+lecvfbq7 for ; Sat, 27 Dec 2008 07:30:21 -0800 (PST) Received: from absinto-orkestra.de (unknown [189.67.147.165]) by core3.amsl.com (Postfix) with SMTP id 0F7143A695F for ; Sat, 27 Dec 2008 07:30:09 -0800 (PST) To: Subject: Can't find you, darling From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081227153012.0F7143A695F@core3.amsl.com> Date: Sat, 27 Dec 2008 07:30:09 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From jiij@3ibank.com Sun Dec 28 19:02:29 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473493A687B for ; Sun, 28 Dec 2008 19:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.145 X-Spam-Level: X-Spam-Status: No, score=-23.145 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj-DmtT5XcE8 for ; Sun, 28 Dec 2008 19:02:28 -0800 (PST) Received: from 59.163.46.84.ip.erdves.lt (59.163.46.84.ip.erdves.lt [84.46.163.59]) by core3.amsl.com (Postfix) with SMTP id 87FBA3A6852 for ; Sun, 28 Dec 2008 19:02:26 -0800 (PST) To: Subject: More length and width From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081229030227.87FBA3A6852@core3.amsl.com> Date: Sun, 28 Dec 2008 19:02:26 -0800 (PST)


Please do not reply to this email. To contact Armstrong Shank Advertising, please visit us

This email message was sent to . If you do not wish to receive further communications from Armstrong Shank Advertising, click here to unsubscribe.

If you've experience any difficulty in being removed from a Armstrong Shank Advertising email list, click here for personalized help.

Copyright © 2008 Armstrong Shank Advertising, Inc. All rights reserved.
7450 S Seneca, Haysville, KS 67060

From kissmarknn@360.cc Mon Dec 29 04:25:21 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C30B3A6862 for ; Mon, 29 Dec 2008 04:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.997 X-Spam-Level: X-Spam-Status: No, score=-17.997 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7SkQ-UJyWjn for ; Mon, 29 Dec 2008 04:25:16 -0800 (PST) Received: from 28.pool85-60-8.dynamic.orange.es (28.pool85-60-8.dynamic.orange.es [85.60.8.28]) by core3.amsl.com (Postfix) with SMTP id A5B743A6C29 for ; Mon, 29 Dec 2008 04:25:13 -0800 (PST) To: Subject: Why did you leave me? From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081229122513.A5B743A6C29@core3.amsl.com> Date: Mon, 29 Dec 2008 04:25:13 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mirror@aft.com.tw Mon Dec 29 10:57:22 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3BFB3A69A9 for ; Mon, 29 Dec 2008 10:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -30.786 X-Spam-Level: X-Spam-Status: No, score=-30.786 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUdxdtRPq9pY for ; Mon, 29 Dec 2008 10:57:22 -0800 (PST) Received: from h94-75-6-178.ufamts.ru (h94-75-6-178.ufamts.ru [94.75.6.178]) by core3.amsl.com (Postfix) with SMTP id 8BA343A6986 for ; Mon, 29 Dec 2008 10:57:21 -0800 (PST) To: Subject: failure notice From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081229185721.8BA343A6986@core3.amsl.com> Date: Mon, 29 Dec 2008 10:57:21 -0800 (PST) About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

C2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052 From dellnotebooks2008@gmail.com Mon Dec 29 15:48:16 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FE3728C252; Mon, 29 Dec 2008 15:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.42 X-Spam-Level: **** X-Spam-Status: No, score=4.42 tagged_above=-999 required=5 tests=[AWL=0.790, BAYES_50=0.001, RCVD_IN_SBL=1.551, 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 c0CbvTbA6c3Z; Mon, 29 Dec 2008 15:48:15 -0800 (PST) Received: from maildcarg4.dc-host.net.ar (maildcarg4.dc-host.net.ar [200.55.6.135]) by core3.amsl.com (Postfix) with ESMTP id A59893A684C; Mon, 29 Dec 2008 15:48:15 -0800 (PST) Received: from f3t ([190.245.2.190]) by maildcarg4.dc-host.net.ar (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0KCK000X5YH2PB90@maildcarg4.dc-host.net.ar>; Sun, 28 Dec 2008 06:31:51 -0300 (ART) Date: Sun, 28 Dec 2008 07:32:01 +0100 From: "dellnotebooks2008@gmail.com" Subject: ESPECIAL NAVIDAD! To: notes Message-id: <389-22008120286321406@f3t> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable EL MEJOR PRECIO!! 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: dellnotebooks2008@gmail=2Ecom 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 y Sistema Operativo en Espa=F1ol Precio: $2499 From kasd@amscrew.cl Tue Dec 30 10:06:21 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDC323A6919 for ; Tue, 30 Dec 2008 10:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.805 X-Spam-Level: X-Spam-Status: No, score=-8.805 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+qw1+iq2PSa for ; Tue, 30 Dec 2008 10:06:21 -0800 (PST) Received: from accela.net (unknown [88.241.88.75]) by core3.amsl.com (Postfix) with SMTP id AE0AD3A690F for ; Tue, 30 Dec 2008 10:06:18 -0800 (PST) To: Subject: Enhance your masculine power From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081230180619.AE0AD3A690F@core3.amsl.com> Date: Tue, 30 Dec 2008 10:06:18 -0800 (PST)


Please do not reply to this email. To contact Armstrong Shank Advertising, please visit us

This email message was sent to . If you do not wish to receive further communications from Armstrong Shank Advertising, click here to unsubscribe.

If you've experience any difficulty in being removed from a Armstrong Shank Advertising email list, click here for personalized help.

Copyright © 2008 Armstrong Shank Advertising, Inc. All rights reserved.
7450 S Seneca, Haysville, KS 67060

From kouxiaogang@3ming.net Wed Dec 31 05:28:35 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E06643A6821 for ; Wed, 31 Dec 2008 05:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.768 X-Spam-Level: X-Spam-Status: No, score=-14.768 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0t9MksBd8+LI for ; Wed, 31 Dec 2008 05:28:35 -0800 (PST) Received: from 83-238-239-60.adsl.inetia.pl (83-238-239-60.adsl.inetia.pl [83.238.239.60]) by core3.amsl.com (Postfix) with SMTP id 245F03A6358 for ; Wed, 31 Dec 2008 05:28:28 -0800 (PST) To: Subject: We seek for you all day! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081231132830.245F03A6358@core3.amsl.com> Date: Wed, 31 Dec 2008 05:28:28 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage.