From julienl@qualcomm.com Fri Oct 2 10:10:57 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11E843A685F for ; Fri, 2 Oct 2009 10:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.617 X-Spam-Level: X-Spam-Status: No, score=-103.617 tagged_above=-999 required=5 tests=[AWL=-1.018, 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 VevxiElO-SjT for ; Fri, 2 Oct 2009 10:10:55 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 5F50A3A67B0 for ; Fri, 2 Oct 2009 10:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1254503543; x=1286039543; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"mext@ietf.org"=20|Date:=20Fri,=202 =20Oct=202009=2010:12:18=20-0700|Subject:=20Fwd:=2010th =20TAHI=20IPv6=20Interoperability=20test=20event |Thread-Topic:=20Fwd:=2010th=20TAHI=20IPv6=20Interoperabi lity=20test=20event|Thread-Index:=20AcpDg38XeNcLZBR0SE6nA L1glKuSSQ=3D=3D|Message-ID:=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,5759"=3B=20a=3D"24483475"; bh=wlHP3c2H5SMWqL3rFstqc57//RtC3yIK0ptQNmydNlg=; b=BBgAvrGL3rdCrZOUFS9sQ3L5tK2PP0cZ1VUonEaCrJwB62E/OtbN6Zog 7HI35BgrX3s4rqo3qqcKYdCl9H6+dQHMtzAegZbblKp03z9/qrVpjx8kb Yf4PeWAZY+J9kbvilw2jvbvyOy46M7NZE4XLJYT8u18iILfXWwtBB3LMg o=; X-IronPort-AV: E=McAfee;i="5300,2777,5759"; a="24483475" 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; 02 Oct 2009 10:12:23 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n92HCNWG027140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 2 Oct 2009 10:12:23 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n92HCM8c012272 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 2 Oct 2009 10:12:23 -0700 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 2 Oct 2009 10:12:22 -0700 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.639.14; Fri, 2 Oct 2009 10:12:22 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Fri, 2 Oct 2009 10:12:22 -0700 From: "Laganier, Julien" To: "mext@ietf.org" Date: Fri, 2 Oct 2009 10:12:18 -0700 Thread-Topic: Fwd: 10th TAHI IPv6 Interoperability test event Thread-Index: AcpDg38XeNcLZBR0SE6nAL1glKuSSQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MEXT] Fwd: 10th TAHI IPv6 Interoperability test event X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 17:10:57 -0000 FYI - there's an upcoming IPv6 TAHI event that includes IPv6 mobility proto= cols IOT. --julien >Hi, all. > >TAHI Project would like to announce about holding 10th TAHI IPv6=20 >Interoperability test event. > > Date: Jan. 25-29, 2010 > Venue: Makuhari Messe, Makuhari, Japan > Target: Conformance & Interoperability tests > > * IPv6 Ready Logo Program Phase-2 > o IPv6 Core Protocols > o IPsec > o IKEv2 > o MIPv6 > o NEMO Basic Support > o DHCPv6 > o SIP > o SNMP (TBD) > o MLDv2 (router only) > o IMS (Trial) (UE only) > * Others > o KINK > o DNS > o MLDv2 (listener only) > >Registration has been started now. > >If you are interested in participating, please visit=20 > to get details. > >Best regards, > >-- >Yukiyo Akisada From rfc-editor@rfc-editor.org Fri Oct 2 17:21:39 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A501B3A6906; Fri, 2 Oct 2009 17:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.606 X-Spam-Level: X-Spam-Status: No, score=-16.606 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biFq0BEouR8T; Fri, 2 Oct 2009 17:21:38 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id C81F53A67DD; Fri, 2 Oct 2009 17:21:38 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 10C6F335638; Fri, 2 Oct 2009 17:22:01 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20091003002201.10C6F335638@bosco.isi.edu> Date: Fri, 2 Oct 2009 17:22:01 -0700 (PDT) Cc: mext@ietf.org, rfc-editor@rfc-editor.org Subject: [MEXT] RFC 5648 on Multiple Care-of Addresses Registration X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 00:21:39 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5648 Title: Multiple Care-of Addresses Registration Author: R. Wakikawa, Ed., V. Devarapalli, G. Tsirtsis, T. Ernst, K. Nagami Status: Standards Track Date: October 2009 Mailbox: ryuji.wakikawa@gmail.com, vijay@wichorus.com, Tsirtsis@gmail.com, thierry.ernst@inria.fr, nagami@inetcore.com Pages: 36 Characters: 90112 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-monami6-multiplecoa-14.txt URL: http://www.rfc-editor.org/rfc/rfc5648.txt According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses but only one, called the primary care-of address, can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by mobile routers using the NEMO (Network Mobility) Basic Support protocol as well. [STANDARDS TRACK] This document is a product of the Mobility EXTensions for IPv6 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From julienl@qualcomm.com Tue Oct 6 07:35:12 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 547D43A68E8 for ; Tue, 6 Oct 2009 07:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.591 X-Spam-Level: X-Spam-Status: No, score=-103.591 tagged_above=-999 required=5 tests=[AWL=-0.992, 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 dxHHBSgDA7L6 for ; Tue, 6 Oct 2009 07:35:11 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 8E1873A69CF for ; Tue, 6 Oct 2009 07:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1254839806; x=1286375806; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"mext@ietf.org"=20|Date:=20Tue,=206 =20Oct=202009=2007:36:20=20-0700|Subject:=20FW:=20MEXT=20 -=20Requested=20sessions=20have=20been=20scheduled=20for =20IETF=2076=20|Thread-Topic:=20MEXT=20-=20Requested=20se ssions=20have=20been=20scheduled=20for=20IETF=2076=20 |Thread-Index:=20AcpGJZV/8rogheZSQ6aG6uONI006hAAbLYEg |Message-ID:=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"utf-8" |Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5762"=3B=20 a=3D"24636272"; bh=LbCrpGtorJtHtPWB1MDe4zExOTjjmQw5+TfrkM6jBoI=; b=ANxOM7nfdRp8Q4XirjOMEjBT6mAG43AyeHunczQitDTrI5DxhM/E/AcI ObV4KbZvZ6IO++ECadQzPFE93I/Vmz/SbWUDWm2sdQhECnh8QGLCgbNOf mjRdLG5lkhZBKvt89Kn5cI4YiB0qOBidRYUNQAqxzzsx9HwkssX9gb2Nl M=; X-IronPort-AV: E=McAfee;i="5300,2777,5762"; a="24636272" 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; 06 Oct 2009 07:36:31 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n96EaUpp013518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 6 Oct 2009 07:36:30 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n96EaU3O003366 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 6 Oct 2009 07:36:30 -0700 (PDT) Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 6 Oct 2009 07:36:29 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Tue, 6 Oct 2009 07:36:29 -0700 From: "Laganier, Julien" To: "mext@ietf.org" Date: Tue, 6 Oct 2009 07:36:20 -0700 Thread-Topic: MEXT - Requested sessions have been scheduled for IETF 76 Thread-Index: AcpGJZV/8rogheZSQ6aG6uONI006hAAbLYEg Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [MEXT] FW: MEXT - Requested sessions have been scheduled for IETF 76 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 14:35:12 -0000 RllJDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJRVRGIFNlY3JldGFyaWF0 IFttYWlsdG86YWdlbmRhQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgT2N0b2JlciAwNSwgMjAw OSA2OjM2IFBNDQpUbzogTGFnYW5pZXIsIEp1bGllbg0KQ2M6IG1hcmNlbG9AaXQudWMzbS5lczsg cmRyb21zQGNpc2NvLmNvbTsgamFyaS5hcmtrb0BwaXVoYS5uZXQ7IHNlc3Npb24tcmVxdWVzdEBp ZXRmLm9yZw0KU3ViamVjdDogTUVYVCAtIFJlcXVlc3RlZCBzZXNzaW9ucyBoYXZlIGJlZW4gc2No ZWR1bGVkIGZvciBJRVRGIDc2IA0KDQpEZWFyIEp1bGllbiBMYWdhbmllciwNCg0KVGhlIHNlc3Np b25zIHRoYXQgeW91IGhhdmUgcmVxdWVzdGVkIGhhdmUgYmVlbiBzY2hlZHVsZWQuDQpCZWxvdyBp cyB0aGUgc2NoZWR1bGVkIHNlc3Npb24gaW5mb3JtYXRpb24gZm9sbG93ZWQgYnkgDQp0aGUgaW5m b3JtYXRpb24gb2Ygc2Vzc2lvbnMgdGhhdCB5b3UgaGF2ZSByZXF1ZXN0ZWQuDQoNCk1FWFQgU2Vz c2lvbiAxICgxLjUgaG91cnMpDQpUdWVzZGF5LCBBZnRlcm5vb24gU2Vzc2lvbiBJSSAxNTIwLTE3 MDANClJvb20gTmFtZTogT3JjaGlkIDINCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCk1FWFQgU2Vzc2lvbiAyICgxLjUgaG91cnMpDQpGcmlkYXksIEFmdGVy bm9vbiBTZXNzaW9uIEkgMTMwMC0xNDAwDQpSb29tIE5hbWU6IE9yY2hpZCAyDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQpSZXF1ZXN0ZWQgSW5m b3JtYXRpb246DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpXb3JraW5nIEdyb3VwIE5hbWU6IG1leHQNCkFyZWEgTmFtZTogSW50 ZXJuZXQgQXJlYQ0KU2Vzc2lvbiBSZXF1ZXN0ZXI6IEp1bGllbiBMYWdhbmllcg0KDQpOdW1iZXIg b2YgU2Vzc2lvbnM6IDINCkxlbmd0aCBvZiBTZXNzaW9uKHMpOiAgMS41IGhvdXJzDQogICAgICAg ICAgICAgICAgICAgICAgIDEuNSBob3Vycw0KICAgICAgICAgICAgICAgICAgICAgICANCk51bWJl ciBvZiBBdHRlbmRlZXM6IDI1MA0KQ29uZmxpY3RzIHRvIEF2b2lkOg0KICBGaXJzdCBQcmlvcml0 eTogIGJ0bnMgc2hpbTYgbmV0bG1tIG5ldGV4dCBjc2kgYmVoYXZlIHNhdmkgZG5zZXh0DQogIFNl Y29uZCBQcmlvcml0eTogIDE2bmcgNmxvd3BhbiA2bWFuIGF1dG9jb25mIGRuYSBpbnRhcmVhIG1h bmV0IG1pcDQgbWlwc2hvcCBoaXANCiAgQk9GIG9yIElSVEYgU2Vzc2lvbjogTVBUQ1AgQk9GOyBt dWx0aW1vYiBXRyBpZiBjcmVhdGVkLg0KDQpTcGVjaWFsIFJlcXVlc3RzOg0KICANCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg== From marcelo@it.uc3m.es Tue Oct 6 08:39:20 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A143A68A1 for ; Tue, 6 Oct 2009 08:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 1rM8FR0DklsC for ; Tue, 6 Oct 2009 08:39:18 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 48E553A68DA for ; Tue, 6 Oct 2009 08:39:16 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id 7F0A3BA509F; Tue, 6 Oct 2009 17:40:52 +0200 (CEST) Message-ID: <4ACB6504.8060301@it.uc3m.es> Date: Tue, 06 Oct 2009 17:40:52 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: mext , "Laganier, Julien" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16930.003 Subject: [MEXT] Call for presentations X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 15:39:20 -0000 Hi, We have scheduled a meeting for the IETF76. If you want a slot for making a presentation, please let us know. Regards, marcelo From charles.perkins@earthlink.net Tue Oct 6 11:47:37 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B8C928C103 for ; Tue, 6 Oct 2009 11:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_20=-0.74, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49oB+TpJx3qS for ; Tue, 6 Oct 2009 11:47:35 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id CE55E28C0FF for ; Tue, 6 Oct 2009 11:47:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=snCzWFwsKrvtWNRE09ok8TNMTLImhAVbQ6h9D+FJR89Ue5pPFtG07sglkNI9ifr+; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.15]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MvF5z-0003EX-QQ; Tue, 06 Oct 2009 14:49:12 -0400 Message-ID: <4ACB9125.4050706@earthlink.net> Date: Tue, 06 Oct 2009 11:49:09 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Arnaud Ebalard References: <87iqfyq4h0.fsf@small.ssi.corp> In-Reply-To: <87iqfyq4h0.fsf@small.ssi.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f520deb1353ac236b92fcbc46271ec51ef5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "mext@ietf.org" Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 18:47:37 -0000 Hello Arnaud, Thanks for the terrific review and many suggestions. I have been owing you a response on the specific questions and issues you raised. So, here goes... Arnaud Ebalard wrote: > >> A Binding Acknowledgement is used to acknowledge receipt of a >> Binding Update, if an acknowledgement was requested in the Binding >> Update, the binding update was sent to a home agent, or an error >> occurred. >> > > As a binding update sent to a Home Agent must have the A bit set > (i.e. "an acknowledgement was requested in the Binding Update" as > stated above), a BA is always sent by the HA. This means the "the > binding update was sent to a home agent" is redundant in previous > paragraph. > How about: if an acknowledgement was requested in the Binding Update (e.g., the binding update was sent to a home agent), or an error occurred. > > >> attachment to other sites, resulting in possible unrechability >> between the MN and the HA, when unique-local IPv6 routable addresses >> are used as care-of addresses. Also, CNs outside the MN's own site >> are not going to be reachable when unique-local IPv6 routable >> addresses are used as home addresses. Therefore, unique-local IPv6 >> unicast addresses SHOULD NOT be used as home or care-of addresses. >> > > If this is the only address usable as a CoA for the node, it is worth > trying to use it. I tried and found some discussion on the list about > this topic but failed (I thought it had been discussed). Can someone > give me some feedback on the reason it is that way? > How about: unique-local IPv6 unicast addresses SHOULD NOT be used as home or care-of addresses if any other addresses are available to the mobile node. > > > As with all IPsec security associations in this specification, manual > configuration of security associations MUST be supported. The used > shared secrets MUST be random and unique for different mobile nodes, > and MUST be distributed off-line to the mobile nodes. > > Automatic key management with IKE [7] MAY be supported. When IKE > > > Any reason not to add a link to IKEv2 spec? > Will do. > >> Reference [15] contains a more detailed description and examples on >> using IPsec to protect the communications between the mobile node and >> the home agent. >> > > What about adding a link to 4877 too? > O.K. > > >> 5.3. Dynamic Home Agent Address Discovery >> >> No security is required for dynamic home agent address discovery. >> > > May be it is the way I understanded it but this sounds like "no security > is needed". It should sounds like "No security is provided for that > mechanism". > As I remember the discussion, it was more properly represented by the existing text. Perhaps opinions have changed in the meantime since this was originally written. It's been a while, but I think the sense of the discussion at that time was that DHAAD would only be used in environments where security was not a problem. > > > > >> This type provides the necessary functionality but does not open >> vulnerabilities discussed in Section 15.1. >> > > What about adding a link to RFC5095 here, i.e. "Section 15.1 and > [RFC5095]". > O.K. > >> 6.1.7. Binding Update Message >> >> The Binding Update (BU) message is used by a mobile node to notify >> other nodes of a new care-of address for itself. Binding Updates are >> sent as described in Section 11.7.1 and Section 11.7.2. >> >> The Binding Update uses the MH Type value 5. When this value is >> indicated in the MH Type field, the format of the Message Data field >> in the Mobility Header is as follows: >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence # | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |A|H|L|K| Reserved | Lifetime | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> . . >> . Mobility options . >> . . >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Acknowledge (A) >> >> The Acknowledge (A) bit is set by the sending mobile node to >> request a Binding Acknowledgement (Section 6.1.8) be returned upon >> receipt of the Binding Update. >> >> Home Registration (H) >> >> The Home Registration (H) bit is set by the sending mobile node to >> request that the receiving node should act as this node's home >> agent. The destination of the packet carrying this message MUST >> be that of a router sharing the same subnet prefix as the home >> address of the mobile node in the binding. >> > > This prevents the MN to communicates with the HA on another > interface. Is there any reason for that limitation, i.e. not having a > SHOULD here instead of a MUST. Or I should ask, what is the reason to > have a MUST here. > I couldn't think of a reason against using SHOULD instead of MUST. However, I don't remember anyone asking for this feature, and unless there is a reason to make the change, I would not relax that mandate. > For instance, the main connectivity of the home agent can be provided by > a given provided (symmetric line) while the MN are on a subnet for which > the prefix is provided by another provider. That way, the download > bandwidth used by the MNs is not shared with the upload bandwidth: > > ISP1 -- home subnet ---[HA]--- ISP2 > In this picture, do you mean that the MN has a home address from ISP2, and it should be able to send a packet to the home agent via a destination address from ISP1? Seems a bit roundabout to me, but still it could be made workable, and one could establish a cost structure for the network which would favor the alternate control signal path. But are there really such networks that need this solution? > >> ... >> The deletion of a binding can be indicated by setting the Lifetime >> field to 0 and by setting the care-of address equal to the home >> address. In deletion, the generation of the binding management key >> depends exclusively on the home keygen token, as explained in >> Section 5.2.5. (Note that while the senders are required to set both >> the Lifetime field to 0 and the care-of address equal to the home >> address, Section 9.5.1 rules for receivers are more liberal, and >> interpret either condition as a deletion.) >> > > For the records: > > There is no rationale for explicitly providing different behavior for > senders and receivers. The various rules associated with what can and > should be done on that aspects are spread at various places in the > spec. I already discussed that in draft-ebalard-mext-hld-security-00. > I'm not sure what to do to resolve your issue. Your first sentence is, in the abstract, incorrect; for example, we are exhorted to be conservative in what we send, but liberal in what we accept. So, a bit more justification would be needed before making any such wholesale changes. I'm reluctant to absorb text from your draft without more discussion. Do you propose any specific changes for this matter? > > > > >> >> Home Address >> >> The Home Address of the destination Mobile Node. >> >> For a type 2 routing header, the Hdr Ext Len MUST be 2. The Segments >> Left value describes the number of route segments remaining; i.e., >> number of explicitly listed intermediate nodes still to be visited >> before reaching the final destination. Segments Left MUST be 1. The >> ordering rules for extension headers in an IPv6 packet are described >> in Section 4.1 of RFC 2460 [8]. The type 2 routing header defined >> for Mobile IPv6 follows the same ordering as other routing headers. >> If both a type 0 and a type 2 routing header are present, the type 2 >> routing header should follow the other routing header. A packet >> containing such nested encapsulation should be created as if the >> inner (type 2) routing header was constructed first and then treated >> as an original packet by the outer (type 0) routing header >> construction process. >> > > Considering deprecation of RH0 by RFC 5095, it may be worth modifying > this paragraph to reflect that, for instance by stating that except > otherwise specified, the RH2 should be the last one in the set of RH > (i.e. removing the reference to the specific 'Type 0'). > O.K. How about: The type 2 routing header defined for Mobile IPv6 follows the same ordering as other routing headers. If another routing header is present along with a type 2 routing header, the type 2 routing header should follow the other routing header. A packet containing such nested encapsulation should be created as if the inner (type 2) routing header was constructed first and then treated as an original packet by header construction process for the other routing header. > > > >> ...... when >> sending unsolicited multicast Router Advertisements more frequently >> than the limit specified in RFC 4861 [20], the sending router need >> > > s/RFC 4861 [20]/Neighbor Discovery [20]/ > > IMHO, this is easier to read. Note that there are various places in the > document where the replacement should be done. > I'd be happier if you could point them out. > > >> 8.4. IPv6 Home Agents >> >> In order for a mobile node to operate correctly while away from home, >> at least one IPv6 router on the mobile node's home link must function >> as a home agent for the mobile node. The following additional >> requirements apply to all IPv6 routers that serve as a home agent: >> >> o Every home agent MUST be able to maintain an entry in its Binding >> Cache for each mobile node for which it is serving as the home >> agent (Section 10.1 and Section 10.3.1). >> >> o Every home agent MUST be able to intercept packets (using proxy >> Neighbor Discovery [20]) addressed to a mobile node for which it >> > > No opinion on whether this is a good idea or not, but probably worth > asking: what about also adding a reference to RFC 4389 (experimental > doc)? > What is the advantage of making the citation? > >> >> o The node MAY support stateful address autoconfiguration mechanisms >> such as DHCPv6 [32] on the interface represented by the tunnel to >> the home agent. >> > > How is that supposed to happen/work? Is that to support provisioning of > *additional* addresses (not HoA) from the Home Network? It is unclear. > What if (a) the mobile node gets an address from DHCP and then (b) runs IKE with its home agent? How should the statement be made clearer? > >> 9. Correspondent Node Operation >> >> 9.1. Conceptual Data Structures >> >> ... >> o A lifetime value, indicating the remaining lifetime for this >> Binding Cache entry. The lifetime value is initialized from the >> Lifetime field in the Binding Update that created or last modified >> this Binding Cache entry. >> > > Lifetime may be the one sent in the BA in fact or am i missing sth? > I reckon so. I could add a sentence: o A lifetime value, indicating the remaining lifetime for this Binding Cache entry. The lifetime value is initialized from the Lifetime field in the Binding Update that created or last modified this Binding Cache entry. The correspondent node MAY select a smaller lifetime for the Binding Cache entry, and supply that value to the mobile node in the Binding Acknowledgment message. >> 9.5.1. Receiving Binding Updates >> >> Before accepting a Binding Update, the receiving node MUST validate >> the Binding Update according to the following tests: >> >> ... >> When the Home Registration (H) bit is not set, the following are also >> required: >> >> .... >> >> If the Home Registration (H) bit is set, the Nonce Indices mobility >> option MUST NOT be present. >> > > The binding auth data must not be present either in that case. > ...? I don't think that is true. > >> >> o If the Lifetime specified in the Binding Update is zero, then this >> is a request to delete the cached binding for the home address. >> If the Home Registration (H) bit is set in the Binding Update, the >> Binding Update is processed according to the procedure specified >> in Section 10.3.1; otherwise, it is processed according to the >> procedure specified in Section 9.5.2. >> > > > That item deals with *deletion* but points to sections associated with > requests to cache a binding (10.3.1 and 9.5.2). The first sentence > should be "If the Lifetime specified in the Binding Update is *not* > zero, then this is a request to *cache a binding* for the home > address". Otherwise, it does not make sense and is duplicate w/ next > item > Good catch! I reckon you are correct. I wonder how that bug stayed in the specification for so long! > > > >> 10.3.1. Primary Care-of Address Registration >> >> When a node receives a Binding Update, it MUST validate it and >> determine the type of Binding Update according to the steps described >> in Section 9.5.1. Furthermore, it MUST authenticate the Binding >> Update as described in Section 5.1. An authorization step specific >> for the home agent is also needed to ensure that only the right node >> can control a particular home address. This is provided through the >> home address unequivocally identifying the security association that >> must be used. >> >> This section describes the processing of a valid and authorized >> Binding Update when it requests the registration of the mobile node's >> primary care-of address. >> >> To begin processing the Binding Update, the home agent MUST perform >> the following sequence of tests: >> >> o If the node implements only correspondent node functionality, or >> has not been configured to act as a home agent, then the node MUST >> reject the Binding Update. The node MUST also return a Binding >> Acknowledgement to the mobile node, in which the Status field is >> set to 131 (home registration not supported). >> >> o Else, if the home address for the binding (the Home Address field >> in the packet's Home Address option) is not an on-link IPv6 >> address with respect to the home agent's current Prefix List, then >> the home agent MUST reject the Binding Update and SHOULD return a >> Binding Acknowledgement to the mobile node, in which the Status >> field is set to 132 (not home subnet). >> >> o Else, if the home agent chooses to reject the Binding Update for >> any other reason (e.g., insufficient resources to serve another >> mobile node as a home agent), then the home agent SHOULD return a >> Binding Acknowledgement to the mobile node, in which the Status >> field is set to an appropriate value to indicate the reason for >> the rejection. >> >> o A Home Address destination option MUST be present in the message. >> It MUST be validated as described in Section 9.3.1 with the >> following additional rule. >> > > When coming back home, the Home Address destination option may be > omitted in fact. > But this is a section dealing with registering a care-of-address, not deregistering it. > > > >> attempt to intercept packets on the mobile node's home link that are >> addressed to the mobile node. >> >> In order to do this, when a node begins serving as the home agent it >> MUST multicast onto the home link a Neighbor Advertisement message >> [20] on behalf of the mobile node. >> > > As specified in section 10.3.1: > > Unless this home agent already has a binding for the given home > address, the home agent MUST perform Duplicate Address Detection [21] > on the mobile node's home link before returning the Binding > Acknowledgement. > > So, the last sentence should be modified to indicate that the NA is sent > only after that initial DAD. > One could argue that the node doesn't begin serving as a home agent until after DAD is finished. But, if you would like to propose some better text, I am open to suggestion. > >> >> While a node is serving as a home agent for some mobile node, the >> home agent uses IPv6 Neighbor Discovery [20] to intercept unicast >> packets on the home link addressed to the mobile node. In order to >> intercept packets in this way, the home agent MUST act as a proxy for >> this mobile node and reply to any received Neighbor Solicitations for >> it. When a home agent receives a Neighbor Solicitation, it MUST >> check if the Target Address specified in the message matches the >> address of any mobile node for which it has a Binding Cache entry >> marked as a home registration. >> > > Need for a link to 4389 here too? > I still didn't exactly see why... > >> 10.4.2. Processing Intercepted Packets >> >> For any packet sent to a mobile node from the mobile node's home >> agent (in which the home agent is the original sender of the packet), >> the home agent is operating as a correspondent node of the mobile >> node for this packet and the procedures described in Section 9.3.2 >> apply. The home agent then uses a routing header to route the packet >> to the mobile node by way of the primary care-of address in the home >> agent's Binding Cache. >> >> While the mobile node is away from home, the home agent intercepts >> any packets on the home link addressed to the mobile node's home >> address, as described in Section 10.4.1. In order to forward each >> intercepted packet to the mobile node, the home agent MUST tunnel the >> packet to the mobile node using IPv6 encapsulation [9]. When a home >> agent encapsulates an intercepted packet for forwarding to the mobile >> node, the home agent sets the Source Address in the new tunnel IP >> header to the home agent's own IP address and sets the Destination >> Address in the tunnel IP header to the mobile node's primary care-of >> address. When received by the mobile node, normal processing of the >> tunnel header [9] will result in decapsulation and processing of the >> original packet by the mobile node. >> >> However, packets addressed to the mobile node's link-local address >> MUST NOT be tunneled to the mobile node. Instead, these packets MUST >> be discarded and the home agent SHOULD return an ICMP Destination >> Unreachable, Code 3, message to the packet's Source Address (unless >> this Source Address is a multicast address). >> > > I am certainly missing something here, but what is the point for the HA > in defending the IP then? > So that no other node will steal the mobile node's link-local address. The mobile node would like to have it back when it returns to the home network. > >> where MaxMobPfxAdvInterval is as defined in Section 12. Then compute >> the final delay for the advertisement: >> >> >> RAND_ADV_DELAY = MinMobPfxAdvInterval + >> (rand() % abs(MaxScheduleDelay - MinMobPfxAdvInterval)) >> >> Here rand() returns a random integer value in the range of 0 to the >> maximum possible integer value. This computation is expected to >> alleviate bursts of advertisements when prefix information changes. >> In addition, a home agent MAY further reduce the rate of packet >> transmission by further delaying individual advertisements, when >> necessary to avoid overwhelming local network resources. The home >> agent SHOULD periodically continue to retransmit an unsolicited >> Advertisement to the mobile node, until it is acknowledged by the >> receipt of a Mobile Prefix Solicitation from the mobile node. >> > > seems weird. > As I remember, this was considered very cool at the time. I don't remember why, but unless there is a need for change I'd rather not go back and figure it out. > >> 11. Mobile Node Operation >> >> 11.1. Conceptual Data Structures >> >> >> >> o The remaining lifetime of that binding. This lifetime is >> initialized from the Lifetime value sent in the Binding Update and >> is decremented until it reaches zero, at which time this entry >> MUST be deleted from the Binding Update List. >> > > Updated by the BA. > > But, I think the BA can only decrease the lifetime, right? So it would still be a further decrementation. > >> 11.3.2. Interaction with Outbound IPsec Processing >> >> ... >> >> The Key Management Mobility Capability (K) bit in Binding Updates and >> Acknowledgements can be used to avoid the need to rerun IKE upon >> movements. >> > > Considering the mechanism is implemented and such an interface needed to > support that, 3775bis could at least point MIGRATE doc given below as an > informational reference document. This clarifies the need and gives a > possible solution. > > http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00 > Can we do this safely without having the citation to be considered normative? > > > > >> 11.4.3. Receiving Mobile Prefix Advertisements >> >> Section 10.6 describes the operation of a home agent to support boot >> time configuration and renumbering a mobile node's home subnet while >> the mobile node is away from home. The home agent sends Mobile >> Prefix Advertisements to the mobile node while away from home, giving >> "important" Prefix Information options that describe changes in the >> prefixes in use on the mobile node's home link. >> >> The Mobile Prefix Solicitation is similar to the Router Solicitation >> used in Neighbor Discovery [20], except it is routed from the mobile >> node on the visited network to the home agent on the home network by >> usual unicast routing rules. >> >> When a mobile node receives a Mobile Prefix Advertisement, it MUST >> validate it according to the following test: >> >> o The Source Address of the IP packet carrying the Mobile Prefix >> Advertisement is the same as the home agent address to which the >> mobile node last sent an accepted home registration Binding Update >> to register its primary care-of address. Otherwise, if no such >> registrations have been made, it SHOULD be the mobile node's >> stored home agent address, if one exists. Otherwise, if the >> mobile node has not yet discovered its home agent's address, it >> MUST NOT accept Mobile Prefix Advertisements. >> >> o The packet MUST have a type 2 routing header and SHOULD be >> protected by an IPsec header as described in Section 5.4 and >> Section 6.8. >> >> o If the ICMP Identifier value matches the ICMP Identifier value of >> the most recently sent Mobile Prefix Solicitation and no other >> advertisement has yet been received for this value, then the >> advertisement is considered to be solicited and will be processed >> further. >> >> Otherwise, the advertisement is unsolicited, and MUST be >> discarded. In this case the mobile node SHOULD send a Mobile >> Prefix Solicitation. >> > > I tried and raise a clarification on that point: > > See http://permalink.gmane.org/gmane.ietf.mip6/9433 > > but got no response. IMHO, clarifying things a bit would help. > How about: Otherwise, the advertisement is unsolicited, and MUST be discarded. In this case the mobile node SHOULD send a Mobile Prefix Solicitation, using the same ICMPv6 identifier that was used for the previous Solicitation. > >> 11.5.2. Home Link Detection >> >> When an MN detects that it has arrived on a new link using the >> movement detection algorithm in use (Section Section 11.5.1,) it >> performs the following steps to determine if it is on the home link. >> >> o The MN performs the procedure described in Section 11.5.2x and >> > > s/11.5.2x/11.5.2/ > > Then, it seems that 11.5.2 is current section. Weird. > > I reckon this ought to be 11.5.3. >> configures an address. It also keeps track of all the on-link >> prefix(es) received in the RA along with their prefix lengths. >> >> o If the home prefix has not been statically configured the MN uses >> some form of bootstrapping procedure (e.g. RFC5026 [25]) to >> determine the home prefix. >> >> o Given the availability of the home prefix, the MN checks whether >> or not the home prefix matches one of the prefixes received in the >> RA. If it does, the MN concludes that it has returned home. >> > > It should be stated here or in the "Security Considerations" section > that this procedure is insecure and may have security impact, as we rely > on basic ND and undergo associated threats. This is documented: > > http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00 > I could put some advice in the Security Considerations section and a cross reference here. If you happen to have a short paragraph of text that you wanted to contribute for that purpose, it would be appreciated. > > > > >> the previously registered care-of address. >> >> In this home registration, the mobile node MUST set the Acknowledge >> (A) and Home Registration (H) bits, set the Lifetime field to zero, >> and set the care-of address for the binding to the mobile node's own >> home address. The mobile node MUST use its home address as the >> source address in the Binding Update. >> > > Processing for receiver allows either lft=0 or CoA == HoA; so what's the > point in that MUST. > Well, it's been there for a long time, and I don't know if it would be worthwhile to change. It might break various interoperability tests, for one thing. > > > > >> 15. Security Considerations >> > > Considering this is documented: > > http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00 > > the possible specific insecurity of the Home Link Detection mechanism > could be referenced in that section. > > > > > >> 15.7. Tunneling via the Home Agent >> >> >> When site local home addresses are used, reverse tunneling can be >> used to send site local traffic from another location. >> Administrators should be aware of this when allowing such home >> addresses. In particular, the outer IP address check described above >> is not sufficient against all attackers. The use of encrypted >> tunnels is particularly useful for these kinds of home addresses. >> > > In previous paragraph, reference to site local (deprecated) should be > replaced by a reference to Unique Local Addresses (RFC4193). > O.K. > >> 16. Contributors >> >> Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik Nordmark, >> and Michael Thomas worked on the return routability protocols >> eventually led to the procedures used in this protocol. >> > > In previous sentence, s/worked/work/ > > > I think some other people were involved -- and this was a very contentious time in the working group. How about: Work done by Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik Nordmark, and Michael Thomas on the return routability protocols shaped the procedures used in this protocol. Regards, Charlie P. From julienl@qualcomm.com Tue Oct 6 16:28:52 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 586AB28C22E for ; Tue, 6 Oct 2009 16:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.567 X-Spam-Level: X-Spam-Status: No, score=-105.567 tagged_above=-999 required=5 tests=[AWL=1.032, 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 H3IlEa7oXAeo for ; Tue, 6 Oct 2009 16:28:51 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 5411528C21F for ; Tue, 6 Oct 2009 16:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1254871828; x=1286407828; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"mext@ietf.org"=20|Date:=20Tue,=206 =20Oct=202009=2016:30:24=20-0700|Subject:=20[WGLC]=20draf t-ietf-mext-flow-binding-03|Thread-Topic:=20[WGLC]=20draf t-ietf-mext-flow-binding-03|Thread-Index:=20AcpG3PrETCpXf QpNQraj6B7QmoF8mw=3D=3D|Message-ID:=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,5763"=3B=20a=3D"24655426"; bh=Hk+ActeCG+VSoF2ySxnNFjkxKxuSrv35aEBpytHwcOM=; b=TrKZPca5FO/5e0T9cSNYow/1FthxmzOcZzBNH/J1kwXjDodUxpUds1Ns PBSvxxFFZmbQtqsj2jQvp/h6K0f54XZ5K69YRIHWRSqLmK4PpofBi38bV +phgxFm/vx2ztouK4i8A5NWsf+zoCd6aiNDZYKX0pYLj7RoIPbg7zGx8S o=; X-IronPort-AV: E=McAfee;i="5300,2777,5763"; a="24655426" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Oct 2009 16:30:27 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n96NURmE028285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 6 Oct 2009 16:30:27 -0700 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 n96NUQvY027087 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 6 Oct 2009 16:30:27 -0700 (PDT) Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 6 Oct 2009 16:30:27 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Tue, 6 Oct 2009 16:30:26 -0700 From: "Laganier, Julien" To: "mext@ietf.org" Date: Tue, 6 Oct 2009 16:30:24 -0700 Thread-Topic: [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpG3PrETCpXfQpNQraj6B7QmoF8mw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 23:28:52 -0000 Folks, Hereby we're starting a two weeks WGLC on our "Flow Bindings in Mobile IPv6= and NEMO Basic Support" document, available at the following URL: Please review the specification, post your comments to the mailing list, an= d state whether or not you think the document is ready to be forwarded to I= ESG before 2009-10-20 6:00PM PST. =20 Thank you for your support. =20 --julien & marcelo, MEXT chairs From arno@natisbad.org Wed Oct 7 02:40:54 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1B53A689F for ; Wed, 7 Oct 2009 02:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 9rlrG6EJi3aj for ; Wed, 7 Oct 2009 02:40:48 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 3B2A63A6826 for ; Wed, 7 Oct 2009 02:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natisbad.org; s=mail; h=From:To:Cc:Subject:References:Date: Message-ID:MIME-Version:Content-Type; bh=Y1mWstUUfysjHQHbV3qhWbc Kjojwp4Ju87Rj0CeVlRQ=; b=u4xU3/DSva+1u4sxHE8qOAD5tqblRLbvnPwM7zk YpCHsIKw4alm1sgTkmBY5qcM9tMZwVB57ufX9mWI6gfvMvYaKSd4EGhhNcf05upn VPYoE3ufbvjzGkSQymBalcHFZr2bmvuoAzdxgdIz9ew3cR0RWBWKch8Ej4hqHjgn OjGA= Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MvT2M-0004AL-4z; Wed, 07 Oct 2009 11:42:22 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "Charles E. Perkins" References: <87iqfyq4h0.fsf@small.ssi.corp> <4ACB9125.4050706@earthlink.net> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:091006:charles.perkins@earthlink.net::WUKkUypYDccj7RIk:000000000000000000000000000000000kjD X-Hashcash: 1:20:091006:mext@ietf.org::c02Fl3fEsP2NRnfa:00007FIR Date: Wed, 07 Oct 2009 11:42:50 +0200 Message-ID: <87fx9vzgit.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "mext@ietf.org" Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 09:40:55 -0000 Hi Charles, "Charles E. Perkins" writes: > Thanks for the terrific review and many suggestions. I have been > owing you a response on the specific questions and issues you > raised. So, here goes... Well, thanks for your work too. Iterating over and over on the spec must be a bit painful at some point. More fun below ... ;-) Note that I did not remove any text from your reply so that you can cross-check. >>> A Binding Acknowledgement is used to acknowledge receipt of a >>> Binding Update, if an acknowledgement was requested in the Binding >>> Update, the binding update was sent to a home agent, or an error >>> occurred. >>> >> >> As a binding update sent to a Home Agent must have the A bit set >> (i.e. "an acknowledgement was requested in the Binding Update" as >> stated above), a BA is always sent by the HA. This means the "the >> binding update was sent to a home agent" is redundant in previous >> paragraph. >> > > How about: > > if an acknowledgement was requested in the Binding > Update (e.g., the binding update was sent to a home agent), or an > error occurred. fine with me. >>> attachment to other sites, resulting in possible unrechability >>> between the MN and the HA, when unique-local IPv6 routable addresses >>> are used as care-of addresses. Also, CNs outside the MN's own site >>> are not going to be reachable when unique-local IPv6 routable >>> addresses are used as home addresses. Therefore, unique-local IPv6 >>> unicast addresses SHOULD NOT be used as home or care-of addresses. >>> >> >> If this is the only address usable as a CoA for the node, it is worth >> trying to use it. I tried and found some discussion on the list about >> this topic but failed (I thought it had been discussed). Can someone >> give me some feedback on the reason it is that way? >> > > How about: > > unique-local IPv6 > unicast addresses SHOULD NOT be used as home or care-of addresses > if any other addresses are available to the mobile node. I think it is better. But I wonder if there is a need to make some specific case for ULA. Basically, one would expect the MN to apply some kind of RFC 3484 logic to select the CoA to be used as source address for the connection with the HA (based on the HA address). I don't think there is a need to go that far in the description but I also don't think there is a need to make a specific case about ULA. IMHO, CoA selection is a local matter for the MN. >> As with all IPsec security associations in this specification, manual >> configuration of security associations MUST be supported. The used >> shared secrets MUST be random and unique for different mobile nodes, >> and MUST be distributed off-line to the mobile nodes. >> >> Automatic key management with IKE [7] MAY be supported. When IKE >> >> >> Any reason not to add a link to IKEv2 spec? >> > > Will do. > >> >>> Reference [15] contains a more detailed description and examples on >>> using IPsec to protect the communications between the mobile node and >>> the home agent. >>> >> >> What about adding a link to 4877 too? >> > O.K. >> >> >>> 5.3. Dynamic Home Agent Address Discovery >>> >>> No security is required for dynamic home agent address discovery. >>> >> >> May be it is the way I understanded it but this sounds like "no security >> is needed". It should sounds like "No security is provided for that >> mechanism". > > As I remember the discussion, it was more properly represented by the > existing text. Perhaps opinions have changed in the meantime since this > was originally written. It's been a while, but I think the sense of > the discussion at that time was that DHAAD would only be used in > environments where security was not a problem. ok. >>> This type provides the necessary functionality but does not open >>> vulnerabilities discussed in Section 15.1. >>> >> >> What about adding a link to RFC5095 here, i.e. "Section 15.1 and >> [RFC5095]". >> > > O.K. > >> >>> 6.1.7. Binding Update Message >>> >>> The Binding Update (BU) message is used by a mobile node to notify >>> other nodes of a new care-of address for itself. Binding Updates are >>> sent as described in Section 11.7.1 and Section 11.7.2. >>> >>> The Binding Update uses the MH Type value 5. When this value is >>> indicated in the MH Type field, the format of the Message Data field >>> in the Mobility Header is as follows: >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Sequence # | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |A|H|L|K| Reserved | Lifetime | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> . . >>> . Mobility options . >>> . . >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Acknowledge (A) >>> >>> The Acknowledge (A) bit is set by the sending mobile node to >>> request a Binding Acknowledgement (Section 6.1.8) be returned upon >>> receipt of the Binding Update. >>> >>> Home Registration (H) >>> >>> The Home Registration (H) bit is set by the sending mobile node to >>> request that the receiving node should act as this node's home >>> agent. The destination of the packet carrying this message MUST >>> be that of a router sharing the same subnet prefix as the home >>> address of the mobile node in the binding. >>> >> >> This prevents the MN to communicates with the HA on another >> interface. Is there any reason for that limitation, i.e. not having a >> SHOULD here instead of a MUST. Or I should ask, what is the reason to >> have a MUST here. >> > > I couldn't think of a reason against using SHOULD instead of MUST. > However, I don't remember anyone asking for this feature, and unless > there is a reason to make the change, I would not relax that mandate. > >> For instance, the main connectivity of the home agent can be provided by >> a given provided (symmetric line) while the MN are on a subnet for which >> the prefix is provided by another provider. That way, the download >> bandwidth used by the MNs is not shared with the upload bandwidth: >> >> ISP1 -- home subnet ---[HA]--- ISP2 >> > In this picture, do you mean that the MN has a home address from > ISP2, and it should be able to send a packet to the home agent via > a destination address from ISP1? No. Sorry for the unclear picture. The MN has a home address from ISP1 (home network prefix is from the prefix provided by ISP1) but connects from a foreign network to the HA which is reachable from outside on an address from ISP2. > but still it could be made workable, and one could establish a > cost structure for the network which would favor the alternate > control signal path. But are there really such networks that need > this solution? Mine looks like what I describe above for the following reason: - on ISP2, I have a SDSL (which costs a leg) - on ISP1, I have an ADSL (cheap and with good downlink) When I am in a foreign network, downloading sth consume some upload bandwidth from my SDSL and some download bandwidth from my ADSL. If my HA address and my Home Network prefix were in a prefix provided by ISP1 (ADSL), I would have a very limited upload bandwidth (i.e. download as a MN). If both were in a prefix provided by ISP2, downloading something as a MN would saturate both directions on the SDSL. Another example were it may be useful: a community of MN that are not expected to speak *with* the outside world. In that case, you can use a ULA prefix for the Home Net. But you want to allow the MN to communicate *from* the outside world, i.e. from foreign networks outside the site. I would have to check the spec, but I think the only thing that would prevent to relax that MUST is the fact that the Home Agent List for DHAAD is built using the HA address provided in the PIO in RA (section 7.2). Home Link Detection mechanism does not use the HA address but the Home Prefix. I let you decide. >>> ... >>> The deletion of a binding can be indicated by setting the Lifetime >>> field to 0 and by setting the care-of address equal to the home >>> address. In deletion, the generation of the binding management key >>> depends exclusively on the home keygen token, as explained in >>> Section 5.2.5. (Note that while the senders are required to set both >>> the Lifetime field to 0 and the care-of address equal to the home >>> address, Section 9.5.1 rules for receivers are more liberal, and >>> interpret either condition as a deletion.) >>> >> >> For the records: >> >> There is no rationale for explicitly providing different behavior for >> senders and receivers. The various rules associated with what can and >> should be done on that aspects are spread at various places in the >> spec. I already discussed that in draft-ebalard-mext-hld-security-00. >> > > I'm not sure what to do to resolve your issue. Your first sentence > is, in the abstract, incorrect; for example, we are exhorted to be > conservative in what we send, but liberal in what we accept. Yes, but this does not mean that we MUST create different logics for sender and receiver. For instance, sender setting reserved field to 0 and receiver ignoring it is ok. But that specific HoA == CoA case w/ lft != 0 seems weird. > So, a bit more justification would be needed before making any such > wholesale changes. I'm reluctant to absorb text from your draft > without more discussion. Do you propose any specific changes for > this matter? As Marcelo pointed out, I don't think that the changes would fit in the scope of rfc3775bis improvements because it would probably change the expected behavior. I think adding a reference to hld-sec draft in the security consideration section would help but I let you and the chairs decide if it would be useful. >>> Home Address >>> >>> The Home Address of the destination Mobile Node. >>> >>> For a type 2 routing header, the Hdr Ext Len MUST be 2. The Segments >>> Left value describes the number of route segments remaining; i.e., >>> number of explicitly listed intermediate nodes still to be visited >>> before reaching the final destination. Segments Left MUST be 1. The >>> ordering rules for extension headers in an IPv6 packet are described >>> in Section 4.1 of RFC 2460 [8]. The type 2 routing header defined >>> for Mobile IPv6 follows the same ordering as other routing headers. >>> If both a type 0 and a type 2 routing header are present, the type 2 >>> routing header should follow the other routing header. A packet >>> containing such nested encapsulation should be created as if the >>> inner (type 2) routing header was constructed first and then treated >>> as an original packet by the outer (type 0) routing header >>> construction process. >>> >> >> Considering deprecation of RH0 by RFC 5095, it may be worth modifying >> this paragraph to reflect that, for instance by stating that except >> otherwise specified, the RH2 should be the last one in the set of RH >> (i.e. removing the reference to the specific 'Type 0'). >> > > O.K. How about: > > The type 2 routing header defined > for Mobile IPv6 follows the same ordering as other routing headers. > If another routing header is present along with a type 2 routing header, > the type 2 routing header should follow the other routing header. A packet > containing such nested encapsulation should be created as if the > inner (type 2) routing header was constructed first and then treated > as an original packet by header construction process for the other > routing header. Seems clear (as far as explaining routing header logic can be ;-) ). >>> ...... when >>> sending unsolicited multicast Router Advertisements more frequently >>> than the limit specified in RFC 4861 [20], the sending router need >>> >> >> s/RFC 4861 [20]/Neighbor Discovery [20]/ >> >> IMHO, this is easier to read. Note that there are various places in the >> document where the replacement should be done. >> > > I'd be happier if you could point them out. No problem: Section 6.7 Page 62, first paragrah: The Mobile Prefix Solicitation messages may have options. These options MUST use the option format defined in RFC 4861 [20]. Section 6.8 Page 64, first paragraph: The Mobile Prefix Advertisement messages may have options. These options MUST use the option format defined in RFC 4861 [20]. Section 6.8 Page 64, second paragraph of Prefix Information descr: The Prefix Information option is defined in Section 4.6.2 of RFC 4861 [20], with modifications defined in Section 7.2 of this Section 7.2 Page 67, middle of first paragraph: than the limit specified in RFC 4861 [20], the sending router need not include all options in each of these Advertisements. However, in Section 7.5 Page 71, two occurences in first paragraph: are available MUST NOT default to them, and SHOULD default to values specified in RFC 4861. Knowledge of the type of network interface and can cause considerable overhead. Routers SHOULD adhere to the intervals specified in RFC 4861 [20], if this overhead is likely to Section 7.5 Page 71, last paragraph: Note that according to RFC 4861 [20], AdvDefaultLifetime is by default based on the value of MaxRtrAdvInterval. AdvDefaultLifetime Section 10.6.1 Page 106, two occurences in last paragraph of that sect.: itself and other home agents on the home link. In RFC 4861 [20] it is acceptable for two routers to advertise different sets of prefixes and All other comparisons of Router Advertisements are as specified in Section 6.2.7 of RFC 4861. Section 11.5.1 Page 126, first paragraph: to discover routers and prefixes on the new link, as described in Section 6.3.7 of RFC 4861 [20]. Section 13 Page 145, third paragraph: The value MinDelayBetweenRAs overrides the value of the protocol constant MIN_DELAY_BETWEEN_RAS, as specified in RFC 4861 [20]. This >>> 8.4. IPv6 Home Agents >>> >>> In order for a mobile node to operate correctly while away from home, >>> at least one IPv6 router on the mobile node's home link must function >>> as a home agent for the mobile node. The following additional >>> requirements apply to all IPv6 routers that serve as a home agent: >>> >>> o Every home agent MUST be able to maintain an entry in its Binding >>> Cache for each mobile node for which it is serving as the home >>> agent (Section 10.1 and Section 10.3.1). >>> >>> o Every home agent MUST be able to intercept packets (using proxy >>> Neighbor Discovery [20]) addressed to a mobile node for which it >>> >> >> No opinion on whether this is a good idea or not, but probably worth >> asking: what about also adding a reference to RFC 4389 (experimental >> doc)? >> > > What is the advantage of making the citation? It complements the content of Section 7.2.8 of RFC 4861 with additional information on ND Proxy. At least, it does not cost much to add a reference to that experimental document so that people are aware that Proxy-ND does not work out of the box with all kinds of links. >>> o The node MAY support stateful address autoconfiguration mechanisms >>> such as DHCPv6 [32] on the interface represented by the tunnel to >>> the home agent. >>> >> >> How is that supposed to happen/work? Is that to support provisioning of >> *additional* addresses (not HoA) from the Home Network? It is unclear. >> > > What if (a) the mobile node gets an address from DHCP and then > (b) runs IKE with its home agent? Sorry, I do not understand what you mean. Can you describe more precisely the steps? The tunnel does not even exist prior to the binding (which require the HoA) so I don't see how this can work. > How should the statement be made clearer? Well, I don't even see how this can work so at the moment, I would remove that item. >>> 9. Correspondent Node Operation >>> >>> 9.1. Conceptual Data Structures >>> >>> ... >>> o A lifetime value, indicating the remaining lifetime for this >>> Binding Cache entry. The lifetime value is initialized from the >>> Lifetime field in the Binding Update that created or last modified >>> this Binding Cache entry. >>> >> >> Lifetime may be the one sent in the BA in fact or am i missing sth? >> > > I reckon so. I could add a sentence: > > o A lifetime value, indicating the remaining lifetime for this > Binding Cache entry. The lifetime value is initialized from the > Lifetime field in the Binding Update that created or last modified > this Binding Cache entry. The correspondent node MAY select a > smaller lifetime for the Binding Cache entry, and supply that value > to the mobile node in the Binding Acknowledgment message. good. >>> 9.5.1. Receiving Binding Updates >>> >>> Before accepting a Binding Update, the receiving node MUST validate >>> the Binding Update according to the following tests: >>> >>> ... When the Home Registration (H) bit is not set, the >>> following are also >>> required: >>> >>> .... >>> >>> If the Home Registration (H) bit is set, the Nonce Indices mobility >>> option MUST NOT be present. >>> >> >> The binding auth data must not be present either in that case. >> > ...? I don't think that is true. H bit set => receiver of the BU is the MN's HA (See section 6.1.7). Binding Auth Data with the HA does not make sense because BU is IPsec protected. The misleading thing with that section is that it is for correspondent node behavior but is also used to describe the steps performed by the HA. So, IMHO: If the Home Registration (H) bit is set, the Nonce Indices and Binding Auth Data mobility options MUST NOT be present. >>> o If the Lifetime specified in the Binding Update is zero, then this >>> is a request to delete the cached binding for the home address. >>> If the Home Registration (H) bit is set in the Binding Update, the >>> Binding Update is processed according to the procedure specified >>> in Section 10.3.1; otherwise, it is processed according to the >>> procedure specified in Section 9.5.2. >>> >> >> >> That item deals with *deletion* but points to sections associated with >> requests to cache a binding (10.3.1 and 9.5.2). The first sentence >> should be "If the Lifetime specified in the Binding Update is *not* >> zero, then this is a request to *cache a binding* for the home >> address". Otherwise, it does not make sense and is duplicate w/ next >> item > > Good catch! I reckon you are correct. I wonder how that bug > stayed in the specification for so long! ;-) >>> 10.3.1. Primary Care-of Address Registration >>> >>> When a node receives a Binding Update, it MUST validate it and >>> determine the type of Binding Update according to the steps described >>> in Section 9.5.1. Furthermore, it MUST authenticate the Binding >>> Update as described in Section 5.1. An authorization step specific >>> for the home agent is also needed to ensure that only the right node >>> can control a particular home address. This is provided through the >>> home address unequivocally identifying the security association that >>> must be used. >>> >>> This section describes the processing of a valid and authorized >>> Binding Update when it requests the registration of the mobile node's >>> primary care-of address. >>> >>> To begin processing the Binding Update, the home agent MUST perform >>> the following sequence of tests: >>> >>> o If the node implements only correspondent node functionality, or >>> has not been configured to act as a home agent, then the node MUST >>> reject the Binding Update. The node MUST also return a Binding >>> Acknowledgement to the mobile node, in which the Status field is >>> set to 131 (home registration not supported). >>> >>> o Else, if the home address for the binding (the Home Address field >>> in the packet's Home Address option) is not an on-link IPv6 >>> address with respect to the home agent's current Prefix List, then >>> the home agent MUST reject the Binding Update and SHOULD return a >>> Binding Acknowledgement to the mobile node, in which the Status >>> field is set to 132 (not home subnet). >>> >>> o Else, if the home agent chooses to reject the Binding Update for >>> any other reason (e.g., insufficient resources to serve another >>> mobile node as a home agent), then the home agent SHOULD return a >>> Binding Acknowledgement to the mobile node, in which the Status >>> field is set to an appropriate value to indicate the reason for >>> the rejection. >>> >>> o A Home Address destination option MUST be present in the message. >>> It MUST be validated as described in Section 9.3.1 with the >>> following additional rule. >>> >> >> When coming back home, the Home Address destination option may be >> omitted in fact. >> > > But this is a section dealing with registering a care-of-address, not > deregistering it. Yes, but second paragraph of the next section (10.3.2, "Primary Care-of Address De-Registration") starts with the following: "A Binding Update is validated and authorized in the manner described in the previous section; note that when the mobile node de-registers when it is at home, it MAY choose to omit the Home Address destination option, in which case the mobile node's home address is the source IP address of the de-registration Binding Update." So the content of section 10.3.1 also applies to dereg BU. But in the end, rereading that paragraph, this seems clear so drop my comment. >>> attempt to intercept packets on the mobile node's home link that are >>> addressed to the mobile node. >>> >>> In order to do this, when a node begins serving as the home agent it >>> MUST multicast onto the home link a Neighbor Advertisement message >>> [20] on behalf of the mobile node. >>> >> >> As specified in section 10.3.1: >> >> Unless this home agent already has a binding for the given home >> address, the home agent MUST perform Duplicate Address Detection [21] >> on the mobile node's home link before returning the Binding >> Acknowledgement. >> >> So, the last sentence should be modified to indicate that the NA is sent >> only after that initial DAD. >> > > One could argue that the node doesn't begin serving as a home agent > until after DAD is finished. But, if you would like to propose some > better text, I am open to suggestion. What about?: In order to do this, when a node begins serving as the home agent it MUST multicast onto the home link a Neighbor Advertisement message [20] on behalf of the mobile node. This can only be done after having verified using DAD that the home address is not already in use on the Home Network (as specified in Section 10.3.1). >>> While a node is serving as a home agent for some mobile node, the >>> home agent uses IPv6 Neighbor Discovery [20] to intercept unicast >>> packets on the home link addressed to the mobile node. In order to >>> intercept packets in this way, the home agent MUST act as a proxy for >>> this mobile node and reply to any received Neighbor Solicitations for >>> it. When a home agent receives a Neighbor Solicitation, it MUST >>> check if the Target Address specified in the message matches the >>> address of any mobile node for which it has a Binding Cache entry >>> marked as a home registration. >>> >> >> Need for a link to 4389 here too? >> > > I still didn't exactly see why... For the reader to be aware it exists. But this is not critical. >>> 10.4.2. Processing Intercepted Packets >>> >>> For any packet sent to a mobile node from the mobile node's home >>> agent (in which the home agent is the original sender of the packet), >>> the home agent is operating as a correspondent node of the mobile >>> node for this packet and the procedures described in Section 9.3.2 >>> apply. The home agent then uses a routing header to route the packet >>> to the mobile node by way of the primary care-of address in the home >>> agent's Binding Cache. >>> >>> While the mobile node is away from home, the home agent intercepts >>> any packets on the home link addressed to the mobile node's home >>> address, as described in Section 10.4.1. In order to forward each >>> intercepted packet to the mobile node, the home agent MUST tunnel the >>> packet to the mobile node using IPv6 encapsulation [9]. When a home >>> agent encapsulates an intercepted packet for forwarding to the mobile >>> node, the home agent sets the Source Address in the new tunnel IP >>> header to the home agent's own IP address and sets the Destination >>> Address in the tunnel IP header to the mobile node's primary care-of >>> address. When received by the mobile node, normal processing of the >>> tunnel header [9] will result in decapsulation and processing of the >>> original packet by the mobile node. >>> >>> However, packets addressed to the mobile node's link-local address >>> MUST NOT be tunneled to the mobile node. Instead, these packets MUST >>> be discarded and the home agent SHOULD return an ICMP Destination >>> Unreachable, Code 3, message to the packet's Source Address (unless >>> this Source Address is a multicast address). >>> >> >> I am certainly missing something here, but what is the point for the HA >> in defending the IP then? >> > > So that no other node will steal the mobile node's link-local address. > The mobile node would like to have it back when it returns to the home > network. Thanks for the clarification. >>> where MaxMobPfxAdvInterval is as defined in Section 12. Then compute >>> the final delay for the advertisement: >>> >>> >>> RAND_ADV_DELAY = MinMobPfxAdvInterval + >>> (rand() % abs(MaxScheduleDelay - MinMobPfxAdvInterval)) >>> >>> Here rand() returns a random integer value in the range of 0 to the >>> maximum possible integer value. This computation is expected to >>> alleviate bursts of advertisements when prefix information changes. >>> In addition, a home agent MAY further reduce the rate of packet >>> transmission by further delaying individual advertisements, when >>> necessary to avoid overwhelming local network resources. The home >>> agent SHOULD periodically continue to retransmit an unsolicited >>> Advertisement to the mobile node, until it is acknowledged by the >>> receipt of a Mobile Prefix Solicitation from the mobile node. >>> >> >> seems weird. >> > > As I remember, this was considered very cool at the time. > I don't remember why, but unless there is a need for change > I'd rather not go back and figure it out. ok. Let's keep it that way. >>> 11. Mobile Node Operation >>> >>> 11.1. Conceptual Data Structures >>> >>> >>> >>> o The remaining lifetime of that binding. This lifetime is >>> initialized from the Lifetime value sent in the Binding Update and >>> is decremented until it reaches zero, at which time this entry >>> MUST be deleted from the Binding Update List. >>> >> >> Updated by the BA. >> >> > But, I think the BA can only decrease the lifetime, right? So it would > still be a further decrementation. yes, exactly. >>> 11.3.2. Interaction with Outbound IPsec Processing >>> >>> ... >>> >>> The Key Management Mobility Capability (K) bit in Binding Updates and >>> Acknowledgements can be used to avoid the need to rerun IKE upon >>> movements. >>> >> >> Considering the mechanism is implemented and such an interface needed to >> support that, 3775bis could at least point MIGRATE doc given below as an >> informational reference document. This clarifies the need and gives a >> possible solution. >> >> http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00 >> > > Can we do this safely without having the citation to be > considered normative? What about changing the K bit description in 6.1.7 from Key Management Mobility Capability (K) If this bit is cleared, the protocol used for establishing the IPsec security associations between the mobile node and the home agent does not survive movements. It may then have to be rerun. (Note that the IPsec security associations themselves are expected to survive movements.) If manual IPsec configuration is used, the bit MUST be cleared. to that: Key Management Mobility Capability (K) If this bit is cleared, the protocol used for establishing the IPsec security associations between the mobile node and the home agent does not survive movements. It may then have to be rerun. If manual IPsec configuration is used, the bit MUST be cleared. Note that the transport mode IPsec security associations themselves are expected to survive movements. A possible solution regarding the update of IKE SA (Phase 1 for IKEv1, IKE_SA for IKEv2) update and optional tunnel mode IPsec SP/SA update is described in [MIGRATE]. >>> 11.4.3. Receiving Mobile Prefix Advertisements >>> >>> Section 10.6 describes the operation of a home agent to support boot >>> time configuration and renumbering a mobile node's home subnet while >>> the mobile node is away from home. The home agent sends Mobile >>> Prefix Advertisements to the mobile node while away from home, giving >>> "important" Prefix Information options that describe changes in the >>> prefixes in use on the mobile node's home link. >>> >>> The Mobile Prefix Solicitation is similar to the Router Solicitation >>> used in Neighbor Discovery [20], except it is routed from the mobile >>> node on the visited network to the home agent on the home network by >>> usual unicast routing rules. >>> >>> When a mobile node receives a Mobile Prefix Advertisement, it MUST >>> validate it according to the following test: >>> >>> o The Source Address of the IP packet carrying the Mobile Prefix >>> Advertisement is the same as the home agent address to which the >>> mobile node last sent an accepted home registration Binding Update >>> to register its primary care-of address. Otherwise, if no such >>> registrations have been made, it SHOULD be the mobile node's >>> stored home agent address, if one exists. Otherwise, if the >>> mobile node has not yet discovered its home agent's address, it >>> MUST NOT accept Mobile Prefix Advertisements. >>> >>> o The packet MUST have a type 2 routing header and SHOULD be >>> protected by an IPsec header as described in Section 5.4 and >>> Section 6.8. >>> >>> o If the ICMP Identifier value matches the ICMP Identifier value of >>> the most recently sent Mobile Prefix Solicitation and no other >>> advertisement has yet been received for this value, then the >>> advertisement is considered to be solicited and will be processed >>> further. >>> >>> Otherwise, the advertisement is unsolicited, and MUST be >>> discarded. In this case the mobile node SHOULD send a Mobile >>> Prefix Solicitation. >>> >> >> I tried and raise a clarification on that point: >> >> See http://permalink.gmane.org/gmane.ietf.mip6/9433 >> >> but got no response. IMHO, clarifying things a bit would help. >> > > How about: > > Otherwise, the advertisement is unsolicited, and MUST be > discarded. In this case the mobile node SHOULD send a Mobile > Prefix Solicitation, using the same ICMPv6 identifier that was > used for the previous Solicitation. ok. >>> 11.5.2. Home Link Detection >>> >>> When an MN detects that it has arrived on a new link using the >>> movement detection algorithm in use (Section Section 11.5.1,) it >>> performs the following steps to determine if it is on the home link. >>> >>> o The MN performs the procedure described in Section 11.5.2x and >>> >> >> s/11.5.2x/11.5.2/ >> >> Then, it seems that 11.5.2 is current section. Weird. >> >> > > I reckon this ought to be 11.5.3. > >>> configures an address. It also keeps track of all the on-link >>> prefix(es) received in the RA along with their prefix lengths. >>> >>> o If the home prefix has not been statically configured the MN uses >>> some form of bootstrapping procedure (e.g. RFC5026 [25]) to >>> determine the home prefix. >>> >>> o Given the availability of the home prefix, the MN checks whether >>> or not the home prefix matches one of the prefixes received in the >>> RA. If it does, the MN concludes that it has returned home. >>> >> >> It should be stated here or in the "Security Considerations" section >> that this procedure is insecure and may have security impact, as we rely >> on basic ND and undergo associated threats. This is documented: >> >> http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00 >> > > I could put some advice in the Security Considerations section and a > cross reference here. If you happen to have a short paragraph of text that > you wanted to contribute for that purpose, it would be appreciated. Is that ok?: The Home Link Detection mechanism described in section 11.5.2 and used by the MN to detect it is at home relies on Neighbor Discovery [20]. When IPsec is used by the MN for protecting data traffic exchanged with the Home Agent from foreign networks, relying on this mechanism may have security implications. This is discussed in [hld-sec]. >>> the previously registered care-of address. >>> >>> In this home registration, the mobile node MUST set the Acknowledge >>> (A) and Home Registration (H) bits, set the Lifetime field to zero, >>> and set the care-of address for the binding to the mobile node's own >>> home address. The mobile node MUST use its home address as the >>> source address in the Binding Update. >>> >> >> Processing for receiver allows either lft=0 or CoA == HoA; so what's the >> point in that MUST. >> > > Well, it's been there for a long time, and I don't know if it > would be worthwhile to change. It might break various > interoperability tests, for one thing. Well, if a HA receives a dereg BU with the lft not set to 0, then it is from a non compliant implementation. And if the HA does not accept such a BU sent by a non-compliant implementation, it would fail an interoperability test. Also note that for the MN to send a BU with the HoA as source address in the IPv6 header (i.e. no HAO), this requires the MN to have detected it is on its Home Network. In that case, it would purposely not set the lifetime to 0 do deregister? But I agree that this is some kind of historical weirdness we need to keep. >>> 15. Security Considerations >>> >> >> Considering this is documented: >> >> http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00 >> >> the possible specific insecurity of the Home Link Detection mechanism >> could be referenced in that section. >> >> >> >> >> >>> 15.7. Tunneling via the Home Agent >>> >>> >>> When site local home addresses are used, reverse tunneling can be >>> used to send site local traffic from another location. >>> Administrators should be aware of this when allowing such home >>> addresses. In particular, the outer IP address check described above >>> is not sufficient against all attackers. The use of encrypted >>> tunnels is particularly useful for these kinds of home addresses. >>> >> >> In previous paragraph, reference to site local (deprecated) should be >> replaced by a reference to Unique Local Addresses (RFC4193). >> > > O.K. > >> >>> 16. Contributors >>> >>> Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik Nordmark, >>> and Michael Thomas worked on the return routability protocols >>> eventually led to the procedures used in this protocol. >>> >> >> In previous sentence, s/worked/work/ >> >> >> > > I think some other people were involved -- and this was a very > contentious time in the working group. Sorry, I may have been unclear. The first sentence has 2 verbs: 'worked' and 'led' but only one subject. I think there is either a missing 'which' or 'worked' need to be changed in 'work' i.e. one of the following would be valid: Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik Nordmark, and Michael Thomas worked on the return routability protocols which eventually led to the procedures used in this protocol. or Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik Nordmark, and Michael Thomas work on the return routability protocols eventually led to the procedures used in this protocol. > Work done by Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, > Erik Nordmark, and Michael Thomas on the return routability protocols > shaped the procedures used in this protocol. that would be ok too. Cheers, a+ From rfc-editor@rfc-editor.org Wed Oct 7 17:08:05 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6BBE3A6937; Wed, 7 Oct 2009 17:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.909 X-Spam-Level: X-Spam-Status: No, score=-16.909 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9FyfZeHvrYI; Wed, 7 Oct 2009 17:08:04 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id A7D7A3A677C; Wed, 7 Oct 2009 17:08:04 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id ECFE833E982; Wed, 7 Oct 2009 17:08:15 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20091008000815.ECFE833E982@bosco.isi.edu> Date: Wed, 7 Oct 2009 17:08:15 -0700 (PDT) Cc: mext@ietf.org, rfc-editor@rfc-editor.org Subject: [MEXT] RFC 5522 on Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 00:08:06 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5522 Title: Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks Author: W. Eddy, W. Ivancic, T. Davis Status: Informational Date: October 2009 Mailbox: weddy@grc.nasa.gov, William.D.Ivancic@grc.nasa.gov, Terry.L.Davis@boeing.com Pages: 31 Characters: 79570 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mext-aero-reqs-04.txt URL: http://www.rfc-editor.org/rfc/rfc5522.txt This document describes the requirements and desired properties of Network Mobility (NEMO) Route Optimization techniques for use in global-networked communications systems for aeronautics and space exploration. Substantial input to these requirements was given by aeronautical communications experts outside the IETF, including members of the International Civil Aviation Organization (ICAO) and other aeronautical communications standards bodies. This memo provides information for the Internet community. This document is a product of the Mobility EXTensions for IPv6 Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From dave.craig4@gmail.com Wed Oct 7 17:35:43 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4620E3A67D3 for ; Wed, 7 Oct 2009 17:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5EXVLLsDr+q for ; Wed, 7 Oct 2009 17:35:42 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id 07A353A684E for ; Wed, 7 Oct 2009 17:35:42 -0700 (PDT) Received: by pxi6 with SMTP id 6so6192975pxi.32 for ; Wed, 07 Oct 2009 17:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=o+wp2YNhtfl60KkV536bFvXN8fr331cbtEHkm+kC5Lw=; b=AqDcBxw5bztXZELynr+vnj4LW00mRvnM4e0ahqSpLewpCBgopaxrvd1PyYKWiYeKKr LDTgtKHEjLh7zhzEw7fj3nfezZTaagq5dQmM88O1UM9wiBmIg3RSJuO1iTxyubxY4V/0 KbYATnCXNrkcaZAbh4S7WMX7GygR7aSnIaAbQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Mg8p06R6ISQopa0VovxxmtPtgm5rDhpJlK1sYFdjk6ORAjUlx5TH3j+nPEMxmLuurr nYHlugJQZH4px4KeocZAYTyHgwfacoLowNLkLDUO8vkutE+tQ74QA1Zw8WjVjESQYE2E 7IUkdjJFWBQVGzoBzVjmPjbH9j41aPQRAMPGQ= MIME-Version: 1.0 Received: by 10.114.242.2 with SMTP id p2mr990978wah.153.1254962238775; Wed, 07 Oct 2009 17:37:18 -0700 (PDT) Date: Wed, 7 Oct 2009 17:37:18 -0700 Message-ID: <40b8fe770910071737u3708ccbbge35b0a0b99bd3fa@mail.gmail.com> From: Dave Craig To: mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 00:42:34 -0000 Nice draft, I have a few comments that I hope will improve it a little bit. General comments, I do not see any specification of handling for fragments and ICMP responses. I think you need some text here because draft mentions filters applying to transport-specific headers and the desire not to reorder packets in a flow by sending them by different paths. I suggest you consider specifying HA behavior that attempts to direct fragments along the same binding as the previous fragment and ICMP responses along the path that corresponds to reversing the source and destination port of the packet encapsulated in an ICMP response. Please let me know if you'd like some text for this. I also suggest that the draft exclude flow bindings from impacting traffic originating from the home agent. It would not go very well if a node sends a discard all flow binding to temporarily stop traffic but is then unable to undo that flow binding. All references to I-D.ietf-monami-multiplecoa should be replaced with RFC 5648, congratulations! * 2. Introduction, page 5, "...which binds one care-of address to one home address".=A0 Since you refer to NEMO, should this be, "...which binds one care-of address to one home address and possibly its associated Mobile Network"? I think this is germane to the flow mobility conversation because this draft enables migrating flows inside the mobile network independently of the home address. * 2. Introduction, page 5, "A policy can contain a request for a special treatment...". This sounds better as, "A policy can contain a request for special treatment..." * 2. Introduction, page 5, "Requesting the flow binding can be decided based on local policies with the mobile node / mobile router and based on the link characteristics and the types of applications running at the time.". This sounds better as, "The mobile node / mobile router assembles the flow binding request based on local policies, link characteristics, and type of applications running at the time." * 2. Introduction, page 6, "with ant-replay protection mechanisms." should be, "with anti-replay..." The again, I may have overlooked an application for flow mobility in the pest extermination business. * 2. Introduction, page 6, "Hence, per-packet load balancing is not currently supported in this extension." This is a non-sequitur with previous text mentioning the problems with load balancing. It sounds like you plan to support it at some point in the future. Suggest rephrasing with some text to effect that load balancing is not envisioned for this extension. Otherwise, as an implementer, I figure that I should start planning in extensibility for load balancing in my design. * 4.1. Definition Update for Binding Identifier Mobility Option, page 8, "BIDs with the same BID-PRI value have equal priority." Do you mean, "BIDs with the same BID-PRI produce unspecified results for flows matching both bindings."? It is not clear what equal priority means. An administrator may rightly assume a longest-prefix match for associated address-type filters, and I do not think you want to make that commitment here. * 4.2. Same comment for Flow Identification Mobility Option, page 9, with respect to FID-PRI. * 4.2. Flow Identification Mobility Option, page 10, Discard. Should you specify whether there is an ICMP response when discarding the packet? Do you want two different actions, one that discards silently and one that discards with ICMP unreachable, network administratively prohibited? I think the later would be useful for p2p-type apps where you'd like to remove candidate paths as quickly as possible. * 4.2. Flow Identification Mobility Option, page 10. Should you include a "Forward" action to be consistent with the text in 5.3.2.1 that mentions an 'Forward' action? * 4.2.1. Binding Reference Sub-option, page 11, do you need some error if the referenced BID does not exist? I noticed that errors for stale FID references had been specified but not BIDs. * 4.4. Flow Bindings entries list and its relationship to Binding Cache, page 14, "A Flow Descriptor:..." Should this be Discriptor(s), since the format described in 4.2 allows multiple flow description sub-options for a single flow identification option? * 4.4. Flow Bindings entries list and its relationship to Binding Cache, page 14, "As an example the following represents an ordered flow bindings entries table..." Would this sound better as, "As an example, the following represents an ordered flow binding entry table..." * 4.4. Flow Bindings entries list and its relationship to Binding Cache, page 14, "A valid BID is required to make the entry "active"." This is inconsistent with Discard flow bindings that are not supposed to have a valid BID. How about requiring valid BID for discard flow bindings in 4.2, page 10 instead of updating this text? Otherwise, 5.2.4. removes flow bindings implicitly when there is a binding update that does not include them. If there is not a BID associated with a discard flow binding, how does the HA know which binding update excludes the flow binding? I guess the other alternative is to expand the flow binding entry table to include a reference to the binding update HoA and CoA that created it, but it is not clear that you want a n-cast type flow binding to disappear when removing the BU for HoA/CoA that created it. * 5.2.2.1. page 18, mentions a unique priority for each flow binding. Did you mean to limit a MN to at most 255 flow bindings? It probably will be less, as configurations will normally include space between priorities to make it easier to add new rules. Suggest treating this the same way as BID-PRI where the precedence between same priority is just (well should be) left unspecified in 4.1. * 5.2.2.1, page 18, "if the Action indicated 'Discard', the Binding Reference sub-option SHOULD NOT be included." How will a node know which binding update no longer includes this flow binding, if it does not have a BID? What do you think about removing this bullet? * 5.3.3. Receiving BU with Flow Summary Option, page 24, "A de-registration binding update (with a zero lifetime) would result in deleting all bindings regardless of the presence of the Flow summary option." Do you mean to remove all of the BID references in the flow bindings? At first glance, I thought this meant removing all of the bindings in the binding cache. There are several references to "bindings" in the document. Suggest a scrub for all instances of the word "binding" in the document, i.e. page 9, I think you meant to refer to flow bindings, not bindings, "This field is used to refer to an existing binding or to create a new binding." * 5.2.4. Removing flow bindings, page 19-20, "Removal of flow binging entries is performed implicitly by omission of a given FID from a binding update". Change binging to binding. This really is, "A binding update removes its BID from a flow binding implicitly by omitting its FID in the Flow Identification Summary Mobility Option. Nodes remove flow binding entries when they no longer have any associated BIDs." The ensuing text that mentions removing BIDs associated with a FID references text that describes removing BIDs entirely, since RFC 5648 does not have the notion of a FID to selectively remove a particular BID. Suggest rewording to mention that it is possible to remove BIDs that also implicitly remove the BID references in the flow binding entry table. I also suggest that you also add text to remove BIDs from flow bindings when the binding for a particular BID expires. * 5.3.2. page 22, "If more than one flow identification option," is, "in the same BU..." * 5.3.2.1. page 23, "If the Binding Reference sub-option is present and includes one or more BIDs..." Should you reject a ncast flow binding that refers to bindings that are not active? Wouldn't this diminish the utility of ncast if the HA removes a binding that is not refreshed and the MN sends a refresh referencing that binding? In this case, the n-cast goes to 0-cast even though n-1 bindings are ok. Suggest removing this bullet or at least paring it down to an error if all of the referenced BIDs do not exist. * 5.3.3. page 24, "If the value of the FID field is present in the mobile nodes list of slow binding entries the, home agent SHOULD refresh the binding entry identified by the FID..." Suggest removing the refresh term. There was not a lifetime specified in the flow binding entry table. This might be more consistent as, "... home agent SHOULD not remove the BIDs associated with the identified FID..." * 5.3.5. page 25, "... or by just ignoring all the flow binding options." Isn't this inconsistent with the text requiring flow identification options MUST be included in the Binding Acknowledgment? Suggest dropping the ignoring text or demote the MUST requirement to a SHOULD. From Mohana.Jeyatharan@sg.panasonic.com Wed Oct 7 17:44:17 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5668F28C1EF for ; Wed, 7 Oct 2009 17:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.81 X-Spam-Level: * X-Spam-Status: No, score=1.81 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_22=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_32=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 zEu0PdxOT+RG for ; Wed, 7 Oct 2009 17:44:16 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 108BC28C200 for ; Wed, 7 Oct 2009 17:44:11 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id n980jh6d027434; Thu, 8 Oct 2009 09:45:43 +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 n980jhF10847; Thu, 8 Oct 2009 09:45:44 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Oct 2009 08:41:35 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD0398AEBF@pslexc01.psl.local> In-Reply-To: <585093.38537.qm@web111408.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scenarios for HA to MN Flow Binding -draft-xia-mext-ha-init-flow-binding Thread-Index: AcpBPNhP7FKb3uo1Sp+S8MbrmUcAmgGcpSZg From: "Mohana Jeyatharan" To: "Behcet Sarikaya" , Subject: Re: [MEXT] Scenarios for HA to MN Flow Binding -draft-xia-mext-ha-init-flow-binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 00:44:17 -0000 Hi Behcet and all, >From the use cases people have proposed for flow binding work, it is acceptable that in most cases, the decision about the flow binding rule is made by the MN.=20 But as mentioned in draft-xia-mext-ha-init-flow-binding, the flow binding rule can originate from HA(be it mandatory or optional). Bcos in some cases, the network can decide what is best for it. Since there is a valid trust relation ship between HA and MN, the HA can use flow binding protocol in a reverse way(as quoted in HA-init ID) to sends its rules to MN. In addition to the scenarios you have quoted, I am quoting another scenario, where the HA can suggest its flow binidng rules and the MN can use these rules to create its own rules. **************************************************** Flow binding rules initiated by HA and their categories [1]Some are Mandatory flow binding rules-case A [2]Some are flow binding preferences and UE can decide on the suitable flow binding rule based on some preference given by the network/HA-case B [3]Some flow binding rules are mandatory but to be applied when an event occurs-Case C=20 *************************************************** Case A and Case B scenarios are given together *************************************************** HA changing default flow policies into default flow binding =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +-----+ | HA | | | +-----+ / \ 3G homelink \ (PMIP)/ \ / \ HPLMN / \ +-----+ +-------+ =20 | S-GW| | ePDG | | | | | +-----+ +-------+ \ / \ / \ / +---+ |MN | +---+ The network entity such as HSS through AAA gives default flow policies to HA (Voice via 3G and data via other). The HA changes default policies=20 into default flow binding rules.=20 The HA has PMIP binding for the home link and knows the binding for home link and the access type tied to homebinding. home binding BID1, foreign binding BID2. Thus HA initiates default flow binding rule (FID1(voice) BID1. FID2(data) BID2. MN generates flow binding rules for uplink and downlink traffic based on flow binding rules given by HA. HA given rules can be subset of the final MN flow binding rules. =20 In case A, MN needs to follow these rules strictly. =20 In case B, if there is no other external factor influencing the flow binding rules being set by MN(ANDSF, MNs preferences etc) it will follow the HA given flow binding rule. Else it will NACK the HA given flow binding rule and give its own flow binding rule. =20 ******************************************************************* Comments? Thanks. BR, Mohana > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Behcet Sarikaya > Sent: Wednesday, September 30, 2009 3:45 AM > To: mext@ietf.org > Subject: [MEXT] Scenarios for HA to MN Flow Binding -draft-xia-mext-ha- > init-flow-binding >=20 > Hello all, > As presented in IETF 75 > http://www.ietf.org/proceedings/75/slides/mext-2/mext-2.htm >=20 > apart from flow binding revocation, we had > - inter-interface flow movement and > - default Flow Binding Provisioning > scenarios. >=20 > Please post any comments on the above or related to the above scenarios. >=20 > Regards, >=20 > Behcet >=20 >=20 >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From julienl@qualcomm.com Wed Oct 7 17:56:56 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F0513A6926 for ; Wed, 7 Oct 2009 17:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.592 X-Spam-Level: X-Spam-Status: No, score=-103.592 tagged_above=-999 required=5 tests=[AWL=-0.993, 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 1tev3PDCzpk0 for ; Wed, 7 Oct 2009 17:56:55 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id BA4753A686E for ; Wed, 7 Oct 2009 17:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1254963517; x=1286499517; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:x-cr-hashedpuzzle: x-cr-puzzleid:acceptlanguage:content-type: content-transfer-encoding:mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"mext@ietf.org"=20|Date:=20Wed,=207 =20Oct=202009=2017:58:29=20-0700|Subject:=20test=20-=20pl ease=20discard.|Thread-Topic:=20test=20-=20please=20disca rd.|Thread-Index:=20AcpHsnMjvAUN94QbSou/bxxo/vTcvQ=3D=3D |Message-ID:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-cr-hashedpuzzle:=20Aruk=20Bvmi =20DQFh=20Drex=20Dx4k=20D/OU=20EcgZ=20EoBw=20Fsb5=20HFO9 =20HT4p=0D=0A=20H0A2=20IDgw=20Iy8C=20KAL1=0D=0A=20KkiI=3B 1=3BbQBlAHgAdABAAGkAZQB0AGYALgBvAHIAZwA=3D=3BSosha1_v1=3B 7=3B{5DB6BEF0-B063-4A7C-B7A8-B2C2D3166EFA}=3BagB1AGwAaQBl AG4AbABAAHEAdQBhAGwAYwBvAG0AbQAuAGMAbwBtAA=3D=3D=3BThu, =0D=0A=2008=20Oct=202009=2000:58:29=0D=0A=20GMT=3BdABlAHM AdAAgAC0AIABwAGwAZQBhAHMAZQAgAGQAaQBzAGMAYQByAGQALgA=3D |x-cr-puzzleid:=20{5DB6BEF0-B063-4A7C-B7A8-B2C2D3166EFA} |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5764"=3B=20a=3D"24755959"; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=PdbuyfOGZGSRQSDW/VJ4aJPrCzefQKvOY2kE5M8xFTcUqBsU/Fj8czxP 3d5aXPC+H6xnpr7RauEAnmhHLsMM4P6nw6zKNjX/iWSW0FJAOoJaO5bz1 wuE2lhP4qum8llu559hc1X9naqNEJ0mZnvBqFC+sYohys0/2fGkgyqnyE s=; X-IronPort-AV: E=McAfee;i="5300,2777,5764"; a="24755959" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Oct 2009 17:58:36 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n980wawb029732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 7 Oct 2009 17:58:36 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n980wXOL020067 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 7 Oct 2009 17:58:36 -0700 (PDT) Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 7 Oct 2009 17:58:33 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.639.14; Wed, 7 Oct 2009 17:58:33 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Wed, 7 Oct 2009 17:58:33 -0700 From: "Laganier, Julien" To: "mext@ietf.org" Date: Wed, 7 Oct 2009 17:58:29 -0700 Thread-Topic: test - please discard. Thread-Index: AcpHsnMjvAUN94QbSou/bxxo/vTcvQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Aruk Bvmi DQFh Drex Dx4k D/OU EcgZ EoBw Fsb5 HFO9 HT4p H0A2 IDgw Iy8C KAL1 KkiI; 1; bQBlAHgAdABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {5DB6BEF0-B063-4A7C-B7A8-B2C2D3166EFA}; agB1AGwAaQBlAG4AbABAAHEAdQBhAGwAYwBvAG0AbQAuAGMAbwBtAA==; Thu, 08 Oct 2009 00:58:29 GMT;dABlAHMAdAAgAC0AIABwAGwAZQBhAHMAZQAgAGQAaQBzAGMAYQByAGQALgA= x-cr-puzzleid: {5DB6BEF0-B063-4A7C-B7A8-B2C2D3166EFA} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MEXT] test - please discard. X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 00:56:56 -0000 From web-usrn@ISI.EDU Thu Oct 8 07:55:54 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29D628C1B5 for ; Thu, 8 Oct 2009 07:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.911 X-Spam-Level: X-Spam-Status: No, score=-16.911 tagged_above=-999 required=5 tests=[AWL=0.688, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTK90As9iYMj for ; Thu, 8 Oct 2009 07:55:54 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id F32823A68C9 for ; Thu, 8 Oct 2009 07:55:53 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n98EutP5029512; Thu, 8 Oct 2009 07:56:56 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n98Euqtl029492; Thu, 8 Oct 2009 07:56:52 -0700 (PDT) Date: Thu, 8 Oct 2009 07:56:52 -0700 (PDT) Message-Id: <200910081456.n98Euqtl029492@boreas.isi.edu> To: ryuji.wakikawa@gmail.com, vijay@wichorus.com, Tsirtsis@gmail.com, thierry.ernst@inria.fr, nagami@inetcore.com, rdroms@cisco.com, jari.arkko@piuha.net, marcelo@it.uc3m.es, julienl@qualcomm.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ah@TR-Sys.de, rfc-editor@rfc-editor.org, mext@ietf.org Subject: [MEXT] [Technical Errata Reported] RFC5648 (1904) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 14:55:55 -0000 The following errata report has been submitted for RFC5648, "Multiple Care-of Addresses Registration". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5648&eid=1904 -------------------------------------- Type: Technical Reported by: Alfred Hoenes Section: 6.2, pg.25 Original Text ------------- a) In Section 4.3, the description of the 'Care-of Address' field in the Binding Identifier Mobility Option specifies: Care-of Address If a Binding Identifier mobility option is included in a Binding Update for the home registration, either IPv4 or IPv6 care-of addresses for the corresponding BID can be stored in this field. For the binding registration to correspondent nodes (i.e., route optimization), only IPv6 care-of addresses can be stored in this field. If no address is specified in this field, the length of ! this field MUST be zero (i.e., not appear in the option). If the ! option is included in any messages other than a Binding Update, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ! the length of this field MUST also be zero. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ b) Contrary to the "MUST" in the last line, Section 6.2 of the RFC says, on mid-page 25, where it elaborates on Binding Acknowledgement messages: If all the above operations are successfully completed and the 'A' flag is set in the Binding Update, 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, MAY be omitted, because the mobile node can match a ^^^ ! corresponding Binding Update List entry using the BID. Corrected Text -------------- a) << no change >> b) If all the above operations are successfully completed and the 'A' flag is set in the Binding Update, 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, MUST be omitted, because the mobile node can match a corresponding Binding Update List entry using the BID. Notes ----- Rationale: The inconsistency is described with the Original Text. The Corrected Text proposed gives preference to the requirement from Section 4.3, which seems to be reasonable for efficiency and consistent with other parts of the specification. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5648 (draft-ietf-monami6-multiplecoa-14) -------------------------------------- Title : Multiple Care-of Addresses Registration Publication Date : October 2009 Author(s) : R. Wakikawa, Ed., V. Devarapalli, G. Tsirtsis, T. Ernst, K. Nagami Category : PROPOSED STANDARD Source : Mobility EXTensions for IPv6 Area : Internet Stream : IETF Verifying Party : IESG From behcetsarikaya@yahoo.com Thu Oct 8 09:51:06 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2343828C1B5 for ; Thu, 8 Oct 2009 09:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, 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 73Feh3U11Ick for ; Thu, 8 Oct 2009 09:51:05 -0700 (PDT) Received: from web111410.mail.gq1.yahoo.com (web111410.mail.gq1.yahoo.com [67.195.15.186]) by core3.amsl.com (Postfix) with SMTP id 5B6CF28C1B4 for ; Thu, 8 Oct 2009 09:51:05 -0700 (PDT) Received: (qmail 19312 invoked by uid 60001); 8 Oct 2009 16:52:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1255020768; bh=l5nt5wnqKsyeVCFCgAiWLpU8Uk0dpKs9bxnObnuUZZM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BlqVlTtNmJ0KPeqBsEC7wkx8tCCJPs/WaLVasA1dAeGv3yZY8ol/QlPbQ2w//1Sn0fDQd1t9tD3Is1GXY2QOmFRCmYfXZtKMkecoQL/2JfQ6LT60iiolkS0FE0KI6EEhz3CXo0nXdQa9sXOVEAoWYQNAzfwyF6OOiV0Z4SHjGWQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fMP7XRzOc2Sw/gZt+QCJEyCRzVo1zT3kaI46G6cOa5PdPpH0mkCiZfhNDKHprNMZSyx3FEkJ2X52S0fyrFzzRi5lnaHfzFo5fGLgZjCUses4C/qeKrcN7I+JBiZcb1Q9briyXvmaFAz9TM1kBzeFqtn1CU1MiRGZ0FZIJMXXq64=; Message-ID: <11879.19213.qm@web111410.mail.gq1.yahoo.com> X-YMail-OSG: 60ofxwMVM1n4i6l4B6lDJ6Jm0NXp6hknWr050Djy_bN_WfMoi4rm1g1fIjJl0ay_.D6eh.EmsP9TBE7EsVQzljm1OPC7RRFe0Oz7iXW2aWOMnKYwNo4eoRufgJTzTMpUuHO7Oh0kT31MAXWP.loxt9CkFbYZcwb.4kZ0q2yoYJA3pX9xSEKbrxss0IOhCttuHLFgl56Bhr9no5zdV.QnamjoLMM3GiAGMK6RhIwi4k2WmeKWInAx.m2aKZ8R4xxXloHahtrkF5_uH94W0Oj3_y8hrb58zrz0Qqtp7gej9m2L0yoooAoEXUT8buSMtIohLDN3xDTkBF8KSBELPRU6HNhVQSwdB4lqhePnA0nkskrreu.xLkg8TJgJ Received: from [206.16.17.212] by web111410.mail.gq1.yahoo.com via HTTP; Thu, 08 Oct 2009 09:52:47 PDT X-Mailer: YahooMailRC/182.10 YahooMailWebService/0.7.347.3 Date: Thu, 8 Oct 2009 09:52:47 -0700 (PDT) From: Behcet Sarikaya To: shara@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: [MEXT] Fw: New Version Notification for draft-sarikaya-aplusp-dsmip-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 16:51:06 -0000 Hi all,=0A=A0 We submitted this draft. Comments posted on the list will be = appreciated.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- Forwarded Message -= ---=0A> From: IETF I-D Submission Tool =0A> To: sari= kaya@ieee.org=0A> Cc: xiayangsong@huawei.com; mohamed.boucadair@orange-ftgr= oup.com=0A> Sent: Thu, October 8, 2009 11:46:35 AM=0A> Subject: New Version= Notification for draft-sarikaya-aplusp-dsmip-00=0A> =0A> =0A> A new versio= n of I-D, draft-sarikaya-aplusp-dsmip-00.txt has been successfuly =0A> subm= itted by Behcet Sarikaya and posted to the IETF repository.=0A> =0A> Filena= me:=A0=A0=A0 draft-sarikaya-aplusp-dsmip=0A> Revision:=A0=A0=A0 00=0A> Titl= e:=A0=A0=A0 =A0=A0=A0 A+P for Dual-Stack Mobile IPv6=0A> Creation_date:=A0= =A0=A0 2009-10-08=0A> WG ID:=A0=A0=A0 =A0=A0=A0 Independent Submission=0A> = Number_of_pages: 15=0A> =0A> Abstract:=0A> This memo describes how to use I= Pv6 Port Range transition technique=0A> in mobile networks for Dual-Stack M= obile IPv6 (DSMIPv6).=A0 Using the=0A> client based DSMIPv6, a mobile node = (MN) which is a dual-stack node=0A> can be assigned with a shared IPv4 Home= Address (HA) together with a=0A> port range from the home agent.=A0 HA is = co-located with Port Range=0A> Router (PRR).=A0 IPv4-in-IPv6 encapsulation = is used to convey IPv4=0A> traffic between the network and the mobile node = (MN).=A0 HA, acting as=0A> PRR receives incoming IPv4 datagrams and determi= nes the routing=0A> identifier (IPv6 address) to use to forward the traffic= to the=0A> appropriate MN among those sharing the same IPv4 address.=A0 In= the=0A> binding mode, HA finds the binding cache entry for this MN and the= n=0A> encapsulates the IPv4 datagram in an IPv6 one and forwards the=0A> en= capsulated datagram to MN.=A0 The stateless mode is also described.=0A> Wit= hin this memo, Mobile network could be WiMAX network or 3GPP Long=0A> Term = Evolution (LTE) network.=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A> =A0 =0A> =0A> =0A> The IETF S= ecretariat.=0A=0A=0A=0A From mohamed.boucadair@orange-ftgroup.com Thu Oct 8 11:51:26 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750423A6999; Thu, 8 Oct 2009 11:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 H8fBWXBNyS8a; Thu, 8 Oct 2009 11:51:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 6661A3A68A8; Thu, 8 Oct 2009 11:51:25 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 502A11043E7; Thu, 8 Oct 2009 20:53:07 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 36D5C27C037; Thu, 8 Oct 2009 20:53:07 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 8 Oct 2009 20:53:07 +0200 From: To: Behcet Sarikaya , "shara@ietf.org" Date: Thu, 8 Oct 2009 20:53:05 +0200 Thread-Topic: [shara] Fw: New Version Notification for draft-sarikaya-aplusp-dsmip-00 Thread-Index: AcpIOLYdKUry/e9TR+mXyTVQ/GfVjQAD7xpw Message-ID: <4954_1255027987_4ACE3513_4954_9356_1_94C682931C08B048B7A8645303FDC9F3078192F9D9@PUEXCB1B.nanterre.francetelecom.fr> References: <11879.19213.qm@web111410.mail.gq1.yahoo.com> In-Reply-To: <11879.19213.qm@web111410.mail.gq1.yahoo.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR x-tm-as-product-ver: SMEX-8.0.0.1259-5.500.1027-16048.005 x-tm-as-result: No--36.302000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.10.8.165123 X-Mailman-Approved-At: Thu, 08 Oct 2009 11:53:27 -0700 Cc: "mext@ietf.org" Subject: Re: [MEXT] [shara] Fw: New Version Notification for draft-sarikaya-aplusp-dsmip-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 18:51:26 -0000 Hi all, The URL to access the file is: http://www.ietf.org/internet-drafts/draft-sa= rikaya-aplusp-dsmip-00.txt Cheers, Med =20 -----Message d'origine----- De : shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] De la part de B= ehcet Sarikaya Envoy=E9 : jeudi 8 octobre 2009 18:53 =C0 : shara@ietf.org Cc : mext@ietf.org Objet : [shara] Fw: New Version Notification for draft-sarikaya-aplusp-dsmi= p-00 Hi all, =A0 We submitted this draft. Comments posted on the list will be appreciate= d. Regards, Behcet ----- Forwarded Message ---- > From: IETF I-D Submission Tool > To: sarikaya@ieee.org > Cc: xiayangsong@huawei.com; mohamed.boucadair@orange-ftgroup.com > Sent: Thu, October 8, 2009 11:46:35 AM > Subject: New Version Notification for draft-sarikaya-aplusp-dsmip-00 >=20 >=20 > A new version of I-D, draft-sarikaya-aplusp-dsmip-00.txt has been=20 > successfuly submitted by Behcet Sarikaya and posted to the IETF repositor= y. >=20 > Filename:=A0=A0=A0 draft-sarikaya-aplusp-dsmip > Revision:=A0=A0=A0 00 > Title:=A0=A0=A0 =A0=A0=A0 A+P for Dual-Stack Mobile IPv6 > Creation_date:=A0=A0=A0 2009-10-08 > WG ID:=A0=A0=A0 =A0=A0=A0 Independent Submission > Number_of_pages: 15 >=20 > Abstract: > This memo describes how to use IPv6 Port Range transition technique in=20 > mobile networks for Dual-Stack Mobile IPv6 (DSMIPv6).=A0 Using the=20 > client based DSMIPv6, a mobile node (MN) which is a dual-stack node=20 > can be assigned with a shared IPv4 Home Address (HA) together with a=20 > port range from the home agent.=A0 HA is co-located with Port Range=20 > Router (PRR).=A0 IPv4-in-IPv6 encapsulation is used to convey IPv4=20 > traffic between the network and the mobile node (MN).=A0 HA, acting as=20 > PRR receives incoming IPv4 datagrams and determines the routing=20 > identifier (IPv6 address) to use to forward the traffic to the=20 > appropriate MN among those sharing the same IPv4 address.=A0 In the=20 > binding mode, HA finds the binding cache entry for this MN and then=20 > encapsulates the IPv4 datagram in an IPv6 one and forwards the=20 > encapsulated datagram to MN.=A0 The stateless mode is also described. > Within this memo, Mobile network could be WiMAX network or 3GPP Long=20 > Term Evolution (LTE) network. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0=20 > =A0=20 >=20 >=20 > The IETF Secretariat. =20=20=20=20=20=20 _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From charles.perkins@earthlink.net Thu Oct 8 12:15:33 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0939128C19D for ; Thu, 8 Oct 2009 12:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb+5lCw5kovC for ; Thu, 8 Oct 2009 12:15:32 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 1E85628C15F for ; Thu, 8 Oct 2009 12:15:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=dTPwddfJYp+OnCtdTR59cwdNd5A5lsX6CNAn0qsMU+pKRBlKmG89odq4PtYEBJoK; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.12]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MvyUE-0006VU-J3; Thu, 08 Oct 2009 15:17:14 -0400 Message-ID: <4ACE3AB6.9090708@earthlink.net> Date: Thu, 08 Oct 2009 12:17:10 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Vijay Devarapalli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f520f1a63ac1b2229f281dcc53527eab3bc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: mext@ietf.org Subject: [MEXT] Weird problem with "Section section" [was, RFC 3775 bis / draft-ietf-mext-rfc3775bis] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 19:15:33 -0000 Hello Vijay, Strangely, there doesn't seem to be anything in the document that should produce the erroneous occurrences of "Section section" or "Section section". Maybe it is a bug with xml2rfc. I'll scan the output and make the repairs manually. If anyone else has information about this, please let me know. Regards, Charlie P. Vijay Devarapalli wrote: > I reviewed the document. It is ready to be sent to the IESG. > > I have a couple of minor comments. > > There are a few instances of "Section Section" in the document. I saw > them in sections 10.3.2, 11.3.6 and 11.5.2. > > The following needs a re-write. > > Binding Error > > The Binding Error is used by the correspondent node or the home > agent to signal an error related to mobility, such as an > inappropriate attempt to use the Home Address destination option > without an existing binding, or when an unrecognized Mobility > Header is received. > > The HA sends a binding error to the mobile node only when it sees an > unrecognized Mobility Header Type. So I suggest re-writing it as > > Binding Error > > The Binding Error is used by the correspondent node to signal an > error related to mobility, such as an inappropriate attempt to use > > the Home Address destination option without an existing binding. > The Binding Error message is also used by the Home Agent to signal > > an error to the mobile node, when it receives an unrecognized > Mobility Header Message Type from the mobile node. > > Vijay > > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Laganier, Julien >> Sent: Wednesday, August 05, 2009 8:20 AM >> To: mext@ietf.org >> Subject: [MEXT] [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis >> >> Folks, >> >> As discussed during the MEXT session in IETF-75 we're issuing >> a two weeks WGLC on RFC 3775 bis >> >> that will follow the two rules below: >> >> - this WGLC is NOT intended for re-opening discussions on >> issues that were resolved during the revision process neither >> for bringing up new issues. >> >> - this WGLC is intended to be sanity check to see whether the >> various changes we agreed to made fit together. Editorial >> corrections are also welcome. >> >> Please review the specification and post a message to the >> mailing list if you think the document is ready to be >> forwarded to IESG before 2009-08-15 6:00PM PST. >> >> Thank you for your support. >> >> --julien & Marcelo, MEXT chairs >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > From charles.perkins@earthlink.net Thu Oct 8 12:37:08 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B243A69EF for ; Thu, 8 Oct 2009 12:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVhR2WzTH3GN for ; Thu, 8 Oct 2009 12:37:07 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 130453A69ED for ; Thu, 8 Oct 2009 12:37:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=r+R6WjnYAfpVfs62ZQ0u6bk1yOilwnFIJnc/WkOEfWOGa9P8UYxLyG3D8Z74tVgr; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.12]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Mvyp3-0002s9-JP; Thu, 08 Oct 2009 15:38:46 -0400 Message-ID: <4ACE3FC0.6030805@earthlink.net> Date: Thu, 08 Oct 2009 12:38:40 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tony Cheneau References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52b080237b7d03f430f0e26d8aa40ccd87350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: draft-ietf-mext-rfc3775bis@tools.ietf.org, mext@ietf.org Subject: Re: [MEXT] Typos in draft-ietf-mext-rfc3775bis-04 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 19:37:08 -0000 Hello Tony, Thanks for your comments! I have made all the suggested repairs to the text. Regards, Charlie P. Tony Cheneau wrote: > Hello dear RFC3775-bis authors, > > > Since I'm new to this working group, I can not give any technical > comments on > the content of the document. However, while reading through the > document, I've > noted some typos, which are as follow: > - section 6.1.8: the status field is the third item to be described. > In the > format, it is the first field. I think it should be moved to be the > first > item. > - section 11.3.4, please remove the dot: " The application uses > the care-of address as a source address for > multicast traffic, just like it would use a stationary address. > This requires that the application either knows the care-of > address, or uses an API such as the IPv6 Socket API for Source > Address Selection specification [24]. to request the stack to use > ^ > the care-of address as a source address in sent packets. The > mobile node MUST NOT use Home Address destination option in such > traffic. > " > - section 11.5.2 contains self reference: > " o The MN performs the procedure described in Section 11.5.2x and > ^^^^^^^ > configures an address. It also keeps track of all the on-link > prefix(es) received in the RA along with their prefix lengths. > " > - section 11.7.4: > " When a mobile node receives a packet containing a Binding Refresh > Request message, the mobile node has a Binding Update List entry for > ^^ > add "if" > the source of the Binding Refresh Request, and the mobile node wants > to retain its binding cache entry at the correspondent node, then the > mobile node should start a return routability procedure." > > Hope it helps. > > Best regards, > Tony Cheneau > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From charles.perkins@earthlink.net Thu Oct 8 12:39:34 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE0633A69ED for ; Thu, 8 Oct 2009 12:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egPr8F1jPOPn for ; Thu, 8 Oct 2009 12:39:34 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 129E33A6916 for ; Thu, 8 Oct 2009 12:39:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=cFmssfGDZJJK/o5bg84ou8cf3UidBv2mJQKlNZB+W49dilrWsl1IdGHRivHLeLwB; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.12]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MvyrU-00068W-KS; Thu, 08 Oct 2009 15:41:16 -0400 Message-ID: <4ACE405A.8060807@earthlink.net> Date: Thu, 08 Oct 2009 12:41:14 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Vijay Devarapalli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f520064960b8daef7896eea050476d574aa350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: mext@ietf.org Subject: Re: [MEXT] [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 19:39:35 -0000 Hello Vijay, Thanks for these comments. I have used your suggested text. Regards, Charlie P. Vijay Devarapalli wrote: > I reviewed the document. It is ready to be sent to the IESG. > > I have a couple of minor comments. > > There are a few instances of "Section Section" in the document. I saw > them in sections 10.3.2, 11.3.6 and 11.5.2. > > The following needs a re-write. > > Binding Error > > The Binding Error is used by the correspondent node or the home > agent to signal an error related to mobility, such as an > inappropriate attempt to use the Home Address destination option > without an existing binding, or when an unrecognized Mobility > Header is received. > > The HA sends a binding error to the mobile node only when it sees an > unrecognized Mobility Header Type. So I suggest re-writing it as > > Binding Error > > The Binding Error is used by the correspondent node to signal an > error related to mobility, such as an inappropriate attempt to use > > the Home Address destination option without an existing binding. > The Binding Error message is also used by the Home Agent to signal > > an error to the mobile node, when it receives an unrecognized > Mobility Header Message Type from the mobile node. > > Vijay > > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Laganier, Julien >> Sent: Wednesday, August 05, 2009 8:20 AM >> To: mext@ietf.org >> Subject: [MEXT] [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis >> >> Folks, >> >> As discussed during the MEXT session in IETF-75 we're issuing >> a two weeks WGLC on RFC 3775 bis >> >> that will follow the two rules below: >> >> - this WGLC is NOT intended for re-opening discussions on >> issues that were resolved during the revision process neither >> for bringing up new issues. >> >> - this WGLC is intended to be sanity check to see whether the >> various changes we agreed to made fit together. Editorial >> corrections are also welcome. >> >> Please review the specification and post a message to the >> mailing list if you think the document is ready to be >> forwarded to IESG before 2009-08-15 6:00PM PST. >> >> Thank you for your support. >> >> --julien & Marcelo, MEXT chairs >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > From charles.perkins@earthlink.net Thu Oct 8 13:11:20 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C7393A69EF for ; Thu, 8 Oct 2009 13:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12sseYmjzJo3 for ; Thu, 8 Oct 2009 13:11:19 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 5EBC43A67D4 for ; Thu, 8 Oct 2009 13:11:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=MqyiUwgIAcnBlh0/9UVEFmpKNBnsd84jRcSMvYeUKq4WvEKZbwsdTNYqh1kzd8hf; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.12]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MvzMD-0005x7-5R; Thu, 08 Oct 2009 16:13:01 -0400 Message-ID: <4ACE47C8.8050401@earthlink.net> Date: Thu, 08 Oct 2009 13:12:56 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ryuji Wakikawa References: <0C5D7BDC-83FD-4C8F-A118-25AB41AA0272@gmail.com> In-Reply-To: <0C5D7BDC-83FD-4C8F-A118-25AB41AA0272@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f528a89f492d4f6d8da194942db8d159598350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "Laganier, Julien" , "mext@ietf.org" Subject: Re: [MEXT] [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 20:11:20 -0000 Hello Ryuji, Thanks for your review. Ryuji Wakikawa wrote: > Hi Charlie and all > > I reviewed this document and support the current version. > It's ready to be sent to IESG. > > - In Appendix A, A4 and A5 are outdated future things, they were > solved by bootstraping RFCs!? I updated one of the cross-references in the main text to refer to the bootstrapping RFC. I think some of the other items described as future work are also done. I'll try to go through them today. > > The next two comments have low priority, but they are just for better > readability. > > - Although there is the reference entry of RFC4225, it is not cited > anywhere in the text body. > Should we refer to it somewhere in the text body? Maybe in section 5.2? I put the citation just after the cross-reference to Section 15. > > - 3.2 Mobile IPv6 Terms > There is RFC 3753 defining the same terms. > home address, home subnet prefix, mobile node, L2 handover, foreign > subnet prefix, care-of address, home agent are defined in RFC3753 > It's OK to me to keep the same terms here, but adding reference of > rfc3753 may help readers. I did that too, keeping the definitions in the document for convenience. Regards, Charlie P. From charles.perkins@earthlink.net Thu Oct 8 13:20:18 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C90A3A689B for ; Thu, 8 Oct 2009 13:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.706 X-Spam-Level: X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iem8GNSXe2vs for ; Thu, 8 Oct 2009 13:20:17 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 895EA3A6804 for ; Thu, 8 Oct 2009 13:20:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=UrZ0+HgsnuSTwM7zhx+0GKqXToqLjxmp0YAaF2L9jDEmQFW+z0web4LIDGKkea6b; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.12]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MvzUu-0001Pr-0y; Thu, 08 Oct 2009 16:22:00 -0400 Message-ID: <4ACE49E6.8000005@earthlink.net> Date: Thu, 08 Oct 2009 13:21:58 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A925DBD.3050003@gmail.com> In-Reply-To: <4A925DBD.3050003@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f520214c94e9450f274170c759231dc0b7b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "mext@ietf.org" Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 20:20:18 -0000 Hello Alex, I didn't see any text in rfc3775bis that referred to mobile networks. But if you have a suggestion about where it would fit, please let me know. I don't think the spec should attempt to refer to all later work. For instance we have MCoA, and Proxy MIP, and who knows what all variants of SIP mobility and SCTP mobility and DNS mobility and HIP mobility and TCP mobility, just to name a few :-) Before long, maybe we'll have NAT boxes implementing mobility by transferring translation contexts :-). [I have not patented this :-), go for it!]. Regards, Charlie P. Alexandru Petrescu wrote: > I suggest the draft-3775bis to refer to RFC3963 in some way. > > Alex > From charles.perkins@earthlink.net Thu Oct 8 13:27:48 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1DB3A69EF for ; Thu, 8 Oct 2009 13:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.712 X-Spam-Level: X-Spam-Status: No, score=-1.712 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrSQLGQupQgm for ; Thu, 8 Oct 2009 13:27:48 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id C8D573A6804 for ; Thu, 8 Oct 2009 13:27:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=r4b6ew5XMUoKo7MmDpkyojwujeFNsGM4cPGnVc9dRfTHosAtRwh0FfnCfL+r42C5; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.12]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MvzcA-0003BT-Ab; Thu, 08 Oct 2009 16:29:30 -0400 Message-ID: <4ACE4BA5.50800@earthlink.net> Date: Thu, 08 Oct 2009 13:29:25 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Stupar, Patrick" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f524e49cabf8c40f7462225d658e556a40e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "Basavaraj Patil \(NTC/Dallas\)" , "mext@ietf.org" Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 20:27:48 -0000 Hello Patrick and Basavaraj, Thanks again Patrick for your review. I have made the change as you suggested, with the later revision as suggested by Basavaraj. Regards, Charlie P. Stupar, Patrick wrote: > Hi all, > > I reviewed the draft and I think it is ready to be sent to the IESG. > > I have one minor comment on section 11.5.2. > > The text does not cover the case of MN bootstrapping in home link. Here is a proposal: > > OLD TEXT > > 11.5.2. Home Link Detection > > When an MN detects that it has arrived on a new link using the > movement detection algorithm in use (Section Section 11.5.1,) it > performs the following steps to determine if it is on the home link. > > o The MN performs the procedure described in Section 11.5.2x and > configures an address. It also keeps track of all the on-link > prefix(es) received in the RA along with their prefix lengths. > > o If the home prefix has not been statically configured the MN uses > some form of bootstrapping procedure (e.g. RFC5026 [25]) to > determine the home prefix. > > o Given the availability of the home prefix, the MN checks whether > or not the home prefix matches one of the prefixes received in the > RA. If it does, the MN concludes that it has returned home. > > NEW TEXT > > 11.5.2. Home Link Detection > > When an MN detects that it has arrived on a new link using the > movement detection algorithm in use (Section 11.5.1) or after bootstrapping, it > performs the following steps to determine if it is on the home link. > > o The MN performs the procedure described in Section 11.5.3 and > configures an address. It also keeps track of all the on-link > prefix(es) received in the RA along with their prefix lengths. > > o If the home prefix has not been statically configured the MN uses > some form of bootstrapping procedure (e.g. RFC5026 [25]) to > determine the home prefix. > > o Given the availability of the home prefix, the MN checks whether > or not the home prefix matches one of the prefixes received in the > RA. If it does, the MN concludes that it is connected to the home link. > > > > Thanks > > Patrick > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of >> Laganier, Julien >> Sent: Friday, August 21, 2009 8:30 PM >> To: Laganier, Julien; mext@ietf.org >> Subject: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext- >> rfc3775bis >> >> Greetings, >> >> There was only one review of the draft RFC3775bis so far and we need >> more to send this document to IESG thus we decided to extend the WGLC. >> >> Please review the specification and post a message to the mailing list >> if you think the document is ready to be forwarded to IESG before 2009- >> 09-11 6:00PM EST. >> >> --julien & marcelo, MEXT chairs >> >> >>> -----Original Message----- >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf >>> >> Of >> >>> Laganier, Julien >>> Sent: Wednesday, August 05, 2009 8:20 AM >>> To: mext@ietf.org >>> Subject: [MEXT] [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis >>> >>> Folks, >>> >>> As discussed during the MEXT session in IETF-75 we're issuing a two >>> weeks WGLC on RFC 3775 bis >> >> mext- >> >>> rfc3775bis-04> that will follow the two rules below: >>> >>> - this WGLC is NOT intended for re-opening discussions on issues that >>> were resolved during the revision process neither for bringing up new >>> issues. >>> >>> - this WGLC is intended to be sanity check to see whether the various >>> changes we agreed to made fit together. Editorial corrections are >>> >> also >> >>> welcome. >>> >>> Please review the specification and post a message to the mailing >>> >> list >> >>> if you think the document is ready to be forwarded to IESG before >>> >> 2009- >> >>> 08-15 6:00PM PST. >>> >>> Thank you for your support. >>> >>> --julien & Marcelo, MEXT chairs >>> >>> _______________________________________________ >>> MEXT mailing 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 ext-fuad.junior@nokia.com Thu Oct 8 13:31:58 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23DFA3A69EF for ; Thu, 8 Oct 2009 13:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQlwl5p4q7fL for ; Thu, 8 Oct 2009 13:31:57 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 4B98D3A68DD for ; Thu, 8 Oct 2009 13:31:57 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n98KX40A013435; Thu, 8 Oct 2009 15:33:39 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 23:33:31 +0300 Received: from mzebe101.NOE.Nokia.com ([172.18.252.71]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 23:33:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Oct 2009 16:33:25 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus call to adopt I-D: draft-premec-mext-extended-home-link-04 as a MEXT WG doc Thread-Index: AcpIVpZDPy0ys0JWSiewKOfWaCKxRQ== From: To: X-OriginalArrivalTime: 08 Oct 2009 20:33:31.0169 (UTC) FILETIME=[99696910:01CA4856] X-Nokia-AV: Clean Cc: mext-chairs@ietf.org Subject: [MEXT] Consensus call to adopt I-D: draft-premec-mext-extended-home-link-04 as a MEXT WG doc X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 20:31:58 -0000 Hi, I have revised the I-D "IPv4 Support for DSMIPv6 IPv6 Home Link" based on comments received. This I-D has been previously accepted for being adopted as WG document, since it solves the problem of a DSMIP6 MN attaching to an IPv6 only home-link. Therefore, I would like to request approval from the chairs to post the I-D as WG document.=20 Any reviews or comments from others are also appreciated. Regards, Fuad Abinader From ext-fuad.junior@nokia.com Thu Oct 8 13:48:42 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADF153A6968 for ; Thu, 8 Oct 2009 13:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI9Pyk8Fc3xT for ; Thu, 8 Oct 2009 13:48:42 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 8FEC43A6833 for ; Thu, 8 Oct 2009 13:48:41 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n98KoLcG028340; Thu, 8 Oct 2009 23:50:21 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 23:50:21 +0300 Received: from mzebe101.NOE.Nokia.com ([172.18.252.71]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 23:50:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Oct 2009 16:50:13 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus call to adopt I-D:draft-premec-mext-extended-home-link-04 as a MEXT WG doc Thread-Index: AcpIVpZDPy0ys0JWSiewKOfWaCKxRQAAKv3g References: From: To: X-OriginalArrivalTime: 08 Oct 2009 20:50:20.0190 (UTC) FILETIME=[F2D5CBE0:01CA4858] X-Nokia-AV: Clean Cc: mext-chairs@tools.ietf.org Subject: Re: [MEXT] Consensus call to adopt I-D:draft-premec-mext-extended-home-link-04 as a MEXT WG doc X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 20:48:42 -0000 Hi, In the previous e-mail I wrongly added the subject as a "Consensus call". Instead, I meant to Request the I-D to be accepted as a WG Item instead. As I'm not a WG chair, I realized I have made a mistake. Therefore, forget this e-mail, as I'll send another one in the correct form and content. Regards, Fuad Abinader >-----Original Message----- >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 >Behalf Of ext ext-fuad.junior@nokia.com >Sent: quinta-feira, 8 de outubro de 2009 16:33 >To: mext@ietf.org >Cc: mext-chairs@ietf.org >Subject: [MEXT] Consensus call to adopt=20 >I-D:draft-premec-mext-extended-home-link-04 as a MEXT WG doc > >Hi, > > I have revised the I-D "IPv4 Support for DSMIPv6 IPv6 Home Link" > based on comments received. >This I-D has been previously accepted for being adopted as WG=20 >document, since it solves the problem of a DSMIP6 MN attaching=20 >to an IPv6 only home-link. Therefore, I would like to request=20 >approval from the chairs to post the I-D as WG document.=20 > Any reviews or comments from others are also appreciated. > >Regards, > >Fuad Abinader >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext > From charles.perkins@earthlink.net Thu Oct 8 13:53:08 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510C73A68D1 for ; Thu, 8 Oct 2009 13:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPuI2Qx1MJow for ; Thu, 8 Oct 2009 13:53:07 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 5F15D3A67D8 for ; Thu, 8 Oct 2009 13:53:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=msa3UovtfT1rZWkgzM7g7DkACc2cYdMkwBje0K81g8IbnLegdeh8TwelA8RxLj5v; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.12]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Mw00f-0001bS-O8; Thu, 08 Oct 2009 16:54:50 -0400 Message-ID: <4ACE5196.2040505@earthlink.net> Date: Thu, 08 Oct 2009 13:54:46 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ahmad Muhanna References: <4AAA7BF4.6030705@wichorus.com> In-Reply-To: <4AAA7BF4.6030705@wichorus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f528286f6d400b146a655d5ea316261b648350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: mext@ietf.org Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 20:53:08 -0000 Charles E. Perkins wrote: > > Hello Ahmad, > > Thanks for your review. I'll try to make the > requested clarifications as follows... > > Ahmad Muhanna wrote: >> I just failed to understand what is the 2nd sentence under section 4.6 >> is trying to say. I see the old text was clearer than the newly modified >> text. Appreciate your clarification. >> >> 4.6. Unique-Local Addressability >> >> ................................ Mobile nodes may not be aware of >> which site they are currently making it hard to prevent accidental >> attachment to other sites, resulting in possible unrechability >> between the MN and the HA, when unique-local IPv6 routable addresses >> are used as care-of addresses. .................................... >> > > If a mobile node tries to use a unique-local address, it could be > an address belonging to a domain other than the home domain. > Thus, the MIPv6 signaling would never reach the MN's home > agent. > > Does this match your understanding? If so, I will try to put in the > clearer sentences to clarify the meaning of that sentence. Here is what I put in for this issue: .................. Mobile nodes may not be to distinguish between their home site and the site at which they are currently located. This can make it hard to prevent accidental attachment to other sites, because the mobile node might use the ULA at another site, which could not be used to successfully send packets to the mobile node's HA. This would result in unreachability between the MN and the HA, when unique-local IPv6 routable addresses are used as care-of addresses. Similarly, CNs outside the MN's own site will not be reachable when ULAs are used as home addresses. Therefore, unique-local IPv6 unicast addresses SHOULD NOT be used as home or care-of addresses when other address choices are available. I also fixed that wretched typo, "unrechability". > >> Comment No. 2: >> ============== >> >> >> ......... >> >> o If the Lifetime specified in the Binding Update is zero, then this >> is a request to delete the cached binding for the home address. >> If the Home Registration (H) bit is set in the Binding Update, the >> Binding Update is processed according to the procedure specified >> in Section 10.3.1; otherwise, it is processed according to the >> procedure specified in Section 9.5.2. >> >> >> My concern is: the new change reverse the logic completely and despite >> that, the second sentence in this bullet still reference sections 10.3.1 >> and 9.5.2. where both handles the processing of BU when lifetime is >> NONZERO! >> >> ............................. >> > > I think you are right. I need to go back and reorganize the bullets. > The particular > bullet you cite would be better as two bullets: > > o If the Lifetime specified in the Binding Update is zero, then this > is a request to delete the cached binding for the home address. > > o If the Home Registration (H) bit is set in the Binding Update, the > Binding Update is processed according to the procedure specified > in Section 10.3.1; otherwise, it is processed according to the > procedure specified in Section 9.5.2. > > But this needs to be integrated with the rest of the bullets also. > > The previous discussion around this issue was to make the "lifetime == 0" > alternative to be the authoritative decision point, and to > de-emphasize the > role of "CoA == HoA". This is the same issue that was later identifed by Arnaud. I must have had a brain freeze when inserting the language to carry out the decision in the last paragraph, or else I just dropped in someone's contributed text without going and reading all the surrounding context (which is just another kind of brain freeze). I remember that was supposed to be an "easy" revision to the text, sigh. I'll make sure this is fixed in ...rfc3775bis-05.txt, thanks. Regards, Charlie P. From ext-fuad.junior@nokia.com Thu Oct 8 13:58:44 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E2153A68FF for ; Thu, 8 Oct 2009 13:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjQmBPDmsk9F for ; Thu, 8 Oct 2009 13:58:43 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 275A53A68D1 for ; Thu, 8 Oct 2009 13:58:42 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n98L0ABQ000402; Fri, 9 Oct 2009 00:00:23 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 00:00:19 +0300 Received: from mzebe101.NOE.Nokia.com ([172.18.252.71]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 00:00:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Oct 2009 17:00:13 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for I-D draft-premec-mext-extended-home-link-04 being accepted as a MEXt WG item Thread-Index: AcpIV+GPljjmHhdNSS+k+0MChYvOrAAASRxg From: To: X-OriginalArrivalTime: 08 Oct 2009 21:00:18.0924 (UTC) FILETIME=[57B55AC0:01CA485A] X-Nokia-AV: Clean Cc: mext-chairs@tools.ietf.org Subject: [MEXT] Request for I-D draft-premec-mext-extended-home-link-04 being accepted as a MEXt WG item X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 20:58:44 -0000 Hi, I have revised the I-D "IPv4 Support for DSMIPv6 IPv6 Home Link" = (http://tools.ietf.org/html/draft-premec-mext-extended-home-link-04) = based on comments received. This I-D has been previously accepted for = being adopted as WG document, since it solves the problem of a DSMIP6 MN = attaching to an IPv6 only home-link. Therefore, I would like to request = approval from the chairs to post the I-D as WG document.=20 Any reviews or comments from others are also appreciated. Regards, Fuad Abinader >-----Original Message----- >From: ext Fuad Abinader [mailto:fabinader@gmail.com]=20 >Sent: quinta-feira, 8 de outubro de 2009 16:43 >To: Junior Fuad (EXT-INdT/Manaus) >Subject: Fwd: New Version Notification for=20 >draft-premec-mext-extended-home-link-04 > >---------- Forwarded message ---------- >From: IETF I-D Submission Tool >Date: 2009/10/8 >Subject: New Version Notification for=20 >draft-premec-mext-extended-home-link-04 >To: fabinader@gmail.com >Cc: domagoj.premec@gmail.com, jouni.nospam@gmail.com > > > >A new version of I-D,=20 >draft-premec-mext-extended-home-link-04.txt has been=20 >successfuly submitted by Fuad Abinader and posted to the IETF=20 >repository. > >Filename: =A0 =A0 =A0 =A0draft-premec-mext-extended-home-link >Revision: =A0 =A0 =A0 =A004 >Title: =A0 =A0 =A0 =A0 =A0 IPv4 Support for DSMIPv6 IPv6 Home Link >Creation_date: =A0 2009-10-08 >WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission >Number_of_pages: 13 > >Abstract: >Mobile IPv6 for Dual Stack Hosts and Routers enables mobility=20 >for the mobile node's IPv6 home address or prefix as well as=20 >an IPv4 home address, irrespective of the IP version supported=20 >on the link that the mobile node is attached to. =A0The home=20 >agent maintains binding cache entries for the IPv6 and IPv4=20 >home addresses assigned to the mobile node when the mobile=20 >node is connected via a foreign link. >The binding cache entries are deprecated when the mobile node=20 >attaches to its home link. =A0This document addresses an issue=20 >related to the de-registration procedure and the continued=20 >connectivity for the IPv4 home address when the mobile node=20 >attaches to its IPv6-only home link. > > > >The IETF Secretariat. > From charles.perkins@earthlink.net Thu Oct 8 14:11:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86CE13A68B1 for ; Thu, 8 Oct 2009 14:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.723 X-Spam-Level: X-Spam-Status: No, score=-1.723 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPZhso7nlkFK for ; Thu, 8 Oct 2009 14:11:13 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 92C9D3A6833 for ; Thu, 8 Oct 2009 14:11:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ANi+M2dfkQCe2FHEskLwYxnCv8u9lTwEyl3wRSa1G9fL6zYGXG7UcHTmrBcqXglP; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.12]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Mw0I9-0008LJ-Ee for mext@ietf.org; Thu, 08 Oct 2009 17:12:54 -0400 Message-ID: <4ACE55CE.5060401@earthlink.net> Date: Thu, 08 Oct 2009 14:12:46 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mext References: <4ACE3AB6.9090708@earthlink.net> <3d57679a0910081256h2d56beb8r5b38e81acee2f523@mail.gmail.com> In-Reply-To: <3d57679a0910081256h2d56beb8r5b38e81acee2f523@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f523954ee53fda7fef514755afaa5e59d67350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Subject: Re: [MEXT] Weird problem with "Section section" [was, RFC 3775 bis / draft-ietf-mext-rfc3775bis] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 21:11:14 -0000 Hello Rajeev and all, The .xml file I used now produces good text without the duplicated "Section". It had not had the word "Section" before the tag, but anyway since everything is working fine now, the issue is resolved. And anyway I will scan the document for the duplication again before submitting the revised text to the Secretariat. Which I hope will be today :-) One possible explanation was that I had actually fixed the problem before submitting the last revision [...rfc3775bis-04.txt] to the Secretariat in July, but that I compiled the wrong version of the .xml and so the error was unfortunately still present and yet not to be found in my most recently revised .xml file. Regards, Charlie P. Rajeev Koodli wrote: > Hi Charlie, > > when you reference something simply use instead of > "Section " > > May be that will do the trick. Or it's something else.. > > Regards, > > -Rajeev > > > > On Thu, Oct 8, 2009 at 12:17 PM, Charles E. Perkins > wrote: > >> Hello Vijay, >> >> Strangely, there doesn't seem to be anything in the >> document that should produce the erroneous occurrences >> of "Section section" or "Section section". Maybe it is a >> bug with xml2rfc. I'll scan the output and make the >> repairs manually. >> >> If anyone else has information about this, please let >> me know. >> >> Regards, >> Charlie P. >> >> Vijay Devarapalli wrote: >> >>> I reviewed the document. It is ready to be sent to the IESG. >>> I have a couple of minor comments. >>> >>> There are a few instances of "Section Section" in the document. I saw >>> them in sections 10.3.2, 11.3.6 and 11.5.2. >>> >>> The following needs a re-write. >>> Binding Error >>> >>> The Binding Error is used by the correspondent node or the home >>> agent to signal an error related to mobility, such as an >>> inappropriate attempt to use the Home Address destination option >>> without an existing binding, or when an unrecognized Mobility >>> Header is received. >>> >>> The HA sends a binding error to the mobile node only when it sees an >>> unrecognized Mobility Header Type. So I suggest re-writing it as >>> >>> Binding Error >>> >>> The Binding Error is used by the correspondent node to signal an >>> error related to mobility, such as an inappropriate attempt to use >>> >>> the Home Address destination option without an existing binding. >>> The Binding Error message is also used by the Home Agent to signal >>> >>> an error to the mobile node, when it receives an unrecognized >>> Mobility Header Message Type from the mobile node. >>> >>> Vijay >>> >>> >>> >>>> -----Original Message----- >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of >>>> Laganier, Julien >>>> Sent: Wednesday, August 05, 2009 8:20 AM >>>> To: mext@ietf.org >>>> Subject: [MEXT] [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis >>>> >>>> Folks, >>>> >>>> As discussed during the MEXT session in IETF-75 we're issuing a two weeks >>>> WGLC on RFC 3775 bis >>>> that will follow >>>> the two rules below: >>>> >>>> - this WGLC is NOT intended for re-opening discussions on issues that >>>> were resolved during the revision process neither for bringing up new >>>> issues. >>>> - this WGLC is intended to be sanity check to see whether the various >>>> changes we agreed to made fit together. Editorial corrections are also >>>> welcome. >>>> >>>> Please review the specification and post a message to the mailing list if >>>> you think the document is ready to be forwarded to IESG before 2009-08-15 >>>> 6:00PM PST. >>>> >>>> Thank you for your support. >>>> >>>> --julien & Marcelo, MEXT chairs >>>> >>>> _______________________________________________ >>>> MEXT mailing 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 Benjamin.Limck@sg.panasonic.com Thu Oct 8 22:40:36 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04AB13A6817 for ; Thu, 8 Oct 2009 22:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.369 X-Spam-Level: ** X-Spam-Status: No, score=2.369 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_73=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 PlZU5Z1YxKHF for ; Thu, 8 Oct 2009 22:40:34 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 5F1BF3A67AC for ; Thu, 8 Oct 2009 22:40:34 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id n995gHaR025821 for ; Fri, 9 Oct 2009 14:42:17 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili04) with ESMTP id n995gEG20088 for ; Fri, 9 Oct 2009 14:42:15 +0900 (JST) Received: from [10.81.113.115] ([10.81.113.115]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 13:38:04 +0800 Message-ID: <4ACECC69.2080601@sg.panasonic.com> Date: Fri, 09 Oct 2009 13:38:49 +0800 From: Benjamin Lim User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "mext@ietf.org" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2009 05:38:04.0640 (UTC) FILETIME=[AC516E00:01CA48A2] Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 05:40:36 -0000 Hi, I have reviewed the draft and it seems to be in good shape. Some comments below. Comment 1 -------------- Reference updates for I-D.ietf-mext-nemo-v4traversal --> RFC 5555 I-D.ietf-monami6-multiplecoa --> RFC 5648 Comment 2 -------------- In section 4.4, it states "A valid BID is required to make the entry "active". If all of the BIDs pointed to by a given entry are not valid BIDs in the binding cache, the flow binding entry becomes "inactive", in other words it does not affect data traffic." FID-PRI FID Flow Description BIDs Action A/I ------- --- ---------------- ---- ------- ------ 10 4 TCP 2 Forward Active 20 3 srcAddr=IPx N/A Discard Active 30 2 srcAddr=IPy 4 Forward Inactive 40 5 UDP 1,3 N-Cast Active Ordered Flow Binding Entries However, for the above figure, in the second entry, N/A mean no BID specified. If so, how can this be an active entry as there is no "valid BID"? I find this confusing. There are two ways to approach this, a) associate a BID with the discard action. This means that the definition of discard action in 4.2 needs to be updated. b) add more text in 4.4 to say that for discard action even if there is no BID associated to it, that entry is treated as valid. Comment 3 -------------- In section 5.3.2.1, the forward action is not defined in 4.2. From my reading of 4.2, my understanding is that using n-cast and specifying a single BID can be implied as the forward action. > 2 n-cast. This value indicates a request to send the flow to one or > more addresses indicated in the Binding Reference sub-option. One or > more BIDs MUST be associated with this Action. If only one BID is > associated with this action then it is essentially a request to > forward packets to that CoA. Care should be taken when the n-cast > action is used as some transport layers may not be able to handle > packet duplication and this can affect their performance. There are two ways to approach this, a) define action forward b) drop the text for action forward in 5.3.2.1. I prefer b) as I feel n-cast covers the forward action. Comment 4 -------------- In section 5.3.3, propose to reword the second paragraph to > If the value of any of the FID fields included in the flow summary > option is not present in the list of flow binding entries for this > mobile node, the home agent MUST reject this flow binding refresh by > including a flow identification option in the BA, and setting the FID > field in the value of the FID that is not found and the Status field > to 135 (FID not found). If the value of any of the FID fields included in the flow summary option is not present in the list of flow binding entries for this mobile node, the home agent MUST reject this flow binding refresh by including a flow identification option in the BA for each FID that is not found, and setting the FID field with the value of the FID and the Status field to 135 (FID not found). Comment 5 -------------- In section 5.3.3, in the third paragraph > If the value of the FID field is present in the mobile nodes list of > slow binding entries the, home agent SHOULD refresh the binding entry > s/ slow/ flow > identified by the FID without changing any of the other parameters > associated with it. Regards, Benjamin Lim From arno@natisbad.org Thu Oct 8 23:52:28 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F8B428C175 for ; Thu, 8 Oct 2009 23:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 tHI7S6IRKw5Y for ; Thu, 8 Oct 2009 23:52:27 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 020C228C19E for ; Thu, 8 Oct 2009 23:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natisbad.org; s=mail; h=From:To:Cc:Subject:References:Date: In-Reply-To:Message-ID:MIME-Version:Content-Type; bh=n5odRvU2F7z DAGorVA1QvS9tmeF/5ZAc2n46t/rLOrE=; b=jJ622ekGTCgMnTPn40MHmJH90TS rO0HCiCKB55dW9BmbVD/C2yLJ8+mcTqLj4UsBvWfZWwr8p6KsxLIELlf2fybIMSX M2Y/f1X18bsnNQ/OA4EMkNik/2/6eLGV99tFEirckua0Fv3mKIs7gSfcw861zI19 4UI9Kckl6/ju2OQo= Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Mw9Ma-0003Yn-OL; Fri, 09 Oct 2009 08:54:04 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "Charles E. Perkins" References: <4AAA7BF4.6030705@wichorus.com> <4ACE5196.2040505@earthlink.net> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:091009:mext@ietf.org::RreXVUTQE0vLqoff:00000go8 X-Hashcash: 1:20:091009:amuhanna@nortel.com::bIMbgwHRA+MqsoVq:0000000000000000000000000000000000000000000caP X-Hashcash: 1:20:091009:charles.perkins@earthlink.net::LTGboLSbSw7vVwPI:0000000000000000000000000000000028SF Date: Fri, 09 Oct 2009 08:54:32 +0200 In-Reply-To: <4ACE5196.2040505@earthlink.net> (Charles E. Perkins's message of "Thu, 08 Oct 2009 13:54:46 -0700") Message-ID: <87ocohhxav.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext@ietf.org Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 06:52:28 -0000 Hi, "Charles E. Perkins" writes: >> Ahmad Muhanna wrote: >>> I just failed to understand what is the 2nd sentence under section 4.6 >>> is trying to say. I see the old text was clearer than the newly modified >>> text. Appreciate your clarification. >>> >>> 4.6. Unique-Local Addressability >>> >>> ................................ Mobile nodes may not be aware of >>> which site they are currently making it hard to prevent accidental >>> attachment to other sites, resulting in possible unrechability >>> between the MN and the HA, when unique-local IPv6 routable addresses >>> are used as care-of addresses. .................................... >>> >> >> If a mobile node tries to use a unique-local address, it could be >> an address belonging to a domain other than the home domain. >> Thus, the MIPv6 signaling would never reach the MN's home >> agent. >> >> Does this match your understanding? If so, I will try to put in the >> clearer sentences to clarify the meaning of that sentence. > > Here is what I put in for this issue: > > .................. Mobile nodes may not be > to distinguish between their home site and the site at which they are s/may not be to/may not be able to/ > currently located. This can make it hard to prevent accidental > attachment to other sites, because the mobile node might use the ULA > at another site, which could not be used to successfully send packets > to the mobile node's HA. This would result in unreachability between > the MN and the HA, when unique-local IPv6 routable addresses are used > as care-of addresses. Similarly, CNs outside the MN's own site will > not be reachable when ULAs are used as home addresses. Therefore, > unique-local IPv6 unicast addresses SHOULD NOT be used as home or > care-of addresses when other address choices are available. I think SHOULD NOT is ok. This leaves some latitude to implementation specific options, I guess. Cheers, a+ From jsundara@qualcomm.com Fri Oct 9 10:22:06 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1136828C1E0 for ; Fri, 9 Oct 2009 10:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VKcjJZCLZsa for ; Fri, 9 Oct 2009 10:22:05 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 0145B28C183 for ; Fri, 9 Oct 2009 10:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=jsundara@qualcomm.com; q=dns/txt; s=qcdkim; t=1255109030; x=1286645030; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Sundararajan,=20Jay=20Kumar"=20|To:=20"mext@ietf.org"=20|Date:=20F ri,=209=20Oct=202009=2010:23:46=20-0700|Subject:=20Re:=20 [MEXT]=20[WGLC]=20draft-ietf-mext-flow-binding-03 |Thread-Topic:=20Re:=20[MEXT]=20[WGLC]=20draft-ietf-mext- flow-binding-03|Thread-Index:=20AcpJBUH63MH20GP1Sgmt6YyJf 4WXDg=3D=3D|Message-ID:=20<8FEE029FDE54A941981406081772A5 8B30F0481576@NALASEXMB09.na.qualcomm.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_8FEE029FDE54A941981406081772A58B30F04 81576NALASEXMB09na_"|MIME-Version:=201.0|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5300,2777,5766"=3B=20a=3D"24893317"; bh=xJufMeh2DhQ/cE+VoVAlkcGukoL6mp/dRr5v2mZtk2Y=; b=SFoagQ5qpumAN1+AupCV+sO9sto+4KkTLZLUiO83VexZAr6Epz763lIV 0L5IHuVTDeeMsPOEm2qHN39EMKc17C302sLyRZJfV+iFUE9OGPVE2NRDh 3e6oT5apy1BgW6CNyLNaWEjKs9k7Kjzdyi0i1PtGI+iOxMSdPO2TlxjYe 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5766"; a="24893317" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Oct 2009 10:23:49 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n99HNn3C018467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 9 Oct 2009 10:23:49 -0700 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 n99HNndI008498 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 9 Oct 2009 10:23:49 -0700 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 9 Oct 2009 10:23:49 -0700 Received: from NALASEXMB09.na.qualcomm.com ([10.47.16.15]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Fri, 9 Oct 2009 10:23:48 -0700 From: "Sundararajan, Jay Kumar" To: "mext@ietf.org" Date: Fri, 9 Oct 2009 10:23:46 -0700 Thread-Topic: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpJBUH63MH20GP1Sgmt6YyJf4WXDg== Message-ID: <8FEE029FDE54A941981406081772A58B30F0481576@NALASEXMB09.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8FEE029FDE54A941981406081772A58B30F0481576NALASEXMB09na_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 09 Oct 2009 10:27:57 -0700 Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 17:25:11 -0000 --_000_8FEE029FDE54A941981406081772A58B30F0481576NALASEXMB09na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I read the draft and it looks good. Just have a few comments (mostly minor = ones): Comment 1 In page 10, the term "Binding Reference sub-option" is used for the first t= ime before it is defined. It might be useful to say that it will be defined= later... Comment 2 Section 5.2.2.2 says: "To modify an existing flow binding the mobile node MUST send a binding upd= ate with a flow identification option, with the FID field set to one of the= FID values already in the list of flow binding entries." I might have missed something, but in this case, what prevents the HA from = sending a failure Status message "135 FID already in use" as mentioned in S= ection 5.3.2.1: "If the FID field of the flow identification option is already present in t= he list of flow binding entries for this mobile node, the home agent MUST r= eject this flow binding add request by copying the flow identification opti= on in the BA, and setting the Status field to 135 (FID already in use)." In other words, how would the receiver distinguish between a modify request= (which should not fail) and an add request with a used FID (which should f= ail)? Comment 3 In Sections 5.3.2.2 and 5.3.3, the "FID not found" Status is set to 135, wh= ereas the table in Page 9 says it is 136. Comment 4 Section 4.2.2 says "17-32 reserved for Flow Description formats". But the s= ection on IANA considerations says 16-32. Minor comments: 1. Page 6: "ant-replay" -> "anti-replay" 2. Page 9: Under FID: "an 16-bit" -> "a 16-bit" 3. End of pg 12: "refresing" -> "refreshing" 4. Pg 17: "Mobiles nodes" -> "Mobile nodes" 5. Pg 18: "Status filed" -> "Status field" 6. Section 5.2.4: "bingings" -> "bindings" 7. Section 5.3.2.2: "processes" -> "process" 8. Section 5.3.3: "slow binding entries the, " -> "flow binding entries, th= e" 9. Section 5.3.6: End of 1st paragraph: there seems to be an extra "when" --_000_8FEE029FDE54A941981406081772A58B30F0481576NALASEXMB09na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I read the draft and it looks good. Just have a few co= mments (mostly minor ones):

 

Comment 1

In page 10, the term "Binding Reference sub-optio= n" is used for the first time before it is defined. It might be useful to say = that it will be defined later...

 

 

Comment 2

Section 5.2.2.2 says:

"To modify an existing flow binding the mobile no= de MUST send a binding update with a flow identification option, with the FID field set to one of the FID values already in the list of flow binding entries."

 

I might have missed something, but in this case, what prevents the HA from sending a failure Status message "135 FID already= in use" as mentioned in Section 5.3.2.1:

 

"If the FID field of the flow identification opti= on is already present in the list of flow binding entries for this mobile node, t= he home agent MUST reject this flow binding add request by copying the flow identification option in the BA, and setting the Status field to 135 (FID already in use)."

 

In other words, how would the receiver distinguish bet= ween a modify request (which should not fail) and an add request with a used FID (which should fail)?

 

 

Comment 3

In Sections 5.3.2.2 and 5.3.3, the "FID not found= " Status is set to 135, whereas the table in Page 9 says it is 136.

 

 

Comment 4

Section 4.2.2 says "17-32 reserved for Flow Descr= iption formats". But the section on IANA considerations says 16-32.

 

 

Minor comments:

1. Page 6: "ant-replay" -> "anti-replay"

2. Page 9: Under FID: "an 16-bit" -> &quo= t;a 16-bit"

3. End of pg 12: "refresing" -> "refreshing"

4. Pg 17: "Mobiles nodes" -> "Mobile nodes"

5. Pg 18: "Status filed" -> "Status field"

6. Section 5.2.4: "bingings" -> "bindings"

7. Section 5.3.2.2: "processes" -> "process"

8. Section 5.3.3: "slow binding entries the, &quo= t; -> "flow binding entries, the"

9. Section 5.3.6: End of 1st paragraph: there seems to= be an extra "when"

--_000_8FEE029FDE54A941981406081772A58B30F0481576NALASEXMB09na_-- From charles.perkins@earthlink.net Fri Oct 9 11:42:40 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376513A67FC for ; Fri, 9 Oct 2009 11:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gW4zcdBLjBkn for ; Fri, 9 Oct 2009 11:42:39 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 89F4E3A67CF for ; Fri, 9 Oct 2009 11:42:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ajuV+7tQs4JLBlFtg7NvSrMIuQk7+gWlM8A1wmnXZ0FftprtHe56KITQgXTyTJNs; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.139]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MwKRq-0006YG-7q; Fri, 09 Oct 2009 14:44:14 -0400 Message-ID: <4ACF847C.2050805@earthlink.net> Date: Fri, 09 Oct 2009 11:44:12 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Arnaud Ebalard References: <4AAA7BF4.6030705@wichorus.com> <4ACE5196.2040505@earthlink.net> <87ocohhxav.fsf@small.ssi.corp> In-Reply-To: <87ocohhxav.fsf@small.ssi.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52165a828f0489337f593799ed4c70bd17350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: mext@ietf.org Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 18:42:40 -0000 Arnaud Ebalard wrote: > Hi, > > "Charles E. Perkins" writes: > > >>> >> Here is what I put in for this issue: >> >> .................. Mobile nodes may not be >> to distinguish between their home site and the site at which they are >> > > s/may not be to/may not be able to/ > Fixed. Thanks! > >> Therefore, >> unique-local IPv6 unicast addresses SHOULD NOT be used as home or >> care-of addresses when other address choices are available. >> > > I think SHOULD NOT is ok. This leaves some latitude to implementation > specific options, I guess. > Yes, it does leave some latitude, but I think correctly captures the intended level of restriction. Regards, Charlie P. From arno@natisbad.org Fri Oct 9 13:09:54 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DAAE3A695E for ; Fri, 9 Oct 2009 13:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 d0ca7to2asfI for ; Fri, 9 Oct 2009 13:09:53 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 85D723A685D for ; Fri, 9 Oct 2009 13:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natisbad.org; s=mail; h=From:To:Cc:Subject:References:Date: In-Reply-To:Message-ID:MIME-Version:Content-Type; bh=/u4miXVRCib DFScL4XPTuu1xEX4PPUH94cdlyO1RYhc=; b=iytiq2PaqF7OtSbH/CiDHBI0kNv Ds7+6+zuGnaqWabvgYmTIGWM/6n2+PTPrx8vPBUnUoz10prHklJW81quDKHh1Rqz pYpnaCX711j7nZhkvyQoWtK8mbg6e5FoxY7Dccq6/gIy6loEnunqhERSr81/7OU0 /CZ6s2HPpJekgwzg= Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MwLoM-0003vw-85; Fri, 09 Oct 2009 22:11:34 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "Charles E. Perkins" References: <4AAA7BF4.6030705@wichorus.com> <4ACE5196.2040505@earthlink.net> <87ocohhxav.fsf@small.ssi.corp> <4ACF847C.2050805@earthlink.net> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:091009:charles.perkins@earthlink.net::lvtFv6UxzW0k75eS:00000000000000000000000000000000477h X-Hashcash: 1:20:091009:mext@ietf.org::gy1QKEUZDgB+0e0c:00003zEN Date: Fri, 09 Oct 2009 22:11:59 +0200 In-Reply-To: <4ACF847C.2050805@earthlink.net> (Charles E. Perkins's message of "Fri, 09 Oct 2009 11:44:12 -0700") Message-ID: <87zl80jpio.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext@ietf.org Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 20:09:54 -0000 Hi, "Charles E. Perkins" writes: >>> Therefore, >>> unique-local IPv6 unicast addresses SHOULD NOT be used as home or >>> care-of addresses when other address choices are available. >>> >> >> I think SHOULD NOT is ok. This leaves some latitude to implementation >> specific options, I guess. >> > > Yes, it does leave some latitude, but I think correctly captures the > intended level of restriction. I read again the sentence and wonder about the following. Can you give me your feeling? It would be to bad (IMHO) if MIPv6 module specifically hardcode the fact that ULA addresses should not be used and do not provide the ability for users to modify that default (partial) behavior. In a previous answer, I had some scenarios in which ULA as CoA or HoA would be useful. I also had a note about RFC 3484 logic as a basis for selection. At the moment, I am still under the impression that ULA are moved aside more by fear than anything else: if you are on a link inside your site (or say a satellite office) and you only have an ULA prefix advertised, what's the problem in giving it a try? Said differently: an IPv6 node on an ULA-only subnet will try and use it to reach a native or 6to4 peer. Why would a MN not do that to try and reach its HA on a native or 6to4 address? Cheers, a+ From xiayangsong@huawei.com Fri Oct 9 13:27:18 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AAEC3A6950 for ; Fri, 9 Oct 2009 13:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.954 X-Spam-Level: X-Spam-Status: No, score=-0.954 tagged_above=-999 required=5 tests=[AWL=-1.645, BAYES_05=-1.11, J_CHICKENPOX_22=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_32=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGr4eoZoFrRU for ; Fri, 9 Oct 2009 13:27:17 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 125713A65A6 for ; Fri, 9 Oct 2009 13:27:17 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KR9004NJKWDEV@usaga02-in.huawei.com> for mext@ietf.org; Fri, 09 Oct 2009 13:29:02 -0700 (PDT) Received: from X24512z ([10.124.12.62]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KR9005OSKWDDZ@usaga02-in.huawei.com> for mext@ietf.org; Fri, 09 Oct 2009 13:29:01 -0700 (PDT) Date: Fri, 09 Oct 2009 15:29:10 -0500 From: Frank Xia To: Mohana Jeyatharan , Behcet Sarikaya , mext@ietf.org Message-id: <016a01ca491f$28cd7dd0$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5F09D220B62F79418461A978CA0921BD0398AEBF@pslexc01.psl.local> Subject: Re: [MEXT] Scenarios for HA to MN Flow Binding-draft-xia-mext-ha-init-flow-binding X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 20:27:18 -0000 Hi Mohana Thanks for bringing up pramatic scenarios. Please check my inline comments. BR Frank ----- Original Message ----- From: "Mohana Jeyatharan" To: "Behcet Sarikaya" ; Sent: Wednesday, October 07, 2009 7:41 PM Subject: Re: [MEXT] Scenarios for HA to MN Flow Binding-draft-xia-mext-ha-init-flow-binding > Hi Behcet and all, > > From the use cases people have proposed for flow binding work, it is > acceptable that in most cases, the decision about the flow binding rule > is made by the MN. Frank=>I would like to say SOME people. AFAIK, there are also some people favor HA initiating flow binding. You can tell from the verbose discussion. > > But as mentioned in draft-xia-mext-ha-init-flow-binding, the flow > binding rule can originate from HA(be it mandatory or optional). Bcos > in some cases, the network can decide what is best for it. Since there > is a valid trust relation ship between HA and MN, the HA can use flow > binding protocol in a reverse way(as quoted in HA-init ID) to sends its > rules to MN. Frank=>Thank for mentioning our draft! > > In addition to the scenarios you have quoted, I am quoting another > scenario, where the HA can suggest its flow binidng rules and the MN can > use these rules to create its own rules. > **************************************************** > Flow binding rules initiated by HA > and their categories > > [1]Some are Mandatory flow binding rules-case A > [2]Some are flow binding preferences and UE can decide on the suitable > flow binding rule based on some preference given by the network/HA-case > B > [3]Some flow binding rules are mandatory but to be applied when an event > occurs-Case C > > *************************************************** > Case A and Case B scenarios are given together > *************************************************** > HA changing default flow policies into default flow binding > ============================================================ > +-----+ > | HA | > | | > +-----+ > / \ > 3G homelink \ > (PMIP)/ \ > / \ HPLMN > / \ > +-----+ +-------+ > | S-GW| | ePDG | > | | | | > +-----+ +-------+ > \ / > \ / > \ / > +---+ > |MN | > +---+ > The network entity such as HSS through AAA gives default flow policies > to HA (Voice via 3G and data via other). The HA changes default > policies > into default flow binding rules. > The HA has PMIP binding for the home link and knows the binding for home > link and the access type tied to homebinding. > home binding BID1, foreign binding BID2. > > Thus HA initiates default flow binding rule (FID1(voice) BID1. > FID2(data) BID2. > MN generates flow binding rules for uplink and downlink traffic based on > flow binding rules given by HA. HA given rules can be subset of the > final MN flow binding rules. > > In case A, MN needs to follow these rules strictly. > > In case B, if there is no other external factor influencing the flow > binding rules being set by MN(ANDSF, MNs preferences etc) it will follow > the HA given flow binding rule. > Else it will NACK the HA given flow binding rule and give its own flow > binding rule. > ******************************************************************* Frank=>We presented this use case last IETF meeting. Many argued that this is about default policy not binding rule provisioning, and this can be done through higher layer mechnisms other than layer 3 solution. Of course, I dont agree. Flowing binding is an operation above layer 3. The terminologies demarcation in this context is confusing. > Comments? > > Thanks. > > BR, > Mohana > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf > Of >> Behcet Sarikaya >> Sent: Wednesday, September 30, 2009 3:45 AM >> To: mext@ietf.org >> Subject: [MEXT] Scenarios for HA to MN Flow Binding > -draft-xia-mext-ha- >> init-flow-binding >> >> Hello all, >> As presented in IETF 75 >> http://www.ietf.org/proceedings/75/slides/mext-2/mext-2.htm >> >> apart from flow binding revocation, we had >> - inter-interface flow movement and >> - default Flow Binding Provisioning >> scenarios. >> >> Please post any comments on the above or related to the above > scenarios. >> >> Regards, >> >> Behcet >> >> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From charles.perkins@earthlink.net Fri Oct 9 13:55:36 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB61C3A6916 for ; Fri, 9 Oct 2009 13:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.742 X-Spam-Level: X-Spam-Status: No, score=-1.742 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVpO54W2VnQs for ; Fri, 9 Oct 2009 13:55:36 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 36A9528B797 for ; Fri, 9 Oct 2009 13:55:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=e9MKJgQcVtRLsH3gbk5X8GdF9Dh+98j0P944EmLxumLztlcp8LpogaLy32+Sipwl; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.139]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MwMWf-0004q0-2h; Fri, 09 Oct 2009 16:57:21 -0400 Message-ID: <4ACFA3AB.5040600@earthlink.net> Date: Fri, 09 Oct 2009 13:57:15 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Arnaud Ebalard References: <4AAA7BF4.6030705@wichorus.com> <4ACE5196.2040505@earthlink.net> <87ocohhxav.fsf@small.ssi.corp> <4ACF847C.2050805@earthlink.net> <87zl80jpio.fsf@small.ssi.corp> In-Reply-To: <87zl80jpio.fsf@small.ssi.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5283439f5b0eb8ce2b7056ffcc4583a493350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: mext Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 20:55:36 -0000 Hello Arnaud, Arnaud Ebalard wrote: > >>>> Therefore, >>>> unique-local IPv6 unicast addresses SHOULD NOT be used as home or >>>> care-of addresses when other address choices are available. >>>> >>>> > > It would be to bad (IMHO) if MIPv6 module specifically hardcode the fact > that ULA addresses should not be used and do not provide the ability for > users to modify that default (partial) behavior. > > I understand that you may be asking for the following logic: - If ULA is the only address available, it SHOULD be used - If another address is available the ULA SHOULD NOT be used. Is that correct? Regards, Charlie P. From charles.perkins@earthlink.net Fri Oct 9 14:12:20 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E774E3A62C1 for ; Fri, 9 Oct 2009 14:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77cODaWcX4cq for ; Fri, 9 Oct 2009 14:12:19 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 72B9F3A6951 for ; Fri, 9 Oct 2009 14:12:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=g5MV8YFir6LhV+MyZ9KhcdhMBi02H/9lkAEi9ENtU51RPX5/MyZ3V3jV88ZY9TPX; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.139]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MwMmp-0001Eq-Ll; Fri, 09 Oct 2009 17:14:04 -0400 Message-ID: <4ACFA799.3080403@earthlink.net> Date: Fri, 09 Oct 2009 14:14:01 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Arnaud Ebalard References: <87iqfyq4h0.fsf@small.ssi.corp> In-Reply-To: <87iqfyq4h0.fsf@small.ssi.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52a8113b84653db31e25b9ed0ffe6b8af8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "mext@ietf.org" Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 21:12:21 -0000 Hello Arnaud, I have made the changes as we have discussed. Additional comments inline below: Arnaud Ebalard wrote: > >> 5.3. Dynamic Home Agent Address Discovery >> >> No security is required for dynamic home agent address discovery. >> > > May be it is the way I understanded it but this sounds like "no security > is needed". It should sounds like "No security is provided for that > mechanism". > I replaced this sentence by the following: Dynamic home agent address discovery has been designed for use in deployments where security is not needed. For this reason, no security solution is provided in this document for dynamic home agent address discovery. > >> 6.1.7. Binding Update Message >> >> .... >> >> Home Registration (H) >> >> The Home Registration (H) bit is set by the sending mobile node to >> request that the receiving node should act as this node's home >> agent. The destination of the packet carrying this message MUST >> be that of a router sharing the same subnet prefix as the home >> address of the mobile node in the binding. >> > > This prevents the MN to communicates with the HA on another > interface. Is there any reason for that limitation, i.e. not having a > SHOULD here instead of a MUST. Or I should ask, what is the reason to > have a MUST here. > > For instance, the main connectivity of the home agent can be provided by > a given provided (symmetric line) while the MN are on a subnet for which > the prefix is provided by another provider. That way, the download > bandwidth used by the MNs is not shared with the upload bandwidth: > > ISP1 -- home subnet ---[HA]--- ISP2 > I am willing to change the MUST to a SHOULD, since the message is secure and the mobile node ought to be able to decide its fate. But, I would only do so if this seemingly slight change were approved by the working group. I think it goes beyond the kinds of clarifications and improvements I can unilaterally decide to do. > >> >> In a Router Advertisement, a home agent MUST, and all other routers >> MAY, include at least one Prefix Information option with the Router >> Address (R) bit set. Neighbor Discovery specifies that, if including >> all options in a Router Advertisement causes the size of the >> Advertisement to exceed the link MTU, multiple Advertisements can be >> sent, each containing a subset of the options [20]. Also, when >> sending unsolicited multicast Router Advertisements more frequently >> than the limit specified in RFC 4861 [20], the sending router need >> > > s/RFC 4861 [20]/Neighbor Discovery [20]/ > > IMHO, this is easier to read. Note that there are various places in the > document where the replacement should be done. > O.K. In this particular paragraph, the same document was cited twice, but in two different ways stylistically. I think it would be better like this: In a Router Advertisement, a home agent MUST, and all other routers MAY, include at least one Prefix Information option with the Router Address (R) bit set. Neighbor Discovery (RFC 4861 [20]) specifies that, when including all options in a Router Advertisement causes the size of the Advertisement to exceed the link MTU, multiple Advertisements can be sent, each containing a subset of the Neighbor Discovery options. Also, when sending unsolicited multicast Router Advertisements more frequently than the limit specified in RFC 4861, the sending router need not include all options in each of these Advertisements. The citation is made only once in the paragraph, both the protocol name and the RFC number are clearly associated, and a small bit of repetitive verbosity is reduced. I'll try to treat the other instances with the same philosophy. Thanks for pointing them out. > > >> 8.4. IPv6 Home Agents >> ... >> > > No opinion on whether this is a good idea or not, but probably worth > asking: what about also adding a reference to RFC 4389 (experimental > doc)? > I don't think that the simple existence of an experimental document that describes various features of proxy ND agents is a strong argument for inclusion. Did you check whether the RFC 4389 specifications are fully compatible with Mobile IPv6 as currently specified? I think it would be wise to do so before making the citation. If there are cases that are handled better in RFC 4389 (e.g., ICMP messaging, neighbor cache operations), then it would be a good idea to (a) make Mobile IPv6 more correct and then (b) cite RFC 4389. I don't think we can rely on RFC 4389 to identify the correct behavior, however, because then the citation would be normative and that would be trouble for an experimental RFC. That's a long way of saying I am quite leery of making this citation. But I'm interested to hear your further comments, and especially if you have assurance that there are no incompatibilities between RFC 4389 and rfc3775bis. >>>> >>> o The node MAY support stateful address autoconfiguration mechanisms >>>> >>> such as DHCPv6 [32] on the interface represented by the tunnel to >>>> >>> the home agent. >>>> >>> >>>> >>> >> >>> >> How is that supposed to happen/work? Is that to support provisioning of >>> >> *additional* addresses (not HoA) from the Home Network? It is unclear. >>> >> >>> >> > >> > What if (a) the mobile node gets an address from DHCP and then >> > (b) runs IKE with its home agent? >> > > Sorry, I do not understand what you mean. Can you describe more > precisely the steps? The tunnel does not even exist prior to the binding > (which require the HoA) so I don't see how this can work. > > >> > How should the statement be made clearer? >> > > Well, I don't even see how this can work so at the moment, I would > remove that item. > I should have thought more about this before answering the first time. I agree it isn't clear, because I think there are several scenarios. First, we can agree that mobile nodes MAY support DHCPv6, right? The question is how to make it work. And rfc3775bis might not be the right place for that. But here are some (slightly) better considered ideas. - the mobile node might use DHCPv6 for configuration information other than its IPv6 address - the mobile node might use DHCPv6 to extend the lifetime of its existing home address - the mobile node might try to use its existing home address, but get a new address from the DHCPv6 server in reply. - for such a new home address, it might need to use IKEv* to make a new security association - perhaps the old address is still valid for a short time while the new IKEv2 packets are tunneled with the home agent - the mobile node should be able to run DHCPv6 to get care-of addresses to be used on the same network interface as is used to support the tunnel to the home agent. I don't claim that having the abovementioned possibilities makes the bulleted item in question any more clear, but I'm not sure how to make it clearer, and I somehow don't think that section is the right place to lay out all the possibilities for DHCPv6 interactions. So unless someone tells me different, for now I'll just leave it alone. > > > >> attempt to intercept packets on the mobile node's home link that are >> addressed to the mobile node. >> >> In order to do this, when a node begins serving as the home agent it >> MUST multicast onto the home link a Neighbor Advertisement message >> [20] on behalf of the mobile node. >> > > As specified in section 10.3.1: > > Unless this home agent already has a binding for the given home > address, the home agent MUST perform Duplicate Address Detection [21] > on the mobile node's home link before returning the Binding > Acknowledgement. > > So, the last sentence should be modified to indicate that the NA is sent > only after that initial DAD. > > How about: In order to do this, when a node begins serving as the home agent it MUST have performed Duplicate Address Detection (as specified in Section 10.3.1), and subsequently it MUST multicast onto the home link a Neighbor Advertisement message [20] on behalf of the mobile node. >> >> o In addition, for all security associations bound to the mobile >> node's home address established by IKE, the mobile node MUST >> include an ISAKMP Identification Payload [6] in the IKE phase 2 >> exchange, giving the mobile node's home address as the initiator >> of the Security Association [5]. >> >> The Key Management Mobility Capability (K) bit in Binding Updates and >> Acknowledgements can be used to avoid the need to rerun IKE upon >> movements. >> > > Considering the mechanism is implemented and such an interface needed to > support that, 3775bis could at least point MIGRATE doc given below as an > informational reference document. This clarifies the need and gives a > possible solution. > > http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00 > So that I can finish revising rfc3775bis before having to stop and read that draft, can you provide some suggested text for the proposed citation? I'll try to read the draft in the next few days understand your citation and text. > > >> >> o Given the availability of the home prefix, the MN checks whether >> or not the home prefix matches one of the prefixes received in the >> RA. If it does, the MN concludes that it has returned home. >> > > It should be stated here or in the "Security Considerations" section > that this procedure is insecure and may have security impact, as we rely > on basic ND and undergo associated threats. This is documented: > > http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00 > How about: o Given the availability of the home prefix, the MN checks whether or not the home prefix matches one of the prefixes received in the RA. If it does, the MN concludes that it is connected to the home link. Please see Section 15.10 for information regarding the security vulnerability associated with this determination. and, 15.10. Vulnerabilities from Neighbor Discovery The ``Home Link Detection'' mechanism (Section 11.5.2) allows the MN to detect when it is at home. When a MN detects it is at home, it is expected to deregister, and also (if in use) to stop IPsec protection for data traffic exchanged over the tunnel to its Home Agent. Unfortunately, Neighbor Discovery is not a secure protocol. It is possible that some networks may harbor malicious routing agents that might advertise false information which would lead a mobile node to erroneously determine that it had returned to its home network. A draft [40] has been written that discusses the possible threats and security impacts associated with the use of this insecure NDP- based mechanism as a trigger to drop IPsec protection of data traffic for the MN. It also provides some results on the implementation of the attacks against an existing MIPv6 module. Possible solutions are suggested. And, finally: > 17. Acknowledgements > > We would like to thank the members of the Mobile IP and IPng Working > Groups for their comments and suggestions on this work. We would > particularly like to thank (in alphabetical order) ... I wonder if anyone noticed the names had not been in alphabetical order :-) for a really long time. There is still one more issue I am working on before considering this revision to be complete. But I thought it would be better to send this long-ish email out first because it will take me a while to puzzle over that issue. Plus there are all those citations to modify. Regards, Charlie P. From Basavaraj.Patil@nokia.com Fri Oct 9 14:24:53 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BD5D28C0FE for ; Fri, 9 Oct 2009 14:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 jnWqznkhxjEF for ; Fri, 9 Oct 2009 14:24:52 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id C878628C182 for ; Fri, 9 Oct 2009 14:24:51 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n99LQSwW016233; Sat, 10 Oct 2009 00:26:31 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Oct 2009 00:25:56 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Oct 2009 00:25:51 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Oct 2009 00:25:46 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Fri, 9 Oct 2009 23:25:45 +0200 From: To: , Date: Fri, 9 Oct 2009 23:25:57 +0200 Thread-Topic: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis Thread-Index: AcpJJXQbKOxA6rTCTpKSlHVOoX6CMAAAaLFh Message-ID: In-Reply-To: <4ACFA799.3080403@earthlink.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Oct 2009 21:25:46.0941 (UTC) FILETIME=[10E3FED0:01CA4927] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 21:24:53 -0000 A few comments about some of the citations being proposed: On 10/9/09 4:14 PM, "Charles Perkins" wrote= : >> Considering the mechanism is implemented and such an interface needed to >> support that, 3775bis could at least point MIGRATE doc given below as an >> informational reference document. This clarifies the need and gives a >> possible solution. >>=20 >> http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00 >> =20 >=20 > So that I can finish revising rfc3775bis before having to stop and read > that draft, > can you provide some suggested text for the proposed citation? I'll try > to read the > draft in the next few days understand your citation and text. This reference does not add any value to 3775bis. It is more relevant in th= e context of 3776 or 4877. Adding this reference even in the Informative section is not required. >>=20 >> It should be stated here or in the "Security Considerations" section >> that this procedure is insecure and may have security impact, as we rely >> on basic ND and undergo associated threats. This is documented: >>=20 >> http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00 >> =20 >=20 > How about: >=20 > o Given the availability of the home prefix, the MN checks whether > or not the home prefix matches one of the prefixes received in the > RA. If it does, the MN concludes that it is connected to the home > link. Please see Section 15.10 for information regarding the > security vulnerability associated with this determination. >=20 >=20 > and, >=20 > 15.10. Vulnerabilities from Neighbor Discovery >=20 > The ``Home Link Detection'' mechanism (Section 11.5.2) allows the MN > to detect when it is at home. When a MN detects it is at home, it is > expected to deregister, and also (if in use) to stop IPsec protection > for data traffic exchanged over the tunnel to its Home Agent. >=20 > Unfortunately, Neighbor Discovery is not a secure protocol. It is > possible that some networks may harbor malicious routing agents that > might advertise false information which would lead a mobile node to > erroneously determine that it had returned to its home network. >=20 > A draft [40] has been written that discusses the possible threats > and security impacts associated with the use of this insecure NDP- > based mechanism as a trigger to drop IPsec protection of data traffic > for the MN. It also provides some results on the implementation of > the attacks against an existing MIPv6 module. Possible solutions are > suggested. This is a much larger change to 3775bis. I-D: draft-ebalard-mext-hld-security-00 has not really been discussed in the MEX= T WG AFAICT and hence making this change based on this reference is not what = I believe is in the scope of the current revision of 3775bis. If an when the MEXT WG agrees that the threats identified in the referenced I-D are accepted, it is okay to make these changes. -Basavaraj From arno@natisbad.org Fri Oct 9 14:32:16 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D1A728C19C for ; Fri, 9 Oct 2009 14:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 TQU32vBewtE8 for ; Fri, 9 Oct 2009 14:32:15 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 2F06A3A63D3 for ; Fri, 9 Oct 2009 14:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natisbad.org; s=mail; h=From:To:Cc:Subject:References:Date: In-Reply-To:Message-ID:MIME-Version:Content-Type; bh=cj3p/hjD0WX hkWek92DO8bbzP9TVecRyM1KLirl9ACY=; b=p1+z6Y6++y11iMphipXr5DrZIy4 5OZs8zXfQMMzEic9h4VmRO9cpmkvnstkbwYXYJ26e9k2wkhs50lQ5R0kDgdByTNz S5eiAhwZe0ZJk3S4dH86BFxhXn0SxkN7OAQzuWBnsGLgKbHJyPrvOYkLILkR3CR7 JiFJYEassLhXFrAk= Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MwN63-0004cK-Oi; Fri, 09 Oct 2009 23:33:56 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "Charles E. Perkins" References: <4AAA7BF4.6030705@wichorus.com> <4ACE5196.2040505@earthlink.net> <87ocohhxav.fsf@small.ssi.corp> <4ACF847C.2050805@earthlink.net> <87zl80jpio.fsf@small.ssi.corp> <4ACFA3AB.5040600@earthlink.net> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:091009:charles.perkins@earthlink.net::unbZHw3PPBVE+r07:0000000000000000000000000000000010k2 X-Hashcash: 1:20:091009:mext@ietf.org::bUjpkFTIO5E+0tMT:00003gPx Date: Fri, 09 Oct 2009 23:34:20 +0200 In-Reply-To: <4ACFA3AB.5040600@earthlink.net> (Charles E. Perkins's message of "Fri, 09 Oct 2009 13:57:15 -0700") Message-ID: <87vdiojlpf.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 21:32:16 -0000 "Charles E. Perkins" writes: > Arnaud Ebalard wrote: >> >>>>> Therefore, >>>>> unique-local IPv6 unicast addresses SHOULD NOT be used as home or >>>>> care-of addresses when other address choices are available. >>>>> >>>>> >> >> It would be to bad (IMHO) if MIPv6 module specifically hardcode the fact >> that ULA addresses should not be used and do not provide the ability for >> users to modify that default (partial) behavior. >> >> > > I understand that you may be asking for the following logic: > - If ULA is the only address available, it SHOULD be used > - If another address is available the ULA SHOULD NOT be used. > > Is that correct? I think it captures what I had in mind, yes. Last comment: If the HA uses an ULA, the logic may be a bit different in some cases (longest prefix match) but if the MIPv6 module supports that specific case, it will probably implement the right logic I guess. Cheers, a+ From charles.perkins@earthlink.net Fri Oct 9 14:36:21 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15DC83A6951 for ; Fri, 9 Oct 2009 14:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQTchL4VpvRd for ; Fri, 9 Oct 2009 14:36:20 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 12A773A6804 for ; Fri, 9 Oct 2009 14:36:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Mx2KNLAfuh43KjU641DXdoI13oB1VsKGt5A1A0uVwzlyKn91aIeGEaoioseLxa8o; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.139]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MwNA0-0003mE-3z; Fri, 09 Oct 2009 17:38:00 -0400 Message-ID: <4ACFAD37.1060802@earthlink.net> Date: Fri, 09 Oct 2009 14:37:59 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com, Arnaud Ebalard References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5253ac2c287da379489fd308645891d4c6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: mext@ietf.org Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 21:36:21 -0000 Hello folks, O.K. I will hold off on submitting the document until this situation is cleared up. It is easy for me to omit these new citations and accompanying text (a lot easier than writing them in the first place). Anyway I will put the completed revision on a website for review before submitting it to the Secretariat. Regards, Charlie P. Basavaraj.Patil@nokia.com wrote: > A few comments about some of the citations being proposed: > > > On 10/9/09 4:14 PM, "Charles Perkins" wrote: > > >>> Considering the mechanism is implemented and such an interface needed to >>> support that, 3775bis could at least point MIGRATE doc given below as an >>> informational reference document. This clarifies the need and gives a >>> possible solution. >>> >>> http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00 >>> >>> >> So that I can finish revising rfc3775bis before having to stop and read >> that draft, >> can you provide some suggested text for the proposed citation? I'll try >> to read the >> draft in the next few days understand your citation and text. >> > > This reference does not add any value to 3775bis. It is more relevant in the > context of 3776 or 4877. Adding this reference even in the Informative > section is not required. > > >>> It should be stated here or in the "Security Considerations" section >>> that this procedure is insecure and may have security impact, as we rely >>> on basic ND and undergo associated threats. This is documented: >>> >>> http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00 >>> >>> >> How about: >> >> o Given the availability of the home prefix, the MN checks whether >> or not the home prefix matches one of the prefixes received in the >> RA. If it does, the MN concludes that it is connected to the home >> link. Please see Section 15.10 for information regarding the >> security vulnerability associated with this determination. >> >> >> and, >> >> 15.10. Vulnerabilities from Neighbor Discovery >> >> The ``Home Link Detection'' mechanism (Section 11.5.2) allows the MN >> to detect when it is at home. When a MN detects it is at home, it is >> expected to deregister, and also (if in use) to stop IPsec protection >> for data traffic exchanged over the tunnel to its Home Agent. >> >> Unfortunately, Neighbor Discovery is not a secure protocol. It is >> possible that some networks may harbor malicious routing agents that >> might advertise false information which would lead a mobile node to >> erroneously determine that it had returned to its home network. >> >> A draft [40] has been written that discusses the possible threats >> and security impacts associated with the use of this insecure NDP- >> based mechanism as a trigger to drop IPsec protection of data traffic >> for the MN. It also provides some results on the implementation of >> the attacks against an existing MIPv6 module. Possible solutions are >> suggested. >> > > This is a much larger change to 3775bis. I-D: > draft-ebalard-mext-hld-security-00 has not really been discussed in the MEXT > WG AFAICT and hence making this change based on this reference is not what I > believe is in the scope of the current revision of 3775bis. > If an when the MEXT WG agrees that the threats identified in the referenced > I-D are accepted, it is okay to make these changes. > > -Basavaraj > > > > From arno@natisbad.org Fri Oct 9 15:24:29 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 626683A6994 for ; Fri, 9 Oct 2009 15:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 aFnKoW8Alp2L for ; Fri, 9 Oct 2009 15:24:28 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id F16993A6964 for ; Fri, 9 Oct 2009 15:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natisbad.org; s=mail; h=From:To:Cc:Subject:References:Date: In-Reply-To:Message-ID:MIME-Version:Content-Type; bh=M9nK43NVPt2 FYJ9tvUGIMwHtBHj9sCuWfW8qr+EiWW4=; b=UJJ8zbBMDn5XBKx5QWpnP5ThcHi ZoI1s15WqRxCNoW4IpU8jO2ahMbh/IFPJBy5Ifd+efanlNyA/VeSFkZe0y5/go2q gVGa717gVMPjvaC8cQXRyHL/p2ISsp4v2IljL06IR1F8OMbNuFv0heyjzN9reRnl 3Zm1POt27pzL4s5k= Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MwNua-00055S-H1; Sat, 10 Oct 2009 00:26:08 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: 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:091009:basavaraj.patil@nokia.com::hIvKtHGqwUPEVXPg:0000000000000000000000000000000000002aNa X-Hashcash: 1:20:091009:mext@ietf.org::wcIdxPUD5ifgLThT:00004tyl X-Hashcash: 1:20:091009:charles.perkins@earthlink.net::sb9cLr1y/er2Uv4I:000000000000000000000000000000008CIu Date: Sat, 10 Oct 2009 00:26:33 +0200 In-Reply-To: (Basavaraj Patil's message of "Fri, 9 Oct 2009 23:25:57 +0200") Message-ID: <87ljjki4py.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext@ietf.org Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 22:24:29 -0000 Hi, writes: > A few comments about some of the citations being proposed: > > > On 10/9/09 4:14 PM, "Charles Perkins" wrote: > >>> Considering the mechanism is implemented and such an interface needed to >>> support that, 3775bis could at least point MIGRATE doc given below as an >>> informational reference document. This clarifies the need and gives a >>> possible solution. >>> >>> http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00 >>> >> >> So that I can finish revising rfc3775bis before having to stop and read >> that draft, >> can you provide some suggested text for the proposed citation? I'll try >> to read the >> draft in the next few days understand your citation and text. > > This reference does not add any value to 3775bis. I'll take that with salt ;-) > It is more relevant in the context of 3776 or 4877. Adding this > reference even in the Informative section is not required. I think rfc3775bis is about correcting issues and clarifying parts of 3775 based on existing feedback. IMHO, this is exactly what this informational reference provides. Even if you are against the use of IPsec/IKE with MIPv6, this is the security mechanism used by the protocol. And providing informational pointers in the spec to possible solutions to support - correct use of IKE with MIPv6 - efficient use of IPsec for protection of tunneled data is useful. It's not fair to keep saying that MIPv6 does not work with IPsec/IKE and in the meantime prevent efforts to clarify the interactions between the protocols to be added to the specs. That been said, I think I have argued enough on that aspect. I'll let Charles capture the thoughts of the working group and decide what to do. >>> It should be stated here or in the "Security Considerations" section >>> that this procedure is insecure and may have security impact, as we rely >>> on basic ND and undergo associated threats. This is documented: >>> >>> http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00 >>> >> >> How about: >> >> o Given the availability of the home prefix, the MN checks whether >> or not the home prefix matches one of the prefixes received in the >> RA. If it does, the MN concludes that it is connected to the home >> link. Please see Section 15.10 for information regarding the >> security vulnerability associated with this determination. >> >> >> and, >> >> 15.10. Vulnerabilities from Neighbor Discovery >> >> The ``Home Link Detection'' mechanism (Section 11.5.2) allows the MN >> to detect when it is at home. When a MN detects it is at home, it is >> expected to deregister, and also (if in use) to stop IPsec protection >> for data traffic exchanged over the tunnel to its Home Agent. >> >> Unfortunately, Neighbor Discovery is not a secure protocol. It is >> possible that some networks may harbor malicious routing agents that >> might advertise false information which would lead a mobile node to >> erroneously determine that it had returned to its home network. >> >> A draft [40] has been written that discusses the possible threats >> and security impacts associated with the use of this insecure NDP- >> based mechanism as a trigger to drop IPsec protection of data traffic >> for the MN. It also provides some results on the implementation of >> the attacks against an existing MIPv6 module. Possible solutions are >> suggested. > > This is a much larger change to 3775bis. I-D: > draft-ebalard-mext-hld-security-00 has not really been discussed in the MEXT > WG AFAICT True. I think I only got a comment from Julien. > and hence making this change based on this reference is not what I > believe is in the scope of the current revision of 3775bis. > If an when the MEXT WG agrees that the threats identified in the referenced > I-D are accepted, it is okay to make these changes. Fine with me. Cheers, a+ From Basavaraj.Patil@nokia.com Fri Oct 9 15:35:07 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27313A69AB for ; Fri, 9 Oct 2009 15:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 jTGHSd+xJnC6 for ; Fri, 9 Oct 2009 15:35:06 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 560183A6887 for ; Fri, 9 Oct 2009 15:35:05 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n99Makag013324; Sat, 10 Oct 2009 01:36:47 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Oct 2009 01:36:46 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Oct 2009 01:36:41 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Sat, 10 Oct 2009 00:36:40 +0200 From: To: , Date: Sat, 10 Oct 2009 00:36:51 +0200 Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpG3PrETCpXfQpNQraj6B7QmoF8mwCVAOxq Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Oct 2009 22:36:41.0580 (UTC) FILETIME=[F8DA62C0:01CA4930] X-Nokia-AV: Clean Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 22:35:07 -0000 Hello, The document needs at least another revision before it would be ready to be sent to the IESG. Below is a review of the Flow bindings I-D : - Update reference DSMIPv6 [I-D.ietf-mext-nemo-v4traversal] to RFC5555 - Update reference [I-D.ietf-monami6-multiplecoa] to RFC5648 > In this document, a flow is defined as a set of IP packets matching a > flow descriptor. The definition in the terminology section is better suited to describe a flow. A flow can be identified by a flow descriptor but that is not the definition of what a flow is. > This specification, however, does not define flow > descriptors and it is assumed that one or more ways of defining flow > descriptors are going to be defined in other specifications. The specification now exists and hence should be referenced, i.e I-D: draft-ietf-mext-binary-ts > Flow Identifier: An unsigned integer. This definition really does not explain what a Flow ID is. Suggested text: "A flow identifier uniquely identifies a flow associated with an MN. It is generated by the MN and is cached in the flow binding list maintained by the MN, HA, CN or MAP." > BID-PRI > > This is a 7-bit unsigned integer placing each BID to a relative > priority with other registered BIDs. Value "0" is reserved. A > lower number in this field indicates higher priority, while > BIDs with the same BID-PRI value have equal priority. This is > consistent with current practice in packet classifiers. I dont see the value in having a priority associated with the BID. This I-D proposes the creation of an ordered BID list. The reason for having an ordered list is to process the packet with the BID which has the highest priority in case there is no match for any Flow ID. This is not required. The HA can decide to forward it to any CoA based on some default binding cache entry or policy that it has. I would suggest not modifying the Binding Identifier mobility option as specified in RFC5648. > FID-PRI > > This is an unsigned 8-bit priority field to indicate the > priority of a particular option. This field is needed in cases > where two different flow descriptions in two different options > overlap. The priority field decides which policy should be in > those cases. A lower number in this field indicates a higher > priority. I guess multiple FIDs can have the same priority, right? Is there a default value in case no priority is assigned by the MN? Or because you are creating an ordered list of FIDs, the priority for each FID is unique? Also it would be good to reserve priority 0 for future use. Some additional text to clarify this might be useful. > Action > > This field specifies the action that needs to be taken by the > receiver of the binding update containing the flow > identification option. The details of these requests are > discussed below. - s/This field specifies/This 8 bit unsigned integer field specifies - Can you include the values defined for the actions further below in the section immediately below the Action field definition? Makes reading easier. - a/Action value 0 is reserved. - In the example of Flow binding entries shown in Sec 4.4, the action field also includes Forward (in addition to discard and n-cast). Does this imply that not indicating anything in the Action field equates to Forwarding? Or should there be a separate value reserved for forwarding as well? Why not be explicit and just assign a value for forwarding as well. > Rsvd > Status Specify these are 8 bit unsigned integer fields just to be explicit. > A number of sub-options can follow the option defined in this > section. Rephrase as : A number of sub-options can follow the Flow Identification mobility option defined in this section. >4.2.1. Binding Reference Sub-option > This section introduces the Binding Reference sub-option, which may > be included in the Flow identification option. Is it really a MAY? If the MN is adding a new flow ID, the binding reference sub-option is mandatory especially if the action is set to Forward. From the processing rules defined in Sec 5.3.2.1 it seems that the binding reference sub-option MUST be included and SHOULD have a valid BID. Adding a flow ID that does not have a valid matching BID in the BC does not make much sense. s/which may be included in the Flow identification option./which MUST be included in the Flow identification mobility option. >4.2.2. Flow Description Sub-option > Sub-opt Type > > Indicates the Sub-option type. For the flow description sub- > option, this field SHOULD be set to one of the FD types defined > below. - Move the text defining the suboptions to follow the definition of the suboption. - s/Indicates the/8 bit unsigned integer which indicates the - What is really implied by: "17-32 reserved for Flow Description formats"? Do these values have any predefined flow descriptions? Or does it imply that these values cannot be used by the MN? > Flow Description > > The flow description corresponding to the type indicated by the > Sub-opt Type field. Flow description is out of scope of this > document. In I-D: draft-ietf-mext-binary-ts-00 Sec 3 says " [I-D.ietf-mext-flow-binding] defines the format for the traffic selector sub-option." There is no traffic selector sub-option defined in the flow-binding ID. The closest match I guess is the flow description field in the flow-description sub-option. Revise the flow description text and also check to see if the format of the traffic selector options fit into the flow description field. >4.3. Flow Identification Summary Mobility Option Is this option really required? The only reason I can gather from the I-D is that every BU MUST include a list of all the FIDs that have been added otheriwse they will be deleted. And hence the summary option is an optimized way of sending a list of all the FIDs. > The Flow Identification Summary Mobility option includes one or more > flow identifiers (FIDs) for the purpose of refresing their state Why do you need to refresh the state of the FIDs? They do not have a lifetime. If a BU sent to the HA for example were to deprecate a BID (interface/CoA no longer being available), the BU could also include the FID options to modify the FIDs which use that BID. If an MN is simply sending a BU to refresh its lifetime associated with one or more CoAs, there is no reason to include the FID summary mobility option. > The binding cache was then > extended by [I-D.ietf-monami6-multiplecoa] to include more than one > care-of addresses and to associate each of them with a Binding > Identifier (BID). s/The binding cache was then/The binding cache has been Also reference the MCoA RFC instead. > * Active/Inactive flag: This flag indicates whether the entry is > active or inactive. What does it mean when the entry is set as Inactive? Does it imply that the BID is invalid? In the example shown in this section what does the 3rd entry which is inactive imply? The MN does not specify in the FID option sent in the BU whether a flow binding is active or inactive. So how is this flag set and under what conditions? > If all of the > BIDs pointed to by a given entry are not valid BIDs in the binding > cache, the flow binding entry becomes "inactive", in other words it > does not affect data traffic. If a BID is not valid, then the entry in the flow binding list should be deprecated. Why would you have an entry in the flow binding list when there is no valid BID in the BC? Invalid BIDs should be treated as an error case. In the protocol operations section the ID says that the HA will reject the addition of a FID if the BID specified in it is invalid. > The third entry is marked as Inactive since the BID 4 does not exist > in the ordered list of BID entries below. Inactive entries do not > affect traffic, i.e., packets are not matched against them. See above reasoning. No reason to have such an entry. Should be viewed as an error case. > Ordered BID Entries As stated earlier as well, there is really no need to order the BIDs. Assigning a priority to the BIDs by modifying the BID Mbility option is not required. Flow mobility works without assigning priorities to BIDs. > Finally any remaining packets that do not match any of the entries > above will be simply forwarded to the care-of address indicated by > the highest order BID in the table below. For the case where there is no matching FID, the HA/CN/MAP can handle it based on policy or forward to a default CoA. > As indicated earlier the > flow description itself is defined in another document. Reference draft-ietf-mext-binary-ts >5.1.1. Preferred Care-of address > > Any node that supports this specification MUST maintain an ordered > list of care-of addresses for each mobile node it maintains a list of > flow bindings for. The ordered list of care-of addresses is built > based on the BID-PRI field of the Binding Identifier option (see > Section 4.1). > > The ordered list of BIDs is used to determine how to forward a packet > to a given mobile node when the packet does not match any of the flow > binding entries defined in Section 4.4. A packet that does not match > any of the flow binding entries SHOULD be forwarded to the care-of > address identified by the BID with the highest priority i.e., lowest > BID-PRI value. See reasons above why BID-PRI is not needed and how packets which do not match any FIDs can be handled in a more simpler/implementation specific manner. > In other words, two flow > identification options in the same message can not be about the same > flow binding. s/can not be/MUST not be > All flow binding state MUST be refreshed in every binding update the > mobile node sends. Any previously registered flow binding that is > not included in a given binding update will be deleted. So, any flow > bindings that are not added or modified by a flow identification > option, but have previously registered and need to be maintained MUST > be included in a flow summary option. Only one flow summary option > can be included in a given binding update. This is suboptimal. Why do you need to include the FID options in every BU. The MN may be sending a BU to refresh the lifetime of a CoA or adding a new CoA etc. Requiring that FID options be carried in every BU even when the FID option does not have any implication is simply an overhead. Additionally there is no reason to keep refreshing FIDs. > When the mobile node sends a binding update it MUST refresh all flow > bindings it wants to maintain even if it does not want to change any > of their parameters. Why? >5.2.4. Removing flow bindings > > Removal of flow binging entries is performed implicitly by omission > of a given FID from a binding update. It would be better to have an explicit flag in the Flow ID mobility option whether the operation is an add/modify/delete rather than this implicit mechanism. Also you would avoid having to send the flow summary option as a means to deprecate FIDs. > When all the BIDs associated with a flow binding are removed, the > flow binding MUST be marked as inactive in the list of flow binding > entries as shown in Section 4.4. If all BIDs are removed and the rule is other than discard, the flow binding itself should be deprecated. Why keep such a flow binding? > If the FID field of the flow identification option is already present > in the list of flow binding entries for this mobile node, the home > agent MUST reject this flow binding add request by copying the flow > identification option in the BA, and setting the Status field to 135 > (FID already in use). Why? It could be a modify operation for an existing FID? How do you specify whether an operation is add or modify? An HA which receives a BU with a FID which already exists for that MN is simply viewed as a modify operation, right? > A de-registration binding > update (with a zero lifetime) would result in deleting all bindings > regardless of the presence of the Flow summary option. It would be useful to include a section which explains what happens when the MN returns to its home link and deregisters. > If the value of the FID field is present in the mobile nodes list of > slow binding entries the, home agent SHOULD refresh the binding entry > identified by the FID without changing any of the other parameters > associated with it. slow binding entries? ;) > If, however, the action > indicated in an entry of the list of flow bindings is "n-cast", the > entry must indicated a BID. s/the entry must indicated a BID/the entry must indicate more than one valid BID. > If none of the > BIDs pointed to in a flow binding entry is valid then the entry is > considered to be inactive (as defined in Section 4.4) and is skipped. > In other words packets should not be matched against that entry. Should that Flow binding be deprecated? -Raj On 10/6/09 6:30 PM, "ext Laganier, Julien" wrote: > Folks, > > Hereby we're starting a two weeks WGLC on our "Flow Bindings in Mobile IP= v6 > and NEMO Basic Support" document, available at the following URL: > > > > Please review the specification, post your comments to the mailing list, = and > state whether or not you think the document is ready to be forwarded to I= ESG > before 2009-10-20 6:00PM PST. > > Thank you for your support. > > --julien & marcelo, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From arno@natisbad.org Fri Oct 9 15:39:49 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFA323A69AF for ; Fri, 9 Oct 2009 15:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 kQuXLMA1nQb8 for ; Fri, 9 Oct 2009 15:39:48 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 8525E3A6949 for ; Fri, 9 Oct 2009 15:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natisbad.org; s=mail; h=From:To:Cc:Subject:References:Date: Message-ID:MIME-Version:Content-Type; bh=N54jYIW06Mn958yoK7kdlO+ bXNIufLVD2snrhURrCEI=; b=ZN6UexU0aSwwW5o9sV3m+3XjQTj6XLmKi927rD3 OtrYx0wNkqc0a/NBoG0mB0OxdbXSe6V98oB7+QVt6R+UChkA93974YoZs9FNCVBS pV6R457HAeEMxT+YFA/Zh7XDZBImIxuTL+q6rQSXWcSLEBKavwxluaECqcCVTbQ5 r/BA= Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MwO9Q-00059h-SN; Sat, 10 Oct 2009 00:41:29 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "Charles E. Perkins" References: <87iqfyq4h0.fsf@small.ssi.corp> <4ACFA799.3080403@earthlink.net> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:091009:mext@ietf.org::fW+Mf5Ub9fbdV1DF:000033oi X-Hashcash: 1:20:091009:charles.perkins@earthlink.net::1WXD/No89gm6cAJO:0000000000000000000000000000000042b9 Date: Sat, 10 Oct 2009 00:41:53 +0200 Message-ID: <87eipci40e.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "mext@ietf.org" Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 22:39:50 -0000 Hi Charles, "Charles E. Perkins" writes: > I replaced this sentence by the following: > > Dynamic home agent address discovery has been designed for use in > deployments where security is not needed. For this reason, no > security solution is provided in this document for dynamic home agent > address discovery. fine with me. >>> 6.1.7. Binding Update Message >>> >>> .... >>> >>> Home Registration (H) >>> >>> The Home Registration (H) bit is set by the sending mobile node to >>> request that the receiving node should act as this node's home >>> agent. The destination of the packet carrying this message MUST >>> be that of a router sharing the same subnet prefix as the home >>> address of the mobile node in the binding. >>> >> >> This prevents the MN to communicates with the HA on another >> interface. Is there any reason for that limitation, i.e. not having a >> SHOULD here instead of a MUST. Or I should ask, what is the reason to >> have a MUST here. >> >> For instance, the main connectivity of the home agent can be provided by >> a given provided (symmetric line) while the MN are on a subnet for which >> the prefix is provided by another provider. That way, the download >> bandwidth used by the MNs is not shared with the upload bandwidth: >> >> ISP1 -- home subnet ---[HA]--- ISP2 >> > > I am willing to change the MUST to a SHOULD, since the message is > secure and the mobile node ought to be able to decide its fate. But, > I would only do so if this seemingly slight change were approved by > the working group. I think it goes beyond the kinds of clarifications and > improvements I can unilaterally decide to do. I agree with you. I would understand if this is kept as is for that reason. >>> In a Router Advertisement, a home agent MUST, and all other routers >>> MAY, include at least one Prefix Information option with the Router >>> Address (R) bit set. Neighbor Discovery specifies that, if including >>> all options in a Router Advertisement causes the size of the >>> Advertisement to exceed the link MTU, multiple Advertisements can be >>> sent, each containing a subset of the options [20]. Also, when >>> sending unsolicited multicast Router Advertisements more frequently >>> than the limit specified in RFC 4861 [20], the sending router need >>> >> >> s/RFC 4861 [20]/Neighbor Discovery [20]/ >> >> IMHO, this is easier to read. Note that there are various places in the >> document where the replacement should be done. >> > > O.K. In this particular paragraph, the same document was cited twice, but > in two different ways stylistically. I think it would be better like this: > > In a Router Advertisement, a home agent MUST, and all other routers > MAY, include at least one Prefix Information option with the Router > Address (R) bit set. Neighbor Discovery (RFC 4861 [20]) specifies > that, when including all options in a Router Advertisement causes the > size of the Advertisement to exceed the link MTU, multiple > Advertisements can be sent, each containing a subset of the Neighbor > Discovery options. Also, when sending unsolicited multicast Router > Advertisements more frequently than the limit specified in RFC 4861, > the sending router need not include all options in each of these > Advertisements. > > > The citation is made only once in the paragraph, both the protocol name and > the RFC number are clearly associated, and a small bit of repetitive > verbosity is reduced. looks ok. > I'll try to treat the other instances with the same philosophy. Thanks > for pointing them out. Thanks >>> 8.4. IPv6 Home Agents >>> ... >>> >> >> No opinion on whether this is a good idea or not, but probably worth >> asking: what about also adding a reference to RFC 4389 (experimental >> doc)? > > I don't think that the simple existence of an experimental document that > describes various features of proxy ND agents is a strong argument for > inclusion. Did you check whether the RFC 4389 specifications are fully > compatible with Mobile IPv6 as currently specified? I think it would be > wise to do so before making the citation. If there are cases that are > handled better in RFC 4389 (e.g., ICMP messaging, neighbor cache > operations), then it would be a good idea to (a) make Mobile IPv6 > more correct and then (b) cite RFC 4389. I don't think we can rely > on RFC 4389 to identify the correct behavior, however, because then > the citation would be normative and that would be trouble for an > experimental RFC. > > That's a long way of saying I am quite leery of making this citation. > But I'm interested to hear your further comments, and especially if > you have assurance that there are no incompatibilities between > RFC 4389 and rfc3775bis. ok. Let's just drop that comment then. I don't think this is worth losing our time on that. >>>>> >>> o The node MAY support stateful address autoconfiguration mechanisms >>>>> >>> such as DHCPv6 [32] on the interface represented by the tunnel to >>>>> >>> the home agent. >>>>> >>> >>>> >> >>>> >> How is that supposed to happen/work? Is that to support provisioning of >>>> >> *additional* addresses (not HoA) from the Home Network? It is unclear. >>>> >> >>> > >>> > What if (a) the mobile node gets an address from DHCP and then >>> > (b) runs IKE with its home agent? >>> >> >> Sorry, I do not understand what you mean. Can you describe more >> precisely the steps? The tunnel does not even exist prior to the binding >> (which require the HoA) so I don't see how this can work. >> >> >>> > How should the statement be made clearer? >> >> Well, I don't even see how this can work so at the moment, I would >> remove that item. >> > > I should have thought more about this before answering the first time. > > I agree it isn't clear, because I think there are several scenarios. > > First, we can agree that mobile nodes MAY support DHCPv6, right? yes, it might. > The question is how to make it work. And rfc3775bis might not be the > right place for that. I agree. There are some thoughts on the topic in 10.4.4 but I don't think this would help a lot. > But here are some (slightly) better considered ideas. > > - the mobile node might use DHCPv6 for configuration information > other than its IPv6 address > - the mobile node might use DHCPv6 to extend the lifetime of its > existing home address > - the mobile node might try to use its existing home address, but > get a new address from the DHCPv6 server in reply. > - for such a new home address, it might need to use IKEv* to > make a new security association > - perhaps the old address is still valid for a short time while the > new IKEv2 packets are tunneled with the home agent > - the mobile node should be able to run DHCPv6 to get care-of > addresses to be used on the same network interface as > is used to support the tunnel to the home agent. > > I don't claim that having the abovementioned possibilities makes > the bulleted item in question any more clear, but I'm not sure > how to make it clearer, and I somehow don't think that section > is the right place to lay out all the possibilities for DHCPv6 > interactions. > > So unless someone tells me different, for now I'll just leave > it alone. ok. >>> attempt to intercept packets on the mobile node's home link that are >>> addressed to the mobile node. >>> >>> In order to do this, when a node begins serving as the home agent it >>> MUST multicast onto the home link a Neighbor Advertisement message >>> [20] on behalf of the mobile node. >>> >> >> As specified in section 10.3.1: >> >> Unless this home agent already has a binding for the given home >> address, the home agent MUST perform Duplicate Address Detection [21] >> on the mobile node's home link before returning the Binding >> Acknowledgement. >> >> So, the last sentence should be modified to indicate that the NA is sent >> only after that initial DAD. >> >> > > How about: > > In order to do this, when a node begins serving as the home agent it > MUST have performed Duplicate Address Detection (as specified in > Section 10.3.1), and subsequently it MUST multicast onto the home > link a Neighbor Advertisement message [20] on behalf of the mobile > node. > > >>> >>> o In addition, for all security associations bound to the mobile >>> node's home address established by IKE, the mobile node MUST >>> include an ISAKMP Identification Payload [6] in the IKE phase 2 >>> exchange, giving the mobile node's home address as the initiator >>> of the Security Association [5]. >>> >>> The Key Management Mobility Capability (K) bit in Binding Updates and >>> Acknowledgements can be used to avoid the need to rerun IKE upon >>> movements. >>> >> >> Considering the mechanism is implemented and such an interface needed to >> support that, 3775bis could at least point MIGRATE doc given below as an >> informational reference document. This clarifies the need and gives a >> possible solution. >> >> http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00 >> > > So that I can finish revising rfc3775bis before having to stop and > read that draft, > can you provide some suggested text for the proposed citation? I'll > try to read the > draft in the next few days understand your citation and text. Considering Basavaraj's comments and unless other people in the WG supports the inclusion, this introduction to the content of the draft is more for you to understand what it discusses if you decide to read it: MIPv6 requires the use of IPsec for protection of signaling traffic. Static keying must be supported. Dynamic keying (using IKE) is optional. Traffic tunneled between the MN and its HA may optionnally be IPsec protected. When a handovers occurs, the CoA changes. For IKE this basically implies that the IKE_SA (Phase 1 for IKEv1) is no more usable. Additionally, when tunnel mode is used, the states maintained by the IKE daemon (mirrored SP and SA endpoints information) are wrong (they reference the wrong address). The endpoint of the tunnel mode SA present in the IPsec stack are also wrong for the same reason after the handover. The draft provides *a* solution to support the update of previous elements, and prevent the need to drop and rekey everything (and/or force the user to manually update its SP/SA). Implementations of the mechanism are publicly available (Linux Kernel, racoon IKEv1 daemon, StrongSwan IKEv2 daemon and UMIP MIPv6 daemon). >>> o Given the availability of the home prefix, the MN checks whether >>> or not the home prefix matches one of the prefixes received in the >>> RA. If it does, the MN concludes that it has returned home. >>> >> >> It should be stated here or in the "Security Considerations" section >> that this procedure is insecure and may have security impact, as we rely >> on basic ND and undergo associated threats. This is documented: >> >> http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00 >> > > How about: > > o Given the availability of the home prefix, the MN checks whether > or not the home prefix matches one of the prefixes received in the > RA. If it does, the MN concludes that it is connected to the home > link. Please see Section 15.10 for information regarding the > security vulnerability associated with this determination. > > > and, > > 15.10. Vulnerabilities from Neighbor Discovery > > The ``Home Link Detection'' mechanism (Section 11.5.2) allows the MN > to detect when it is at home. When a MN detects it is at home, it is > expected to deregister, and also (if in use) to stop IPsec protection > for data traffic exchanged over the tunnel to its Home Agent. > > Unfortunately, Neighbor Discovery is not a secure protocol. It is > possible that some networks may harbor malicious routing agents that > might advertise false information which would lead a mobile node to > erroneously determine that it had returned to its home network. > > A draft [40] has been written that discusses the possible threats > and security impacts associated with the use of this insecure NDP- > based mechanism as a trigger to drop IPsec protection of data traffic > for the MN. It also provides some results on the implementation of > the attacks against an existing MIPv6 module. Possible solutions are > suggested. Works for me. But let's let the WG decide if this fits. > And, finally: > >> 17. Acknowledgements >> >> We would like to thank the members of the Mobile IP and IPng Working >> Groups for their comments and suggestions on this work. We would >> particularly like to thank (in alphabetical order) ... > > I wonder if anyone noticed the names had not been in alphabetical > order :-) for a really long time. > > There is still one more issue I am working on before considering this > revision to be complete. > But I thought it would be better to send this long-ish email out first > because it will take me a > while to puzzle over that issue. Plus there are all those citations > to modify. Thanks for your work, Cheers, a+ From charles.perkins@earthlink.net Fri Oct 9 15:46:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 812243A69AF for ; Fri, 9 Oct 2009 15:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrfkivb-3uhd for ; Fri, 9 Oct 2009 15:46:12 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id D277F3A68AC for ; Fri, 9 Oct 2009 15:46:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=j8Qgskdy8/7n0z8NVryNPRHHUXqpOLa1RmV/vrU4sZONXxqOCuajLJ2gF3/gjPru; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.139]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MwOFe-0006ho-5l; Fri, 09 Oct 2009 18:47:54 -0400 Message-ID: <4ACFBD99.5040302@earthlink.net> Date: Fri, 09 Oct 2009 15:47:53 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Arnaud Ebalard References: <87ljjki4py.fsf@small.ssi.corp> In-Reply-To: <87ljjki4py.fsf@small.ssi.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52f53ebbea381e2ec774f3f109d5848ee9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: mext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 22:46:13 -0000 Arnaud Ebalard wrote: > >> It is more relevant in the context of 3776 or 4877. Adding this >> reference even in the Informative section is not required. >> > > .... > Even if you are against the use of IPsec/IKE with MIPv6, this is the > security mechanism used by the protocol. And providing informational > pointers in the spec to possible solutions to support > > - correct use of IKE with MIPv6 > - efficient use of IPsec for protection of tunneled data > > is useful. It's not fair to keep saying that MIPv6 does not work with > IPsec/IKE and in the meantime prevent efforts to clarify the > interactions between the protocols to be added to the specs. > > That been said, I think I have argued enough on that aspect. I'll let > Charles capture the thoughts of the working group and decide what to do. > > > Well, if I have to -- but more better would be to have the working group establish the resolution with consensus gauged by the WG chairs. I'm in the mode of avoiding controversy on these points :-) Regards, Charlie P. From Basavaraj.Patil@nokia.com Fri Oct 9 15:49:56 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A913928C17E for ; Fri, 9 Oct 2009 15:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 Z5iXy9ag7sI1 for ; Fri, 9 Oct 2009 15:49:55 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 0DFAF3A69A5 for ; Fri, 9 Oct 2009 15:49:54 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n99MmOF4021204; Sat, 10 Oct 2009 01:48:25 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Oct 2009 01:48:20 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Oct 2009 01:48:15 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Sat, 10 Oct 2009 00:48:14 +0200 From: To: Date: Sat, 10 Oct 2009 00:48:26 +0200 Thread-Topic: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis Thread-Index: AcpJL4R6XC7A2Pp6QXmZgbSocfpG2AAAxg8n Message-ID: In-Reply-To: <87ljjki4py.fsf@small.ssi.corp> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Oct 2009 22:48:15.0309 (UTC) FILETIME=[965907D0:01CA4932] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 22:49:56 -0000 Inline: On 10/9/09 5:26 PM, "ext Arnaud Ebalard" wrote: > Hi, >=20 > writes: >=20 >> A few comments about some of the citations being proposed: >>=20 >>=20 >> On 10/9/09 4:14 PM, "Charles Perkins" wr= ote: >>=20 >>>> Considering the mechanism is implemented and such an interface needed = to >>>> support that, 3775bis could at least point MIGRATE doc given below as = an >>>> informational reference document. This clarifies the need and gives a >>>> possible solution. >>>>=20 >>>> http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-= 00 >>>>=20 >>>=20 >>> So that I can finish revising rfc3775bis before having to stop and read >>> that draft, >>> can you provide some suggested text for the proposed citation? I'll tr= y >>> to read the >>> draft in the next few days understand your citation and text. >>=20 >> This reference does not add any value to 3775bis. >=20 > I'll take that with salt ;-) Only if you disagree about my comment. 3775 does not discuss the security details and hence mentioning Pfkey interface here has no value. >=20 >> It is more relevant in the context of 3776 or 4877. Adding this >> reference even in the Informative section is not required. >=20 > I think rfc3775bis is about correcting issues and clarifying parts of > 3775 based on existing feedback. IMHO, this is exactly what this > informational reference provides. Agree about what the intent of 377bis is. However the reference that you ar= e suggesting should be a part of the IPsec/IKE(v2) RFCs because it makes more sense there. =20 >=20 > Even if you are against the use of IPsec/IKE with MIPv6, this is the > security mechanism used by the protocol. I am not "against" the use of IPsec/IKE with MIP6. I just think that it is an impractical security model for MIP6. > And providing informational > pointers in the spec to possible solutions to support >=20 > - correct use of IKE with MIPv6 > - efficient use of IPsec for protection of tunneled data Right. But not in the context of 3775bis. The aspects of security are specified in other RFCs which would be the relevant place to provide the reference.=20 >=20 > is useful. It's not fair to keep saying that MIPv6 does not work with > IPsec/IKE and in the meantime prevent efforts to clarify the > interactions between the protocols to be added to the specs. FWIW we do have a working implementation of MIP6 with IPsec/IKEv2. So I hav= e never stated that it does not work. I am of the opinion that there are better security approaches that are easier to implement and deploy for MIP6= . IPsec/IKEv2 was the wrong choice for MIP6 security. However just because that is what has been specified does not mean we cannot improve it. It is i= n the WG and IETFs interest to specify a protocol that is actually implementable and used rather than defining something which would challenge implementers without any real benefit. >=20 > That been said, I think I have argued enough on that aspect. I'll let > Charles capture the thoughts of the working group and decide what to do. >=20 Sure. -Raj >=20 >>>> It should be stated here or in the "Security Considerations" section >>>> that this procedure is insecure and may have security impact, as we re= ly >>>> on basic ND and undergo associated threats. This is documented: >>>>=20 >>>> http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00 >>>>=20 >>>=20 >>> How about: >>>=20 >>> o Given the availability of the home prefix, the MN checks whether >>> or not the home prefix matches one of the prefixes received in th= e >>> RA. If it does, the MN concludes that it is connected to the hom= e >>> link. Please see Section 15.10 for information regarding the >>> security vulnerability associated with this determination. >>>=20 >>>=20 >>> and, >>>=20 >>> 15.10. Vulnerabilities from Neighbor Discovery >>>=20 >>> The ``Home Link Detection'' mechanism (Section 11.5.2) allows the MN >>> to detect when it is at home. When a MN detects it is at home, it i= s >>> expected to deregister, and also (if in use) to stop IPsec protectio= n >>> for data traffic exchanged over the tunnel to its Home Agent. >>>=20 >>> Unfortunately, Neighbor Discovery is not a secure protocol. It is >>> possible that some networks may harbor malicious routing agents that >>> might advertise false information which would lead a mobile node to >>> erroneously determine that it had returned to its home network. >>>=20 >>> A draft [40] has been written that discusses the possible threats >>> and security impacts associated with the use of this insecure NDP- >>> based mechanism as a trigger to drop IPsec protection of data traffi= c >>> for the MN. It also provides some results on the implementation of >>> the attacks against an existing MIPv6 module. Possible solutions ar= e >>> suggested. >>=20 >> This is a much larger change to 3775bis. I-D: >> draft-ebalard-mext-hld-security-00 has not really been discussed in the = MEXT >> WG AFAICT >=20 > True. I think I only got a comment from Julien. >=20 >> and hence making this change based on this reference is not what I >> believe is in the scope of the current revision of 3775bis. >> If an when the MEXT WG agrees that the threats identified in the referen= ced >> I-D are accepted, it is okay to make these changes. >=20 > Fine with me. >=20 > Cheers, >=20 > a+ From julienl@qualcomm.com Fri Oct 9 15:55:24 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D9843A69A5 for ; Fri, 9 Oct 2009 15:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.569 X-Spam-Level: X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=-0.970, 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 B4eFE7NzorgD for ; Fri, 9 Oct 2009 15:55:23 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 8258F3A69BC for ; Fri, 9 Oct 2009 15:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1255129029; x=1286665029; 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"Laganier,=20Julien"=20 |To:=20"Basavaraj.Patil@nokia.com"=20,=0D=0A=20=20=20=20=20=20=20=20"charles.perkins@ea rthlink.net"=20,=0D=0A=20 =20=20=20=20=20=20=20"arno@natisbad.org"=20|CC:=20"mext@ietf.org"=20|Date:=20Fri ,=209=20Oct=202009=2015:56:53=20-0700|Subject:=20RE:=20[M EXT]=20EXTENDED=20[WGLC]=20RFC=203775=20bis=20/=20draft-i etf-mext-rfc3775bis|Thread-Topic:=20[MEXT]=20EXTENDED=20[ WGLC]=20RFC=203775=20bis=20/=0D=0A=20draft-ietf-mext-rfc3 775bis|Thread-Index:=20AcpJJXQbKOxA6rTCTpKSlHVOoX6CMAAAaL FhAALZUwA=3D|Message-ID:=20|References:=20 <4ACFA799.3080403@earthlink.net>=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,5766"=3B=20a=3D"24925184"; bh=YEFFCXpsQ8LXH0NfZf+0EPgzfS/hy9eEFWdCLz/0gL8=; b=C5RDlhciUkiUYJmUKki81ziBdLdbZSe52QFg3jdGPhJHFyHHYpM12/3w s7NBBoCEDbe4s22Az+P1ingxACZG+mqL/ggAG2ZfrnVXH+5X3kPxVlJyF QJK6wKlgZIM6jGwL/L2RZoHD7E3cwcqxGPup0HaiK9lbX9+DWXF3C2APq w=; X-IronPort-AV: E=McAfee;i="5300,2777,5766"; a="24925184" 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; 09 Oct 2009 15:57:08 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n99Mv8JW031876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Oct 2009 15:57:08 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n99Mv3dp027091 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 9 Oct 2009 15:57:07 -0700 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 9 Oct 2009 15:56:56 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Fri, 9 Oct 2009 15:56:55 -0700 From: "Laganier, Julien" To: "Basavaraj.Patil@nokia.com" , "charles.perkins@earthlink.net" , "arno@natisbad.org" Date: Fri, 9 Oct 2009 15:56:53 -0700 Thread-Topic: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis Thread-Index: AcpJJXQbKOxA6rTCTpKSlHVOoX6CMAAAaLFhAALZUwA= Message-ID: References: <4ACFA799.3080403@earthlink.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 22:55:24 -0000 Basavaraj, Basavaraj Patil wrote:=20 >=20 > A few comments about some of the citations being proposed: >=20 >=20 > On 10/9/09 4:14 PM, "Charles Perkins" > wrote: >=20 > >> Considering the mechanism is implemented and such an interface > needed to > >> support that, 3775bis could at least point MIGRATE doc given below > as an > >> informational reference document. This clarifies the need and gives > a > >> possible solution. > >> > >> http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced- > migrate-00 > >> > > > > So that I can finish revising rfc3775bis before having to stop and > read > > that draft, > > can you provide some suggested text for the proposed citation? I'll > try > > to read the > > draft in the next few days understand your citation and text. >=20 > This reference does not add any value to 3775bis. It is more relevant > in the > context of 3776 or 4877. Adding this reference even in the Informative > section is not required. Speaking as an individual regarding whether or not addition of the referenc= e is required: Well, informative references are by definition informative a= nd are not required to be read to implement the specification. IMHO the ref= erence does provide useful information since it points to an API between IP= sec and MIPv6 which is implicitly assumed in the design of 3775. That being said, I agree with you that such a reference would also be relev= ant in the context of 3776 and 4877. --julien From charles.perkins@earthlink.net Fri Oct 9 16:01:12 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06AD13A69E2 for ; Fri, 9 Oct 2009 16:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBPiwGTBLAwH for ; Fri, 9 Oct 2009 16:01:11 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 3F99C3A6A7B for ; Fri, 9 Oct 2009 16:00:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=EoQsRtTHsyUNz2M8/y4DJ+1HmHdn1IV/mZTynP1Opw9oNWLKz1v/befS8QharQwE; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.139]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MwOTp-0001LO-L7; Fri, 09 Oct 2009 19:02:33 -0400 Message-ID: <4ACFC109.9050409@earthlink.net> Date: Fri, 09 Oct 2009 16:02:33 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Arnaud Ebalard Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f524bf397396d182f5397d6d295816ee77c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: mext Subject: [MEXT] Neighbor Discovery citations X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 23:01:12 -0000 Hello folks, Following my previous comment, I have made changes based on Arnaud's suggestion. Generally, in a section of text, I make an initial citation indicating Neighbor Discovery. For subsequent references in the same paragraph or related section of text, I use the shorter "RFC 4861" to identify the citation. I hope this is agreeable. Repeating Neighbor Discovery over and over again seems quite tedious. If anyone else wants to suggest other places where RFC-style citations should be converted into "protocol-name" style citations, please send me specific instances and I'll take a crack at it next week. Regards, Charlie P. > >> s/RFC 4861 [20]/Neighbor Discovery [20]/ > >> > >> IMHO, this is easier to read. Note that there are various places in the > >> document where the replacement should be done. > >> > > > > > I'd be happier if you could point them out. > > > No problem: > > Section 6.7 Page 62, first paragrah: > > The Mobile Prefix Solicitation messages may have options. These > options MUST use the option format defined in RFC 4861 [20]. > > Section 6.8 Page 64, first paragraph: > > The Mobile Prefix Advertisement messages may have options. These > options MUST use the option format defined in RFC 4861 [20]. > > Section 6.8 Page 64, second paragraph of Prefix Information descr: > > The Prefix Information option is defined in Section 4.6.2 of RFC > 4861 [20], with modifications defined in Section 7.2 of this > > Section 7.2 Page 67, middle of first paragraph: > > than the limit specified in RFC 4861 [20], the sending router need > not include all options in each of these Advertisements. However, in > > Section 7.5 Page 71, two occurences in first paragraph: > > are available MUST NOT default to them, and SHOULD default to values > specified in RFC 4861. Knowledge of the type of network interface > > and > > can cause considerable overhead. Routers SHOULD adhere to the > intervals specified in RFC 4861 [20], if this overhead is likely to > > Section 7.5 Page 71, last paragraph: > > Note that according to RFC 4861 [20], AdvDefaultLifetime is by > default based on the value of MaxRtrAdvInterval. AdvDefaultLifetime > > Section 10.6.1 Page 106, two occurences in last paragraph of that sect.: > > itself and other home agents on the home link. In RFC 4861 [20] it > is acceptable for two routers to advertise different sets of prefixes > > and > > All other comparisons of Router Advertisements are as specified in > Section 6.2.7 of RFC 4861. > > Section 11.5.1 Page 126, first paragraph: > > to discover routers and prefixes on the new link, as described in > Section 6.3.7 of RFC 4861 [20]. > > Section 13 Page 145, third paragraph: > > The value MinDelayBetweenRAs overrides the value of the protocol > constant MIN_DELAY_BETWEEN_RAS, as specified in RFC 4861 [20]. This > > > From julienl@qualcomm.com Fri Oct 9 16:09:06 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 512353A67FB for ; Fri, 9 Oct 2009 16:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.547 X-Spam-Level: X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=-0.948, 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 HTYP0pB37Rjl for ; Fri, 9 Oct 2009 16:09:05 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 97A4E28C215 for ; Fri, 9 Oct 2009 16:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1255129851; x=1286665851; 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"Laganier,=20Julien"=20 |To:=20"Charles=20E.=20Perkins"=20,=0D=0A=20=20=20=20=20=20=20=20Arnaud=20Ebalard =0D=0A=09|CC:=20mext=20 |Date:=20Fri,=209=20Oct=202009=2016:10:38=20-0700 |Subject:=20RE:=20[MEXT]=20Neighbor=20Discovery=20citatio ns|Thread-Topic:=20[MEXT]=20Neighbor=20Discovery=20citati ons|Thread-Index:=20AcpJNQ5sso97Y/sCRFGdZQM2DdLcGAAAE9uA |Message-ID:=20|References:=20<4ACFC109.90 50409@earthlink.net>|In-Reply-To:=20<4ACFC109.9050409@ear thlink.net>|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"5300,2777,5766"=3B=20a=3D"24925934"; bh=OtLmv8ZFLCG/JsNd2puo+CLf/QX8CUl9IitVauvjK4s=; b=h0a3sj1Xv4RWKjTK7sSIzLHKnd01dEjPuh2EeC81KYQB1BJB690RYT3/ bbmjjxl785rco6tQlEu3afcbRSepwxms1IH0jxPihwiEI9xpZBzd3i4FU 4bGo8uSSWCMACfQGRbhLRtqrkV37oWHm+NzxrotXETN/QYSbsFujm3X+0 s=; X-IronPort-AV: E=McAfee;i="5300,2777,5766"; a="24925934" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Oct 2009 16:10:51 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n99NAonI017442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Oct 2009 16:10:51 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n99NAdxJ004379 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 9 Oct 2009 16:10:50 -0700 (PDT) Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 9 Oct 2009 16:10:40 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Fri, 9 Oct 2009 16:10:40 -0700 From: "Laganier, Julien" To: "Charles E. Perkins" , Arnaud Ebalard Date: Fri, 9 Oct 2009 16:10:38 -0700 Thread-Topic: [MEXT] Neighbor Discovery citations Thread-Index: AcpJNQ5sso97Y/sCRFGdZQM2DdLcGAAAE9uA Message-ID: References: <4ACFC109.9050409@earthlink.net> In-Reply-To: <4ACFC109.9050409@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mext Subject: Re: [MEXT] Neighbor Discovery citations X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 23:09:06 -0000 Charles E. Perkins wrote:=20 >=20 > Hello folks, >=20 > Following my previous comment, I have made changes > based on Arnaud's suggestion. Generally, in a section of text, > I make an initial citation indicating Neighbor Discovery. > For subsequent references in the same paragraph or > related section of text, I use the shorter "RFC 4861" > to identify the citation. I hope this is agreeable. > Repeating Neighbor Discovery over and over again > seems quite tedious. >=20 > If anyone else wants to suggest other places where > RFC-style citations should be converted into > "protocol-name" style citations, please send me > specific instances and I'll take a crack at it next > week. I think the RFC Editor is going to use a citation style that encloses the R= FC number in between brakets, thus the end result RFC won't have "RFC 4861 = [20]", but "RFC 4861 [RFC4861]". From that point of view it does make sense= to either use "Neighbor Discovery [RFC4861]", or only the reference "[RFC4= 861]". --julien From charles.perkins@earthlink.net Fri Oct 9 16:28:01 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051D63A6A75 for ; Fri, 9 Oct 2009 16:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.763 X-Spam-Level: X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yq9fbg9vlT1x for ; Fri, 9 Oct 2009 16:28:00 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 24AC13A69FF for ; Fri, 9 Oct 2009 16:28:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=iAX4vf5WP0BMQN2eOfhSyooItdVgve4BP+mnRLLBuCPw9QQyxpc9tVrJTv9P5yVH; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.139]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MwOu1-00041R-RH for mext@ietf.org; Fri, 09 Oct 2009 19:29:38 -0400 Message-ID: <4ACFC75D.2090905@earthlink.net> Date: Fri, 09 Oct 2009 16:29:33 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5259367347cf92dd9e4aa50896a0ee2631350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Subject: [MEXT] draft-ietf-mext-rfc3775bis-05.txt ("Mobility Support in IPv6") X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 23:28:01 -0000 Hello folks, TGIF! I've compiled revision #5 for "Mobility Support in IPv6", and copied it to the following URL: http://www.psg.com/~charliep/txt/mobilev6/draft-ietf-mext-rfc3775bis-05.txt I removed (at least for now) the proposed new Security Considerations section and related text. I think I have covered all the non-controversial revisions and improvements that have been suggested since July. I'd like to submit it for IETF publication next week. Regards, Charlie P. From wassim.haddad@ericsson.com Sun Oct 11 22:59:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41CAB3A67DD for ; Sun, 11 Oct 2009 22:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 PIiqSBe2aOec for ; Sun, 11 Oct 2009 22:59:13 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 777303A6407 for ; Sun, 11 Oct 2009 22:59:13 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n9C5x6Ke029821; Mon, 12 Oct 2009 00:59:06 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 00:59:05 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 00:59:05 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.110]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 12 Oct 2009 01:59:05 -0400 From: Wassim Haddad To: "mext@ietf.org" Date: Mon, 12 Oct 2009 01:59:03 -0400 Thread-Topic: MIPv6 interaction with NAT64 Thread-Index: AcpLARndL9vNge+8RUm5YODM2La46g== Message-ID: <2991246A29623A4082EB2B06A2B891A41B804B217C@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2991246A29623A4082EB2B06A2B891A41B804B217CEUSAACMS0703e_" MIME-Version: 1.0 X-OriginalArrivalTime: 12 Oct 2009 05:59:05.0460 (UTC) FILETIME=[1B108B40:01CA4B01] Cc: "Charliep@computer.org" , Wassim Haddad Subject: [MEXT] MIPv6 interaction with NAT64 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 05:59:14 -0000 --_000_2991246A29623A4082EB2B06A2B891A41B804B217CEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The following draft has been discussed first in BEHAVE WG and it was recomm= ended to re-submit it to MEXT for further discussion. http://www.ietf.org/id/draft-haddad-mext-nat64-mobility-harmful-00.txt Please take a look. Comments are highly appreciated! Regards, Wassim H. --_000_2991246A29623A4082EB2B06A2B891A41B804B217CEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,
 
The following draft has been discussed first in BEHAVE WG and it was r= ecommended to
re-submit it to MEXT for further discussion.
 
 
 
Please take a look. Comments are highly appreciated!
 
 
Regards,
 
Wassim H.
 
 
 
 --_000_2991246A29623A4082EB2B06A2B891A41B804B217CEUSAACMS0703e_-- From kaaspetersen@yahoo.dk Mon Oct 12 05:05:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D7E3A68C6 for ; Mon, 12 Oct 2009 05:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggivJfn9lPLp for ; Mon, 12 Oct 2009 05:05:03 -0700 (PDT) Received: from web27801.mail.ukl.yahoo.com (web27801.mail.ukl.yahoo.com [217.146.182.6]) by core3.amsl.com (Postfix) with SMTP id 92B8528B797 for ; Mon, 12 Oct 2009 05:05:02 -0700 (PDT) Received: (qmail 85657 invoked by uid 60001); 12 Oct 2009 12:04:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1255349099; bh=5MO/hXuHJf9HElr2FpXvWmUWT5DBal6vPKZyoCGdSR0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=glfupBceZbEOuTRoD5sZeYUoC/nv6Venm6T0tzd6WPbht1Q+bG9pfYhD4p+bCBrPDV3e+O7YzBu8R27qpfa4xLhQs9yUX++aufKTCTjHpxGgVLJwReGLnRNbb0KNn53ZNiGD0qa6XJnnmb1qnJQQk4pkbc2+K7nyckNcWu1k7AI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zs5Kxsc1Fjdamg2ShlxHzJR53DZs3iNbGLLdUObtLR9fPMPu1XdHheM2EAaD8GlBAZc9r3WyUwwgi54FE+e1yJx6+3kbEe5ADa25C076RzCa0eT8Ej2Vl78887TJShDn/wK4efQ8RT27jhY5AGHGtEm00XXBSQpwIwJxkZEQ1Bs=; Message-ID: <610435.85626.qm@web27801.mail.ukl.yahoo.com> X-YMail-OSG: nj7mg90VM1koAkqmeZz14ACvCAlJgbBBQKUI655N2PiWbyAHiYpMXNPIj1t12LwML6xA7NMWBLeh6aIsU1F0MvQMDrqhBA1kc1ZdCZfPWQUqV7pW4YS_mLbxlSCDsdjKgyl4FcoC1b_4RKWccxkK6.UyDsKifXYPfofWwK_8POBjTVuU8bNKpGM5KGfVOCNwVjWWAFFpaMX0gWq83HSCkaxyAHH415QdbRyrEVVl_Eu7rWPZWc8SoPuTuoefBmjZw8v93hmE9iegYkeT.QUqpPbNwnqTllOLHuQDNnvACtT2OQ8fjbaXrPQslf4snsWobdL7JGkvuw-- Received: from [194.237.142.7] by web27801.mail.ukl.yahoo.com via HTTP; Mon, 12 Oct 2009 12:04:59 GMT X-Mailer: YahooMailClassic/7.0.14 YahooMailWebService/0.7.347.3 Date: Mon, 12 Oct 2009 12:04:59 +0000 (GMT) From: Christian Kaas-Petersen To: mext@ietf.org, ext-fuad.junior@nokia.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [MEXT] Request for I-D draft-premec-mext-extended-home-link-04 being accepted as a MEXt WG item X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 12:05:04 -0000 I have read the draft. I have one item I should to be discussed further, o= ne item I should like to have clarified, and I have some editorial remarks. Item for discussion. It must be a simple operation for a mobile node to cl= ear its entries in the binding cache of its chosen home agent. Such a simp= le operation is the sending of a BU with lifetime of zero. I believe this = principle is enforced in all mobility related protocols. Therefore I think= the choice made in section 6.2 is not the best choice. If the mobile node= "forgets" the IPv4 Home Address option, the home agent continues keeping t= he IPv4 HoA binding until its lifetime expires. This is not so good, altho= ugh it doesn't harm. My view is, that if the home agent is smart enought t= o understand the X flag, it should be smart enough to know of the relation = between the IPv4 HoA and the IPv6 HoA. Item for clarification. In section 3, the last paragraph gives the impress= ion it is possible to observe a gap, when using RFC5555 packets, between a = normal complete de-registration and a subsequent registration of only an IP= v4 home address. The BU for this subsequent attempt to do a registration w= ill, as far as I can work it out, be identical to the BU shown in section 5= .3, with the only modification of the X flag being absent, but such a BU wi= ll be treated by all home agents as a de-registration. Therefore it is not= possible with RFC5555 packets and semantics to create the IPv4 HoA entry. = Please correct me if I am wrong. Editorial comments. * Abstract, first sentence: "supported on the link" change to "supported on the foreign link". * Abstract, third sentence: I suggest you change "deprecated" to "cleared". * Abstract, fourth sentence: "related to the de-registration" change to "related to the registration and the de-registration". This is because the mobile node might actually boot up and do its first registration on an IPv6-only home link. * Section 1, first paragraph: "may be in many cases IPv6 only" change to "may in many cases be IPv6 only". * Section 1, second paragraph: "if the attaches to its home link" change to "if the mobile node attaches to its home link". * Section 4, first para: "on its outbound interface". All interfaces allow inbound and outbound traffic. What is meant is north-bound interface or upstream interface. * Section 5.3, "The HA sends the following response", to this should be added, that the response is sent only if the A-flag=3D1 was set in the BU, else no response is sent. * Section 6.2, "the lifetime filed" change to "the lifetime field". * Section 10.2, multiplecoa draft is now RFC5648. Christian =20 --- Den tors 8/10/09 skrev ext-fuad.junior@nokia.com : Fra: ext-fuad.junior@nokia.com Emne: [MEXT] Request for I-D draft-premec-mext-extended-home-link-04 being = accepted as a MEXt WG item Til: mext@ietf.org Cc: mext-chairs@tools.ietf.org Dato: torsdag 8. oktober 2009 23.00 Hi, =A0=A0=A0 I have revised the I-D "IPv4 Support for DSMIPv6 IPv6 Home Link" = (http://tools.ietf.org/html/draft-premec-mext-extended-home-link-04) based = on comments received. This I-D has been previously accepted for being adopt= ed as WG document, since it solves the problem of a DSMIP6 MN attaching to = an IPv6 only home-link. Therefore, I would like to request approval from th= e chairs to post the I-D as WG document.=20 =A0=A0=A0 Any reviews or comments from others are also appreciated. Regards, Fuad Abinader >-----Original Message----- >From: ext Fuad Abinader [mailto:fabinader@gmail.com]=20 >Sent: quinta-feira, 8 de outubro de 2009 16:43 >To: Junior Fuad (EXT-INdT/Manaus) >Subject: Fwd: New Version Notification for=20 >draft-premec-mext-extended-home-link-04 > >---------- Forwarded message ---------- >From: IETF I-D Submission Tool >Date: 2009/10/8 >Subject: New Version Notification for=20 >draft-premec-mext-extended-home-link-04 >To: fabinader@gmail.com >Cc: domagoj.premec@gmail.com, jouni.nospam@gmail.com > > > >A new version of I-D,=20 >draft-premec-mext-extended-home-link-04.txt has been=20 >successfuly submitted by Fuad Abinader and posted to the IETF=20 >repository. > >Filename: =A0 =A0 =A0 =A0draft-premec-mext-extended-home-link >Revision: =A0 =A0 =A0 =A004 >Title: =A0 =A0 =A0 =A0 =A0 IPv4 Support for DSMIPv6 IPv6 Home Link >Creation_date: =A0 2009-10-08 >WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission >Number_of_pages: 13 > >Abstract: >Mobile IPv6 for Dual Stack Hosts and Routers enables mobility=20 >for the mobile node's IPv6 home address or prefix as well as=20 >an IPv4 home address, irrespective of the IP version supported=20 >on the link that the mobile node is attached to. =A0The home=20 >agent maintains binding cache entries for the IPv6 and IPv4=20 >home addresses assigned to the mobile node when the mobile=20 >node is connected via a foreign link. >The binding cache entries are deprecated when the mobile node=20 >attaches to its home link. =A0This document addresses an issue=20 >related to the de-registration procedure and the continued=20 >connectivity for the IPv4 home address when the mobile node=20 >attaches to its IPv6-only home link. > > > >The IETF Secretariat. > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext =0A=0A=0A Find din nye laptop p=E5 kelkoo.dk. Se de gode tilbud her - = http://dk.yahoo.com/r/pat/mm From Basavaraj.Patil@nokia.com Mon Oct 12 10:06:05 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D05528C254 for ; Mon, 12 Oct 2009 10:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.208, 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 yRnaKRNHVeHR for ; Mon, 12 Oct 2009 10:06:04 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 83A4D28C236 for ; Mon, 12 Oct 2009 10:06:03 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9CH5vdA031299; Mon, 12 Oct 2009 20:06:01 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 20:05:59 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 20:05:58 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Mon, 12 Oct 2009 19:05:58 +0200 From: To: , , Date: Mon, 12 Oct 2009 19:06:07 +0200 Thread-Topic: [MEXT] Request for I-D draft-premec-mext-extended-home-link-04 being accepted as a MEXt WG item Thread-Index: AcpLNPzhP/H+IEEZTZm3uDDtbQ1BBQAKUzhd Message-ID: In-Reply-To: <610435.85626.qm@web27801.mail.ukl.yahoo.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Oct 2009 17:05:58.0585 (UTC) FILETIME=[44BEE290:01CA4B5E] X-Nokia-AV: Clean Subject: Re: [MEXT] Request for I-D draft-premec-mext-extended-home-link-04 being accepted as a MEXt WG item X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 17:06:05 -0000 Hello, A few responses inline: On 10/12/09 7:04 AM, "ext Christian Kaas-Petersen" wrote: >=20 > I have read the draft. I have one item I should to be discussed further,= one > item I should like to have clarified, and I have some editorial remarks. >=20 > Item for discussion. It must be a simple operation for a mobile node to = clear > its entries in the binding cache of its chosen home agent. Such a simple > operation is the sending of a BU with lifetime of zero. I believe this > principle is enforced in all mobility related protocols. Sending a BU with lifetime=3D0 is a simple and clean operation for deregistering the bindings. This is simple in the basic MIP6 protocol wherein you had one CoA registered as the default CoA. However with DSMIP6 and MCoA (and subsequently flow bindings as well) the binding cache is more complex. The HA maintains bindings for multiple CoAs as well as v4 and v6 HoAs. A simple dereg message with lifetime=3D0 is not explicit enough for t= he HA to determine if all bindings need to be deprecated or only the v6 HoA. As per RFC5555 (Sec 4.4.2.1): " Deregistering the IPv6 home address is described in [RFC3775]. The same mechanism applies in this specification. Mobile nodes may remove the binding for only the IPv4 home address 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 maintaining 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. " The above text does not provide a solution for the scenario wherein the MN is on an IPv6 only HL. The options covered for dereg in 5555 are: 1. Deregister all bindings (v4 and v6 HoA) by sending a BU with lifetime=3D= 0 2. Deregister an IPv4 HoA by sending a BU excluding the IPv4 HoA If the MN wants the v4 HoA binding to be maintained while deprecating the binding for the v6 HoA as a result of being on its IPv6 HL, a more explicit indication to the HA is necessary. > Therefore I think > the choice made in section 6.2 is not the best choice. If the mobile nod= e > "forgets" the IPv4 Home Address option, the home agent continues keeping = the > IPv4 HoA binding until its lifetime expires. This is not so good, althou= gh it > doesn't harm. My view is, that if the home agent is smart enought to > understand the X flag, it should be smart enough to know of the relation > between the IPv4 HoA and the IPv6 HoA. You assume that the HA is smart enough. It would be better to have a well-defined mechanism how the HA handles the deregistration of only the v6 HoA binding. It is not a question of the MN forgetting to include the v4 Ho= A in the dereg. It is rather the MN wanting to ensure that the v4 HoA continues to operate even when there is no binding for the v6 HoA itself. >=20 > Item for clarification. In section 3, the last paragraph gives the impre= ssion > it is possible to observe a gap, when using RFC5555 packets, between a no= rmal > complete de-registration and a subsequent registration of only an IPv4 ho= me > address. The BU for this subsequent attempt to do a registration will, a= s far > as I can work it out, be identical to the BU shown in section 5.3, with t= he > only modification of the X flag being absent, but such a BU will be treat= ed by > all home agents as a de-registration. Therefore it is not possible with > RFC5555 packets and semantics to create the IPv4 HoA entry. Please corre= ct me > if I am wrong. The I-D is not recommending doing a deregistration of all the HoAs and then sending a subsequent BU to register the v4 HoA with the v6 HoA as the CoA. It is simply providing anticipated behavior. But IMO the BU sent by the MN which has SRC=3DIPv6HoA and the X flag would create a binding for the v4 Ho= A with packets being tunnelled to the IPv6 HoA of the MN. IMO dereg operation should have the following behavior: 1. Sending a BU with lifetime=3D0 deprecates all bindings. This is irrespective of the source address in the BU. An MN may simply want to deregister mobility support even when located on a foreign link. 2. Sending a BU to deregister only the v6 or v4 HoA from foreign link. 3. Sending a BU to deregister only the v6 or v4 HoA when it is on its home link.=20 Cheers, -Raj >=20 > Editorial comments. >=20 > * Abstract, first sentence: "supported on the link" change to > "supported on the foreign link". > * Abstract, third sentence: I suggest you change "deprecated" to "cleared= ". > * Abstract, fourth sentence: "related to the de-registration" change to > "related to the registration and the de-registration". This is because > the mobile node might actually boot up and do its first registration on > an IPv6-only home link. > * Section 1, first paragraph: "may be in many cases IPv6 only" change to > "may in many cases be IPv6 only". > * Section 1, second paragraph: "if the attaches to its home link" change > to "if the mobile node attaches to its home link". > * Section 4, first para: "on its outbound interface". All interfaces > allow inbound and outbound traffic. What is meant is north-bound > interface or upstream interface. > * Section 5.3, "The HA sends the following response", to this should be > added, that the response is sent only if the A-flag=3D1 was set in > the BU, else no response is sent. > * Section 6.2, "the lifetime filed" change to "the lifetime field". > * Section 10.2, multiplecoa draft is now RFC5648. >=20 > Christian >=20 >=20 >=20 > --- Den tors 8/10/09 skrev ext-fuad.junior@nokia.com > : >=20 >=20 > Fra: ext-fuad.junior@nokia.com > Emne: [MEXT] Request for I-D draft-premec-mext-extended-home-link-04 bein= g > accepted as a MEXt WG item > Til: mext@ietf.org > Cc: mext-chairs@tools.ietf.org > Dato: torsdag 8. oktober 2009 23.00 >=20 >=20 >=20 > Hi, >=20 > =A0=A0=A0 I have revised the I-D "IPv4 Support for DSMIPv6 IPv6 Home Link= " > (http://tools.ietf.org/html/draft-premec-mext-extended-home-link-04) base= d on > comments received. This I-D has been previously accepted for being adopte= d as > WG document, since it solves the problem of a DSMIP6 MN attaching to an I= Pv6 > only home-link. Therefore, I would like to request approval from the chai= rs to > post the I-D as WG document. > =A0=A0=A0 Any reviews or comments from others are also appreciated. >=20 > Regards, >=20 > Fuad Abinader >=20 >> -----Original Message----- >> From: ext Fuad Abinader [mailto:fabinader@gmail.com] >> Sent: quinta-feira, 8 de outubro de 2009 16:43 >> To: Junior Fuad (EXT-INdT/Manaus) >> Subject: Fwd: New Version Notification for >> draft-premec-mext-extended-home-link-04 >>=20 >> ---------- Forwarded message ---------- >> From: IETF I-D Submission Tool >> Date: 2009/10/8 >> Subject: New Version Notification for >> draft-premec-mext-extended-home-link-04 >> To: fabinader@gmail.com >> Cc: domagoj.premec@gmail.com, jouni.nospam@gmail.com >>=20 >>=20 >>=20 >> A new version of I-D, >> draft-premec-mext-extended-home-link-04.txt has been >> successfuly submitted by Fuad Abinader and posted to the IETF >> repository. >>=20 >> Filename: =A0 =A0 =A0 =A0draft-premec-mext-extended-home-link >> Revision: =A0 =A0 =A0 =A004 >> Title: =A0 =A0 =A0 =A0 =A0 IPv4 Support for DSMIPv6 IPv6 Home Link >> Creation_date: =A0 2009-10-08 >> WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission >> Number_of_pages: 13 >>=20 >> Abstract: >> Mobile IPv6 for Dual Stack Hosts and Routers enables mobility >> for the mobile node's IPv6 home address or prefix as well as >> an IPv4 home address, irrespective of the IP version supported >> on the link that the mobile node is attached to. =A0The home >> agent maintains binding cache entries for the IPv6 and IPv4 >> home addresses assigned to the mobile node when the mobile >> node is connected via a foreign link. >> The binding cache entries are deprecated when the mobile node >> attaches to its home link. =A0This document addresses an issue >> related to the de-registration procedure and the continued >> connectivity for the IPv4 home address when the mobile node >> attaches to its IPv6-only home link. >>=20 >>=20 >>=20 >> The IETF Secretariat. >>=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 >=20 >=20 > Find din nye laptop p=E5 kelkoo.dk. Se de gode tilbud her - > http://dk.yahoo.com/r/pat/mm > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From Basavaraj.Patil@nokia.com Mon Oct 12 10:09:50 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC92D28C271 for ; Mon, 12 Oct 2009 10:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.604, 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 NXfJ8c41TnyV for ; Mon, 12 Oct 2009 10:09:50 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A7B6E28C261 for ; Mon, 12 Oct 2009 10:09:49 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9CH9isU018537; Mon, 12 Oct 2009 20:09:45 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 20:09:44 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 20:09:43 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 20:09:39 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 12 Oct 2009 19:09:38 +0200 From: To: Date: Mon, 12 Oct 2009 19:09:50 +0200 Thread-Topic: RFC3775bis dereg issue Thread-Index: AcpLXs6uAvLojLxPj0Sdkk15oBtBwg== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Oct 2009 17:09:39.0469 (UTC) FILETIME=[C8671BD0:01CA4B5E] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: [MEXT] RFC3775bis dereg issue X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 17:09:50 -0000 Hi Charlie, In Rev 5 of the I-D posted at the URL in your earlier email, Sec 10.3.2 states: " When the Status field in the Binding Acknowledgement is greater than or equal to 128 and the Source Address of the Binding Update is on the home link, the home agent MUST send it to the mobile node's link layer address (retrieved either from the Binding Update or through Neighbor Solicitation). " The MN may be on a virtual HL and hence there may not be a LLA for the MN t= o which the BAck can be sent. IMO the above sentence should be revised by deleting the part about sending it to the LLA and the clarification in the parentheses. -Basavaraj From charles.perkins@earthlink.net Mon Oct 12 10:49:19 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B7653A689E for ; Mon, 12 Oct 2009 10:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QB4v3EchAodN for ; Mon, 12 Oct 2009 10:49:18 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 617253A682E for ; Mon, 12 Oct 2009 10:49:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=lMA+bNAUi98zXrC6N/t+1ykybDLKNZW0FMll/JsOJLwLeZ2zqWo2oQhSVxxezPbJ; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.153]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MxP1F-00060X-Pf; Mon, 12 Oct 2009 13:49:13 -0400 Message-ID: <4AD36C18.8040407@earthlink.net> Date: Mon, 12 Oct 2009 10:49:12 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52934f091764fcb7a58cb87273cba4e119350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: mext@ietf.org Subject: Re: [MEXT] RFC3775bis dereg issue X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 17:49:19 -0000 Hello Basavaraj, What if I add another clause, to say that the mandate is placed when the Binding Update came from a mobile node on the same link? Regards, Charlie P. Basavaraj.Patil@nokia.com wrote: > Hi Charlie, > > In Rev 5 of the I-D posted at the URL in your earlier email, Sec 10.3.2 > states: > > " > When the Status > field in the Binding Acknowledgement is greater than or equal to 128 > and the Source Address of the Binding Update is on the home link, the > home agent MUST send it to the mobile node's link layer address > (retrieved either from the Binding Update or through Neighbor > Solicitation). > > " > > The MN may be on a virtual HL and hence there may not be a LLA for the MN to > which the BAck can be sent. IMO the above sentence should be revised by > deleting the part about sending it to the LLA and the clarification in the > parentheses. > > -Basavaraj > > > > From Basavaraj.Patil@nokia.com Mon Oct 12 11:14:06 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DCEF3A694C for ; Mon, 12 Oct 2009 11:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 aC7VXUXtTjfE for ; Mon, 12 Oct 2009 11:14:05 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 00E6E3A6948 for ; Mon, 12 Oct 2009 11:14:04 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9CIDqBh032507; Mon, 12 Oct 2009 21:13:59 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 21:13:53 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 21:13:48 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 12 Oct 2009 20:13:48 +0200 From: To: Date: Mon, 12 Oct 2009 20:13:58 +0200 Thread-Topic: RFC3775bis dereg issue Thread-Index: AcpLZFZXy/vWB1G6RFeQHkDuXh6AEQAA23t/ Message-ID: In-Reply-To: <4AD36C18.8040407@earthlink.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Oct 2009 18:13:48.0810 (UTC) FILETIME=[BEC9EEA0:01CA4B67] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] RFC3775bis dereg issue X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 18:14:06 -0000 Hi Charlie, On 10/12/09 12:49 PM, "Charles Perkins" wrote: >=20 >=20 > Hello Basavaraj, >=20 > What if I add another clause, to say that the mandate > is placed when the Binding Update came from a mobile > node on the same link? I think that would work.Thx. -Basavaraj >=20 > Regards, > Charlie P. >=20 >=20 > Basavaraj.Patil@nokia.com wrote: >> Hi Charlie, >>=20 >> In Rev 5 of the I-D posted at the URL in your earlier email, Sec 10.3.2 >> states: >>=20 >> " >> When the Status >> field in the Binding Acknowledgement is greater than or equal to 128 >> and the Source Address of the Binding Update is on the home link, the >> home agent MUST send it to the mobile node's link layer address >> (retrieved either from the Binding Update or through Neighbor >> Solicitation). >>=20 >> " >>=20 >> The MN may be on a virtual HL and hence there may not be a LLA for the M= N to >> which the BAck can be sent. IMO the above sentence should be revised by >> deleting the part about sending it to the LLA and the clarification in t= he >> parentheses. >>=20 >> -Basavaraj >>=20 >>=20 >>=20 >> =20 >=20 From arno@natisbad.org Tue Oct 13 02:34:26 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB0C3A67BE for ; Tue, 13 Oct 2009 02:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GopxOxzbKMNr for ; Tue, 13 Oct 2009 02:34:25 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id B33BF3A6774 for ; Tue, 13 Oct 2009 02:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natisbad.org; s=mail; h=From:To:Cc:Subject:References:Date: Message-ID:MIME-Version:Content-Type; bh=DygfHdK49gj8l3N+Aj2oEwZ A1fjEqW1LgNWYG0zDoL8=; b=rDZmeOo9njirW9B+IQrgAwMkT0qq4W4RaYnY6Rm Mlpu45iz7Xr67Tvb2FNiUCA9FAQBO63jIczbUcCU+xDJnN6poVtXNO4w4rtNwlnK U6Xyt8fiBuAG9N2d26s3CaJKpkmzBVa9VKrR873pAnp/8t9I20umpCTVpoe31rIf YMMs= Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Mxdla-0008C2-7c; Tue, 13 Oct 2009 11:34:02 +0200 X-Hashcash: 1:20:091013:marcelo@it.uc3m.es::yLqM3DUQ0UW+zN+N:00000000000000000000000000000000000000000000Ao3 X-Hashcash: 1:20:091013:julien.laganier.ietf@googlemail.com::iDYrsnJJ8oactWV9:0000000000000000000000000008kj From: arno@natisbad.org (Arnaud Ebalard) To: "Charles E. Perkins" References: <4ACFC75D.2090905@earthlink.net> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:091013:charles.perkins@earthlink.net::pdtai3qkdqK5ES+s:0000000000000000000000000000000002qI X-Hashcash: 1:20:091013:mext@ietf.org::MqEbRTAmpK3FX1YP:00004dyE Date: Tue, 13 Oct 2009 11:34:25 +0200 Message-ID: <877huzljry.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Julien Laganier , mext Subject: Re: [MEXT] draft-ietf-mext-rfc3775bis-05.txt ("Mobility Support in IPv6") X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 09:34:27 -0000 Hi, "Charles E. Perkins" writes: > I've compiled revision #5 for "Mobility Support in IPv6", > and copied it to the following URL: > > http://www.psg.com/~charliep/txt/mobilev6/draft-ietf-mext-rfc3775bis-05.txt Thanks. > I removed (at least for now) the proposed new > Security Considerations section and related text. > I think I have covered all the non-controversial > revisions and improvements that have been > suggested since July. I'd like to submit it for > IETF publication next week. Julien and Marcelo, do you have any thoughts on those aspects? Is there time and/or interest to add informational reference about: - MIGRATE draft - hld-sec draft (possible impact of ND insecurity) in the doc or do you consider that outside the scope of 3755bis? Cheers, a+ From rdroms@cisco.com Tue Oct 13 09:34:17 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D5523A6954 for ; Tue, 13 Oct 2009 09:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrG3rFtncz6g for ; Tue, 13 Oct 2009 09:34:16 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2DEFD3A685A for ; Tue, 13 Oct 2009 09:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=2108; q=dns/txt; s=rtpiport02001; t=1255451658; x=1256661258; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ralph=20Droms=20|Subject:=20Re :=20[MEXT]=20FW:=20=20I-D=20Action:draft-ietf-mext-bindin g-revocation-13.txt|Date:=20Tue,=2013=20Oct=202009=2012:3 4:15=20-0400|Message-Id:=20|To:=20Ahmad=20Muhanna=20|Cc:=20mext=20,=20Jari=20Arkko=20|Mime-Version:=201.0=20(Apple=20Messa ge=20framework=20v936)|Content-Transfer-Encoding:=207bit |In-Reply-To:=20|References:=20; bh=s98ZewnTKUTa6llNTy9uUJI5BiZPusgoAil6JRHHqkg=; b=D7Usynn2taXCa53gR27U3ZCRWpFTIhextO+VKmU4/Qsctq0Q4hg9eE/F OvN6FZJnZPbrNPfh7+FvE1yfB6H1pXfBz+GMi79ffWeOVEUEbs5TrcmgE FPJ2B9ZYBvoMpKsK3zl7K6wkDEM7yTRvGA5rgvtIEKhFBbiNyzo1s1AMr Q=; Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAE9J1EpAZnwN/2dsb2JhbADBEpgDhC0EgVs X-IronPort-AV: E=Sophos;i="4.44,551,1249257600"; d="scan'208";a="62827647" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 13 Oct 2009 16:34:15 +0000 Received: from [161.44.65.121] ([161.44.65.121]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9DGYFNi029052; Tue, 13 Oct 2009 16:34:15 GMT Message-Id: From: Ralph Droms To: Ahmad Muhanna In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Oct 2009 12:34:15 -0400 References: X-Mailer: Apple Mail (2.936) Cc: Jari Arkko , mext Subject: Re: [MEXT] FW: I-D Action:draft-ietf-mext-binding-revocation-13.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 16:34:17 -0000 I've cleared. - Ralph On Sep 30, 2009, at 2:15 AM 9/30/09, Ahmad Muhanna wrote: > All, > > We submitted revision (13) which addresses all comments that we > received > during the (IESG + Gen-ART) review + Removed the Acknowledge (A) bit. > > Please take a look and let us know if you have any comments. > > Regards, > Ahmad > > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf > Of > Internet-Drafts@ietf.org > Sent: Wednesday, September 30, 2009 1:00 AM > To: i-d-announce@ietf.org > Cc: mext@ietf.org > Subject: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-13.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobility EXTensions for IPv6 Working > Group of the IETF. > > > Title : Binding Revocation for IPv6 Mobility > Author(s) : A. Muhanna, et al. > Filename : draft-ietf-mext-binding-revocation-13.txt > Pages : 40 > Date : 2009-09-29 > > This document defines a binding revocation mechanism to terminate a > mobile node's mobility session and the associated resources. These > semantics are generic enough and can be used by mobility entities in > the > case of Mobile IPv6 and its extensions. This mechanism allows the > mobility entity which initiates the revocation procedure to request > its > peer to terminate either one, multiple or all specified binding(s). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-1 > 3.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. > revocation > -13 > .URL>_______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From Basavaraj.Patil@nokia.com Tue Oct 13 10:14:46 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1213A3A69BF for ; Tue, 13 Oct 2009 10:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 fKDLId4KX7UJ for ; Tue, 13 Oct 2009 10:14:44 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 683A23A67FF for ; Tue, 13 Oct 2009 10:14:44 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9DHEZNv024284 for ; Tue, 13 Oct 2009 20:14:43 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 20:14:32 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 20:14:32 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 13 Oct 2009 19:14:31 +0200 From: To: Date: Tue, 13 Oct 2009 19:14:41 +0200 Thread-Topic: Alternate security architecture I-D Thread-Index: AcpMKKaKHRHvPiZNfEKqCD46bvjS+w== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Oct 2009 17:14:32.0224 (UTC) FILETIME=[A14FBA00:01CA4C28] X-Nokia-AV: Clean Subject: [MEXT] Alternate security architecture I-D X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 17:14:46 -0000 Hello, The revised I-D proposing an alternate security architecture for (DS)MIP6 has been posted. Security architecture for Mobile IPv6 using TLS http://www.ietf.org/id/draft-korhonen-mext-mip6-altsec-02.txt Comments/feedback welcome. -Basavaraj From Basavaraj.Patil@nokia.com Tue Oct 13 10:15:45 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25D728C266 for ; Tue, 13 Oct 2009 10:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.357 X-Spam-Level: X-Spam-Status: No, score=-6.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 Eqj8TGEje23Y for ; Tue, 13 Oct 2009 10:15:45 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 868C128C246 for ; Tue, 13 Oct 2009 10:15:44 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9DHFJbH024172 for ; Tue, 13 Oct 2009 20:15:43 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 20:15:33 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 20:15:29 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 13 Oct 2009 19:15:24 +0200 From: To: Date: Tue, 13 Oct 2009 19:15:35 +0200 Thread-Topic: New Version Notification for draft-korhonen-mext-mip6-altsec-02 Thread-Index: AcpMD8QmeiJzAnpBR0qeBxmcCQL76AAGQKUM Message-ID: In-Reply-To: <20091013141337.CFCDA28C181@core3.amsl.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Oct 2009 17:15:29.0194 (UTC) FILETIME=[C344A8A0:01CA4C28] X-Nokia-AV: Clean Subject: [MEXT] FW: New Version Notification for draft-korhonen-mext-mip6-altsec-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: , X-List-Received-Date: Tue, 13 Oct 2009 17:15:45 -0000 FYI, ------ Forwarded Message A new version of I-D, draft-korhonen-mext-mip6-altsec-02.txt has been successfuly submitted by Jouni Korhonen and posted to the IETF repository. Filename: draft-korhonen-mext-mip6-altsec Revision: 02 Title: Security architecture for Mobile IPv6 using TLS Creation_date: 2009-10-13 WG ID: Independent Submission Number_of_pages: 36 Abstract: Mobile IPv6 signaling between the mobile node and home agent is secured using IPsec. The security association between a mobile node and the home agent is established using IKEv1 or IKEv2. The security model specified for Mobile IPv6 requires interaction between the Mobile IPv6 protocol module and the IKE/IPsec module of the IP stack. Implementation and deployment concerns exist with such a security architecture. This document proposes an alternate security framework, which relies on Transport Layer Security for establishing keying material and obtaining bootstrapping parameters required for protecting Mobile IPv6 signaling and data traffic between the mobile node and home agent. =20 The IETF Secretariat. ------ End of Forwarded Message From sgundave@cisco.com Tue Oct 13 18:27:08 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A7373A68D2 for ; Tue, 13 Oct 2009 18:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xo3dt++9g75 for ; Tue, 13 Oct 2009 18:27:07 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 27D333A68C1 for ; Tue, 13 Oct 2009 18:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=3356; q=dns/txt; s=sjiport06001; t=1255483629; x=1256693229; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Sri=20Gundavelli=20|Subject: =20Gateway=20Initiated=20Dual-stack=20lite=20Support |Date:=20Tue,=2013=20Oct=202009=2018:27:08=20-0700=20(PDT )|Message-ID:=20|To:=20mext@ietf.org|cc:=20Frank=20Brockner s=20|MIME-Version:=201.0; bh=V0wiJkNPXuQqS2CjQe8U2tW4myI3tODQ8rKNPiXrOVM=; b=gZJExRZKR+f8vCdElC9/MfCHkwmgwkFe5ro1ITK5K0bkdbyedO4yuSVR AThknOkKX+J0LQdG29uk8el5jRNUJh5Y5Esw468CDOqLgA2gdEZn7o1dd tPScyb319wGTo2MErMmi0weqYOvrUIehKIGc/hiqgULwhp3xbfdV7+OtI s=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,554,1249257600"; d="scan'208";a="408709342" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 14 Oct 2009 01:27:09 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9E1R9HN015361; Wed, 14 Oct 2009 01:27:09 GMT Date: Tue, 13 Oct 2009 18:27:08 -0700 (PDT) From: Sri Gundavelli To: mext@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Frank Brockners Subject: [MEXT] Gateway Initiated Dual-stack lite Support X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 01:27:08 -0000 We have posted a draft on using Gateway Initiated Dual-stack lite approach for IPv6 migration support. Following is the pointer to the draft. http://www.ietf.org/id/draft-gundavelli-softwire-gateway-init-ds-lite-00.txt The key aspect of this solution is the approach by which we are applying dual-stack lite solution to IP mobility architectures. In this gateway initiated dual-stack lite mode we are leveraging the mobile tunnel by extending it to the CGN, and by using a UE specific softwire for session identification. Please review and comment. Abstract Dual-Stack lite has been proposed as a IPv4 to IPv6 transition technology. Dual-stack lite allows a service provider to migrate his network to IPv6, while still offering IPv4 services to the end customer. The dual-stack lite solution uses an IPv4 over IPv6 tunnel between a host (or access device) and a dual-stack lite large scale NAT. Several existing network architectures (e.g. 3GPP, WiMAX, or PPP based broadband networks) already specify dual-stack deployment and leverage tunneling technology between the access device and an access gateway in the provider network. Applying the existing dual- stack lite concept to these networks will result in changes to the end-system and unnecessary tunneling overhead. This draft describes a modified implementation of dual-stack lite where existing access tunnels are extended beyond the access gateway to the dual-stack lite large scale NAT using softwires. This evolved approach applies to IPv4 as well as IPv6 networks. Regards ---------- Forwarded message ---------- Date: Tue, 13 Oct 2009 18:08:24 -0700 (PDT) From: IETF I-D Submission Tool To: sgundave@cisco.com Cc: fbrockne@cisco.com Subject: New Version Notification for draft-gundavelli-softwire-gateway-init-ds-lite-00 A new version of I-D, draft-gundavelli-softwire-gateway-init-ds-lite-00.txt has been successfuly submitted by Sri Gundavelli and posted to the IETF repository. Filename: draft-gundavelli-softwire-gateway-init-ds-lite Revision: 00 Title: Gateway Initiated Dual-Stack Lite Deployment Creation_date: 2009-10-13 WG ID: Independent Submission Number_of_pages: 21 Abstract: Dual-Stack lite has been proposed as a IPv4 to IPv6 transition technology. Dual-stack lite allows a service provider to migrate his network to IPv6, while still offering IPv4 services to the end customer. The dual-stack lite solution uses an IPv4 over IPv6 tunnel between a host (or access device) and a dual-stack lite large scale NAT. Several existing network architectures (e.g. 3GPP, WiMAX, or PPP based broadband networks) already specify dual-stack deployment and leverage tunneling technology between the access device and an access gateway in the provider network. Applying the existing dual- stack lite concept to these networks will result in changes to the end-system and unnecessary tunneling overhead. This draft describes a modified implementation of dual-stack lite where existing access tunnels are extended beyond the access gateway to the dual-stack lite large scale NAT using softwires. This evolved approach applies to IPv4 as well as IPv6 networks. The IETF Secretariat. From rdroms@cisco.com Sat Oct 17 05:26:45 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D38893A68A5 for ; Sat, 17 Oct 2009 05:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjtF2aO3z99W for ; Sat, 17 Oct 2009 05:26:45 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B3A6E3A677D for ; Sat, 17 Oct 2009 05:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=1066; q=dns/txt; s=rtpiport02001; t=1255782410; x=1256992010; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ralph=20Droms=20|Subject:=20Re :=20[MEXT]=20Gateway=20Initiated=20Dual-stack=20lite=20Su pport|Date:=20Sat,=2017=20Oct=202009=2008:26:38=20-0400 |Message-Id:=20|To:=20Sri=20Gundavelli=20|Cc: =20mext=20,=20Frank=20Brockners=20|Mime-Version:=201.0=20(Apple=20Message=20fra mework=20v936)|Content-Transfer-Encoding:=207bit |In-Reply-To:=20|References:=20; bh=j5ZXG4AHghYC83WKZ3TG2qeTwWE6RWk3tQGfZ8xmrJU=; b=RnOXs+IJ5ncXs8/cTRep3O216CTXzKMk/aWR+/EH9LVD/ZXeC2ttNx3B BnbBslfQ+9l7nIlsyk6G93ooVduPOO9gHf0s1g0YEjxMJqSmqrTQQTZcY avzXfr05pVifNhbVmLM39fxRXEKZO/o5d9qPGqgQTvs5aXsbq8yRj0HXR A=; Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,577,1249257600"; d="scan'208";a="63563773" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 17 Oct 2009 12:26:49 +0000 Received: from bxb-rdroms-8717.cisco.com (bxb-rdroms-8717.cisco.com [10.98.10.88]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9HCQhta021890; Sat, 17 Oct 2009 12:26:49 GMT Message-Id: From: Ralph Droms To: Sri Gundavelli In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 17 Oct 2009 08:26:38 -0400 References: X-Mailer: Apple Mail (2.936) Cc: Frank Brockners , mext Subject: Re: [MEXT] Gateway Initiated Dual-stack lite Support X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 12:26:45 -0000 Quick question about your draft... I understand about stitching the tunnels together in a gateway. In the case of DS-lite, there is a NAT function in the DSLTC as well as a tunnel concentrator function. Presumably, that NAT function appeared somewhere else in the scenarios you describe in the I-D. Where is that NAT function before the addition of DS-lite and how does DS-lite change the NAT function? - Ralph On Oct 13, 2009, at 9:27 PM 10/13/09, Sri Gundavelli wrote: > > We have posted a draft on using Gateway Initiated Dual-stack lite > approach for IPv6 migration support. Following is the pointer to > the draft. > > http://www.ietf.org/id/draft-gundavelli-softwire-gateway-init-ds-lite-00.txt > > The key aspect of this solution is the approach by which we are > applying > dual-stack lite solution to IP mobility architectures. In this gateway > initiated dual-stack lite mode we are leveraging the mobile tunnel > by extending it to the CGN, and by using a UE specific softwire for > session identification. From sgundave@cisco.com Sat Oct 17 07:06:54 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6F8428B56A for ; Sat, 17 Oct 2009 07:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jR8dJgrgsLOj for ; Sat, 17 Oct 2009 07:06:54 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 07B0428C0DB for ; Sat, 17 Oct 2009 07:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=3208; q=dns/txt; s=sjiport05001; t=1255788419; x=1256998019; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Sri=20Gundavelli=20|Subject: =20Re:=20[MEXT]=20Gateway=20Initiated=20Dual-stack=20lite =20Support|Date:=20Sat,=2017=20Oct=202009=2007:06:58=20-0 700=20(PDT)|Message-ID:=20|To:=20Ralph=20Droms=20|cc:=20mext=20,=20Frank=20Brockne rs=20|MIME-Version:=201.0 |In-Reply-To:=20|References:=20=0D=0A=20; bh=rsC0QJZFvwbS4l/sC0NBOJVSjrsOdeUXTmRSCvZhS/4=; b=Rz+IQjXl3Yx0TXfV8ub/La9sbAyj8dBc4OIOB0AtluPihlGwIxpPMdcZ 85AagQYGRd1eMhMuPj2rXziqh72bdUk4PV2ccWWop7DhR9AQX4+Ks3VFw E31V+QXMIzV+vlCgMnT9uKq1hBwgrvOaAZ88zIbR+7IHrpVD5d7NWs1mx M=; Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,577,1249257600"; d="scan'208";a="99348838" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 17 Oct 2009 14:06:59 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9HE6xba009777; Sat, 17 Oct 2009 14:06:59 GMT Date: Sat, 17 Oct 2009 07:06:58 -0700 (PDT) From: Sri Gundavelli To: Ralph Droms In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Frank Brockners , mext Subject: Re: [MEXT] Gateway Initiated Dual-stack lite Support X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 14:06:55 -0000 Hi Ralph, Thanks for the comment. Please see below. On Sat, 17 Oct 2009, Ralph Droms wrote: > Quick question about your draft... > > I understand about stitching the tunnels together in a gateway. In the case > of DS-lite, there is a NAT function in the DSLTC as well as a tunnel > concentrator function. Presumably, that NAT function appeared somewhere else > in the scenarios you describe in the I-D. Where is that NAT function before > the addition of DS-lite and how does DS-lite change the NAT function? > The application of DS-lite is not changing the placement of the NAT function. The NAT function is outside the anchor (HA/PDN), performing address translation on the MN's traffic, when overlapping addressing is in use. Now, if the home network and the access network are in seperate domains seperated by NAT (such as in RFC-3519, RFC-5555), the mobility tunnel may go through some translation, but that has no bearing on the MN's traffic and the placement of the NAT in the home network is still outside the anchor. The transport tunnel has little purpose in the the MN's addressing and translation context. Now, when we apply Dual-stack lite function to these architectures, based on any of the modes (GTP, MIPv6, or PMIPv6), we are making the anchor point (HA/LMA/PDN) perform the DS lite initiator function to the DSLTC (LSN), with no change in where the NAT is placed. We are building a unique softwire-id for each mobility session, but using a single tunnel between the anchor and the DSLTC, using GRE to identify the user flows. This is very close to the gateway mode that the DS-lite draft supports, except using GRE to identify the flows and mapping the access tunnel to the CGN tunnel. This approach results in: - Allocation of the same IP (overlapping addresses) to all MN's. Solves the issues for some operators who dont have enough RFC-1918 address space - No *changes* to MN (UE)'s host stack, requirement for some handset vendors - No bearing on the type of transport used for the mobility tunnel. Allows the operator to migrate their network in incremental steps, allowing IPv6-only or IPv4 transport network. - Just using NAT44 and we are not doing 4 to 6 translation and back 6 to 4, avoiding all those side affects of NAT464. - No additional overahead of the CGN tunnel in the access network or on the MN. Just one tunnel from the anchor to the LSN. - Minimal changes to anchor (HA/LMA/PDN). Regards Sri > - Ralph > > On Oct 13, 2009, at 9:27 PM 10/13/09, Sri Gundavelli wrote: > >> >> We have posted a draft on using Gateway Initiated Dual-stack lite approach >> for IPv6 migration support. Following is the pointer to >> the draft. >> >> http://www.ietf.org/id/draft-gundavelli-softwire-gateway-init-ds-lite-00.txt >> >> The key aspect of this solution is the approach by which we are applying >> dual-stack lite solution to IP mobility architectures. In this gateway >> initiated dual-stack lite mode we are leveraging the mobile tunnel >> by extending it to the CGN, and by using a UE specific softwire for >> session identification. > From tsirtsis@googlemail.com Mon Oct 19 01:45:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 904C928C0EA for ; Mon, 19 Oct 2009 01:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wETZc858aKDC for ; Mon, 19 Oct 2009 01:45:03 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 6FF433A67A3 for ; Mon, 19 Oct 2009 01:45:03 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so1773932fga.13 for ; Mon, 19 Oct 2009 01:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=HCqJN2Obo+GeY52uRi1Mee94OCeforZlgWuMYa4lvY4=; b=B5n1rSFiGc5qtWBId+f9X3widQGgOuqBqkcmhUnZkMkTimDHXPqoRFbaiIbD5JD8YV 93/ac+uajI1oLExM0CUdG29TC8jueuqV2h84P1fAwizZ0BJqDW3iiabCykPN/lvmzw9h 22FuOH+ZHTO9cEZVCKfGFAf76mcFV2dzQIfWk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VbY/5yjj6G8Bv9CpYN29aBC3JtWclT777t5wiPj6/fgFLVHJhDFdjYn5rNrmMhIfVo 0Kziw/rE2W9l0Qq8Ig1PZ4BePIxFmcT5C5Ezo3+a9eX8nOIqsuaDl+mRLHiUzXuwh2ow IeaHHQXoY5MDRjTO9HSO3S9eeoMdbPGi8VtYE= MIME-Version: 1.0 Received: by 10.239.139.39 with SMTP id r39mr366647hbr.116.1255941904094; Mon, 19 Oct 2009 01:45:04 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Oct 2009 09:45:04 +0100 Message-ID: From: George Tsirtsis To: "Laganier, Julien" Content-Type: text/plain; charset=UTF-8 Cc: "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 08:45:04 -0000 Hi folks, Just to apologize for the delay in dealing with the comments so far. We are in the process of reviewing all of them and we will be back with you soon with responses. Regards George On Wed, Oct 7, 2009 at 12:30 AM, Laganier, Julien wrote: > Folks, > > Hereby we're starting a two weeks WGLC on our "Flow Bindings in Mobile IPv6 and NEMO Basic Support" document, available at the following URL: > > > > Please review the specification, post your comments to the mailing list, and state whether or not you think the document is ready to be forwarded to IESG before 2009-10-20 6:00PM PST. > > Thank you for your support. > > --julien & marcelo, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From conny.larsson@ericsson.com Mon Oct 19 13:25:01 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49A783A67B0 for ; Mon, 19 Oct 2009 13:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.828 X-Spam-Level: X-Spam-Status: No, score=-4.828 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqrwEh4z+QXo for ; Mon, 19 Oct 2009 13:25:00 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id A555E3A6816 for ; Mon, 19 Oct 2009 13:24:59 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-63-4adccb2123bd Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 74.E0.08816.12BCCDA4; Mon, 19 Oct 2009 22:25:05 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 22:25:05 +0200 Received: from [127.0.0.1] ([147.214.130.137]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 22:25:04 +0200 Message-ID: <4ADCCB1D.2020705@ericsson.com> Date: Mon, 19 Oct 2009 22:25:01 +0200 From: Conny Larsson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Laganier, Julien" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030402050908020006010909" X-OriginalArrivalTime: 19 Oct 2009 20:25:04.0301 (UTC) FILETIME=[3DD6BDD0:01CA50FA] X-Brightmail-Tracker: AAAAAA== Cc: "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 20:25:01 -0000 This is a multi-part message in MIME format. --------------030402050908020006010909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Comments (a detailed review will be done when the draft has been updated) There has been a lengthy discussion on the mailing list regarding support for bidirectional transfer of flow descriptors. A number of arguments have been stated both in favor of bidirectional transfer and against it. I'm in favor of adding support for bidirectional transfer and believe it should be added according to what has previously been agreed in the WG charter. There has also been a discussion about support for binary and ASCII flow descriptors. The draft is currently written only to fit the binary format. I see no reason for this approach. The draft could easily be changed to fit both formats. I see no reason for draft-ietf-mext-flow-binding-03 to be forwarded to IESG before the above issues have been fixed. Regards Conny Laganier, Julien wrote: > Folks, > > Hereby we're starting a two weeks WGLC on our "Flow Bindings in Mobile IPv6 and NEMO Basic Support" document, available at the following URL: > > > > Please review the specification, post your comments to the mailing list, and state whether or not you think the document is ready to be forwarded to IESG before 2009-10-20 6:00PM PST. > > Thank you for your support. > > --julien & marcelo, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > -- line *CONNY LARSSON M.Sc.* * Senior Research Engineer* Ericsson AB Ericsson Research, Packet Technologies Isafjordsgatan 14E SE-164 80 Stockholm, Sweden Phone +46 10 714 8458 SMS/MMS +46 70 267 3556 Conny.Larsson@ericsson.com www.ericsson.com Ericsson --------------030402050908020006010909 Content-Type: multipart/related; boundary="------------000107020205060608070707" --------------000107020205060608070707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

Comments (a detailed review will be done when the draft has been updated)

There has been a lengthy discussion on the mailing list regarding support for bidirectional transfer of flow descriptors. A number of arguments have been stated both in favor of bidirectional transfer and against it. I'm in favor of adding support for bidirectional transfer and believe it should be added according to what has previously been agreed in the WG charter.

There has also been a discussion about support for binary and ASCII flow descriptors. The draft is currently written only to fit the binary format. I see no reason for this approach. The draft could easily be changed to fit both formats.

I see no reason for draft-ietf-mext-flow-binding-03 to be forwarded to IESG before the above issues have been fixed.

Regards
Conny

Laganier, Julien wrote: 
Folks,

Hereby we're starting a two weeks WGLC on our "Flow Bindings in Mobile IPv6 and NEMO Basic Support" document, available at the following URL:

<http://tools.ietf.org/html/draft-ietf-mext-flow-binding-03>

Please review the specification, post your comments to the mailing list, and state whether or not you think the document is ready to be forwarded to IESG before 2009-10-20 6:00PM PST.
 
Thank you for your support.
 
--julien & marcelo, MEXT chairs
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext

--
Ericsson Signature


line

CONNY LARSSON M.Sc.
Senior Research Engineer


Ericsson AB
Ericsson Research, Packet Technologies
Isafjordsgatan 14E
SE-164 80 Stockholm, Sweden
Phone +46 10 714 8458
SMS/MMS +46 70 267 3556
Conny.Larsson@ericsson.com
www.ericsson.com



Ericsson

--------------000107020205060608070707 Content-Type: image/gif; name="Email_line.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Email_line.gif" R0lGODlh/wADAPcAABUpeBUoeBQse1WrIWCvHQCDrwCOUhQtewCLcRMvfACMZQCEoxiYOzqi LQCNXwCMZp0MXEYdbQCHkkAfbjyjLAhhnwdlojAicgCNWgCGlQCOVQRvqQRxqgCIhg9BiQZo pFYaag6UP8YEU3C0FrYHVwtUln4SYgCGlxI1gHUUZACKeCmdNFsZaYgRYACQR8MFVIQRYRE3 gqcKWpoNXACFnnIVZGsWZi0ichomdghenQN1rQhgngCHjg5HjQ9AiHa2ExE6hDkgcACIiUwc bDShL7kHVg9Dijwfb3gUY4y9CgpXmF8ZaACOWGuyGFCqI2OwG24WZZS/BkqoJgCJewCDrE2p JQtTlQCHiyyeMyEldVutHwCMaBA8hRA/hxyZOdUBUMwDUqoKWQCFmwF8sgF+swCNYaQLWgCE qgCCtgCEpwCFnACJfwCKdgCLbWgXZgCPTCojcwCFoBQqeSQkdAldnAJ6sAN0rFkaaQxNkQlb mwCHjQ1Kjw5GjACLaz+kKgCQSRE5g7MIVwVtp4S6DZrBBAdjoKAMWzGgMM8OWl2uHgGQRQOR RHO1FHsTYxaXPJEPXo++CYe7DACPSkkdbU8ca7AJWGixGQN3rgVrphcndwZqpWawGgdkoWIY aAZno5K/CC+fMY0PXwCHkAxQkwCKegCIhLwGVQCPUCGbNzeiLgiTQgCNXCScNhCVPhOWPX64 EJzCA2UXZ0SmKBA9hlKqIgxOkh6aONICUVIba88CUSecNRMwfq0JWACCs3m3EgCGmQCJgACI gpfABRI2gQCMY78GVVisIACEqIG5DwCCtQ5EiwCEpYESYQF/tACBtQCJfZQOXQCKdEinJ4m8 CwCLbwpWl0KlKQCOVwCPTjMhcYoQX0MebgtRlB0ldZcOXQVuqCckdACFogCGkwCDsQJ7sQCK cgWSQwRyqw1MkG6zFzcgcAlamgCDrgCIh3y4EQ1JjhMyfhIzfwJ4rwCLagCNXgCOUwpYmQuU QLPPN+Drqp/DAtXkjK/NLLHOK/Ccu////yH5BAAAAAAALAAAAAD/AAMAAAj/AP/9y8cPFiFh UT5BSjIt0iBkr9z5+sFoRLomljY9IZBIi7EBtJxUkSJNljU/FBqkInIIFJYVulihsuWFgSNX rULcU2VukSIXfyS9wXbKQD0N15hgWEXPQRliCh5smdenDTUE5aKxUUFqyrM1wIKV6tBOyBU9 PERJEJfhxC8xamjECbdgWZpjZ6iwKzCuVzI0zpqRGUOujrxLOuyc47DhmyBMmj54ssCpUIUd OejkWWdPSbUSVriNqoUH3Z53PfgoM+LBR5dZXIAAijEMRTx4uxIcECAHQIBMOLplmQMOzo0L 2dQFOTJhW4RJQyjhAnGHxZJOsdzYgFIjBZJGJpjB/2ihLdQjaN5mQDBkRkYYXpUCkShiqtgL ESLA5Lp1y59Agf3oYxBCCjHkEEQSUWQRRhpx5BFIIpFkEkoqseQSTDLRZBNOOvHkE1BCEWUU Ukox5RRUUlFlFVZaceUVWGKRZRZaarHlFlxy0WUXXnrx5RdgghFmGGKKMeYYZJJRZhlmmnHm GWiikWYaaqqx5hpsstFmG2668eYbcMIRZxxyyjHnHHTSUWcddtpx5x144pFnHnrqsecefPLR Zx9++t3yBSL//bMPPgMmtFBDD0U0UUUXZbRRRx+FNFJJJ6W0UksvxTRTTTfltFNPPwU1VFFH JbVUU09FNVVVV2W1VVdfhWY1VllnpbVWW2/FNVddd+W1V19/BTZYYYcltlhjj0U2WWWXZbZZ Z5+FNlppp6W2WmuvxTZbbbfltltvvwU3XHHHJbdcc89FN11112W3XXffhTdeeeelt15778U3 X3335bffF/79ExAAOw== --------------000107020205060608070707 Content-Type: image/gif; name="Email.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Email.gif" R0lGODlhZQB7APcAAAAAQgAASgAAUgAIUgApWggIWggQWhAQWhAQYxAYWhAYYxgYYxghYyEh aykpaykpcykxczExczE5czE5ezk5ezlCe0JCe0JChEJKe0JKhEpKhEpShEpSjFJShFJSjFJa jFpajFpalFpjlGNjlGNrlGNrnGtrnGtznHNznHNzpXN7pXt7pXuEpXuErYSErYSMrYyMrYyM tYyUtZSUtZSUvZSctZScvZycvZylvaWlvaWlxqWtxq2txq2tzq21zrW1zrW9zr29zr291r3G 1sbG1sbG3sbO3s7O3tbW3tbW59be597e597e797n7+fn7+fv9+/v7+/v9+/39/f39/f3//f/ //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////ywAAAAAZQB7AAAI/gBBEBhIsKDBgwgTKlzIsKHD hBY0PJxIsaLFiw84XNzIsWNFCBs8ihxJkgAEjSVTqnwIcqXLlwdPwpz5siXNmyVl4tzp0SbP nxZ1Ah3KMiTRiRNaFDmiA2VNp0cXmhBCxYpVK1RcwPQZ9WAIHUyuirUyxcPTrgYz0Dgytq2V HTWNdo2Q4khVt22RnI1qQkcUvICJxCXqASzgw1Zi7N1JwUWSu4jxJtkqd2YEFVQjH64ihMJW qC5D9HCi+bCTGx9oclVJwUhpwFB8jNgpdGWS122nEGkR4efqki5wi00yIwPR2il/CHeSw2zC Bzd/k1Su2cmQEwpLjI5yROvnlzQi/hNh4Rnh1yVtdVB+GeGvWyczJCKkEOMxYOwukacMgf7q EtkJTZBCZoj9MBhME7jAgw4o9IaQdqSVNll+oP3EAQ1hCRfEgT81dptwV6WwGE4p/OAeiFYZ yOFMokWIolVOKPYdTPRl+KIVUABhQnSVqRTCEzdaRYQLFdBWIUkTnAjiEjNcAJR0I4UHohM+ CHTckSNRV1oUP5zg4EEeiODkTFCKpCViSRCZEAc3MFEVlxDMuFJwhy2Bg3MHXbCCfWMdsd5L bLXlBA+zIfTAgFMc5t1K+pU0ARFX6baCBAmJ1h9iguXX40ocuLBCkQhpQIMTkEU2IaNY3kSB UijysOJO/iW6CGIII9JUmKwowvDnTBzEEOiNUPxQaK0qmVBEqSge8SmPMMWArHBN3CAfTo2O 5EEVLzLBgwhDlemRDiBSQQQKlF75khCvTZEmqFF521EPmi2RQ6pP0ttRCYdFwcOOaBnkbkc8 5EaECl/2W1C1JNGwxBRRIGHDmAYj9G9PGhgX8UIIX8zTxBqTaW/Hqm0K8sYfj/yqyUai3K3I Knvcsm8sv0zhQin00MMOPehgsw0DxZDzzT3cQOtALtgMMX1FJMGEEDTESUCJSTTB1AQDiaZ0 Ej049ZXSRdzA7go2Zz3QAzargHHMBMDbVhS9fTjWDAMVYZWVKyhpVWpqi+Wk/pRiiUgA31dF UcJAWvpJwAXYqphQxuBagYQOO/DAww1xY3WDC0NcRTW6VqQ2wl1HoFACC0JE4IFVS6QAwgk3 NGBBVVC4AAIJNxhnwlUzjACEVVNQnbcVs1VQlasKedv4CgAcJPcUDAzUX0icmxWoDwetYJUP AwAQQAEDnGDVEQkkT5DcVlA+UKBw+yCWnxNYRfzi9DYurAkmpJAaActbsAAHUOA4EOcbmADs ylMQfJGFB+QagAA8kCgrCGFZBJgAaaZgAYKoQEhpIwtpqDACBwzvbAtpXJ8qZ4UlKOEvS7gf 5zTwAavoBSGcg9EMDmCAHYgFCuq5wF+UUJALwIgA/gFzQgvQQ4QMJOp9Eosf76IABSYKYSCu GUsRCLLC0zlOIY5poBVgIIAEqOAIWqQBBfq3hIJoAHVAJIsFYmCVGvwFiTFBW+NuEAEJUIAC TlseCkbQH34BEAKJmoLFEuIBSFmBCAZQ4AIwQJ0kYOA2giSI9Q6ZQSpIJFFROCLGlGgFFiBk eRAAAAus8kQCRI8AQfgeAQ8CgBEISQENMEAAAFCBH1InBwT5kFbgVRYCzEAscPSXHGF0hGIm QQhxYssUPBOBRFHBM5nrHAEy4J5g3aAHScjABZjwgxjMoD8xaMARhhADGHwICARgoFV68EU0 EkB9vYSAi4J5MHr9Tiye/vkQqDgHN/JZyQO/ugoIOtAWwdRyLEigGgFOgKts/u9uRLsKOouH thC4gAUXzajZCGCCixLkAi5wweBG4IIWlGsgI7jBEIjQA++sgAdDEMK+CJKCHKyUBxslCAVe EAQi8MBvVbvol1YQUivBT2a0QRtSc1KypfZEqU4VScaiKlWoUpUjU70qVq2q1aA0tasU4RhY J5LVsYaVq2Z1SFnTqla0snWTb61qXHvy1blKzK129Vdd83owvPJ1IGv9a18F+5G9ClashDWJ Yf+KWMIGNrGNPexi+RpZxk42r5Wl7GXtmlnMbnauneXsZ+MaWtCO9q2lJe1p2Zpa1Pr1rw8I AggAADs= --------------000107020205060608070707-- --------------030402050908020006010909-- From charliep@computer.org Mon Oct 19 13:32:29 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E5DD28C0F5 for ; Mon, 19 Oct 2009 13:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNu+M9l+cd20 for ; Mon, 19 Oct 2009 13:32:28 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id ADB233A67B0 for ; Mon, 19 Oct 2009 13:32:28 -0700 (PDT) Received: from [12.204.153.98] (helo=[10.166.254.13]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MzyuB-00038V-Pg for mext@ietf.org; Mon, 19 Oct 2009 16:32:35 -0400 Message-ID: <4ADCCCE3.1010506@computer.org> Date: Mon, 19 Oct 2009 13:32:35 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5209fb6d1c3fef9d464f127174c8e2d4ce350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Subject: [MEXT] [Fwd: New Version Notification for draft-perkins-mext-4283mnids-00] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 20:32:29 -0000 Hello folks, This is a very simple draft, but could make a significant difference in ease of standardization. Anyway it would avoid the need to shoehorn every possible type of identifier into a new substructure for the MN-NAI. Any comments will be appreciated. Regards, Charlie P. -------- Original Message -------- Subject: New Version Notification for draft-perkins-mext-4283mnids-00 Date: Mon, 19 Oct 2009 13:20:49 -0700 (PDT) From: IETF I-D Submission Tool To: charliep@computer.org CC: vijay@wichorus.com A new version of I-D, draft-perkins-mext-4283mnids-00.txt has been successfuly submitted by Charles Perkins and posted to the IETF repository. Filename: draft-perkins-mext-4283mnids Revision: 00 Title: MN Identifier Types for RFC 4283 Mobile Node Identifier Option Creation_date: 2009-10-19 WG ID: Independent Submission Number_of_pages: 8 Abstract: Additional Identifier Types are proposed for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283). The IETF Secretariat. From hesham@elevatemobile.com Mon Oct 19 16:49:56 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F0383A695C for ; Mon, 19 Oct 2009 16:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPtj8UkU3dGq for ; Mon, 19 Oct 2009 16:49:55 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 5F11028C136 for ; Mon, 19 Oct 2009 16:49:54 -0700 (PDT) Received: from [203.219.211.243] (helo=[192.168.0.2]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1N01z9-0005nn-Bs; Tue, 20 Oct 2009 10:49:55 +1100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 20 Oct 2009 10:49:46 +1100 From: Hesham Soliman To: Conny Larsson , "Laganier, Julien" Message-ID: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpRFtZN18TuGcTvbE6zdSGmg44uwQ== In-Reply-To: <4ADCCB1D.2020705@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 23:49:56 -0000 Hi Conny, We need the comments now, not after the document is updated :). This is WGLC and we're updating the document as a result of reviews. The bidirectionality issue was discussed and it was decided that there is no case for it. This was sent to the list by the chairs. So we won't be adding this to the draft. Hesham On 20/10/09 7:25 AM, "Conny Larsson" wrote: > Hi, > > Comments (a detailed review will be done when the draft has been updated) > > There has been a lengthy discussion on the mailing list regarding > support for bidirectional transfer of flow descriptors. A number of > arguments have been stated both in favor of bidirectional transfer and > against it. I'm in favor of adding support for bidirectional transfer > and believe it should be added according to what has previously been > agreed in the WG charter. > > There has also been a discussion about support for binary and ASCII flow > descriptors. The draft is currently written only to fit the binary > format. I see no reason for this approach. The draft could easily be > changed to fit both formats. > > I see no reason for draft-ietf-mext-flow-binding-03 to be forwarded to > IESG before the above issues have been fixed. > > Regards > Conny > > Laganier, Julien wrote: >> Folks, >> >> Hereby we're starting a two weeks WGLC on our "Flow Bindings in Mobile IPv6 >> and NEMO Basic Support" document, available at the following URL: >> >> >> >> Please review the specification, post your comments to the mailing list, and >> state whether or not you think the document is ready to be forwarded to IESG >> before 2009-10-20 6:00PM PST. >> >> Thank you for your support. >> >> --julien & marcelo, MEXT chairs >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> From yuri.ismailov@ericsson.com Tue Oct 20 00:55:09 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27B793A6782 for ; Tue, 20 Oct 2009 00:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yr6sBsNOPXzZ for ; Tue, 20 Oct 2009 00:55:08 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 46F4C3A6767 for ; Tue, 20 Oct 2009 00:55:04 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-e4-4add6cdb4769 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id E1.07.04191.BDC6DDA4; Tue, 20 Oct 2009 09:55:07 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 09:55:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA515A.A0F957A9" Date: Tue, 20 Oct 2009 09:55:01 +0200 Message-ID: In-Reply-To: <4ADCCB1D.2020705@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpQ+kKhiHtqC6MjQ42xDThQzig4rgAW+xuw References: <4ADCCB1D.2020705@ericsson.com> From: "Yuri Ismailov" To: "Laganier, Julien" X-OriginalArrivalTime: 20 Oct 2009 07:55:02.0826 (UTC) FILETIME=[A14858A0:01CA515A] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 07:55:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA515A.A0F957A9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, after re-reading the draft come up with the comment on "Discard" action in "Flow Identification Mobility Option" I suggest either to extend the paragraph in the section 4.2 or add a separate subsection clarifying behavior of MN and HA before and after the "Discard" action was issued by MN. =20 Below are the issues which are proposed to be addressed in the text. =20 1.The case when installed FID represent ranges of port numbers and IP addresses. If MN decides to discard a particular flow within the range then before that a correspondent FID should be installed in the HA. Otherwise "136 FID not found" will be returned from HA. =20 2. Specify the time interval for how long time the "Discard" state will be active in HA. This is necessary because there is no "un-discard" message sent from MN. =20 3. Add a disclaimer that for some protocols, like TCP, "Discard" action may lead to hanging up the connection at CN and should be used responsibly. =20 =20 Regards Yuri =20 ------_=_NextPart_001_01CA515A.A0F957A9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ericsson Signature
Hi,
after re-reading the draft come up with the = comment on=20 "Discard" action in "Flow = Identification=20 Mobility Option"
I suggest either to extend the paragraph = in the=20 section 4.2 or add a separate subsection clarifying behavior of MN and = HA before=20 and after the "Discard" action was issued by=20 MN.
 
Below are the issues which are proposed to be = addressed=20 in the text.
 
1.The case when installed FID represent ranges of port = numbers and=20 IP addresses. If MN decides to discard a particular flow within the = range then=20 before that a correspondent FID should be installed in the HA. = Otherwise =20 "136 FID not found" will be returned from=20 HA.
 
2. Specify the time interval for how long time the = "Discard" state=20 will be active in HA. This is necessary because there is no = "un-discard"=20 message sent from MN.
 
3. Add=20 a disclaimer that for some protocols, like TCP, "Discard" action may = lead to=20 hanging up the connection at CN and should be used=20 responsibly.
 
 
Regards
Yuri
 

 ------_=_NextPart_001_01CA515A.A0F957A9-- From behcetsarikaya@yahoo.com Tue Oct 20 08:11:07 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFB563A6844 for ; Tue, 20 Oct 2009 08:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.058 X-Spam-Level: X-Spam-Status: No, score=-1.058 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, 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 QzoG7nGw1Kmn for ; Tue, 20 Oct 2009 08:11:07 -0700 (PDT) Received: from web111407.mail.gq1.yahoo.com (web111407.mail.gq1.yahoo.com [67.195.15.168]) by core3.amsl.com (Postfix) with SMTP id 276373A67BD for ; Tue, 20 Oct 2009 08:11:07 -0700 (PDT) Received: (qmail 91747 invoked by uid 60001); 20 Oct 2009 15:11:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1256051473; bh=ABpB0E9DVrGOogXfJXGS1ZCod7rN2UQvkyRFykXa//Y=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Eab70BmcaAhlb69nLcEVssCxKRLO7uD8c/VoO2GE96YKT7piSVcGhnBoAt9wTTJUsDA36a3Ln34Hvv4w3snWvfMCeKhOTYrGIzCzexumkE8Mv6istT9ptIVQE3zuqqq8lNnaW1DJ1Gp61P99+KalTiZm0Oc88an+KWGslmK5/0U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UaRxe7e1bm+pNDvC2aUCKE9tK0UK2CveGcXqiyr/PJ3LfGg3OgrAY8oWMs/aaRQZJ4PVnLGaEbXTix5S5oFAuG0rV3DxY4fW32kgL2Vlw1cpPkgHdezA9nwvjZ/0VDbUz6Y1o+XfPLapqPHaXrt6UhbBKZ3OBc1veYXwoVoTHl0=; Message-ID: <346103.90889.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: CjNAB10VM1m4Zs_t.9FiFfe8ebycHfUg4HVS9jfwLdc3y33InRXt7cw05X8lNNH3Dy9DaFyIIC2aTb51F4Pr4Fs0eF3rNAbT3wX6_uZYRyZK9gqHhf5v_4E.btLSeD56o5fnC9XsnBgtOaq2Fgz87uKroJOgYL.EXWH3Ff_XMjgukPZMlV1xnJfeRHHwb8kB8D_vHkPwFiW87U270uFfTYMxNDea_bmPbDyGjo6i2fKpeB1hziU9tuOBE9Rw3Gw3zKKoVgVnlG4QgEvb3J3UsWnc8be.yZX6hKexH24HAB8uzQxVCaCfuuVQbRv9TasfOVspVsMKledHQY40jS9Gq4tjgBLgFgTXnxgF7XxBM0DrCA-- Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Tue, 20 Oct 2009 08:11:13 PDT X-Mailer: YahooMailRC/182.10 YahooMailWebService/0.7.361.3 References: Date: Tue, 20 Oct 2009 08:11:13 -0700 (PDT) From: Behcet Sarikaya To: Hesham Soliman , Conny Larsson , "Laganier, Julien" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 15:11:08 -0000 Hi Conny, Hesham,=0A=0A=0A=0A----- Original Message ----=0A> From: Hesham S= oliman =0A> To: Conny Larsson ; "Laganier, Julien" =0A> Cc: "mext@ietf.org= " =0A> Sent: Mon, October 19, 2009 6:49:46 PM=0A> Subject: R= e: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03=0A> =0A> Hi Conny, =0A> = =0A> We need the comments now, not after the document is updated :). This i= s WGLC=0A> and we're updating the document as a result of reviews.=0A> =0A>= The bidirectionality issue was discussed and it was decided that there is = no=0A> case for it. =0A=0AI don't think this reflects the situation.=0A=0AT= he right answer is that flow revocation and possibly other flow binding ope= rations initiated by HA=A0will be taken up as part of=A0MEXT rechartering.= =0A=0ABTW we revised our draft, here is the link to the revised draft:=0A= =0Ahttp://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-01.txt=0A= =0A=0ARegards,=0A=0ABehcet=0A=0A=0A From julienl@qualcomm.com Tue Oct 20 09:08:33 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2736828C134 for ; Tue, 20 Oct 2009 09:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.688 X-Spam-Level: X-Spam-Status: No, score=-105.688 tagged_above=-999 required=5 tests=[AWL=0.911, 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 J+1u-2CMsVVn for ; Tue, 20 Oct 2009 09:08:32 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id E7F6928C0F8 for ; Tue, 20 Oct 2009 09:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1256054920; x=1287590920; 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"Laganier,=20Julien"=20 |To:=20"charliep@computer.org"=20, =20mext=20|Date:=20Tue,=2020=20Oct=202009 =2009:08:25=20-0700|Subject:=20RE:=20[MEXT]=20[Fwd:=20New =20Version=20Notification=20for=0D=0A=09draft-perkins-mex t-4283mnids-00]|Thread-Topic:=20[MEXT]=20[Fwd:=20New=20Ve rsion=20Notification=20for=0D=0A=09draft-perkins-mext-428 3mnids-00]|Thread-Index:=20AcpQ/FbOVpO8hMLSQieK37EexhL/vQ Alj+YA|Message-ID:=20|References:=20<4ADCC CE3.1010506@computer.org>|In-Reply-To:=20<4ADCCCE3.101050 6@computer.org>|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,5777"=3B=20a=3D"25670756"; bh=yGqnh4cR7PwS23C9yAYkQBLYtX08rCTCsoW7I2Ph47g=; b=uhzKQ0Qn85F4Q5QVUBXMztCWxywmpqN4x91H7DQVXZItq/ut/UEjM8rc B4YEgv8OQ8ScJLwxTWgGKUvxWzDNQgRzTB71Uw23tMHxQhuhSMzG6cK+W xO5LD3tsypdu9EbWHNd4qGr98Ok0vwaH3AMjGe0iwBqxE1BlBELDPgsih g=; X-IronPort-AV: E=McAfee;i="5300,2777,5777"; a="25670756" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Oct 2009 09:08:28 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9KG8R2N015026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Oct 2009 09:08:28 -0700 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 n9KG8RSa030268 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 20 Oct 2009 09:08:27 -0700 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 20 Oct 2009 09:08:26 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Tue, 20 Oct 2009 09:08:27 -0700 From: "Laganier, Julien" To: "charliep@computer.org" , mext Date: Tue, 20 Oct 2009 09:08:25 -0700 Thread-Topic: [MEXT] [Fwd: New Version Notification for draft-perkins-mext-4283mnids-00] Thread-Index: AcpQ/FbOVpO8hMLSQieK37EexhL/vQAlj+YA Message-ID: References: <4ADCCCE3.1010506@computer.org> In-Reply-To: <4ADCCCE3.1010506@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MEXT] [Fwd: New Version Notification for draft-perkins-mext-4283mnids-00] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 16:08:33 -0000 Hello Charlie, Two comments on this draft: I'm wondering how useful it is to reserve a MNID type to encode a 3GPP IMSI= [1] given that EAP-AKA [RFC4187] and the 3GPP Numbering, addressing and id= entification specification [TS23.003] already define means of encoding the = IMSI as an NAI. Also, w.r.t. P-TMSI and GUTI, 1) it's unclear to me whether these identifie= rs are going to be used to identify a MN with its HA or LMA, and 2) if it's= going to be used, why not let 3GPP define in [TS23.003] their own mapping = of P-TMSI, GUTI, or whatever identifier they're using, into a NAI? Best, --julien [RFC4187] Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA) [TS23.003] 3rd Generation Partnership Project, "3GPP Technical Specification 23.003: Technical Specification Group Core Network and Terminals; Numbering, addressing and identification" Charles E. Perkins wrote: > =20 > Hello folks, >=20 > This is a very simple draft, but could make a significant > difference in ease of standardization. Anyway it would > avoid the need to shoehorn every possible type of identifier > into a new substructure for the MN-NAI. >=20 > Any comments will be appreciated. >=20 > Regards, > Charlie P. >=20 >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for draft-perkins-mext-4283mnids-00 > Date: Mon, 19 Oct 2009 13:20:49 -0700 (PDT) > From: IETF I-D Submission Tool > To: charliep@computer.org > CC: vijay@wichorus.com >=20 >=20 > A new version of I-D, draft-perkins-mext-4283mnids-00.txt has been > successfuly submitted by Charles Perkins and posted to the IETF > repository. >=20 > Filename: draft-perkins-mext-4283mnids > Revision: 00 > Title: MN Identifier Types for RFC 4283 Mobile Node > Identifier Option > Creation_date: 2009-10-19 > WG ID: Independent Submission > Number_of_pages: 8 >=20 > Abstract: > Additional Identifier Types are proposed for use with the Mobile Node > Identifier Option for MIPv6 (RFC 4283). >=20 >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From charliep@computer.org Tue Oct 20 09:34:44 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C12128C141 for ; Tue, 20 Oct 2009 09:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcjRtOrFPoVm for ; Tue, 20 Oct 2009 09:34:43 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 886523A69A5 for ; Tue, 20 Oct 2009 09:34:43 -0700 (PDT) Received: from [12.204.153.98] (helo=[10.166.254.153]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N0Hff-0004Sk-EY; Tue, 20 Oct 2009 12:34:51 -0400 Message-ID: <4ADDE6AB.9000301@computer.org> Date: Tue, 20 Oct 2009 09:34:51 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Laganier, Julien" References: <4ADCCCE3.1010506@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f529be86eba1aadb2c486c84b54597c3a65350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: mext Subject: Re: [MEXT] [Fwd: New Version Notification for draft-perkins-mext-4283mnids-00] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 16:34:44 -0000 Hello Julien, Your comment actually applies to every type of identifier. Even MAC addresses could be written as NAIs: AB_CD_EF_00_11_22@ieeeMACaddresses.org Or: MAC_ADDRESS_AB_CD_EF_00_11_22@HomeAgent.org depending on preferneces for AAA administration. I'd give 5 to 1 odds that the use of NAI as you mentioned by 3GPP and others was predicated on the restriction that it was the only choice available. It seems to me that, going into the future, we can do better. And there is absolutely no pressure evident today on the MNID type registry. Nearer term, I think the availability of appropriate MNID types might be valuable for the work that is ongoing for an alternate security mechanism for MIPv6. Regards, Charlie P. Laganier, Julien wrote: > Hello Charlie, > > Two comments on this draft: > > I'm wondering how useful it is to reserve a MNID type to encode a 3GPP IMSI [1] given that EAP-AKA [RFC4187] and the 3GPP Numbering, addressing and identification specification [TS23.003] already define means of encoding the IMSI as an NAI. > > Also, w.r.t. P-TMSI and GUTI, 1) it's unclear to me whether these identifiers are going to be used to identify a MN with its HA or LMA, and 2) if it's going to be used, why not let 3GPP define in [TS23.003] their own mapping of P-TMSI, GUTI, or whatever identifier they're using, into a NAI? > > Best, > > --julien > > [RFC4187] Extensible Authentication Protocol Method for 3rd Generation > Authentication and Key Agreement (EAP-AKA) > [TS23.003] 3rd Generation Partnership Project, "3GPP Technical > Specification 23.003: Technical Specification Group Core > Network and Terminals; Numbering, addressing and identification" > > Charles E. Perkins wrote: >> >> Hello folks, >> >> This is a very simple draft, but could make a significant >> difference in ease of standardization. Anyway it would >> avoid the need to shoehorn every possible type of identifier >> into a new substructure for the MN-NAI. >> >> Any comments will be appreciated. >> >> Regards, >> Charlie P. >> >> >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-perkins-mext-4283mnids-00 >> Date: Mon, 19 Oct 2009 13:20:49 -0700 (PDT) >> From: IETF I-D Submission Tool >> To: charliep@computer.org >> CC: vijay@wichorus.com >> >> >> A new version of I-D, draft-perkins-mext-4283mnids-00.txt has been >> successfuly submitted by Charles Perkins and posted to the IETF >> repository. >> >> Filename: draft-perkins-mext-4283mnids >> Revision: 00 >> Title: MN Identifier Types for RFC 4283 Mobile Node >> Identifier Option >> Creation_date: 2009-10-19 >> WG ID: Independent Submission >> Number_of_pages: 8 >> >> Abstract: >> Additional Identifier Types are proposed for use with the Mobile Node >> Identifier Option for MIPv6 (RFC 4283). >> >> >> >> >> The IETF Secretariat. >> >> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From julienl@qualcomm.com Tue Oct 20 09:45:40 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4C7C3A68E4 for ; Tue, 20 Oct 2009 09:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.673 X-Spam-Level: X-Spam-Status: No, score=-105.673 tagged_above=-999 required=5 tests=[AWL=0.926, 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 7E+Euo8LmrZx for ; Tue, 20 Oct 2009 09:45:39 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 835333A67FA for ; Tue, 20 Oct 2009 09:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1256057147; x=1287593147; 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"Laganier,=20Julien"=20 |To:=20"charliep@computer.org"=20 |CC:=20mext=20|Date:=20Tue,=2020=20Oct=202 009=2009:45:42=20-0700|Subject:=20RE:=20[MEXT]=20[Fwd:=20 New=20Version=09Notification=09for=0D=0A=09draft-perkins- mext-4283mnids-00]|Thread-Topic:=20[MEXT]=20[Fwd:=20New =20Version=09Notification=09for=0D=0A=09draft-perkins-mex t-4283mnids-00]|Thread-Index:=20AcpRo0m1fOv30TRxRTeyL3dv+ REZLQAAHNag|Message-ID:=20|References:=20< 4ADCCCE3.1010506@computer.org>=0D=0A=09=0D =0A=20<4ADDE6AB.9000301@computer.org>|In-Reply-To:=20<4AD DE6AB.9000301@computer.org>|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,5777"=3B=20a=3D"25673518"; bh=ADMwG8z94jBeEuipg0N+Sx+06cXXiDw32mueoPj8qTM=; b=wx04plgSYPX9ziMNFN4avqhJJYiHboMwP1WY9YBaka3XtL7nWlSAbpIw flogXb7eR+NaG+XKH5E7xhIfwZyAqIm9rPEUZe10SAM34FbazJgggsSxR 8/MaaBtQmro9EJ2RvXqTiv2ZAC4XQWN4nE5aOWFPwdJROK+6jM44U6UFz c=; X-IronPort-AV: E=McAfee;i="5300,2777,5777"; a="25673518" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Oct 2009 09:45:44 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9KGjisE016626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Oct 2009 09:45:44 -0700 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 n9KGjhUN008928 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 20 Oct 2009 09:45:44 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 20 Oct 2009 09:45:43 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Tue, 20 Oct 2009 09:45:43 -0700 From: "Laganier, Julien" To: "charliep@computer.org" Date: Tue, 20 Oct 2009 09:45:42 -0700 Thread-Topic: [MEXT] [Fwd: New Version Notification for draft-perkins-mext-4283mnids-00] Thread-Index: AcpRo0m1fOv30TRxRTeyL3dv+REZLQAAHNag Message-ID: References: <4ADCCCE3.1010506@computer.org> <4ADDE6AB.9000301@computer.org> In-Reply-To: <4ADDE6AB.9000301@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mext Subject: Re: [MEXT] [Fwd: New Version Notification for draft-perkins-mext-4283mnids-00] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 16:45:40 -0000 The IANA considerations of RFC 4283 states: In addition, IANA has created a new namespace for the subtype field of the Mobile Node Identifier option. The currently allocated values are as follows: NAI (defined in [RFC4282]). New values for this namespace can be allocated using Standards Action [RFC2434]. =20 So I do not see what restriction made encoding the IMSI as an NAI the only = choice available. If 3GPP had wanted to encode an MNID subtype to encode th= e IMSI, they could have get it allocated via the appropriate channel. =20 As to the lack of pressure on the MNID subtype registry, it is not IMHO a r= eason to reserve values before a clear requirement has been expressed, whic= h doesn't seem to be the case yet. Until then... --julien Charles E. Perkins >=20 > Hello Julien, >=20 > Your comment actually applies to every type of > identifier. Even MAC addresses could be written > as NAIs: > AB_CD_EF_00_11_22@ieeeMACaddresses.org > Or: > MAC_ADDRESS_AB_CD_EF_00_11_22@HomeAgent.org > depending on preferneces for AAA administration. >=20 > I'd give 5 to 1 odds that the use of NAI as you > mentioned by 3GPP and others was predicated on > the restriction that it was the only choice > available. > > It seems to me that, going into the future, we > can do better. And there is absolutely no pressure > evident today on the MNID type registry. >=20 > Nearer term, I think the availability of appropriate > MNID types might be valuable for the work that is > ongoing for an alternate security mechanism for > MIPv6. >=20 > Regards, > Charlie P. >=20 >=20 >=20 > Laganier, Julien wrote: > > Hello Charlie, > > > > Two comments on this draft: > > > > I'm wondering how useful it is to reserve a MNID type to encode a > 3GPP IMSI [1] given that EAP-AKA [RFC4187] and the 3GPP Numbering, > addressing and identification specification [TS23.003] already define > means of encoding the IMSI as an NAI. > > > > Also, w.r.t. P-TMSI and GUTI, 1) it's unclear to me whether these > identifiers are going to be used to identify a MN with its HA or LMA, > and 2) if it's going to be used, why not let 3GPP define in [TS23.003] > their own mapping of P-TMSI, GUTI, or whatever identifier they're using, > into a NAI? > > > > Best, > > > > --julien > > > > [RFC4187] Extensible Authentication Protocol Method for 3rd > Generation > > Authentication and Key Agreement (EAP-AKA) > > [TS23.003] 3rd Generation Partnership Project, "3GPP Technical > > Specification 23.003: Technical Specification Group Core > > Network and Terminals; Numbering, addressing and > identification" > > > > Charles E. Perkins wrote: > >> > >> Hello folks, > >> > >> This is a very simple draft, but could make a significant > >> difference in ease of standardization. Anyway it would > >> avoid the need to shoehorn every possible type of identifier > >> into a new substructure for the MN-NAI. > >> > >> Any comments will be appreciated. > >> > >> Regards, > >> Charlie P. > >> > >> > >> > >> -------- Original Message -------- > >> Subject: New Version Notification for draft-perkins-mext-4283mnids- > 00 > >> Date: Mon, 19 Oct 2009 13:20:49 -0700 (PDT) > >> From: IETF I-D Submission Tool > >> To: charliep@computer.org > >> CC: vijay@wichorus.com > >> > >> > >> A new version of I-D, draft-perkins-mext-4283mnids-00.txt has been > >> successfuly submitted by Charles Perkins and posted to the IETF > >> repository. > >> > >> Filename: draft-perkins-mext-4283mnids > >> Revision: 00 > >> Title: MN Identifier Types for RFC 4283 Mobile Node > >> Identifier Option > >> Creation_date: 2009-10-19 > >> WG ID: Independent Submission > >> Number_of_pages: 8 > >> > >> Abstract: > >> Additional Identifier Types are proposed for use with the Mobile > Node > >> Identifier Option for MIPv6 (RFC 4283). > >> > >> > >> > >> > >> The IETF Secretariat. > >> > >> > >> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From charliep@computer.org Tue Oct 20 10:05:55 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEA83A6939 for ; Tue, 20 Oct 2009 10:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIxhUJWaCr4h for ; Tue, 20 Oct 2009 10:05:54 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 1B8ED3A682F for ; Tue, 20 Oct 2009 10:05:54 -0700 (PDT) Received: from [12.204.153.98] (helo=[10.166.254.153]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N0I9p-0001KF-Pd; Tue, 20 Oct 2009 13:06:01 -0400 Message-ID: <4ADDEDF9.2070201@computer.org> Date: Tue, 20 Oct 2009 10:06:01 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Laganier, Julien" References: <4ADCCCE3.1010506@computer.org> <4ADDE6AB.9000301@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5263bc80598ce7dcba0fb37adf7e95968b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: mext Subject: Re: [MEXT] [Fwd: New Version Notification for draft-perkins-mext-4283mnids-00] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 17:05:55 -0000 Hello Julien, Well, if I were a 3GPP standardization representative, and I had the choices of (a) submitting yet another standards document to an external SDO and attending 3 _more_ meetings per year at the additional cost of months and many thousands of dollars or (b) encoding my identifier as an NAI, I think the choice would be obvious. Of course, both choices are "available". Regarding: > As to the lack of pressure on the MNID subtype registry, it > is not IMHO a reason to reserve values of course we agree. But I was responding to your earlier suggestion about whether it was advisable to use the type space. Regarding: > it is not IMHO a reason to reserve values before a clear > requirement has been expressed, which doesn't seem to be > the case yet. As pointed out above, I think that as long as the identifiers of the appropriate type cannot be easily used, we will continue to see creative applications of the only identifier type that _is_ easily able to be used -- namely, the NAI. Regards, Charlie P. Laganier, Julien wrote: > The IANA considerations of RFC 4283 states: > > In addition, IANA has created a new namespace for the subtype field > of the Mobile Node Identifier option. The currently allocated values > are as follows: > > NAI (defined in [RFC4282]). > > New values for this namespace can be allocated using Standards Action > [RFC2434]. > > So I do not see what restriction made encoding the IMSI as an NAI the only choice available. If 3GPP had wanted to encode an MNID subtype to encode the IMSI, they could have get it allocated via the appropriate channel. > > As to the lack of pressure on the MNID subtype registry, it is not IMHO a reason to reserve values before a clear requirement has been expressed, which doesn't seem to be the case yet. Until then... > > --julien > > Charles E. Perkins >> Hello Julien, >> >> Your comment actually applies to every type of >> identifier. Even MAC addresses could be written >> as NAIs: >> AB_CD_EF_00_11_22@ieeeMACaddresses.org >> Or: >> MAC_ADDRESS_AB_CD_EF_00_11_22@HomeAgent.org >> depending on preferneces for AAA administration. >> >> I'd give 5 to 1 odds that the use of NAI as you >> mentioned by 3GPP and others was predicated on >> the restriction that it was the only choice >> available. >> >> It seems to me that, going into the future, we >> can do better. And there is absolutely no pressure >> evident today on the MNID type registry. >> >> Nearer term, I think the availability of appropriate >> MNID types might be valuable for the work that is >> ongoing for an alternate security mechanism for >> MIPv6. >> >> Regards, >> Charlie P. >> >> >> >> Laganier, Julien wrote: >>> Hello Charlie, >>> >>> Two comments on this draft: >>> >>> I'm wondering how useful it is to reserve a MNID type to encode a >> 3GPP IMSI [1] given that EAP-AKA [RFC4187] and the 3GPP Numbering, >> addressing and identification specification [TS23.003] already define >> means of encoding the IMSI as an NAI. >>> Also, w.r.t. P-TMSI and GUTI, 1) it's unclear to me whether these >> identifiers are going to be used to identify a MN with its HA or LMA, >> and 2) if it's going to be used, why not let 3GPP define in [TS23.003] >> their own mapping of P-TMSI, GUTI, or whatever identifier they're using, >> into a NAI? >>> Best, >>> >>> --julien >>> >>> [RFC4187] Extensible Authentication Protocol Method for 3rd >> Generation >>> Authentication and Key Agreement (EAP-AKA) >>> [TS23.003] 3rd Generation Partnership Project, "3GPP Technical >>> Specification 23.003: Technical Specification Group Core >>> Network and Terminals; Numbering, addressing and >> identification" >>> Charles E. Perkins wrote: >>>> Hello folks, >>>> >>>> This is a very simple draft, but could make a significant >>>> difference in ease of standardization. Anyway it would >>>> avoid the need to shoehorn every possible type of identifier >>>> into a new substructure for the MN-NAI. >>>> >>>> Any comments will be appreciated. >>>> >>>> Regards, >>>> Charlie P. >>>> >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: New Version Notification for draft-perkins-mext-4283mnids- >> 00 >>>> Date: Mon, 19 Oct 2009 13:20:49 -0700 (PDT) >>>> From: IETF I-D Submission Tool >>>> To: charliep@computer.org >>>> CC: vijay@wichorus.com >>>> >>>> >>>> A new version of I-D, draft-perkins-mext-4283mnids-00.txt has been >>>> successfuly submitted by Charles Perkins and posted to the IETF >>>> repository. >>>> >>>> Filename: draft-perkins-mext-4283mnids >>>> Revision: 00 >>>> Title: MN Identifier Types for RFC 4283 Mobile Node >>>> Identifier Option >>>> Creation_date: 2009-10-19 >>>> WG ID: Independent Submission >>>> Number_of_pages: 8 >>>> >>>> Abstract: >>>> Additional Identifier Types are proposed for use with the Mobile >> Node >>>> Identifier Option for MIPv6 (RFC 4283). >>>> >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing 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 julienl@qualcomm.com Tue Oct 20 10:13:10 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53C503A694C for ; Tue, 20 Oct 2009 10:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.744 X-Spam-Level: X-Spam-Status: No, score=-103.744 tagged_above=-999 required=5 tests=[AWL=-1.145, 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 921A76Jh30R1 for ; Tue, 20 Oct 2009 10:13:09 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 77C9428C17F for ; Tue, 20 Oct 2009 10:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1256058709; x=1287594709; 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"Laganier,=20Julien"=20 |To:=20"charliep@computer.org"=20 |CC:=20mext=20|Date:=20Tue,=2020=20Oct=202 009=2010:11:46=20-0700|Subject:=20RE:=20[MEXT]=20[Fwd:=20 New=20Version=09Notification=09for=0D=0A=09draft-perkins- mext-4283mnids-00]|Thread-Topic:=20[MEXT]=20[Fwd:=20New =20Version=09Notification=09for=0D=0A=09draft-perkins-mex t-4283mnids-00]|Thread-Index:=20AcpRp5vRLhnjGUymT2iL82X2/ kUR+gAAFO8A|Message-ID:=20|References:=20< 4ADCCCE3.1010506@computer.org>=0D=0A=09=0D =0A=20<4ADDE6AB.9000301@computer.org>=0D=0A=20=0D=0A=20<4ADDEDF9.2070201@computer.org>|In-Reply-To: =20<4ADDEDF9.2070201@computer.org>|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,5777"=3B=20a=3D"25673760"; bh=JwLeH2WLm8ojm7kY66Mnk105UPn2oknm+uUs/0ETQF4=; b=ikbMk1ocrYYXGFqFN8Rq8eVgSaq/ilvXbiNqulopMcetUeTKOQQObgRI awvCr+TYZZDp5CC+RnrViloU97OlI7VghKqHlKCq5u/joDEsKQ7V8Kxer aqYwMd6QfCSfhZCRWBWwiqKX16foPssmATLw3xSgaXbb0Nx8OehGAF0cY I=; X-IronPort-AV: E=McAfee;i="5300,2777,5777"; a="25673760" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Oct 2009 10:11:49 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9KHBnh7025309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Oct 2009 10:11:49 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9KHBmpL020456 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 20 Oct 2009 10:11:48 -0700 (PDT) Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 20 Oct 2009 10:11:48 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Tue, 20 Oct 2009 10:11:47 -0700 From: "Laganier, Julien" To: "charliep@computer.org" Date: Tue, 20 Oct 2009 10:11:46 -0700 Thread-Topic: [MEXT] [Fwd: New Version Notification for draft-perkins-mext-4283mnids-00] Thread-Index: AcpRp5vRLhnjGUymT2iL82X2/kUR+gAAFO8A Message-ID: References: <4ADCCCE3.1010506@computer.org> <4ADDE6AB.9000301@computer.org> <4ADDEDF9.2070201@computer.org> In-Reply-To: <4ADDEDF9.2070201@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mext Subject: Re: [MEXT] [Fwd: New Version Notification for draft-perkins-mext-4283mnids-00] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 17:13:10 -0000 Hello Charlie, With my initial comment I meant I wasn't sure 3GPP is interested in using a= new MNID subtype for IMSI. In my view having a MNID subtype reserved for IMSI it is as simple as 1) wr= iting a draft (which you did) and 2) having 3GPP reference that draft so th= at here in the IETF it's clear what their intent is and we can move forward= and get the draft published as an RFC.=20 Hope that clarifies. --julien > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@computer.org] > Sent: Tuesday, October 20, 2009 10:06 AM > To: Laganier, Julien > Cc: mext > Subject: Re: [MEXT] [Fwd: New Version Notification for draft-perkins- > mext-4283mnids-00] >=20 >=20 > Hello Julien, >=20 > Well, if I were a 3GPP standardization representative, > and I had the choices of (a) submitting yet another > standards document to an external SDO and attending > 3 _more_ meetings per year at the additional cost of > months and many thousands of dollars or (b) encoding > my identifier as an NAI, I think the choice would be > obvious. >=20 > Of course, both choices are "available". >=20 > Regarding: >=20 > > As to the lack of pressure on the MNID subtype registry, it > > is not IMHO a reason to reserve values >=20 > of course we agree. But I was responding to your > earlier suggestion about whether it was advisable > to use the type space. >=20 > Regarding: >=20 > > it is not IMHO a reason to reserve values before a clear > > requirement has been expressed, which doesn't seem to be > > the case yet. >=20 > As pointed out above, I think that as long as the identifiers > of the appropriate type cannot be easily used, we will > continue to see creative applications of the only identifier > type that _is_ easily able to be used -- namely, the NAI. >=20 > Regards, > Charlie P. >=20 >=20 >=20 > Laganier, Julien wrote: > > The IANA considerations of RFC 4283 states: > > > > In addition, IANA has created a new namespace for the subtype > field > > of the Mobile Node Identifier option. The currently allocated > values > > are as follows: > > > > NAI (defined in [RFC4282]). > > > > New values for this namespace can be allocated using Standards > Action > > [RFC2434]. > > > > So I do not see what restriction made encoding the IMSI as an NAI the > only choice available. If 3GPP had wanted to encode an MNID subtype to > encode the IMSI, they could have get it allocated via the appropriate > channel. > > > > As to the lack of pressure on the MNID subtype registry, it is not > IMHO a reason to reserve values before a clear requirement has been > expressed, which doesn't seem to be the case yet. Until then... > > > > --julien > > > > Charles E. Perkins > >> Hello Julien, > >> > >> Your comment actually applies to every type of > >> identifier. Even MAC addresses could be written > >> as NAIs: > >> AB_CD_EF_00_11_22@ieeeMACaddresses.org > >> Or: > >> MAC_ADDRESS_AB_CD_EF_00_11_22@HomeAgent.org > >> depending on preferneces for AAA administration. > >> > >> I'd give 5 to 1 odds that the use of NAI as you > >> mentioned by 3GPP and others was predicated on > >> the restriction that it was the only choice > >> available. > >> > >> It seems to me that, going into the future, we > >> can do better. And there is absolutely no pressure > >> evident today on the MNID type registry. > >> > >> Nearer term, I think the availability of appropriate > >> MNID types might be valuable for the work that is > >> ongoing for an alternate security mechanism for > >> MIPv6. > >> > >> Regards, > >> Charlie P. > >> > >> > >> > >> Laganier, Julien wrote: > >>> Hello Charlie, > >>> > >>> Two comments on this draft: > >>> > >>> I'm wondering how useful it is to reserve a MNID type to encode a > >> 3GPP IMSI [1] given that EAP-AKA [RFC4187] and the 3GPP Numbering, > >> addressing and identification specification [TS23.003] already > define > >> means of encoding the IMSI as an NAI. > >>> Also, w.r.t. P-TMSI and GUTI, 1) it's unclear to me whether these > >> identifiers are going to be used to identify a MN with its HA or LMA, > >> and 2) if it's going to be used, why not let 3GPP define in > [TS23.003] > >> their own mapping of P-TMSI, GUTI, or whatever identifier they're > using, > >> into a NAI? > >>> Best, > >>> > >>> --julien > >>> > >>> [RFC4187] Extensible Authentication Protocol Method for 3rd > >> Generation > >>> Authentication and Key Agreement (EAP-AKA) > >>> [TS23.003] 3rd Generation Partnership Project, "3GPP Technical > >>> Specification 23.003: Technical Specification Group Core > >>> Network and Terminals; Numbering, addressing and > >> identification" > >>> Charles E. Perkins wrote: > >>>> Hello folks, > >>>> > >>>> This is a very simple draft, but could make a significant > >>>> difference in ease of standardization. Anyway it would > >>>> avoid the need to shoehorn every possible type of identifier > >>>> into a new substructure for the MN-NAI. > >>>> > >>>> Any comments will be appreciated. > >>>> > >>>> Regards, > >>>> Charlie P. > >>>> > >>>> > >>>> > >>>> -------- Original Message -------- > >>>> Subject: New Version Notification for draft-perkins-mext- > 4283mnids- > >> 00 > >>>> Date: Mon, 19 Oct 2009 13:20:49 -0700 (PDT) > >>>> From: IETF I-D Submission Tool > >>>> To: charliep@computer.org > >>>> CC: vijay@wichorus.com > >>>> > >>>> > >>>> A new version of I-D, draft-perkins-mext-4283mnids-00.txt has been > >>>> successfuly submitted by Charles Perkins and posted to the IETF > >>>> repository. > >>>> > >>>> Filename: draft-perkins-mext-4283mnids > >>>> Revision: 00 > >>>> Title: MN Identifier Types for RFC 4283 Mobile Node > >>>> Identifier Option > >>>> Creation_date: 2009-10-19 > >>>> WG ID: Independent Submission > >>>> Number_of_pages: 8 > >>>> > >>>> Abstract: > >>>> Additional Identifier Types are proposed for use with the Mobile > >> Node > >>>> Identifier Option for MIPv6 (RFC 4283). > >>>> > >>>> > >>>> > >>>> > >>>> The IETF Secretariat. > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> MEXT mailing 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 yuri.ismailov@ericsson.com Wed Oct 21 01:12:29 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E4403A685B for ; Wed, 21 Oct 2009 01:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 6Cmk6TwF6eYS for ; Wed, 21 Oct 2009 01:12:27 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id DFA133A67A1 for ; Wed, 21 Oct 2009 01:12:22 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-0b-4adec26d908b Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 52.EA.04191.D62CEDA4; Wed, 21 Oct 2009 10:12:29 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 10:06:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 10:06:42 +0200 Message-ID: In-Reply-To: <346103.90889.qm@web111407.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpRl5T31646WtRNThOHRe/GeaYKxwAjaMaw References: <346103.90889.qm@web111407.mail.gq1.yahoo.com> From: "Yuri Ismailov" To: "Behcet Sarikaya" , "Hesham Soliman" , "Conny Larsson" , "Laganier, Julien" X-OriginalArrivalTime: 21 Oct 2009 08:06:44.0949 (UTC) FILETIME=[6E319050:01CA5225] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 08:12:29 -0000 Hi, Sorry for jumping in, but did not understand the point with = re-chartering. As I can see it is in the charter. /yuri =20 -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of = Behcet Sarikaya Sent: Tuesday, October 20, 2009 5:11 PM To: Hesham Soliman; Conny Larsson; Laganier, Julien Cc: mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Hi Conny, Hesham, ----- Original Message ---- > From: Hesham Soliman > To: Conny Larsson ; "Laganier, Julien"=20 > > Cc: "mext@ietf.org" > Sent: Mon, October 19, 2009 6:49:46 PM > Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >=20 > Hi Conny, >=20 > We need the comments now, not after the document is updated :). This=20 > is WGLC and we're updating the document as a result of reviews. >=20 > The bidirectionality issue was discussed and it was decided that there = > is no case for it. I don't think this reflects the situation. The right answer is that flow revocation and possibly other flow binding = operations initiated by HA=A0will be taken up as part of=A0MEXT = rechartering. BTW we revised our draft, here is the link to the revised draft: http://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-01.txt Regards, Behcet =20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From hesham@elevatemobile.com Wed Oct 21 01:21:44 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E3F23A6768 for ; Wed, 21 Oct 2009 01:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpK+pkN-OsE2 for ; Wed, 21 Oct 2009 01:21:42 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id B6A773A67EB for ; Wed, 21 Oct 2009 01:21:38 -0700 (PDT) Received: from [203.219.211.243] (helo=[192.168.0.2]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1N0WRu-0001uf-Du; Wed, 21 Oct 2009 19:21:40 +1100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 21 Oct 2009 19:21:32 +1100 From: Hesham Soliman To: , , Message-ID: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpG3PrETCpXfQpNQraj6B7QmoF8mwCVAOxqAj2gHek= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 08:21:44 -0000 Hi Raj, Thanks for the comments. Until the draft is updated (we discussed the comments so far and George is going to propose text and do the new rev), I'll give a quick overview comment in response. You have two main comments that manifest themselves in various forms below: 1. Questioning the need for PRI 2. Questioning the need to include existing bindings in the BU to refresh them. Answers: 1. We have to have a PRI for the HA to work out the priosirities of bindings. IFF two PRI values are the same then the HA will select one of them based on means out of our scope. Removing the PRI is essentially asking the MN to "hope" that the HA arranges them properly. 2. MIPv6 basically allows one BU to completely overwrite the previous BU. This makes the implementation simple. Hence, if you don't include something in a BU it is removed. You could argue for a different approach but I think you'll find that it's more complex and likely more BW consuming. This way it's fairly easy to keep things in sync between the MN and HA. Regarding how the HA knows if it's an "add" or "modify" operation, it doesn't need to, when it receives an FID it checks if it already exists, if yes then it overwrites it with the new one, if no then it creates a new one. Simple! George will respond to your comments about inactive bindings. Hesham On 10/10/09 8:36 AM, "Basavaraj.Patil@nokia.com" wrote: > > Hello, > > The document needs at least another revision before it would be ready > to be sent to the IESG. > > Below is a review of the Flow bindings I-D > : > > - Update reference DSMIPv6 [I-D.ietf-mext-nemo-v4traversal] to RFC5555 > > - Update reference [I-D.ietf-monami6-multiplecoa] to RFC5648 > >> In this document, a flow is defined as a set of IP packets matching a >> flow descriptor. > > The definition in the terminology section is better suited to describe > a flow. A flow can be identified by a flow descriptor but that is not > the definition of what a flow is. > >> This specification, however, does not define flow >> descriptors and it is assumed that one or more ways of defining flow >> descriptors are going to be defined in other specifications. > > The specification now exists and hence should be referenced, i.e I-D: > draft-ietf-mext-binary-ts > > >> Flow Identifier: An unsigned integer. > > This definition really does not explain what a Flow ID is. Suggested > text: "A flow identifier uniquely identifies a flow associated with an > MN. It is generated by the MN and is cached in the flow binding list > maintained by the MN, HA, CN or MAP." > >> BID-PRI >> >> This is a 7-bit unsigned integer placing each BID to a relative >> priority with other registered BIDs. Value "0" is reserved. A >> lower number in this field indicates higher priority, while >> BIDs with the same BID-PRI value have equal priority. This is >> consistent with current practice in packet classifiers. > > I dont see the value in having a priority associated with the > BID. This I-D proposes the creation of an ordered BID list. The reason > for having an ordered list is to process the packet with the BID which > has the highest priority in case there is no match for any Flow > ID. This is not required. The HA can decide to forward it to any CoA > based on some default binding cache entry or policy that it has. > I would suggest not modifying the Binding Identifier mobility option > as specified in RFC5648. > >> FID-PRI >> >> This is an unsigned 8-bit priority field to indicate the >> priority of a particular option. This field is needed in cases >> where two different flow descriptions in two different options >> overlap. The priority field decides which policy should be in >> those cases. A lower number in this field indicates a higher >> priority. > > I guess multiple FIDs can have the same priority, right? Is there a > default value in case no priority is assigned by the MN? Or because > you are creating an ordered list of FIDs, the priority for each FID is > unique? Also it would be good to reserve priority 0 for future use. > Some additional text to clarify this might be useful. > >> Action >> >> This field specifies the action that needs to be taken by the >> receiver of the binding update containing the flow >> identification option. The details of these requests are >> discussed below. > > - s/This field specifies/This 8 bit unsigned integer field specifies > - Can you include the values defined for the actions further below in > the section immediately below the Action field definition? Makes > reading easier. > - a/Action value 0 is reserved. > - In the example of Flow binding entries shown in Sec 4.4, the action > field also includes Forward (in addition to discard and > n-cast). Does this imply that not indicating anything in the Action > field equates to Forwarding? Or should there be a separate value > reserved for forwarding as well? Why not be explicit and just assign > a value for forwarding as well. > >> Rsvd >> Status > > Specify these are 8 bit unsigned integer fields just to be explicit. > >> A number of sub-options can follow the option defined in this >> section. > > Rephrase as : A number of sub-options can follow the Flow > Identification mobility option defined in this section. > >> 4.2.1. Binding Reference Sub-option >> This section introduces the Binding Reference sub-option, which may >> be included in the Flow identification option. > > Is it really a MAY? If the MN is adding a new flow ID, the binding > reference sub-option is mandatory especially if the action is set to > Forward. From the processing rules defined in Sec 5.3.2.1 it seems > that the binding reference sub-option MUST be included and SHOULD have > a valid BID. > > Adding a flow ID that does not have a valid matching BID in the BC > does not make much sense. > > s/which may be included in the Flow identification option./which MUST > be included in the Flow identification mobility option. > >> 4.2.2. Flow Description Sub-option >> Sub-opt Type >> >> Indicates the Sub-option type. For the flow description sub- >> option, this field SHOULD be set to one of the FD types defined >> below. > > - Move the text defining the suboptions to follow the definition of the > suboption. > - s/Indicates the/8 bit unsigned integer which indicates the > - What is really implied by: "17-32 reserved for Flow Description > formats"? > Do these values have any predefined flow descriptions? Or does it > imply that these values cannot be used by the MN? > >> Flow Description >> >> The flow description corresponding to the type indicated by the >> Sub-opt Type field. Flow description is out of scope of this >> document. > > In I-D: draft-ietf-mext-binary-ts-00 Sec 3 says " > [I-D.ietf-mext-flow-binding] defines the format for the traffic > selector sub-option." > > There is no traffic selector sub-option defined in the flow-binding > ID. The closest match I guess is the flow description field in the > flow-description sub-option. Revise the flow description text and also > check to see if the format of the traffic selector options fit into > the flow description field. > >> 4.3. Flow Identification Summary Mobility Option > > Is this option really required? The only reason I can gather from the > I-D is that every BU MUST include a list of all the FIDs that have > been added otheriwse they will be deleted. And hence the summary > option is an optimized way of sending a list of all the FIDs. > >> The Flow Identification Summary Mobility option includes one or more >> flow identifiers (FIDs) for the purpose of refresing their state > > Why do you need to refresh the state of the FIDs? They do not have a > lifetime. If a BU sent to the HA for example were to deprecate a BID > (interface/CoA no longer being available), the BU could also include > the FID options to modify the FIDs which use that BID. If an MN is > simply sending a BU to refresh its lifetime associated with one or > more CoAs, there is no reason to include the FID summary mobility > option. > >> The binding cache was then >> extended by [I-D.ietf-monami6-multiplecoa] to include more than one >> care-of addresses and to associate each of them with a Binding >> Identifier (BID). > > s/The binding cache was then/The binding cache has been > Also reference the MCoA RFC instead. > >> * Active/Inactive flag: This flag indicates whether the entry is >> active or inactive. > > What does it mean when the entry is set as Inactive? Does it imply > that the BID is invalid? In the example shown in this section what > does the 3rd entry which is inactive imply? The MN does not specify in > the FID option sent in the BU whether a flow binding is active or > inactive. So how is this flag set and under what conditions? > >> If all of the >> BIDs pointed to by a given entry are not valid BIDs in the binding >> cache, the flow binding entry becomes "inactive", in other words it >> does not affect data traffic. > > If a BID is not valid, then the entry in the flow binding list should > be deprecated. Why would you have an entry in the flow binding list > when there is no valid BID in the BC? > Invalid BIDs should be treated as an error case. In the protocol > operations section the ID says that the HA will reject the addition of > a FID if the BID specified in it is invalid. > >> The third entry is marked as Inactive since the BID 4 does not exist >> in the ordered list of BID entries below. Inactive entries do not >> affect traffic, i.e., packets are not matched against them. > > See above reasoning. No reason to have such an entry. Should be viewed > as an error case. > >> Ordered BID Entries > > As stated earlier as well, there is really no need to order the > BIDs. Assigning a priority to the BIDs by modifying the BID Mbility > option is not required. Flow mobility works without assigning > priorities to BIDs. > >> Finally any remaining packets that do not match any of the entries >> above will be simply forwarded to the care-of address indicated by >> the highest order BID in the table below. > > For the case where there is no matching FID, the HA/CN/MAP can handle > it based on policy or forward to a default CoA. > >> As indicated earlier the >> flow description itself is defined in another document. > > Reference draft-ietf-mext-binary-ts > >> 5.1.1. Preferred Care-of address >> >> Any node that supports this specification MUST maintain an ordered >> list of care-of addresses for each mobile node it maintains a list of >> flow bindings for. The ordered list of care-of addresses is built >> based on the BID-PRI field of the Binding Identifier option (see >> Section 4.1). >> >> The ordered list of BIDs is used to determine how to forward a packet >> to a given mobile node when the packet does not match any of the flow >> binding entries defined in Section 4.4. A packet that does not match >> any of the flow binding entries SHOULD be forwarded to the care-of >> address identified by the BID with the highest priority i.e., lowest >> BID-PRI value. > > See reasons above why BID-PRI is not needed and how packets which do > not match any FIDs can be handled in a more simpler/implementation > specific manner. > >> In other words, two flow >> identification options in the same message can not be about the same >> flow binding. > > s/can not be/MUST not be > >> All flow binding state MUST be refreshed in every binding update the >> mobile node sends. Any previously registered flow binding that is >> not included in a given binding update will be deleted. So, any flow >> bindings that are not added or modified by a flow identification >> option, but have previously registered and need to be maintained MUST >> be included in a flow summary option. Only one flow summary option >> can be included in a given binding update. > > This is suboptimal. Why do you need to include the FID options in > every BU. The MN may be sending a BU to refresh the lifetime of a CoA > or adding a new CoA etc. Requiring that FID options be carried in > every BU even when the FID option does not have any implication is > simply an overhead. Additionally there is no reason to keep refreshing > FIDs. > >> When the mobile node sends a binding update it MUST refresh all flow >> bindings it wants to maintain even if it does not want to change any >> of their parameters. > > Why? > >> 5.2.4. Removing flow bindings >> >> Removal of flow binging entries is performed implicitly by omission >> of a given FID from a binding update. > > It would be better to have an explicit flag in the Flow ID mobility > option whether the operation is an add/modify/delete rather than this > implicit mechanism. Also you would avoid having to send the flow > summary option as a means to deprecate FIDs. > >> When all the BIDs associated with a flow binding are removed, the >> flow binding MUST be marked as inactive in the list of flow binding >> entries as shown in Section 4.4. > > If all BIDs are removed and the rule is other than discard, the flow > binding itself should be deprecated. Why keep such a flow binding? > >> If the FID field of the flow identification option is already present >> in the list of flow binding entries for this mobile node, the home >> agent MUST reject this flow binding add request by copying the flow >> identification option in the BA, and setting the Status field to 135 >> (FID already in use). > > Why? It could be a modify operation for an existing FID? How do you > specify whether an operation is add or modify? > An HA which receives a BU with a FID which already exists for that MN > is simply viewed as a modify operation, right? > >> A de-registration binding >> update (with a zero lifetime) would result in deleting all bindings >> regardless of the presence of the Flow summary option. > > It would be useful to include a section which explains what happens > when the MN returns to its home link and deregisters. > >> If the value of the FID field is present in the mobile nodes list of >> slow binding entries the, home agent SHOULD refresh the binding entry >> identified by the FID without changing any of the other parameters >> associated with it. > > slow binding entries? ;) > >> If, however, the action >> indicated in an entry of the list of flow bindings is "n-cast", the >> entry must indicated a BID. > > s/the entry must indicated a BID/the entry must indicate more than one > valid BID. > >> If none of the >> BIDs pointed to in a flow binding entry is valid then the entry is >> considered to be inactive (as defined in Section 4.4) and is skipped. >> In other words packets should not be matched against that entry. > > Should that Flow binding be deprecated? > > -Raj > > > > On 10/6/09 6:30 PM, "ext Laganier, Julien" wrote: > >> Folks, >> >> Hereby we're starting a two weeks WGLC on our "Flow Bindings in Mobile IPv6 >> and NEMO Basic Support" document, available at the following URL: >> >> >> >> Please review the specification, post your comments to the mailing list, and >> state whether or not you think the document is ready to be forwarded to IESG >> before 2009-10-20 6:00PM PST. >> >> Thank you for your support. >> >> --julien & marcelo, MEXT chairs >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From yuri.ismailov@ericsson.com Wed Oct 21 01:26:46 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8E243A6768 for ; Wed, 21 Oct 2009 01:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 UJR0B3sLLnaQ for ; Wed, 21 Oct 2009 01:26:46 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A9AA53A657C for ; Wed, 21 Oct 2009 01:26:45 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-ee-4adec5ccb31d Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 2E.9C.04191.CC5CEDA4; Wed, 21 Oct 2009 10:26:53 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 10:25:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 10:25:28 +0200 Message-ID: In-Reply-To: <4ADEC521.60708@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpSJ9uZU2POGHrSQMSk+UMY8ecuRwAACQuA References: <346103.90889.qm@web111407.mail.gq1.yahoo.com> <4ADEC521.60708@it.uc3m.es> From: "Yuri Ismailov" To: "marcelo bagnulo braun" X-OriginalArrivalTime: 21 Oct 2009 08:25:28.0936 (UTC) FILETIME=[0C245E80:01CA5228] X-Brightmail-Tracker: AAAAAA== Cc: "Laganier, Julien" , mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 08:26:47 -0000 Hi Marcelo, Got the point Regards Yuri =20 -----Original Message----- From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 Sent: Wednesday, October 21, 2009 10:24 AM To: Yuri Ismailov Cc: Behcet Sarikaya; Hesham Soliman; Conny Larsson; Laganier, Julien; = mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Hi Yuri, about the rechartering: the main challenge that MEXT has is how manage the energy. In order to work on something, we not only need to decide that this is = not broken, but also that we want to invest the limited amount of energy = of the WG in this topic _instead_ than investing in another topic. and this is why we need a rechartering, so we can pick this topic and = not pick another one or viveversa. Makes sense? Regards, marcelo Yuri Ismailov escribi=F3: > Hi, > Sorry for jumping in, but did not understand the point with = re-chartering. > As I can see it is in the charter. > > /yuri > =20 > > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf=20 > Of Behcet Sarikaya > Sent: Tuesday, October 20, 2009 5:11 PM > To: Hesham Soliman; Conny Larsson; Laganier, Julien > Cc: mext@ietf.org > Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 > > Hi Conny, Hesham, > > > > ----- Original Message ---- > =20 >> From: Hesham Soliman >> To: Conny Larsson ; "Laganier, Julien"=20 >> >> Cc: "mext@ietf.org" >> Sent: Mon, October 19, 2009 6:49:46 PM >> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >> >> Hi Conny, >> >> We need the comments now, not after the document is updated :). This=20 >> is WGLC and we're updating the document as a result of reviews. >> >> The bidirectionality issue was discussed and it was decided that=20 >> there is no case for it. >> =20 > > I don't think this reflects the situation. > > The right answer is that flow revocation and possibly other flow = binding operations initiated by HA will be taken up as part of MEXT = rechartering. > > BTW we revised our draft, here is the link to the revised draft: > > http://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-01.txt > > > Regards, > > Behcet > > > =20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > =20 From marcelo@it.uc3m.es Wed Oct 21 01:42:41 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 931E43A6767 for ; Wed, 21 Oct 2009 01:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqQstdMP+N57 for ; Wed, 21 Oct 2009 01:42:40 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id D0CFE3A6782 for ; Wed, 21 Oct 2009 01:42:39 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 428866C25A9; Wed, 21 Oct 2009 10:24:01 +0200 (CEST) Message-ID: <4ADEC521.60708@it.uc3m.es> Date: Wed, 21 Oct 2009 10:24:01 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Yuri Ismailov References: <346103.90889.qm@web111407.mail.gq1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16960.003 Cc: "Laganier, Julien" , mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 08:42:41 -0000 Hi Yuri, about the rechartering: the main challenge that MEXT has is how manage the energy. In order to work on something, we not only need to decide that this is not broken, but also that we want to invest the limited amount of energy of the WG in this topic _instead_ than investing in another topic. and this is why we need a rechartering, so we can pick this topic and not pick another one or viveversa. Makes sense? Regards, marcelo Yuri Ismailov escribió: > Hi, > Sorry for jumping in, but did not understand the point with re-chartering. > As I can see it is in the charter. > > /yuri > > > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Behcet Sarikaya > Sent: Tuesday, October 20, 2009 5:11 PM > To: Hesham Soliman; Conny Larsson; Laganier, Julien > Cc: mext@ietf.org > Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 > > Hi Conny, Hesham, > > > > ----- Original Message ---- > >> From: Hesham Soliman >> To: Conny Larsson ; "Laganier, Julien" >> >> Cc: "mext@ietf.org" >> Sent: Mon, October 19, 2009 6:49:46 PM >> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >> >> Hi Conny, >> >> We need the comments now, not after the document is updated :). This >> is WGLC and we're updating the document as a result of reviews. >> >> The bidirectionality issue was discussed and it was decided that there >> is no case for it. >> > > I don't think this reflects the situation. > > The right answer is that flow revocation and possibly other flow binding operations initiated by HA will be taken up as part of MEXT rechartering. > > BTW we revised our draft, here is the link to the revised draft: > > http://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-01.txt > > > Regards, > > Behcet > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From conny.larsson@ericsson.com Wed Oct 21 07:44:31 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD00D28C124 for ; Wed, 21 Oct 2009 07:44:31 -0700 (PDT) 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.710, 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 Cjq1cbOXRkoZ for ; Wed, 21 Oct 2009 07:44:31 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7A8883A6862 for ; Wed, 21 Oct 2009 07:44:30 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-71-4adf1e539aca Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 76.41.04191.25E1FDA4; Wed, 21 Oct 2009 16:44:36 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 16:44:27 +0200 Received: from [127.0.0.1] ([147.214.130.137]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 16:44:27 +0200 Message-ID: <4ADF1E48.5040502@ericsson.com> Date: Wed, 21 Oct 2009 16:44:24 +0200 From: Conny Larsson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2009 14:44:27.0706 (UTC) FILETIME=[FD8151A0:01CA525C] X-Brightmail-Tracker: AAAAAA== Cc: "Laganier, Julien" , "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 14:44:31 -0000 Hi Hesham, See inline. Regards Conny Hesham Soliman wrote: > Hi Conny, > > We need the comments now, not after the document is updated :). This is WGLC > and we're updating the document as a result of reviews. > Your draft is only considering the binary flow descriptors and I see no reason for this limitation. It has previously been suggested that your draft only should handle the transfer and operation of flow descriptors. Specific flow descriptor handling should be put in a separate draft. To be more specific. In case of ASCII format there is no need for the FID and FID-PRI fields in Figure 2. They are only used for the binary flow descriptors. Besides this all option length fields indicates the length of the option in 1-octet unit, not 8-octet units. The Binding Reference sub-option (section 4.2.1), the Flow Description sub-option (section 4.2.2) and the Flow Identification Summary option (section 4.3) are binary specific things and should be taken care of by that draft, they are not needed for the ASCII format. Making these changes, and perhaps some minor modifications related to these changes, would make the draft look much better. I believe it's doable. > The bidirectionality issue was discussed and it was decided that there is no > case for it. This was sent to the list by the chairs. So we won't be adding > this to the draft. > There is a draft making the case for HA to MN initiated flow bindings, but this is a separate discussion from the one above. > Hesham > > > On 20/10/09 7:25 AM, "Conny Larsson" wrote: > > >> Hi, >> >> Comments (a detailed review will be done when the draft has been updated) >> >> There has been a lengthy discussion on the mailing list regarding >> support for bidirectional transfer of flow descriptors. A number of >> arguments have been stated both in favor of bidirectional transfer and >> against it. I'm in favor of adding support for bidirectional transfer >> and believe it should be added according to what has previously been >> agreed in the WG charter. >> >> There has also been a discussion about support for binary and ASCII flow >> descriptors. The draft is currently written only to fit the binary >> format. I see no reason for this approach. The draft could easily be >> changed to fit both formats. >> >> I see no reason for draft-ietf-mext-flow-binding-03 to be forwarded to >> IESG before the above issues have been fixed. >> >> Regards >> Conny >> >> Laganier, Julien wrote: >> >>> Folks, >>> >>> Hereby we're starting a two weeks WGLC on our "Flow Bindings in Mobile IPv6 >>> and NEMO Basic Support" document, available at the following URL: >>> >>> >>> >>> Please review the specification, post your comments to the mailing list, and >>> state whether or not you think the document is ready to be forwarded to IESG >>> before 2009-10-20 6:00PM PST. >>> >>> Thank you for your support. >>> >>> --julien & marcelo, MEXT chairs >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> From root@core3.amsl.com Wed Oct 21 11:15:02 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B0E323A67FA; Wed, 21 Oct 2009 11:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091021181502.B0E323A67FA@core3.amsl.com> Date: Wed, 21 Oct 2009 11:15:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 18:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobility Support in IPv6 Author(s) : D. Johnson, et al. Filename : draft-ietf-mext-rfc3775bis-05.txt Pages : 174 Date : 2009-10-21 This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-rfc3775bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-21110343.I-D@ietf.org> --NextPart-- From tsirtsis@googlemail.com Wed Oct 21 11:26:28 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A2B3A69DA for ; Wed, 21 Oct 2009 11:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjnBKoK2UYcR for ; Wed, 21 Oct 2009 11:26:26 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id C5F393A69E3 for ; Wed, 21 Oct 2009 11:26:25 -0700 (PDT) Received: by ywh13 with SMTP id 13so9612457ywh.29 for ; Wed, 21 Oct 2009 11:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=g6iU62HMKeQYZCmE/hEYW9clOD+f+GT+nRpfkdEOVzM=; b=O7HwW9qgFhg2yKCxx1ShYQ45GeUV8dgx97+0WdjAFvwY8LrqG5nqsX8AAozHCpTjHf 41saYP5vu0GfEGAfRzG8WET+5CA33++/Z+SOW+23zMhaQyDZ5Wlehv+G6fjUcp8hxedf fcTHhD+2mPrIDUWseRmLKp8mVU+Z7Vn10ILJA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cGFHyVjFdA8awJXdpw9oQV+3m0qdXGj/Bcy1HseLdjkDk82NWj+n0YmQ8EoEvC3ivu rGdPIMxw5T6tSjzyrJr9MCq9CKn7As2uaQ8opZYy4sMTOL0fD+DDhkxWbue3yPY5vNrx WNLHdja5vA+cLLZ3RL/RvqzPOCneqVXSzrbr0= MIME-Version: 1.0 Received: by 10.239.190.207 with SMTP id y15mr700973hbh.151.1256149590156; Wed, 21 Oct 2009 11:26:30 -0700 (PDT) In-Reply-To: <40b8fe770910071737u3708ccbbge35b0a0b99bd3fa@mail.gmail.com> References: <40b8fe770910071737u3708ccbbge35b0a0b99bd3fa@mail.gmail.com> Date: Wed, 21 Oct 2009 19:26:30 +0100 Message-ID: From: George Tsirtsis To: Dave Craig Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 18:26:28 -0000 Hi Dave Thanks a lot of your detailed review. I am accepting most of your points below so see responses in line. George On Thu, Oct 8, 2009 at 1:37 AM, Dave Craig wrote: > Nice draft, I have a few comments that I hope will improve it a little bi= t. > > General comments, I do not see any specification of handling for > fragments and ICMP responses. =C2=A0I think you need some text here becau= se > draft mentions filters applying to transport-specific headers and the > desire not to reorder packets in a flow by sending them by different > paths. =C2=A0I suggest you consider specifying HA behavior that attempts = to > direct fragments along the same binding as the previous fragment and > ICMP responses along the path that corresponds to reversing the source > and destination port of the packet encapsulated in an ICMP response. > Please let me know if you'd like some text for this. > GT> Some good points here: I am adding the following text, in the Packet Processing section : "If a packet is fragmented, only the first fragment contains all IP and transport layer headers, while subsequent fragments only contain an IP header with= out transport layer headers. For this reason it is poss= ible that subsequent fragments do not match the same tra= ffic selector as the initial fragment of such a packet. Unless specific measures are taken the likely outco= me is that the initial fragment is routed as the MN inten= ded while subsequent fragments are routed differently, = and probably based on the default flow binding. HAs, MA= Ps, and CNs SHOULD take care to forward all fragments o= f a given packet the same way, and in accordance to the= flow binding matching the first fragment of said packet.= This should be possible given the fact that fragment hea= ders include enough information to identify a fragment a= s part of a specific packet, but the details of how t= his is ensured are implementation specific and are not defined in this specification. > I also suggest that the draft exclude flow bindings from impacting > traffic originating from the home agent. It would not go very well if > a node sends a discard all flow binding to temporarily stop traffic > but is then unable to undo that flow binding. > GT> I am not sure it is worth saying something like that. The MN can damage itself in many different ways, which we cannot really prevent > All references to I-D.ietf-monami-multiplecoa should be replaced with > RFC 5648, congratulations! > GT> done, thanks. > * 2. Introduction, page 5, "...which binds one care-of address to one > home address".=C2=A0 Since you refer to NEMO, should this be, "...which > binds one care-of address to one home address and possibly its > associated Mobile Network"? =C2=A0I think this is germane to the flow > mobility conversation because this draft enables migrating flows > inside the mobile network independently of the home address. > GT> done > * 2. Introduction, page 5, "A policy can contain a request for a > special treatment...". =C2=A0This sounds better as, "A policy can contain= a > request for special treatment..." > GT> OK > * 2. Introduction, page 5, "Requesting the flow binding can be decided > based on local policies with the mobile node / mobile router and based > on the link characteristics and the types of applications running at > the time.". =C2=A0This sounds better as, "The mobile node / mobile router > assembles the flow binding request based on local policies, link > characteristics, and type of applications running at the time." > GT> done. > * 2. Introduction, page 6, "with ant-replay protection mechanisms." > should be, "with anti-replay..." =C2=A0The again, I may have overlooked a= n > application for flow mobility in the pest extermination business. > GT> nice :-) > * 2. Introduction, page 6, "Hence, per-packet load balancing is not > currently supported in this extension." =C2=A0This is a non-sequitur with > previous text mentioning the problems with load balancing. =C2=A0It sound= s > like you plan to support it at some point in the future. =C2=A0Suggest > rephrasing with some text to effect that load balancing is not > envisioned for this extension. =C2=A0Otherwise, as an implementer, I figu= re > that I should start planning in extensibility for load balancing in my > design. > GT> done. > * 4.1. Definition Update for Binding Identifier Mobility Option, page > 8, "BIDs with the same BID-PRI value have equal priority." =C2=A0Do you > mean, "BIDs with the same BID-PRI produce unspecified results for > flows matching both bindings."? =C2=A0It is not clear what equal priority > means. =C2=A0An administrator may rightly assume a longest-prefix match f= or > associated address-type filters, and I do not think you want to make > that commitment here. > GT> added: "....meaning that, which BID is used is an implementation issue.= " > * 4.2. Same comment for Flow Identification Mobility Option, page 9, > with respect to FID-PRI. > GT> It does not apply here since as per WG request (despite authors' disagreement) each FID MUST have a different FID-PRI > * 4.2. Flow Identification Mobility Option, page 10, Discard. =C2=A0Shoul= d > you specify whether there is an ICMP response when discarding the > packet? =C2=A0Do you want two different actions, one that discards silent= ly > and one that discards with ICMP unreachable, network administratively > prohibited? =C2=A0I think the later would be useful for p2p-type apps whe= re > you'd like to remove candidate paths as quickly as possible. GT> Not so sure about this. I consider the discard function almost like a firewall....firewalls typically silently discard afaik. > > * 4.2. Flow Identification Mobility Option, page 10. =C2=A0Should you > include a "Forward" action to be consistent with the text in 5.3.2.1 > that mentions an 'Forward' action? > GT> no I will clean up text in 5.3.2.1, which is a remnant from last version. Now we no longer have forward. We indicate it using n-cast and pointing the flow to a single BID. > * 4.2.1. Binding Reference Sub-option, page 11, do you need some error > if the referenced BID does not exist? =C2=A0I noticed that errors for sta= le > FID references had been specified but not BIDs. > GT> added "BID not found" > * 4.4. Flow Bindings entries list and its relationship to Binding > Cache, page 14, "A Flow Descriptor:..." =C2=A0Should this be Discriptor(s= ), > since the format described in 4.2 allows multiple flow description > sub-options for a single flow identification option? > GT> No, only one of these can be in a Flow Identification Option. I will clarify. > * 4.4. Flow Bindings entries list and its relationship to Binding > Cache, page 14, "As an example the following represents an ordered > flow bindings entries table..." =C2=A0Would this sound better as, "As an > example, the following represents an ordered flow binding entry > table..." > GT> OK > * 4.4. Flow Bindings entries list and its relationship to Binding > Cache, page 14, "A valid BID is required to make the entry "active"." > This is inconsistent with Discard flow bindings that are not supposed > to have a valid BID. =C2=A0How about requiring valid BID for discard flow > bindings in 4.2, page 10 instead of updating this text? =C2=A0Otherwise, > 5.2.4. removes flow bindings implicitly when there is a binding update > that does not include them. =C2=A0If there is not a BID associated with a > discard flow binding, how does the HA know which binding update > excludes the flow binding? =C2=A0I guess the other alternative is to expa= nd > the flow binding entry table to include a reference to the binding > update HoA and CoA that created it, but it is not clear that you want > a n-cast type flow binding to disappear when removing the BU for > HoA/CoA that created it. > GT> Good points. I would prefer not to reserve a BID for "Discard" flow bindings. Instead, I will clarify that flow bindings that take BIDs (i.e., other than those with "discard" action) need active BIDs to be active. As already indicated for discard flow bindings, as well as any other flow binding, they are removed by omitting the corresponding FID from a subsequent BU. I will also clarify that deleting BIDs renders flow "n-cast" flow bindings inactive, but does nothing to "discard" flow bindings that in any case are not associated with any BID. > * 5.2.2.1. page 18, mentions a unique priority for each flow binding. > Did you mean to limit a MN to at most 255 flow bindings? =C2=A0It probabl= y > will be less, as configurations will normally include space between > priorities to make it easier to add new rules. =C2=A0Suggest treating thi= s > the same way as BID-PRI where the precedence between same priority is > just (well should be) left unspecified in 4.1. > GT> That was the authors' proposal but we got overwritten by the WG. I still do not like the unique priority per FID but I think it is workable. Spaces are not really required since FIDs can be overwritten at will (at the expense of longer BUs). > * 5.2.2.1, page 18, "if the Action indicated 'Discard', the Binding > Reference sub-option SHOULD NOT be included." =C2=A0How will a node know > which binding update no longer includes this flow binding, if it does > not have a BID? =C2=A0What do you think about removing this bullet? > GT> Flow bindings state is managed based on the FIDs, not the BIDs....so the node will look at the FIDs to see which ones need to be maintained. > * 5.3.3. Receiving BU with Flow Summary Option, page 24, "A > de-registration binding update (with a zero lifetime) would result in > deleting all bindings regardless of the presence of the Flow summary > option." Do you mean to remove all of the BID references in the flow > bindings? =C2=A0At first glance, I thought this meant removing all of the > bindings in the binding cache. =C2=A0There are several references to > "bindings" in the document. =C2=A0Suggest a scrub for all instances of th= e > word "binding" in the document, i.e. page 9, I think you meant to > refer to flow bindings, not bindings, "This field is used to refer to > an existing binding or to create a new binding." > GT> A dereg-BU removes ALL MIPv6 bindings, and all Flow Bindings so 5.3.3 is correct. You point about being careful with the use of the term "binding" vs "flow binding" is well taken though... I went through the document to qualified the term "binding" in several additional places. > * 5.2.4. Removing flow bindings, page 19-20, "Removal of flow binging > entries is performed implicitly by omission of a given FID from a > binding update". =C2=A0Change binging to binding. =C2=A0This really is, "= A > binding update removes its BID from a flow binding implicitly by > omitting its FID in the Flow Identification Summary Mobility Option. > Nodes remove flow binding entries when they no longer have any > associated BIDs." =C2=A0The ensuing text that mentions removing BIDs > associated with a FID references text that describes removing BIDs > entirely, since RFC 5648 does not have the notion of a FID to > selectively remove a particular BID. =C2=A0Suggest rewording to mention > that it is possible to remove BIDs that also implicitly remove the BID > references in the flow binding entry table. =C2=A0I also suggest that you > also add text to remove BIDs from flow bindings when the binding for a > particular BID expires. > GT> I think the draft is clear on this:. a) BU deregistration (RFC3775) removes ALL state, including BID and FID sta= ted b) BID deregistration (RFC5648) removes a specific BID c) In Flow Binding Removals: - If all BIDs associated with an n-cast flow binding are removed the the flow binding becomes inactive - Flow bindings are deleted by omitting their FIDs from next BU. In any case I am rewording the sections you refer to above as per your earlier comments which I think will make this clearer. > * 5.3.2. page 22, "If more than one flow identification option," is, > "in the same BU..." > GT> actualy it should say: If more than one flow identification options in the same BU have the same value in the FID field, all the fl= ow identification options MUST be rejected." > * 5.3.2.1. page 23, "If the Binding Reference sub-option is present > and includes one or more BIDs..." =C2=A0Should you reject a ncast flow > binding that refers to bindings that are not active? =C2=A0Wouldn't this > diminish the utility of ncast if the HA removes a binding that is not > refreshed and the MN sends a refresh referencing that binding? =C2=A0In > this case, the n-cast goes to 0-cast even though n-1 bindings are ok. > Suggest removing this bullet or at least paring it down to an error if > all of the referenced BIDs do not exist. > GT> I am not sure I following you. This only says that when you create a flow binding all the information must be valid, including the BIDs you are listing. I think this is just normal expectation, no?. > * 5.3.3. page 24, "If the value of the FID field is present in the > mobile nodes list of slow binding entries the, home agent SHOULD > refresh the binding entry identified by the FID..." Suggest removing > the refresh term. =C2=A0There was not a lifetime specified in the flow > binding entry table. =C2=A0This might be more consistent as, "... home > agent SHOULD not remove the BIDs associated with the identified > FID..." > GT> Ah, this is again an remnant of an old version. We no longer make any distinction between add and modify requests in the messages. This is purely done based on whether an FID in a BU already exists in the HA or not. If it exist then the entry associated with the FID is modified according to the contents of the BU, oif the FID does not exist then a new entry is added. I will clean up this part of the spec appropriately. > * 5.3.5. page 25, "... or by just ignoring all the flow binding > options." =C2=A0Isn't this inconsistent with the text requiring flow > identification options MUST be included in the Binding Acknowledgment? > =C2=A0Suggest dropping the ignoring text or demote the MUST requirement t= o > a SHOULD. > GT> You are right, I changed MUST to SHOULD. _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From tsirtsis@googlemail.com Wed Oct 21 11:27:39 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F7543A69DB for ; Wed, 21 Oct 2009 11:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_73=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 vR2MjkBxeiwL for ; Wed, 21 Oct 2009 11:27:38 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 686FC3A69DA for ; Wed, 21 Oct 2009 11:27:38 -0700 (PDT) Received: by yxe30 with SMTP id 30so9240085yxe.29 for ; Wed, 21 Oct 2009 11:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Bq1tBQhuxF5J39Vv+zyHLPztGk+MoX0YDoKo765PI/Y=; b=vQpxwQGu7CgZN2Te4ptlEq0PtkeBxcgyx5FKoTeS1Ol3Hh/xKMy48YAAOLtH6nnc7z tTSXol5nRxhs2BJOfnRlrT+P4xAkYYPxk3G0yzaisxFw9EFUdIa46/Ck8oisN2Brop2m R101z/jG/4WKbeBVCjwPEe/9sAqqH67C6y/cs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=UvNtnX4yMN+S8eLgbhDmurq9GgTM6iBLXbRlh6LgWFwF/2NpadD00WfkoK0Ycft1qP 2UPue/Y8NcqnfWG/abnVZRoti0I0mri5qvoYdz3oXTPXdM+q/OQjm5f6cWsaYThXJT/t yqA9smnOFFRB8MtREIBGVqrZ11y05u3CqL3hk= MIME-Version: 1.0 Received: by 10.239.139.84 with SMTP id s20mr679986hbs.110.1256149663097; Wed, 21 Oct 2009 11:27:43 -0700 (PDT) In-Reply-To: <4ACECC69.2080601@sg.panasonic.com> References: <4ACECC69.2080601@sg.panasonic.com> Date: Wed, 21 Oct 2009 19:27:42 +0100 Message-ID: From: George Tsirtsis To: Benjamin Lim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 18:27:39 -0000 Thanks a lot Ben...all comments below resolved....but also see inline. Geroge On Fri, Oct 9, 2009 at 6:38 AM, Benjamin Lim wrote: > Hi, > > I have reviewed the draft and it seems to be in good shape. Some > comments below. > > Comment 1 > -------------- > Reference updates for > I-D.ietf-mext-nemo-v4traversal --> RFC 5555 > I-D.ietf-monami6-multiplecoa --> RFC 5648 > GT> Done. > Comment 2 > -------------- > In section 4.4, it states > "A valid BID is required to make the entry "active". =C2=A0If all of the = BIDs > pointed to by a given entry are not valid BIDs in the binding cache, the > flow binding entry becomes "inactive", in other words it does not affect > data traffic." > > FID-PRI =C2=A0 =C2=A0 FID =C2=A0 =C2=A0Flow Description =C2=A0 =C2=A0BIDs= =C2=A0 =C2=A0Action =C2=A0 =C2=A0 =C2=A0 A/I > =C2=A0 =C2=A0------- =C2=A0 =C2=A0 --- =C2=A0 =C2=A0---------------- =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ---- =C2=A0 =C2=A0 =C2=A0------- =C2=A0 =C2=A0 ---= --- > =C2=A0 =C2=A0 =C2=A0 10 =C2=A0 =C2=A0 =C2=A0 =C2=A04 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 TCP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = 2 =C2=A0 =C2=A0 =C2=A0Forward =C2=A0 =C2=A0 Active > =C2=A0 =C2=A0 =C2=A0 20 =C2=A0 =C2=A0 =C2=A0 =C2=A03 =C2=A0 =C2=A0 =C2=A0= srcAddr=3DIPx =C2=A0 =C2=A0 =C2=A0 N/A =C2=A0 =C2=A0 Discard =C2=A0 =C2=A0= Active > =C2=A0 =C2=A0 =C2=A0 30 =C2=A0 =C2=A0 =C2=A0 =C2=A02 =C2=A0 =C2=A0 =C2=A0= srcAddr=3DIPy =C2=A0 =C2=A0 =C2=A0 =C2=A04 =C2=A0 =C2=A0 =C2=A0Forward =C2= =A0 =C2=A0 Inactive > =C2=A0 =C2=A0 =C2=A0 40 =C2=A0 =C2=A0 =C2=A0 =C2=A05 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 UDP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1,3 =C2= =A0 =C2=A0 N-Cast =C2=A0 =C2=A0 =C2=A0Active > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Ordered Flow Binding Entries > > However, for the above figure, in the second entry, N/A mean no BID > specified. If so, how can this be an active entry as there is no "valid > BID"? I find this confusing. There are two ways to approach this, > > a) associate a BID with the discard action. This means that the > definition of discard action in 4.2 needs to be updated. > b) add more text in 4.4 to say that for discard action even if there is > no BID associated to it, that entry is treated as valid. > GT> Yes, Dave caught that one too. I will do (b). > Comment 3 > -------------- > In section 5.3.2.1, the forward action is not defined in 4.2. From my > reading of 4.2, my understanding is that using n-cast and specifying a > single BID can be implied as the forward action. > GT> Yes true. Fixed. > >> 2 n-cast. =C2=A0This value indicates a request to send the flow to one o= r >> more addresses indicated in the Binding Reference sub-option. One or >> more BIDs MUST be associated with this Action. =C2=A0If only one BID is >> associated with this action then it is essentially a request to >> forward packets to that CoA. =C2=A0Care should be taken when the n-cast >> action is used as some transport layers may not be able to handle >> packet duplication and this can affect their performance. > > > There are two ways to approach this, > a) define action forward > b) drop the text for action forward in 5.3.2.1. > > I prefer b) as I feel n-cast covers the forward action. > GT> I agree. done. > Comment 4 > -------------- > In section 5.3.3, propose to reword the second paragraph to > > >> If the value of any of the FID fields included in the flow summary >> option is not present in the list of flow binding entries for this >> mobile node, the home agent MUST reject this flow binding refresh by >> including a flow identification option in the BA, and setting the FID >> =C2=A0field in the value of the FID that is not found and the Status fie= ld >> =C2=A0to 135 (FID not found). > > > > If the value of any of the FID fields included in the flow summary > option is not present in the list of flow binding entries for this > mobile node, the home agent MUST reject this flow binding refresh by > including a flow identification option in the BA for each FID that is > not found, and setting the FID field with the value of the FID and the > Status field to 135 (FID not found). > > GT> done. > Comment 5 > -------------- > In section 5.3.3, in the third paragraph > >> If the value of the FID field is present in the mobile nodes list of >> slow binding entries the, home agent SHOULD refresh the binding entry >> > s/ slow/ flow > GT> done >> identified by the FID without changing any of the other parameters >> associated with it. > > Regards, > Benjamin Lim > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From tsirtsis@googlemail.com Wed Oct 21 11:36:01 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A73BE3A685C for ; Wed, 21 Oct 2009 11:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69s2RzwwtzAw for ; Wed, 21 Oct 2009 11:36:00 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 7E77E3A67F7 for ; Wed, 21 Oct 2009 11:36:00 -0700 (PDT) Received: by yxe30 with SMTP id 30so9251707yxe.29 for ; Wed, 21 Oct 2009 11:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=2UX1bQ42s3rNiKownsWZ7DBkz6qdDM6vj5ZsPmwn6ik=; b=cbXiqDVIZw3ETl9X+Jhbzh/yHYFv3rWJlLc2SiiLa+ULfjlJFAhXEUUwD4EclVnLFl G+ei37EbPsGu/vs0f2cmYMbrN+sS25L2U0mYIOuapqJfLbngNVJrLvqeiHKnT0uG8Qe5 c+5whd3I09+i0aGVup3/u5Z3tYWVLC8sZnHLU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=N/N0HM3ZI6ABOZBIolD/TP0H0EU20VVDHAyP8NpeV+OkkbNKE93W4ilF4yMjUgN1cQ DRoKu2pe7FcX1LHdJB5QZPHfjsUpMDiScdgGV6QL8SGhohx/HlDYK0AtRL5YnT5xpEdp d0Hlp886I91JP3C5+jgJI0No6Qpgo1vwhv3NA= MIME-Version: 1.0 Received: by 10.239.130.30 with SMTP id 30mr4695hbh.130.1256150165067; Wed, 21 Oct 2009 11:36:05 -0700 (PDT) In-Reply-To: <8FEE029FDE54A941981406081772A58B30F0481576@NALASEXMB09.na.qualcomm.com> References: <8FEE029FDE54A941981406081772A58B30F0481576@NALASEXMB09.na.qualcomm.com> Date: Wed, 21 Oct 2009 19:36:04 +0100 Message-ID: From: George Tsirtsis To: "Sundararajan, Jay Kumar" Content-Type: text/plain; charset=UTF-8 Cc: "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 18:36:01 -0000 Hi Jay, Thanks for the comments. I think I accepted all of them...see below. George On Fri, Oct 9, 2009 at 6:23 PM, Sundararajan, Jay Kumar wrote: > I read the draft and it looks good. Just have a few comments (mostly minor > ones): > > > > Comment 1 > > In page 10, the term "Binding Reference sub-option" is used for the first > time before it is defined. It might be useful to say that it will be defined > later... > > GT> I added a pointer to the sub-option definition > > > > Comment 2 > > Section 5.2.2.2 says: > > "To modify an existing flow binding the mobile node MUST send a binding > update with a flow identification option, with the FID field set to one of > the FID values already in the list of flow binding entries." > > > > I might have missed something, but in this case, what prevents the HA from > sending a failure Status message "135 FID already in use" as mentioned in > Section 5.3.2.1: > > GT> Section 5.3.2.1 is wrong. It is a remnant of the older version when we were indicating ADD vs MODIFY explicitly in the Flow Identification option. Section 5.3.2.1 will be corrected and the error code "FID already in use" will be removed. > > "If the FID field of the flow identification option is already present in > the list of flow binding entries for this mobile node, the home agent MUST > reject this flow binding add request by copying the flow identification > option in the BA, and setting the Status field to 135 (FID already in use)." > > > In other words, how would the receiver distinguish between a modify request > (which should not fail) and an add request with a used FID (which should > fail)? > > GT> As also caught by others, this is another remnant of an older version, but I will correct all this in the new version. According to the decisions we made in the last version of the spec, the HA simply looks at the FIDs in the BU, if it has state for them then this is modification, if it has no state for them it is an addition. > > > > Comment 3 > > In Sections 5.3.2.2 and 5.3.3, the "FID not found" Status is set to 135, > whereas the table in Page 9 says it is 136. > > GT> fixed, actually I will renumber all of them since we have moved things about over time. > > > > Comment 4 > > Section 4.2.2 says "17-32 reserved for Flow Description formats". But the > section on IANA considerations says 16-32. > > GT> I will correct it thanks. > > > > Minor comments: > > 1. Page 6: "ant-replay" -> "anti-replay" > > 2. Page 9: Under FID: "an 16-bit" -> "a 16-bit" > > 3. End of pg 12: "refresing" -> "refreshing" > > 4. Pg 17: "Mobiles nodes" -> "Mobile nodes" > > 5. Pg 18: "Status filed" -> "Status field" > > 6. Section 5.2.4: "bingings" -> "bindings" > > 7. Section 5.3.2.2: "processes" -> "process" > > 8. Section 5.3.3: "slow binding entries the, " -> "flow binding entries, > the" > > 9. Section 5.3.6: End of 1st paragraph: there seems to be an extra "when" > GT> all of these fixed. Thanks! > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From julienl@qualcomm.com Wed Oct 21 13:21:53 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F5428C113 for ; Wed, 21 Oct 2009 13:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.71 X-Spam-Level: X-Spam-Status: No, score=-105.71 tagged_above=-999 required=5 tests=[AWL=0.889, 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 Ug1ou82aU-8E for ; Wed, 21 Oct 2009 13:21:52 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 1AA4E3A67EC for ; Wed, 21 Oct 2009 13:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1256156521; x=1287692521; 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"Laganier,=20Julien"=20 |To:=20Conny=20Larsson=20,=0D =0A=20=20=20=20=20=20=20=20Hesham=20Soliman=0D=0A=09|CC:=20"mext@ietf.org"=20|Date:=20Wed,=2021=20Oct=202009=2013:21:58=20-0700 |Subject:=20RE:=20[MEXT]=20[WGLC]=20draft-ietf-mext-flow- binding-03|Thread-Topic:=20[MEXT]=20[WGLC]=20draft-ietf-m ext-flow-binding-03|Thread-Index:=20AcpSXQnlSzmFEorQS8aDW L3RFwnMewAJbiTw|Message-ID:=20|References: =20=0D=0A=20<4ADF 1E48.5040502@ericsson.com>|In-Reply-To:=20<4ADF1E48.50405 02@ericsson.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5778"=3B=20a=3D"25778104"; bh=RzdbTTuURPmQBG5tFEiuS1SIWDj4EwaDFRa5ZgM+Djo=; b=xuqslAM9T2q7FkANBqRMywDUVWNs9qSTb6m7aC837g4AASiZxMe90RIG U5Kfe1BgRzxa6UdJk+2EV+6DGTTxAp0IDiTwdP87NMCEcnowQCkqxtHkX qg/6cnZCkOL7+0aBdJg2iqoTC469sCcZ6juoSSlRgrud/Nb7aE/M/g2tH E=; X-IronPort-AV: E=McAfee;i="5300,2777,5778"; a="25778104" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2009 13:22:01 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9LKM0DN007489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Oct 2009 13:22:00 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9LKM0NE022261 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 21 Oct 2009 13:22:00 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 21 Oct 2009 13:21:59 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Wed, 21 Oct 2009 13:21:59 -0700 From: "Laganier, Julien" To: Conny Larsson , Hesham Soliman Date: Wed, 21 Oct 2009 13:21:58 -0700 Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpSXQnlSzmFEorQS8aDWL3RFwnMewAJbiTw Message-ID: References: <4ADF1E48.5040502@ericsson.com> In-Reply-To: <4ADF1E48.5040502@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 20:21:53 -0000 Hi Conny, Please see my individual comments below: Conny Larsson wrote: >=20 > Hesham Soliman wrote: > > Hi Conny, > > > > We need the comments now, not after the document is updated :). This > > is WGLC and we're updating the document as a result of reviews. > > > Your draft is only considering the binary flow descriptors and I see no > reason for this limitation. It has previously been suggested that your > draft only should handle the transfer and operation of flow descriptors. > Specific flow descriptor handling should be put in a separate draft. I do not understand your statement that the WG draft considers only binary = flow descriptors. The WG draft does not imply any type of flow descriptor i= n particular, and reserves sub-option types 17-32 for various types of flow= descriptors. > To be more specific. In case of ASCII format there is no need for the > FID and FID-PRI fields in Figure 2. They are only used for the binary > flow descriptors. Besides this all option length fields indicates the > length of the option in 1-octet unit, not 8-octet units. I do not understand why you're tying the need for Flow IDentifier and FID P= riority to a binary format. The Flow IDentifier and FID Priority are in intrinsic part of the flow bind= ing protocol extension considered so far by the WG which implies ordering t= he flow binding rules.=20 The need for them do not depend on the format used to describe how to match= a specific flow aggregate, it is a design choice that has been made. That = a flow binding rule matches a traffic aggregate based on an ASCII or binary= description doesn't change the fact that rules have to be ordered. > The Binding Reference sub-option (section 4.2.1), the Flow Description > sub-option (section 4.2.2) and the Flow Identification Summary option > (section 4.3) are binary specific things and should be taken care of by > that draft, they are not needed for the ASCII format. Same comment as above: - The flow description doesn't imply a specific format:=20 Flow Description The flow description corresponding to the type indicated by the Sub-opt Type field. Flow description is out of scope of this document. The following values are reserved for the sub-option Type values are defined for Flow Description: 17-32 reserved for Flow Description formats. - The flow identification summary doesn't imply a specific format: The Flow Identification Summary Mobility option includes one or more flow identifiers (FIDs) for the purpose of refreshing their state. > Making these changes, and perhaps some minor modifications related to > these changes, would make the draft look much better. I believe it's > doable. At this point in the lifecycle of a WG document (i.e., the WG Last Call) I = don't think we want to change the basics of the flow binding mechanisms, th= at is, that packets are matched against an ordered ruleset. --julien From julienl@qualcomm.com Thu Oct 22 10:20:47 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A90F3A6963 for ; Thu, 22 Oct 2009 10:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.698 X-Spam-Level: X-Spam-Status: No, score=-103.698 tagged_above=-999 required=5 tests=[AWL=-1.099, 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 uKIKnIaGLZ-8 for ; Thu, 22 Oct 2009 10:20:46 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id ECB993A6995 for ; Thu, 22 Oct 2009 10:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1256232056; x=1287768056; 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"Laganier,=20Julien"=20 |To:=20"mext@ietf.org"=20|CC:=20"draft-iet f-mext-flow-binding@tools.ietf.org"=0D=0A=09|Date:=20Thu,=2022=20Oct =202009=2010:20:53=20-0700|Subject:=20RE:=20[WGLC]=20draf t-ietf-mext-flow-binding-03|Thread-Topic:=20[WGLC]=20draf t-ietf-mext-flow-binding-03|Thread-Index:=20AcpG3PrETCpXf QpNQraj6B7QmoF8mwLwae6g|Message-ID:=20 |References:=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5779"=3B=20a=3D"25847369"; bh=JqwhhYhNafClS+odFL7uSWzUBXG7Veq2hgeMxYIaurU=; b=v+wYdHzeT79gzGzjRr1H+Gsqqo5K4tM1NJwWNCTQEbaXXNT/9sxpFTzJ egB3PY3v20wsZQkpohDbCw8AV8p80hPdAcOQAfNDTI5xAqeNxwXQkcweM Lshf6VzvXfybELTkVFe23lqdy3e+ASXbgwxBANOF5iko8Wb0DFcU8Cn7q s=; X-IronPort-AV: E=McAfee;i="5300,2777,5779"; a="25847369" 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; 22 Oct 2009 10:20:55 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9MHKtlC010195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2009 10:20:55 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9MHKsqU025304 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 22 Oct 2009 10:20:55 -0700 (PDT) Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 22 Oct 2009 10:20:55 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Thu, 22 Oct 2009 10:20:54 -0700 From: "Laganier, Julien" To: "mext@ietf.org" Date: Thu, 22 Oct 2009 10:20:53 -0700 Thread-Topic: [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpG3PrETCpXfQpNQraj6B7QmoF8mwLwae6g Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-mext-flow-binding@tools.ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 17:20:47 -0000 Folks, Please find below my _individual_ WGLC comments: As we've discussed in the past I think the terminology is misleading and we= had agreed to fix it. The draft hasn't been updated since then, however, s= o I'm repeating my comments in the WGLC.=20 The current flow description can catches traffic to many destination, e.g.,= HTTP traffic to any destination, yet the current definition of flow talks = about packet exchanged between two nodes:=20 Flow: A flow is identified as a set of data packets that are exchanged between two nodes and match a given flow description I think it is fair to say that the basic object that this specification man= ipulates is a "bunch of flows" rather than a flow. So I think we should mak= e the following easy change and renaming in our definitions and terminology= , it will make the specification more consistent and easier to read without= entailing changes to the protocol mechanism: Flow:=20 (something ala RFC 2460, e.g.) a sequence of packets sent from a particular source to a particular (unicast or multicast) destination for which a MN desires=20 special handling by intervening MIPv6 peers, being it the HA or the CN. =20 Flow Description -> Traffic Description/Selector (I don't care which one= we pick, traffic selector is used by IPsec already with exactly the same m= eaning that here):=20 a piece of information that identifies one or more flows. The identification is based on various fields of the=20 network and transport layer headers, such as the source address, the destination port, the protocol number, the=20 DSCP value, etc. Flow Identification -> Traffic Identification Flow Identifier -> Traffic Identifier:=20 an unsigned integer used as a reference to a particular Traffic Description/Selector. Flow Binding -> Traffic Binding:=20 an association between a traffic description/selector and=20 an action (Forward or Discard). An IP packet that matches=20 the traffic description/selector will be processed according to the action. Note above, the Flow identifier doesn't need to be included in the definiti= on of a binding. Also I prefer to use "Forward" rather than "n-cast", since= Forward is clear and does not necessarily imply that the packet is only fo= rwarded in one direction. --julien From julienl@qualcomm.com Thu Oct 22 15:17:59 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6144D28C180 for ; Thu, 22 Oct 2009 15:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.579 X-Spam-Level: X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=-0.980, 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 kzWKyC9Cufcq for ; Thu, 22 Oct 2009 15:17:58 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 93DF028C117 for ; Thu, 22 Oct 2009 15:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1256249888; x=1287785888; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"mext@ietf.org"=20|CC:=20"marcelo@i t.uc3m.es"=20|Date:=20Thu,=2022=20Oct =202009=2015:18:05=20-0700|Subject:=20MEXT=20agenda |Thread-Topic:=20MEXT=20agenda|Thread-Index:=20AcpTZYa2W9 6Od5UISB2NvvShZtq7/A=3D=3D|Message-ID:=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,5779"=3B=20a=3D"25867554"; bh=OUvd2LwTIOPBVM92OthJoUVWzoRxz44Y0ce+MSKFGpc=; b=t9z+VgJMQdNuGbQm3MpAf40KiRCZY9pp3Odf/kZ0z87RfNH0k2E3Tk9l cAWu8XvE6IFLQxbRlq1XJzLk+BtUCpe8pkaMmWLEs7CNW0Picg+ZPZIbL EidxxSmAjLJRA9Hei6JaIWX9wWEtaKtIMFpZupKiJhryNldwQNFS8WpNk 0=; X-IronPort-AV: E=McAfee;i="5300,2777,5779"; a="25867554" 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; 22 Oct 2009 15:18:08 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9MMI8um018960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2009 15:18:08 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9MMI7iD008333 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 22 Oct 2009 15:18:08 -0700 Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 22 Oct 2009 15:18:07 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Thu, 22 Oct 2009 15:18:07 -0700 From: "Laganier, Julien" To: "mext@ietf.org" Date: Thu, 22 Oct 2009 15:18:05 -0700 Thread-Topic: MEXT agenda Thread-Index: AcpTZYa2W96Od5UISB2NvvShZtq7/A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MEXT] MEXT agenda X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 22:17:59 -0000 Folks, Apologize for not having posted an agenda earlier. This is to let you know = that we're working on it and will upload it tomorrow. --julien & marcelo From charles.perkins@earthlink.net Thu Oct 22 23:27:30 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADAC93A67DB for ; Thu, 22 Oct 2009 23:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGUPSXeqBGiX for ; Thu, 22 Oct 2009 23:27:30 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 080713A6774 for ; Thu, 22 Oct 2009 23:27:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ZGjYRwONhW2iXMQg3W3HtsSInA4dQSg3hndFijHG8/rIvdIlleegppZnqtmuZCHd; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.102]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N1Dci-00028V-1z; Fri, 23 Oct 2009 02:27:40 -0400 Message-ID: <4AE14CDB.3080801@earthlink.net> Date: Thu, 22 Oct 2009 23:27:39 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Laganier, Julien" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f523171d31bb8acab8c3a20e1ef84b41a2d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: "mext@ietf.org" Subject: Re: [MEXT] MEXT agenda X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 06:27:30 -0000 Hello Julien, Could I have 3 minutes to discuss the recent draft proposing the new MN identifiers? Regards, Charlie P. Laganier, Julien wrote: > Folks, > > Apologize for not having posted an agenda earlier. This is to let you know that we're working on it and will upload it tomorrow. > > --julien & marcelo > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > From tsirtsis@googlemail.com Fri Oct 23 02:00:16 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBCC028C12A for ; Fri, 23 Oct 2009 02:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNUGj8xU8rRb for ; Fri, 23 Oct 2009 02:00:14 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 4564828C107 for ; Fri, 23 Oct 2009 02:00:11 -0700 (PDT) Received: by fxm18 with SMTP id 18so10077893fxm.37 for ; Fri, 23 Oct 2009 02:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qYOA7+RiVhZlOZjdxu1h2cPmShnhInD3sOUIc7s06Ls=; b=Kxo5xOPUmXu134IpbbsBS1wjrov2yhnat9hDkNzcut6pcpNZBSO8yHJtZcecSid0OP qA/W9dVIM3fILcMeUTbZq81SwJwBLTrpZrPyFOsKZFFSdmknbx4BBNukJzCLnEtv6+83 pmJ9B8J+Liub44Jcl9kmmp9269ciObptEOrL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lQj8lZoO91QQs5Gsui+HZHdSwM1PiboyzOulIrjP3ndKkrnhVyx1QRaWaqcjo/XDXq Bz90FgArVl36GIEPOi5UloBgcqJcxo1uH8GFnVactpd8lxiL3rsKYAvOkAhKoRaGI/Fu DObDubGB0UQexv3oMfYDaUhJIPXx83tJr/Pgs= MIME-Version: 1.0 Received: by 10.239.183.22 with SMTP id s22mr980281hbg.6.1256288417167; Fri, 23 Oct 2009 02:00:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Oct 2009 10:00:17 +0100 Message-ID: From: George Tsirtsis To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: julienl@qualcomm.com, mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 09:00:17 -0000 Hi Raj, Thanks for the very detailed review, it is appreciated. I have taken on board most of your comments. See also inline. On Fri, Oct 9, 2009 at 11:36 PM, wrote: > > Hello, > > The document needs at least another revision before it would be ready > to be sent to the IESG. > > Below is a review of the Flow bindings I-D > : > > - Update reference DSMIPv6 [I-D.ietf-mext-nemo-v4traversal] to RFC5555 > > - Update reference [I-D.ietf-monami6-multiplecoa] to RFC5648 > GT> done >> =C2=A0 In this document, a flow is defined as a set of IP packets matchi= ng a >> =C2=A0 flow descriptor. > > The definition in the terminology section is better suited to describe > a flow. A flow can be identified by a flow descriptor but that is not > the definition of what a flow is. > >> =C2=A0 This specification, however, does not define flow >> =C2=A0 descriptors and it is assumed that one or more ways of defining f= low >> =C2=A0 descriptors are going to be defined in other specifications. > > The specification now exists and hence should be referenced, i.e I-D: > draft-ietf-mext-binary-ts > GT> will do > >> =C2=A0 =C2=A0 Flow Identifier: An unsigned integer. > > This definition really does not explain what a Flow ID is. Suggested > text: "A flow identifier uniquely identifies a flow associated with an > MN. It is generated by the MN and is cached in the flow binding list > maintained by the MN, HA, CN or MAP." > GT> nice, thanks. >> =C2=A0 =C2=A0 BID-PRI >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is a 7-bit unsigned integer placing eac= h BID to a relative >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 priority with other registered BIDs. =C2=A0V= alue "0" is reserved. =C2=A0A >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 lower number in this field indicates higher = priority, while >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 BIDs with the same BID-PRI value have equal = priority. =C2=A0This is >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 consistent with current practice in packet c= lassifiers. > > I dont see the value in having a priority associated with the > BID. This I-D proposes the creation of an ordered BID list. The reason > for having an ordered list is to process the packet with the BID which > has the highest priority in case there is no match for any Flow > ID. This is not required. The HA can decide to forward it to any CoA > based on some default binding cache entry or policy that it has. > I would suggest not modifying the Binding Identifier mobility option > as specified in RFC5648. > GT> I think Hesham responded to this but the bottom line is that it is not reasonable for the MN to be able to route any specific flow as it wants, but not being able to indicate what the default CoA should be. >> =C2=A0 =C2=A0 =C2=A0FID-PRI >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is an unsigned 8-bit priority field to = indicate the >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 priority of a particular option. =C2=A0This = field is needed in cases >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 where two different flow descriptions in two= different options >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 overlap. =C2=A0The priority field decides wh= ich policy should be in >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 those cases. =C2=A0A lower number in this fi= eld indicates a higher >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 priority. > > I guess multiple FIDs can have the same priority, right? Is there a > default value in case no priority is assigned by the MN? Or because > you are creating an ordered list of FIDs, the priority for each FID is > unique? Also it would be good to reserve priority 0 for future use. > Some additional text to clarify this might be useful. > GT> I have already dealt with this in another e-mail, but each flow binding has a unique FID-PRI. I will reserve value 0 as you suggest. >> =C2=A0 =C2=A0 =C2=A0Action >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 This field specifies the action that needs t= o be taken by the >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 receiver of the binding update containing th= e flow >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 identification option. =C2=A0The details of = these requests are >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 discussed below. > > - s/This field specifies/This 8 bit unsigned integer field specifies GT> ok > - Can you include the values defined for the actions further below in > =C2=A0the section immediately below the Action field definition? Makes > =C2=A0reading easier. GT> Yes, done. > - a/Action value 0 is reserved. GT> done > - In the example of Flow binding entries shown in Sec 4.4, the action > =C2=A0field also includes Forward (in addition to discard and > =C2=A0n-cast). Does this imply that not indicating anything in the Action > =C2=A0field equates to Forwarding? Or should there be a separate value > =C2=A0reserved for forwarding as well? Why not be explicit and just assig= n > =C2=A0a value for forwarding as well. > GT> Yes, caught by others too...as I said before it s remnant from an older version. which I have now fixed. >> Rsvd >> Status > > Specify these are 8 bit unsigned integer fields just to be explicit. > GT> A bit extreme for the reserved bits but will do for Status >> =C2=A0 A number of sub-options can follow the option defined in this >> =C2=A0 section. > > Rephrase as : A number of sub-options can follow the Flow > Identification mobility option defined in this section. > GT> done >>4.2.1. =C2=A0Binding Reference Sub-option >> =C2=A0This section introduces the Binding Reference sub-option, which ma= y >> =C2=A0 be included in the Flow identification option. > > Is it really a MAY? If the MN is adding a new flow ID, the binding > reference sub-option is mandatory especially if the action is set to > Forward. From the processing rules defined in Sec 5.3.2.1 it seems > that the binding reference sub-option MUST be included and SHOULD have > a valid BID. > > Adding a flow ID that does not have a valid matching BID in the BC > does not make much sense. > GT> It does when Action=3DDiscard. > s/which may be included in the Flow identification option./which MUST > be included in the Flow identification mobility option. > >>4.2.2. =C2=A0Flow Description Sub-option >> =C2=A0 =C2=A0 =C2=A0Sub-opt Type >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indicates the Sub-option type. =C2=A0For the= flow description sub- >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 option, this field SHOULD be set to one of t= he FD types defined >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 below. > > - Move the text defining the suboptions to follow the definition of the > =C2=A0suboption. GT> OK > - s/Indicates the/8 bit unsigned integer which indicates the GT> OK > - What is really implied by: "17-32 reserved for Flow Description > =C2=A0formats"? > =C2=A0Do these values have any predefined flow descriptions? Or does it > =C2=A0imply that these values cannot be used by the MN? > GT> This is the by product of splitting Traffic Selector (ex. Flow Description) definitions out of the Flow Bindings draft. It simply reserves some Sub-Type values for use by Traffic Selectors. draft-ietf-mext-binary-ts will for example use some of these values. Another way would be to define the TS sub-types for binary TSs only for now...which would probably make things clearer. In this case only the body of these TSs would be defined in a separate draft. >> =C2=A0 =C2=A0 =C2=A0Flow Description >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 The flow description corresponding to the ty= pe indicated by the >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sub-opt Type field. =C2=A0Flow description i= s out of scope of this >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 document. > > In I-D: draft-ietf-mext-binary-ts-00 Sec 3 says " > =C2=A0 [I-D.ietf-mext-flow-binding] defines the format for the traffic > =C2=A0 selector sub-option." > > There is no traffic selector sub-option defined in the flow-binding > ID. The closest match I guess is the flow description field in the > flow-description sub-option. Revise the flow description text and also > check to see if the format of the traffic selector options fit into > the flow description field. > GT> Yes, we renamed Flow Description to Traffic Selector after the publication of v03 of the draft. Next version will use the term Traffic Selector, instead of Flow Description. >>4.3. =C2=A0Flow Identification Summary Mobility Option > > Is this option really required? The only reason I can gather from the > I-D is that every BU MUST include a list of all the FIDs that have > been added otheriwse they will be deleted. And hence the summary > option is an optimized way of sending a list of all the FIDs. > >> =C2=A0 The Flow Identification Summary Mobility option includes one or m= ore >> =C2=A0 flow identifiers (FIDs) for the purpose of refresing their state > > Why do you need to refresh the state of the FIDs? They do not have a > lifetime. If a BU sent to the HA for example were to deprecate a BID > (interface/CoA no longer being available), the BU could also include > the FID options to modify the FIDs which use that BID. If an MN is > simply sending a BU to refresh its lifetime associated with one or > more CoAs, there is no reason to include the FID summary mobility > option. > GT> Hesham dealt with this point. >> =C2=A0 The binding cache was then >> =C2=A0 extended by [I-D.ietf-monami6-multiplecoa] to include more than o= ne >> =C2=A0 care-of addresses and to associate each of them with a Binding >> =C2=A0 Identifier (BID). > > s/The binding cache was then/The binding cache has been > Also reference the MCoA RFC instead. > GT> OK >> =C2=A0 =C2=A0 =C2=A0* =C2=A0Active/Inactive flag: This flag indicates wh= ether the entry is >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 active or inactive. > > What does it mean when the entry is set as Inactive? Does it imply > that the BID is invalid? In the example shown in this section what > does the 3rd entry which is inactive imply? The MN does not specify in > the FID option sent in the BU whether a flow binding is active or > inactive. So how is this flag set and under what conditions? > GT> A BID is becoming invalid when it is deregistered. in other words, if an MN creates a Flow Binding and points it to BID1, but then some time later it deregisters BID1, then we say that the flow binding pointing to BID1 (assuming it only points to BID1) becomes inactive....which means that the HA keeps the flow binding state but does not use it to match packets with This is done in anticipation of the fact that CoAs might come and go, and we would like to avoid having the M N to have to keep reregistering flow bindings (with length TSs) just because a BID had to be removed and be replaced by a new one a few seconds later. >> =C2=A0 If all of the >> =C2=A0 BIDs pointed to by a given entry are not valid BIDs in the bindin= g >> =C2=A0 cache, the flow binding entry becomes "inactive", in other words = it >> =C2=A0 does not affect data traffic. > > If a BID is not valid, then the entry in the flow binding list should > be deprecated. Why would you have an entry in the flow binding list > when there is no valid BID in the BC? > Invalid BIDs should be treated as an error case. In the protocol > operations section the ID says that the HA will reject the addition of > a FID if the BID specified in it is invalid. > GT> See above >> =C2=A0The third entry is marked as Inactive since the BID 4 does not exi= st >> =C2=A0 in the ordered list of BID entries below. =C2=A0Inactive entries = do not >> =C2=A0 affect traffic, i.e., packets are not matched against them. > > See above reasoning. No reason to have such an entry. Should be viewed > as an error case. > GT> Its not an error case, see above. >> Ordered BID Entries > > As stated earlier as well, there is really no need to order the > BIDs. Assigning a priority to the BIDs by modifying the BID Mbility > option is not required. Flow mobility works without assigning > priorities to BIDs. > >> =C2=A0 Finally any remaining packets that do not match any of the entrie= s >> =C2=A0 above will be simply forwarded to the care-of address indicated b= y >> =C2=A0 the highest order BID in the table below. > > For the case where there is no matching FID, the HA/CN/MAP can handle > it based on policy or forward to a default CoA. > GT> I think we have answered this. >> =C2=A0 As indicated earlier the >> =C2=A0 flow description itself is defined in another document. > > Reference draft-ietf-mext-binary-ts > GT> OK >>5.1.1. =C2=A0Preferred Care-of address >> >> =C2=A0 Any node that supports this specification MUST maintain an ordere= d >> =C2=A0 list of care-of addresses for each mobile node it maintains a lis= t of >> =C2=A0 flow bindings for. =C2=A0The ordered list of care-of addresses is= built >> =C2=A0 based on the BID-PRI field of the Binding Identifier option (see >> =C2=A0 Section 4.1). >> >> =C2=A0 The ordered list of BIDs is used to determine how to forward a pa= cket >> =C2=A0 to a given mobile node when the packet does not match any of the = flow >> =C2=A0 binding entries defined in Section 4.4. =C2=A0A packet that does = not match >> =C2=A0 any of the flow binding entries SHOULD be forwarded to the care-o= f >> =C2=A0 address identified by the BID with the highest priority i.e., low= est >> =C2=A0 BID-PRI value. > > See reasons above why BID-PRI is not needed and how packets which do > not match any FIDs can be handled in a more simpler/implementation > specific manner. > GT> See above >> =C2=A0 In other words, two flow >> =C2=A0 identification options in the same message can not be about the s= ame >> =C2=A0 flow binding. > > s/can not be/MUST not be > GT> There is already a "MUST" about this in the previous sentence. "More than one flow identification options MAY be included in the same binding update but each of them MU= ST include a different FID.". The sentence you quoted is just further explanation. >> =C2=A0 All flow binding state MUST be refreshed in every binding update = the >> =C2=A0 mobile node sends. =C2=A0Any previously registered flow binding t= hat is >> =C2=A0 not included in a given binding update will be deleted. =C2=A0So,= any flow >> =C2=A0 bindings that are not added or modified by a flow identification >> =C2=A0 option, but have previously registered and need to be maintained = MUST >> =C2=A0 be included in a flow summary option. =C2=A0Only one flow summary= option >> =C2=A0 can be included in a given binding update. > > This is suboptimal. Why do you need to include the FID options in > every BU. The MN may be sending a BU to refresh the lifetime of a CoA > or adding a new CoA etc. Requiring that FID options be carried in > every BU even when the FID option does not have any implication is > simply an overhead. Additionally there is no reason to keep refreshing > FIDs. > GT> Hesham dealt with this point too. >> =C2=A0 When the mobile node sends a binding update it MUST refresh all f= low >> =C2=A0 bindings it wants to maintain even if it does not want to change = any >> =C2=A0 of their parameters. > > Why? > GT> See Hesham's e-mail >>5.2.4. =C2=A0Removing flow bindings >> >> =C2=A0 Removal of flow binging entries is performed implicitly by omissi= on >> =C2=A0 of a given FID from a binding update. > > It would be better to have an explicit flag in the Flow ID mobility > option whether the operation is an add/modify/delete rather than this > implicit mechanism. Also you would avoid having to send the flow > summary option as a means to deprecate FIDs. > GT> This is how it was earlier and the authors and WG decided to change it. The current mechanism is actually more natural to the normal MIPv6 operations. Beleive me we went through the exercise with add/modify/delete and it got rather complex without any benefit. See also below when I summarize the current technique which I think is very simple. >> =C2=A0 When all the BIDs associated with a flow binding are removed, the >> =C2=A0 flow binding MUST be marked as inactive in the list of flow bindi= ng >> =C2=A0 entries as shown in Section 4.4. > > If all BIDs are removed and the rule is other than discard, the flow > binding itself should be deprecated. Why keep such a flow binding? > GT> As I said so that the MN does not have to keep sending a Traffic Selector for flows (especially think long term ones) just because a BID was temporarily removed. >> =C2=A0 If the FID field of the flow identification option is already pre= sent >> =C2=A0 in the list of flow binding entries for this mobile node, the hom= e >> =C2=A0 agent MUST reject this flow binding add request by copying the fl= ow >> =C2=A0 identification option in the BA, and setting the Status field to = 135 >> =C2=A0 (FID already in use). > > Why? It could be a modify operation for an existing FID? How do you > specify whether an operation is add or modify? > An HA which receives a BU with a FID which already exists for that MN > is simply viewed as a modify operation, right? > GT> This is a bug so I am correcting the text. The mechanism is very simple and straightforward. When a BU is received the HA looks at the list of FIDs. - If for a given FID the HA already has state, the flow binding in the BU replaces the flow binding in the HA (i.e., this is a Modify). - If for a given FID the HA does not have state, then the flow binding is added to the HA (i.e., this is an addition), - If the HA has flow bindings with FIDs that are not included in a BU, the flow bindings are removed from the HA (i.e., this is a delete) >> =C2=A0 A de-registration binding >> =C2=A0 update (with a zero lifetime) would result in deleting all bindin= gs >> =C2=A0 regardless of the presence of the Flow summary option. > > It would be useful to include a section which explains what happens > when the MN returns to its home link and deregisters. > GT> Good idea. I will add text explaining that returning home is performed as per RFC3775 and RFC5648...something like the following:.
This specification is compatible to the home registr= ation procedures defined in an= d . More specifically, if the= mobile node performes an style deregistration, all of its bindings, including flow bindings are deleted. If the mobile node, however, performs an style home registration, then the home link is associated with= a specific BID and so, as far as this specification i= s concerned, it is treated as any other link associat= ed with a given BID.
>> =C2=A0If the value of the FID field is present in the mobile nodes list = of >> =C2=A0 slow binding entries the, home agent SHOULD refresh the binding e= ntry >> =C2=A0 identified by the FID without changing any of the other parameter= s >> =C2=A0 associated with it. > > slow binding entries? ;) > GT> yes...very slow ;-) >> =C2=A0 If, however, the action >> =C2=A0 indicated in an entry of the list of flow bindings is "n-cast", t= he >> =C2=A0 entry must indicated a BID. > > s/the entry must indicated a BID/the entry must indicate more than one > valid BID. > GT> ok >> =C2=A0 If none of the >> =C2=A0 BIDs pointed to in a flow binding entry is valid then the entry i= s >> =C2=A0 considered to be inactive (as defined in Section 4.4) and is skip= ped. >> =C2=A0 In other words packets should not be matched against that entry. > > Should that Flow binding be deprecated? > GT> it just become inactive as explained above. > -Raj > > > > On 10/6/09 6:30 PM, "ext Laganier, Julien" wrote: > >> Folks, >> >> Hereby we're starting a two weeks WGLC on our "Flow Bindings in Mobile I= Pv6 >> and NEMO Basic Support" document, available at the following URL: >> >> >> >> Please review the specification, post your comments to the mailing list,= and >> state whether or not you think the document is ready to be forwarded to = IESG >> before 2009-10-20 6:00PM PST. >> >> Thank you for your support. >> >> --julien & marcelo, MEXT chairs >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From tsirtsis@googlemail.com Fri Oct 23 02:07:40 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFD7628C0F8 for ; Fri, 23 Oct 2009 02:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haps6yNVslF4 for ; Fri, 23 Oct 2009 02:07:39 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id A5ED828C0F5 for ; Fri, 23 Oct 2009 02:07:39 -0700 (PDT) Received: by fxm18 with SMTP id 18so10083934fxm.37 for ; Fri, 23 Oct 2009 02:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bcwFJLUjWXIXPJHDoVjw11S5w9DtB7YQm66inxqXy48=; b=RL0IGvLJdbuh22R7C0DdpL8pOkXqXX0WDYNVAzZzzsnmvYbFT7ZEMoI4rtq+BPBvfZ Z6HZUvWFjSYiq5P22mSvnzb6a0kWukvj2ASh6amgobckk93ex/qNFTa3o2Yh+h28uHWg fbkCtZxlxa8+bB2vhG+dZP7n84VkuLPnVySSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gAFKcOE0mibWbq6GZRTpTXjPtGCdTCQQBKZpMbPHu+SAZHBFbXZiflXx6aJpo/GW9l SkdHJPthcDU9vVg6J2J7SaihN7achuYU20q7qxpDWdbfGhlGHSj06Tox1rb4E0SttoaG LOdYhBP2QFX4AvqetYMfnG6day0Ihy98SV2Hw= MIME-Version: 1.0 Received: by 10.239.145.15 with SMTP id q15mr956569hba.121.1256288869420; Fri, 23 Oct 2009 02:07:49 -0700 (PDT) In-Reply-To: References: <4ADCCB1D.2020705@ericsson.com> Date: Fri, 23 Oct 2009 10:07:49 +0100 Message-ID: From: George Tsirtsis To: Yuri Ismailov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Laganier, Julien" , mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 09:07:40 -0000 Hi Yuri, Comments inline... On Tue, Oct 20, 2009 at 8:55 AM, Yuri Ismailov wrote: > Hi, > after re-reading the draft come up with the comment on "Discard" action i= n > "Flow Identification Mobility Option" > I suggest either to extend the paragraph in the section 4.2 or add a > separate subsection clarifying behavior of MN and HA before and after the > "Discard" action was issued by MN. > > Below are the issues which=C2=A0are proposed to=C2=A0be addressed in the = text. > > 1.The case when installed FID represent ranges of port numbers and IP > addresses. If MN decides to discard a particular flow within the range th= en > before that a correspondent FID should be installed in the HA. Otherwise > "136 FID=C2=A0not found" will be returned from HA. > GT> If the MN wants to discard a particular flow within a range of previously registered flows, it needs to either split the range it two parts, or even better, use a higher FID-PRI for the discard flow so that packets get matched against it before they get matched against the range. > 2. Specify the time interval for how long time the "Discard" state will b= e > active in HA.=C2=A0This is necessary because there is no "un-discard" mes= sage > sent from MN. > GT> Flow bindings share the same lifetime with the BU. There is no flow binding-specific lifetime. If an MN wants to remove a flow binding it sends a BU which does not include the corresponding FID. > 3. Add a disclaimer that for some protocols, like TCP, "Discard" action m= ay > lead to hanging up the connection at CN and should be used responsibly. > GT> Discarding packets will drop connections....yes...I do not think there is anything to say here. > > Regards > Yuri > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From tsirtsis@googlemail.com Fri Oct 23 02:24:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23CB83A6885 for ; Fri, 23 Oct 2009 02:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4E0b6dGCZvVT for ; Fri, 23 Oct 2009 02:24:24 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 3803F3A677C for ; Fri, 23 Oct 2009 02:24:22 -0700 (PDT) Received: by fxm18 with SMTP id 18so10096912fxm.37 for ; Fri, 23 Oct 2009 02:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hdrEzaMFWhKhz7EACbxp4yQw/o65OMf3pLcPTrkH4D8=; b=ZtQEn+IESmonK+bwQYpO7lZ9zgL3ZpeJxv3j6naKce4Dn1zKq1vrxHSWCpOtyWmq6M pmMp7xonXWyYnMjRfuSVe/RRYYGJIdELIM/EhtVZ5zZfzVTe9d6MSFgdwQr2AJSiIOML TOixL9RKhy8vCDjgvgsBEuRWYgKrAYWIcHMk4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fSLonQBAMf9SW8xFsTBfas3Z9bDA6XA/RzR0C278z5aO8DWnqbzH9YAjSXq8H1NQVx f/s1PP6qNYJoOGQwcNf6ru6fJWqQs/Pe/Wi3AHw08LFKvOtY6WlQ7aw652XXIjjXZ3pW aumTcDJto+G/3pZ4dEmk2W90EccBhXa/vdVig= MIME-Version: 1.0 Received: by 10.239.139.209 with SMTP id u17mr908892hbu.79.1256289869766; Fri, 23 Oct 2009 02:24:29 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Oct 2009 10:24:29 +0100 Message-ID: From: George Tsirtsis To: "Laganier, Julien" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-mext-flow-binding@tools.ietf.org" , "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 09:24:25 -0000 Julien, I propose the following which I think addresses the terminology issues but is also consistent with the rest of the document. Flow: A flow is as a set of data packets that are exchanged between two nodes. In the context of this specification the term "flow" is some times used to refer to a plurality of flows as well as a single flow. Traffic Selector: Information that identifies one or= more flows. Flow binding: It consists of a traffic selector, and= an action. IP packets from one or more flows that matc= h the traffic selector associated with the flow binding, = are processed according to the action associated with t= he same flow binding. Flow Identifier: A flow identifier uniquely identifi= es a flow binding associated with a mobile node. It is generated by a mobile node and is cached in the tab= le of flow binding entries maintained by the MN, HA, CN o= r MAP. WRT to the use of the term "n-cast" vs "forward" I am fine with changing it to "Forward" which I agree makes more sense. In an effort to avoid an endless/pointless discussion about it, however, I would like the chairs to reassure me that I will not have to change it back again :-). George On Thu, Oct 22, 2009 at 6:20 PM, Laganier, Julien wr= ote: > Folks, > > Please find below my _individual_ WGLC comments: > > As we've discussed in the past I think the terminology is misleading and = we had agreed to fix it. The draft hasn't been updated since then, however,= so I'm repeating my comments in the WGLC. > > The current flow description can catches traffic to many destination, e.g= ., HTTP traffic to any destination, yet the current definition of flow talk= s about packet exchanged between two nodes: > > =C2=A0 =C2=A0 =C2=A0Flow: A flow is identified as a set of data packets t= hat are > =C2=A0 =C2=A0 =C2=A0exchanged between two nodes and match a given flow de= scription > > I think it is fair to say that the basic object that this specification m= anipulates is a "bunch of flows" rather than a flow. So I think we should m= ake the following easy change and renaming in our definitions and terminolo= gy, it will make the specification more consistent and easier to read witho= ut entailing changes to the protocol mechanism: > > =C2=A0 Flow: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 (something ala RFC 2460, e.g.) a sequence of = packets > =C2=A0 =C2=A0 =C2=A0 =C2=A0 sent from a particular source to a particular= (unicast > =C2=A0 =C2=A0 =C2=A0 =C2=A0 or multicast) destination for which a MN desi= res > =C2=A0 =C2=A0 =C2=A0 =C2=A0 special handling by intervening MIPv6 peers, = being it > =C2=A0 =C2=A0 =C2=A0 =C2=A0 the HA or the CN. > > =C2=A0 Flow Description -> Traffic Description/Selector (I don't care whi= ch one we pick, traffic selector is used by IPsec already with exactly the = same meaning that here): > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 a piece of information that identifies one or= more flows. > =C2=A0 =C2=A0 =C2=A0 =C2=A0 The identification is based on various fields= of the > =C2=A0 =C2=A0 =C2=A0 =C2=A0 network and transport layer headers, such as = the source > =C2=A0 =C2=A0 =C2=A0 =C2=A0 address, the destination port, the protocol n= umber, the > =C2=A0 =C2=A0 =C2=A0 =C2=A0 DSCP value, etc. > > =C2=A0 Flow Identification -> Traffic Identification > > =C2=A0 Flow Identifier -> Traffic Identifier: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 an unsigned integer used as a reference to a = particular > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Traffic Description/Selector. > > =C2=A0 Flow Binding -> Traffic Binding: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0an association between a traffic description/s= elector and > =C2=A0 =C2=A0 =C2=A0 =C2=A0an action (Forward or Discard). =C2=A0An IP pa= cket that matches > =C2=A0 =C2=A0 =C2=A0 =C2=A0the traffic description/selector will be proce= ssed according > =C2=A0 =C2=A0 =C2=A0 =C2=A0to the action. > > Note above, the Flow identifier doesn't need to be included in the defini= tion of a binding. Also I prefer to use "Forward" rather than "n-cast", sin= ce Forward is clear and does not necessarily imply that the packet is only = forwarded in one direction. > > --julien > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From yuri.ismailov@ericsson.com Fri Oct 23 05:19:54 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE093A68C7 for ; Fri, 23 Oct 2009 05:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 kQCor4RBD1Jt for ; Fri, 23 Oct 2009 05:19:53 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EC8F53A6358 for ; Fri, 23 Oct 2009 05:19:52 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-56-4ae19f72e2b4 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 15.D1.24026.27F91EA4; Fri, 23 Oct 2009 14:20:02 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 14:20:01 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Oct 2009 14:20:01 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpTxrYB40htjVSIQ6eOPm+zzytv2AAEIDwg References: <4ADCCB1D.2020705@ericsson.com> From: "Yuri Ismailov" To: "George Tsirtsis" X-OriginalArrivalTime: 23 Oct 2009 12:20:01.0482 (UTC) FILETIME=[24DBFAA0:01CA53DB] X-Brightmail-Tracker: AAAAAA== Cc: "Laganier, Julien" , mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 12:19:54 -0000 Hi Goerge, Thanks for the answers, What I did not understand if there will be some clarification text in = the draft around "discard" action or all that is obvious and does not = require any changes? My comment was that some additional text is needed. I do not think your clarification about using FID-PRI is quite clear. = The reason is that there is no FID for a particular flow within the = range There is only a FID for the whole range of port numbers and/or IP = addresses. Surprized that disclaimer for n-cast about carefull use is in the text = and about disclaimer for "discard" you just say "I do not think there is anything to say here." Still the question is will there be = related text? Regards Yuri -----Original Message----- From: George Tsirtsis [mailto:tsirtsis@googlemail.com]=20 Sent: Friday, October 23, 2009 11:08 AM To: Yuri Ismailov Cc: Laganier, Julien; mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Hi Yuri, Comments inline... On Tue, Oct 20, 2009 at 8:55 AM, Yuri Ismailov = wrote: > Hi, > after re-reading the draft come up with the comment on "Discard"=20 > action in "Flow Identification Mobility Option" > I suggest either to extend the paragraph in the section 4.2 or add a=20 > separate subsection clarifying behavior of MN and HA before and after=20 > the "Discard" action was issued by MN. > > Below are the issues which=A0are proposed to=A0be addressed in the = text. > > 1.The case when installed FID represent ranges of port numbers and IP=20 > addresses. If MN decides to discard a particular flow within the range = > then before that a correspondent FID should be installed in the HA.=20 > Otherwise > "136 FID=A0not found" will be returned from HA. > GT> If the MN wants to discard a particular flow within a range of previously registered flows, it needs to either split the range it two = parts, or even better, use a higher FID-PRI for the discard flow so = that packets get matched against it before they get matched against the = range. > 2. Specify the time interval for how long time the "Discard" state=20 > will be active in HA.=A0This is necessary because there is no=20 > "un-discard" message sent from MN. > GT> Flow bindings share the same lifetime with the BU. There is no flow binding-specific lifetime. If an MN wants to remove a flow binding = it sends a BU which does not include the corresponding FID. > 3. Add a disclaimer that for some protocols, like TCP, "Discard"=20 > action may lead to hanging up the connection at CN and should be used = responsibly. > GT> Discarding packets will drop connections....yes...I do not think there is anything to say here. > > Regards > Yuri > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From julienl@qualcomm.com Fri Oct 23 08:17:34 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937AA3A6836 for ; Fri, 23 Oct 2009 08:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.535 X-Spam-Level: X-Spam-Status: No, score=-103.535 tagged_above=-999 required=5 tests=[AWL=-0.936, 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 PaQYOXuL8EGV for ; Fri, 23 Oct 2009 08:17:33 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 37C223A67E4 for ; Fri, 23 Oct 2009 08:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1256311064; x=1287847064; 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"Laganier,=20Julien"=20 |To:=20George=20Tsirtsis=20|CC: =20"mext@ietf.org"=20,=0D=0A=20=20=20=20 =20=20=20=20"draft-ietf-mext-flow-binding@tools.ietf.org" =0D=0A=09 |Date:=20Fri,=2023=20Oct=202009=2008:17:28=20-0700 |Subject:=20RE:=20[MEXT]=20[WGLC]=20draft-ietf-mext-flow- binding-03|Thread-Topic:=20[MEXT]=20[WGLC]=20draft-ietf-m ext-flow-binding-03|Thread-Index:=20AcpTwqipT4zGvsfHReC/w k/kSClW/QAMP2mA|Message-ID:=20|References: =20=0D=0A=09=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"utf-8" |Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5780"=3B=20 a=3D"25941016"; bh=d5MJbaAETeXDvt1o0aLcfBXIfpbfJkM8VVMlsKi8/3w=; b=I/MdiKc5HXJB/q75DNtP+Ff6lY+DNeAqsE7uIYJnvIHEydtoPozsDXEJ fLfIzbsWlN45Dihq/G6VFZkTBYcAUQrmm/gvBru6F2j9ksN5Vm7YVBBWo OusUwBeiWmu9zDl0TGjHAmsfoD0+DfmL9IaEOf+Rj5hQkpbmPCZDf+TZY o=; X-IronPort-AV: E=McAfee;i="5300,2777,5780"; a="25941016" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Oct 2009 08:17:31 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9NFHVV9016682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 23 Oct 2009 08:17:31 -0700 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 n9NFHUj0018144 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 23 Oct 2009 08:17:30 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 23 Oct 2009 08:17:30 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Fri, 23 Oct 2009 08:17:30 -0700 From: "Laganier, Julien" To: George Tsirtsis Date: Fri, 23 Oct 2009 08:17:28 -0700 Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpTwqipT4zGvsfHReC/wk/kSClW/QAMP2mA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "draft-ietf-mext-flow-binding@tools.ietf.org" , "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 15:17:34 -0000 VGhhbmtzIEdlb3JnZSwgdGhpcyBsb29rcyBnb29kLg0KDQotLWp1bGllbg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEdlb3JnZSBUc2lydHNpcyBbbWFpbHRvOnRzaXJ0 c2lzQGdvb2dsZW1haWwuY29tXQ0KPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMjMsIDIwMDkgMjoy NCBBTQ0KPiBUbzogTGFnYW5pZXIsIEp1bGllbg0KPiBDYzogbWV4dEBpZXRmLm9yZzsgZHJhZnQt aWV0Zi1tZXh0LWZsb3ctYmluZGluZ0B0b29scy5pZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW01F WFRdIFtXR0xDXSBkcmFmdC1pZXRmLW1leHQtZmxvdy1iaW5kaW5nLTAzDQo+IA0KPiBKdWxpZW4s DQo+IA0KPiBJIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB3aGljaCBJIHRoaW5rIGFkZHJlc3NlcyB0 aGUgdGVybWlub2xvZ3kgaXNzdWVzDQo+IGJ1dCBpcyBhbHNvIGNvbnNpc3RlbnQgd2l0aCB0aGUg cmVzdCBvZiB0aGUgZG9jdW1lbnQuDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgIDx0PkZsb3c6 IEEgZmxvdyBpcyBhcyBhIHNldCBvZiBkYXRhIHBhY2tldHMgdGhhdA0KPiBhcmUNCj4gICAgICAg ICAgICAgICAgICAgICAgICAgZXhjaGFuZ2VkIGJldHdlZW4gdHdvIG5vZGVzLiBJbiB0aGUgY29u dGV4dCBvZg0KPiB0aGlzDQo+ICAgICAgICAgICAgICAgICAgICAgICAgIHNwZWNpZmljYXRpb24g dGhlIHRlcm0gImZsb3ciIGlzIHNvbWUgdGltZXMNCj4gdXNlZCB0bw0KPiAgICAgICAgICAgICAg ICAgICAgICAgICByZWZlciB0byBhIHBsdXJhbGl0eSBvZiBmbG93cyBhcyB3ZWxsIGFzIGENCj4g c2luZ2xlIGZsb3cuPC90Pg0KPiAgICAgICAgICAgICAgICAgICAgIDx0PlRyYWZmaWMgU2VsZWN0 b3I6IEluZm9ybWF0aW9uIHRoYXQgaWRlbnRpZmllcw0KPiBvbmUgb3IgbW9yZQ0KPiAgICAgICAg ICAgICAgICAgICAgICAgICBmbG93cy4gPC90Pg0KPiAgICAgICAgICAgICAgICAgICAgIDx0PkZs b3cgYmluZGluZzogSXQgY29uc2lzdHMgb2YgYSB0cmFmZmljIHNlbGVjdG9yLA0KPiBhbmQgYW4N Cj4gICAgICAgICAgICAgICAgICAgICAgICAgYWN0aW9uLiBJUCBwYWNrZXRzIGZyb20gb25lIG9y IG1vcmUgZmxvd3MgdGhhdA0KPiBtYXRjaCB0aGUNCj4gICAgICAgICAgICAgICAgICAgICAgICAg dHJhZmZpYyBzZWxlY3RvciBhc3NvY2lhdGVkIHdpdGggdGhlIGZsb3cNCj4gYmluZGluZywgYXJl DQo+ICAgICAgICAgICAgICAgICAgICAgICAgIHByb2Nlc3NlZCBhY2NvcmRpbmcgdG8gdGhlIGFj dGlvbiBhc3NvY2lhdGVkDQo+IHdpdGggdGhlDQo+ICAgICAgICAgICAgICAgICAgICAgICAgIHNh bWUgZmxvdyBiaW5kaW5nLjwvdD4NCj4gICAgICAgICAgICAgICAgICAgICA8dD5GbG93IElkZW50 aWZpZXI6IEEgZmxvdyBpZGVudGlmaWVyIHVuaXF1ZWx5DQo+IGlkZW50aWZpZXMgYQ0KPiAgICAg ICAgICAgICAgICAgICAgICAgICBmbG93IGJpbmRpbmcgYXNzb2NpYXRlZCB3aXRoIGEgbW9iaWxl IG5vZGUuIEl0DQo+IGlzDQo+ICAgICAgICAgICAgICAgICAgICAgICAgIGdlbmVyYXRlZCBieSBh IG1vYmlsZSBub2RlIGFuZCBpcyBjYWNoZWQgaW4gdGhlDQo+IHRhYmxlIG9mDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgIGZsb3cgYmluZGluZyBlbnRyaWVzIG1haW50YWluZWQgYnkgdGhlIE1O LCBIQSwNCj4gQ04gb3INCj4gICAgICAgICAgICAgICAgICAgICAgICAgTUFQLjwvdD4NCj4gDQo+ IFdSVCB0byB0aGUgdXNlIG9mIHRoZSB0ZXJtICJuLWNhc3QiIHZzICJmb3J3YXJkIiBJIGFtIGZp bmUgd2l0aA0KPiBjaGFuZ2luZyBpdCB0byAiRm9yd2FyZCIgd2hpY2ggSSBhZ3JlZSBtYWtlcyBt b3JlIHNlbnNlLiBJbiBhbiBlZmZvcnQNCj4gdG8gYXZvaWQgYW4gZW5kbGVzcy9wb2ludGxlc3Mg ZGlzY3Vzc2lvbiBhYm91dCBpdCwgaG93ZXZlciwgSSB3b3VsZA0KPiBsaWtlIHRoZSBjaGFpcnMg dG8gcmVhc3N1cmUgbWUgdGhhdCBJIHdpbGwgbm90IGhhdmUgdG8gY2hhbmdlIGl0IGJhY2sNCj4g YWdhaW4gOi0pLg0KPiANCj4gR2VvcmdlDQo+IA0KPiBPbiBUaHUsIE9jdCAyMiwgMjAwOSBhdCA2 OjIwIFBNLCBMYWdhbmllciwgSnVsaWVuDQo+IDxqdWxpZW5sQHF1YWxjb21tLmNvbT4gd3JvdGU6 DQo+ID4gRm9sa3MsDQo+ID4NCj4gPiBQbGVhc2UgZmluZCBiZWxvdyBteSBfaW5kaXZpZHVhbF8g V0dMQyBjb21tZW50czoNCj4gPg0KPiA+IEFzIHdlJ3ZlIGRpc2N1c3NlZCBpbiB0aGUgcGFzdCBJ IHRoaW5rIHRoZSB0ZXJtaW5vbG9neSBpcyBtaXNsZWFkaW5nDQo+IGFuZCB3ZSBoYWQgYWdyZWVk IHRvIGZpeCBpdC4gVGhlIGRyYWZ0IGhhc24ndCBiZWVuIHVwZGF0ZWQgc2luY2UgdGhlbiwNCj4g aG93ZXZlciwgc28gSSdtIHJlcGVhdGluZyBteSBjb21tZW50cyBpbiB0aGUgV0dMQy4NCj4gPg0K PiA+IFRoZSBjdXJyZW50IGZsb3cgZGVzY3JpcHRpb24gY2FuIGNhdGNoZXMgdHJhZmZpYyB0byBt YW55IGRlc3RpbmF0aW9uLA0KPiBlLmcuLCBIVFRQIHRyYWZmaWMgdG8gYW55IGRlc3RpbmF0aW9u LCB5ZXQgdGhlIGN1cnJlbnQgZGVmaW5pdGlvbiBvZg0KPiBmbG93IHRhbGtzIGFib3V0IHBhY2tl dCBleGNoYW5nZWQgYmV0d2VlbiB0d28gbm9kZXM6DQo+ID4NCj4gPiDCoCDCoCDCoEZsb3c6IEEg ZmxvdyBpcyBpZGVudGlmaWVkIGFzIGEgc2V0IG9mIGRhdGEgcGFja2V0cyB0aGF0IGFyZQ0KPiA+ IMKgIMKgIMKgZXhjaGFuZ2VkIGJldHdlZW4gdHdvIG5vZGVzIGFuZCBtYXRjaCBhIGdpdmVuIGZs b3cgZGVzY3JpcHRpb24NCj4gPg0KPiA+IEkgdGhpbmsgaXQgaXMgZmFpciB0byBzYXkgdGhhdCB0 aGUgYmFzaWMgb2JqZWN0IHRoYXQgdGhpcw0KPiBzcGVjaWZpY2F0aW9uIG1hbmlwdWxhdGVzIGlz IGEgImJ1bmNoIG9mIGZsb3dzIiByYXRoZXIgdGhhbiBhIGZsb3cuIFNvDQo+IEkgdGhpbmsgd2Ug c2hvdWxkIG1ha2UgdGhlIGZvbGxvd2luZyBlYXN5IGNoYW5nZSBhbmQgcmVuYW1pbmcgaW4gb3Vy DQo+IGRlZmluaXRpb25zIGFuZCB0ZXJtaW5vbG9neSwgaXQgd2lsbCBtYWtlIHRoZSBzcGVjaWZp Y2F0aW9uIG1vcmUNCj4gY29uc2lzdGVudCBhbmQgZWFzaWVyIHRvIHJlYWQgd2l0aG91dCBlbnRh aWxpbmcgY2hhbmdlcyB0byB0aGUgcHJvdG9jb2wNCj4gbWVjaGFuaXNtOg0KPiA+DQo+ID4gwqAg RmxvdzoNCj4gPg0KPiA+IMKgIMKgIMKgIMKgIChzb21ldGhpbmcgYWxhIFJGQyAyNDYwLCBlLmcu KSBhIHNlcXVlbmNlIG9mIHBhY2tldHMNCj4gPiDCoCDCoCDCoCDCoCBzZW50IGZyb20gYSBwYXJ0 aWN1bGFyIHNvdXJjZSB0byBhIHBhcnRpY3VsYXIgKHVuaWNhc3QNCj4gPiDCoCDCoCDCoCDCoCBv ciBtdWx0aWNhc3QpIGRlc3RpbmF0aW9uIGZvciB3aGljaCBhIE1OIGRlc2lyZXMNCj4gPiDCoCDC oCDCoCDCoCBzcGVjaWFsIGhhbmRsaW5nIGJ5IGludGVydmVuaW5nIE1JUHY2IHBlZXJzLCBiZWlu ZyBpdA0KPiA+IMKgIMKgIMKgIMKgIHRoZSBIQSBvciB0aGUgQ04uDQo+ID4NCj4gPiDCoCBGbG93 IERlc2NyaXB0aW9uIC0+IFRyYWZmaWMgRGVzY3JpcHRpb24vU2VsZWN0b3IgKEkgZG9uJ3QgY2Fy ZQ0KPiB3aGljaCBvbmUgd2UgcGljaywgdHJhZmZpYyBzZWxlY3RvciBpcyB1c2VkIGJ5IElQc2Vj IGFscmVhZHkgd2l0aA0KPiBleGFjdGx5IHRoZSBzYW1lIG1lYW5pbmcgdGhhdCBoZXJlKToNCj4g Pg0KPiA+IMKgIMKgIMKgIMKgIGEgcGllY2Ugb2YgaW5mb3JtYXRpb24gdGhhdCBpZGVudGlmaWVz IG9uZSBvciBtb3JlIGZsb3dzLg0KPiA+IMKgIMKgIMKgIMKgIFRoZSBpZGVudGlmaWNhdGlvbiBp cyBiYXNlZCBvbiB2YXJpb3VzIGZpZWxkcyBvZiB0aGUNCj4gPiDCoCDCoCDCoCDCoCBuZXR3b3Jr IGFuZCB0cmFuc3BvcnQgbGF5ZXIgaGVhZGVycywgc3VjaCBhcyB0aGUgc291cmNlDQo+ID4gwqAg wqAgwqAgwqAgYWRkcmVzcywgdGhlIGRlc3RpbmF0aW9uIHBvcnQsIHRoZSBwcm90b2NvbCBudW1i ZXIsIHRoZQ0KPiA+IMKgIMKgIMKgIMKgIERTQ1AgdmFsdWUsIGV0Yy4NCj4gPg0KPiA+IMKgIEZs b3cgSWRlbnRpZmljYXRpb24gLT4gVHJhZmZpYyBJZGVudGlmaWNhdGlvbg0KPiA+DQo+ID4gwqAg RmxvdyBJZGVudGlmaWVyIC0+IFRyYWZmaWMgSWRlbnRpZmllcjoNCj4gPg0KPiA+IMKgIMKgIMKg IMKgIGFuIHVuc2lnbmVkIGludGVnZXIgdXNlZCBhcyBhIHJlZmVyZW5jZSB0byBhIHBhcnRpY3Vs YXINCj4gPiDCoCDCoCDCoCDCoCBUcmFmZmljIERlc2NyaXB0aW9uL1NlbGVjdG9yLg0KPiA+DQo+ ID4gwqAgRmxvdyBCaW5kaW5nIC0+IFRyYWZmaWMgQmluZGluZzoNCj4gPg0KPiA+IMKgIMKgIMKg IMKgYW4gYXNzb2NpYXRpb24gYmV0d2VlbiBhIHRyYWZmaWMgZGVzY3JpcHRpb24vc2VsZWN0b3Ig YW5kDQo+ID4gwqAgwqAgwqAgwqBhbiBhY3Rpb24gKEZvcndhcmQgb3IgRGlzY2FyZCkuIMKgQW4g SVAgcGFja2V0IHRoYXQgbWF0Y2hlcw0KPiA+IMKgIMKgIMKgIMKgdGhlIHRyYWZmaWMgZGVzY3Jp cHRpb24vc2VsZWN0b3Igd2lsbCBiZSBwcm9jZXNzZWQgYWNjb3JkaW5nDQo+ID4gwqAgwqAgwqAg wqB0byB0aGUgYWN0aW9uLg0KPiA+DQo+ID4gTm90ZSBhYm92ZSwgdGhlIEZsb3cgaWRlbnRpZmll ciBkb2Vzbid0IG5lZWQgdG8gYmUgaW5jbHVkZWQgaW4gdGhlDQo+IGRlZmluaXRpb24gb2YgYSBi aW5kaW5nLiBBbHNvIEkgcHJlZmVyIHRvIHVzZSAiRm9yd2FyZCIgcmF0aGVyIHRoYW4gIm4tDQo+ IGNhc3QiLCBzaW5jZSBGb3J3YXJkIGlzIGNsZWFyIGFuZCBkb2VzIG5vdCBuZWNlc3NhcmlseSBp bXBseSB0aGF0IHRoZQ0KPiBwYWNrZXQgaXMgb25seSBmb3J3YXJkZWQgaW4gb25lIGRpcmVjdGlv bi4NCj4gPg0KPiA+IC0tanVsaWVuDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiBNRVhUIG1haWxpbmcgbGlzdA0KPiA+IE1FWFRAaWV0Zi5v cmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21leHQNCj4gPg0K From tsirtsis@googlemail.com Fri Oct 23 08:53:36 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85A4A3A6894 for ; Fri, 23 Oct 2009 08:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caUw3IqKUGZu for ; Fri, 23 Oct 2009 08:53:35 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 252EB3A659C for ; Fri, 23 Oct 2009 08:53:34 -0700 (PDT) Received: by fxm18 with SMTP id 18so10438619fxm.37 for ; Fri, 23 Oct 2009 08:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zUsUCG2c0syqJJ0RQCeSJgx/5lOBIGcCjlXWhVIRLbI=; b=M8I80EkorLjB1eE/dik6sOYLTdYknllwHnUPfJYPHjWZaRkdkC1syIDKF8NoO09rTP NqRo9vKgLoxSV89dFikiA24ZVtpei1eym+awSCoH13g3zUi2rRMDr4qEH4+qwNWxudLa hW9AfuglVVPRxrEGq3pMEpTHBMm9I2nEEhKPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aeRkd+B2Ngk5c3SDQGP/waTRMfRbRAUUEm4Bcb/NhhTfDtDPp01dGswbigdOTb/HPO VcxO3niOn2xA7doPE5Gpx7sI8Kw7CJQ+vAlo+rYZzQ53RTLjDv5xACo2DZ1oanO3cAYW u9DkP+cvuqOrZUjJPN51cRPOC77OLzXd7NklE= MIME-Version: 1.0 Received: by 10.239.139.79 with SMTP id s15mr996932hbs.106.1256313221799; Fri, 23 Oct 2009 08:53:41 -0700 (PDT) In-Reply-To: References: <4ADCCB1D.2020705@ericsson.com> Date: Fri, 23 Oct 2009 16:53:41 +0100 Message-ID: From: George Tsirtsis To: Yuri Ismailov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Laganier, Julien" , mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 15:53:36 -0000 Hi Yuri, comments inline. On Fri, Oct 23, 2009 at 1:20 PM, Yuri Ismailov wrote: > Hi Goerge, > Thanks for the answers, > What I did not understand if there will be some clarification text in the= draft around "discard" action or all that is obvious and does not require = any changes? My comment was that some additional text is needed. > GT> I am not yet sure what non-trivial clarification we can provide. IMO we do not need to provide any further clarifications on this subject. > I do not think your clarification about using FID-PRI is quite clear. The= reason is that there is no FID for a particular flow within the range Ther= e is only a FID for the whole range of port numbers and/or IP addresses. > GT> What prevents you from creating another FID that is specific for that = flow? > Surprized that disclaimer for n-cast about carefull use is in the text an= d about disclaimer for "discard" you just say "I do not think > there is anything to say here." Still the question is will there be relat= ed text? > GT> I think the implication of dropping packets is much clearer than the implication of n-casting. Dropping packets means the application to which the packet is sent will not receive the packet...do we really need to say that? On the other hand, receiving N copies of the same packet has some implications to TCP....this is also rather obvious for people that know TCP...but maybe not everyone does. > Regards > Yuri > > > -----Original Message----- > From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > Sent: Friday, October 23, 2009 11:08 AM > To: Yuri Ismailov > Cc: Laganier, Julien; mext@ietf.org > Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 > > Hi Yuri, > > Comments inline... > > On Tue, Oct 20, 2009 at 8:55 AM, Yuri Ismailov wrote: >> Hi, >> after re-reading the draft come up with the comment on "Discard" >> action in "Flow Identification Mobility Option" >> I suggest either to extend the paragraph in the section 4.2 or add a >> separate subsection clarifying behavior of MN and HA before and after >> the "Discard" action was issued by MN. >> >> Below are the issues which=C2=A0are proposed to=C2=A0be addressed in the= text. >> >> 1.The case when installed FID represent ranges of port numbers and IP >> addresses. If MN decides to discard a particular flow within the range >> then before that a correspondent FID should be installed in the HA. >> Otherwise >> "136 FID=C2=A0not found" will be returned from HA. >> > > GT> If the MN wants to discard a particular flow within a range of > previously registered flows, it needs to either split the range it two pa= rts, or even better, use a higher FID-PRI for the =C2=A0discard flow so tha= t packets get matched against it before they get matched against the range. > >> 2. Specify the time interval for how long time the "Discard" state >> will be active in HA.=C2=A0This is necessary because there is no >> "un-discard" message sent from MN. >> > > GT> Flow bindings share the same lifetime with the BU. There is no > flow binding-specific lifetime. If an MN wants to remove a flow binding i= t sends a BU which does not include the corresponding FID. > >> 3. Add a disclaimer that for some protocols, like TCP, "Discard" >> action may lead to hanging up the connection at CN and should be used re= sponsibly. >> > > GT> Discarding packets will drop connections....yes...I do not think > there is anything to say here. > >> >> Regards >> Yuri >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > From julienl@qualcomm.com Fri Oct 23 13:07:02 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 862D83A6990 for ; Fri, 23 Oct 2009 13:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.494 X-Spam-Level: X-Spam-Status: No, score=-103.494 tagged_above=-999 required=5 tests=[AWL=-0.895, 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 qaXvzCbxLZox for ; Fri, 23 Oct 2009 13:07:01 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 6D5D53A6985 for ; Fri, 23 Oct 2009 13:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1256328432; x=1287864432; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"mext@ietf.org"=20|CC:=20"marcelo@i t.uc3m.es"=20|Date:=20Fri,=2023=20Oct =202009=2013:07:06=20-0700|Subject:=20MEXT=20agenda=20at =20IETF-76=20posted|Thread-Topic:=20MEXT=20agenda=20at=20 IETF-76=20posted|Thread-Index:=20AcpUHGUUPklr9ZdLSuq3u3tq 7x1H2Q=3D=3D|Message-ID:=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,5780"=3B=20a=3D"25960277"; bh=0j1HfkFlyCIehG+nf3dWfb+q6hBpHTG5H4xUxqi890A=; b=p1evaJiLccHdij5JfukY0lUTFeKxSmB07MqdhgPeA2tfCpO/x/2b+8Oh Y7hKUg8UUtONsMaOcgSoEslI9liQr7qIFfW/kLMvLSRmTc61WTvnmcGdG HrnGU8AFqa1FIgrQZ0wiBQyP5W4x4ymGIM5v6ZW5E1tbLjtFM5N58SLW/ 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5780"; a="25960277" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Oct 2009 13:07:12 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9NK7BaM023816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 23 Oct 2009 13:07:12 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9NK78iU025561 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 23 Oct 2009 13:07:11 -0700 Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 23 Oct 2009 13:07:08 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Fri, 23 Oct 2009 13:07:08 -0700 From: "Laganier, Julien" To: "mext@ietf.org" Date: Fri, 23 Oct 2009 13:07:06 -0700 Thread-Topic: MEXT agenda at IETF-76 posted Thread-Index: AcpUHGUUPklr9ZdLSuq3u3tq7x1H2Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MEXT] MEXT agenda at IETF-76 posted X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 20:07:02 -0000 Folks, We have posted the agenda: --julien & marcelo From julienl@qualcomm.com Fri Oct 23 16:26:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3DD628C0FF for ; Fri, 23 Oct 2009 16:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.457 X-Spam-Level: X-Spam-Status: No, score=-105.457 tagged_above=-999 required=5 tests=[AWL=1.142, 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 LQtzOvSE92SE for ; Fri, 23 Oct 2009 16:26:03 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id C64B128B797 for ; Fri, 23 Oct 2009 16:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1256340374; x=1287876374; 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"Laganier,=20Julien"=20 |To:=20"mext@ietf.org"=20|Date:=20Fri,=202 3=20Oct=202009=2016:25:12=20-0700|Subject:=20RE:=20MEXT =20agenda=20at=20IETF-76=20posted|Thread-Topic:=20MEXT=20 agenda=20at=20IETF-76=20posted|Thread-Index:=20AcpUHGUUPk lr9ZdLSuq3u3tq7x1H2QAG5Pkg|Message-ID:=20 |References:=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5780"=3B=20a=3D"25972112"; bh=uzakyFxRCgUtvBE+Oo/Sstjp4yYBTMOyDyEGAQLABsM=; b=ouRHw28s14RntH9ZSIEJPV92Bv8hggzFhpJdmaCtzSzMIyrTp6W8Wnqv 9vtCxrI2C2ukjdmJmLshGQvs2Ir6BUJ+i2m7U4aNhdJEhZH3T6xurtPgk ORONpYUvDSgXySJIQ6GJEFWn3NQhjaDmTVY4S1DshVwOSrcUSkKlF/NFu U=; X-IronPort-AV: E=McAfee;i="5300,2777,5780"; a="25972112" 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; 23 Oct 2009 16:26:13 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9NNQDGn017173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 23 Oct 2009 16:26:13 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9NNOuxC030707 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 23 Oct 2009 16:26:13 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 23 Oct 2009 16:25:13 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Fri, 23 Oct 2009 16:25:13 -0700 From: "Laganier, Julien" To: "mext@ietf.org" Date: Fri, 23 Oct 2009 16:25:12 -0700 Thread-Topic: MEXT agenda at IETF-76 posted Thread-Index: AcpUHGUUPklr9ZdLSuq3u3tq7x1H2QAG5Pkg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MEXT] MEXT agenda at IETF-76 posted X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 23:26:04 -0000 I've updated the agenda -- had previously missed Charlie's slot for 4283 MN= IDs. --julien > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Laganier, Julien > Sent: Friday, October 23, 2009 1:07 PM > To: mext@ietf.org > Subject: [MEXT] MEXT agenda at IETF-76 posted >=20 > Folks, >=20 > We have posted the agenda: >=20 > >=20 > --julien & marcelo > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From yuri.ismailov@ericsson.com Mon Oct 26 01:27:24 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD2728C1F6 for ; Mon, 26 Oct 2009 01:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 vA0LEJvh01-e for ; Mon, 26 Oct 2009 01:27:23 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 04B7A28C1F2 for ; Mon, 26 Oct 2009 01:27:22 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-ae-4ae55d765cd3 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 48.2B.24026.67D55EA4; Mon, 26 Oct 2009 09:27:35 +0100 (CET) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 09:27:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 09:27:32 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpT+P7Xov8p9Q8/RsCcol6n7JUwQACF8Wkg References: <4ADCCB1D.2020705@ericsson.com> From: "Yuri Ismailov" To: "George Tsirtsis" X-OriginalArrivalTime: 26 Oct 2009 08:27:34.0700 (UTC) FILETIME=[2B2B2EC0:01CA5616] X-Brightmail-Tracker: AAAAAA== Cc: "Laganier, Julien" , mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 08:27:24 -0000 Hi George, all George, what I understood from ******* GT> I am not yet sure what non-trivial clarification we can provide. IMO we do not need to provide any further clarifications on this = subject. ******** is that you do not see any point of further discussion. Well, I will anyway provide the text which I think is suitable for = clarification. On the other hand I disagree about the fact that TCP connection = suffering performance is more clearer than TCP connection stop working. = Strange that this is not obvious. Below is the proposal for the text to add in the paragraph describing = "Discard" action in chapter 4.2 After the text: "1 Discard. This value indicates a request to discard all packets in the flow described by the option. No BIDs are associated with this Action." Add the following text: "In the case there is no correspondent FID to a particular flow or range = of flows, which should be discarded, a mobile node MUST install a = correspondent FID, otherwise error code 136 "FID not found" will be = returned by HA. Care should be taken when issuing request for discarding = packets as this will lead to disrupting applications communication after = the "Discard" action was applied to selected flows. Implementations may = consider notifying impacted applications in mobile nodes" Regards Yuri -----Original Message----- From: George Tsirtsis [mailto:tsirtsis@googlemail.com]=20 Sent: Friday, October 23, 2009 5:54 PM To: Yuri Ismailov Cc: Laganier, Julien; mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Hi Yuri, comments inline. On Fri, Oct 23, 2009 at 1:20 PM, Yuri Ismailov = wrote: > Hi Goerge, > Thanks for the answers, > What I did not understand if there will be some clarification text in = the draft around "discard" action or all that is obvious and does not = require any changes? My comment was that some additional text is needed. > GT> I am not yet sure what non-trivial clarification we can provide. IMO we do not need to provide any further clarifications on this = subject. > I do not think your clarification about using FID-PRI is quite clear. = The reason is that there is no FID for a particular flow within the = range There is only a FID for the whole range of port numbers and/or IP = addresses. > GT> What prevents you from creating another FID that is specific for = that flow? > Surprized that disclaimer for n-cast about carefull use is in the text = > and about disclaimer for "discard" you just say "I do not think there = is anything to say here." Still the question is will there be related = text? > GT> I think the implication of dropping packets is much clearer than the implication of n-casting. Dropping packets means the application to = which the packet is sent will not receive the packet...do we really need = to say that? On the other hand, receiving N copies of the same packet = has some implications to TCP....this is also rather obvious for people = that know TCP...but maybe not everyone does. > Regards > Yuri > > > -----Original Message----- > From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > Sent: Friday, October 23, 2009 11:08 AM > To: Yuri Ismailov > Cc: Laganier, Julien; mext@ietf.org > Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 > > Hi Yuri, > > Comments inline... > > On Tue, Oct 20, 2009 at 8:55 AM, Yuri Ismailov = wrote: >> Hi, >> after re-reading the draft come up with the comment on "Discard" >> action in "Flow Identification Mobility Option" >> I suggest either to extend the paragraph in the section 4.2 or add a=20 >> separate subsection clarifying behavior of MN and HA before and after = >> the "Discard" action was issued by MN. >> >> Below are the issues which=A0are proposed to=A0be addressed in the = text. >> >> 1.The case when installed FID represent ranges of port numbers and IP = >> addresses. If MN decides to discard a particular flow within the=20 >> range then before that a correspondent FID should be installed in the = HA. >> Otherwise >> "136 FID=A0not found" will be returned from HA. >> > > GT> If the MN wants to discard a particular flow within a range of > previously registered flows, it needs to either split the range it two = parts, or even better, use a higher FID-PRI for the =A0discard flow so = that packets get matched against it before they get matched against the = range. > >> 2. Specify the time interval for how long time the "Discard" state=20 >> will be active in HA.=A0This is necessary because there is no=20 >> "un-discard" message sent from MN. >> > > GT> Flow bindings share the same lifetime with the BU. There is no > flow binding-specific lifetime. If an MN wants to remove a flow = binding it sends a BU which does not include the corresponding FID. > >> 3. Add a disclaimer that for some protocols, like TCP, "Discard" >> action may lead to hanging up the connection at CN and should be used = responsibly. >> > > GT> Discarding packets will drop connections....yes...I do not think > there is anything to say here. > >> >> Regards >> Yuri >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > From hesham@elevatemobile.com Mon Oct 26 01:58:43 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5962E28C179 for ; Mon, 26 Oct 2009 01:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyaCYn29ThXR for ; Mon, 26 Oct 2009 01:58:42 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 3238828C0D9 for ; Mon, 26 Oct 2009 01:58:41 -0700 (PDT) Received: from [203.219.211.243] (helo=[192.168.0.2]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1N2LPZ-0002xR-J3; Mon, 26 Oct 2009 19:58:45 +1100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 26 Oct 2009 19:58:39 +1100 From: Hesham Soliman To: Yuri Ismailov , George Tsirtsis Message-ID: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpT+P7Xov8p9Q8/RsCcol6n7JUwQACF8WkgAAJveWQ= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Cc: "Laganier, Julien" , mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 08:58:43 -0000 Yuri, >=20 > After the text: >=20 > "1 Discard. This value indicates a request to discard all packets > in the flow described by the option. No BIDs are associated with > this Action." >=20 > Add the following text: >=20 > "In the case there is no correspondent FID to a particular flow or range = of > flows, which should be discarded, a mobile node MUST install a correspond= ent > FID, otherwise error code 136 "FID not found" will be returned by HA. =3D> I don't understand what this means. Can you clarify? Care=20 > should be taken when issuing request for discarding packets as this will = lead > to disrupting applications communication after the "Discard" action was > applied to selected flows. Implementations may consider notifying impacte= d > applications in mobile nodes" =3D> This part is clear to me. Hesham >=20 >=20 >=20 > Regards > Yuri >=20 >=20 > -----Original Message----- > From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > Sent: Friday, October 23, 2009 5:54 PM > To: Yuri Ismailov > Cc: Laganier, Julien; mext@ietf.org > Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >=20 > Hi Yuri, comments inline. >=20 > On Fri, Oct 23, 2009 at 1:20 PM, Yuri Ismailov > wrote: >> Hi Goerge, >> Thanks for the answers, >> What I did not understand if there will be some clarification text in th= e >> draft around "discard" action or all that is obvious and does not requir= e any >> changes? My comment was that some additional text is needed. >>=20 >=20 > GT> I am not yet sure what non-trivial clarification we can provide. > IMO we do not need to provide any further clarifications on this subject. >=20 >> I do not think your clarification about using FID-PRI is quite clear. Th= e >> reason is that there is no FID for a particular flow within the range Th= ere >> is only a FID for the whole range of port numbers and/or IP addresses. >>=20 >=20 > GT> What prevents you from creating another FID that is specific for tha= t > flow? >=20 >> Surprized that disclaimer for n-cast about carefull use is in the text >> and about disclaimer for "discard" you just say "I do not think there is >> anything to say here." Still the question is will there be related text? >>=20 >=20 > GT> I think the implication of dropping packets is much clearer than > the implication of n-casting. Dropping packets means the application to w= hich > the packet is sent will not receive the packet...do we really need to say > that? On the other hand, receiving N copies of the same packet has some > implications to TCP....this is also rather obvious for people that know > TCP...but maybe not everyone does. >=20 >> Regards >> Yuri >>=20 >>=20 >> -----Original Message----- >> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >> Sent: Friday, October 23, 2009 11:08 AM >> To: Yuri Ismailov >> Cc: Laganier, Julien; mext@ietf.org >> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>=20 >> Hi Yuri, >>=20 >> Comments inline... >>=20 >> On Tue, Oct 20, 2009 at 8:55 AM, Yuri Ismailov >> wrote: >>> Hi, >>> after re-reading the draft come up with the comment on "Discard" >>> action in "Flow Identification Mobility Option" >>> I suggest either to extend the paragraph in the section 4.2 or add a >>> separate subsection clarifying behavior of MN and HA before and after >>> the "Discard" action was issued by MN. >>>=20 >>> Below are the issues which=A0are proposed to=A0be addressed in the text. >>>=20 >>> 1.The case when installed FID represent ranges of port numbers and IP >>> addresses. If MN decides to discard a particular flow within the >>> range then before that a correspondent FID should be installed in the H= A. >>> Otherwise >>> "136 FID=A0not found" will be returned from HA. >>>=20 >>=20 >> GT> If the MN wants to discard a particular flow within a range of >> previously registered flows, it needs to either split the range it two p= arts, >> or even better, use a higher FID-PRI for the =A0discard flow so that packe= ts >> get matched against it before they get matched against the range. >>=20 >>> 2. Specify the time interval for how long time the "Discard" state >>> will be active in HA.=A0This is necessary because there is no >>> "un-discard" message sent from MN. >>>=20 >>=20 >> GT> Flow bindings share the same lifetime with the BU. There is no >> flow binding-specific lifetime. If an MN wants to remove a flow binding = it >> sends a BU which does not include the corresponding FID. >>=20 >>> 3. Add a disclaimer that for some protocols, like TCP, "Discard" >>> action may lead to hanging up the connection at CN and should be used >>> responsibly. >>>=20 >>=20 >> GT> Discarding packets will drop connections....yes...I do not think >> there is anything to say here. >>=20 >>>=20 >>> Regards >>> Yuri >>>=20 >>>=20 >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>>=20 >>>=20 >>=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From tsirtsis@googlemail.com Mon Oct 26 02:47:20 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80CBD3A6991 for ; Mon, 26 Oct 2009 02:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okH9lS+Gmqeo for ; Mon, 26 Oct 2009 02:47:19 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 2D5173A687C for ; Mon, 26 Oct 2009 02:47:19 -0700 (PDT) Received: by fxm18 with SMTP id 18so11896933fxm.37 for ; Mon, 26 Oct 2009 02:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=azNCoDrvR51+4lF5T57LLmm9OKGY38ehT0hrZMS9QtU=; b=aRbeTRiSKvoNd9Bjfta25VAXIeVtP6En4Bp2FKUZdJRiVU3eAeNyo0xqDtK8Rt6N1r TKl2pjJprj0X5GbMf0FCAqKKAbMpPRCt0UkHqATVl9KEn7XL8+QPaBPQA/sTdnclFUKu YY6vE3M+V94mTSME7k23Udrfr1CEZ5gfI9Yrc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wPqrMZ4uslUPvCVvQiSOzPKRNniCW9p8F2DwfqQI9KAdTUskRRxOTXZtNNinf9FJHX oHBDGg7IJDAlHRs0fm0ncTHLydCD3SqUYTZOk00BrpKyFyF9Mg5CHdJqG62f826VSGZU Y/SUGbv09kaRBxBi9/WbdDRZlO/LcBTmP0C3w= MIME-Version: 1.0 Received: by 10.239.237.193 with SMTP id k1mr1176978hbp.173.1256550449224; Mon, 26 Oct 2009 02:47:29 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Oct 2009 09:47:29 +0000 Message-ID: From: George Tsirtsis To: Hesham Soliman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Laganier, Julien" , mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 09:47:20 -0000 On Mon, Oct 26, 2009 at 8:58 AM, Hesham Soliman wrote: > Yuri, > > >> >> After the text: >> >> "1 Discard. =C2=A0This value indicates a request to discard all packets >> =C2=A0in the flow described by the option. =C2=A0No BIDs are associated = with >> =C2=A0this Action." >> >> Add the following text: >> >> "In the case there is no correspondent FID to a particular flow or range= of >> flows, which should be discarded, a mobile node MUST install a correspon= dent >> FID, otherwise error code 136 "FID not found" will be returned by HA. > > =3D> I don't understand what this means. Can you clarify? > GT> Yes this seems strange since there is no way to indicate Discard Action without providing an FID. > > =C2=A0Care >> should be taken when issuing request for discarding packets as this will= lead >> to disrupting applications communication after the "Discard" action was >> applied to selected flows. Implementations may consider notifying impact= ed >> applications in mobile nodes" > > =3D> This part is clear to me. > GT> Yuri, I will add this to the document, no problem. > Hesham > >> >> >> >> Regards >> Yuri >> >> >> -----Original Message----- >> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >> Sent: Friday, October 23, 2009 5:54 PM >> To: Yuri Ismailov >> Cc: Laganier, Julien; mext@ietf.org >> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >> >> Hi Yuri, comments inline. >> >> On Fri, Oct 23, 2009 at 1:20 PM, Yuri Ismailov >> wrote: >>> Hi Goerge, >>> Thanks for the answers, >>> What I did not understand if there will be some clarification text in t= he >>> draft around "discard" action or all that is obvious and does not requi= re any >>> changes? My comment was that some additional text is needed. >>> >> >> GT> I am not yet sure what non-trivial clarification we can provide. >> IMO we do not need to provide any further clarifications on this subject= . >> >>> I do not think your clarification about using FID-PRI is quite clear. T= he >>> reason is that there is no FID for a particular flow within the range T= here >>> is only a FID for the whole range of port numbers and/or IP addresses. >>> >> >> GT> What prevents you from =C2=A0creating another FID that is specific f= or that >> flow? >> >>> Surprized that disclaimer for n-cast about carefull use is in the text >>> and about disclaimer for "discard" you just say "I do not think there i= s >>> anything to say here." Still the question is will there be related text= ? >>> >> >> GT> I think the implication of dropping packets is much clearer than >> the implication of n-casting. Dropping packets means the application to = which >> the packet is sent will not receive the packet...do we really need to sa= y >> that? On the other hand, receiving N copies of the same packet has some >> implications to TCP....this is also rather obvious for people that know >> TCP...but maybe not everyone does. >> >>> Regards >>> Yuri >>> >>> >>> -----Original Message----- >>> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >>> Sent: Friday, October 23, 2009 11:08 AM >>> To: Yuri Ismailov >>> Cc: Laganier, Julien; mext@ietf.org >>> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>> >>> Hi Yuri, >>> >>> Comments inline... >>> >>> On Tue, Oct 20, 2009 at 8:55 AM, Yuri Ismailov >>> wrote: >>>> Hi, >>>> after re-reading the draft come up with the comment on "Discard" >>>> action in "Flow Identification Mobility Option" >>>> I suggest either to extend the paragraph in the section 4.2 or add a >>>> separate subsection clarifying behavior of MN and HA before and after >>>> the "Discard" action was issued by MN. >>>> >>>> Below are the issues which=C2=A0are proposed to=C2=A0be addressed in t= he text. >>>> >>>> 1.The case when installed FID represent ranges of port numbers and IP >>>> addresses. If MN decides to discard a particular flow within the >>>> range then before that a correspondent FID should be installed in the = HA. >>>> Otherwise >>>> "136 FID=C2=A0not found" will be returned from HA. >>>> >>> >>> GT> If the MN wants to discard a particular flow within a range of >>> previously registered flows, it needs to either split the range it two = parts, >>> or even better, use a higher FID-PRI for the =C2=A0discard flow so that= packets >>> get matched against it before they get matched against the range. >>> >>>> 2. Specify the time interval for how long time the "Discard" state >>>> will be active in HA.=C2=A0This is necessary because there is no >>>> "un-discard" message sent from MN. >>>> >>> >>> GT> Flow bindings share the same lifetime with the BU. There is no >>> flow binding-specific lifetime. If an MN wants to remove a flow binding= it >>> sends a BU which does not include the corresponding FID. >>> >>>> 3. Add a disclaimer that for some protocols, like TCP, "Discard" >>>> action may lead to hanging up the connection at CN and should be used >>>> responsibly. >>>> >>> >>> GT> Discarding packets will drop connections....yes...I do not think >>> there is anything to say here. >>> >>>> >>>> Regards >>>> Yuri >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > > From yuri.ismailov@ericsson.com Mon Oct 26 04:11:31 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2F433A68FB for ; Mon, 26 Oct 2009 04:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_101=0.6, J_CHICKENPOX_102=0.6, MANGLED_PILL=2.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 mhxCTDA-Kx8y for ; Mon, 26 Oct 2009 04:11:30 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E22943A681A for ; Mon, 26 Oct 2009 04:11:29 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-12-4ae583ed0eb8 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 88.AC.04191.DE385EA4; Mon, 26 Oct 2009 12:11:41 +0100 (CET) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 12:11:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 12:11:40 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpT+P7Xov8p9Q8/RsCcol6n7JUwQACF8WkgAAJveWQABApIIA== References: From: "Yuri Ismailov" To: "Hesham Soliman" , "George Tsirtsis" X-OriginalArrivalTime: 26 Oct 2009 11:11:41.0597 (UTC) FILETIME=[18606CD0:01CA562D] X-Brightmail-Tracker: AAAAAA== Cc: "Laganier, Julien" , mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 11:11:31 -0000 Hi Hesham, If, for example, there is a FID which covers range of port numbers and = IP addresses. In such case flow bindings may look like as following FID-PRI FID Flow Description BIDs Action A/I ------- --- ---------------- ---- ------- ------ 10 4 TCP dstPortMin=3DP1 1 Forward Active dstPortMax=3DPN If an MN whishes to discard some particular port number P1 < i < PN = then the only possibility with the current FID table is to set=20 The whole range to the state "Discard" If other port numbers in the range should be still in Active state then = the new FID definitions will be required and flow bindings will have to = be transformed looking like the following, for example: FID-PRI FID Flow Description BIDs Action A/I ------- --- ---------------- ---- ------- ------ 10 4 TCP dstPortMin=3DP1 1 Forward Active dstPortMax=3DP(i-1) 10 5 TCP dstPortMin=3DP(i+1) 1 Forward Active dstPortMax=3DPN 10 6 TCP dstPortMin=3Di 1 Discard Active Similar should be done if there are ranges of IP addresses and/or both = IP addresses and port numbers covered by a single FID Does this clarify what I mean? Regards Yuri -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Monday, October 26, 2009 9:59 AM To: Yuri Ismailov; George Tsirtsis Cc: Laganier, Julien; mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Yuri, >=20 > After the text: >=20 > "1 Discard. This value indicates a request to discard all packets in = > the flow described by the option. No BIDs are associated with this=20 > Action." >=20 > Add the following text: >=20 > "In the case there is no correspondent FID to a particular flow or=20 > range of flows, which should be discarded, a mobile node MUST install=20 > a correspondent FID, otherwise error code 136 "FID not found" will be = returned by HA. =3D> I don't understand what this means. Can you clarify? Care=20 > should be taken when issuing request for discarding packets as this=20 > will lead to disrupting applications communication after the "Discard" = > action was applied to selected flows. Implementations may consider=20 > notifying impacted applications in mobile nodes" =3D> This part is clear to me. Hesham >=20 >=20 >=20 > Regards > Yuri >=20 >=20 > -----Original Message----- > From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > Sent: Friday, October 23, 2009 5:54 PM > To: Yuri Ismailov > Cc: Laganier, Julien; mext@ietf.org > Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >=20 > Hi Yuri, comments inline. >=20 > On Fri, Oct 23, 2009 at 1:20 PM, Yuri Ismailov=20 > > wrote: >> Hi Goerge, >> Thanks for the answers, >> What I did not understand if there will be some clarification text in = >> the draft around "discard" action or all that is obvious and does not = >> require any changes? My comment was that some additional text is = needed. >>=20 >=20 > GT> I am not yet sure what non-trivial clarification we can provide. > IMO we do not need to provide any further clarifications on this = subject. >=20 >> I do not think your clarification about using FID-PRI is quite clear. = >> The reason is that there is no FID for a particular flow within the=20 >> range There is only a FID for the whole range of port numbers and/or = IP addresses. >>=20 >=20 > GT> What prevents you from creating another FID that is specific for=20 > GT> that > flow? >=20 >> Surprized that disclaimer for n-cast about carefull use is in the=20 >> text and about disclaimer for "discard" you just say "I do not think=20 >> there is anything to say here." Still the question is will there be = related text? >>=20 >=20 > GT> I think the implication of dropping packets is much clearer than > the implication of n-casting. Dropping packets means the application=20 > to which the packet is sent will not receive the packet...do we really = > need to say that? On the other hand, receiving N copies of the same=20 > packet has some implications to TCP....this is also rather obvious for = > people that know TCP...but maybe not everyone does. >=20 >> Regards >> Yuri >>=20 >>=20 >> -----Original Message----- >> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >> Sent: Friday, October 23, 2009 11:08 AM >> To: Yuri Ismailov >> Cc: Laganier, Julien; mext@ietf.org >> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>=20 >> Hi Yuri, >>=20 >> Comments inline... >>=20 >> On Tue, Oct 20, 2009 at 8:55 AM, Yuri Ismailov=20 >> >> wrote: >>> Hi, >>> after re-reading the draft come up with the comment on "Discard" >>> action in "Flow Identification Mobility Option" >>> I suggest either to extend the paragraph in the section 4.2 or add a = >>> separate subsection clarifying behavior of MN and HA before and=20 >>> after the "Discard" action was issued by MN. >>>=20 >>> Below are the issues which=A0are proposed to=A0be addressed in the = text. >>>=20 >>> 1.The case when installed FID represent ranges of port numbers and=20 >>> IP addresses. If MN decides to discard a particular flow within the=20 >>> range then before that a correspondent FID should be installed in = the HA. >>> Otherwise >>> "136 FID=A0not found" will be returned from HA. >>>=20 >>=20 >> GT> If the MN wants to discard a particular flow within a range of >> previously registered flows, it needs to either split the range it=20 >> two parts, or even better, use a higher FID-PRI for the =A0discard = flow=20 >> so that packets get matched against it before they get matched = against the range. >>=20 >>> 2. Specify the time interval for how long time the "Discard" state=20 >>> will be active in HA.=A0This is necessary because there is no=20 >>> "un-discard" message sent from MN. >>>=20 >>=20 >> GT> Flow bindings share the same lifetime with the BU. There is no >> flow binding-specific lifetime. If an MN wants to remove a flow=20 >> binding it sends a BU which does not include the corresponding FID. >>=20 >>> 3. Add a disclaimer that for some protocols, like TCP, "Discard" >>> action may lead to hanging up the connection at CN and should be=20 >>> used responsibly. >>>=20 >>=20 >> GT> Discarding packets will drop connections....yes...I do not think >> there is anything to say here. >>=20 >>>=20 >>> Regards >>> Yuri >>>=20 >>>=20 >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>>=20 >>>=20 >>=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From hesham@elevatemobile.com Mon Oct 26 04:54:37 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F0B93A68EE for ; Mon, 26 Oct 2009 04:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.082 X-Spam-Level: X-Spam-Status: No, score=0.082 tagged_above=-999 required=5 tests=[AWL=-2.215, BAYES_00=-2.599, J_CHICKENPOX_101=0.6, J_CHICKENPOX_102=0.6, MANGLED_PILL=2.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8waWC0xi7r6 for ; Mon, 26 Oct 2009 04:54:36 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 1DDA13A67F3 for ; Mon, 26 Oct 2009 04:54:35 -0700 (PDT) Received: from [203.219.211.243] (helo=[192.168.0.2]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1N2O9n-0005Mf-Rc; Mon, 26 Oct 2009 22:54:40 +1100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 26 Oct 2009 22:54:32 +1100 From: Hesham Soliman To: Yuri Ismailov , George Tsirtsis Message-ID: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpT+P7Xov8p9Q8/RsCcol6n7JUwQACF8WkgAAJveWQABApIIAACGj2a In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Cc: "Laganier, Julien" , mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 11:54:37 -0000 On 26/10/09 10:11 PM, "Yuri Ismailov" wrote: > Hi Hesham, >=20 > If, for example, there is a FID which covers range of port numbers and IP > addresses. In such case flow bindings may look like as following >=20 > FID-PRI FID Flow Description BIDs Action A/I > ------- --- ---------------- ---- ------- ------ > 10 4 TCP dstPortMin=3DP1 1 Forward Active > dstPortMax=3DPN >=20 > If an MN whishes to discard some particular port number P1 < i < PN then= the > only possibility with the current FID table is to set > The whole range to the state "Discard" =3D> No, that's not a good way to go at all. If you want to do that the way t= o say discard port 100 where P1 < 100 < N then you send a new FID with Discar= d action, PRI set to say 9 (higher priority). You don't need to touch the existing one.=20 Hesham >=20 > If other port numbers in the range should be still in Active state then t= he > new FID definitions will be required and flow bindings will have to be > transformed looking like the following, for example: >=20 > FID-PRI FID Flow Description BIDs Action A/I > ------- --- ---------------- ---- ------- ------ > 10 4 TCP dstPortMin=3DP1 1 Forward Active > dstPortMax=3DP(i-1) >=20 > 10 5 TCP dstPortMin=3DP(i+1) 1 Forward Active > dstPortMax=3DPN >=20 > 10 6 TCP dstPortMin=3Di 1 Discard Active >=20 > Similar should be done if there are ranges of IP addresses and/or both I= P > addresses and port numbers covered by a single FID >=20 > Does this clarify what I mean? >=20 > Regards > Yuri >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Monday, October 26, 2009 9:59 AM > To: Yuri Ismailov; George Tsirtsis > Cc: Laganier, Julien; mext@ietf.org > Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >=20 > Yuri, >=20 >=20 >>=20 >> After the text: >>=20 >> "1 Discard. This value indicates a request to discard all packets in >> the flow described by the option. No BIDs are associated with this >> Action." >>=20 >> Add the following text: >>=20 >> "In the case there is no correspondent FID to a particular flow or >> range of flows, which should be discarded, a mobile node MUST install >> a correspondent FID, otherwise error code 136 "FID not found" will be >> returned by HA. >=20 > =3D> I don't understand what this means. Can you clarify? >=20 >=20 > Care=20 >> should be taken when issuing request for discarding packets as this >> will lead to disrupting applications communication after the "Discard" >> action was applied to selected flows. Implementations may consider >> notifying impacted applications in mobile nodes" >=20 > =3D> This part is clear to me. >=20 > Hesham >=20 >>=20 >>=20 >>=20 >> Regards >> Yuri >>=20 >>=20 >> -----Original Message----- >> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >> Sent: Friday, October 23, 2009 5:54 PM >> To: Yuri Ismailov >> Cc: Laganier, Julien; mext@ietf.org >> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>=20 >> Hi Yuri, comments inline. >>=20 >> On Fri, Oct 23, 2009 at 1:20 PM, Yuri Ismailov >> >> wrote: >>> Hi Goerge, >>> Thanks for the answers, >>> What I did not understand if there will be some clarification text in >>> the draft around "discard" action or all that is obvious and does not >>> require any changes? My comment was that some additional text is needed= . >>>=20 >>=20 >> GT> I am not yet sure what non-trivial clarification we can provide. >> IMO we do not need to provide any further clarifications on this subject= . >>=20 >>> I do not think your clarification about using FID-PRI is quite clear. >>> The reason is that there is no FID for a particular flow within the >>> range There is only a FID for the whole range of port numbers and/or IP >>> addresses. >>>=20 >>=20 >> GT> What prevents you from creating another FID that is specific for >> GT> that >> flow? >>=20 >>> Surprized that disclaimer for n-cast about carefull use is in the >>> text and about disclaimer for "discard" you just say "I do not think >>> there is anything to say here." Still the question is will there be rel= ated >>> text? >>>=20 >>=20 >> GT> I think the implication of dropping packets is much clearer than >> the implication of n-casting. Dropping packets means the application >> to which the packet is sent will not receive the packet...do we really >> need to say that? On the other hand, receiving N copies of the same >> packet has some implications to TCP....this is also rather obvious for >> people that know TCP...but maybe not everyone does. >>=20 >>> Regards >>> Yuri >>>=20 >>>=20 >>> -----Original Message----- >>> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >>> Sent: Friday, October 23, 2009 11:08 AM >>> To: Yuri Ismailov >>> Cc: Laganier, Julien; mext@ietf.org >>> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>>=20 >>> Hi Yuri, >>>=20 >>> Comments inline... >>>=20 >>> On Tue, Oct 20, 2009 at 8:55 AM, Yuri Ismailov >>> >>> wrote: >>>> Hi, >>>> after re-reading the draft come up with the comment on "Discard" >>>> action in "Flow Identification Mobility Option" >>>> I suggest either to extend the paragraph in the section 4.2 or add a >>>> separate subsection clarifying behavior of MN and HA before and >>>> after the "Discard" action was issued by MN. >>>>=20 >>>> Below are the issues which=A0are proposed to=A0be addressed in the text. >>>>=20 >>>> 1.The case when installed FID represent ranges of port numbers and >>>> IP addresses. If MN decides to discard a particular flow within the >>>> range then before that a correspondent FID should be installed in the = HA. >>>> Otherwise >>>> "136 FID=A0not found" will be returned from HA. >>>>=20 >>>=20 >>> GT> If the MN wants to discard a particular flow within a range of >>> previously registered flows, it needs to either split the range it >>> two parts, or even better, use a higher FID-PRI for the =A0discard flow >>> so that packets get matched against it before they get matched against = the >>> range. >>>=20 >>>> 2. Specify the time interval for how long time the "Discard" state >>>> will be active in HA.=A0This is necessary because there is no >>>> "un-discard" message sent from MN. >>>>=20 >>>=20 >>> GT> Flow bindings share the same lifetime with the BU. There is no >>> flow binding-specific lifetime. If an MN wants to remove a flow >>> binding it sends a BU which does not include the corresponding FID. >>>=20 >>>> 3. Add a disclaimer that for some protocols, like TCP, "Discard" >>>> action may lead to hanging up the connection at CN and should be >>>> used responsibly. >>>>=20 >>>=20 >>> GT> Discarding packets will drop connections....yes...I do not think >>> there is anything to say here. >>>=20 >>>>=20 >>>> Regards >>>> Yuri >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>>=20 >>>>=20 >>>=20 >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >=20 >=20 From yuri.ismailov@ericsson.com Mon Oct 26 05:12:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFB103A6A69 for ; Mon, 26 Oct 2009 05:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[AWL=-1.458, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_101=0.6, J_CHICKENPOX_102=0.6, MANGLED_PILL=2.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 nRLFphq6QfQM for ; Mon, 26 Oct 2009 05:12:12 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B7F213A67AB for ; Mon, 26 Oct 2009 05:12:11 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-b4-4ae59227e031 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 73.E1.04191.72295EA4; Mon, 26 Oct 2009 13:12:23 +0100 (CET) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 13:12:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 13:12:21 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpT+P7Xov8p9Q8/RsCcol6n7JUwQACF8WkgAAJveWQABApIIAACGj2aAABpTLA= References: From: "Yuri Ismailov" To: "Hesham Soliman" , "George Tsirtsis" X-OriginalArrivalTime: 26 Oct 2009 12:12:23.0273 (UTC) FILETIME=[92FC1590:01CA5635] X-Brightmail-Tracker: AAAAAA== Cc: "Laganier, Julien" , mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 12:12:13 -0000 Hesham, Yes, what you're saying will do the job, not in all possible situations = though (FID-PRI number less than existing one should be available) In such case the proposal for the text, which I gave earlier would work = as well, and I would recommend to include the example which we went = through as well. Regads Yuri -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Monday, October 26, 2009 12:55 PM To: Yuri Ismailov; George Tsirtsis Cc: Laganier, Julien; mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 On 26/10/09 10:11 PM, "Yuri Ismailov" = wrote: > Hi Hesham, >=20 > If, for example, there is a FID which covers range of port numbers and = > IP addresses. In such case flow bindings may look like as following >=20 > FID-PRI FID Flow Description BIDs Action A/I > ------- --- ---------------- ---- ------- ------ > 10 4 TCP dstPortMin=3DP1 1 Forward = Active > dstPortMax=3DPN >=20 > If an MN whishes to discard some particular port number P1 < i < PN=20 > then the only possibility with the current FID table is to set The=20 > whole range to the state "Discard" =3D> No, that's not a good way to go at all. If you want to do that the = way to say discard port 100 where P1 < 100 < N then you send a new FID = with Discard action, PRI set to say 9 (higher priority). You don't need = to touch the existing one.=20 Hesham >=20 > If other port numbers in the range should be still in Active state=20 > then the new FID definitions will be required and flow bindings will=20 > have to be transformed looking like the following, for example: >=20 > FID-PRI FID Flow Description BIDs Action A/I > ------- --- ---------------- ---- ------- ------ > 10 4 TCP dstPortMin=3DP1 1 Forward = Active > dstPortMax=3DP(i-1) >=20 > 10 5 TCP dstPortMin=3DP(i+1) 1 Forward = Active > dstPortMax=3DPN >=20 > 10 6 TCP dstPortMin=3Di 1 Discard = Active >=20 > Similar should be done if there are ranges of IP addresses and/or=20 > both IP addresses and port numbers covered by a single FID >=20 > Does this clarify what I mean? >=20 > Regards > Yuri >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Monday, October 26, 2009 9:59 AM > To: Yuri Ismailov; George Tsirtsis > Cc: Laganier, Julien; mext@ietf.org > Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >=20 > Yuri, >=20 >=20 >>=20 >> After the text: >>=20 >> "1 Discard. This value indicates a request to discard all packets =20 >> in the flow described by the option. No BIDs are associated with =20 >> this Action." >>=20 >> Add the following text: >>=20 >> "In the case there is no correspondent FID to a particular flow or=20 >> range of flows, which should be discarded, a mobile node MUST install = >> a correspondent FID, otherwise error code 136 "FID not found" will be = >> returned by HA. >=20 > =3D> I don't understand what this means. Can you clarify? >=20 >=20 > Care >> should be taken when issuing request for discarding packets as this=20 >> will lead to disrupting applications communication after the = "Discard" >> action was applied to selected flows. Implementations may consider=20 >> notifying impacted applications in mobile nodes" >=20 > =3D> This part is clear to me. >=20 > Hesham >=20 >>=20 >>=20 >>=20 >> Regards >> Yuri >>=20 >>=20 >> -----Original Message----- >> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >> Sent: Friday, October 23, 2009 5:54 PM >> To: Yuri Ismailov >> Cc: Laganier, Julien; mext@ietf.org >> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>=20 >> Hi Yuri, comments inline. >>=20 >> On Fri, Oct 23, 2009 at 1:20 PM, Yuri Ismailov=20 >> >> wrote: >>> Hi Goerge, >>> Thanks for the answers, >>> What I did not understand if there will be some clarification text=20 >>> in the draft around "discard" action or all that is obvious and does = >>> not require any changes? My comment was that some additional text is = needed. >>>=20 >>=20 >> GT> I am not yet sure what non-trivial clarification we can provide. >> IMO we do not need to provide any further clarifications on this = subject. >>=20 >>> I do not think your clarification about using FID-PRI is quite = clear. >>> The reason is that there is no FID for a particular flow within the=20 >>> range There is only a FID for the whole range of port numbers and/or = >>> IP addresses. >>>=20 >>=20 >> GT> What prevents you from creating another FID that is specific for = >> GT> that >> flow? >>=20 >>> Surprized that disclaimer for n-cast about carefull use is in the=20 >>> text and about disclaimer for "discard" you just say "I do not think = >>> there is anything to say here." Still the question is will there be=20 >>> related text? >>>=20 >>=20 >> GT> I think the implication of dropping packets is much clearer than >> the implication of n-casting. Dropping packets means the application=20 >> to which the packet is sent will not receive the packet...do we=20 >> really need to say that? On the other hand, receiving N copies of the = >> same packet has some implications to TCP....this is also rather=20 >> obvious for people that know TCP...but maybe not everyone does. >>=20 >>> Regards >>> Yuri >>>=20 >>>=20 >>> -----Original Message----- >>> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >>> Sent: Friday, October 23, 2009 11:08 AM >>> To: Yuri Ismailov >>> Cc: Laganier, Julien; mext@ietf.org >>> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>>=20 >>> Hi Yuri, >>>=20 >>> Comments inline... >>>=20 >>> On Tue, Oct 20, 2009 at 8:55 AM, Yuri Ismailov=20 >>> >>> wrote: >>>> Hi, >>>> after re-reading the draft come up with the comment on "Discard" >>>> action in "Flow Identification Mobility Option" >>>> I suggest either to extend the paragraph in the section 4.2 or add=20 >>>> a separate subsection clarifying behavior of MN and HA before and=20 >>>> after the "Discard" action was issued by MN. >>>>=20 >>>> Below are the issues which=A0are proposed to=A0be addressed in the = text. >>>>=20 >>>> 1.The case when installed FID represent ranges of port numbers and=20 >>>> IP addresses. If MN decides to discard a particular flow within the = >>>> range then before that a correspondent FID should be installed in = the HA. >>>> Otherwise >>>> "136 FID=A0not found" will be returned from HA. >>>>=20 >>>=20 >>> GT> If the MN wants to discard a particular flow within a range of >>> previously registered flows, it needs to either split the range it=20 >>> two parts, or even better, use a higher FID-PRI for the =A0discard=20 >>> flow so that packets get matched against it before they get matched=20 >>> against the range. >>>=20 >>>> 2. Specify the time interval for how long time the "Discard" state=20 >>>> will be active in HA.=A0This is necessary because there is no=20 >>>> "un-discard" message sent from MN. >>>>=20 >>>=20 >>> GT> Flow bindings share the same lifetime with the BU. There is no >>> flow binding-specific lifetime. If an MN wants to remove a flow=20 >>> binding it sends a BU which does not include the corresponding FID. >>>=20 >>>> 3. Add a disclaimer that for some protocols, like TCP, "Discard" >>>> action may lead to hanging up the connection at CN and should be=20 >>>> used responsibly. >>>>=20 >>>=20 >>> GT> Discarding packets will drop connections....yes...I do not think >>> there is anything to say here. >>>=20 >>>>=20 >>>> Regards >>>> Yuri >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>>=20 >>>>=20 >>>=20 >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >=20 >=20 From hesham@elevatemobile.com Mon Oct 26 05:18:45 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 381833A6A73 for ; Mon, 26 Oct 2009 05:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.635 X-Spam-Level: X-Spam-Status: No, score=0.635 tagged_above=-999 required=5 tests=[AWL=-1.662, BAYES_00=-2.599, J_CHICKENPOX_101=0.6, J_CHICKENPOX_102=0.6, MANGLED_PILL=2.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4f+xLcXchJ7 for ; Mon, 26 Oct 2009 05:18:44 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id C4D6F3A67DB for ; Mon, 26 Oct 2009 05:18:42 -0700 (PDT) Received: from [203.219.211.243] (helo=[192.168.0.2]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1N2OX9-0006nG-KG; Mon, 26 Oct 2009 23:18:48 +1100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 26 Oct 2009 23:18:41 +1100 From: Hesham Soliman To: Yuri Ismailov , George Tsirtsis Message-ID: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpT+P7Xov8p9Q8/RsCcol6n7JUwQACF8WkgAAJveWQABApIIAACGj2aAABpTLAAAG6fVA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Cc: "Laganier, Julien" , mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 12:18:45 -0000 On 26/10/09 11:12 PM, "Yuri Ismailov" wrote: > Hesham, > Yes, what you're saying will do the job, not in all possible situations t= hough > (FID-PRI number less than existing one should be available) =3D> Sure, but since the MN knows what is available and what's not, it can renumber FIDs ...etc. > In such case the proposal for the text, which I gave earlier would work a= s > well, and I would recommend to include the example which we went through = as > well. =3D> I think the second part of your text is clear, we will have to incorporate this example in a different part of the draft, but point taken. Thanks, Hesham >=20 > Regads > Yuri >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Monday, October 26, 2009 12:55 PM > To: Yuri Ismailov; George Tsirtsis > Cc: Laganier, Julien; mext@ietf.org > Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >=20 >=20 >=20 >=20 > On 26/10/09 10:11 PM, "Yuri Ismailov" wrote: >=20 >> Hi Hesham, >>=20 >> If, for example, there is a FID which covers range of port numbers and >> IP addresses. In such case flow bindings may look like as following >>=20 >> FID-PRI FID Flow Description BIDs Action A/I >> ------- --- ---------------- ---- ------- ------ >> 10 4 TCP dstPortMin=3DP1 1 Forward Active >> dstPortMax=3DPN >>=20 >> If an MN whishes to discard some particular port number P1 < i < PN >> then the only possibility with the current FID table is to set The >> whole range to the state "Discard" >=20 > =3D> No, that's not a good way to go at all. If you want to do that the way= to > say discard port 100 where P1 < 100 < N then you send a new FID with Disc= ard > action, PRI set to say 9 (higher priority). You don't need to touch the > existing one.=20 >=20 > Hesham >=20 >=20 >>=20 >> If other port numbers in the range should be still in Active state >> then the new FID definitions will be required and flow bindings will >> have to be transformed looking like the following, for example: >>=20 >> FID-PRI FID Flow Description BIDs Action A/I >> ------- --- ---------------- ---- ------- ------ >> 10 4 TCP dstPortMin=3DP1 1 Forward Active >> dstPortMax=3DP(i-1) >>=20 >> 10 5 TCP dstPortMin=3DP(i+1) 1 Forward Active >> dstPortMax=3DPN >>=20 >> 10 6 TCP dstPortMin=3Di 1 Discard Active >>=20 >> Similar should be done if there are ranges of IP addresses and/or >> both IP addresses and port numbers covered by a single FID >>=20 >> Does this clarify what I mean? >>=20 >> Regards >> Yuri >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Monday, October 26, 2009 9:59 AM >> To: Yuri Ismailov; George Tsirtsis >> Cc: Laganier, Julien; mext@ietf.org >> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>=20 >> Yuri, >>=20 >>=20 >>>=20 >>> After the text: >>>=20 >>> "1 Discard. This value indicates a request to discard all packets >>> in the flow described by the option. No BIDs are associated with >>> this Action." >>>=20 >>> Add the following text: >>>=20 >>> "In the case there is no correspondent FID to a particular flow or >>> range of flows, which should be discarded, a mobile node MUST install >>> a correspondent FID, otherwise error code 136 "FID not found" will be >>> returned by HA. >>=20 >> =3D> I don't understand what this means. Can you clarify? >>=20 >>=20 >> Care >>> should be taken when issuing request for discarding packets as this >>> will lead to disrupting applications communication after the "Discard" >>> action was applied to selected flows. Implementations may consider >>> notifying impacted applications in mobile nodes" >>=20 >> =3D> This part is clear to me. >>=20 >> Hesham >>=20 >>>=20 >>>=20 >>>=20 >>> Regards >>> Yuri >>>=20 >>>=20 >>> -----Original Message----- >>> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >>> Sent: Friday, October 23, 2009 5:54 PM >>> To: Yuri Ismailov >>> Cc: Laganier, Julien; mext@ietf.org >>> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>>=20 >>> Hi Yuri, comments inline. >>>=20 >>> On Fri, Oct 23, 2009 at 1:20 PM, Yuri Ismailov >>> >>> wrote: >>>> Hi Goerge, >>>> Thanks for the answers, >>>> What I did not understand if there will be some clarification text >>>> in the draft around "discard" action or all that is obvious and does >>>> not require any changes? My comment was that some additional text is >>>> needed. >>>>=20 >>>=20 >>> GT> I am not yet sure what non-trivial clarification we can provide. >>> IMO we do not need to provide any further clarifications on this subjec= t. >>>=20 >>>> I do not think your clarification about using FID-PRI is quite clear. >>>> The reason is that there is no FID for a particular flow within the >>>> range There is only a FID for the whole range of port numbers and/or >>>> IP addresses. >>>>=20 >>>=20 >>> GT> What prevents you from creating another FID that is specific for >>> GT> that >>> flow? >>>=20 >>>> Surprized that disclaimer for n-cast about carefull use is in the >>>> text and about disclaimer for "discard" you just say "I do not think >>>> there is anything to say here." Still the question is will there be >>>> related text? >>>>=20 >>>=20 >>> GT> I think the implication of dropping packets is much clearer than >>> the implication of n-casting. Dropping packets means the application >>> to which the packet is sent will not receive the packet...do we >>> really need to say that? On the other hand, receiving N copies of the >>> same packet has some implications to TCP....this is also rather >>> obvious for people that know TCP...but maybe not everyone does. >>>=20 >>>> Regards >>>> Yuri >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >>>> Sent: Friday, October 23, 2009 11:08 AM >>>> To: Yuri Ismailov >>>> Cc: Laganier, Julien; mext@ietf.org >>>> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>>>=20 >>>> Hi Yuri, >>>>=20 >>>> Comments inline... >>>>=20 >>>> On Tue, Oct 20, 2009 at 8:55 AM, Yuri Ismailov >>>> >>>> wrote: >>>>> Hi, >>>>> after re-reading the draft come up with the comment on "Discard" >>>>> action in "Flow Identification Mobility Option" >>>>> I suggest either to extend the paragraph in the section 4.2 or add >>>>> a separate subsection clarifying behavior of MN and HA before and >>>>> after the "Discard" action was issued by MN. >>>>>=20 >>>>> Below are the issues which=A0are proposed to=A0be addressed in the text. >>>>>=20 >>>>> 1.The case when installed FID represent ranges of port numbers and >>>>> IP addresses. If MN decides to discard a particular flow within the >>>>> range then before that a correspondent FID should be installed in the= HA. >>>>> Otherwise >>>>> "136 FID=A0not found" will be returned from HA. >>>>>=20 >>>>=20 >>>> GT> If the MN wants to discard a particular flow within a range of >>>> previously registered flows, it needs to either split the range it >>>> two parts, or even better, use a higher FID-PRI for the =A0discard >>>> flow so that packets get matched against it before they get matched >>>> against the range. >>>>=20 >>>>> 2. Specify the time interval for how long time the "Discard" state >>>>> will be active in HA.=A0This is necessary because there is no >>>>> "un-discard" message sent from MN. >>>>>=20 >>>>=20 >>>> GT> Flow bindings share the same lifetime with the BU. There is no >>>> flow binding-specific lifetime. If an MN wants to remove a flow >>>> binding it sends a BU which does not include the corresponding FID. >>>>=20 >>>>> 3. Add a disclaimer that for some protocols, like TCP, "Discard" >>>>> action may lead to hanging up the connection at CN and should be >>>>> used responsibly. >>>>>=20 >>>>=20 >>>> GT> Discarding packets will drop connections....yes...I do not think >>>> there is anything to say here. >>>>=20 >>>>>=20 >>>>> Regards >>>>> Yuri >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>=20 >>>>>=20 >>>>=20 >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>=20 >>=20 >=20 >=20 From yuri.ismailov@ericsson.com Mon Oct 26 05:35:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6CF23A6828 for ; Mon, 26 Oct 2009 05:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_101=0.6, J_CHICKENPOX_102=0.6, MANGLED_PILL=2.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 oWemMt5SHL8Z for ; Mon, 26 Oct 2009 05:35:24 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id F3B023A6767 for ; Mon, 26 Oct 2009 05:35:23 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-51-4ae597977731 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 7C.9E.31706.79795EA4; Mon, 26 Oct 2009 13:35:36 +0100 (CET) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 13:35:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 13:35:31 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpT+P7Xov8p9Q8/RsCcol6n7JUwQACF8WkgAAJveWQABApIIAACGj2aAABpTLAAAG6fVAAAfZGA References: From: "Yuri Ismailov" To: "Hesham Soliman" , "George Tsirtsis" X-OriginalArrivalTime: 26 Oct 2009 12:35:35.0718 (UTC) FILETIME=[D0F25460:01CA5638] X-Brightmail-Tracker: AAAAAA== Cc: "Laganier, Julien" , mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 12:35:25 -0000 OK, Hope to see you in Hiroshima Regards Yuri =20 -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Monday, October 26, 2009 1:19 PM To: Yuri Ismailov; George Tsirtsis Cc: Laganier, Julien; mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 On 26/10/09 11:12 PM, "Yuri Ismailov" = wrote: > Hesham, > Yes, what you're saying will do the job, not in all possible=20 > situations though (FID-PRI number less than existing one should be=20 > available) =3D> Sure, but since the MN knows what is available and what's not, it = can renumber FIDs ...etc. > In such case the proposal for the text, which I gave earlier would=20 > work as well, and I would recommend to include the example which we=20 > went through as well. =3D> I think the second part of your text is clear, we will have to = incorporate this example in a different part of the draft, but point = taken. Thanks, Hesham >=20 > Regads > Yuri >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Monday, October 26, 2009 12:55 PM > To: Yuri Ismailov; George Tsirtsis > Cc: Laganier, Julien; mext@ietf.org > Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >=20 >=20 >=20 >=20 > On 26/10/09 10:11 PM, "Yuri Ismailov" = wrote: >=20 >> Hi Hesham, >>=20 >> If, for example, there is a FID which covers range of port numbers=20 >> and IP addresses. In such case flow bindings may look like as=20 >> following >>=20 >> FID-PRI FID Flow Description BIDs Action A/I >> ------- --- ---------------- ---- ------- ------ >> 10 4 TCP dstPortMin=3DP1 1 Forward = Active >> dstPortMax=3DPN >>=20 >> If an MN whishes to discard some particular port number P1 < i < PN=20 >> then the only possibility with the current FID table is to set The=20 >> whole range to the state "Discard" >=20 > =3D> No, that's not a good way to go at all. If you want to do that = the=20 > way to say discard port 100 where P1 < 100 < N then you send a new FID = > with Discard action, PRI set to say 9 (higher priority). You don't=20 > need to touch the existing one. >=20 > Hesham >=20 >=20 >>=20 >> If other port numbers in the range should be still in Active state=20 >> then the new FID definitions will be required and flow bindings will=20 >> have to be transformed looking like the following, for example: >>=20 >> FID-PRI FID Flow Description BIDs Action A/I >> ------- --- ---------------- ---- ------- ------ >> 10 4 TCP dstPortMin=3DP1 1 Forward = Active >> dstPortMax=3DP(i-1) >>=20 >> 10 5 TCP dstPortMin=3DP(i+1) 1 Forward = Active >> dstPortMax=3DPN >>=20 >> 10 6 TCP dstPortMin=3Di 1 Discard = Active >>=20 >> Similar should be done if there are ranges of IP addresses and/or=20 >> both IP addresses and port numbers covered by a single FID >>=20 >> Does this clarify what I mean? >>=20 >> Regards >> Yuri >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Monday, October 26, 2009 9:59 AM >> To: Yuri Ismailov; George Tsirtsis >> Cc: Laganier, Julien; mext@ietf.org >> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>=20 >> Yuri, >>=20 >>=20 >>>=20 >>> After the text: >>>=20 >>> "1 Discard. This value indicates a request to discard all packets=20 >>> in the flow described by the option. No BIDs are associated with=20 >>> this Action." >>>=20 >>> Add the following text: >>>=20 >>> "In the case there is no correspondent FID to a particular flow or=20 >>> range of flows, which should be discarded, a mobile node MUST=20 >>> install a correspondent FID, otherwise error code 136 "FID not=20 >>> found" will be returned by HA. >>=20 >> =3D> I don't understand what this means. Can you clarify? >>=20 >>=20 >> Care >>> should be taken when issuing request for discarding packets as this=20 >>> will lead to disrupting applications communication after the = "Discard" >>> action was applied to selected flows. Implementations may consider=20 >>> notifying impacted applications in mobile nodes" >>=20 >> =3D> This part is clear to me. >>=20 >> Hesham >>=20 >>>=20 >>>=20 >>>=20 >>> Regards >>> Yuri >>>=20 >>>=20 >>> -----Original Message----- >>> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >>> Sent: Friday, October 23, 2009 5:54 PM >>> To: Yuri Ismailov >>> Cc: Laganier, Julien; mext@ietf.org >>> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>>=20 >>> Hi Yuri, comments inline. >>>=20 >>> On Fri, Oct 23, 2009 at 1:20 PM, Yuri Ismailov=20 >>> >>> wrote: >>>> Hi Goerge, >>>> Thanks for the answers, >>>> What I did not understand if there will be some clarification text=20 >>>> in the draft around "discard" action or all that is obvious and=20 >>>> does not require any changes? My comment was that some additional=20 >>>> text is needed. >>>>=20 >>>=20 >>> GT> I am not yet sure what non-trivial clarification we can provide. >>> IMO we do not need to provide any further clarifications on this = subject. >>>=20 >>>> I do not think your clarification about using FID-PRI is quite = clear. >>>> The reason is that there is no FID for a particular flow within the = >>>> range There is only a FID for the whole range of port numbers=20 >>>> and/or IP addresses. >>>>=20 >>>=20 >>> GT> What prevents you from creating another FID that is specific=20 >>> GT> for that >>> flow? >>>=20 >>>> Surprized that disclaimer for n-cast about carefull use is in the=20 >>>> text and about disclaimer for "discard" you just say "I do not=20 >>>> think there is anything to say here." Still the question is will=20 >>>> there be related text? >>>>=20 >>>=20 >>> GT> I think the implication of dropping packets is much clearer than >>> the implication of n-casting. Dropping packets means the application = >>> to which the packet is sent will not receive the packet...do we=20 >>> really need to say that? On the other hand, receiving N copies of=20 >>> the same packet has some implications to TCP....this is also rather=20 >>> obvious for people that know TCP...but maybe not everyone does. >>>=20 >>>> Regards >>>> Yuri >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >>>> Sent: Friday, October 23, 2009 11:08 AM >>>> To: Yuri Ismailov >>>> Cc: Laganier, Julien; mext@ietf.org >>>> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>>>=20 >>>> Hi Yuri, >>>>=20 >>>> Comments inline... >>>>=20 >>>> On Tue, Oct 20, 2009 at 8:55 AM, Yuri Ismailov=20 >>>> >>>> wrote: >>>>> Hi, >>>>> after re-reading the draft come up with the comment on "Discard" >>>>> action in "Flow Identification Mobility Option" >>>>> I suggest either to extend the paragraph in the section 4.2 or add = >>>>> a separate subsection clarifying behavior of MN and HA before and=20 >>>>> after the "Discard" action was issued by MN. >>>>>=20 >>>>> Below are the issues which=A0are proposed to=A0be addressed in the = text. >>>>>=20 >>>>> 1.The case when installed FID represent ranges of port numbers and = >>>>> IP addresses. If MN decides to discard a particular flow within=20 >>>>> the range then before that a correspondent FID should be installed = in the HA. >>>>> Otherwise >>>>> "136 FID=A0not found" will be returned from HA. >>>>>=20 >>>>=20 >>>> GT> If the MN wants to discard a particular flow within a range of >>>> previously registered flows, it needs to either split the range it=20 >>>> two parts, or even better, use a higher FID-PRI for the =A0discard=20 >>>> flow so that packets get matched against it before they get matched = >>>> against the range. >>>>=20 >>>>> 2. Specify the time interval for how long time the "Discard" state = >>>>> will be active in HA.=A0This is necessary because there is no=20 >>>>> "un-discard" message sent from MN. >>>>>=20 >>>>=20 >>>> GT> Flow bindings share the same lifetime with the BU. There is no >>>> flow binding-specific lifetime. If an MN wants to remove a flow=20 >>>> binding it sends a BU which does not include the corresponding FID. >>>>=20 >>>>> 3. Add a disclaimer that for some protocols, like TCP, "Discard" >>>>> action may lead to hanging up the connection at CN and should be=20 >>>>> used responsibly. >>>>>=20 >>>>=20 >>>> GT> Discarding packets will drop connections....yes...I do not=20 >>>> GT> think >>>> there is anything to say here. >>>>=20 >>>>>=20 >>>>> Regards >>>>> Yuri >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>=20 >>>>>=20 >>>>=20 >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>=20 >>=20 >=20 >=20 From tsirtsis@googlemail.com Mon Oct 26 08:02:06 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A13C83A6A87 for ; Mon, 26 Oct 2009 08:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.19 X-Spam-Level: X-Spam-Status: No, score=-0.19 tagged_above=-999 required=5 tests=[AWL=-1.712, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_101=0.6, J_CHICKENPOX_102=0.6, MANGLED_PILL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mw7427vKBq-s for ; Mon, 26 Oct 2009 08:02:05 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 883393A6A88 for ; Mon, 26 Oct 2009 08:02:04 -0700 (PDT) Received: by fxm18 with SMTP id 18so12131899fxm.37 for ; Mon, 26 Oct 2009 08:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gN+gVfYO0sIVQtDR0fM98XEXYPFcVCEqp6ync+c/xck=; b=HLK9bQdkHwrlDMYtIlzgjRcxm9HWzDwqeMi6J6surcGezuFLCEOZ4WR3BKqBaTRhF/ 5k1rmzCYqdrFMp0BDSOSX5hcH5zM6Bwq1Nx74T233PWpnWMaPmZpA9txZTPzVK2HAuUi W3SjLD9AWGzUveK5EZzaCHdhOHrBbn8xL8Ofw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tG8Pq9GOrnzFbmBhqi3h/FEgnM5O/K5aYTeJ0uBJMjUyZecHqX/B+shNryjXXRvFT9 MGQ1XtAOZgYJHvqoZxQLw8PMp3H7/VMsJlqKgg7AH/FU78BjfMWhelIb+nraT3J2Fe4P G2q2ZzUpItbwngvuzbIGwbOj4g43u8eNEgY5M= MIME-Version: 1.0 Received: by 10.239.142.146 with SMTP id g18mr562659hba.105.1256569333658; Mon, 26 Oct 2009 08:02:13 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Oct 2009 15:02:13 +0000 Message-ID: From: George Tsirtsis To: Hesham Soliman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Laganier, Julien" , mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:02:06 -0000 Folks, I do not agree with adding examples like that. there is a virtually infinite number of traffic flows resulting in an equivalent number of traffic selector combinations. It is also a really large number of different ways of putting together TSs that do exactly the same thing. All this is at the discretion of the implementor and we should not get in the middle of it. Regards George On Mon, Oct 26, 2009 at 12:18 PM, Hesham Soliman wrote: > > > > On 26/10/09 11:12 PM, "Yuri Ismailov" wrote: > >> Hesham, >> Yes, what you're saying will do the job, not in all possible situations = though >> (FID-PRI number less than existing one should be available) > > =3D> Sure, but since the MN knows what is available and what's not, it ca= n > renumber FIDs ...etc. > >> In such case the proposal for the text, which I gave earlier would work = as >> well, and I would recommend to include the example which we went through= as >> well. > > =3D> I think the second part of your text is clear, we will have to > incorporate this example in a different part of the draft, but point take= n. > > Thanks, > Hesham > >> >> Regads >> Yuri >> >> >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Monday, October 26, 2009 12:55 PM >> To: Yuri Ismailov; George Tsirtsis >> Cc: Laganier, Julien; mext@ietf.org >> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >> >> >> >> >> On 26/10/09 10:11 PM, "Yuri Ismailov" wrote= : >> >>> Hi Hesham, >>> >>> If, for example, there is a FID which covers range of port numbers and >>> IP addresses. In such case flow bindings may look like as following >>> >>> =C2=A0 =C2=A0 FID-PRI =C2=A0 =C2=A0 FID =C2=A0 =C2=A0Flow Description = =C2=A0 =C2=A0BIDs =C2=A0 =C2=A0Action =C2=A0 =C2=A0 =C2=A0 A/I >>> =C2=A0 =C2=A0 ------- =C2=A0 =C2=A0 --- =C2=A0 =C2=A0---------------- = =C2=A0 =C2=A0---- =C2=A0 =C2=A0------- =C2=A0 =C2=A0 ------ >>> =C2=A0 =C2=A0 =C2=A0 =C2=A010 =C2=A0 =C2=A0 =C2=A0 =C2=A04 =C2=A0 =C2= =A0 TCP dstPortMin=3DP1 =C2=A0 =C2=A01 =C2=A0 =C2=A0 =C2=A0Forward =C2=A0 = =C2=A0 Active >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0dstPortMax=3DPN >>> >>> If an MN whishes to discard some particular port number =C2=A0P1 < i < = PN >>> then the only possibility with the current FID table is to set The >>> whole range to the state "Discard" >> >> =3D> No, that's not a good way to go at all. If you want to do that the = way to >> say discard port 100 where P1 < 100 < N then you send a new FID with Dis= card >> action, PRI set to say 9 (higher priority). You don't need to touch the >> existing one. >> >> Hesham >> >> >>> >>> If other port numbers in the range should be still in Active state >>> then the new FID definitions will be required and flow bindings will >>> have to be transformed looking like the following, for example: >>> >>> =C2=A0 =C2=A0 FID-PRI =C2=A0 =C2=A0 FID =C2=A0 =C2=A0Flow Description = =C2=A0 =C2=A0BIDs =C2=A0 =C2=A0Action =C2=A0 =C2=A0 =C2=A0 A/I >>> =C2=A0 =C2=A0 ------- =C2=A0 =C2=A0 --- =C2=A0 =C2=A0---------------- = =C2=A0 =C2=A0---- =C2=A0 =C2=A0------- =C2=A0 =C2=A0 ------ >>> =C2=A0 =C2=A0 =C2=A0 =C2=A010 =C2=A0 =C2=A0 =C2=A0 =C2=A04 =C2=A0 =C2= =A0 TCP dstPortMin=3DP1 =C2=A0 =C2=A01 =C2=A0 =C2=A0 =C2=A0Forward =C2=A0 = =C2=A0 Active >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0dstPortMax=3DP(i-1) >>> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A010 =C2=A0 =C2=A0 =C2=A0 =C2=A05 =C2=A0 =C2= =A0TCP dstPortMin=3DP(i+1) 1 =C2=A0 =C2=A0 =C2=A0Forward =C2=A0 =C2=A0 Acti= ve >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0dstPortMax=3DPN >>> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A010 =C2=A0 =C2=A0 =C2=A0 =C2=A06 =C2=A0 =C2= =A0 TCP dstPortMin=3Di =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 Discard =C2=A0 = =C2=A0 Active >>> >>> Similar =C2=A0should be done if there are ranges of IP addresses and/or >>> both IP addresses and port numbers covered by a single FID >>> >>> Does this clarify what I mean? >>> >>> Regards >>> Yuri >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Monday, October 26, 2009 9:59 AM >>> To: Yuri Ismailov; George Tsirtsis >>> Cc: Laganier, Julien; mext@ietf.org >>> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>> >>> Yuri, >>> >>> >>>> >>>> After the text: >>>> >>>> "1 Discard. =C2=A0This value indicates a request to discard all packet= s >>>> in the flow described by the option. =C2=A0No BIDs are associated with >>>> this Action." >>>> >>>> Add the following text: >>>> >>>> "In the case there is no correspondent FID to a particular flow or >>>> range of flows, which should be discarded, a mobile node MUST install >>>> a correspondent FID, otherwise error code 136 "FID not found" will be >>>> returned by HA. >>> >>> =3D> I don't understand what this means. Can you clarify? >>> >>> >>> =C2=A0 Care >>>> should be taken when issuing request for discarding packets as this >>>> will lead to disrupting applications communication after the "Discard" >>>> action was applied to selected flows. Implementations may consider >>>> notifying impacted applications in mobile nodes" >>> >>> =3D> This part is clear to me. >>> >>> Hesham >>> >>>> >>>> >>>> >>>> Regards >>>> Yuri >>>> >>>> >>>> -----Original Message----- >>>> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >>>> Sent: Friday, October 23, 2009 5:54 PM >>>> To: Yuri Ismailov >>>> Cc: Laganier, Julien; mext@ietf.org >>>> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>>> >>>> Hi Yuri, comments inline. >>>> >>>> On Fri, Oct 23, 2009 at 1:20 PM, Yuri Ismailov >>>> >>>> wrote: >>>>> Hi Goerge, >>>>> Thanks for the answers, >>>>> What I did not understand if there will be some clarification text >>>>> in the draft around "discard" action or all that is obvious and does >>>>> not require any changes? My comment was that some additional text is >>>>> needed. >>>>> >>>> >>>> GT> I am not yet sure what non-trivial clarification we can provide. >>>> IMO we do not need to provide any further clarifications on this subje= ct. >>>> >>>>> I do not think your clarification about using FID-PRI is quite clear. >>>>> The reason is that there is no FID for a particular flow within the >>>>> range There is only a FID for the whole range of port numbers and/or >>>>> IP addresses. >>>>> >>>> >>>> GT> What prevents you from =C2=A0creating another FID that is specific= for >>>> GT> that >>>> flow? >>>> >>>>> Surprized that disclaimer for n-cast about carefull use is in the >>>>> text and about disclaimer for "discard" you just say "I do not think >>>>> there is anything to say here." Still the question is will there be >>>>> related text? >>>>> >>>> >>>> GT> I think the implication of dropping packets is much clearer than >>>> the implication of n-casting. Dropping packets means the application >>>> to which the packet is sent will not receive the packet...do we >>>> really need to say that? On the other hand, receiving N copies of the >>>> same packet has some implications to TCP....this is also rather >>>> obvious for people that know TCP...but maybe not everyone does. >>>> >>>>> Regards >>>>> Yuri >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >>>>> Sent: Friday, October 23, 2009 11:08 AM >>>>> To: Yuri Ismailov >>>>> Cc: Laganier, Julien; mext@ietf.org >>>>> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>>>> >>>>> Hi Yuri, >>>>> >>>>> Comments inline... >>>>> >>>>> On Tue, Oct 20, 2009 at 8:55 AM, Yuri Ismailov >>>>> >>>>> wrote: >>>>>> Hi, >>>>>> after re-reading the draft come up with the comment on "Discard" >>>>>> action in "Flow Identification Mobility Option" >>>>>> I suggest either to extend the paragraph in the section 4.2 or add >>>>>> a separate subsection clarifying behavior of MN and HA before and >>>>>> after the "Discard" action was issued by MN. >>>>>> >>>>>> Below are the issues which=C2=A0are proposed to=C2=A0be addressed in= the text. >>>>>> >>>>>> 1.The case when installed FID represent ranges of port numbers and >>>>>> IP addresses. If MN decides to discard a particular flow within the >>>>>> range then before that a correspondent FID should be installed in th= e HA. >>>>>> Otherwise >>>>>> "136 FID=C2=A0not found" will be returned from HA. >>>>>> >>>>> >>>>> GT> If the MN wants to discard a particular flow within a range of >>>>> previously registered flows, it needs to either split the range it >>>>> two parts, or even better, use a higher FID-PRI for the =C2=A0discard >>>>> flow so that packets get matched against it before they get matched >>>>> against the range. >>>>> >>>>>> 2. Specify the time interval for how long time the "Discard" state >>>>>> will be active in HA.=C2=A0This is necessary because there is no >>>>>> "un-discard" message sent from MN. >>>>>> >>>>> >>>>> GT> Flow bindings share the same lifetime with the BU. There is no >>>>> flow binding-specific lifetime. If an MN wants to remove a flow >>>>> binding it sends a BU which does not include the corresponding FID. >>>>> >>>>>> 3. Add a disclaimer that for some protocols, like TCP, "Discard" >>>>>> action may lead to hanging up the connection at CN and should be >>>>>> used responsibly. >>>>>> >>>>> >>>>> GT> Discarding packets will drop connections....yes...I do not think >>>>> there is anything to say here. >>>>> >>>>>> >>>>>> Regards >>>>>> Yuri >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >> >> > > > From xiayangsong@huawei.com Mon Oct 26 08:13:33 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40EE43A6A9B for ; Mon, 26 Oct 2009 08:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[AWL=-1.623, BAYES_00=-2.599, J_CHICKENPOX_101=0.6, J_CHICKENPOX_102=0.6, MANGLED_PILL=2.3, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJiXyv9+whdM for ; Mon, 26 Oct 2009 08:13:32 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 087F03A6A79 for ; Mon, 26 Oct 2009 08:13:32 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS40011KNMV8T@usaga04-in.huawei.com> for mext@ietf.org; Mon, 26 Oct 2009 10:13:45 -0500 (CDT) Received: from X24512z ([10.124.12.62]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KS400H0BNMRIK@usaga04-in.huawei.com> for mext@ietf.org; Mon, 26 Oct 2009 10:13:43 -0500 (CDT) Date: Mon, 26 Oct 2009 10:13:39 -0500 From: Frank Xia To: George Tsirtsis , Hesham Soliman Message-id: <007f01ca564e$e8157a80$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=utf-8; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Cc: "Laganier, Julien" , mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:13:33 -0000 Hi George It will help mobile application to make use of underline flow binding mechnism. You can put in a seperate appendix. BR Frank ----- Original Message ----- From: "George Tsirtsis" To: "Hesham Soliman" Cc: "Laganier, Julien" ; Sent: Monday, October 26, 2009 10:02 AM Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 > Folks, > > I do not agree with adding examples like that. there is a virtually > infinite number of traffic flows resulting in an equivalent number of > traffic selector combinations. It is also a really large number of > different ways of putting together TSs that do exactly the same thing. > All this is at the discretion of the implementor and we should not get > in the middle of it. > > Regards > George > > On Mon, Oct 26, 2009 at 12:18 PM, Hesham Soliman > wrote: >> >> >> >> On 26/10/09 11:12 PM, "Yuri Ismailov" wrote: >> >>> Hesham, >>> Yes, what you're saying will do the job, not in all possible situations >>> though >>> (FID-PRI number less than existing one should be available) >> >> => Sure, but since the MN knows what is available and what's not, it can >> renumber FIDs ...etc. >> >>> In such case the proposal for the text, which I gave earlier would work >>> as >>> well, and I would recommend to include the example which we went through >>> as >>> well. >> >> => I think the second part of your text is clear, we will have to >> incorporate this example in a different part of the draft, but point >> taken. >> >> Thanks, >> Hesham >> >>> >>> Regads >>> Yuri >>> >>> >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Monday, October 26, 2009 12:55 PM >>> To: Yuri Ismailov; George Tsirtsis >>> Cc: Laganier, Julien; mext@ietf.org >>> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>> >>> >>> >>> >>> On 26/10/09 10:11 PM, "Yuri Ismailov" >>> wrote: >>> >>>> Hi Hesham, >>>> >>>> If, for example, there is a FID which covers range of port numbers and >>>> IP addresses. In such case flow bindings may look like as following >>>> >>>> FID-PRI FID Flow Description BIDs Action A/I >>>> ------- --- ---------------- ---- ------- ------ >>>> 10 4 TCP dstPortMin=P1 1 Forward Active >>>> dstPortMax=PN >>>> >>>> If an MN whishes to discard some particular port number P1 < i < PN >>>> then the only possibility with the current FID table is to set The >>>> whole range to the state "Discard" >>> >>> => No, that's not a good way to go at all. If you want to do that the >>> way to >>> say discard port 100 where P1 < 100 < N then you send a new FID with >>> Discard >>> action, PRI set to say 9 (higher priority). You don't need to touch the >>> existing one. >>> >>> Hesham >>> >>> >>>> >>>> If other port numbers in the range should be still in Active state >>>> then the new FID definitions will be required and flow bindings will >>>> have to be transformed looking like the following, for example: >>>> >>>> FID-PRI FID Flow Description BIDs Action A/I >>>> ------- --- ---------------- ---- ------- ------ >>>> 10 4 TCP dstPortMin=P1 1 Forward Active >>>> dstPortMax=P(i-1) >>>> >>>> 10 5 TCP dstPortMin=P(i+1) 1 Forward Active >>>> dstPortMax=PN >>>> >>>> 10 6 TCP dstPortMin=i 1 Discard Active >>>> >>>> Similar should be done if there are ranges of IP addresses and/or >>>> both IP addresses and port numbers covered by a single FID >>>> >>>> Does this clarify what I mean? >>>> >>>> Regards >>>> Yuri >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>> Sent: Monday, October 26, 2009 9:59 AM >>>> To: Yuri Ismailov; George Tsirtsis >>>> Cc: Laganier, Julien; mext@ietf.org >>>> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>>> >>>> Yuri, >>>> >>>> >>>>> >>>>> After the text: >>>>> >>>>> "1 Discard. This value indicates a request to discard all packets >>>>> in the flow described by the option. No BIDs are associated with >>>>> this Action." >>>>> >>>>> Add the following text: >>>>> >>>>> "In the case there is no correspondent FID to a particular flow or >>>>> range of flows, which should be discarded, a mobile node MUST install >>>>> a correspondent FID, otherwise error code 136 "FID not found" will be >>>>> returned by HA. >>>> >>>> => I don't understand what this means. Can you clarify? >>>> >>>> >>>> Care >>>>> should be taken when issuing request for discarding packets as this >>>>> will lead to disrupting applications communication after the "Discard" >>>>> action was applied to selected flows. Implementations may consider >>>>> notifying impacted applications in mobile nodes" >>>> >>>> => This part is clear to me. >>>> >>>> Hesham >>>> >>>>> >>>>> >>>>> >>>>> Regards >>>>> Yuri >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >>>>> Sent: Friday, October 23, 2009 5:54 PM >>>>> To: Yuri Ismailov >>>>> Cc: Laganier, Julien; mext@ietf.org >>>>> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>>>> >>>>> Hi Yuri, comments inline. >>>>> >>>>> On Fri, Oct 23, 2009 at 1:20 PM, Yuri Ismailov >>>>> >>>>> wrote: >>>>>> Hi Goerge, >>>>>> Thanks for the answers, >>>>>> What I did not understand if there will be some clarification text >>>>>> in the draft around "discard" action or all that is obvious and does >>>>>> not require any changes? My comment was that some additional text is >>>>>> needed. >>>>>> >>>>> >>>>> GT> I am not yet sure what non-trivial clarification we can provide. >>>>> IMO we do not need to provide any further clarifications on this >>>>> subject. >>>>> >>>>>> I do not think your clarification about using FID-PRI is quite clear. >>>>>> The reason is that there is no FID for a particular flow within the >>>>>> range There is only a FID for the whole range of port numbers and/or >>>>>> IP addresses. >>>>>> >>>>> >>>>> GT> What prevents you from creating another FID that is specific for >>>>> GT> that >>>>> flow? >>>>> >>>>>> Surprized that disclaimer for n-cast about carefull use is in the >>>>>> text and about disclaimer for "discard" you just say "I do not think >>>>>> there is anything to say here." Still the question is will there be >>>>>> related text? >>>>>> >>>>> >>>>> GT> I think the implication of dropping packets is much clearer than >>>>> the implication of n-casting. Dropping packets means the application >>>>> to which the packet is sent will not receive the packet...do we >>>>> really need to say that? On the other hand, receiving N copies of the >>>>> same packet has some implications to TCP....this is also rather >>>>> obvious for people that know TCP...but maybe not everyone does. >>>>> >>>>>> Regards >>>>>> Yuri >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >>>>>> Sent: Friday, October 23, 2009 11:08 AM >>>>>> To: Yuri Ismailov >>>>>> Cc: Laganier, Julien; mext@ietf.org >>>>>> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>>>>> >>>>>> Hi Yuri, >>>>>> >>>>>> Comments inline... >>>>>> >>>>>> On Tue, Oct 20, 2009 at 8:55 AM, Yuri Ismailov >>>>>> >>>>>> wrote: >>>>>>> Hi, >>>>>>> after re-reading the draft come up with the comment on "Discard" >>>>>>> action in "Flow Identification Mobility Option" >>>>>>> I suggest either to extend the paragraph in the section 4.2 or add >>>>>>> a separate subsection clarifying behavior of MN and HA before and >>>>>>> after the "Discard" action was issued by MN. >>>>>>> >>>>>>> Below are the issues which are proposed to be addressed in the text. >>>>>>> >>>>>>> 1.The case when installed FID represent ranges of port numbers and >>>>>>> IP addresses. If MN decides to discard a particular flow within the >>>>>>> range then before that a correspondent FID should be installed in >>>>>>> the HA. >>>>>>> Otherwise >>>>>>> "136 FID not found" will be returned from HA. >>>>>>> >>>>>> >>>>>> GT> If the MN wants to discard a particular flow within a range of >>>>>> previously registered flows, it needs to either split the range it >>>>>> two parts, or even better, use a higher FID-PRI for the discard >>>>>> flow so that packets get matched against it before they get matched >>>>>> against the range. >>>>>> >>>>>>> 2. Specify the time interval for how long time the "Discard" state >>>>>>> will be active in HA. This is necessary because there is no >>>>>>> "un-discard" message sent from MN. >>>>>>> >>>>>> >>>>>> GT> Flow bindings share the same lifetime with the BU. There is no >>>>>> flow binding-specific lifetime. If an MN wants to remove a flow >>>>>> binding it sends a BU which does not include the corresponding FID. >>>>>> >>>>>>> 3. Add a disclaimer that for some protocols, like TCP, "Discard" >>>>>>> action may lead to hanging up the connection at CN and should be >>>>>>> used responsibly. >>>>>>> >>>>>> >>>>>> GT> Discarding packets will drop connections....yes...I do not think >>>>>> there is anything to say here. >>>>>> >>>>>>> >>>>>>> Regards >>>>>>> Yuri >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> MEXT mailing 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 yuri.ismailov@ericsson.com Mon Oct 26 08:43:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A10FF3A6A88 for ; Mon, 26 Oct 2009 08:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.843 X-Spam-Level: X-Spam-Status: No, score=-3.843 tagged_above=-999 required=5 tests=[AWL=-1.094, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_101=0.6, J_CHICKENPOX_102=0.6, MANGLED_PILL=2.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 m-rUENIS0e5A for ; Mon, 26 Oct 2009 08:43:03 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 5733E3A694A for ; Mon, 26 Oct 2009 08:43:02 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-ff-4ae5c392c681 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 39.DC.31706.293C5EA4; Mon, 26 Oct 2009 16:43:14 +0100 (CET) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 16:43:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 16:43:13 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Thread-Index: AcpWTU3S+QtKKCjMQiiubQLBGwImiQABX4KQ References: From: "Yuri Ismailov" To: "George Tsirtsis" , "Hesham Soliman" X-OriginalArrivalTime: 26 Oct 2009 15:43:14.0257 (UTC) FILETIME=[078F0C10:01CA5653] X-Brightmail-Tracker: AAAAAA== Cc: "Laganier, Julien" , mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:43:04 -0000 George, There is no need to give infinite number of examples, just one for = clarifying purposes I think it makes things clearer /yuri =20 -----Original Message----- From: George Tsirtsis [mailto:tsirtsis@googlemail.com]=20 Sent: Monday, October 26, 2009 4:02 PM To: Hesham Soliman Cc: Yuri Ismailov; Laganier, Julien; mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 Folks, I do not agree with adding examples like that. there is a virtually = infinite number of traffic flows resulting in an equivalent number of = traffic selector combinations. It is also a really large number of = different ways of putting together TSs that do exactly the same thing. All this is at the discretion of the implementor and we should not get = in the middle of it. Regards George On Mon, Oct 26, 2009 at 12:18 PM, Hesham Soliman = wrote: > > > > On 26/10/09 11:12 PM, "Yuri Ismailov" = wrote: > >> Hesham, >> Yes, what you're saying will do the job, not in all possible=20 >> situations though (FID-PRI number less than existing one should be=20 >> available) > > =3D> Sure, but since the MN knows what is available and what's not, it = > can renumber FIDs ...etc. > >> In such case the proposal for the text, which I gave earlier would=20 >> work as well, and I would recommend to include the example which we=20 >> went through as well. > > =3D> I think the second part of your text is clear, we will have to=20 > incorporate this example in a different part of the draft, but point = taken. > > Thanks, > Hesham > >> >> Regads >> Yuri >> >> >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Monday, October 26, 2009 12:55 PM >> To: Yuri Ismailov; George Tsirtsis >> Cc: Laganier, Julien; mext@ietf.org >> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >> >> >> >> >> On 26/10/09 10:11 PM, "Yuri Ismailov" = wrote: >> >>> Hi Hesham, >>> >>> If, for example, there is a FID which covers range of port numbers=20 >>> and IP addresses. In such case flow bindings may look like as=20 >>> following >>> >>> =A0 =A0 FID-PRI =A0 =A0 FID =A0 =A0Flow Description =A0 =A0BIDs =A0 = =A0Action =A0 =A0 =A0 A/I >>> =A0 =A0 ------- =A0 =A0 --- =A0 =A0---------------- =A0 =A0---- =A0 = =A0------- =A0 =A0=20 >>> ------ >>> =A0 =A0 =A0 =A010 =A0 =A0 =A0 =A04 =A0 =A0 TCP dstPortMin=3DP1 =A0 = =A01 =A0 =A0 =A0Forward =A0 =A0=20 >>> Active >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0dstPortMax=3DPN >>> >>> If an MN whishes to discard some particular port number =A0P1 < i < = PN=20 >>> then the only possibility with the current FID table is to set The=20 >>> whole range to the state "Discard" >> >> =3D> No, that's not a good way to go at all. If you want to do that = the=20 >> way to say discard port 100 where P1 < 100 < N then you send a new=20 >> FID with Discard action, PRI set to say 9 (higher priority). You=20 >> don't need to touch the existing one. >> >> Hesham >> >> >>> >>> If other port numbers in the range should be still in Active state=20 >>> then the new FID definitions will be required and flow bindings will = >>> have to be transformed looking like the following, for example: >>> >>> =A0 =A0 FID-PRI =A0 =A0 FID =A0 =A0Flow Description =A0 =A0BIDs =A0 = =A0Action =A0 =A0 =A0 A/I >>> =A0 =A0 ------- =A0 =A0 --- =A0 =A0---------------- =A0 =A0---- =A0 = =A0------- =A0 =A0=20 >>> ------ >>> =A0 =A0 =A0 =A010 =A0 =A0 =A0 =A04 =A0 =A0 TCP dstPortMin=3DP1 =A0 = =A01 =A0 =A0 =A0Forward =A0 =A0=20 >>> Active >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0dstPortMax=3DP(i-1) >>> >>> =A0 =A0 =A0 =A010 =A0 =A0 =A0 =A05 =A0 =A0TCP dstPortMin=3DP(i+1) 1 = =A0 =A0 =A0Forward =A0 =A0=20 >>> Active >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dstPortMax=3DPN >>> >>> =A0 =A0 =A0 =A010 =A0 =A0 =A0 =A06 =A0 =A0 TCP dstPortMin=3Di =A0 = =A0 1 =A0 =A0 =A0 Discard =A0 =A0=20 >>> Active >>> >>> Similar =A0should be done if there are ranges of IP addresses and/or = >>> both IP addresses and port numbers covered by a single FID >>> >>> Does this clarify what I mean? >>> >>> Regards >>> Yuri >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Monday, October 26, 2009 9:59 AM >>> To: Yuri Ismailov; George Tsirtsis >>> Cc: Laganier, Julien; mext@ietf.org >>> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>> >>> Yuri, >>> >>> >>>> >>>> After the text: >>>> >>>> "1 Discard. =A0This value indicates a request to discard all = packets=20 >>>> in the flow described by the option. =A0No BIDs are associated with = >>>> this Action." >>>> >>>> Add the following text: >>>> >>>> "In the case there is no correspondent FID to a particular flow or=20 >>>> range of flows, which should be discarded, a mobile node MUST=20 >>>> install a correspondent FID, otherwise error code 136 "FID not=20 >>>> found" will be returned by HA. >>> >>> =3D> I don't understand what this means. Can you clarify? >>> >>> >>> =A0 Care >>>> should be taken when issuing request for discarding packets as this = >>>> will lead to disrupting applications communication after the = "Discard" >>>> action was applied to selected flows. Implementations may consider=20 >>>> notifying impacted applications in mobile nodes" >>> >>> =3D> This part is clear to me. >>> >>> Hesham >>> >>>> >>>> >>>> >>>> Regards >>>> Yuri >>>> >>>> >>>> -----Original Message----- >>>> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >>>> Sent: Friday, October 23, 2009 5:54 PM >>>> To: Yuri Ismailov >>>> Cc: Laganier, Julien; mext@ietf.org >>>> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>>> >>>> Hi Yuri, comments inline. >>>> >>>> On Fri, Oct 23, 2009 at 1:20 PM, Yuri Ismailov=20 >>>> >>>> wrote: >>>>> Hi Goerge, >>>>> Thanks for the answers, >>>>> What I did not understand if there will be some clarification text = >>>>> in the draft around "discard" action or all that is obvious and=20 >>>>> does not require any changes? My comment was that some additional=20 >>>>> text is needed. >>>>> >>>> >>>> GT> I am not yet sure what non-trivial clarification we can = provide. >>>> IMO we do not need to provide any further clarifications on this = subject. >>>> >>>>> I do not think your clarification about using FID-PRI is quite = clear. >>>>> The reason is that there is no FID for a particular flow within=20 >>>>> the range There is only a FID for the whole range of port numbers=20 >>>>> and/or IP addresses. >>>>> >>>> >>>> GT> What prevents you from =A0creating another FID that is specific = >>>> GT> for that >>>> flow? >>>> >>>>> Surprized that disclaimer for n-cast about carefull use is in the=20 >>>>> text and about disclaimer for "discard" you just say "I do not=20 >>>>> think there is anything to say here." Still the question is will=20 >>>>> there be related text? >>>>> >>>> >>>> GT> I think the implication of dropping packets is much clearer=20 >>>> GT> than >>>> the implication of n-casting. Dropping packets means the=20 >>>> application to which the packet is sent will not receive the=20 >>>> packet...do we really need to say that? On the other hand,=20 >>>> receiving N copies of the same packet has some implications to=20 >>>> TCP....this is also rather obvious for people that know TCP...but = maybe not everyone does. >>>> >>>>> Regards >>>>> Yuri >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >>>>> Sent: Friday, October 23, 2009 11:08 AM >>>>> To: Yuri Ismailov >>>>> Cc: Laganier, Julien; mext@ietf.org >>>>> Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03 >>>>> >>>>> Hi Yuri, >>>>> >>>>> Comments inline... >>>>> >>>>> On Tue, Oct 20, 2009 at 8:55 AM, Yuri Ismailov=20 >>>>> >>>>> wrote: >>>>>> Hi, >>>>>> after re-reading the draft come up with the comment on "Discard" >>>>>> action in "Flow Identification Mobility Option" >>>>>> I suggest either to extend the paragraph in the section 4.2 or=20 >>>>>> add a separate subsection clarifying behavior of MN and HA before = >>>>>> and after the "Discard" action was issued by MN. >>>>>> >>>>>> Below are the issues which=A0are proposed to=A0be addressed in = the text. >>>>>> >>>>>> 1.The case when installed FID represent ranges of port numbers=20 >>>>>> and IP addresses. If MN decides to discard a particular flow=20 >>>>>> within the range then before that a correspondent FID should be = installed in the HA. >>>>>> Otherwise >>>>>> "136 FID=A0not found" will be returned from HA. >>>>>> >>>>> >>>>> GT> If the MN wants to discard a particular flow within a range of >>>>> previously registered flows, it needs to either split the range it = >>>>> two parts, or even better, use a higher FID-PRI for the =A0discard = >>>>> flow so that packets get matched against it before they get=20 >>>>> matched against the range. >>>>> >>>>>> 2. Specify the time interval for how long time the "Discard"=20 >>>>>> state will be active in HA.=A0This is necessary because there is = no=20 >>>>>> "un-discard" message sent from MN. >>>>>> >>>>> >>>>> GT> Flow bindings share the same lifetime with the BU. There is no >>>>> flow binding-specific lifetime. If an MN wants to remove a flow=20 >>>>> binding it sends a BU which does not include the corresponding = FID. >>>>> >>>>>> 3. Add a disclaimer that for some protocols, like TCP, "Discard" >>>>>> action may lead to hanging up the connection at CN and should be=20 >>>>>> used responsibly. >>>>>> >>>>> >>>>> GT> Discarding packets will drop connections....yes...I do not=20 >>>>> GT> think >>>>> there is anything to say here. >>>>> >>>>>> >>>>>> Regards >>>>>> Yuri >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >> >> > > > From Basavaraj.Patil@nokia.com Mon Oct 26 11:39:28 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0917128C13C for ; Mon, 26 Oct 2009 11:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 wn8Z3J9Yq8pM for ; Mon, 26 Oct 2009 11:39:27 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C57E728C19A for ; Mon, 26 Oct 2009 11:39:26 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9QIdafe003787 for ; Mon, 26 Oct 2009 20:39:37 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 20:39:36 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 20:39:35 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 20:39:31 +0200 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 26 Oct 2009 19:39:30 +0100 From: To: Date: Mon, 26 Oct 2009 19:39:31 +0100 Thread-Topic: New Version of I-D draft-patil-mext-mip6issueswithipsec-02 Thread-Index: AcpWazvOhRX/z5dyTuScs2s02oc43wA6zoAw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Oct 2009 18:39:31.0834 (UTC) FILETIME=[A84935A0:01CA566B] X-Nokia-AV: Clean Subject: [MEXT] FW: New Version of I-D draft-patil-mext-mip6issueswithipsec-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: , X-List-Received-Date: Mon, 26 Oct 2009 18:39:28 -0000 =20 -----Original Message----- From: ext IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Monday, October 26, 2009 1:36 PM To: Patil Basavaraj (Nokia-D/Dallas) Cc: domagoj.premec.ext@gmail.com; charliep@wichorus.com; Hannes.Tschofenig@= gmx.net Subject: New Version Notification for draft-patil-mext-mip6issueswithipsec-= 02=20 A new version of I-D, draft-patil-mext-mip6issueswithipsec-02.txt has been = posted to the IETF repository. Filename: draft-patil-mext-mip6issueswithipsec Revision: 02 Title: Problems with the use of IPsec as the security protocol for Mobile= IPv6 Creation_date: 2009-10-26 WG ID: Independent Submission Number_of_pages: 15 Abstract: Mobile IPv6 as specified in RFC3775 relies on IPsec for securing the signal= ing messages and user plane traffic between the mobile node and home agent.= An IPsec SA between the mobile node and the home agent provides security = for the mobility signaling. Use of IPsec for securing the data traffic bet= ween the mobile node and home agent is optional. This document analyses th= e implications of the design decision to mandate IPsec as the default secur= ity protocol for Mobile IPv6 and consequently Dual-stack Mobile IPv6 and recommends revisiting this= decision in view of the experience gained from implementation and adoption= in other standards bodies. = =20 The IETF Secretariat. From root@core3.amsl.com Mon Oct 26 12:15:02 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 793A93A697C; Mon, 26 Oct 2009 12:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026191502.793A93A697C@core3.amsl.com> Date: Mon, 26 Oct 2009 12:15:02 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-pd-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 19:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : DHCPv6 Prefix Delegation for NEMO Author(s) : R. Droms, et al. Filename : draft-ietf-mext-nemo-pd-03.txt Pages : 13 Date : 2009-10-26 One aspect of network mobility support is the assignment of a prefix or prefixes to a Mobile Router (MR) for use on the links in the Mobile Network. DHCPv6 prefix delegation can be used for this configuration task. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-nemo-pd-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26120902.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 26 17:00:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 629D63A6861; Mon, 26 Oct 2009 17:00:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091027000001.629D63A6861@core3.amsl.com> Date: Mon, 26 Oct 2009 17:00:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-14.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 00:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-ietf-mext-binding-revocation-14.txt Pages : 40 Date : 2009-10-26 This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its peer to terminate either one, multiple or all specified binding(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-binding-revocation-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26164621.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 26 17:00:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C8A1328C1AE; Mon, 26 Oct 2009 17:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091027000001.C8A1328C1AE@core3.amsl.com> Date: Mon, 26 Oct 2009 17:00:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-firewall-admin-02.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 00:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Guidelines for firewall administrators regarding MIPv6 traffic Author(s) : S. Krishnan, et al. Filename : draft-ietf-mext-firewall-admin-02.txt Pages : 12 Date : 2009-10-26 This document presents some recommendations for firewall administrators to help them configure their existing firewalls in a way that allows in certain deployment scenarios the Mobile IPv6 and DSMIPv6 signaling and data messages to pass through. For other scenarios, the support of additional mechanisms to create pinholes required for MIPv6 will be necessary. This document assumes that the firewalls in question include some kind of stateful packet filtering capability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-firewall-admin-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-firewall-admin-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26165752.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 26 17:00:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D2AE528C403; Mon, 26 Oct 2009 17:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091027000001.D2AE528C403@core3.amsl.com> Date: Mon, 26 Oct 2009 17:00:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-firewall-vendor-02.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 00:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Guidelines for firewall vendors regarding MIPv6 traffic Author(s) : S. Krishnan, et al. Filename : draft-ietf-mext-firewall-vendor-02.txt Pages : 8 Date : 2009-10-26 This document presents some recommendations for firewall vendors to help them implement their firewalls in a way that allows Mobile IPv6 and DSMIPv6 signaling and data messages to pass through. This document describes how to implement stateful packet filtering capability for MIPv6 and DSMIPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-firewall-vendor-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-firewall-vendor-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26165817.I-D@ietf.org> --NextPart-- From AMUHANNA@nortel.com Mon Oct 26 17:03:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 807773A6861 for ; Mon, 26 Oct 2009 17:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 WdPxkpc0m6Ew for ; Mon, 26 Oct 2009 17:03:24 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E760E3A69DC for ; Mon, 26 Oct 2009 17:03:23 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n9R035409829; Tue, 27 Oct 2009 00:03:06 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA5698.DB98B476" Date: Mon, 26 Oct 2009 19:03:04 -0500 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-mext-binding-revocation-14.txt Thread-Index: AcpWmIdP4m7zn8Q9SLCFCeS6+2nUggAAA7Eg From: "Ahmad Muhanna" To: Cc: mext-chairs@tools.ietf.org, Jari Arkko Subject: [MEXT] FW: I-D Action:draft-ietf-mext-binding-revocation-14.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 00:03:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5698.DB98B476 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hello Folks, We submitted a new revision of the Binding Revocation draft rev (14) This revision clarifies the use of Alternate Care-of Address option in the Binding Revocation Indication message. 1. In the case of Client MIP6, the HA always sends the BRI message to the MN CoA. 2. In case of the PMIPv6, clarified the existing text.=20 We also made a small correction that was made during the IESG review and we missed in rev 13. Thank you all for your feedback and reviews. Regards, Ahmad -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, October 26, 2009 7:00 PM To: i-d-announce@ietf.org Cc: mext@ietf.org Subject: I-D Action:draft-ietf-mext-binding-revocation-14.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-ietf-mext-binding-revocation-14.txt Pages : 40 Date : 2009-10-26 This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its peer to terminate either one, multiple or all specified binding(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-1 4.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01CA5698.DB98B476 Content-Type: application/octet-stream; name="draft-ietf-mext-binding-revocation-14.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-mext-binding-revocation-14.URL Content-Disposition: attachment; filename="draft-ietf-mext-binding-revocation-14.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLW1leHQtYmluZGluZy1yZXZvY2F0aW9uLTE0LnR4dA0K ------_=_NextPart_001_01CA5698.DB98B476 Content-Type: text/plain; name="ATT2714670.txt" Content-Transfer-Encoding: base64 Content-Description: ATT2714670.txt Content-Disposition: attachment; filename="ATT2714670.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01CA5698.DB98B476-- From karagian@cs.utwente.nl Wed Oct 28 00:56:16 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBEF83A67DA for ; Wed, 28 Oct 2009 00:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9eQJ2wEV7qN for ; Wed, 28 Oct 2009 00:56:16 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id D1ACE3A67C1 for ; Wed, 28 Oct 2009 00:56:15 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id n9S7uRfr011219; Wed, 28 Oct 2009 08:56:28 +0100 (MET) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Wed, 28 Oct 2009 07:56:27 +0000 To: mext@ietf.org Date: Wed, 28 Oct 2009 07:56:27 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <1YQg52vl.1256716587.3922310.karagian@ewi.utwente.nl> In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 28 Oct 2009 08:56:29 +0100 (MET) Cc: "ryuji@jp.toyota-itc.com" , "john@jbkenney.com" Subject: [MEXT] updated draft on requirements imposed by traffic safety applications on network/transport layers X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 07:56:16 -0000 Hi all An updated version of an Internet draft has been submitted to the IETF that describes a number of communication performance requirements that are imposed by traffic safety applications on a network layer, see: http://www.ietf.org/id/draft-karagiannis-traffic-safety-requirements-01.txt These traffic safety applications and requirements have been derived by the USA VSC (Vehicular Safety Communications)and VSC-A (VSC-Applications) projects and by the European Car to Car Communication Consortium (C2C-CC) and the ETSI TC ITS standardization body. The goal of this document is to stimulate the discussion on judging whether these performance requirements could or could not be supported (currently and in the future) by IP based network solutions. The goal of this document is to stimulate the discussion on judging whether these performance requirements could or could not be supported (currently and in the future) by IP based network and transport solutions. Best regards, Georgios From wwwrun@core3.amsl.com Wed Oct 28 08:02:45 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 3A1E828C16B; Wed, 28 Oct 2009 08:02:45 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20091028150245.3A1E828C16B@core3.amsl.com> Date: Wed, 28 Oct 2009 08:02:45 -0700 (PDT) Cc: mext mailing list , Internet Architecture Board , mext chair , RFC Editor Subject: [MEXT] Protocol Action: 'Binding Revocation for IPv6 Mobility' to Proposed Standard X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 15:02:45 -0000 The IESG has approved the following document: - 'Binding Revocation for IPv6 Mobility ' as a Proposed Standard This document is the product of the Mobility EXTensions for IPv6 Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-14.txt Technical Summary This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. Working Group Summary This is a product of the MEXT WG. The document's progress was coordinated with the NETLMM WG. Document Quality The mechanism specified by this document is relied upon by the Evolved Packet System developed by 3GPP and as thus will be implemented by 3GPP vendors. Personnel Document Shepherd is Julien Laganier. The Sponsoring AD is Jari Arkko. RFC Editor Note Add an "Updates: RFC 3775" header to the top Change in the Abstract: OLD: These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. NEW: This mechanism can be used both with base Mobile IPv6 and its extensions, such as Proxy Mobile IPv6. The mechanism allows the mobility entity which initiates the revocation procedure to request its peer to terminate either one, multiple or all specified binding cache entries.