From JuanCarlos.Zuniga@InterDigital.com Thu Oct 4 20:27:21 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CE511E8099 for ; Thu, 4 Oct 2012 20:27:21 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NB3V7HaO6+AD for ; Thu, 4 Oct 2012 20:27:20 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA561F041F for ; Thu, 4 Oct 2012 20:27:20 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Oct 2012 23:27:19 -0400 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, 4 Oct 2012 23:27:18 -0400 Message-ID: In-Reply-To: <98C5D681-7EE7-459C-A967-AA56615F3395@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] questions on draft-ietf-mif-api-extension Thread-Index: Ac2bM5TwhUnJUqgWSJuSLlTzTedzbwAPRX+AABF870AAGojRgAAN6BQg//+r3wD/8wqLEA== References: <13124_1348587411_5061CF93_13124_3978_1_81C77F07008CA24F9783A98CFD706F71039CD9@PEXCVZYM12.corporate.adroot.infra.ftgroup><23309_1348648042_5062BC6A_23309_4116_9_81C77F07008CA24F9783A98CFD706F71039F8F@PEXCVZYM12.corporate.adroot.infra.ftgroup><604144AF-FA1F-4D42-9428-34A31E88C7B0@nominum.com><7356_1348666600_506304E8_7356_6703_1_81C77F07008CA24F9783A98CFD706F7103A1D0@PEXCVZYM12.corporate.adroot.infra.ftgroup> <98C5D681-7EE7-459C-A967-AA56615F3395@nominum.com> From: "Zuniga, Juan Carlos" To: "Ted Lemon" , X-OriginalArrivalTime: 05 Oct 2012 03:27:19.0445 (UTC) FILETIME=[534EAC50:01CDA2A9] Cc: mif@ietf.org Subject: Re: [mif] questions on draft-ietf-mif-api-extension X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 03:27:21 -0000 Ted, At the moment Pierrick and I were not planning to make a new version of the current Connection Manager MIF API considerations document we recently submitted (draft-seite-mif-cm), unless of course we got specific comments before the deadline. However, by looking at your previous response I think we are converging to the same line of thought. We can take a look again at the document according to the suggestion from your previous posting:=20 " What I would encourage you to do if you want to go down this path is think about the current [MIF API] document in terms of what it might _prevent_ you from doing in the supplementary [extended MIF API] document, and ask us to fix those bits." Likewise, if you have time to read draft-seite-mif-cm and can send us some comments to clean it up wrt the current MIF API document before the next IETF it would be appreciated. Regards, Juan Carlos > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > Ted Lemon > Sent: Wednesday, September 26, 2012 10:32 AM > To: > Cc: mif@ietf.org > Subject: Re: [mif] questions on draft-ietf-mif-api-extension >=20 > On Sep 26, 2012, at 9:36 AM, > wrote: > > Actually, Juan-Carlos and myself have submitted a discussion draft to > address this point. Now, I understand better the purpose of the MIF API > and we need to revise according to your feedback. Hopefully, we'll be > ready to discuss it at the next IETF. >=20 > Yup, I was happy to see that, but haven't had time to read it yet. If > you get a new version out before the next IETF, I'll be ready to > discuss it with you there. :) >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From tireddy@cisco.com Thu Oct 18 05:32:23 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B63321F871D for ; Thu, 18 Oct 2012 05:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.459 X-Spam-Level: X-Spam-Status: No, score=-10.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVZH2zzmMBd3 for ; Thu, 18 Oct 2012 05:32:22 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7F78321F871E for ; Thu, 18 Oct 2012 05:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2702; q=dns/txt; s=iport; t=1350563542; x=1351773142; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=hN7F8RJxj7DbFyvt6ErZoJnD0Xx+3zmGPA2O/XQFGmU=; b=As77jzUbClsX5+lFMycyZTNA1ayWQvK99tnFLmCukvZVmC1KKIMWVUih 5uMVBhHFIHgiT48JfYS03PXxxuxAwK3mOz+74xVAfKI12Ik5ZEYHCkAd+ AYoQ2xaalj/uJZXWQ34BPs/w4UwECXz2nb2Oz4atPgVOtUDPSWYJnadzG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGj1f1CtJXG9/2dsb2JhbABFhhK5NnWBCIIgAQEBBBIBEBFDAgwGAQgRBAEBAwIGHQMCBDAUAQYBAQUFBA4FCAEZh2ILnDCNIZMKgSGKN4UwMmADlwCNNIFrgm+BWiMa X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="133017343" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 18 Oct 2012 12:32:22 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9ICWMmT012144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Oct 2012 12:32:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 07:32:20 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mif@ietf.org" Thread-Topic: New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt Thread-Index: AQHNqwBu7RP4kWipA0qEvbLMwC6QFpe++/4Q Date: Thu, 18 Oct 2012 12:32:20 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1480EDFA@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.28.246] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--26.942700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [mif] FW: New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 12:32:23 -0000 VGhpcyBkcmFmdCBwcm9wb3NlcyBuZXcgREhDUHY2IG9wdGlvbnMgdG8gYmUgYWRkZWQgYnkgdGhl IERIQ1B2NiByZWxheSBhZ2VudCB3aGVuIGl0IGdlbmVyYXRlcyBhIFJlbGF5LUZvcndhcmRlZCBt ZXNzYWdlIHRvIGluZmx1ZW5jZSB0aGUgREhDUHY2IHNlcnZlcidzIHJlc3BvbnNlIHRoYXQgbW9k aWZ5IHRoZSBob3N0J3MgYWRkcmVzcyBwb2xpY3kgdGFibGUgW0ktRC5pZXRmLTZtYW4tYWRkci1z ZWxlY3Qtb3B0XSBiYXNlZCBvbiBvYnNlcnZlZCBuZXR3b3JrIGNoYXJhY3RlcmlzdGljcy4gVGhl c2Ugb3B0aW9ucyBjYW4gYWxzbyBiZSB1c2VkIHRvIGNvbmRpdGlvbmFsbHkgZGlzYWJsZSBJUHY2 IHRlbXBvcmFyeSBhZGRyZXNzZXMgaW4gYSBtYW5hZ2VkIG5ldHdvcmsgZm9yIHNlbGVjdGl2ZSBo b3N0cyB3aXRob3V0IGF1dGhlbnRpY2F0aW9uIHN1cHBsaWNhbnQuDQoNCkNvbW1lbnRzIGFuZCBz dWdnZXN0aW9ucyBhcmUgd2VsY29tZS4NCg0KLS1UaXJ1Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgT2N0b2JlciAxNSwgMjAxMiAxMTo0MSBQ TQ0KVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCkNjOiBQcmFzaGFudGggUGF0aWwg KHByYXNwYXRpKTsgRGFuIFdpbmcgKGR3aW5nKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1yZWRkeS1taWYtZGhjcHY2LXByZWNlZGVuY2Utb3BzLTAyLnR4dA0K DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1yZWRkeS1taWYtZGhjcHY2LXByZWNlZGVu Y2Utb3BzLTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaXJ1bWFs ZXN3YXIgUmVkZHkgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5h bWU6CSBkcmFmdC1yZWRkeS1taWYtZGhjcHY2LXByZWNlZGVuY2Utb3BzDQpSZXZpc2lvbjoJIDAy DQpUaXRsZToJCSBSZWxheS1TdXBwbGllZCBESENQdjYgUHJlY2VkZW5jZSBPcHRpb25zDQpDcmVh dGlvbiBkYXRlOgkgMjAxMi0xMC0xNQ0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpO dW1iZXIgb2YgcGFnZXM6IDExDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJlZGR5LW1pZi1kaGNwdjYtcHJlY2VkZW5jZS1vcHMtMDIu dHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtcmVkZHktbWlmLWRoY3B2Ni1wcmVjZWRlbmNlLW9wcw0KSHRtbGl6ZWQ6ICAgICAgICBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS1taWYtZGhjcHY2LXByZWNlZGVuY2Ut b3BzLTAyDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LXJlZGR5LW1pZi1kaGNwdjYtcHJlY2VkZW5jZS1vcHMtMDINCg0KQWJzdHJhY3Q6DQog ICBOZXR3b3JrIGNvbmZpZ3VyYXRpb24gb2YgaG9zdHMgaXMgY3VycmVudGx5IHJlbGF0aXZlbHkg c3RhdGljIHdpdGgNCiAgIGxpdHRsZSBjb25zaWRlcmF0aW9uIG9mIGR5bmFtaWMgbmV0d29yayBj aGFyYWN0ZXJpc3RpY3MuICBUaGUgbmV0d29yaw0KICAgaW5mcmFzdHJ1Y3R1cmUgaXMgYXdhcmUg b2YgZHluYW1pYyBuZXR3b3JrIGNoYXJhY3RlcmlzdGljcy4gIFRoaXMNCiAgIHNwZWNpZmljYXRp b24gZXh0ZW5kcyBESENQdjYgc28gdGhhdCB0aGUgREhDUHY2IHJlbGF5IGFnZW50IGNhbg0KICAg aW5mbHVlbmNlIGEgaG9zdCdzIGNvbmZpZ3VyYXRpb24uDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From Ted.Lemon@nominum.com Thu Oct 18 05:41:27 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8131721F87A9 for ; Thu, 18 Oct 2012 05:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.482 X-Spam-Level: X-Spam-Status: No, score=-106.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQLnBErkj+b7 for ; Thu, 18 Oct 2012 05:41:27 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id E01E221F87D6 for ; Thu, 18 Oct 2012 05:41:26 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUH/49hkRjihGv6uIHHJ0uy3UCIwXZmMN@postini.com; Thu, 18 Oct 2012 05:41:26 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0D65C1B8350 for ; Thu, 18 Oct 2012 05:41:26 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 03D8819005C; Thu, 18 Oct 2012 05:41:26 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 18 Oct 2012 05:41:26 -0700 From: Ted Lemon To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [mif] New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt Thread-Index: AQHNrS3iW6gFvmNkqUiZ8bkm+bpnwg== Date: Thu, 18 Oct 2012 12:41:24 +0000 Message-ID: <7E99AA25-66C2-4A4D-B251-0E71F31FBA26@nominum.com> References: <913383AAA69FF945B8F946018B75898A1480EDFA@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A1480EDFA@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <39B10DC141A65846955216DB70DF4A35@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 12:41:27 -0000 On Oct 18, 2012, at 8:32 AM, Tirumaleswar Reddy (tireddy) wrote: > These options can also be used to conditionally disable IPv6 temporary ad= dresses in a managed network for selective hosts without authentication sup= plicant. How would that work? Have you raised this in 6man? From alexandru.petrescu@gmail.com Thu Oct 18 08:27:18 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6634921F8832 for ; Thu, 18 Oct 2012 08:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.996 X-Spam-Level: X-Spam-Status: No, score=-9.996 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJh2Q8+wVK1L for ; Thu, 18 Oct 2012 08:27:17 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 82E5021F8817 for ; Thu, 18 Oct 2012 08:27:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q9IFRFv0016948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 18 Oct 2012 17:27:15 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q9IFRFPJ009138 for ; Thu, 18 Oct 2012 17:27:15 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q9IFRECr029762 for ; Thu, 18 Oct 2012 17:27:15 +0200 Message-ID: <50801FD2.6020402@gmail.com> Date: Thu, 18 Oct 2012 17:27:14 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] Announcing draft-kaiser-nd-pd-00.txt "Prefix Delegation extension to Neighbor Discovery protocol" X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 15:27:18 -0000 Dear participants to MIF WG, We just submitted "Prefix Delegation extension to Neighbor Discovery protocol" draft-kaiser-nd-pd-00 available at: http://tools.ietf.org/html/draft-kaiser-nd-pd-00 During the fruitful discussions about DHCP and routes mention was made about potential extensions of ND to realize Prefix Delegation. The discussion was that since we needed small unique-protocol software for autoconfiguring machine-class devices behind a Mobile Router we faced two potential development ways: either extend DHCP to do default route, or extend ND to do prefix delegation. The ND-PD concept existed in drafts as early as 2000 and some aspects were protected since. We kindly request comments about this. Thanks in advance, Alex From tireddy@cisco.com Fri Oct 19 20:03:33 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BE421F8885 for ; Fri, 19 Oct 2012 20:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2PAe98nk9YZ for ; Fri, 19 Oct 2012 20:03:32 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C12DF21F8871 for ; Fri, 19 Oct 2012 20:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7051; q=dns/txt; s=iport; t=1350702213; x=1351911813; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cVNRGTdS/tPAfa9d6g1x7z8SBz4gV191QQ8OrMfbnY0=; b=HOOUR3LO4nfeb6/thxtLTGczhf0Jwllyzgsq/podTcftF0dZ+MoErX+B h8tKuunmJVmXrGpDdCsvjhKC54kFQ4dtklbWJ6SdNOhSUnkPvJ3f/hXjb +/Q4Mmj9gkep/AJw0Qf3kcqVnj4eyniY0DyuQy1xeFbWt4YuP3HDNVrKt g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAcUglCtJV2d/2dsb2JhbABFgkq+Q4EIgiABAQEDARIBGkoCBQcEAgEIEQQBAQsdBzIUCQgCBA4FCAEZh1wGC5wRn3uLWhqFdWADpDyBa4JvgVoJFwQa X-IronPort-AV: E=Sophos;i="4.80,618,1344211200"; d="scan'208,217";a="133664206" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 20 Oct 2012 03:03:32 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9K33Wnr005534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Oct 2012 03:03:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Fri, 19 Oct 2012 22:03:31 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Ted Lemon Thread-Topic: [mif] New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt Thread-Index: AQHNqwBu7RP4kWipA0qEvbLMwC6QFpe++/4QgABdlgD//67RUA== Date: Sat, 20 Oct 2012 03:03:31 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A148124F2@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A1480EDFA@xmb-rcd-x10.cisco.com> <7E99AA25-66C2-4A4D-B251-0E71F31FBA26@nominum.com> In-Reply-To: <7E99AA25-66C2-4A4D-B251-0E71F31FBA26@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.82.198] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--44.302900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A148124F2xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 03:03:33 -0000 --_000_913383AAA69FF945B8F946018B75898A148124F2xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Thursday, October 18, 2012 6:11 PM > To: Tirumaleswar Reddy (tireddy) > Cc: mif@ietf.org > Subject: Re: [mif] New Version Notification for draft-reddy-mif-dhcpv6- > precedence-ops-02.txt > > On Oct 18, 2012, at 8:32 AM, Tirumaleswar Reddy (tireddy) > > wrote: > > These options can also be used to conditionally disable IPv6 temporary > addresses in a managed network for selective hosts without authentication > supplicant. > > How would that work? Hi Ted, For e.g. In Enterprise premises hosts with EAP kind of supplicants can be t= racked even when the IP address changes but for guests, BYOD (Bring your Ow= n Device) without such supplicants IP address based authentication is still= required for such users. When Address-based authentication is used, re- authentication occurs for each new address obtained by the host, which can = create a lot of authentication transactions. Switches acting as DHCP relay = agent can influence the DHCP server not to assign temporary addresses. It's= explained in detail in section 3.2.1 "Avoiding Excessive IP-Based Authenti= cation" of this draft. > Have you raised this in 6man ? The above point was discussed in 6man specific to privacy addresses http://= www.ietf.org/mail-archive/web/ipv6/current/msg15710.html --Tiru. --_000_913383AAA69FF945B8F946018B75898A148124F2xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> -----Original Message-----

> From: Ted Lemon [mailto:Ted.Lemon@nominum.co= m]

> Sent: Thursday, October 18, 2012 6:11 PM

> To: Tirumaleswar Reddy (tireddy)<= /p>

> Cc: mif@ietf.org

> Subject: Re: [mif] New Version Notification = for draft-reddy-mif-dhcpv6-

> precedence-ops-02.txt

>

> On Oct 18, 2012, at 8:32 AM, Tirumaleswar Re= ddy (tireddy) <tireddy@cisco.com>

> wrote:

> > These options can also be used to condi= tionally disable IPv6 temporary

> addresses in a managed network for selective= hosts without authentication

> supplicant.

>

> How would that work?   =

 

Hi Ted,

 

For e.g. In Enterprise premises hosts with EAP ki= nd of supplicants can be tracked even when the IP address changes but for g= uests, BYOD (Bring your Own Device) without such supplicants IP address bas= ed authentication is still required for such users. When Address-based authentication is used, re-<= /p>

authentication occurs for each new address obtain= ed by the host, which can create a lot of authentication transactions. Swit= ches acting as DHCP relay agent can influence the DHCP server not to assign= temporary addresses. It's explained in detail in section 3.2.1 "Avoiding Excessive IP-Based Authenticatio= n" of this draft.

 

> Have you raised this in 6man ?

 

The above point was discussed in 6man specific to= privacy addresses http://www.ietf.org/mail-archive/web/ipv6/current/msg15710.html

 

--Tiru.

--_000_913383AAA69FF945B8F946018B75898A148124F2xmbrcdx10ciscoc_-- From Ted.Lemon@nominum.com Fri Oct 19 21:11:40 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD4521F882E for ; Fri, 19 Oct 2012 21:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoBMONyOZsTE for ; Fri, 19 Oct 2012 21:11:39 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE8C21F8880 for ; Fri, 19 Oct 2012 21:11:39 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUIIke+Nh5rtZzBdX6JjWe5RMfP2ozwxO@postini.com; Fri, 19 Oct 2012 21:11:39 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E3C2E1B8233 for ; Fri, 19 Oct 2012 21:11:38 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id DC5EB19005C; Fri, 19 Oct 2012 21:11:38 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 19 Oct 2012 21:11:39 -0700 From: Ted Lemon To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [mif] New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt Thread-Index: AQHNrS3iW6gFvmNkqUiZ8bkm+bpnwpfB+fWAgAATB4A= Date: Sat, 20 Oct 2012 04:11:37 +0000 Message-ID: <09806E4D-E6BA-431A-9BB4-F59AD64885A7@nominum.com> References: <913383AAA69FF945B8F946018B75898A1480EDFA@xmb-rcd-x10.cisco.com> <7E99AA25-66C2-4A4D-B251-0E71F31FBA26@nominum.com> <913383AAA69FF945B8F946018B75898A148124F2@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A148124F2@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <20D777A06107964986BC7F4C109B8687@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 04:11:41 -0000 On Oct 19, 2012, at 11:03 PM, Tirumaleswar Reddy (tireddy) wrote: > Switches acting as DHCP relay agent can influence the DHCP server not to = assign temporary addresses.=20 Okay, so this is preventing DHCP assignment of IA_TA, not assignment of tem= porary addresses in general.=20 From tireddy@cisco.com Sat Oct 20 19:55:04 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8316421F891E for ; Sat, 20 Oct 2012 19:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNrnA87Hk65m for ; Sat, 20 Oct 2012 19:55:04 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 03DD721F891D for ; Sat, 20 Oct 2012 19:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1065; q=dns/txt; s=iport; t=1350788104; x=1351997704; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=M2G6lEBPfPUppA7zMPFaAh/vbjNgfWo37PttnaYKOYo=; b=GK7BaiSzlkddHaJe2RAfLPzRKcdAvO+vVW8LjmJfEMAotqcJzpfpuT2S 0fzbidXZy/FjLH/DiCAH9aNdvn0aruuaGb3+O476HnUTv8dOe1y/PnIuh wkr0fXBxKmf86AW72i7OcwuPkSq+lzCqU2tVJyhHj7EqP7db1ToD3gLHQ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALNig1CtJXG//2dsb2JhbABEwQ+BCIIgAQEBBBIBJz0CDAQCAQgRBAEBAQoUCQcyFAkIAgQOBQgah2KbUJ8Wi1+GD2ADpD+Ba4JvgVogBBo X-IronPort-AV: E=Sophos;i="4.80,622,1344211200"; d="scan'208";a="130772206" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 21 Oct 2012 02:55:03 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9L2t3OU016467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 21 Oct 2012 02:55:03 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Sat, 20 Oct 2012 21:55:03 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Ted Lemon Thread-Topic: [mif] New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt Thread-Index: AQHNqwBu7RP4kWipA0qEvbLMwC6QFpe++/4QgABdlgD//67RUIAC52qAgAEm/SA= Date: Sun, 21 Oct 2012 02:55:03 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14812900@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A1480EDFA@xmb-rcd-x10.cisco.com> <7E99AA25-66C2-4A4D-B251-0E71F31FBA26@nominum.com> <913383AAA69FF945B8F946018B75898A148124F2@xmb-rcd-x10.cisco.com> <09806E4D-E6BA-431A-9BB4-F59AD64885A7@nominum.com> In-Reply-To: <09806E4D-E6BA-431A-9BB4-F59AD64885A7@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.79.230] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19290.004 x-tm-as-result: No--40.651100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 02:55:04 -0000 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Saturday, October 20, 2012 9:42 AM > To: Tirumaleswar Reddy (tireddy) > Cc: mif@ietf.org > Subject: Re: [mif] New Version Notification for draft-reddy-mif-dhcpv6- > precedence-ops-02.txt >=20 > On Oct 19, 2012, at 11:03 PM, Tirumaleswar Reddy (tireddy) > wrote: > > Switches acting as DHCP relay agent can influence the DHCP server not t= o > assign temporary addresses. >=20 > Okay, so this is preventing DHCP assignment of IA_TA, not assignment of > temporary addresses in general. Hi Ted, Yes. In such Managed Networks, SLAAC is disabled and IPv6 addresses are onl= y assigned using DHCPv6 server. Switches in such environments provide First= Hop Security by gleaning DHCP/NDP messages and can make sure hosts are usi= ng the IPv6 addresses assigned by the DHCPv6 server only (Source Guard). Wi= th the technique in this draft only certain hosts will be permitted assignm= ent of IA_TA and not for other hosts.=20 --Tiru. From Ted.Lemon@nominum.com Sat Oct 20 20:01:10 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4579521F891D for ; Sat, 20 Oct 2012 20:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOrTym1t1z5s for ; Sat, 20 Oct 2012 20:01:09 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id A345D21F891B for ; Sat, 20 Oct 2012 20:01:09 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUINldTQEuMz350Y2CGPLYC4EGJVFTZqI@postini.com; Sat, 20 Oct 2012 20:01:09 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DB2D51B829A for ; Sat, 20 Oct 2012 20:01:08 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D216D19005C; Sat, 20 Oct 2012 20:01:08 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Sat, 20 Oct 2012 20:01:08 -0700 From: Ted Lemon To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [mif] New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt Thread-Index: AQHNrS3iW6gFvmNkqUiZ8bkm+bpnwpfB+fWAgAATB4CAAXzwgIAAAbKA Date: Sun, 21 Oct 2012 03:01:08 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A1480EDFA@xmb-rcd-x10.cisco.com> <7E99AA25-66C2-4A4D-B251-0E71F31FBA26@nominum.com> <913383AAA69FF945B8F946018B75898A148124F2@xmb-rcd-x10.cisco.com> <09806E4D-E6BA-431A-9BB4-F59AD64885A7@nominum.com> <913383AAA69FF945B8F946018B75898A14812900@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A14812900@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 03:01:10 -0000 On Oct 20, 2012, at 10:55 PM, "Tirumaleswar Reddy (tireddy)" wrote: > Yes. In such Managed Networks, SLAAC is disabled and IPv6 addresses are o= nly assigned using DHCPv6 server. Switches in such environments provide Fir= st Hop Security by gleaning DHCP/NDP messages and can make sure hosts are u= sing the IPv6 addresses assigned by the DHCPv6 server only (Source Guard). = With the technique in this draft only certain hosts will be permitted assig= nment of IA_TA and not for other hosts.=20 That makes sense=97thanks for clarifying! From internet-drafts@ietf.org Sun Oct 21 19:33:57 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D4621F8878; Sun, 21 Oct 2012 19:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zT5Rs-xmpsVX; Sun, 21 Oct 2012 19:33:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0D421F842B; Sun, 21 Oct 2012 19:33:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022023357.14897.80560.idtracker@ietfa.amsl.com> Date: Sun, 21 Oct 2012 19:33:57 -0700 Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-happy-eyeballs-extension-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 02:33:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiple Interfaces Working Group of the = IETF. Title : Happy Eyeballs Extension for Multiple Interfaces Author(s) : Gang Chen Carl Williams Dan Wing Andrew Yourtchenko Filename : draft-ietf-mif-happy-eyeballs-extension-01.txt Pages : 11 Date : 2012-10-21 Abstract: Currently the interface selection in multi-interface environment is exclusive - only one interface can be used at the time, frequently needing manual intervention. Happy Eyeballs in MIF would make the selection process smoother by using the connectivity checks over a pre-filtered interfaces according to defined policy. This would choose "best" interface with an automatic fallback. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mif-happy-eyeballs-extension There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mif-happy-eyeballs-extension-= 01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From phdgang@gmail.com Sun Oct 21 23:02:46 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A421521F8B3A for ; Sun, 21 Oct 2012 23:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.402 X-Spam-Level: X-Spam-Status: No, score=-3.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlZvRatKtMxo for ; Sun, 21 Oct 2012 23:02:46 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DAEB921F8B34 for ; Sun, 21 Oct 2012 23:02:45 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so2818873vbb.31 for ; Sun, 21 Oct 2012 23:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=mTO46N9GTTMjEn6gzGmfSyaQR45OoOsfqQWdkVhoEm0=; b=JHvvtf/sePav3/zOHWIMi5TMgvYAXog8K/nb4Xi1KyQuYnQXTDKb5714EcJFDjdDud +LJAU9qqfz/KkYi29fsVJ4EChJNSfYudUa+0xxqRHFSL82yw7gpXuc/grH+4oR6G+Oc0 OnbK2LQjPPJ3T0Lh3v9Yr4RMPjVGjAKvzwWmnGXBGJXrkeAWNjnMleDrrvhoYvkO9yGg BOcNjI0brfTAKQMcUD0yx5Fv9LgkaZuqW+1/JbdCpKIETVRQusduoGVp+dJbDwn6RJdc gjKawMXUm10r8E9/VSiiwUKZ3lfiD4Ol/oqIAUXccDsWXeRbGmcGGH9QY8yeXDojynTR 6PCg== MIME-Version: 1.0 Received: by 10.52.26.133 with SMTP id l5mr10387496vdg.132.1350885765096; Sun, 21 Oct 2012 23:02:45 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Sun, 21 Oct 2012 23:02:45 -0700 (PDT) In-Reply-To: <20121022023357.14897.80560.idtracker@ietfa.amsl.com> References: <20121022023357.14897.80560.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 14:02:45 +0800 Message-ID: From: GangChen To: mif@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [mif] I-D Action: draft-ietf-mif-happy-eyeballs-extension-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 06:02:46 -0000 Dear folks, We have updated the draft with the comments received so far. The changes mainly are 1) Added the further discussions on the setting of Fallback Timeout in Section 6.2. The draft described several available recommendations we found. For more optimal timers, authors believe those settings should leave to particular cases and implementation decisions. We provided discussions accordingly to clarify the concerns. 2) The precedence of user inputs has been highlighted 3) Two-stage approach has been claimed to be "not prescribed" in section 4 4) Several editorial improvements Your further comments are more than welcome Many thanks Gang 2012/10/22, internet-drafts@ietf.org : > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiple Interfaces Working Group of the > IETF. > > Title : Happy Eyeballs Extension for Multiple Interfaces > Author(s) : Gang Chen > Carl Williams > Dan Wing > Andrew Yourtchenko > Filename : draft-ietf-mif-happy-eyeballs-extension-01.txt > Pages : 11 > Date : 2012-10-21 > > Abstract: > Currently the interface selection in multi-interface environment is > exclusive - only one interface can be used at the time, frequently > needing manual intervention. Happy Eyeballs in MIF would make the > selection process smoother by using the connectivity checks over a > pre-filtered interfaces according to defined policy. This would > choose "best" interface with an automatic fallback. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mif-happy-eyeballs-extension > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mif-happy-eyeballs-extension-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From internet-drafts@ietf.org Mon Oct 22 10:21:16 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E90B11E80E8; Mon, 22 Oct 2012 10:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btM6Xg0s33P6; Mon, 22 Oct 2012 10:21:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1D621F861B; Mon, 22 Oct 2012 10:21:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022172113.19816.84272.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 10:21:13 -0700 Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-api-extension-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:21:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiple Interfaces Working Group of the = IETF. Title : MIF API consideration Author(s) : Dapeng Liu Ted Lemon Yuri Ismailov Zhen Cao Filename : draft-ietf-mif-api-extension-02.txt Pages : 17 Date : 2012-10-22 Abstract: Traditionally, hosts that communicate on the network have done so over a single network link, which is provided by a single service provider. This simple environment is relatively easy to program to, and relatively predictable. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mif-api-extension There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mif-api-extension-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mif-api-extension-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zehn.cao@gmail.com Tue Oct 23 00:38:35 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A77821F85B1 for ; Tue, 23 Oct 2012 00:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wZ5sRajYUrP for ; Tue, 23 Oct 2012 00:38:32 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B15B21F8511 for ; Tue, 23 Oct 2012 00:38:32 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so3240825iad.31 for ; Tue, 23 Oct 2012 00:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ai2w5KpIs0w5TiXSlFHeutHasIKrBCtnx3xFOViKiUY=; b=XkAf1qVyQ0YvH4YsMps3my/YxNO8adLBGb9V7L+ZTD/vDpEdtc1p+pk/rrAoSJV3A8 f5QK554ONqixOiKKLxo+unzhyy2hy3vEqXWLAj+IjVdAi8sWRpE7/3cwbHNQxDVO+PnM xZFGlIv/8SZswdxd1dyd6vVRg1Hvy7/nwc9fQ68x1it2X7JzNoR/y8mzi7i38cduETRW MtbDIhE7rtqTvLiGyRO/YwD4/Ll6IfdvKN9hCIt2E1+AH7KBtjtBP1Of8dcqggFibQzW c9OnorQ+a2xf4W3VBSBUJAQhQP+vabMByA4xBXIEuBOgUAlLkO0THI7g8xON6SsZJGwt rURw== MIME-Version: 1.0 Received: by 10.50.209.71 with SMTP id mk7mr18837785igc.34.1350977911164; Tue, 23 Oct 2012 00:38:31 -0700 (PDT) Received: by 10.64.64.102 with HTTP; Tue, 23 Oct 2012 00:38:31 -0700 (PDT) In-Reply-To: <20121015131910.25587.13444.idtracker@ietfa.amsl.com> References: <20121015131910.25587.13444.idtracker@ietfa.amsl.com> Date: Tue, 23 Oct 2012 15:38:31 +0800 Message-ID: From: Zhen Cao To: mif Content-Type: multipart/alternative; boundary=14dae93404f97e8d7a04ccb50ef0 Subject: [mif] Fwd: I-D Action: draft-cao-mif-srv-dis-ps-00.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 07:38:35 -0000 --14dae93404f97e8d7a04ccb50ef0 Content-Type: text/plain; charset=ISO-8859-1 Dear All, This is a new draft on service discovery in a multiple interface environment. Comments are welcome, thank you in advance. Best regards, cz ---------- Forwarded message ---------- From: Date: Mon, Oct 15, 2012 at 9:19 PM Subject: I-D Action: draft-cao-mif-srv-dis-ps-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Service Discovery in a Multiple Connection Environment: Problem Statement Author(s) : Zhen Cao Filename : draft-cao-mif-srv-dis-ps-00.txt Pages : 8 Date : 2012-10-15 Abstract: This document analyzes the problem of service discovery in a multiple connection environment. A multiple connection environment consists of multiple-interfaces nodes connecting to multiple networks or mutliple provisioning domains. Given a type of service a mutliple- interfaced client is looking for, the discovery progress ought to return a correct pointer to the service instance that the client is able to access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-cao-mif-srv-dis-ps There's also a htmlized version available at: http://tools.ietf.org/html/draft-cao-mif-srv-dis-ps-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --14dae93404f97e8d7a04ccb50ef0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear All,=A0

This is a new draft on service discovery in= a multiple interface environment.=A0

Comments are= welcome, thank you in advance.=A0

Best regards,
cz
---------- Forwarded message -= ---------
From: <= ;internet-drafts@ietf.org&g= t;
Date: Mon, Oct 15, 2012 at 9:19 PM
Subject: I-D Action: draft-cao-mif-sr= v-dis-ps-00.txt
To: i-d-announc= e@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Service Discovery in a Multiple= Connection Environment: Problem Statement
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Zhen Cao
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-cao-mif-srv-dis-ps-00.txt =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-10-15

Abstract:
=A0 =A0This document analyzes the problem of service discovery in a multipl= e
=A0 =A0connection environment. =A0A multiple connection environment consist= s
=A0 =A0of multiple-interfaces nodes connecting to multiple networks or
=A0 =A0mutliple provisioning domains. =A0Given a type of service a mutliple= -
=A0 =A0interfaced client is looking for, the discovery progress ought to =A0 =A0return a correct pointer to the service instance that the client is<= br> =A0 =A0able to access.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-cao-mif-srv-dis-ps<= br>
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-cao-mif-srv-dis-ps-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--14dae93404f97e8d7a04ccb50ef0-- From brian.e.carpenter@gmail.com Tue Oct 23 02:24:52 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BC021F85B4 for ; Tue, 23 Oct 2012 02:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yKXZgWBR-rx for ; Tue, 23 Oct 2012 02:24:52 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 172A021F853E for ; Tue, 23 Oct 2012 02:24:51 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so1251665bkc.31 for ; Tue, 23 Oct 2012 02:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bieIFXPWI+R56uZnzmJWV7UAI32/7YkFRkYe8CEGk8Y=; b=Uv5zzUptyR2/6MnAEFmKn++DOX1gxdcx/QVbzSMfrGPGPBjrlloBL+g+AMGcm9pb75 bK7voPUcg1lL3yrit0uotJIWltQN+xhZM7hIAV8+jOZTiT9OYZ2oxNtTox9TdwV8RYZA IfXkuNLte5b+LtUgp5aUmlrt9XMyHfa4LXg52EC2zn5QIBQmMRGM2YWB5/gYiRccplie 8HH4yZpjLKHJm1MMYtrQ+BN5zgGwAj03gj94aHyV217PghsWzh501c7D3wjczAKzRWhp 9loEImv2PBWsTgLqA6PuIeQsNVMCw5lxXd4qdhGJ03EXNKEvHNLCVUiOjhGduWQX0rFM 2qCQ== Received: by 10.204.11.133 with SMTP id t5mr3572424bkt.14.1350984291200; Tue, 23 Oct 2012 02:24:51 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-57.as13285.net. [2.102.219.57]) by mx.google.com with ESMTPS id g8sm5103153bkv.6.2012.10.23.02.24.49 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 02:24:50 -0700 (PDT) Message-ID: <50866262.3050500@gmail.com> Date: Tue, 23 Oct 2012 10:24:50 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" References: <913383AAA69FF945B8F946018B75898A1480EDFA@xmb-rcd-x10.cisco.com> <7E99AA25-66C2-4A4D-B251-0E71F31FBA26@nominum.com> <913383AAA69FF945B8F946018B75898A148124F2@xmb-rcd-x10.cisco.com> <09806E4D-E6BA-431A-9BB4-F59AD64885A7@nominum.com> <913383AAA69FF945B8F946018B75898A14812900@xmb-rcd-x10.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "mif@ietf.org" Subject: Re: [mif] New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 09:24:52 -0000 On 21/10/2012 04:01, Ted Lemon wrote: > On Oct 20, 2012, at 10:55 PM, "Tirumaleswar Reddy (tireddy)" wrote: >> Yes. In such Managed Networks, SLAAC is disabled and IPv6 addresses ar= e only assigned using DHCPv6 server. Switches in such environments provid= e First Hop Security by gleaning DHCP/NDP messages and can make sure host= s are using the IPv6 addresses assigned by the DHCPv6 server only (Source= Guard). With the technique in this draft only certain hosts will be perm= itted assignment of IA_TA and not for other hosts.=20 >=20 > That makes sense=E2=80=94thanks for clarifying! It makes sense, but the draft doesn't explain that it is only intended for use in managed networks where the suppression of privacy is considered acceptable. I think this needs to be stated in the Introduction, and the issue of (loss of) privacy needs to be discussed in the Security Considerations. How will users know that temporary addressing has been disabled? Is there a risk of a rogue DHCPv6 relay switching off temporary addressing for hosts that really need it? Also, in the section > 3.2.1. Avoiding Excessive IP-Based Authentication it says: > When Address-based authentication is used, re- > authentication occurs for each address obtained by the host, which > can create a lot of authentication transactions. To reduce this > chatter, This doesn't convince me that the proposed feature is solving a real problem. "A lot of" and "chatter" are vague terms. Can you add something to suggest what size of a network would have a real performance problem as a result? Regards Brian Carpenter From Ted.Lemon@nominum.com Tue Oct 23 08:52:42 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79B311E80CC for ; Tue, 23 Oct 2012 08:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.504 X-Spam-Level: X-Spam-Status: No, score=-106.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTiN1cBo0Nhb for ; Tue, 23 Oct 2012 08:52:41 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8750A11E80D1 for ; Tue, 23 Oct 2012 08:52:33 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUIa9Qcjp68woi0NoMFTcg57LYVAxwjhq@postini.com; Tue, 23 Oct 2012 08:52:40 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B50D41B82F4 for ; Tue, 23 Oct 2012 08:52:32 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A921219005C; Tue, 23 Oct 2012 08:52:32 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 23 Oct 2012 08:52:27 -0700 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [mif] New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt Thread-Index: AQHNrS3iW6gFvmNkqUiZ8bkm+bpnwpfB+fWAgAATB4CAAXzwgIAAAbKAgAOP3wCAAGxKgA== Date: Tue, 23 Oct 2012 15:52:25 +0000 Message-ID: <896E858D-BF41-4100-9E63-EE07B0D74DA6@nominum.com> References: <913383AAA69FF945B8F946018B75898A1480EDFA@xmb-rcd-x10.cisco.com> <7E99AA25-66C2-4A4D-B251-0E71F31FBA26@nominum.com> <913383AAA69FF945B8F946018B75898A148124F2@xmb-rcd-x10.cisco.com> <09806E4D-E6BA-431A-9BB4-F59AD64885A7@nominum.com> <913383AAA69FF945B8F946018B75898A14812900@xmb-rcd-x10.cisco.com> <50866262.3050500@gmail.com> In-Reply-To: <50866262.3050500@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <1D96C8967FB42943B2394B5D239C038B@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [mif] New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 15:52:42 -0000 On Oct 23, 2012, at 5:24 AM, Brian E Carpenter wrote: > It makes sense, but the draft doesn't explain that it is only > intended for use in managed networks where the suppression of > privacy is considered acceptable. I think this needs to be stated > in the Introduction, and the issue of (loss of) privacy needs to > be discussed in the Security Considerations. It might be worth mentioning in the security considerations section, but it= 's worth noting that this option increases the user's privacy, rather than = decreasing it; users who are known to the local network get temporary addre= sses; only those users who haven't yet registered do not. This would only occur on a network with a security policy that forbade priv= acy addresses in general. It's already possible to do that with existing = DHCP servers, routers and DHCP clients. The incremental additional privacy may seem trivial, since the user is stil= l being tracked by the local service provider whether they get privacy addr= esses or not on this network. However, the user would at least in princip= le have real and meaningful privacy from being tracked by their IP address = by service providers outside the administrative domain of the local network= . From lorenzo@google.com Tue Oct 23 19:54:02 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D528C21F87E7 for ; Tue, 23 Oct 2012 19:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.891 X-Spam-Level: X-Spam-Status: No, score=-102.891 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ly6Rc-X0uAtU for ; Tue, 23 Oct 2012 19:54:02 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4F71F0C6E for ; Tue, 23 Oct 2012 19:54:02 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so49822oag.31 for ; Tue, 23 Oct 2012 19:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=gwNok3PIkGlXTkn9RbgFgPjPkM8aaiXn05evRisMYSs=; b=VENnLaTTc9xG19Pbprg84pPvh8ohin3plSbYtKwzs7enuOerGPyq6DhzSufvUnvgZo /CoXeMSn41Po4sIFlU2flU0lsXVEXPREZ+Oc1JO8vMCePxEx612mkXbxHfuXyokJM0T2 yZl+ZjgWO17YtTio0/EgGSjbh+vsvSrUcCfs3pd/SDSpmmFEi3NjlQ/accikfiNjac0U CKVK5xfydlk8iy+nZku4gxHaIjM3VCT4YO+Lh9xY+e1AW+k5cShGQ6yso0EWm1FMXHTJ kyy+EDo+2Y2ZYV0ZLXkLFIc5KgMdEmowc6JOkRscIL6+1PYyvOVheAuufFv5ixYeU2ey Dyiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=gwNok3PIkGlXTkn9RbgFgPjPkM8aaiXn05evRisMYSs=; b=fwvjK7IKFqJPiZZFJKcZ6ErXv+mt9lYXHcHLPjztut0xpeZC8Ef9nXRmVn367E+rax o4lRolikaelvZhTFAG44/N34vvPBqCKyBK7qkYCpPSO+LbO90H9lHkJSYUtSN/pYNW1M j1imLSNDwjDNwMaeUdZSGnlcuEoWhk6IoF0t5LiIGvNpW+7HM6UaLw+KM9UGKwFRHh9+ 5lEQ1et8CL7e7kap6IZVrvFwn1Iv7Ccu8JOSPttbiH/Xol0+nFh0wiNWoXEO0jYEp3rr tioOZknLBCP2t4cbjYsqjArmJtlZ0ti5v8cyGLekSoBg5uB7v34DtgE7YSK7fDFZBB0P Nrrg== Received: by 10.60.5.138 with SMTP id s10mr12584108oes.80.1351047241608; Tue, 23 Oct 2012 19:54:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Tue, 23 Oct 2012 19:53:40 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A1480EDFA@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A1480EDFA@xmb-rcd-x10.cisco.com> From: Lorenzo Colitti Date: Wed, 24 Oct 2012 11:53:40 +0900 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=e89a8ff252cee92f0d04ccc5328a X-System-Of-Record: true X-Gm-Message-State: ALoCoQmSEW3vgTnleGWhgxFs8z3qm7YR3VKaNZHKkX05VqSEYuhWtEUxvzM8w2irmhedTauZsM9DBRw3I21OuIMicS7PZuuv8VBDlwPfQG25ZrUEQ9SJDLz+/UZHJh3wesGpAaXnXwMDUWoGRjMpP9VXMJsbD+jjoi8kYVZRziA5OTPjVLngg/Q/whmFQ7o+wdtbgEzD/zzW Cc: "mif@ietf.org" Subject: Re: [mif] FW: New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 02:54:02 -0000 --e89a8ff252cee92f0d04ccc5328a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 18, 2012 at 9:32 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > This draft proposes new DHCPv6 options to be added by the DHCPv6 relay > agent when it generates a Relay-Forwarded message to influence the DHCPv6 > server's response that modify the host's address policy table > [I-D.ietf-6man-addr-select-opt] based on observed network characteristics. > These options can also be used to conditionally disable IPv6 temporary > addresses in a managed network for selective hosts without authentication > supplicant. > > Comments and suggestions are welcome. > A few general points: 1. The draft deals with two DHCPv6 options, with different use cases. Why are you combine the options? I believe things would be much clearer if each option had its own draft with its own use case. 2. Why is this draft in MIF? The address selection option has nothing to do with multiple interfaces, and is already being discussed in 6man. The relay-supplied prefix option also has nothing to do with multiple interfaces. 3. The introduction does not provide a problem statement that matches the solutions. The introduction says that "DHCPv6 allows relatively static information to be configured in hosts, which is somewhat limiting", but then states that the problem can be fixed by introducing DHCPv6 options. I don't see how this is possible. DHCPv6 options cannot make things more dynamic, since in DHCPv6, options are only handed out at request/response time, and DHCPv6 options cannot change how often requests are made. Since the options being proposed as solutions do not solve the problem, the draft needs another problem statement. 4. The draft confuses RFC4941 privacy addresses with IA_TA options. Ignoring IA_TA options will not disable RFC4941 privacy addresses, because they are only used by SLAAC. The references to RFC 4941 should be removed. As regards the address selection option specifically: 1. The option itself is still work in progress in 6man. So the modifications should happen in 6man, not here. Otherwise we will have two working groups working on the same option which is likely to have bad results. 3. I don't understand the use case (Section 3.1). If the DHCPv6 relay is in the mobile access gateway, then it's in the mobile operator's network. If it's in the mobile operator's network, then how can it "influence the DHCPv6 Server in the home network"? In general, the DHCPv6 server in the home network has no way of talking to the mobile operator's network. --e89a8ff252cee92f0d04ccc5328a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Oct 18, 2012 at 9:32 PM, = Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> This draft proposes new DHCPv6 options to be added by the DHCPv6 relay agen= t when it generates a Relay-Forwarded message to influence the DHCPv6 serve= r's response that modify the host's address policy table [I-D.ietf-= 6man-addr-select-opt] based on observed network characteristics. These opti= ons can also be used to conditionally disable IPv6 temporary addresses in a= managed network for selective hosts without authentication supplicant.

Comments and suggestions are welcome.

A= few general points:

1. The draft deals with = two DHCPv6 options, with different use cases. Why are you combine the optio= ns? I believe things would be much clearer if each option had its own draft= with its own use case.

2. Why is this draft in MIF? The address selection opti= on has nothing to do with multiple interfaces, and is already being discuss= ed in 6man. The relay-supplied prefix option also has nothing to do with mu= ltiple interfaces.

3. The introduction does not provide a problem st= atement that matches the solutions. The introduction says that "DHCPv6= allows relatively static information to be configured in=A0hosts, which is= somewhat limiting", but then states that the problem can be fixed by = introducing DHCPv6 options. I don't see how this is possible. DHCPv6 op= tions cannot make things more dynamic, since in DHCPv6, options are only ha= nded out at request/response time, and DHCPv6 options cannot change how oft= en requests are made. Since the options being proposed as solutions do not = solve the problem, the draft needs another problem statement.

4. The draft confuses RFC4941 privacy ad= dresses with IA_TA options. Ignoring IA_TA options will not disable RFC4941= privacy addresses, because they are only used by SLAAC. The references to = RFC 4941 should be removed.

As regards the address selection= option specifically:

1. The option itself i= s still work in progress in 6man. So the modifications should happen in 6ma= n, not here. Otherwise we will have two working groups working on the same = option which is likely to have bad results.
3. I don't understand the use case (Section 3.1). If the DHCPv6 re= lay is in the mobile access gateway, then it's in the mobile operator&#= 39;s network. If it's in the mobile operator's network, then how ca= n it "influence the DHCPv6 Server in the home=A0network"? In gene= ral, the DHCPv6 server in the home network has no way of talking to the mob= ile operator's network.
--e89a8ff252cee92f0d04ccc5328a-- From ivo.sedlacek@ericsson.com Wed Oct 24 05:34:33 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6494A21F894C for ; Wed, 24 Oct 2012 05:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.038 X-Spam-Level: X-Spam-Status: No, score=-5.038 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UM3tyx8D0TBz for ; Wed, 24 Oct 2012 05:34:27 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D3F3121F8939 for ; Wed, 24 Oct 2012 05:34:26 -0700 (PDT) X-AuditID: c1b4fb25-b7f956d0000011c3-0c-5087e050357a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E5.6E.04547.050E7805; Wed, 24 Oct 2012 14:34:24 +0200 (CEST) Received: from ESESSHC023.ericsson.se (153.88.183.87) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 24 Oct 2012 14:34:24 +0200 Received: from ESESSMB301.ericsson.se ([169.254.1.169]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 14:34:24 +0200 From: Ivo Sedlacek To: "mif@ietf.org" Thread-Topic: Question to draft-ietf-mif-dhcpv6-route-option-05 Thread-Index: Ac2x48yO3q8p/vbGSI+GbiRys+ZsVQ== Date: Wed, 24 Oct 2012 12:34:23 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610101A1DC@ESESSMB301.ericsson.se> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/related; boundary="_005_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUyM+JvrW7Ag/YAg499ZhZde24wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr48XhJcwF7ZcYK9bsec3ewHhvD2MXIyeHhICJxJNDe5kgbDGJ C/fWs3UxcnEICZxilOj9+ZcdwtnJKDFx/loWCGcJo8Thv30sIC1sAnoSE7ccYQWxRQQUJf6+ 3s0MYgsLWEms7Z7PBhG3lzh6bikzhK0n8epTG9hqFgFViY51U4E2cHDwCnhL9J5JAQkzCshK XP3TC1bCLCAucevJfKjrRCQeXjzNBmGLSrx8/I8VwlaU2Hm2nRnkNmaBbkaJj9OusYMkeAUE JU7OfMICMl9IQE3i46r8CYwis5CMnYWsZRaSFoiifImrfZfZIWwdiQW7P7FB2NoSyxa+Zoax zxx4zIQpriOx+dJOqDmKEm2ds6GWLWWUWHngMRtM0e6/PawwRVO6H8ItW9o2DaiGAyzedacM rvf3qhOsMDUv7r9mQ9a7gFFoFaNwbmJmTnq5kV5qUWZycXF+nl5x6iZGYEI5uOW36g7GO+dE DjFKc7AoifNab93jLySQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRaVNrs3mK0cZ9zsVpNQdD WPVbp85jYnnzJcG4terBN2/B/bzsEz82mmx8s5WXLZ3Juzxv68/p06QaTp3KL1+aeYg5o/zN cTmZrQXrzb/u/N6bsVBj6ezOxtuP267GrLgkaL/oZfOh4t0+xcfZgtUsj8+aq3lirlJbN9dh dqVrnw++UdO94K2txFKckWioxVxUnAgATC0ID/YCAAA= Subject: [mif] Question to draft-ietf-mif-dhcpv6-route-option-05 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 12:34:33 -0000 --_005_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_ Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_" --_000_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, draft-ietf-mif-dhcpv6-route-option-05 states in section 7.1: Metric field (available in previous version of this draft) has been replaced with 2-bit preference field that is in line with RIO information. Issue1: the section 4 states: In terms of the high level operation of the solution defined in this draft, a DHCPv6 client interested in obtaining routing information request the route options using the DHCPv6 Option Request Option (ORO) sent to a server. A Server, when configured to do so, provides the requested route information as part of a nested options structure covering; the next-hop address; the destination prefix; >>the route metric<<; any additional options applicable to the destination or next- hop. Given the statement in section 7.1, is "the route metric" above correct or = is it an obsolete text? Issue2: section 5.2 states: .... 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_RT_PREFIX | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix-Length |Resvd|Prf|Resvd| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Prefix | | (up to 16 octets) | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . RT_PREFIX sub-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Route Prefix Option Format .... Metric: Route Metric. 8-bit signed integer. The Route Metric indicates whether to prefer the next hop associated with this prefix over others, when multiple identical prefixes (for different next hops) have been received. .... There is no "Metric" field shown in the Figure 3. Thanks for clarification. Kind regards IVO SEDLACEK Ericsson Mobile +420 608 234 709 ivo.sedlacek@ericsson.com www.ericsson.com [Description: Description: http://www.ericsson.com/] This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer --_000_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

draft-ietf-mif-dhcpv6-route-option-05 sta= tes in section 7.1:

 

   Metric field (available in previous version o= f this draft) has been

   replaced with 2-bit preference field that is = in line with RIO

   information.

 

Issue1:

 

the section 4 states:

 

   In terms of the high level operation of the solution defi=
ned in this
   draft, a DHCPv6 client interested in obtaining routing in=
formation
   request the route options using the DHCPv6 Option Request=
 Option
   (ORO) sent to a server.  A Server, when configured t=
o do so, provides
   the requested route information as part of a nested optio=
ns structure
   covering; the next-hop address; the destination prefix; <=
u>>>the route
   metric<<; any additional options applicable =
to the destination or next-
   hop.

 

Given the statement in section 7.1, is &q= uot;the route metric" above correct or is it an obsolete text?

 

 

Issue2:=

 

section 5.2 states:

....

 

      0      &n=
bsp;            1&nb=
sp;            =
      2       &=
nbsp;           3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9=
 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;
     |       OPTION_=
RT_PREFIX        |   &nbs=
p;      option-len     &n=
bsp;     |
     +-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;
     |       &n=
bsp;            =
;     Route lifetime      =
;            &n=
bsp;     |
     +-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;
     | Prefix-Length |Resvd|Prf|Resvd|  =
            &nb=
sp;            =
    |
     +-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+   &=
nbsp;           &nbs=
p;            &=
nbsp;  |
     |       &n=
bsp;            =
;        Prefix    &=
nbsp;           &nbs=
p;            |=

     |       &n=
bsp;            =
;      (up to 16 octets)    &n=
bsp;            =
;   |
     |       &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;     |
     |       &n=
bsp;            =
;           +-+-&=
#43;-+-+-+-+-+-+-+-+-+-+-+-+=
;-+-+
     |       &n=
bsp;            =
;           |  =
            &nb=
sp;            =
    |
     +-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+   &=
nbsp;           &nbs=
p;            &=
nbsp;  |
     .       &n=
bsp;            =
;             &=
nbsp;           &nbs=
p;            &=
nbsp;    .
     .       &n=
bsp;            =
;     RT_PREFIX sub-options    &nbs=
p;            .=

     .       &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;     .
     +-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;
 
            &nb=
sp;      Figure 3: Route Prefix Option Format=

 

....

 

   Metric:   Route Metric. 8-bit signed integer.&n=
bsp; The Route Metric
           &nbs=
p; indicates whether to prefer the next hop associated with

           &nbs=
p; this prefix over others, when multiple identical prefixes

           &nbs=
p; (for different next hops) have been received.


....


 


There is no "Metric" field show=
n in the Figure 3.


 


Thanks for clarification.


 


Kind regards<=
/o:p>


 


3D"Description:=



IVO SEDLACEK





Ericsson

Mobile +420 608 234 709

ivo.sedlacek@ericsson.com

www.ericsson.com 





3D"Description=


 


This Communication is Confid=
ential. We only send and receive email on the basis of the terms set out at

www.ericsson.com/email_disclaimer
--_000_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_-- --_005_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1417; creation-date="Wed, 24 Oct 2012 12:34:23 GMT"; modification-date="Wed, 24 Oct 2012 12:34:23 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlh/wADAPcAABUpeBUoeBQse1WrIWCvHQCDrwCOUhQtewCLcRMvfACMZQCEoxiYOzqiLQCN XwCMZp0MXEYdbQCHkkAfbjyjLAhhnwdlojAicgCNWgCGlQCOVQRvqQRxqgCIhg9BiQZopFYaag6U P8YEU3C0FrYHVwtUln4SYgCGlxI1gHUUZACKeCmdNFsZaYgRYACQR8MFVIQRYRE3gqcKWpoNXACF nnIVZGsWZi0ichomdghenQN1rQhgngCHjg5HjQ9AiHa2ExE6hDkgcACIiUwcbDShL7kHVg9Dijwf b3gUY4y9CgpXmF8ZaACOWGuyGFCqI2OwG24WZZS/BkqoJgCJewCDrE2pJQtTlQCHiyyeMyEldVut HwCMaBA8hRA/hxyZOdUBUMwDUqoKWQCFmwF8sgF+swCNYaQLWgCEqgCCtgCEpwCFnACJfwCKdgCL bWgXZgCPTCojcwCFoBQqeSQkdAldnAJ6sAN0rFkaaQxNkQlbmwCHjQ1Kjw5GjACLaz+kKgCQSRE5 g7MIVwVtp4S6DZrBBAdjoKAMWzGgMM8OWl2uHgGQRQORRHO1FHsTYxaXPJEPXo++CYe7DACPSkkd bU8ca7AJWGixGQN3rgVrphcndwZqpWawGgdkoWIYaAZno5K/CC+fMY0PXwCHkAxQkwCKegCIhLwG VQCPUCGbNzeiLgiTQgCNXCScNhCVPhOWPX64EJzCA2UXZ0SmKBA9hlKqIgxOkh6aONICUVIba88C USecNRMwfq0JWACCs3m3EgCGmQCJgACIgpfABRI2gQCMY78GVVisIACEqIG5DwCCtQ5EiwCEpYES YQF/tACBtQCJfZQOXQCKdEinJ4m8CwCLbwpWl0KlKQCOVwCPTjMhcYoQX0MebgtRlB0ldZcOXQVu qCckdACFogCGkwCDsQJ7sQCKcgWSQwRyqw1MkG6zFzcgcAlamgCDrgCIh3y4EQ1JjhMyfhIzfwJ4 rwCLagCNXgCOUwpYmQuUQLPPN+Drqp/DAtXkjK/NLLHOK/Ccu////yH5BAAAAAAALAAAAAD/AAMA AAj/AP/9y8cPFiFhUT5BSjIt0iBkr9z5+sFoRLomljY9IZBIi7EBtJxUkSJNljU/FBqkInIIFJYV ulihsuWFgSNXrULcU2VukSIXfyS9wXbKQD0N15hgWEXPQRliCh5smdenDTUE5aKxUUFqyrM1wIKV 6tBOyBU9PERJEJfhxC8xamjECbdgWZpjZ6iwKzCuVzI0zpqRGUOujrxLOuyc47DhmyBMmj54ssCp UIUdOejkWWdPSbUSVriNqoUH3Z53PfgoM+LBR5dZXIAAijEMRTx4uxIcECAHQIBMOLplmQMOzo0L 2dQFOTJhW4RJQyjhAnGHxZJOsdzYgFIjBZJGJpjB/2ihLdQjaN5mQDBkRkYYXpUCkShiqtgLESLA 5Lp1y59Agf3oYxBCCjHkEEQSUWQRRhpx5BFIIpFkEkoqseQSTDLRZBNOOvHkE1BCEWUUUkox5RRU UlFlFVZaceUVWGKRZRZaarHlFlxy0WUXXnrx5RdgghFmGGKKMeYYZJJRZhlmmnHmGWiikWYaaqqx 5hpsstFmG2668eYbcMIRZxxyyjHnHHTSUWcddtpx5x144pFnHnrqsecefPLRZx9++t3yBSL//bMP PgMmtFBDD0U0UUUXZbRRRx+FNFJJJ6W0UksvxTRTTTfltFNPPwU1VFFHJbVUU09FNVVVV2W1VVdf hWY1VllnpbVWW2/FNVddd+W1V19/BTZYYYcltlhjj0U2WWWXZbZZZ5+FNlppp6W2WmuvxTZbbbfl tltvvwU3XHHHJbdcc89FN11112W3XXffhTdeeeelt15778U3X3335bffF/79ExAAOw== --_005_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=1809; creation-date="Wed, 24 Oct 2012 12:34:23 GMT"; modification-date="Wed, 24 Oct 2012 12:34:23 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlh9AFRAPcAAId6ryxvsAtXo8zr6BBJmdIaXiuWxACZi5nW17ritehtmC6skFWWx3YdbtfD 2ffg6qpUjgCXpb3X6gCYnGvHjKbbqaypzHvCQSmsSpnXzI3RjQCcZxKkauLx1OWUtcXjpq3ftkQj ed7r9ACMuieltdekwo5Xlbvh6ur25oy118MaYQiiUwCaeM7s3tc5dNbV5u71+hg7jnfE1tjuzZnS 4qbUcZXPb6bXiLIvcojM3MfmswN8uVW7tKrY5rWWve6jv+zh7ENysSpGlJ2bw5vZvaoaZWa8Q4TQ npYvd2g/iCwqgBGatpsbZ7R3p1m5RILEQMeVuunR4YUca3m32fL68wCeW5rM47Xfp/Tw9gCTsm9v qUu6cEahywOCurMaY3JRlG6Yxse10b3l1YjQuRSmT2e41UyFvZSjyhGhhEi6gt4oZ8tIgZ+52HbH cYrD3sOlxtTu223AUk62RY6v04jO00S2ld7y6+749atonUKzRka2U1W8nLTiw9SVuM3m8X3NoJDV rfXR3/rw9WbDpyhYobqGsTGFvq3M4zOiyFEgdeCjwamYwHMtemO/Wd3w9TQnfTq0ZTq1drW713fK s+NHfarezK6Hs+TC1tSzzmbCuL/iptmFrKGz1FtTmIGbxtrw2rXdms/c7BGdqnuu07qmyFas0glg qiKpe4k7gRWFvj+yR8rqzojJW14fc1S6VHSKu8V2pCEyh/Oyya6Xv4jPy2qp0fPC1Krd1BKSwIjS shpmrFW5xrfcjBd5t+azyzg6isLL4YvGPwZusjKvSO73+u+Us94ZXHvGXFikz2GDuY7JTbHA2w6k UUSww+Dm8ZGozn2mzjayVojFQCuvaavgx1aw0ojHTsLhmZzA3ZTKTFfAjMSFr4jQwpegx37ET1M6 iEBehn+Trr/J1xA1aJ+uwu/y9t/k68/X4WB5mzBQfCBDcprYqnCGpY+huK+8zE9rkqatz9brv7/R 5ZbNWRhusshmmI+r0Kvbm3TAQiKrW5dpobvfmt1XiaGJtgAoXv///ywAAAAA9AFRAAAI/gD/CRxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1L1qC5duHC iSvLtq3bqeTe+Zs7F93bu3jz/hSHbhzdv/7I6R1MuPBKc+zUAV4MzrDjx5AxlmuXbrFlf40ja97M uWDcy6Azdx5NWi9fv6BBCy7NurVYxIpTp2bnurZtrJMrywatjp2528CDPz0Xe7dldO6EK1+eVLfx v+nIlWNOvXrQc8/p9v5tvbt3neKe/o9Dt7bgOXbg3q3+zr49yvCywUkveLb4XNHu8+v3aP+vunbc DVQOOeCA1s5+CCZ40TmozTXeOQa5g85u+Clo4YULTYYOO+sNdF6D8WEo4ogOneXcc++QqOKKAg0o V3Z/JcfijBZKCCKM43RI447swQYjYOm0Mx2PRH7H4I/a+Vbkkt/19xxyTEbZHXzZyTeklFgyR6Vs 6oQT4EBxgQNOOFdmaeZo2KU2XnkEndMXkGWeKWdkBVqmnlnhOElXOHP2GVk5J/735T8DnnhZhX4m Opg7aUFYkDsvGoeoopQW5uaNu6VY6aaDmZMnknOxyemoZRUK6lzqyEjqqmGdEymo/u+oyuqsXblz qj/RxUnrrllhutt2vAbL1Za7jSersMheRWxo8yXrLFZp8ubls9RmVSdgD1arLW7X+nPntuBCS447 g4Zr7rnopqvuuuy26+678MYr77z01mvvvfiqe444/PKr0IBpkeMowOG0MzA5aRk8kDkIh+NovvRa tla3/uQoUKgChbPYP0fS1Rg5IGbGDpCO0lVegXxCfO5c6YgpJoQUzzUdxiOjCk5l/8TWcsv/oLZz Yxrf5/PF9wmEssor+yOq0XMRqttaoZpD14EC/eaggPClI2DPcx1YDmqC/TWxPykjDW7X/Z4cqjt+ jUO0OOSwbBBqvUFYTpK/wee2+UA181kXZv8cbfbZGweOrYyhBl02mIDZVfOe8InWTtFzSR2Y4INr W1daaTENWHmhTu7tQZfSBeFpdMWN60BB09a0xupgnjm1GBdU5z+i2/VPqNE+bNCLbAI6l62VC6Tb gU1/XTHZs2vuDzqcT3v73RW/bfjmef7zDjrttIOaOL2hhZo5E+L6WcUz+5Pxns1XK/H1Ar0YttKE xizOjY0tZpfwf42DuPqEQs3i2oes6HHuN+jJjDvExKe0BEhCLvNNOFwGDiH9I4Fi6lCYwKGkjJVN HGlZGgFHSMISmvCEKEyhClfIwha68IUwjKEMZ0jDGtrwhjjMYUUCAgA7 --_005_39B5E4D390E9BD4890E2B3107900610101A1DCESESSMB301ericsso_-- From praspati@cisco.com Wed Oct 24 10:42:17 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43EC21F882B for ; Wed, 24 Oct 2012 10:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.307 X-Spam-Level: X-Spam-Status: No, score=-10.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A21TdJTtyweO for ; Wed, 24 Oct 2012 10:42:16 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 12CBF21F8711 for ; Wed, 24 Oct 2012 10:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2831; q=dns/txt; s=iport; t=1351100536; x=1352310136; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7ssgkFBr2zrL1ClQSXGqQQkLbD58O6MUx0CDr0jmEMc=; b=PPP36orjOWzgv6tadZRY6cxFGGFj0/YWkLgrcnp7OAkB8fYspGImeQWz YvkiTp/TxOTkVl1wwjfmlJwOR5iCgOavc5XI5JGZGlzU3Wa9P2bJS3ChZ LXDmqIj47PJjrOwUfDwmUUF/8LfJWxX5rhPyUal9Ean0TM190p7ykxbhG 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJkniFCtJXHB/2dsb2JhbABEwXmBCIIeAQEBBAEBAQ8BWwkCEgEIGApFBgslAgQBDQUIGodQAw8LnEOWPA2JUASKemeGDGEDlB6MfoMlgWuCb4FbAh4EAhg X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="134958329" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 24 Oct 2012 17:42:15 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9OHgFYD005271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Oct 2012 17:42:15 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.203]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 12:42:15 -0500 From: "Prashanth Patil (praspati)" To: Brian E Carpenter , "Tirumaleswar Reddy (tireddy)" Thread-Topic: [mif] New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt Thread-Index: AQHNsg7nS4dGruTwa0O9vQpZCFwZAg== Date: Wed, 24 Oct 2012 17:42:14 +0000 Message-ID: In-Reply-To: <50866262.3050500@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.164.161] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19302.000 x-tm-as-result: No--53.154900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <791C1213793F034B9729E58DCC9DC953@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 17:42:18 -0000 Hi Brian, On 23/10/12 2:54 PM, "Brian E Carpenter" wrote: >On 21/10/2012 04:01, Ted Lemon wrote: >> On Oct 20, 2012, at 10:55 PM, "Tirumaleswar Reddy (tireddy)" >> wrote: >>> Yes. In such Managed Networks, SLAAC is disabled and IPv6 addresses >>>are only assigned using DHCPv6 server. Switches in such environments >>>provide First Hop Security by gleaning DHCP/NDP messages and can make >>>sure hosts are using the IPv6 addresses assigned by the DHCPv6 server >>>only (Source Guard). With the technique in this draft only certain >>>hosts will be permitted assignment of IA_TA and not for other hosts. >>=20 >> That makes sense=8Bthanks for clarifying! > >It makes sense, but the draft doesn't explain that it is only >intended for use in managed networks where the suppression of >privacy is considered acceptable. I think this needs to be stated >in the Introduction, and the issue of (loss of) privacy needs to >be discussed in the Security Considerations. Sure, will state as suggested. > >How will users know that temporary addressing has been disabled? Users wont. I suppose guests authenticating using Webauth could be served a disclaimer page that points this out. It's the administrative domain that makes this decision. > >Is there a risk of a rogue DHCPv6 relay switching off temporary >addressing for hosts that really need it? DHCP authentication should be used to counter such risks. A DHCP server would then only process relay options included by a valid relay agent. > >Also, in the section > >> 3.2.1. Avoiding Excessive IP-Based Authentication > >it says: > >> When Address-based authentication is used, re- >> authentication occurs for each address obtained by the host, which >> can create a lot of authentication transactions. To reduce this >> chatter, > >This doesn't convince me that the proposed feature is solving a real >problem. "A lot of" and "chatter" are vague terms. Can you add something >to suggest what size of a network would have a real performance problem >as a result? When IP address based authentication eg Webauth is used, the authentication device will end up authenticating each and every temporary address used by the client - So 'a lot of' here implies that the number of authentications is equal to the number of temporary addresses used by the host - this would also lead to bad user experience. The same number of transactions with the backend AAA server to validate user credentials will also have to be made. Will add these details. -Prashanth > >Regards > Brian Carpenter > > >_______________________________________________ >mif mailing list >mif@ietf.org >https://www.ietf.org/mailman/listinfo/mif From tireddy@cisco.com Wed Oct 24 22:57:57 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5005C21F9053 for ; Wed, 24 Oct 2012 22:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbsOKoNACe0P for ; Wed, 24 Oct 2012 22:57:55 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9C39521F9052 for ; Wed, 24 Oct 2012 22:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19330; q=dns/txt; s=iport; t=1351144675; x=1352354275; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XubvA2EwUAMxJiyDQAz5tZoa5Qt+Btxr6sbFPTgRhIw=; b=k5M92LsI3Bs0DsOsdCyllS8WJCUkV/dxIgPBBBY0XXu4bPF/gzosMzNH TogmBJjCnHtPHQ9RdlQlVA1KaVuC5BqmyXbSTzXOzy1PkhWkww1WnFUjq Tm2EQYQqd2It0FHHrDrCBBnqdHlaW1wHB6aOWBdGpmJFkfMAkMV2VDwTD c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFAOnTiFCtJXG9/2dsb2JhbABEgkq2bAGIaoEIgh4BAQEEEgEUBkoCEAIBCBEEAQELHQcyFAgBCAIEDgUIEweHYgudG6AHi2GGDGEDlwqNN4Frgm+BWyAEGg X-IronPort-AV: E=Sophos;i="4.80,645,1344211200"; d="scan'208,217";a="135135946" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 25 Oct 2012 05:57:55 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9P5vsjt028070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Oct 2012 05:57:54 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Thu, 25 Oct 2012 00:57:54 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Lorenzo Colitti Thread-Topic: [mif] FW: New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt Thread-Index: AQHNqwBu7RP4kWipA0qEvbLMwC6QFpe++/4QgAknXQCAAIGNwA== Date: Thu, 25 Oct 2012 05:57:54 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1481D4AF@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A1480EDFA@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.71.111] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19306.000 x-tm-as-result: No--55.806600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A1481D4AFxmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] FW: New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 05:57:57 -0000 --_000_913383AAA69FF945B8F946018B75898A1481D4AFxmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see inline [Tiru] From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: Wednesday, October 24, 2012 8:24 AM To: Tirumaleswar Reddy (tireddy) Cc: mif@ietf.org Subject: Re: [mif] FW: New Version Notification for draft-reddy-mif-dhcpv6-= precedence-ops-02.txt On Thu, Oct 18, 2012 at 9:32 PM, Tirumaleswar Reddy (tireddy) > wrote: This draft proposes new DHCPv6 options to be added by the DHCPv6 relay agen= t when it generates a Relay-Forwarded message to influence the DHCPv6 serve= r's response that modify the host's address policy table [I-D.ietf-6man-add= r-select-opt] based on observed network characteristics. These options can = also be used to conditionally disable IPv6 temporary addresses in a managed= network for selective hosts without authentication supplicant. Comments and suggestions are welcome. A few general points: 1. The draft deals with two DHCPv6 options, with different use cases. Why a= re you combine the options? I believe things would be much clearer if each = option had its own draft with its own use case. [Tiru] Sure, we will create two different drafts. After we split the draft = into two [1] we will post Absolute Precedence Option with relevant use case= s in 6man [2] Relay-supplied prefix option in DHCP WG. 2. Why is this draft in MIF? The address selection option has nothing to do= with multiple interfaces, and is already being discussed in 6man. The rela= y-supplied prefix option also has nothing to do with multiple interfaces. [Tiru] Yes. Only Absolute Precedence Option deals with MIF scenario where M= obile Node is assigned prefixes from both Local Access Network and Home Net= work. We had other multi-homing use cases in 01 version which are removed i= n 02. 3. The introduction does not provide a problem statement that matches the s= olutions. The introduction says that "DHCPv6 allows relatively static infor= mation to be configured in hosts, which is somewhat limiting", but then sta= tes that the problem can be fixed by introducing DHCPv6 options. I don't se= e how this is possible. DHCPv6 options cannot make things more dynamic, sin= ce in DHCPv6, options are only handed out at request/response time, and DHC= Pv6 options cannot change how often requests are made. Since the options be= ing proposed as solutions do not solve the problem, the draft needs another= problem statement. [Tiru] Agreed the problem statement needs to be fixed in this version. But we are evaluating other scenarios for the next version For e.g. In IPv= 6 multi-homing, dual stack scenarios - where Relay agent dynamically influe= nces the host policy table If IPv6 connectivity is detected to be broken (S= ection 10.3.1 of RFC 6724). This can be achieved by Relay Agent sending REC= ONFIGURE-REQUEST (http://tools.ietf.org/html/draft-ietf-dhc-triggered-recon= figure-01) to the DHCPv6 server providing the updated policy table in Absol= ute Precedence Option. DHCPv6 server will in turn initiate reconfigure mess= age with the client, resulting in the client to initiate Renew/Reply or inf= ormation-request/Reply transaction with the server to receive updated Polic= y Table OR Do you think we can send the dynamic policy table in RA itself and solve th= e problem (but then it brings in complexity on the host if it is receiving = policy table from two different sources) Please let us know your opinion before we proceed on this path . 4. The draft confuses RFC4941 privacy addresses with IA_TA options. Ignorin= g IA_TA options will not disable RFC4941 privacy addresses, because they ar= e only used by SLAAC. The references to RFC 4941 should be removed. [Tiru] Yes, will remove this part. As regards the address selection option specifically: 1. The option itself is still work in progress in 6man. So the modification= s should happen in 6man, not here. Otherwise we will have two working group= s working on the same option which is likely to have bad results. [Tiru] Agreed 3. I don't understand the use case (Section 3.1). If the DHCPv6 relay is in= the mobile access gateway, then it's in the mobile operator's network. If = it's in the mobile operator's network, then how can it "influence the DHCPv= 6 Server in the home network"? In general, the DHCPv6 server in the home ne= twork has no way of talking to the mobile operator's network. [Tiru] This use case is specific to Proxy Mobile IPv6 (RFC 5213). Where the= re is tie-up b/w the Local Access Network and Mobile Network. Mobile. MAG i= n the Local Access Network establishes tunnel with LMA in the Home network.= MAG can act as a DHCP relay agent and can communicate with the DHCP server= in the home network. MN MAG(DHCP-R) LMA DHCP-S | |------->| | 1. Proxy Binding Update * | |<-------| | 2. Proxy Binding Acknowledgement | |=3D=3D=3D=3D=3D=3D=3D=3D| | 3. Tunnel/Route Setup* |------>|-------------->| 4. Solicit via DHCP-R |<------|<--------------| 5. Advertise via DHCP-R |------>|-------------->| 6. Request via DHCP-R |<------|<--------------| 7. Reply via DHCP-R | | | We will add more details to explain these details in next version. --Tiru. --_000_913383AAA69FF945B8F946018B75898A1481D4AFxmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see inline [Tiru]

 

From: Lorenzo = Colitti [mailto:lorenzo@google.com]
Sent: Wednesday, October 24, 2012 8:24 AM
To: Tirumaleswar Reddy (tireddy)
Cc: mif@ietf.org
Subject: Re: [mif] FW: New Version Notification for draft-reddy-mif-= dhcpv6-precedence-ops-02.txt

 

 

On Thu, Oct 18, 2012 at 9:32 PM, Tirumaleswar Reddy = (tireddy) <tiredd= y@cisco.com> wrote:

This draft proposes new DHCPv6 options to be added b= y the DHCPv6 relay agent when it generates a Relay-Forwarded message to inf= luence the DHCPv6 server's response that modify the host's address policy t= able [I-D.ietf-6man-addr-select-opt] based on observed network characteristics. These options can also be used = to conditionally disable IPv6 temporary addresses in a managed network for = selective hosts without authentication supplicant.

Comments and suggestions are welcome.

 

A few general points:

 

1. The draft deals with two DHCPv6 options, with dif= ferent use cases. Why are you combine the options? I believe things would b= e much clearer if each option had its own draft with its own use case.=

[Tiru] Sure, we will create two different drafts. After we s= plit the draft into two [1] we will post Absolute Precedence Option with re= levant use cases in 6man [2] Relay-supplied prefix option in DHCP WG.

 

2. Why is this draft in MIF? The address selection o= ption has nothing to do with multiple interfaces, and is already being disc= ussed in 6man. The relay-supplied prefix option also has nothing to do with= multiple interfaces.

[Tiru] Yes. Only Absolute Precedence Option deals with MIF s= cenario where Mobile Node is assigned prefixes from both Local Access Netwo= rk and Home Network. We had other multi-homing use cases in 01 version which are removed in 02.=

 

3. The introduction does not provide a problem state= ment that matches the solutions. The introduction says that "DHCPv6 al= lows relatively static information to be configured in hosts, which is= somewhat limiting", but then states that the problem can be fixed by introducing DHCPv6 options. I don't see how this i= s possible. DHCPv6 options cannot make things more dynamic, since in DHCPv6= , options are only handed out at request/response time, and DHCPv6 options = cannot change how often requests are made. Since the options being proposed as solutions do not solve the p= roblem, the draft needs another problem statement.

[Tiru] Agreed the problem statement needs to be fixed in thi= s version. 

But we are evaluating other scenarios for the next version&n=
bsp; For e.g. In IPv6 multi-homing, dual stack scenarios - where Relay agen=
t dynamically influences the host policy table If IPv6 connectivity is dete=
cted to be broken (Section 10.3.1 of RFC 6724). This can be achieved by Rel=
ay Agent sending RECONFIGURE-REQUEST (http://tools.ietf.org/html/draft-=
ietf-dhc-triggered-reconfigure-01) to the DHCPv6 server providing the u=
pdated policy table in Absolute Precedence Option. DHCPv6 server will in tu=
rn initiate reconfigure message with the client, resulting in the client to=
 initiate Renew/Reply or information-request/Reply transaction with the ser=
ver to receive updated Policy Table OR 
Do you think we can send the dynamic policy=
 table in RA itself and solve the problem (but then it brings in complexity=
 on the host if it is receiving policy table from two different sources) 
Pleas=
e let us know your opinion before we proceed on this path .

 

 

4. The draft confuses RFC4941 privacy addresses with= IA_TA options. Ignoring IA_TA options will not disable RFC4941 privacy add= resses, because they are only used by SLAAC. The references to RFC 4941 sho= uld be removed.

[Tiru] Yes, will remove this part. 

As regards the address selection option specifically= :

 

1. The option itself is still work in progress in 6m= an. So the modifications should happen in 6man, not here. Otherwise we will= have two working groups working on the same option which is likely to have= bad results.

[Tiru] Agreed

 

3. I don't understand the use case (Section 3.1). If= the DHCPv6 relay is in the mobile access gateway, then it's in the mobile = operator's network. If it's in the mobile operator's network, then how can = it "influence the DHCPv6 Server in the home network"? In general, the DHCPv6 server in the home net= work has no way of talking to the mobile operator's network.

 

[Tiru] This use case is specific to Proxy Mobile IPv6 (RFC 5= 213). Where there is tie-up b/w the Local Access Network and Mobile Network= . Mobile. MAG in the Local Access Network establishes tunnel with LMA in the Home network. MAG = can act as a DHCP relay agent and can communicate with the DHCP server in t= he home network.

 

  MN   MAG(DHCP-R) LMA   DHCP-S

   |       |------->| =
     | 1. Proxy Binding Update *


   |       |<-------| =
     | 2. Proxy Binding Acknowledgement 

   |       |=3D=3D=3D=3D=
=3D=3D=3D=3D|      | 3. Tunnel/Route Setup*


   |------>|-------------->| 4. Solicit via DHCP-R


   |<------|<--------------| 5. Advertise via DHCP-R


   |------>|-------------->| 6. Request via DHCP-R


   |<------|<--------------| 7. Reply via DHCP-R<=
/o:p>


   |       |   =
            |


We will add more details to explain these details in next ve=
rsion.


 


--Tiru.
--_000_913383AAA69FF945B8F946018B75898A1481D4AFxmbrcdx10ciscoc_-- From n@arifumi.net Thu Oct 25 03:26:55 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C13C21F8962 for ; Thu, 25 Oct 2012 03:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1odR++C4g-F for ; Thu, 25 Oct 2012 03:26:55 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A3DB221F893B for ; Thu, 25 Oct 2012 03:26:54 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so1414019lam.31 for ; Thu, 25 Oct 2012 03:26:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=B5OSYeqgXshAlVsI1xC402YB14nArGxVrCEOU8MRrls=; b=pSJW1tCBjOH3CZCw6tSn6Jdw6yLDTd28PRavbknhZFwNglggvEMkV5ZFeoe0F2ZT3Z edGP42urA8ntprbYu1TFhLr8bQRjbnFpTL4zT2PyKPedxhIgcClezjhlkYd2T2MHky39 JJZ0Ceg6E7Hx2Af/GlVq4RWH2efuoRDYXW3JRXSqBWSJBRnr222DVfK6ZZMYa4qXXlV/ 0mckPnXkAo9y8nLfMp/3Rpa23CCsRINEjHVwkY1yca+M1UGkj0TTxL6d+nP9XyMDFi/F TDlR64A19qWCI4QZ79psM3HkpWMsto4sYru7/e3NWewF96AlbhT64LRgh+32yaa0SKck YOJQ== MIME-Version: 1.0 Received: by 10.152.109.145 with SMTP id hs17mr17377151lab.5.1351160813545; Thu, 25 Oct 2012 03:26:53 -0700 (PDT) Sender: n@arifumi.net Received: by 10.114.64.16 with HTTP; Thu, 25 Oct 2012 03:26:53 -0700 (PDT) X-Originating-IP: [2001:df0:45:20::61] In-Reply-To: References: <913383AAA69FF945B8F946018B75898A1480EDFA@xmb-rcd-x10.cisco.com> Date: Thu, 25 Oct 2012 19:26:53 +0900 X-Google-Sender-Auth: GESW8FQzy_xTpa-b-cqWL-dFAsc Message-ID: From: Arifumi Matsumoto To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmwOh9gp/DlNunwyNAKLSKRJT2hzJjC6MyWWp6p5gRYp725xjhURgmKUkoOt1rFKprz67J6 Cc: "mif@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [mif] FW: New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 10:26:55 -0000 Hi, 2012/10/24 Lorenzo Colitti : > As regards the address selection option specifically: > > 1. The option itself is still work in progress in 6man. So the modifications > should happen in 6man, not here. Otherwise we will have two working groups > working on the same option which is likely to have bad results. > 3. I don't understand the use case (Section 3.1). If the DHCPv6 relay is in > the mobile access gateway, then it's in the mobile operator's network. If > it's in the mobile operator's network, then how can it "influence the DHCPv6 > Server in the home network"? In general, the DHCPv6 server in the home > network has no way of talking to the mobile operator's network. It looks to me this is not the modifications to the address selection option happening in 6man, but it is another proposal for tweaking DHCPv6 messages from clients at DHCP relay agent. So, in other words, this option just depends on the address selection option. If it is true, a work that depends on another work can be done separately in a separate wg. I do not know whether mif is the right place for this proposal, but generally speaking it is the right place where the scope and motivation matche best. Thanks. From lorenzo@google.com Thu Oct 25 18:09:36 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E7121F843D for ; Thu, 25 Oct 2012 18:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.898 X-Spam-Level: X-Spam-Status: No, score=-102.898 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHSjeIVfNQBh for ; Thu, 25 Oct 2012 18:09:28 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7602C21F8427 for ; Thu, 25 Oct 2012 18:09:28 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so2490411oag.31 for ; Thu, 25 Oct 2012 18:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=Y1OGwsStERf8iQjPl/6lSjav/0q/4TBus4YA3PB5PIM=; b=TZb58hh18pnEymFXRcaofdw0BDsYyKYT/53tTOF8CTIsjQ1+P/6tISR3r7BE7kkAmi Yyj3j0AsqHapP6zShR7oedP4kQkthodmuMKOLCHUkwJNP9JAK87ECZuOFX8T8F2euqyy P7O2Q4gGtZ+zkOC5ORcSobeVOe+c9j9IaBF3i8T0VihldV1jdwBa6zvhzahxRY1nGFv9 wYm0HMeljd2cuT0jpwx6FOR3E79M1vmjj6T867hu9h19OzmidNwPguhbVxCUhH9DeHQD 5S3IFwKcsUVwx9JM8uR/ZPDhf+IaDFeaRDJIy/2z701cQWiT/imInV9fGA+aOnLXVLe8 CGMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=Y1OGwsStERf8iQjPl/6lSjav/0q/4TBus4YA3PB5PIM=; b=EK04qZDZqD1T9Ai94rFRZMZ2IEWp5Al47f+CCG3gmfOcY02Y9sTXqXDkSr5SorCAln oTXNDoPcRZAUszQnIM0g/2vx8cBCuHgvxg2D3M20nxn8wPDaKt8N8P0j9vQe3o4DaH57 8n6mDFjSrm7k7/TYzZfCur8A91eljQb9oCSrGjt0fmekjt/Oc4euMy0J1hB0oyl6wFzg 0zdtWwuHOzifvHunTSby37oUH01ouIJSKefVNOS++/KBrTV5z0I8NidJ9psyb+l9eLNX W0hbme2bZAZ2IMaE4KZJbafeEzK7e6UwP36RQFIa3bd8rv4Dk6ebJUI4ANJ1MRPbd4+y UhnA== Received: by 10.182.31.13 with SMTP id w13mr17413056obh.29.1351213767782; Thu, 25 Oct 2012 18:09:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Thu, 25 Oct 2012 18:09:07 -0700 (PDT) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A1480EDFA@xmb-rcd-x10.cisco.com> From: Lorenzo Colitti Date: Fri, 26 Oct 2012 10:09:07 +0900 Message-ID: To: Arifumi Matsumoto Content-Type: multipart/alternative; boundary=14dae93a148da4f17b04ccebf80d X-System-Of-Record: true X-Gm-Message-State: ALoCoQkbrYMhvIiUzCO/rGPB5JFec0jTKALGqlsOLWVyqhIt8yp9ICu+g3eST1gaWarjqMO+nE7CttyaqDysYHBQiZV/WOuwsU3zffKhus5UZmPxP1rhC9BwrNhmXGaUt2pKVjZs0pXUdeOr8TmQhytQreHCHcxBsqsFVjEBvu6iTiemENFbxK6/2Tl9jOYmRgpIxoHNNI4D Cc: "mif@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [mif] FW: New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 01:09:36 -0000 --14dae93a148da4f17b04ccebf80d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 25, 2012 at 7:26 PM, Arifumi Matsumoto wrote: > So, in other words, this option just depends on the address selection > option. > If it is true, a work that depends on another work can be done separately > in > a separate wg. > Sounds reasonable. > I do not know whether mif is the right place for this proposal, but > generally speaking it is the right place where the scope and motivation > matche best. > I disagree that MIF is the right place. MIF is chartered to deal with multiple interfaces. "Allowing relay agents to modify DHCPv6 requests in flight" and "allowing relay agents to initiate DHCPv6 requests on behalf of clients" has nothing to do with multiple interfaces. --14dae93a148da4f17b04ccebf80d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 25, 2012 at 7:26 PM, Arifumi Matsumoto <arifumi@nttv6.net&= gt; wrote:
So, in other words, this option just depends on the address selection optio= n.
If it is true, a work that depends on another work can be done separately i= n
a separate wg.

Sounds reasonable.
=
=A0
I do not know whether mif is t= he right place for this proposal, but generally=A0speaking it is the right = place where the scope and motivation matche best.

I disagree that MIF is the right place. MI= F is chartered to deal with multiple interfaces. "Allowing relay agent= s to modify DHCPv6 requests in flight" and "allowing relay agents= to initiate DHCPv6 requests on behalf of clients" has nothing to do w= ith multiple interfaces.
--14dae93a148da4f17b04ccebf80d-- From zehn.cao@gmail.com Thu Oct 25 20:28:59 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9C121F86EA for ; Thu, 25 Oct 2012 20:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNUKte2eHh2v for ; Thu, 25 Oct 2012 20:28:58 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5051821F86DB for ; Thu, 25 Oct 2012 20:28:58 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so3635788iec.31 for ; Thu, 25 Oct 2012 20:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=g9vLwp8nJryISi89nug0gH94BpJhRH/2+E064bNoA2Q=; b=SaFaTZARIF7mNH0DebcXIUaYdB07HOgtL6IcVKUEeRdEfbQ3XeXoKJq9IyKs2SOXpq I8lD/8YpdHJLmh465ke87dD8A9AtjOcgPAebz/JrfG1ybkJGVdaT6cS9CkeFgQDbHSA7 mESfxK7lV9WRSbohwGGRHBaykYr/aXNSbTGTaZ9UxfBJ5jKiUZRjj46OmAFwvSmOGgEP HkdUBy0aNL/FzS0mkzBYOwFAqq8E78f6JI1zZQHOJ98IGkbhVuYrMuM56pJSDblj6tw+ m55r/MiD5LUU0JRLQ63/qXQ4vS9dkDjwZmT3kpsWcCcvbFiLMClBQFiz0ifYCGDck7+p PLig== MIME-Version: 1.0 Received: by 10.50.212.8 with SMTP id ng8mr692346igc.64.1351222137828; Thu, 25 Oct 2012 20:28:57 -0700 (PDT) Received: by 10.64.64.102 with HTTP; Thu, 25 Oct 2012 20:28:57 -0700 (PDT) In-Reply-To: <3745_1351079968_5087D820_3745_163_10_81C77F07008CA24F9783A98CFD706F710477F6@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20121015131910.25587.13444.idtracker@ietfa.amsl.com> <3745_1351079968_5087D820_3745_163_10_81C77F07008CA24F9783A98CFD706F710477F6@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Fri, 26 Oct 2012 11:28:57 +0800 Message-ID: From: Zhen Cao To: pierrick.seite@orange.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: mif Subject: Re: [mif] Fwd: I-D Action: draft-cao-mif-srv-dis-ps-00.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 03:28:59 -0000 Hi Pierrick, Thank you very much for you comments, see my response inline. On Wed, Oct 24, 2012 at 7:59 PM, wrote: > > Hi Zhen, > > > > I think, the problem you=92re describing is valid. Did you check Homenet = WG? I remember a presentation describing the Homenet use-cases, and multiho= ming was one of the use-cases. I guess they have a similar problem with ser= vice discovery=85 I remember there was a presentation from Daniel (France Telecom). I would review that as a solution document. > What is a Service domain ? A definition is needed IMHO. will add definition in our slides and revisions. > When reading step 1 in Section 2 (the host send a query to find a servic= e), a question comes immediately to the mind: On which interface the servi= ce discovery request must be sent? Shouldn=92t we have a step 0 =93discover= y of the service discovery server=94 ? =96I guess, it is the problem 1 you= have identified, it leads to requirelent =93Service Directory Service Conf= iguration=94. Right? Just to be sure I understood correctly the logic of th= e I-D=85. Yes, I agree. I will add step zero. > > In step 2, you wrote: Service Request Handling: any entity that receives = the query request should handle the request. I slightly disagree; actually = a service discovery entity is expected to proceed to request concerning the= services from its domain; the service discovery server on the public WiFi = interface cannot handle the requests for 3GPP only service discovery. [cz] I mean it should handle the query. To check if it has such information is also a =93handling=94 in this regards. > In step 4: I do not understand why you add the last statement =93unless i= t is the service domain that has met a problem.=94 [cz] I mean the server is down, e.g., a web server is down. > Problem 2: it seems that it is the same problem than for DNS selection: = some DNS answers are only valid on a given interface. The FQDN which can be= reached on a single interface are expected to be resolved by the DNS serve= r from that interface (e.g. a private 3GPP fqdn is resolved by 3GPP dns ser= vers not by public Wifi DNS servers). [cz] I admit that problem 2 is solvable by the mif-dns solution. But mif-dns solution is limited in that it only solves the problem of the service directory configuration. > Problem 3: this problem should not exist with proper service discovery s= erver configuration (service which access is limited to a given interface i= s resolved by SD servers from that interface) . [cz] in a SRV query, the port contained in the response may be blocked on that interface. This is one of the example where problem 3 exists. The service discovery server could sometimes not that smart, and the management of the discovery server is different from the infrastructure, e.g, host use google public dns as discovery server in its access network. > In conclusion, I agree there is a problem. But the problem is a problem o= f service discovery server selection, just as the DNS server selection.. Th= e figure 2 illustrates very well the problem. What is required to solve the= problem is to be able to request the proper SD server depending on the rea= chability of the service (service which access is limited to a given interf= ace is resolved by SD servers from that interface) . Actually, we have a pr= oblem because SD server are node scoped and cannot be per interface. > [cz] the same thing as above, the discovery server most time do not have full knowledge of the servers and infrastructure information. that's where the concerns arise. > Typo on section 2: s/The serivce discovery process/service discovery proc= ess Thanks for pointing it out. > BR, > > Pierrick > > > > > > De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de Zhe= n Cao > Envoy=E9 : mardi 23 octobre 2012 09:39 > =C0 : mif > Objet : [mif] Fwd: I-D Action: draft-cao-mif-srv-dis-ps-00.txt > > > > Dear All, > > > > This is a new draft on service discovery in a multiple interface environm= ent. > > > > Comments are welcome, thank you in advance. > > > > Best regards, > > cz > > ---------- Forwarded message ---------- > From: > Date: Mon, Oct 15, 2012 at 9:19 PM > Subject: I-D Action: draft-cao-mif-srv-dis-ps-00.txt > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > > Title : Service Discovery in a Multiple Connection Envi= ronment: Problem Statement > Author(s) : Zhen Cao > Filename : draft-cao-mif-srv-dis-ps-00.txt > Pages : 8 > Date : 2012-10-15 > > Abstract: > This document analyzes the problem of service discovery in a multiple > connection environment. A multiple connection environment consists > of multiple-interfaces nodes connecting to multiple networks or > mutliple provisioning domains. Given a type of service a mutliple- > interfaced client is looking for, the discovery progress ought to > return a correct pointer to the service instance that the client is > able to access. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-cao-mif-srv-dis-ps > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-cao-mif-srv-dis-ps-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. From n@arifumi.net Fri Oct 26 02:00:36 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C06521F84FA for ; Fri, 26 Oct 2012 02:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAxS8qeJN7Hr for ; Fri, 26 Oct 2012 02:00:35 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8702521F84F6 for ; Fri, 26 Oct 2012 02:00:35 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3075080vbb.31 for ; Fri, 26 Oct 2012 02:00:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:date:x-google-sender-auth :message-id:subject:from:to:content-type:x-gm-message-state; bh=niJ9MQfAOc3ihj1APU8X5hlLgPKrPqubo2vz+T0j55U=; b=Bvyu3fpGMOfZdlXad0xjWhBoZsjCrGD8HHIXgRIiNHrgTThhUssgPKkPI01L8bZV9I Tk8gmMSQaAjony498Av08IZMquUdZrOtWlHPvNrlvxeL8PkCxW32Jkz/7uC7PJr2pWSj nfmftSB5TtGj43Y9Z7gmiyfhZnj+W9fDyMBSVyOEH682H5vCKfDZCUp6BJcBW1cZM6L3 Z9JUlB1MbqdHyHb4a22B3q8th3wo8kMQwdheuysqII2GOLLyeH7x2hSseLKVn0EUmTGa nrj+6flscp70M49VN58wUFGekBZZw0gPb++mPjR9ciVhJcgvsMWfrMNdKmJk3IxqDGiN l4nw== MIME-Version: 1.0 Received: by 10.52.36.40 with SMTP id n8mr28999270vdj.52.1351242032805; Fri, 26 Oct 2012 02:00:32 -0700 (PDT) Sender: n@arifumi.net Received: by 10.58.178.229 with HTTP; Fri, 26 Oct 2012 02:00:32 -0700 (PDT) X-Originating-IP: [222.147.76.182] Date: Fri, 26 Oct 2012 18:00:32 +0900 X-Google-Sender-Auth: eYjSj0wtdb3-BJYO7MfLdASUZsA Message-ID: From: Arifumi Matsumoto To: "mif@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkIFYqaFRlU6GuCLhFXwiejFi7eVoFYm7ZqYCaeL4K8VoTy08nFA97gDmFwV2LjtDvOU3W3 Subject: [mif] dhcp route option on issue tracker X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 09:00:36 -0000 All, as far as I see the issue tracker site, only the minor or trivial issues are raised about the dhcp route option. http://trac.tools.ietf.org/wg/mif/trac/report/1 Please report an issue to the sie, if you have one. Thanks. From alexandru.petrescu@gmail.com Fri Oct 26 02:21:17 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334D921F84F3 for ; Fri, 26 Oct 2012 02:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.085 X-Spam-Level: X-Spam-Status: No, score=-10.085 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83uXZL2ftqs1 for ; Fri, 26 Oct 2012 02:21:16 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 584C321F84D9 for ; Fri, 26 Oct 2012 02:21:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q9Q9LDPX017213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 26 Oct 2012 11:21:13 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q9Q9LDBH011012 for ; Fri, 26 Oct 2012 11:21:13 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q9Q9L9tQ024255 for ; Fri, 26 Oct 2012 11:21:13 +0200 Message-ID: <508A5606.1090707@gmail.com> Date: Fri, 26 Oct 2012 11:21:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: mif@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] dhcp route option on issue tracker X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 09:21:17 -0000 Hello Arifumi, Thank you for the email. I am trying to udnerstand what is meant by qualifying them as minor and trivial? Some of them have Type as "Enhancement". Also, what do these qualifications mean with respect to progressing the draft? Does it mean they'd supposedly have to be solved in order to progress? (when I created some of them I was wondering the same thing). Additionally, two issues were posted by Ivo Sedlacek " Question to draft-ietf-mif-dhcpv6-route-option-05" on October 24th, 2012. Shall we discuss these 2 issues? Should one upload these 2 issues on the tracker? Thanks and listening to advice, Alex Le 26/10/2012 11:00, Arifumi Matsumoto a écrit : > All, > > as far as I see the issue tracker site, only the minor or trivial > issues are raised about the dhcp route option. > http://trac.tools.ietf.org/wg/mif/trac/report/1 > > Please report an issue to the sie, if you have one. > > Thanks. _______________________________________________ mif mailing > list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif > > From n@arifumi.net Fri Oct 26 02:50:25 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4891D21F84F3 for ; Fri, 26 Oct 2012 02:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fp005DqSy5fi for ; Fri, 26 Oct 2012 02:50:24 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3BD21F84ED for ; Fri, 26 Oct 2012 02:50:24 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2562681lam.31 for ; Fri, 26 Oct 2012 02:50:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=RD+wY6dZ41ZYWXuuITCWgWi6Dtn7Ym8dRzRNocqavRU=; b=atJf3MAMYjuiDNbaS3SwiHjB7/SwO+iDGBZ32PRXeKzAt+pXchaoLQvSQAT/x2wi/o BOjkS7jEzzC3Pdoz7I1fyil9zaNFeNTv0K/0lT/WgTycDAg+ruLhOlTILKI9S9/lGE9G UYDrco/D4B33S5epYj9q74PXH8LX7KmybnLyf6MFQAsPNn7jAfKXGF58QPPZfkaOsP2/ hFmNAeDtD8ft+17ZO/6PRq8EEuZDrjLDs1fvGgDoDbLhrKb0GSvyXGiNhLf+81hHs4zC CXqTvzZq2NuS43bi2nnSUgeva89NffeHwiuihhQqFAyMW+3shkKP3IaiqN8Yquo6rzDL A6sw== MIME-Version: 1.0 Received: by 10.112.30.163 with SMTP id t3mr8824935lbh.56.1351245022968; Fri, 26 Oct 2012 02:50:22 -0700 (PDT) Sender: n@arifumi.net Received: by 10.114.64.16 with HTTP; Fri, 26 Oct 2012 02:50:22 -0700 (PDT) X-Originating-IP: [192.68.248.65] In-Reply-To: <508A5606.1090707@gmail.com> References: <508A5606.1090707@gmail.com> Date: Fri, 26 Oct 2012 18:50:22 +0900 X-Google-Sender-Auth: x7Q9EbkMMkuo5Vc-Cp6u96-tuYE Message-ID: From: Arifumi Matsumoto To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm8ESfGWvgfakWIdSSFWSdadejFHccwdG2fAPNr2Ar6t05wnaFoHb+mTY4wjoT6VcLSpYr/ Cc: mif@ietf.org Subject: Re: [mif] dhcp route option on issue tracker X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 09:50:25 -0000 Alex, first of all, thank you for filing the issues to the site. comments inline. 2012/10/26 Alexandru Petrescu : > Hello Arifumi, > > Thank you for the email. I am trying to udnerstand what is meant by > qualifying them as minor and trivial? Some of them have Type as > "Enhancement". I mean Priority value listed on each issue. > Also, what do these qualifications mean with respect to progressing the > draft? Does it mean they'd supposedly have to be solved in order to > progress? (when I created some of them I was wondering the same thing). This document has passwd WGLC. So the progress should mean IESG review. I think all the issues have to be solved to progess. But, I want to have all the issues posted to the site, and try to work with important ones if we have. > > Additionally, two issues were posted by Ivo Sedlacek " Question to > draft-ietf-mif-dhcpv6-route-option-05" on October 24th, 2012. Shall we > discuss these 2 issues? Should one upload these 2 issues on the tracker? I think we do not need to upload, as far as any disagreement are not raised to my answering comment. Thanks. > > Thanks and listening to advice, > > Alex > > Le 26/10/2012 11:00, Arifumi Matsumoto a =E9crit : >> >> All, >> >> as far as I see the issue tracker site, only the minor or trivial >> issues are raised about the dhcp route option. >> http://trac.tools.ietf.org/wg/mif/trac/report/1 >> >> Please report an issue to the sie, if you have one. >> >> Thanks. _______________________________________________ mif mailing >> list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif >> >> > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From alexandru.petrescu@gmail.com Fri Oct 26 03:03:22 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E83221F8513 for ; Fri, 26 Oct 2012 03:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.092 X-Spam-Level: X-Spam-Status: No, score=-10.092 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qdw+TU4qPZmb for ; Fri, 26 Oct 2012 03:03:21 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id EE63921F8502 for ; Fri, 26 Oct 2012 03:03:20 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q9QA3Jlj006335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 26 Oct 2012 12:03:19 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q9QA3Jqd029085 for ; Fri, 26 Oct 2012 12:03:19 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q9QA3FDj018803 for ; Fri, 26 Oct 2012 12:03:19 +0200 Message-ID: <508A5FE3.3050407@gmail.com> Date: Fri, 26 Oct 2012 12:03:15 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: mif@ietf.org References: <39B5E4D390E9BD4890E2B3107900610101A1DC@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B3107900610101A1DC@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Question to draft-ietf-mif-dhcpv6-route-option-05 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 10:03:22 -0000 Le 24/10/2012 14:34, Ivo Sedlacek a écrit : > Hello, > > draft-ietf-mif-dhcpv6-route-option-05 states in section 7.1: > > Metric field (available in previous version of this draft) has been > > replaced with 2-bit preference field that is in line with RIO > > information. > > Issue1: > > the section 4 states: > > In terms of the high level operation of the solution defined in this > > draft, a DHCPv6 client interested in obtaining routing information > > request the route options using the DHCPv6 Option Request Option > > (ORO) sent to a server. A Server, when configured to do so, provides > > the requested route information as part of a nested options structure > > covering; the next-hop address; the destination prefix;_>>the route_ > > _ metric<<;_ any additional options applicable to the destination or next- > > hop. > > Given the statement in section 7.1, is "the route metric" above correct > or is it an obsolete text? I agree, I wonder the same thing as you. In implementation, when inserting a routing entry in a routing table some times there is a need of a 'metric' field. Often that is valued to 1 or 0, when no dynamic routing protocol is used. For default route configuration, this 'metric' field in routing table is not of utmost importance because often it is assumed as 1 (the next-hop is right next to it). But whether or not the 'metric' field should be offered by DHCP Route-Option is debateable? > Issue2: > > section 5.2 states: > > .... > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | OPTION_RT_PREFIX | option-len | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Route lifetime | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Prefix-Length |Resvd|Prf|Resvd| | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > | Prefix | > > | (up to 16 octets) | > > | | > > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > . . > > . RT_PREFIX sub-options . > > . . > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 3: Route Prefix Option Format > > > > .... > > Metric: Route Metric. 8-bit signed integer. The Route Metric > > indicates whether to prefer the next hop associated with > > this prefix over others, when multiple identical prefixes > > (for different next hops) have been received. > > .... > > > > There is no "Metric" field shown in the Figure 3. I agree and I wonder the same as you? Also, the meaning of the "metric" as suggested above - prefer a next-hop over another - is relatively debateable. I thought about this metric as more of a hint to a dynamic routing protocol which may be in place to calculate shorter routes in terms of hopcount. On another hand, that mentioned 'preference' signification of 'metric' is probably more of what RFC4191 calls also "preference", instead of 'metric'. I wonder about the authors' intention about this 'metric' field. Alex > > Thanks for clarification. > > Kind regards > > Description: Description: line > > *IVO SEDLACEK * > > > Ericsson > Mobile +420 608 234 709 > ivo.sedlacek@ericsson.com > www.ericsson.com > > > > Description: Description: http://www.ericsson.com/ > > > This Communication is Confidential. We only send and receive email on > the basis of the terms set out at www.ericsson.com/email_disclaimer > > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From trac+mif@trac.tools.ietf.org Wed Oct 31 23:53:25 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41E521F851E for ; Wed, 31 Oct 2012 23:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKVsHDpujES4 for ; Wed, 31 Oct 2012 23:53:24 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEDE21F8514 for ; Wed, 31 Oct 2012 23:53:24 -0700 (PDT) Received: from localhost ([127.0.0.1]:52566 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TToe2-0007Hk-CW; Thu, 01 Nov 2012 07:52:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com X-Trac-Project: mif Date: Thu, 01 Nov 2012 06:52:50 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mif/trac/ticket/9 Message-ID: <051.749484748d0cabe9f80637168229f52b@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com, mif@ietf.org X-SA-Exim-Mail-From: trac+mif@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arifumi@nttv6.net, sarikaya@ieee.org, suntao@chinamobile.com, tomasz.mrugalski@gmail.com, wdec@cisco.com Resent-Message-Id: <20121101065324.6AEDE21F8514@ietfa.amsl.com> Resent-Date: Wed, 31 Oct 2012 23:53:24 -0700 (PDT) Resent-From: trac+mif@trac.tools.ietf.org Cc: mif@ietf.org Subject: [mif] #9: violates RFC 5505 section-3.2.1 (fate sharing) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 06:53:25 -0000 #9: violates RFC 5505 section-3.2.1 (fate sharing) From http://tools.ietf.org/html/rfc5505#section-3.2.1 : "For example, learning default gateways via Router Advertisements provides perfect fate sharing. That is, gateway addresses can be obtained if and only if they can actually be used." "Similar limitations exist for other server-based configuration mechanisms such as DHCP. Typically DHCP servers do not check for the liveness of the configuration information they provide, and do not discover new configuration information automatically. As a result, there is no guarantee that configuration information will be current." -- -------------------------+------------------------------------------------- Reporter: ek@… | Owner: draft-ietf-mif-dhcpv6-route- Type: defect | option@… Priority: blocker | Status: new Component: dhcpv6 | Milestone: -route-option | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: mif From trac+mif@trac.tools.ietf.org Wed Oct 31 23:58:52 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E471F21F853D for ; Wed, 31 Oct 2012 23:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kA7lNgbJQYvd for ; Wed, 31 Oct 2012 23:58:52 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3CC21F853C for ; Wed, 31 Oct 2012 23:58:52 -0700 (PDT) Received: from localhost ([127.0.0.1]:53430 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTojU-0001Ac-NY; Thu, 01 Nov 2012 07:58:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com X-Trac-Project: mif Date: Thu, 01 Nov 2012 06:58:28 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mif/trac/ticket/10 Message-ID: <051.d3955dd3f1342b89dabf4eb81ebfd5d0@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com, mif@ietf.org X-SA-Exim-Mail-From: trac+mif@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arifumi@nttv6.net, sarikaya@ieee.org, suntao@chinamobile.com, tomasz.mrugalski@gmail.com, wdec@cisco.com Resent-Message-Id: <20121101065852.5D3CC21F853C@ietfa.amsl.com> Resent-Date: Wed, 31 Oct 2012 23:58:52 -0700 (PDT) Resent-From: trac+mif@trac.tools.ietf.org Cc: mif@ietf.org Subject: [mif] #10: walled garden use case #1 is invalid as a motivation X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 06:58:53 -0000 #10: walled garden use case #1 is invalid as a motivation Quoting from IAB document http://tools.ietf.org/html/rfc3002 section 4.2.1 : "It was strongly recommended that independent of the ubiquity of the 'walled garden' deployment scenario that protocols and architectural decisions should not target this model. To continue the success of Internet protocols at operating across a highly diverse and heterogeneous environment the IETF must continue to foster the adoption of an 'open model'." As such, I believe that the IETF should not permit walled garden scenarios to be presented as valid motivations. -- -------------------------+------------------------------------------------- Reporter: ek@… | Owner: draft-ietf-mif-dhcpv6-route- Type: defect | option@… Priority: major | Status: new Component: dhcpv6 | Milestone: -route-option | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: mif From trac+mif@trac.tools.ietf.org Wed Oct 31 23:59:40 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D283B21F853D for ; Wed, 31 Oct 2012 23:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMs4L7-0aWYr for ; Wed, 31 Oct 2012 23:59:40 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 44BFC21F853C for ; Wed, 31 Oct 2012 23:59:40 -0700 (PDT) Received: from localhost ([127.0.0.1]:53517 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTokY-0001DD-0l; Thu, 01 Nov 2012 07:59:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com X-Trac-Project: mif Date: Thu, 01 Nov 2012 06:59:34 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mif/trac/ticket/11 Message-ID: <051.4a9007177106b70fb92661cae8264b5e@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com, mif@ietf.org X-SA-Exim-Mail-From: trac+mif@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arifumi@nttv6.net, sarikaya@ieee.org, suntao@chinamobile.com, tomasz.mrugalski@gmail.com, wdec@cisco.com Resent-Message-Id: <20121101065940.44BFC21F853C@ietfa.amsl.com> Resent-Date: Wed, 31 Oct 2012 23:59:40 -0700 (PDT) Resent-From: trac+mif@trac.tools.ietf.org Cc: mif@ietf.org Subject: [mif] #11: walled garden use case #5 is invalid as a motivation X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 06:59:41 -0000 #11: walled garden use case #5 is invalid as a motivation Quoting from IAB document http://tools.ietf.org/html/rfc3002 section 4.2.1 : "It was strongly recommended that independent of the ubiquity of the 'walled garden' deployment scenario that protocols and architectural decisions should not target this model. To continue the success of Internet protocols at operating across a highly diverse and heterogeneous environment the IETF must continue to foster the adoption of an 'open model'." As such, I believe that the IETF should not permit walled garden scenarios to be presented as valid motivations. -- -------------------------+------------------------------------------------- Reporter: ek@… | Owner: draft-ietf-mif-dhcpv6-route- Type: defect | option@… Priority: major | Status: new Component: dhcpv6 | Milestone: -route-option | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: mif