From nobody Wed Oct 1 01:17:33 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF931A916F for ; Wed, 1 Oct 2014 01:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.086 X-Spam-Level: X-Spam-Status: No, score=-5.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ7WUeAW0AEY for ; Wed, 1 Oct 2014 01:17:29 -0700 (PDT) Received: from mx1.nominet.org.uk (mx1.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 346031A8828 for ; Wed, 1 Oct 2014 01:17:28 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=iZVHjdf/vznHOJimcZV8P+epOA648pgaQyQeOBfY89PDsPB11bQ7fa6I 22ztCa8GmkM2Il3/TOuqgJArVOEuvHzvls0ZCjBTwXB26qYkjO4pAjPsI 6SUZYBu7eK9+5y5WJ53/OjHmHXPFzlaqdz2a1DRAsnHTi1wJNTZE+OFlJ GnhIg/y8Y8FhPnlQZRofJlhXgZTe2DZHTNoVE5CtJR0OII1JP6bQ8AKCS rbjSOxoG1KH/Cl+rWsu0kQbtXUsFn; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1412151449; x=1443687449; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=g3Cim5qKifytfpGKDiaWLMwAxULw0mtCqPktMRImeBY=; b=A9hlzokiUIxUL2+Sw4dMQDbgvotlm87k7AIE4q06WjbMNHDvGwUynmLb oUgwfD7RjXLi4eYr7ZTOniYq7tItvYyp2IfteEPz110LHengVkroGbcuk /T17xPQGiME4hSVZPmZJcq8hR0gGpjR+wWBGWmkTS0kz9IAC/GvBd0bSz iYo2IvQWIk1vml5bDoP/kW5MW9i6r5kuIwsiRckD4jTYaqKSd0OyveP1r 1k1Vg4h3AT00XNiuKrfAd4hJhe0Qs; X-IronPort-AV: E=Sophos;i="5.04,630,1406588400"; d="scan'208";a="13468577" X-IPAS-Result: AsArANK3K1TV+MWR/2dsb2JhbABggmsjAYETHKFqmEmPeIhqFgEBeoQKOhk4AT5CJwSIUgOZQ6VMk1uBHQWzJoNjgjSBAgEBAQ Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 01 Oct 2014 09:17:27 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%16]) with mapi id 14.03.0181.006; Wed, 1 Oct 2014 09:17:26 +0100 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: reminder - IETF91 important dates Thread-Index: AQHP3VAiHDNogt1400yv8soAjBt54w== Date: Wed, 1 Oct 2014 08:17:26 +0000 Message-ID: <2011BE30-849E-444B-9539-78640FF13CF8@nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/RyRnzwfjMq2-fuKUpigfjmRAIgM Subject: [homenet] reminder - IETF91 important dates X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 08:17:31 -0000 I'd like to remind the group that the submission deadline cutoff for all dr= afts including -00 is 23:59 UTC on Monday October 27th. If you have new drafts or updates to bring to the group, it would be apprec= iated if we could get them sooner rather than later so that the group has t= ime to digest and discuss them in advance of our face-to-face session in Ho= nolulu. Similarly, if you would like agenda time at that meeting please let the cha= irs know. thanks, Ray and Mark From nobody Wed Oct 1 06:21:05 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730441A064C; Wed, 1 Oct 2014 06:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyG5FkS8SsiE; Wed, 1 Oct 2014 06:20:48 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E29B1A038E; Wed, 1 Oct 2014 06:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=467; q=dns/txt; s=iport; t=1412169648; x=1413379248; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=9Vkyaik0kHk2vgd5TRAphKGUZxiT/IUfpx86Hd1UGEY=; b=REzXAVbGo6IEm646htpptRdGZNw/oawlNbeo3k0op++pnm2jemzpHOtD WcoSlK8WRJuVroqeukir1a41DRJrDe1/kor7bffxVjcTVRZkiGHa1+5N6 k/BFUT1PLwULPjllCNlMm6ckXdYePUGJKLGG/q4MToLTRMoXvmwtsR41f o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEHANr+K1StJssW/2dsb2JhbABgg2FayjuHQwEEAwKBIwF7hEJAATwWGAMCAQIBWAEHAQGIOg2+GBiQJh2ENQEElimHCoFlhXOOG4NlO4J5AQEB X-IronPort-AV: E=Sophos;i="5.04,632,1406592000"; d="scan'208";a="196028725" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 01 Oct 2014 13:20:46 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s91DKkYu012074; Wed, 1 Oct 2014 13:20:46 GMT Message-ID: <542BFFAE.1080105@cisco.com> Date: Wed, 01 Oct 2014 15:20:46 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: homenet@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/y8BA3jvNu4ZpAekVjvoYJ8tXmDU Cc: "anima@ietf.org" Subject: [homenet] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 13:20:51 -0000 Dear all, Based on the previous UCAN BoF, we are considering having an ANIMA WG: Autonomic Networking Integrated Model and Approach This is now a proposed charter, under consideration by the IESG. This is your chance to provide feedback on http://datatracker.ietf.org/wg/anima/charter/ Note also that a BoF has been requested, just in case. Since HOMENET was mentioned during the UCAN BoF, I thought of double-checking with you guys. Regards, Benoit From SRS0=Td+t=6Y=darou.fr=pierre.pfister@bounces.m4x.org Wed Oct 1 06:58:15 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC08A1A19F7; Wed, 1 Oct 2014 06:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Fm_OxD62_Me; Wed, 1 Oct 2014 06:58:13 -0700 (PDT) Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C122F1A8898; Wed, 1 Oct 2014 06:58:12 -0700 (PDT) Received: from dhcp-10-61-104-225.cisco.com (173-38-208-170.cisco.com [173.38.208.170]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id C3D5D1408EFA2; Wed, 1 Oct 2014 15:58:09 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E01FB9B2-0178-4AFE-8DDC-09D744143B3B" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Pierre Pfister In-Reply-To: <542BFFAE.1080105@cisco.com> Date: Wed, 1 Oct 2014 15:58:08 +0200 Message-Id: <9B8FD45E-3C1C-4CA3-A754-430B2BFC9CAE@darou.fr> References: <542BFFAE.1080105@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1878.6) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Wed Oct 1 15:58:10 2014 +0200 (CEST)) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/0Nn45Q_tK9Pc_B3Jf4HH8Qydl3Q Cc: homenet@ietf.org, "anima@ietf.org" Subject: Re: [homenet] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 13:58:53 -0000 --Apple-Mail=_E01FB9B2-0178-4AFE-8DDC-09D744143B3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Benoit, Looks like ANIMA=92s goals are quite similar to Homenet=92s indeed. Please allow me to comment the charter. 1. Why would you put the =91negociation protocol=92 in the charter (even = last call in the milestones !) ? It seems fair to me that discussions = about what should be the approach and solution happen after the WG = creation, isn=92t it ? 2. "A solution for distributed IPv6 prefix management within a network." = -> Please have a look to HNCP (draft-ietf-homenet-hncp) + Prefix = Assignment Algorithm (draft-ietf-homenet-prefix-assignement). Ha, and we = have running open-source code for all this as well: = https://github.com/sbyx/hnetd. 3. "A solution for always-on, data plane independent connectivity = between network elements (i.e., stable in the case of = mis-configurations)." Sure the =91data plane independent=92 makes it a = little bit more buzzy. But in the end this pretty much looks like the = problem routing protocols are made to solve (The 'mis-configurations=92 = part is more about point 2.). Regards, - Pierre Le 1 oct. 2014 =E0 15:20, Benoit Claise a =E9crit : > Dear all, >=20 > Based on the previous UCAN BoF, we are considering having an ANIMA WG: = Autonomic Networking Integrated Model and Approach > This is now a proposed charter, under consideration by the IESG. > This is your chance to provide feedback on = http://datatracker.ietf.org/wg/anima/charter/ > Note also that a BoF has been requested, just in case. > Since HOMENET was mentioned during the UCAN BoF, I thought of = double-checking with you guys. >=20 > Regards, Benoit >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail=_E01FB9B2-0178-4AFE-8DDC-09D744143B3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hello = Benoit,

Looks like ANIMA=92s goals are quite = similar to Homenet=92s indeed.
Please allow me to comment the = charter.

1. Why would you put the =91negociation = protocol=92 in the charter (even last call in the milestones !) ? It = seems fair to me that discussions about what should be the approach and = solution happen after the WG creation, isn=92t it = ?

2. "A solution for = distributed IPv6 prefix management within a network." = -> Please have a look to HNCP = (draft-ietf-homenet-hncp) + Prefix Assignment Algorithm = (draft-ietf-homenet-prefix-assignement). Ha, and we have running = open-source code for all this as well: https://github.com/sbyx/hnetd.<= /div>

3. "A solution for = always-on, data plane independent connectivity between network = elements (i.e., stable = in the case of mis-configurations)." Sure the =91data = plane independent=92 makes it a little bit more buzzy. But in the end = this pretty much looks like the problem routing protocols are made to = solve (The 'mis-configurations=92 part is more about point = 2.).


Regards,

- = Pierre


Le 1 oct. 2014 =E0 15:20, = Benoit Claise <bclaise@cisco.com> a =E9crit = :

Dear all,

Based on the previous UCAN BoF, we are = considering having an ANIMA WG: Autonomic Networking Integrated Model = and Approach
This is now a proposed charter, under consideration by = the IESG.
This is your chance to provide feedback on http://datatracker.= ietf.org/wg/anima/charter/
Note also that a BoF has been = requested, just in case.
Since HOMENET was mentioned during the UCAN = BoF, I thought of double-checking with you guys.

Regards, = Benoit





____________________________________________= ___
homenet mailing list
homenet@ietf.org
https://www.ietf.or= g/mailman/listinfo/homenet

= --Apple-Mail=_E01FB9B2-0178-4AFE-8DDC-09D744143B3B-- From nobody Wed Oct 1 09:27:17 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8261ACE84; Wed, 1 Oct 2014 09:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzrMegtsxZFe; Wed, 1 Oct 2014 09:27:13 -0700 (PDT) Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.234]) by ietfa.amsl.com (Postfix) with ESMTP id 93B781A1A48; Wed, 1 Oct 2014 09:27:12 -0700 (PDT) Received: from kosame.lan (84.248.80.109) by jenni1.inet.fi (8.5.142.08) (authenticated as stenma-47) id 54194991014411A3; Wed, 1 Oct 2014 19:27:05 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Markus Stenberg In-Reply-To: <542BFFAE.1080105@cisco.com> Date: Wed, 1 Oct 2014 19:27:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <542BFFAE.1080105@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/atiM-KKqRqmnodHqf58rd7yLrg0 Cc: homenet@ietf.org, Markus Stenberg , "anima@ietf.org" Subject: Re: [homenet] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 16:27:14 -0000 On 1.10.2014, at 16.20, Benoit Claise wrote: > Based on the previous UCAN BoF, we are considering having an ANIMA WG: = Autonomic Networking Integrated Model and Approach > This is now a proposed charter, under consideration by the IESG. > This is your chance to provide feedback on = http://datatracker.ietf.org/wg/anima/charter/ > Note also that a BoF has been requested, just in case. > Since HOMENET was mentioned during the UCAN BoF, I thought of = double-checking with you guys. TL;DR: Please either add homenet (and solutions already in the WG) to = the WG goals, or drop IoT too and just focus on enterprise. Looking at the milestones, I am very curious about lack of requirements = or architecture work before promoting solutions and even WGLCing them.=20= Notably, adoption of a solution (discovery+negotiation protocol) before = adoption of use cases seems like putting cart before the horse. It is not also clear to me how well the suitability of the solution has = been evaluated. For implementation of some autonomic, distributed = algorithms, point-to-point negotiation protocol such as the suggested = solution is far from optimal. In case of homenet, we moved from = hierarchical DHCPv6 PD (point-to-point hierarchy) to a distributed = algorithm (draft-ietf-homenet-prefix-assignment*) which was result of = over two years of draft updates, academic proving of correctness etc.=20 Also, while dropping homenet from list of target things is _a_ way to = solve the conflict that we already have autonomic solution for that = particular problem which works (it was mentioned there before in e.g. = IETF 90 not-quite-WG-forming BoF), even better would be to have a = general solution that _also_ works in a homenet. Especially as IoT is = just specialized type of homenet, I assume, although it is covered only = by one mention in the whole charter (and the rest does not seem very IoT = oriented). Looking at the solutions, from homenet developer / draft writer point of = view, I would welcome a general trust bootstrapping framework. I am not = convinced by the current solution draft for that (it assumes too many = components for a home network case at least). A lot of the other things = seem somewhat enterprise-y (control plane with IPsec, own routing = protocol and ULAs? Not in IoT device at least, nor probably in = constrained homenet router), or just unsuitable, such as the negotiation = protocol that does not seem like a good fit for distributed decision = making which is usually the key thing in autonomic networking.=20 Cheers, -Markus From nobody Wed Oct 1 12:25:51 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E211A802E; Wed, 1 Oct 2014 12:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj_J9Zj4vmTI; Wed, 1 Oct 2014 12:25:41 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23501A701F; Wed, 1 Oct 2014 12:25:41 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id kq14so794178pab.12 for ; Wed, 01 Oct 2014 12:25:41 -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=A87ZD4irf5AFdehghImKDmDtkDFd+7bePKezwv49gvs=; b=K0KW773hAIE5kLzVMde5hKvzGC3BNNgsGLzPx3aQaHYHhMBIxZz1IinPuB8zLUXUJn KyHj5iWwC0NiItnjz4EIDQoAkC4MzKEbzxXdS+/RHFxoW4bOdtzmEpOZ4FbYgKZtT3oB O1V3v69+xzk5csvcag7ZahQfbvzk+QOHRKWm5fukSmktHKA9qGfGu7JTuGt49/r/JYXZ /wqyVvLnhViJ+rgi1j4NHOuLvrzy7Lrj1MbOzCukQlu2DZqc4EcVGeZLGUzpv1S4A0mG c4/qksEkBUSliVUc66QDWe4kOLhVdy+cDcZv3QYXfyDcjRhorWJBdHxcoLJPSgOtT7ia 8yeg== X-Received: by 10.70.10.100 with SMTP id h4mr18364486pdb.162.1412191541436; Wed, 01 Oct 2014 12:25:41 -0700 (PDT) Received: from [192.168.178.23] (89.199.69.111.dynamic.snap.net.nz. [111.69.199.89]) by mx.google.com with ESMTPSA id ja2sm1620054pbb.82.2014.10.01.12.25.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Oct 2014 12:25:40 -0700 (PDT) Message-ID: <542C5536.3030507@gmail.com> Date: Thu, 02 Oct 2014 08:25:42 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pierre Pfister References: <542BFFAE.1080105@cisco.com> <9B8FD45E-3C1C-4CA3-A754-430B2BFC9CAE@darou.fr> In-Reply-To: <9B8FD45E-3C1C-4CA3-A754-430B2BFC9CAE@darou.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/tReR-wou3qmgFTt4aH-PY6PKWtM Cc: Benoit Claise , homenet@ietf.org, "anima@ietf.org" Subject: Re: [homenet] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 19:25:48 -0000 Pierre, On 02/10/2014 02:58, Pierre Pfister wrote: > Hello Benoit, >=20 > Looks like ANIMA=E2=80=99s goals are quite similar to Homenet=E2=80=99s= > indeed.=20 Except that homenet has a limited scope and is well advanced in its work. > Please allow me to comment the charter. >=20 > 1. Why would you put the =E2=80=98negociation protocol=E2=80=99 in the > charter (even last call in the milestones !) ? It seems fair > to me that discussions about what should be the approach and > solution happen after the WG creation, isn=E2=80=99t it ? Not really. The details are all to be discussed of course, but the concept is fundamental to autonomics: devices talk to each other rather than receiving instructions from above. (As Rene Struik has pointed out, there is another way to look at it, state synchronization, but that's largely a difference of terminology.) >=20 > 2. "A solution for distributed IPv6 prefix management within > a network." -> Please have a look to HNCP > (draft-ietf-homenet-hncp) + Prefix Assignment Algorithm > (draft-ietf-homenet-prefix-assignement). Ha, and we have > running open-source code for all this as well: > https://github.com/sbyx/hnetd. Yes, in the homenet context. It's a bit different in the carrier context. What we are really after is a general mechanism for the future. If we miss the homenet boat, that's our fault for starting late. There is a lot to learn from homenet, in my opinion. >=20 > 3. "A solution for always-on, data plane independent > connectivity between network elements (i.e., stable in the > case of mis-configurations)." Sure the =E2=80=98data plane > independent=E2=80=99 makes it a little bit more buzzy. But in the end > this pretty much looks like the problem routing protocols are > made to solve (The 'mis-configurations=E2=80=99 part is more about > point 2.). Yes, for the problem that routing protocols solve, they do a good job. But we are talking about all the problems that routing protocols don't solve. Brian >=20 >=20 > Regards, >=20 > - Pierre >=20 >=20 > Le 1 oct. 2014 =C3=A0 15:20, Benoit Claise a > =C3=A9crit : >=20 >> Dear all, >>=20 >> Based on the previous UCAN BoF, we are considering having >> an ANIMA WG: Autonomic Networking Integrated Model and >> Approach This is now a proposed charter, under >> consideration by the IESG. This is your chance to provide >> feedback on http://datatracker.ietf.org/wg/anima/charter/=20 >> Note also that a BoF has been requested, just in case.=20 >> Since HOMENET was mentioned during the UCAN BoF, I thought >> of double-checking with you guys. >>=20 >> Regards, Benoit >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ homenet >> mailing list homenet@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/homenet >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 >=20 > _______________________________________________ homenet > mailing list homenet@ietf.org=20 > https://www.ietf.org/mailman/listinfo/homenet From nobody Wed Oct 1 12:44:53 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6541A8782; Wed, 1 Oct 2014 12:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ST4Nt3ZXWObT; Wed, 1 Oct 2014 12:44:50 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E971A1AD3; Wed, 1 Oct 2014 12:44:50 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id ft15so764829pdb.2 for ; Wed, 01 Oct 2014 12:44:50 -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=NSiytEDtbRF2hwfdGt6rtplaHbvYs3Kkfx+BZPLdt3c=; b=Wgs70QiriRlDSId3/U0Ebu4EP+A/340xg86BIhuUeNTckN8hTlxV7xugQqr2EtvDSr 0t/wRGUiSXdhqiWmtODjwDIVDTf0r+OTiPi/00gSugcAjwgzy0oFUOWoNGTSzjpNWWJ1 agsCVO/E/fTaONsqVhhurx1mx6fx2hqi+1z4Cp/fXSZtcifdNtL5SqIZfaASfY/XbYrU uO0sCeOvZrDSAjHYGjTZSlJalQ8u6tIGmz4o8WmOemmbmy0xbIEeTtiGxUomuvJTcCbM lLDbAE+q6Y3mHBGcixDmXa8E/NCkqKA0ASEsr+CJFHmM+Js1Ih18JP1mvE/rWDFz71T6 1hQw== X-Received: by 10.70.129.136 with SMTP id nw8mr14540791pdb.128.1412192690218; Wed, 01 Oct 2014 12:44:50 -0700 (PDT) Received: from [192.168.178.23] (89.199.69.111.dynamic.snap.net.nz. [111.69.199.89]) by mx.google.com with ESMTPSA id yp10sm1744859pac.18.2014.10.01.12.44.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Oct 2014 12:44:49 -0700 (PDT) Message-ID: <542C59B3.10700@gmail.com> Date: Thu, 02 Oct 2014 08:44:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Markus Stenberg References: <542BFFAE.1080105@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Tu1aG0zRdKGpzRpDbdmd6xT2WWg Cc: Benoit Claise , homenet@ietf.org, "anima@ietf.org" Subject: Re: [homenet] [Anima] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 19:44:52 -0000 Markus, On 02/10/2014 05:27, Markus Stenberg wrote: > On 1.10.2014, at 16.20, Benoit Claise > wrote: >> Based on the previous UCAN BoF, we are considering having >> an ANIMA WG: Autonomic Networking Integrated Model and >> Approach This is now a proposed charter, under >> consideration by the IESG. This is your chance to provide >> feedback on http://datatracker.ietf.org/wg/anima/charter/ >> Note also that a BoF has been requested, just in case. >> Since HOMENET was mentioned during the UCAN BoF, I thought >> of double-checking with you guys. > > TL;DR: Please either add homenet (and solutions already in > the WG) to the WG goals, or drop IoT too and just focus on > enterprise. Personal comments on this: 1) One reason for not stating homenet as part of the scope is that we do not want to interfere with the current progress in homenet. Personally I think there is a lot to learn from homenet, but as I just said to Pierre, we are too late to affect homenet's choices. I will be delighted if the results can be applied to homenets in future, of course. 2) I am also a little nervous about the IoT reference in the charter. We haven't yet seen a use case description that would apply to IoT (which has IMHO a much broader scope than home networks, e.g. building services.) I think the initial focus is indeed on enterprise and carrier networks where the OPEX pain is greatest, but we should not artificially limit the applicability either. > > Looking at the milestones, I am very curious about lack of > requirements or architecture work before promoting solutions > and even WGLCing them. There are the existing NMRG documents and there will be an overview document, but we are following quite specific direction from the ADs about this. > Notably, adoption of a solution (discovery+negotiation > protocol) before adoption of use cases seems like putting > cart before the horse. Again, we are following direction from the ADs. > It is not also clear to me how well the suitability of the > solution has been evaluated. For implementation of some > autonomic, distributed algorithms, point-to-point negotiation > protocol such as the suggested solution is far from optimal. > In case of homenet, we moved from hierarchical DHCPv6 PD > (point-to-point hierarchy) to a distributed algorithm > (draft-ietf-homenet-prefix-assignment*) which was result of > over two years of draft updates, academic proving of > correctness etc. There is a subtle point here. The idea is to produce generic components that do *not* imply specific autonomic algorithms. If we do it correctly, those components will support either a top down or a distributed mechanism or even a blend of the two approaches. So actually the solution choices come later: we don't have to decide in advance between top-down and peer-to-peer. > Also, while dropping homenet from list of target things is > _a_ way to solve the conflict that we already have autonomic > solution for that particular problem which works (it was > mentioned there before in e.g. IETF 90 not-quite-WG-forming > BoF), even better would be to have a general solution that > _also_ works in a homenet. If we were having this discussion 5 years ago, I would agree. But you homenet guys are ahead of us. > Especially as IoT is just > specialized type of homenet, I assume, As above - I don't think that's right; IoT is much broader. > although it is covered > only by one mention in the whole charter (and the rest does > not seem very IoT oriented). So should we say in the charter that the scope is everything but the initial focus is enterprise and carrier? > > Looking at the solutions, from homenet developer / draft > writer point of view, I would welcome a general trust > bootstrapping framework. I am not convinced by the current > solution draft for that (it assumes too many components for a > home network case at least). A lot of the other things seem > somewhat enterprise-y (control plane with IPsec, own routing > protocol and ULAs? Not in IoT device at least, nor probably > in constrained homenet router), or just unsuitable, such as > the negotiation protocol that does not seem like a good fit > for distributed decision making which is usually the key > thing in autonomic networking. That means we have explained the negotiation idea badly. It is not top-down negotiation like draft-boucadair-network-automation-requirements. It is peer to peer with top-down as a special case. Thanks Brian From nobody Wed Oct 1 13:04:30 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36691A701E; Wed, 1 Oct 2014 13:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S05WTm0frwSO; Wed, 1 Oct 2014 13:04:23 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18C01A700C; Wed, 1 Oct 2014 13:04:23 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id rl12so1145878iec.3 for ; Wed, 01 Oct 2014 13:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=w4W35Ngo4JEMa4ZNloFfvoME08n8ixzhJZhoVoriQyE=; b=Ty7ldY1J+jODWn/kqfvItqrqx24e+ZMYZjqDl1WTwt9G7BpsUI2EgN+y5QWj8BjDsP DUJIiRIkSmdJLS2CJhdLQDYPve6pKeOtvmtCe8CEAoFVr8eaY9m1r0wC4NbV5HQdkgSc g4RHP1hMlaC7iAjF0L7d2Mpl7QXhjOstO/1opege00JgixTpMv1RQ1yaw0wGZ8B0hyLh DlM2e+SSU0E8ovd4U7UwQysgf21Dl9sg5dgVII69rQMk/Xsh3QK+qMcGvbenL3IMYFXW Hsyg4QPJ1M9oDB2/rPx7MEjKshiOc0D7zpZDP2zl52/Okv4+kmDOzkzeDtTs8AV/AQs8 TkOQ== X-Received: by 10.50.112.67 with SMTP id io3mr23192749igb.37.1412193863109; Wed, 01 Oct 2014 13:04:23 -0700 (PDT) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id an1sm2118795igc.7.2014.10.01.13.04.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Oct 2014 13:04:22 -0700 (PDT) Message-ID: <542C5E45.5010101@gmail.com> Date: Wed, 01 Oct 2014 16:04:21 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Brian E Carpenter , Markus Stenberg References: <542BFFAE.1080105@cisco.com> <542C59B3.10700@gmail.com> In-Reply-To: <542C59B3.10700@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/BJKZkPc9ER6Y-ui3L2F5hYCKoi4 Cc: Benoit Claise , homenet@ietf.org, "anima@ietf.org" Subject: Re: [homenet] [Anima] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 20:04:26 -0000 Dear colleagues: I think it would be a mistake not to consider highly constrained networks= and devices at first. If one would like to get anywhere close to 30-50 b= illion interconnected objects (the rosy marketing numbers by Cisco and In= tel referenced everywhere), there is an absolute requirement to make trus= t lifecycle management and network management overhead virtually disappea= r, without the need for human intervention, except in exceptional cases. = Without almost zero cost over the *entire* lifecycle of a device, while a= t the same time assuring a mix of ease of use - flexibility - security, f= orecasted internet of things type deployments figures may never materiali= ze. Any solution direction that would not consider foremost the constrain= ts of the deployment category that will soon outnumber all others should = be discouraged. If one closely examines and designs for the nimble object= s in the universe, it would obviously also fit for the less nimble; the o= ther way around, this does not necessarily hold. As argued before, I do agree with comments that solid footing for the eff= ort needs more work (which, I think, has been echoed by the group during = conf calls and by the AD). Best regards, Rene =3D=3D So should we say in the charter that the scope is everything but the init= ial focus is enterprise and carrier? On 10/1/2014 3:44 PM, Brian E Carpenter wrote: > Markus, > > On 02/10/2014 05:27, Markus Stenberg wrote: >> On 1.10.2014, at 16.20, Benoit Claise >> wrote: >>> Based on the previous UCAN BoF, we are considering having >>> an ANIMA WG: Autonomic Networking Integrated Model and >>> Approach This is now a proposed charter, under >>> consideration by the IESG. This is your chance to provide >>> feedback on http://datatracker.ietf.org/wg/anima/charter/ >>> Note also that a BoF has been requested, just in case. >>> Since HOMENET was mentioned during the UCAN BoF, I thought >>> of double-checking with you guys. >> TL;DR: Please either add homenet (and solutions already in >> the WG) to the WG goals, or drop IoT too and just focus on >> enterprise. > Personal comments on this: > > 1) One reason for not stating homenet as part of the scope is > that we do not want to interfere with the current progress in > homenet. Personally I think there is a lot to learn from > homenet, but as I just said to Pierre, we are too late to affect > homenet's choices. I will be delighted if the results can be > applied to homenets in future, of course. > > 2) I am also a little nervous about the IoT reference in the > charter. We haven't yet seen a use case description that would > apply to IoT (which has IMHO a much broader scope than home > networks, e.g. building services.) > > I think the initial focus is indeed on enterprise and carrier > networks where the OPEX pain is greatest, but we should not > artificially limit the applicability either. > >> Looking at the milestones, I am very curious about lack of >> requirements or architecture work before promoting solutions >> and even WGLCing them. > There are the existing NMRG documents and there will be an > overview document, but we are following quite specific direction > from the ADs about this. > >> Notably, adoption of a solution (discovery+negotiation >> protocol) before adoption of use cases seems like putting >> cart before the horse. > Again, we are following direction from the ADs. > >> It is not also clear to me how well the suitability of the >> solution has been evaluated. For implementation of some >> autonomic, distributed algorithms, point-to-point negotiation >> protocol such as the suggested solution is far from optimal. >> In case of homenet, we moved from hierarchical DHCPv6 PD >> (point-to-point hierarchy) to a distributed algorithm >> (draft-ietf-homenet-prefix-assignment*) which was result of >> over two years of draft updates, academic proving of >> correctness etc. > There is a subtle point here. The idea is to produce generic > components that do *not* imply specific autonomic algorithms. If > we do it correctly, those components will support either a top > down or a distributed mechanism or even a blend of the two > approaches. So actually the solution choices come later: we > don't have to decide in advance between top-down and peer-to-peer. > >> Also, while dropping homenet from list of target things is >> _a_ way to solve the conflict that we already have autonomic >> solution for that particular problem which works (it was >> mentioned there before in e.g. IETF 90 not-quite-WG-forming >> BoF), even better would be to have a general solution that >> _also_ works in a homenet. > If we were having this discussion 5 years ago, I would agree. > But you homenet guys are ahead of us. > >> Especially as IoT is just >> specialized type of homenet, I assume, > As above - I don't think that's right; IoT is much broader. > >> although it is covered >> only by one mention in the whole charter (and the rest does >> not seem very IoT oriented). > So should we say in the charter that the scope is everything but > the initial focus is enterprise and carrier? > >> Looking at the solutions, from homenet developer / draft >> writer point of view, I would welcome a general trust >> bootstrapping framework. I am not convinced by the current >> solution draft for that (it assumes too many components for a >> home network case at least). A lot of the other things seem >> somewhat enterprise-y (control plane with IPsec, own routing >> protocol and ULAs? Not in IoT device at least, nor probably >> in constrained homenet router), or just unsuitable, such as >> the negotiation protocol that does not seem like a good fit >> for distributed decision making which is usually the key >> thing in autonomic networking. > That means we have explained the negotiation idea badly. It is > not top-down negotiation like > draft-boucadair-network-automation-requirements. It is peer to > peer with top-down as a special case. > > Thanks > Brian > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --=20 email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Wed Oct 1 13:27:39 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF231A8030; Wed, 1 Oct 2014 13:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueqrI5h_fSyG; Wed, 1 Oct 2014 13:27:37 -0700 (PDT) Received: from chi.subsignal.org (cxd-2-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:ed::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8A01A1A6FF7; Wed, 1 Oct 2014 13:27:37 -0700 (PDT) Received: from [192.168.178.66] (55d4422a.access.ecotel.net [85.212.66.42]) by chi.subsignal.org (Postfix) with ESMTPSA id 9F49B1261A2; Wed, 1 Oct 2014 22:28:37 +0200 (CEST) Message-ID: <542C63B7.90109@openwrt.org> Date: Wed, 01 Oct 2014 22:27:35 +0200 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Brian E Carpenter , Pierre Pfister References: <542BFFAE.1080105@cisco.com> <9B8FD45E-3C1C-4CA3-A754-430B2BFC9CAE@darou.fr> <542C5536.3030507@gmail.com> In-Reply-To: <542C5536.3030507@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/4xeyUHs01Ijj8LLND3lOfivQNnY Cc: Benoit Claise , homenet@ietf.org, "anima@ietf.org" Subject: Re: [homenet] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 20:27:39 -0000 > Except that homenet has a limited scope and is well advanced > in its work. Still some of the essential underlying problems are the same and I think you should not discard the progress in this working group all too quickly. Instead adopting concepts and ideas from homenet could very much benefit ANIMA. The underlying problems of "state synchronization" or "negotiation" are the same. Sure we've already built something on top of that but why not look at the foundation. > Not really. The details are all to be discussed of course, but > the concept is fundamental to autonomics: devices talk to each > other rather than receiving instructions from above. (As Rene > Struik has pointed out, there is another way to look at it, > state synchronization, but that's largely a difference of > terminology.) Well I think your statement is a bit premature here. Yes, a negotiation protocol is certainly necessary. However even superficially comparing draft-jiang-config-negotiation-protocol with draft-ietf-homenet-hncp shows that the problem can be tackled by completely different approaches and it would surprise me if these were the only ways to do it. Plus I can't really tell from a first quick look at it which of these approaches is more generic than the other. Perhaps we should try to compare both and see what could be improved in either variant or maybe find another variant which combines the best of both worlds? Cheers, Steven From nobody Wed Oct 1 15:18:37 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1761A87C7; Wed, 1 Oct 2014 15:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTpoigPliQIw; Wed, 1 Oct 2014 15:18:17 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7F91A87BF; Wed, 1 Oct 2014 15:18:17 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id v10so905086pde.8 for ; Wed, 01 Oct 2014 15:18:17 -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=9E3vWzW2IUHE1L1shE9t2dJHDLGJjCU1vI9z2CDBqJU=; b=FseTlAm4Cc5CXAIGs/5kdEZxAITrBFf38OewGUnakjYh6F5dJHfOLZbzeK6y37qw4M 71qSScNKDKil1VIKSNb+WAT9YYN/iQ0Rt4BlgmWwYN5TwkWJdF9th4NL/mOA/6lbQEnk dMf9PW14l6s6b7E6yYqsh+4tZGsmWb4QNAURfyhwA4BJOL8lrKlmXiuwiGf9H+NcqwA5 Feptcp+sUT7cpUSV2Rk/kQa+MzjvbxGOYc2h2teOTDtwfxRRl7czvvXWTJ42MyEAW0mV djYuuRIZtVpZ25IwdqY993JES24s4QQEasThhOc7bLXvL44fU4DGfLesZQzTs6QToDBG /Tdg== X-Received: by 10.66.241.166 with SMTP id wj6mr68726826pac.149.1412201897230; Wed, 01 Oct 2014 15:18:17 -0700 (PDT) Received: from [192.168.178.23] (89.199.69.111.dynamic.snap.net.nz. [111.69.199.89]) by mx.google.com with ESMTPSA id mq4sm1905575pdb.18.2014.10.01.15.18.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Oct 2014 15:18:16 -0700 (PDT) Message-ID: <542C7DAC.5000807@gmail.com> Date: Thu, 02 Oct 2014 11:18:20 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Rene Struik References: <542BFFAE.1080105@cisco.com> <542C59B3.10700@gmail.com> <542C5E45.5010101@gmail.com> In-Reply-To: <542C5E45.5010101@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/jNY6aFHA32pbJjNHu_nvT6MvoDU Cc: Benoit Claise , homenet@ietf.org, Markus Stenberg , "anima@ietf.org" Subject: Re: [homenet] [Anima] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 22:18:20 -0000 On 02/10/2014 09:04, Rene Struik wrote: > Dear colleagues: > > I think it would be a mistake not to consider highly constrained > networks and devices at first. That's a good comment and is more precise than the buzzword "IoT". It would not distress me to see the buzzword removed. However, my personal impression is that the resource-constrained devices will be be carrying much management software at all, so it would be the gateways to a whole cluster of constrained devices that would be the target systems for Anima. Brian > If one would like to get anywhere close > to 30-50 billion interconnected objects (the rosy marketing numbers by > Cisco and Intel referenced everywhere), there is an absolute requirement > to make trust lifecycle management and network management overhead > virtually disappear, without the need for human intervention, except in > exceptional cases. Without almost zero cost over the *entire* lifecycle > of a device, while at the same time assuring a mix of ease of use - > flexibility - security, forecasted internet of things type deployments > figures may never materialize. Any solution direction that would not > consider foremost the constraints of the deployment category that will > soon outnumber all others should be discouraged. If one closely examines > and designs for the nimble objects in the universe, it would obviously > also fit for the less nimble; the other way around, this does not > necessarily hold. > > As argued before, I do agree with comments that solid footing for the > effort needs more work (which, I think, has been echoed by the group > during conf calls and by the AD). > > Best regards, Rene > > == > So should we say in the charter that the scope is everything but the > initial focus is enterprise and carrier? > > On 10/1/2014 3:44 PM, Brian E Carpenter wrote: >> Markus, >> >> On 02/10/2014 05:27, Markus Stenberg wrote: >>> On 1.10.2014, at 16.20, Benoit Claise >>> wrote: >>>> Based on the previous UCAN BoF, we are considering having >>>> an ANIMA WG: Autonomic Networking Integrated Model and >>>> Approach This is now a proposed charter, under >>>> consideration by the IESG. This is your chance to provide >>>> feedback on http://datatracker.ietf.org/wg/anima/charter/ >>>> Note also that a BoF has been requested, just in case. >>>> Since HOMENET was mentioned during the UCAN BoF, I thought >>>> of double-checking with you guys. >>> TL;DR: Please either add homenet (and solutions already in >>> the WG) to the WG goals, or drop IoT too and just focus on >>> enterprise. >> Personal comments on this: >> >> 1) One reason for not stating homenet as part of the scope is >> that we do not want to interfere with the current progress in >> homenet. Personally I think there is a lot to learn from >> homenet, but as I just said to Pierre, we are too late to affect >> homenet's choices. I will be delighted if the results can be >> applied to homenets in future, of course. >> >> 2) I am also a little nervous about the IoT reference in the >> charter. We haven't yet seen a use case description that would >> apply to IoT (which has IMHO a much broader scope than home >> networks, e.g. building services.) >> >> I think the initial focus is indeed on enterprise and carrier >> networks where the OPEX pain is greatest, but we should not >> artificially limit the applicability either. >> >>> Looking at the milestones, I am very curious about lack of >>> requirements or architecture work before promoting solutions >>> and even WGLCing them. >> There are the existing NMRG documents and there will be an >> overview document, but we are following quite specific direction >> from the ADs about this. >> >>> Notably, adoption of a solution (discovery+negotiation >>> protocol) before adoption of use cases seems like putting >>> cart before the horse. >> Again, we are following direction from the ADs. >> >>> It is not also clear to me how well the suitability of the >>> solution has been evaluated. For implementation of some >>> autonomic, distributed algorithms, point-to-point negotiation >>> protocol such as the suggested solution is far from optimal. >>> In case of homenet, we moved from hierarchical DHCPv6 PD >>> (point-to-point hierarchy) to a distributed algorithm >>> (draft-ietf-homenet-prefix-assignment*) which was result of >>> over two years of draft updates, academic proving of >>> correctness etc. >> There is a subtle point here. The idea is to produce generic >> components that do *not* imply specific autonomic algorithms. If >> we do it correctly, those components will support either a top >> down or a distributed mechanism or even a blend of the two >> approaches. So actually the solution choices come later: we >> don't have to decide in advance between top-down and peer-to-peer. >> >>> Also, while dropping homenet from list of target things is >>> _a_ way to solve the conflict that we already have autonomic >>> solution for that particular problem which works (it was >>> mentioned there before in e.g. IETF 90 not-quite-WG-forming >>> BoF), even better would be to have a general solution that >>> _also_ works in a homenet. >> If we were having this discussion 5 years ago, I would agree. >> But you homenet guys are ahead of us. >> >>> Especially as IoT is just >>> specialized type of homenet, I assume, >> As above - I don't think that's right; IoT is much broader. >> >>> although it is covered >>> only by one mention in the whole charter (and the rest does >>> not seem very IoT oriented). >> So should we say in the charter that the scope is everything but >> the initial focus is enterprise and carrier? >> >>> Looking at the solutions, from homenet developer / draft >>> writer point of view, I would welcome a general trust >>> bootstrapping framework. I am not convinced by the current >>> solution draft for that (it assumes too many components for a >>> home network case at least). A lot of the other things seem >>> somewhat enterprise-y (control plane with IPsec, own routing >>> protocol and ULAs? Not in IoT device at least, nor probably >>> in constrained homenet router), or just unsuitable, such as >>> the negotiation protocol that does not seem like a good fit >>> for distributed decision making which is usually the key >>> thing in autonomic networking. >> That means we have explained the negotiation idea badly. It is >> not top-down negotiation like >> draft-boucadair-network-automation-requirements. It is peer to >> peer with top-down as a special case. >> >> Thanks >> Brian >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > From nobody Wed Oct 1 15:21:21 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C881A87C2; Wed, 1 Oct 2014 15:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFtJGRTBUvGH; Wed, 1 Oct 2014 15:21:09 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743DB1A87C7; Wed, 1 Oct 2014 15:21:09 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id ey11so1052483pad.27 for ; Wed, 01 Oct 2014 15:21:08 -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=yAvTSf+Ln0V9Px/EiPLRNoOBGetsD/VIR2J7wOPIva8=; b=gbK7gCAXW1DigMcwNrKtpv9+4H568LPLc+dkLuboutsCNmzhRo/dAfewb81+GLq4Hs ZgAylbNH47e1Fi5CCJNWLuLEADWGJjQjBJ2XmiCqP1iFlYrJ08B3vuc7Nr1ro3OJDBHc vkArU9nvCN6UyxF+olc8BeHJuLvJ44tN9kbVGN2vnQySy60CQmkzuj7dEXr/EJJiP/+N Y/nrmOTL7o77kIS6qJj5kwPu8RDZvW16mehir+3PcphRBjaNsfEGkvHeOqx6rvGJLTxN Ad0rnwSQMIhDjgn42rek+utyidt1j1kM0TUEIZtJ5b16rdjU3cf3VCDEhyxlO7Zh2W96 f6LA== X-Received: by 10.66.119.103 with SMTP id kt7mr82078446pab.95.1412202068069; Wed, 01 Oct 2014 15:21:08 -0700 (PDT) Received: from [192.168.178.23] (89.199.69.111.dynamic.snap.net.nz. [111.69.199.89]) by mx.google.com with ESMTPSA id xk6sm1909521pbc.11.2014.10.01.15.21.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Oct 2014 15:21:07 -0700 (PDT) Message-ID: <542C7E57.1040708@gmail.com> Date: Thu, 02 Oct 2014 11:21:11 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Steven Barth References: <542BFFAE.1080105@cisco.com> <9B8FD45E-3C1C-4CA3-A754-430B2BFC9CAE@darou.fr> <542C5536.3030507@gmail.com> <542C63B7.90109@openwrt.org> In-Reply-To: <542C63B7.90109@openwrt.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/EqeRml8-XSYr0nI5NZsKkA0BgqU Cc: Benoit Claise , homenet@ietf.org, Pierre Pfister , "anima@ietf.org" Subject: Re: [homenet] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 22:21:12 -0000 On 02/10/2014 09:27, Steven Barth wrote: > >> Except that homenet has a limited scope and is well advanced >> in its work. > Still some of the essential underlying problems are the same and I think > you should not discard the progress in this working group all too > quickly. Instead adopting concepts and ideas from homenet could very > much benefit ANIMA. The underlying problems of "state synchronization" > or "negotiation" are the same. Sure we've already built something on top > of that but why not look at the foundation. > > >> Not really. The details are all to be discussed of course, but >> the concept is fundamental to autonomics: devices talk to each >> other rather than receiving instructions from above. (As Rene >> Struik has pointed out, there is another way to look at it, >> state synchronization, but that's largely a difference of >> terminology.) > Well I think your statement is a bit premature here. Yes, a negotiation > protocol is certainly necessary. > However even superficially comparing > draft-jiang-config-negotiation-protocol with draft-ietf-homenet-hncp > shows that the problem can be tackled by completely different approaches > and it would surprise me if these were the only ways to do it. Plus I > can't really tell from a first quick look at it which of these > approaches is more generic than the other. Perhaps we should try to > compare both and see what could be improved in either variant or maybe > find another variant which combines the best of both worlds? I quite agree. We will be updating the config-negotiation-protocol draft but I think there is a lot to learn from HNCP. I hope the words in the charter don't imply otherwise. Brian > > > Cheers, > > Steven > From nobody Wed Oct 1 17:26:32 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAE41A8855 for ; Wed, 1 Oct 2014 17:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHJqqR4ZKqkA for ; Wed, 1 Oct 2014 17:26:27 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9C11A8843 for ; Wed, 1 Oct 2014 17:26:27 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id cc10so2361262wib.17 for ; Wed, 01 Oct 2014 17:26:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=2dUtH389/0A2fXs/2WaCaJFJ+td/Lic3Lke7mPXZcSQ=; b=PS6hwTp9JaGEbnhGhI7D3PguhYBIiW4avOG0NE8qPXUP4YMoeJNVFeuuY1W/Uarb6b ea4ppLlYlASd/r6jc493m+fEJjChp3MRTvhLjWh2OEURZvd/o+kvBCQZR1SD8OZ0Kmdm kBozNb10LU2F+byXmoqhYEKs6NbjbLIsoUnHqTYet8D9wRksnmYoU04Uy7Hw3Wb0n7JN dd2WOprRF3KIBToyc3JGctSTggdG/w1WK1jJaWW1OnjcWwQeES/nnspnMDKTeNp0ap23 9r7FNOV5iyKzIkBIEHKThr5abOzXN/5nGfdEJhqaOLFbVc2aENbJKWM2+Sswad8o1bKM QJZg== X-Gm-Message-State: ALoCoQnLE9ctCZq9Blgfjro4XDomzbll8Zn6FQGOrGRA6thhBNELc+NLxqVKNs5snpLJGBjSwgRi X-Received: by 10.194.185.230 with SMTP id ff6mr18238062wjc.120.1412209585989; Wed, 01 Oct 2014 17:26:25 -0700 (PDT) Received: from ?IPv6:2001:420:c0c1:8:602e:47b3:938a:b82e? ([2001:420:c0c1:8:602e:47b3:938a:b82e]) by mx.google.com with ESMTPSA id hu3sm2772527wjb.17.2014.10.01.17.26.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Oct 2014 17:26:25 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B61EC433-4596-4C2C-9AF4-5CE6C43C72EE" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Mark Townsley In-Reply-To: <542C59B3.10700@gmail.com> Date: Thu, 2 Oct 2014 02:26:20 +0200 Message-Id: <5F26857C-1C41-4D1F-AA4A-B7D9E947180F@townsley.net> References: <542BFFAE.1080105@cisco.com> <542C59B3.10700@gmail.com> To: Brian Carpenter X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/wa-hCIKLb90CHwt4eGsYMmET7jo Cc: Benoit Claise , homenet@ietf.org, Markus Stenberg , "anima@ietf.org" Subject: Re: [homenet] [Anima] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 00:26:29 -0000 --Apple-Mail=_B61EC433-4596-4C2C-9AF4-5CE6C43C72EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 1, 2014, at 9:44 PM, Brian E Carpenter = wrote: >=20 > 1) One reason for not stating homenet as part of the scope is > that we do not want to interfere with the current progress in > homenet. Personally I think there is a lot to learn from > homenet, but as I just said to Pierre, we are too late to affect > homenet's choices. I will be delighted if the results can be > applied to homenets in future, of course. > If we were having this discussion 5 years ago, I would agree. > But you homenet guys are ahead of us. Yes and no. Yes, homenet is ahead of anima in terms of, say, a distributed IPv6 = prefix configuration algorithm. This is one of the first things the = group began tackling, so there's quite a bit of water under the bridge = here. However, while I have seen a lot of recent effort in security, = homenet has a long way to go here. This happens to be something I get = the impression anima has been working on for quite a while. You say that you wish to learn from what homenet has done, yet the = current proposed anima charter says: ...autonomic service agents will demonstrate the usage of the above mentioned autonomic infrastructure components with two use cases: o A solution for distributed IPv6 prefix management within a network. Although prefix delegation is currently supported, it relies on human action to subdivide and assign prefixes according to local requirements, and this process could become autonomic. This use case is precisely what draft-ietf-homenet-prefix-assignment = does (which has roots all the way back to = draft-arkko-homenet-prefix-assignment-00 in October 2011). So to = homenet, this is a solved problem - with an algorithm that has been = applied not just to HNCP, but to OSPF and ISIS.=20 I do think that there is room for a non-distributed algorithm that is = tied more to centralized mechanisms, particularly as you move closer to = a more tightly managed system. But for a distributed approach, as you = observed Brian, homenet is rather far along.=20 This is just the most obvious example that jumps out at me. There may be = something similar to say about HNCP itself, the use of src+dst routing, = etc. In any case, It's not hard to extrapolate from here that in a = year's time or so, if we continue on the current trajectory, homenet = will have come up with its own non-anima secure bootstrapping, and anima = will have come up with its own non-homenet distributed IPv6 prefix = configuration. =20 - Mark --Apple-Mail=_B61EC433-4596-4C2C-9AF4-5CE6C43C72EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 1, 2014, at 9:44 PM, Brian E = Carpenter <brian.e.carpenter@gmail.com> wrote:

1) One reason for not stating homenet as part of the scope = is
that we do not want to interfere with the current progress = in
homenet. Personally I think there is a lot to learn = from
homenet, but as I just said to Pierre, we are too late to = affect
homenet's choices. I will be delighted if the results can = be
applied to homenets in future, of = course.









= --Apple-Mail=_B61EC433-4596-4C2C-9AF4-5CE6C43C72EE-- From nobody Wed Oct 1 17:41:39 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727B41A8855 for ; Wed, 1 Oct 2014 17:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EV7KmUsJXPTU for ; Wed, 1 Oct 2014 17:41:36 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 961B91A8851 for ; Wed, 1 Oct 2014 17:41:36 -0700 (PDT) Received: from [10.0.10.40] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id B75F82380367 for ; Wed, 1 Oct 2014 20:41:35 -0400 (EDT) From: Ted Lemon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <28FC2E42-6931-46BB-B06B-91818C41ABC5@fugue.com> Date: Wed, 1 Oct 2014 20:41:35 -0400 To: "homenet@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/c1BLJUwkiLp7iXv84YaBfGokEuM Subject: [homenet] Please consider attending the ANIMA BoF in Honolulu. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 00:41:38 -0000 The ANIMA BoF (Autonomous Network Integrated Model and Approach) appears = to relate to the work being done on HNCP, so Dave Thaler suggested, and = I agree, that it would be helpful for Homenet participants to look at = the BoF agenda and think about whether or not there is synergy or = conflict here. If you think either of these is the case, it would be = helpful if you could attend the ANIMA BoF and participate in the = discussion there. From nobody Wed Oct 1 17:56:46 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA0D1A8874 for ; Wed, 1 Oct 2014 17:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCLHXoWOm5vN for ; Wed, 1 Oct 2014 17:56:44 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 028701A8870 for ; Wed, 1 Oct 2014 17:56:44 -0700 (PDT) Received: from [10.0.10.40] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id DD0892380367 for ; Wed, 1 Oct 2014 20:56:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <28FC2E42-6931-46BB-B06B-91818C41ABC5@fugue.com> Date: Wed, 1 Oct 2014 20:56:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <550AFEDE-2D26-4F50-9701-41F941E49934@fugue.com> References: <28FC2E42-6931-46BB-B06B-91818C41ABC5@fugue.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/aR6pSNnjCCdAJLpDBinkuJAI3wA Subject: Re: [homenet] Please consider attending the ANIMA BoF in Honolulu. X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 00:56:45 -0000 On Oct 1, 2014, at 8:41 PM, Ted Lemon wrote: > The ANIMA BoF (Autonomous Network Integrated Model and Approach) = appears to relate to the work being done on HNCP, so Dave Thaler = suggested, and I agree, that it would be helpful for Homenet = participants to look at the BoF agenda and think about whether or not = there is synergy or conflict here. If you think either of these is the = case, it would be helpful if you could attend the ANIMA BoF and = participate in the discussion there. Hm, I composed this this morning before the discussion started on the = mailing list, and sent it without thinking just now, so it's a bit of a = lame duck. But the point that I think is important here is that if = people think there is something to talk about, we need to talk about = whether to charter this working group. There is talk about sending the = working group charter out for IETF review on Thursday, possibly = chartering the working group by the following Thursday if the IETF = consensus is to do so; I think that this is premature, and that we = should hold an actual BoF in November and have a real discussion about = this there. That said, if in fact the charter does go out for external review on = Thursday, and if people in Homenet think there is a potential conflict = or synergy between the work in the charter and the work Homenet is doing = that needs to be addressed in the charter, you need to raise that and = argue that point during the IETF last call. In order for your input to = count in the consensus determination, you need to make actionable = arguments. It is not actually wrong for two IETF working groups to do = work that overlaps, if the IETF has consensus to do that, so the goal = should be to try to get the right outcome, not to try to shut down the = effort or to filibuster the process. From nobody Wed Oct 1 20:16:19 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B16D1A0033; Wed, 1 Oct 2014 20:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPe5KJxsECJq; Wed, 1 Oct 2014 20:16:13 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC3A1A0009; Wed, 1 Oct 2014 20:16:13 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id eu11so1485832pac.14 for ; Wed, 01 Oct 2014 20:16:13 -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=pjFUP0ecYjmE0tYAQeHcit2/iDRcYgj7wdELUtz4iCU=; b=abWZQ5qVkYCHUtJMxO1q2OO5iXqUjYMfxzTXrE+U42Oi3SPh/b0qVYIi1AUte2RfrH vMFn4cArosU1aq95yUcerQjR1p1We9u5jhbWdhX6PmQqY5zxIzwIwMTvVulGob8xb++O CRTZ7rU8DtqSILfxUF8HAiYr4wmcUqoJz8ldrpn7bJAXIe0G0nIb5ubvRECIS5jcpSsR FX+8/VgWhnPMye71TIOjEpAirWVGsNE9JyWKxQCc9Jt8RXZWbdJVOpB90j3aiDV5+5VI mwyArm6R3FsWDd3+ecz0iG3ep/z1BW0lfD0nfj1U94Uy5WOSsztKRk+vXios6c1APuuk BcFg== X-Received: by 10.67.14.198 with SMTP id fi6mr48690612pad.34.1412219772586; Wed, 01 Oct 2014 20:16:12 -0700 (PDT) Received: from [192.168.178.23] (89.199.69.111.dynamic.snap.net.nz. [111.69.199.89]) by mx.google.com with ESMTPSA id yt3sm2215038pbc.34.2014.10.01.20.16.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Oct 2014 20:16:11 -0700 (PDT) Message-ID: <542CC380.1030600@gmail.com> Date: Thu, 02 Oct 2014 16:16:16 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Townsley References: <542BFFAE.1080105@cisco.com> <542C59B3.10700@gmail.com> <5F26857C-1C41-4D1F-AA4A-B7D9E947180F@townsley.net> In-Reply-To: <5F26857C-1C41-4D1F-AA4A-B7D9E947180F@townsley.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/oq_ICXeEvWqhRO70UIS7Et3tHTA Cc: Benoit Claise , homenet@ietf.org, Markus Stenberg , "anima@ietf.org" Subject: Re: [homenet] [Anima] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 03:16:15 -0000 On 02/10/2014 13:26, Mark Townsley wrote: > On Oct 1, 2014, at 9:44 PM, Brian E Carpenter wrote: >> 1) One reason for not stating homenet as part of the scope is >> that we do not want to interfere with the current progress in >> homenet. Personally I think there is a lot to learn from >> homenet, but as I just said to Pierre, we are too late to affect >> homenet's choices. I will be delighted if the results can be >> applied to homenets in future, of course. > >> If we were having this discussion 5 years ago, I would agree. >> But you homenet guys are ahead of us. > > > Yes and no. > > Yes, homenet is ahead of anima in terms of, say, a distributed IPv6 prefix configuration algorithm. This is one of the first things the group began tackling, so there's quite a bit of water under the bridge here. However, while I have seen a lot of recent effort in security, homenet has a long way to go here. This happens to be something I get the impression anima has been working on for quite a while. > > You say that you wish to learn from what homenet has done, yet the current proposed anima charter says: > > ...autonomic service agents will demonstrate the usage of the above > mentioned autonomic infrastructure components with two use cases: > > o A solution for distributed IPv6 prefix management within a network. > Although prefix delegation is currently supported, it relies on human > action to subdivide and assign prefixes according to local requirements, > and this process could become autonomic. > > This use case is precisely what draft-ietf-homenet-prefix-assignment does (which has roots all the way back to draft-arkko-homenet-prefix-assignment-00 in October 2011). So to homenet, this is a solved problem - with an algorithm that has been applied not just to HNCP, but to OSPF and ISIS. Well, we have a bug in our short description, because the intention is to support prefix assignment in a carrier scenario, which is different in many ways. Good catch. > I do think that there is room for a non-distributed algorithm that is tied more to centralized mechanisms, particularly as you move closer to a more tightly managed system. But for a distributed approach, as you observed Brian, homenet is rather far along. > This is just the most obvious example that jumps out at me. There may be something similar to say about HNCP itself, the use of src+dst routing, etc. In any case, It's not hard to extrapolate from here that in a year's time or so, if we continue on the current trajectory, homenet will have come up with its own non-anima secure bootstrapping, and anima will have come up with its own non-homenet distributed IPv6 prefix configuration. Which we should try to coordinate, since I see no reason in theory why there can't be common underlying mechanisms between enterprise, carrier and SOHO. But I don't want to hear in 2 years time that homenet is stuck because anima hasn't met its milestones. Brian From nobody Wed Oct 1 23:27:15 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181F41A00F8 for ; Wed, 1 Oct 2014 23:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jh1odifH0Lic for ; Wed, 1 Oct 2014 23:27:11 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8711A00F3 for ; Wed, 1 Oct 2014 23:27:11 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id x19so1874718ier.25 for ; Wed, 01 Oct 2014 23:27:10 -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; bh=+po/2i3Wb+kqV6cSivh3CxNfNFisNNB4TpsM8bIUxQo=; b=FPFdkHw54ghYCcFTxLXs/VI45C64w/4ias8ba78jv8L9+ubuj2RQtPUvGAhBMAb4gW dzq1SQs5mMax08SufeoiyYGoRFgqRTn+HMIs5af5IIRkoeTXl5+aAd9cO3kYp3JCbFtp wgbzMvKa3BszSYjz8TLITXG7d5AZKYzx8NHsWYV9utqcgoEIq1/9w64kY41WsjqUfA7W fNrknd5PrGvXVOlu0EwU1hNTrpGnlAMD9OlCSzUUpij6Yr5X1MLtAExxd781o8QT0l/j X9kG5jBp3x1OEWv34qZBlDEwaQZwIlT4p8IbbjcsANuoHgzMZV1BQ0wXbbqaX2x2XCXZ uXdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+po/2i3Wb+kqV6cSivh3CxNfNFisNNB4TpsM8bIUxQo=; b=alZNzBvYXIXyFca2y+vFf9IzLS+cr6JCzOsiSxZ5NNOe4Yt823WcVDZasH2JPQG5KG JGk+6Wo0OGJNo6W4UxLmWcR0pdtZ7bTFuJYwRErdYsK6U4F2GM6ohAdSqo4aiq3/ZFEY IxBAcVAwceq4OckSA+DgTemuLyTQHmqNOqmPoV6bXMS3C+Iiip3+XsUAGfaNqMT4DUcF p5thnGc1UxHhpjIIAm2m6H6NWsGztk0ke2rXNkv1KrKerXWkpPWKI6s3H3kgPy5R23QU hTvjfpPQaLxdICislUDyY6RAjXYgCQfQt2bR4b7iEN7ix8/2m2NdBAy0Lzm86zjm55Hw x7mQ== X-Gm-Message-State: ALoCoQlmwxJiQQehLauxJxC7I8TTNyfn+zobCo5NeGeS/Pk8D2rFWL7BFDWI5MZ52/wJYHo7RnbM X-Received: by 10.42.49.8 with SMTP id u8mr2564583icf.11.1412231230521; Wed, 01 Oct 2014 23:27:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.144 with HTTP; Wed, 1 Oct 2014 23:26:49 -0700 (PDT) In-Reply-To: <542CC380.1030600@gmail.com> References: <542BFFAE.1080105@cisco.com> <542C59B3.10700@gmail.com> <5F26857C-1C41-4D1F-AA4A-B7D9E947180F@townsley.net> <542CC380.1030600@gmail.com> From: Lorenzo Colitti Date: Thu, 2 Oct 2014 15:26:49 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=90e6ba1efb46d628ad05046ab4f5 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/mgVWf-FpZTjmQWoYoxqUkYELx5A Cc: Benoit Claise , "homenet@ietf.org" , Markus Stenberg , Mark Townsley , "anima@ietf.org" Subject: Re: [homenet] [Anima] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 06:27:13 -0000 --90e6ba1efb46d628ad05046ab4f5 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 2, 2014 at 12:16 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > This use case is precisely what draft-ietf-homenet-prefix-assignment > does (which has roots all the way back to > draft-arkko-homenet-prefix-assignment-00 in October 2011). So to homenet, > this is a solved problem - with an algorithm that has been applied not just > to HNCP, but to OSPF and ISIS. > > Well, we have a bug in our short description, because the intention is to > support prefix assignment in a carrier scenario, which is different > in many ways. Really? Which ways? --90e6ba1efb46d628ad05046ab4f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Oct 2, 2014 at 12:16 PM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
> This use case is precisely what draft-ietf-homenet-prefix-as= signment does (which has roots all the way back to draft-arkko-homenet-pref= ix-assignment-00 in October 2011). So to homenet, this is a solved problem = - with an algorithm that has been applied not just to HNCP, but to OSPF and= ISIS.

Well, we have a bug in our short description, because the intention = is to
support prefix assignment in a carrier scenario, which is different
in many ways.=C2=A0

Really? Which ways?=C2= =A0
--90e6ba1efb46d628ad05046ab4f5-- From nobody Thu Oct 2 01:20:50 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6A11A0164; Thu, 2 Oct 2014 01:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jOQBsXhqW81; Thu, 2 Oct 2014 01:20:31 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA6C1A0173; Thu, 2 Oct 2014 01:20:27 -0700 (PDT) Received: from poro.lan (84.248.80.109) by jenni2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 5416869201892247; Thu, 2 Oct 2014 11:20:19 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Markus Stenberg In-Reply-To: <542C59B3.10700@gmail.com> Date: Thu, 2 Oct 2014 11:20:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <542BFFAE.1080105@cisco.com> <542C59B3.10700@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/o4PhjOa4h9YAFNyU7ydtCiW0rPg Cc: Benoit Claise , homenet@ietf.org, Markus Stenberg , "anima@ietf.org" Subject: Re: [homenet] [Anima] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 08:20:33 -0000 On 1.10.2014, at 22.44, Brian E Carpenter = wrote: > Personal comments on this: >=20 > 1) One reason for not stating homenet as part of the scope is > that we do not want to interfere with the current progress in > homenet. Personally I think there is a lot to learn from > homenet, but as I just said to Pierre, we are too late to affect > homenet's choices. I will be delighted if the results can be > applied to homenets in future, of course. Well, it sounds as if you plan to WGLC your negotiation protocol = probably around the time we WGLC HNCP (or sooner? who knows). > 2) I am also a little nervous about the IoT reference in the > charter. We haven't yet seen a use case description that would > apply to IoT (which has IMHO a much broader scope than home > networks, e.g. building services.) >=20 > I think the initial focus is indeed on enterprise and carrier > networks where the OPEX pain is greatest, but we should not > artificially limit the applicability either. I would just say that you aim at enterprise networks and leave it at = that, then. Considering home networks, and even more so constrained = devices in the IoT land have different management model and resources = than your typical enterprise devices. > There are the existing NMRG documents and there will be an > overview document, but we are following quite specific direction > from the ADs about this. Well, at least providing links to them in the charter would be probably = good idea then. As it is, it looks like =91we have solution, here is the = WG=92 to me. >> It is not also clear to me how well the suitability of the >> solution has been evaluated. For implementation of some >> autonomic, distributed algorithms, point-to-point negotiation >> protocol such as the suggested solution is far from optimal. >> In case of homenet, we moved from hierarchical DHCPv6 PD >> (point-to-point hierarchy) to a distributed algorithm >> (draft-ietf-homenet-prefix-assignment*) which was result of >> over two years of draft updates, academic proving of >> correctness etc. > There is a subtle point here. The idea is to produce generic > components that do *not* imply specific autonomic algorithms. If > we do it correctly, those components will support either a top > down or a distributed mechanism or even a blend of the two > approaches. So actually the solution choices come later: we > don=92t have to decide in advance between top-down and peer-to-peer. A protocol (draft-jiang-config-negotiation-protocol) that is essentially = point-to-point state push/pull mechanism does not seem like natural fit = for that (+- some discovery). The scalable solutions with such protocol require hierarchies of = delegation. For example, given prefix delegation problem, the reasonable = (=3Dlow number of total message exchanges) solutions wind up subdividing = the prefix hierarchically, or alternatively with some =91god node=92(s) = that perform the allocations. It becomes harder if you have multiple = sources of same resource (=3Dprefix) or want to be robust in case of = failure. >> although it is covered >> only by one mention in the whole charter (and the rest does >> not seem very IoT oriented). > So should we say in the charter that the scope is everything but > the initial focus is enterprise and carrier? Or that you are developing enterprise solution and it can work for = anything with luck.=20 >> Looking at the solutions, from homenet developer / draft >> writer point of view, I would welcome a general trust >> bootstrapping framework. I am not convinced by the current >> solution draft for that (it assumes too many components for a >> home network case at least). A lot of the other things seem >> somewhat enterprise-y (control plane with IPsec, own routing >> protocol and ULAs? Not in IoT device at least, nor probably >> in constrained homenet router), or just unsuitable, such as >> the negotiation protocol that does not seem like a good fit >> for distributed decision making which is usually the key >> thing in autonomic networking. > That means we have explained the negotiation idea badly. It is > not top-down negotiation like > draft-boucadair-network-automation-requirements. It is peer to > peer with top-down as a special case. Sure, it is simple =91who is there=92, =92{can I haz X, (yes|no|no but = you can have Y)}+=92 protocol as far as I can read the draft anyway = (draft-jiang-config-negotiation-protocol-02) It is not obvious to me how it would be even used to tell other all = other nodes about e.g. change in some network parameter (say, NTP = server). Is it a =91request=92? Who is it sent to? How to prevent = duplication of sending it to nodes that already did receive it? =46rom my point of view, a general network infra protocol needs - discovery - state push/pull _network wide_ HNCP does this; I am not sure how CDNP can be used for this, but I = welcome examples. Cheers, -Markus= From nobody Thu Oct 2 05:16:59 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCBC1A6F9B; Thu, 2 Oct 2014 05:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlkhqJ3wtRdR; Thu, 2 Oct 2014 05:16:50 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875CA1A6F93; Thu, 2 Oct 2014 05:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8980; q=dns/txt; s=iport; t=1412252210; x=1413461810; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=AP2Yhm7tHZgqv6g5ZeFNc4nrT6gyASLzug9/Xe22gTY=; b=NqueQKDMoYv0qKQMHfwurBqDogO1XgbOLaGf8W1DpLp7nCIYr2kKyZIA cSHh8+VJinzY3m6BEmgPmLqai3PFcEurn16f+LVI5M9oCIdWwhCrBdyuh ZCLdD+Gkmp17elRGo1v3wsFbcJBl7zcRFgXTDlKL3Bw2MNB0YOtTpyCpD s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoEAI9BLVStJssW/2dsb2JhbABgg2FZiF3CCIdNAoEiAXuEAwEBAQMBeAEQCxIGCRYPCQMCAQIBNw4GDQEFAgEBBRKIGwgNvQsBF4oxhSQBAU8HhEsFj1OGVocKgWWFc44bg2U7LwGBDoE7AQEB X-IronPort-AV: E=Sophos;i="5.04,638,1406592000"; d="scan'208,217";a="192400627" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 02 Oct 2014 12:16:48 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s92CGlRx007766; Thu, 2 Oct 2014 12:16:47 GMT Message-ID: <542D422F.1090302@cisco.com> Date: Thu, 02 Oct 2014 14:16:47 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Markus Stenberg References: <542BFFAE.1080105@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020106060309070102050606" Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Ke_5pa6EXJqz6si4NG0RaUKRfAE Cc: homenet@ietf.org, "anima@ietf.org" Subject: Re: [homenet] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 12:16:54 -0000 This is a multi-part message in MIME format. --------------020106060309070102050606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/10/2014 18:27, Markus Stenberg wrote: > On 1.10.2014, at 16.20, Benoit Claise wrote: >> Based on the previous UCAN BoF, we are considering having an ANIMA WG: Autonomic Networking Integrated Model and Approach >> This is now a proposed charter, under consideration by the IESG. >> This is your chance to provide feedback on http://datatracker.ietf.org/wg/anima/charter/ >> Note also that a BoF has been requested, just in case. >> Since HOMENET was mentioned during the UCAN BoF, I thought of double-checking with you guys. > TL;DR: Please either add homenet (and solutions already in the WG) to the WG goals, or drop IoT too and just focus on enterprise. > > Looking at the milestones, I am very curious about lack of requirements or architecture work before promoting solutions and even WGLCing them. As mentioned in http://www.ietf.org/mail-archive/web/anima/current/msg00246.html A few observations, to start with: 1. Autonomic Networking could be a huge explanatory field. 2. From the BoF, we heard (among other points): There is interest but focus ... focus ... focus on things that could be done quickly 3. The IESG has also been realizing that the process of problem statement/use cases/requirements/architecture/protocol takes way too long for the industry. 4. If a great architecture document to rule all autonomic functions would have been easy, it would been done already. In NMRG for example, which had plenty of time to think about it! So an architecture as a starting point is not the right approach. 5. A WG can always be re-chartered in future phases These are the reasons why Joel and I asked the BoF chairs to lead a charter discussion, focusing on only 2 use cases > > Notably, adoption of a solution (discovery+negotiation protocol) before adoption of use cases seems like putting cart before the horse. Valid point. Regards, Benoit > > It is not also clear to me how well the suitability of the solution has been evaluated. For implementation of some autonomic, distributed algorithms, point-to-point negotiation protocol such as the suggested solution is far from optimal. In case of homenet, we moved from hierarchical DHCPv6 PD (point-to-point hierarchy) to a distributed algorithm (draft-ietf-homenet-prefix-assignment*) which was result of over two years of draft updates, academic proving of correctness etc. > > Also, while dropping homenet from list of target things is _a_ way to solve the conflict that we already have autonomic solution for that particular problem which works (it was mentioned there before in e.g. IETF 90 not-quite-WG-forming BoF), even better would be to have a general solution that _also_ works in a homenet. Especially as IoT is just specialized type of homenet, I assume, although it is covered only by one mention in the whole charter (and the rest does not seem very IoT oriented). > > Looking at the solutions, from homenet developer / draft writer point of view, I would welcome a general trust bootstrapping framework. I am not convinced by the current solution draft for that (it assumes too many components for a home network case at least). A lot of the other things seem somewhat enterprise-y (control plane with IPsec, own routing protocol and ULAs? Not in IoT device at least, nor probably in constrained homenet router), or just unsuitable, such as the negotiation protocol that does not seem like a good fit for distributed decision making which is usually the key thing in autonomic networking. > > Cheers, > > -Markus > > . > --------------020106060309070102050606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 01/10/2014 18:27, Markus Stenberg wrote:
On 1.10.2014, at 16.20, Benoit Claise <bclaise@cisco.com> wrote:

Based on the previous UCAN BoF, we are considering having an ANIMA WG: Autonomic Networking Integrated Model and Approach
This is now a proposed charter, under consideration by the IESG.
This is your chance to provide feedback on http://datatracker.ietf.org/wg/anima/charter/
Note also that a BoF has been requested, just in case.
Since HOMENET was mentioned during the UCAN BoF, I thought of double-checking with you guys.

TL;DR: Please either add homenet (and solutions already in the WG) to the WG goals, or drop IoT too and just focus on enterprise.

Looking at the milestones, I am very curious about lack of requirements or architecture work before promoting solutions and even WGLCing them.
As mentioned in http://www.ietf.org/mail-archive/web/anima/current/msg00246.html
A few observations, to start with:
1. Autonomic Networking could be a huge explanatory field.
2. From the BoF, we heard (among other points):
    There is interest but focus ... focus ... focus on things that could be done quickly
3. The IESG has also been realizing that the process of problem statement/use cases/requirements/architecture/protocol takes way too long for the industry.
4. If a great architecture document to rule all autonomic functions would have been easy, it would been done already. In NMRG for example, which had plenty of time to think about it! So an architecture as a starting point is not the right approach.
5. A WG can always be re-chartered in future phases

These are the reasons why Joel and I asked the BoF chairs to lead a charter discussion, focusing on only 2 use cases


Notably, adoption of a solution (discovery+negotiation protocol) before adoption of use cases seems like putting cart before the horse.
Valid point.

Regards, Benoit

It is not also clear to me how well the suitability of the solution has been evaluated. For implementation of some autonomic, distributed algorithms, point-to-point negotiation protocol such as the suggested solution is far from optimal. In case of homenet, we moved from hierarchical DHCPv6 PD (point-to-point hierarchy) to a distributed algorithm (draft-ietf-homenet-prefix-assignment*) which was result of over two years of draft updates, academic proving of correctness etc. 

Also, while dropping homenet from list of target things is _a_ way to solve the conflict that we already have autonomic solution for that particular problem which works (it was mentioned there before in e.g. IETF 90 not-quite-WG-forming BoF), even better would be to have a general solution that _also_ works in a homenet. Especially as IoT is just specialized type of homenet, I assume, although it is covered only by one mention in the whole charter (and the rest does not seem very IoT oriented).

Looking at the solutions, from homenet developer / draft writer point of view, I would welcome a general trust bootstrapping framework. I am not convinced by the current solution draft for that (it assumes too many components for a home network case at least). A lot of the other things seem somewhat enterprise-y (control plane with IPsec, own routing protocol and ULAs? Not in IoT device at least, nor probably in constrained homenet router), or just unsuitable, such as the negotiation protocol that does not seem like a good fit for distributed decision making which is usually the key thing in autonomic networking. 

Cheers,

-Markus

.

--------------020106060309070102050606-- From nobody Thu Oct 2 05:49:50 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC8E1A6FC3; Thu, 2 Oct 2014 05:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BFD0IXmh2qz; Thu, 2 Oct 2014 05:49:46 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC2EE1A6FA8; Thu, 2 Oct 2014 05:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3736; q=dns/txt; s=iport; t=1412254186; x=1413463786; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QMM0t3PiISVpqjzqRrxxZfxrrloOoXdyDCOcMZSFfzc=; b=UIdlL3RqbFGXQV0BtANwdmRPJIAzY6Fp8IhUzw1S0Ovfw2bNtzzBhRKw +cfV+UHqIx4SVyvl9047xXclDlaNFk8+SuKeB5ZyN56CLzipXKjrbI1mE UhFRBfBllfM8nCCpi5a7OwWX/mouqoBM0PaNA8TnemsOlgOfdP/USboxm 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAI9JLVStJA2L/2dsb2JhbABggw5TWQTKVwqHTQKBCRYBe4QDAQEBBAEBATctBwsMBAIBCBEEAQELFAkHJwsUCQgCBAENBQgTA4ggDb0TARePRBEBHzEHBoMogR0FhiqLQ4Q8iG+KYIkug2NsgQ85gQIBAQE X-IronPort-AV: E=Sophos;i="5.04,638,1406592000"; d="scan'208";a="83366351" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP; 02 Oct 2014 12:49:36 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s92Cnamf027441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Oct 2014 12:49:36 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.204]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Thu, 2 Oct 2014 07:49:36 -0500 From: "Michael Behringer (mbehring)" To: Ted Lemon , The IESG Thread-Topic: [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) Thread-Index: AQHP3jVHokqaa0NBjkebeYQrfyizUZwcvPCw Date: Thu, 2 Oct 2014 12:49:36 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21C59B2B@xmb-rcd-x14.cisco.com> References: <20141002113735.6068.22745.idtracker@ietfa.amsl.com> In-Reply-To: <20141002113735.6068.22745.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.197.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/je878C0jyMY5pADuFy6c4038yK0 Cc: "homenet@ietf.org" , "anima@ietf.org" Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 12:49:47 -0000 My personal goal is that what we do in ANIMA is fully compatible with and i= deally used in homenet. It would feel wrong to me to have an infrastructure= that doesn't work in a homenet.=20 The security bootstrap is a good example of what we can achieve, with reaso= nable effort. To me, address management is a *use case* for the ANIMA work.= Actually, we ought to be able to map *any* distributed address management = method on top of the autonomic infrastructure that we're trying to create i= n ANIMA.=20 We should also look to use HNCP in ANIMA, for sure (and the charter allows = that!). But according to my intro statement, what ANIMA does would have to = work across all architectures. We need to look more closely at this, and se= e whether 1) HNCP works as is , or 2) we can create an HNCP++ that can scal= e to SP/Ent, or 3) we need a different approach in ANIMA. As long as we do = proper due diligence we should be able to settle on the best of those 3 opt= ions.=20 So, personally I think we can work out a charter that resolves those confli= cts, step by step.=20 Michael > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Ted Lemon > Sent: 02 October 2014 13:38 > To: The IESG > Cc: anima@ietf.org > Subject: [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with > BLOCK) >=20 > Ted Lemon has entered the following ballot position for > charter-ietf-anima-00-09: Block >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/charter-ietf-anima/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- >=20 > The following exchange between Mark and Brian illustrates what I want out > of a BoF or External Review discussion: >=20 > Mark: >=20 > [...] >=20 > In any case, It's not hard to extrapolate from here that in a year's time= or so, > if we continue on the current trajectory, homenet will have come up with > its own non-anima secure bootstrapping, and anima will have come up with > its own non-homenet distributed IPv6 prefix configuration. >=20 > Brian: >=20 > Which we should try to coordinate, since I see no reason in theory why > there can't be common underlying mechanisms between enterprise, carrier > and SOHO. But I don't want to hear in 2 years time that homenet is stuck > because anima hasn't met its milestones. >=20 > Ted: >=20 > Right now Homenet has a solution for the distributed configuration proble= m > with a spec and at least one WIP implementation, and is working > seriously on the mutual authentication problem. There may be some > synergy between what Homenet is trying to do and what ANIMA is trying to > do. If there is, it would be a big win to coordinate the two groups' > activities. It may also be that there is no synergy, and the efforts > are really effectively independent. >=20 > Before the working group is chartered, I would like to see some clarity > reached about this. If there is synergy, I'd like there to be some > clear agreement about how to move forward so that ANIMA can achieve its > goals and Homenet can achieve its goals without either creating an intero= p > problem or stalling. >=20 >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Oct 2 05:57:25 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECC61A6FE6; Thu, 2 Oct 2014 05:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.015 X-Spam-Level: X-Spam-Status: No, score=0.015 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRk0v0H-IdKO; Thu, 2 Oct 2014 05:57:19 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B34D1A6FD9; Thu, 2 Oct 2014 05:57:19 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id B8BABED2B44AA; Thu, 2 Oct 2014 12:57:15 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s92CvF31004935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Oct 2014 14:57:16 +0200 Received: from [172.27.204.73] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 2 Oct 2014 14:57:15 +0200 Message-ID: <542D4BAB.2060009@alcatel-lucent.com> Date: Thu, 2 Oct 2014 14:57:15 +0200 From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Benoit Claise , Markus Stenberg References: <542BFFAE.1080105@cisco.com> <542D422F.1090302@cisco.com> In-Reply-To: <542D422F.1090302@cisco.com> Content-Type: multipart/alternative; boundary="------------060709060604050702030808" X-Originating-IP: [135.239.27.38] Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/e2Syc4y_dWPY6VsYLAJzyI-9o70 Cc: homenet@ietf.org, "anima@ietf.org" Subject: Re: [homenet] [Anima] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 12:57:21 -0000 --------------060709060604050702030808 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Dear Benoit, Markus, all, On 02/10/2014 14:16, Benoit Claise wrote: > On 01/10/2014 18:27, Markus Stenberg wrote: > >> Notably, adoption of a solution (discovery+negotiation protocol) before adoption of use cases seems like putting cart before the horse. > Valid point. > > Regards, Benoit Indeed a valid point, however before concluding here, some insights might help: -OPS ADs gave guidance to focus on (applicability on) 2 use cases only. -The solution adoption milestone shall read as _applicability_ of the protocols onto the two proposed/elected use cases (the milestone should be rewritten in that sense for more clarity). -The WG aims at developing protocols reusable _among __multiple_ use cases. -An initial step of the WG should be to extract, from these multiple use cases, the boundaries / problems these protocols have to solve. HTH, best regards, Laurent. --------------060709060604050702030808 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Dear Benoit, Markus, all,

On 02/10/2014 14:16, Benoit Claise wrote:
On 01/10/2014 18:27, Markus Stenberg wrote:

Notably, adoption of a solution (discovery+negotiation protocol) before adoption of use cases seems like putting cart before the horse.
Valid point.

Regards, Benoit

Indeed a valid point, however before concluding here, some insights might help:
    -OPS ADs gave guidance to focus on (applicability on) 2 use cases only.
    -The solution adoption milestone shall read as applicability of the protocols onto the two proposed/elected use cases (the milestone should be rewritten in that sense for more clarity).
    -The WG aims at developing protocols reusable among multiple use cases.
    -An initial step of the WG should be to extract, from these multiple use cases, the boundaries / problems these protocols have to solve.


HTH, best regards, Laurent.

--------------060709060604050702030808-- From nobody Thu Oct 2 06:15:40 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168551A86F8; Thu, 2 Oct 2014 06:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQQdtRuHpnrr; Thu, 2 Oct 2014 06:15:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 68F001A7D82; Thu, 2 Oct 2014 06:15:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C23F6BDFD; Thu, 2 Oct 2014 14:15:23 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOwIa00bromN; Thu, 2 Oct 2014 14:15:17 +0100 (IST) Received: from [10.87.48.7] (unknown [86.42.29.169]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 65825BE20; Thu, 2 Oct 2014 14:15:15 +0100 (IST) Message-ID: <542D4FE3.2010607@cs.tcd.ie> Date: Thu, 02 Oct 2014 14:15:15 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Ted Lemon , The IESG References: <20141002113735.6068.22745.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21C59B2B@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21C59B2B@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Xhoh5Ed5dgI7EpBw-mHNDtM-rFk Cc: "homenet@ietf.org" , "anima@ietf.org" Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 13:15:30 -0000 On 02/10/14 13:49, Michael Behringer (mbehring) wrote: > My personal goal is that what we do in ANIMA is fully compatible with > and ideally used in homenet. It would feel wrong to me to have an > infrastructure that doesn't work in a homenet. > > The security bootstrap is a good example of what we can achieve, with > reasonable effort. FWIW, it is not clear to me that the reasonable requirements for provisioning device security information (or bootstrapping if we wanted to call it that) are the same. In enterprise environments we see fewer larger vendors of devices. In the home where we additionally have a large range of vendors many of whom are tiny and leverage a lot of OSS and who could perhaps not take part in the kind of provisioning infrastructure that is quite reasonable for enterprises and their vendors. I do think both want to end up in the same state, where devices are authorised for connection to the network and where there is some keying material usable for security, but I'd be surprised if one approach to getting there worked the same way for both homes and enterprises. S. From nobody Thu Oct 2 06:50:32 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49081A0365; Thu, 2 Oct 2014 06:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.62 X-Spam-Level: X-Spam-Status: No, score=-3.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdUnd61h_upF; Thu, 2 Oct 2014 06:50:25 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512BA1A0379; Thu, 2 Oct 2014 06:50:25 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.156980657; Thu, 02 Oct 2014 07:50:13 -0600 Received: from PACDCEXMB22.cable.comcast.com ([fe80::f887:1b71:477f:d14b]) by PACDCEXHUB01.cable.comcast.com ([fe80::bdc4:5b5c:ee33:b058%16]) with mapi id 14.03.0181.006; Thu, 2 Oct 2014 09:50:14 -0400 From: "Leddy, John" To: Stephen Farrell , "Michael Behringer (mbehring)" , Ted Lemon , The IESG Thread-Topic: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) Thread-Index: AQHP3jVHokqaa0NBjkebeYQrfyizUZwcvPCwgABPgoD//8bWgA== Date: Thu, 2 Oct 2014 13:50:13 +0000 Message-ID: References: <20141002113735.6068.22745.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21C59B2B@xmb-rcd-x14.cisco.com> <542D4FE3.2010607@cs.tcd.ie> In-Reply-To: <542D4FE3.2010607@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [24.40.56.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/MdZlhjcHA4q0SrNlNsukWFgwDIk Cc: "homenet@ietf.org" , "anima@ietf.org" Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 13:50:27 -0000 My worry on this topic is that we are referring to =B3the Home=B2 and =B3th= e Enterprise=B2. It isn=B9t that clear of a distinction. This isn=B9t just a simple L2 flat home vs. a Fortune 1000 enterprise. The home is getting more complex and includes work from home; IOT, home security, hot spots, cloud services, policies, discovery etc. Large numbers of SMB=B9s look like more high end residential than they do large enterprises. It would be ideal to have a solution that spans the range of size and complexity for both residential and enterprise. Perhaps enabling features/capabilities where required. Also, as far as IPV6 connectivity residential is probably ahead of enterprises in adopting V6 centric architectures and services. Residential doesn=B9t have much of a choice, it just happens. 2cents, John On 10/2/14, 9:15 AM, "Stephen Farrell" wrote: > > >On 02/10/14 13:49, Michael Behringer (mbehring) wrote: >> My personal goal is that what we do in ANIMA is fully compatible with >> and ideally used in homenet. It would feel wrong to me to have an >> infrastructure that doesn't work in a homenet. >>=20 >> The security bootstrap is a good example of what we can achieve, with >> reasonable effort. > >FWIW, it is not clear to me that the reasonable requirements >for provisioning device security information (or bootstrapping >if we wanted to call it that) are the same. > >In enterprise environments we see fewer larger vendors of devices. >In the home where we additionally have a large range of vendors >many of whom are tiny and leverage a lot of OSS and who could >perhaps not take part in the kind of provisioning infrastructure >that is quite reasonable for enterprises and their vendors. > >I do think both want to end up in the same state, where devices >are authorised for connection to the network and where there is >some keying material usable for security, but I'd be surprised >if one approach to getting there worked the same way for both >homes and enterprises. > >S. > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet > From nobody Thu Oct 2 07:41:46 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37161A0377; Thu, 2 Oct 2014 07:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.801 X-Spam-Level: X-Spam-Status: No, score=-13.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ra07vYenQVMi; Thu, 2 Oct 2014 07:41:38 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4591A037D; Thu, 2 Oct 2014 07:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3352; q=dns/txt; s=iport; t=1412260898; x=1413470498; h=date:from:to:cc:subject:message-id:mime-version: content-transfer-encoding; bh=69pUWjxOV52QTLLgYzl/uWnvPBaeYFl+fsKRDn3EyYs=; b=AHpfX5sUouyQOMatukyl27nK9MVhAqzIhWdeTEYhhgHE+NBG5aJjnOEs eYt3TzSzV09OftlZ2Nlb2tI2tHvxlSYjuFUVzYgKAounsHgtJW40JJf+A d6JZaORYIjdu8mRhmGBFsPGhM0DcosMVTl8GYDwilbQyr5G3wLwCn/BMb Q=; X-IronPort-AV: E=Sophos;i="5.04,638,1406592000"; d="scan'208";a="83454028" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 02 Oct 2014 14:41:38 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s92EfaXK025564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Oct 2014 14:41:37 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s92Efauq001876; Thu, 2 Oct 2014 07:41:36 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s92EfaRu001875; Thu, 2 Oct 2014 07:41:36 -0700 Date: Thu, 2 Oct 2014 07:41:36 -0700 From: Toerless Eckert To: "Leddy, John" Message-ID: <20141002144136.GA1847@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/OfuYeqoql0xC8kSPwWm08iR9ikg Cc: "Michael Behringer \(mbehring\)" , The IESG , "homenet@ietf.org" , Stephen Farrell , "anima@ietf.org" , Ted Lemon Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 14:41:40 -0000 Fully agreed. But does this imply that we will make most progress by blocking out a working group that is actively chartered to look at the problems in the market segments Homenet is not addressing ? If the BLOCK is meant to suggest a charter improvements for anima to better define our mutual desire to share whatever is applicable and not reinvent unnecessarily, then where is the proposed charter text change ? Cheers Toerless P.S.: Also, if i may throw in some random tidbit of technology thoughts: I love home networks (and the WG for it), because it is the best place for IPv6 to eliminate IPv4 and start creating fresh, better IP network. I have a lot of doubt that we are anywhere close to going that route especially in larger enterprises, so the address management for IPv4 in those networks is going to be a crucial requirement where i don't think homenet could (or should) be any big help. And i am not sure if i would want to hold my breath for a lot of IPv4 adress complexity reduction in IoT either. But certainly autonomic processes cold rather help than hurt in that matter. On Thu, Oct 02, 2014 at 01:50:13PM +0000, Leddy, John wrote: > My worry on this topic is that we are referring to łthe Home˛ and łthe > Enterprise˛. > It isnąt that clear of a distinction. This isnąt just a simple L2 flat > home vs. a Fortune 1000 enterprise. > > The home is getting more complex and includes work from home; IOT, home > security, hot spots, cloud services, policies, discovery etc. > Large numbers of SMBąs look like more high end residential than they do > large enterprises. > > It would be ideal to have a solution that spans the range of size and > complexity for both residential and enterprise. > Perhaps enabling features/capabilities where required. > > Also, as far as IPV6 connectivity residential is probably ahead of > enterprises in adopting V6 centric architectures and services. > Residential doesnąt have much of a choice, it just happens. > > 2cents, John > > On 10/2/14, 9:15 AM, "Stephen Farrell" wrote: > > > > > > >On 02/10/14 13:49, Michael Behringer (mbehring) wrote: > >> My personal goal is that what we do in ANIMA is fully compatible with > >> and ideally used in homenet. It would feel wrong to me to have an > >> infrastructure that doesn't work in a homenet. > >> > >> The security bootstrap is a good example of what we can achieve, with > >> reasonable effort. > > > >FWIW, it is not clear to me that the reasonable requirements > >for provisioning device security information (or bootstrapping > >if we wanted to call it that) are the same. > > > >In enterprise environments we see fewer larger vendors of devices. > >In the home where we additionally have a large range of vendors > >many of whom are tiny and leverage a lot of OSS and who could > >perhaps not take part in the kind of provisioning infrastructure > >that is quite reasonable for enterprises and their vendors. > > > >I do think both want to end up in the same state, where devices > >are authorised for connection to the network and where there is > >some keying material usable for security, but I'd be surprised > >if one approach to getting there worked the same way for both > >homes and enterprises. > > > >S. > > From nobody Thu Oct 2 11:58:35 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8914F1A1AAC; Thu, 2 Oct 2014 11:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4W8Tpi0AqqQr; Thu, 2 Oct 2014 11:58:30 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D15F1A1AA9; Thu, 2 Oct 2014 11:58:30 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id eu11so3176691pac.35 for ; Thu, 02 Oct 2014 11:58:30 -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=JzFcfiqKav1RlXnvt0N1sGdelejPoxTbqtEYodCDi0Y=; b=AHzPTqFmuFXhLVAQR68iUebPscFv82Ez4a0L5ge6tBlQn0KSyju6H54YG0qQmPaPNo n9NZHKPT4igxvJ3D8a5srYd5QGaLqvckj/pFFga7SHAqzhDTdgK8H6lVNajRC8W19wFR ozuov0IK7r/IPnul2w9YJI9UbMw1gLIUnv3A0XkUMVrIHpk+63R9h45iUYKV7bDXX4Kb Ml3Ts7uEFEiU9Bs0mF6gZFGtdYTd5JO9l4TEysWDpSh3HtqvvS4X6FrXh0hu4Js6TsQB 8CN78DATqsGYKZfGBbhGQdQTXo2vmHuaRFvazdK0tJOLN3r/wR3HGXSqGzcEOr4EJsrx wkyQ== X-Received: by 10.68.69.36 with SMTP id b4mr911477pbu.59.1412276309288; Thu, 02 Oct 2014 11:58:29 -0700 (PDT) Received: from [192.168.178.23] (81.199.69.111.dynamic.snap.net.nz. [111.69.199.81]) by mx.google.com with ESMTPSA id yh3sm4480949pbb.38.2014.10.02.11.58.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 11:58:28 -0700 (PDT) Message-ID: <542DA05A.50008@gmail.com> Date: Fri, 03 Oct 2014 07:58:34 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <542BFFAE.1080105@cisco.com> <542C59B3.10700@gmail.com> <5F26857C-1C41-4D1F-AA4A-B7D9E947180F@townsley.net> <542CC380.1030600@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/EFP6z558vbQnSDY2RH-ZiaySNMY Cc: Benoit Claise , "homenet@ietf.org" , Markus Stenberg , Mark Townsley , "anima@ietf.org" Subject: Re: [homenet] [Anima] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 18:58:32 -0000 On 02/10/2014 19:26, Lorenzo Colitti wrote: > On Thu, Oct 2, 2014 at 12:16 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >>> This use case is precisely what draft-ietf-homenet-prefix-assignment >> does (which has roots all the way back to >> draft-arkko-homenet-prefix-assignment-00 in October 2011). So to homenet, >> this is a solved problem - with an algorithm that has been applied not just >> to HNCP, but to OSPF and ISIS. >> >> Well, we have a bug in our short description, because the intention is to >> support prefix assignment in a carrier scenario, which is different >> in many ways. > > > Really? Which ways? That was the point of draft-jiang-auto-addr-management which was briefly presented at the UCAN BOF. Brian From nobody Thu Oct 2 12:07:41 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5C71A1BB9; Thu, 2 Oct 2014 12:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PH758SJFQoz0; Thu, 2 Oct 2014 12:07:34 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1BE21A1BB8; Thu, 2 Oct 2014 12:07:34 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2E2CB20012; Thu, 2 Oct 2014 15:13:17 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 23F9263AED; Thu, 2 Oct 2014 15:07:32 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0D1BE63AEC; Thu, 2 Oct 2014 15:07:32 -0400 (EDT) From: Michael Richardson To: Benoit Claise In-Reply-To: <542BFFAE.1080105@cisco.com> References: <542BFFAE.1080105@cisco.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Ok-W0cFLUWqVRwE-PFN6AUH8_n0 Cc: homenet@ietf.org, "anima@ietf.org" Subject: Re: [homenet] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 19:07:38 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Benoit Claise wrote: > Based on the previous UCAN BoF, we are considering having an ANIMA WG: > Autonomic Networking Integrated Model and Approach > This is now a proposed charter, under consideration by the IESG. > This is your chance to provide feedback on > http://datatracker.ietf.org/wg/anima/charter/ Thanks. I have read the charter. Thank you for trying to restrict it to something focused. I think you have enough focus, but there still significant space for scope creap. Why not build this issue into the charter? Mar 2015 - recharter to refocus scope [In reading it, I was reminded of the SNMP v2 security wars of 1995. Can we have enough security present in order to configure the system to have security, was part of the underlying debate. I think we can do it now.] =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVC2icYCLcPvd0N1lAQIrBQf/VZ0hwjbbtkH84T7g6htjtNtcPQjMQznV Pfz3w3muahzMZqcSNeLcSbHtg9Yss92Hz73xY+O/wLAYkEB2kGLNYjbGJ5Ae+OYX SwbSwXeEAkFmBUIUHIyfYSLbkcn3NAeGb9adPa43hXbhJMKJzQqX9aWapwzDkFoP FisJRndLe6ejg9Oe+ce7CWGeSkpUkyotRXkpnrLT8ENKfS5P3k/fuRv3t3KS8Tmw XD16cyOoWOxYxvCYUYZwNUtKKsI9Gy2FoHb2FMDrwLclA1LwTKEw+qaVadkPEYX9 enuQFq/Uw3O3FJiJ/AmrSIevHIEcmFuUdFWyaYtaab2doqOyW/4smQ== =Egj8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 2 12:11:34 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379A31A1B4F; Thu, 2 Oct 2014 12:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9DX2h76-bSb; Thu, 2 Oct 2014 12:11:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46CB1A1B59; Thu, 2 Oct 2014 12:11:28 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3983C20012; Thu, 2 Oct 2014 15:17:13 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3332663AED; Thu, 2 Oct 2014 15:11:28 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1DD7D63AEC; Thu, 2 Oct 2014 15:11:28 -0400 (EDT) From: Michael Richardson To: Markus Stenberg In-Reply-To: References: <542BFFAE.1080105@cisco.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Gy5HS_xAWUjbhxzhSNainxbfpjc Cc: Benoit Claise , homenet@ietf.org, "anima@ietf.org" Subject: Re: [homenet] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 19:11:30 -0000 --=-=-= Markus Stenberg wrote: >> Note also that a BoF has been requested, just in case. >> Since HOMENET was mentioned during the UCAN BoF, I thought of >>double-checking with you guys. > TL;DR: Please either add homenet (and solutions already in the WG) to > the WG goals, or drop IoT too and just focus on enterprise. I see your point; if you think that much IoT will be in the home. However, there are significant areas of IoT deployment into industrial settings which have very different availability of human resources. While in the home, there is perhaps an IoT : HUMAN ration of 1000:1, which is to say that in an average home of 100 devices, there is barely 10% of a human available set them up, in industrial settings the ratio could be even worse (10000:1?), but still that might leave a team of ten trained humans available to create Intents. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVC2jXYCLcPvd0N1lAQJg1Qf/TcBBd0Dx3Bst1xZ1aBE+2jBrvGs2ZJuF gYvjN2h0M/ZOBOJA5999ltm87xBKB7lcY0JQ/h8XuZG3137dtuBMa0RPqum5qimj GiKqFvQZ626c5KWeEk5uQHmERV+tFNIRVq9zAot1WdvNj5IwPQEkdsGyu057pY6o 7QpmT0iOwCo2qug0S8ixHAw1G+qR6Hl3Is2szHJrqFzCZgO488ELaL+uiTQs89x8 t7oAcOa5MWpkhEIa0+wfHD9T992JZe1Gq7tkZaDpb1znkruggrrLg0YRCPVjboJV ea3DPFh0KMmbqACgCWcz7cs8cTTIFfS3hWKdJL2TBbh/QbGm6WMo5w== =vVRc -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 2 12:18:14 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834EB1A1BD4; Thu, 2 Oct 2014 12:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2YtlgAHeRUy; Thu, 2 Oct 2014 12:18:10 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF3C21A1BD1; Thu, 2 Oct 2014 12:18:10 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id rd3so3242612pab.18 for ; Thu, 02 Oct 2014 12:18:10 -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=cbmbQ0+0GB3UzgZzbklEGfRDWpGd2Wxaky2R57qljxE=; b=yoR44nqkq0aZxnVlqRFYWYhX7f3eoj5/8RmHOO7//duIkSrBrKBigq7EJdpgzymlt1 BNwvSjf7hZ8rwGUnpnEVmDqO5jGmMqTeRa0YcJ7O2teHnr9jztzDwE2gmEg3IcZxykN8 7FXNNuQbofYx4cHsPGO2xIoBItV2xAk1Hr6tH+b17WrAFtZjzFOqnFL6yPR5sd0dAiS+ GLNTi0ppc6mEra00oIbeHlIbigbHT0eHtOA/6a614fMickBODxV0j/SAF26XwkpWNq9q i38w9QAyNLtv6Hy9CtSNNpKKFoN0FtAtRnk9A3KiBEVNECzrPV+yxcFroJQAc8xA2QbU 1Adw== X-Received: by 10.66.151.196 with SMTP id us4mr1288801pab.78.1412277490335; Thu, 02 Oct 2014 12:18:10 -0700 (PDT) Received: from [192.168.178.23] (81.199.69.111.dynamic.snap.net.nz. [111.69.199.81]) by mx.google.com with ESMTPSA id az8sm4590986pac.12.2014.10.02.12.18.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 12:18:09 -0700 (PDT) Message-ID: <542DA4F7.4030406@gmail.com> Date: Fri, 03 Oct 2014 08:18:15 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Markus Stenberg References: <542BFFAE.1080105@cisco.com> <542C59B3.10700@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/iJ3s57TOvjePQpbUtK-m6WS6b9c Cc: Benoit Claise , homenet@ietf.org, "anima@ietf.org" Subject: Re: [homenet] [Anima] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 19:18:12 -0000 On 02/10/2014 21:20, Markus Stenberg wrote: > On 1.10.2014, at 22.44, Brian E Carpenter = wrote: >> Personal comments on this: >> >> 1) One reason for not stating homenet as part of the scope is >> that we do not want to interfere with the current progress in >> homenet. Personally I think there is a lot to learn from >> homenet, but as I just said to Pierre, we are too late to affect >> homenet's choices. I will be delighted if the results can be >> applied to homenets in future, of course. >=20 > Well, it sounds as if you plan to WGLC your negotiation protocol probab= ly around the time we WGLC HNCP (or sooner? who knows). I have no idea. The homenet milestones haven't been updated for 2 years, but I would expect HNCP to be much sooner than Anima. >> 2) I am also a little nervous about the IoT reference in the >> charter. We haven't yet seen a use case description that would >> apply to IoT (which has IMHO a much broader scope than home >> networks, e.g. building services.) >> >> I think the initial focus is indeed on enterprise and carrier >> networks where the OPEX pain is greatest, but we should not >> artificially limit the applicability either. >=20 > I would just say that you aim at enterprise networks and leave it at th= at, then. Considering home networks, and even more so constrained devices= in the IoT land have different management model and resources than your = typical enterprise devices. Yes, but we are (to be frank) trying to disrupt the current enterprise model and I don't want to constrain the thinking by constraining the scope. >=20 >> There are the existing NMRG documents and there will be an >> overview document, but we are following quite specific direction >> from the ADs about this. >=20 > Well, at least providing links to them in the charter would be probably= good idea then. As it is, it looks like =E2=80=98we have solution, here = is the WG=E2=80=99 to me. The NMRG drafts are cited in the charter. We are trying to avoid claiming that existing solution proposals *are* the draft solutions, because that's the WG's choice to make. >=20 >>> It is not also clear to me how well the suitability of the >>> solution has been evaluated. For implementation of some >>> autonomic, distributed algorithms, point-to-point negotiation >>> protocol such as the suggested solution is far from optimal. >>> In case of homenet, we moved from hierarchical DHCPv6 PD >>> (point-to-point hierarchy) to a distributed algorithm >>> (draft-ietf-homenet-prefix-assignment*) which was result of >>> over two years of draft updates, academic proving of >>> correctness etc. >> There is a subtle point here. The idea is to produce generic >> components that do *not* imply specific autonomic algorithms. If >> we do it correctly, those components will support either a top >> down or a distributed mechanism or even a blend of the two >> approaches. So actually the solution choices come later: we >> don=E2=80=99t have to decide in advance between top-down and peer-to-p= eer. >=20 > A protocol (draft-jiang-config-negotiation-protocol) that is essentiall= y point-to-point state push/pull mechanism does not seem like natural fit= for that (+- some discovery). Well, I disagree, but that again is a job for the WG. > The scalable solutions with such protocol require hierarchies of delega= tion. For example, given prefix delegation problem, the reasonable (=3Dlo= w number of total message exchanges) solutions wind up subdividing the pr= efix hierarchically, or alternatively with some =E2=80=98god node=E2=80=99= (s) that perform the allocations. It becomes harder if you have multiple = sources of same resource (=3Dprefix) or want to be robust in case of fail= ure. If a resource needs a hierarchy you would contstruct that on top of the negotiation protocol, not as an intrinsic feature of the protocol. >>> although it is covered >>> only by one mention in the whole charter (and the rest does >>> not seem very IoT oriented). >> So should we say in the charter that the scope is everything but >> the initial focus is enterprise and carrier? >=20 > Or that you are developing enterprise solution and it can work for anyt= hing with luck.=20 No, not with luck, if we do it right. That would be like saying that DHCP(v4) was designed for campus networks but would work for home networks with luck. >=20 >>> Looking at the solutions, from homenet developer / draft >>> writer point of view, I would welcome a general trust >>> bootstrapping framework. I am not convinced by the current >>> solution draft for that (it assumes too many components for a >>> home network case at least). A lot of the other things seem >>> somewhat enterprise-y (control plane with IPsec, own routing >>> protocol and ULAs? Not in IoT device at least, nor probably >>> in constrained homenet router), or just unsuitable, such as >>> the negotiation protocol that does not seem like a good fit >>> for distributed decision making which is usually the key >>> thing in autonomic networking. >> That means we have explained the negotiation idea badly. It is >> not top-down negotiation like >> draft-boucadair-network-automation-requirements. It is peer to >> peer with top-down as a special case. >=20 > Sure, it is simple =E2=80=98who is there=E2=80=99, =E2=80=99{can I haz = X, (yes|no|no but you can have Y)}+=E2=80=99 protocol as far as I can re= ad the draft anyway (draft-jiang-config-negotiation-protocol-02) Exactly. And that is pretty close to Turing-complete so it could be used very generally. >=20 > It is not obvious to me how it would be even used to tell other all oth= er nodes about e.g. change in some network parameter (say, NTP server). I= s it a =E2=80=98request=E2=80=99? Who is it sent to? How to prevent dupli= cation of sending it to nodes that already did receive it? Yes. I noticed that when considering Rene's comment about state synchronization and it needs more work. Nobody is saying that it is fully baked yet. >=20 > From my point of view, a general network infra protocol needs >=20 > - discovery > - state push/pull _network wide_ >=20 > HNCP does this; I am not sure how CDNP can be used for this, but I welc= ome examples. It's intentionally peer-to-peer so network-wide requires propagation; but I don't understand how HNCP could do some of the other things we want. There will be a revised requirements in a forthcoming draft, so I'd rather have that discussion later. Let me be clear: if HNCP can be generalised to do what we need (which would probably mean changing its name slightly) I'd be delighted. There is absolutely nothing to be gained by having two protocols if one will work. Brian From nobody Thu Oct 2 14:35:46 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89001ACE09; Thu, 2 Oct 2014 14:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRWg0MexUXve; Thu, 2 Oct 2014 14:35:40 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072C91ACE06; Thu, 2 Oct 2014 14:35:40 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id eu11so3552360pac.28 for ; Thu, 02 Oct 2014 14:35:39 -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=jrC/aF7pX+9s//N83OdsqguNMfjIJFIqWwucOc+I1x0=; b=Jjg5sh60vuIK1okvYipeei07MPXo6CUwhj5CSUZYBl/3XsVXQ1WRuLB2J/ADnHeo1f v8syxpmYHuyhFnx1+pKATNy4xhZlBPmUWaucn/JDIvpcsos+4DP25p5TdnQme5CDm7VN N7rvWLXSRzd0OlNfM3v6z1kwEdzpRWM6EJmQUM1yIb/daV+7NGpxMIfR9GaxKQYumqDP 8a6cU4sQjr39Bqr8wWagVvknUNpHYSXb4IrlKnt57wkOErJK0wW5u8KF0Y51XvY8mTdd 5+l6+x/ildKawBB+W4Hqdpe5eiMzm4yQ/NiM0yHA87wMYWhTpYbgjAPrB+So7XKGlU+H 2ZoA== X-Received: by 10.66.119.103 with SMTP id kt7mr1944689pab.95.1412285739682; Thu, 02 Oct 2014 14:35:39 -0700 (PDT) Received: from [192.168.178.23] (81.199.69.111.dynamic.snap.net.nz. [111.69.199.81]) by mx.google.com with ESMTPSA id k11sm4726502pbq.61.2014.10.02.14.35.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 14:35:38 -0700 (PDT) Message-ID: <542DC532.1080408@gmail.com> Date: Fri, 03 Oct 2014 10:35:46 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Michael Behringer (mbehring)" References: <20141002113735.6068.22745.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21C59B2B@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21C59B2B@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/4e4j3P-j9H1uymbneoOfxY02Rp0 Cc: "homenet@ietf.org" , Ted Lemon , "anima@ietf.org" , The IESG Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 21:35:41 -0000 On 03/10/2014 01:49, Michael Behringer (mbehring) wrote: > My personal goal is that what we do in ANIMA is fully compatible with and ideally used in homenet. It would feel wrong to me to have an infrastructure that doesn't work in a homenet. > > The security bootstrap is a good example of what we can achieve, with reasonable effort. To me, address management is a *use case* for the ANIMA work. Actually, we ought to be able to map *any* distributed address management method on top of the autonomic infrastructure that we're trying to create in ANIMA. > > We should also look to use HNCP in ANIMA, for sure (and the charter allows that!). But according to my intro statement, what ANIMA does would have to work across all architectures. We need to look more closely at this, and see whether 1) HNCP works as is , or 2) we can create an HNCP++ that can scale to SP/Ent, or 3) we need a different approach in ANIMA. As long as we do proper due diligence we should be able to settle on the best of those 3 options. Exactly. We have a model for the discovery/negotiation protocol which is certainly different from HNCP right now, but it is *not* written in stone. However, today HNCP has a defined scope and has some limitations, so if we converge, it would have to lose the H ("home") and gain some other properties. I don't believe we can commit to that in the charter but of course we can commit to investigate it. Brian > So, personally I think we can work out a charter that resolves those conflicts, step by step. > > Michael > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Ted Lemon >> Sent: 02 October 2014 13:38 >> To: The IESG >> Cc: anima@ietf.org >> Subject: [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with >> BLOCK) >> >> Ted Lemon has entered the following ballot position for >> charter-ietf-anima-00-09: Block >> >> When responding, please keep the subject line intact and reply to all email >> addresses included in the To and CC lines. (Feel free to cut this introductory >> paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/charter-ietf-anima/ >> >> >> >> ---------------------------------------------------------------------- >> BLOCK: >> ---------------------------------------------------------------------- >> >> The following exchange between Mark and Brian illustrates what I want out >> of a BoF or External Review discussion: >> >> Mark: >> >> [...] >> >> In any case, It's not hard to extrapolate from here that in a year's time or so, >> if we continue on the current trajectory, homenet will have come up with >> its own non-anima secure bootstrapping, and anima will have come up with >> its own non-homenet distributed IPv6 prefix configuration. >> >> Brian: >> >> Which we should try to coordinate, since I see no reason in theory why >> there can't be common underlying mechanisms between enterprise, carrier >> and SOHO. But I don't want to hear in 2 years time that homenet is stuck >> because anima hasn't met its milestones. >> >> Ted: >> >> Right now Homenet has a solution for the distributed configuration problem >> with a spec and at least one WIP implementation, and is working >> seriously on the mutual authentication problem. There may be some >> synergy between what Homenet is trying to do and what ANIMA is trying to >> do. If there is, it would be a big win to coordinate the two groups' >> activities. It may also be that there is no synergy, and the efforts >> are really effectively independent. >> >> Before the working group is chartered, I would like to see some clarity >> reached about this. If there is synergy, I'd like there to be some >> clear agreement about how to move forward so that ANIMA can achieve its >> goals and Homenet can achieve its goals without either creating an interop >> problem or stalling. >> >> >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > . > From nobody Thu Oct 2 14:47:51 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDD91ACE13; Thu, 2 Oct 2014 14:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFh_kNuR7xb3; Thu, 2 Oct 2014 14:47:44 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6C5F1ACE1B; Thu, 2 Oct 2014 14:47:44 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id rd3so3784pab.34 for ; Thu, 02 Oct 2014 14:47:44 -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=7283KmDLvjEOuupH6DFFPBwDXGkG85gXmyogq1FNJpA=; b=CR/EHzV+xtIOb032FxxEI8LzUV40CFnpHILYFt2QTIroT/gaPiTWh41okokPBtrgGe 3KcF39mviJsGAjKRb4eLTyuttiGm4aKzzLmIHOQadx7AUMvxK0w2X5z41/KsdkzXTSWV At3T6AAXbB5+bOk3bP7Gi/NXkGrYQ/saXYndrjLdB2PTBLbCUuRdupFWfwh+Q6QYv9pM mY/whNxXciZZBCfKp6ksg29qoao8snW/o9qRh2+/YfUcUiiuPLpe151oCya1ghQ4Mg+L /RTT/rCzghmSu41G5GiA0t2OafdwyROuKAkUWUSJay4DP25dEmtWl8fMR+6MeC4SwuJJ /psQ== X-Received: by 10.68.193.194 with SMTP id hq2mr1938023pbc.169.1412286464398; Thu, 02 Oct 2014 14:47:44 -0700 (PDT) Received: from [192.168.178.23] (81.199.69.111.dynamic.snap.net.nz. [111.69.199.81]) by mx.google.com with ESMTPSA id ee5sm4725473pbc.76.2014.10.02.14.47.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 14:47:43 -0700 (PDT) Message-ID: <542DC806.50406@gmail.com> Date: Fri, 03 Oct 2014 10:47:50 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kathleen Moriarty References: <20141002113735.6068.22745.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21C59B2B@xmb-rcd-x14.cisco.com> <542D4FE3.2010607@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/r_qAwzueu0-fnQ8T7kIFkYFsF0Y Cc: "Michael Behringer \(mbehring\)" , The IESG , "homenet@ietf.org" , Stephen Farrell , "anima@ietf.org" , Ted Lemon Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 21:47:46 -0000 On 03/10/2014 04:12, Kathleen Moriarty wrote: > On Thu, Oct 2, 2014 at 9:15 AM, Stephen Farrell > wrote: > >> >> On 02/10/14 13:49, Michael Behringer (mbehring) wrote: >>> My personal goal is that what we do in ANIMA is fully compatible with >>> and ideally used in homenet. It would feel wrong to me to have an >>> infrastructure that doesn't work in a homenet. >>> >>> The security bootstrap is a good example of what we can achieve, with >>> reasonable effort. >> FWIW, it is not clear to me that the reasonable requirements >> for provisioning device security information (or bootstrapping >> if we wanted to call it that) are the same. >> > > This is where we would have overlap with SACM and I2NSF. I've spoken in > Ops and Dan R has helped to try to recruit some folks to help in SACM. It > would be good to not solve this in multiple places. SACM and I2NSF are > de-conflicting what they cover. Provisioning and assessing security > information is part of those efforts already, hence my questions on the > charter as well. > >> In enterprise environments we see fewer larger vendors of devices. >> In the home where we additionally have a large range of vendors >> many of whom are tiny and leverage a lot of OSS and who could >> perhaps not take part in the kind of provisioning infrastructure >> that is quite reasonable for enterprises and their vendors. >> > > There is a push in the vendor space for this type of automation and I'm all > for it, let's just coordinate on it so we don't wind up with too many ways > to do it. Absolutely. It isn't surprising that Anima proponents are proposing specific approaches to security (or anything else), but there is an overriding sentence in the charter: "Where suitable protocols, models or methods exist, they will be preferred over creating new ones. " Clerarly that calls for coordination and awareness. Brian > > >> I do think both want to end up in the same state, where devices >> are authorised for connection to the network and where there is >> some keying material usable for security, but I'd be surprised >> if one approach to getting there worked the same way for both >> homes and enterprises. >> > > I'd like to see this discusses more, but maybe it's not in this group? > > Thanks, > Kathleen > >> S. >> >> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Oct 2 15:19:56 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF821ACE37; Thu, 2 Oct 2014 15:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUssfQkrTTvo; Thu, 2 Oct 2014 15:19:52 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F5021ACE2F; Thu, 2 Oct 2014 15:19:52 -0700 (PDT) Received: by mail-oi0-f50.google.com with SMTP id i138so37303oig.37 for ; Thu, 02 Oct 2014 15:19:52 -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=WE9HKAzzXp8P4wwQOd2RTDgNyZ8/DUP0kjsOS/h/KOM=; b=TEo5ecRQhIAZ2qY/wBRU24pjyoldVzziseVY4HFmSCgn37w7AOLbIgsnwcrw53PMmS cfMllDwlyEqBYa30Srt8fan6q11BrGLNPbwP17vDWrSzIVXX+Ixf804qp4Iz/AiYJvzI tv5ZuO/jSqB+mkmkABwSpkwwl4ljixwJ1kvUvqOf/ei+UoMyDDGNtH4yvGCJegnQm1ZZ 7IxLmCFFp5d9qdkV8XBAbCiBz8Le4oqnATvi5YoCXQ2DTbCHy330qcTGWH9k8D/M9xkL bP8F8FEQaX0yhLCkkuH0g6OYhgvA196Qpk1wtYdYa1fIb0betgZYvSAexEz9bz399NKm q05g== MIME-Version: 1.0 X-Received: by 10.60.179.200 with SMTP id di8mr1929232oec.75.1412288392030; Thu, 02 Oct 2014 15:19:52 -0700 (PDT) Received: by 10.202.227.76 with HTTP; Thu, 2 Oct 2014 15:19:51 -0700 (PDT) In-Reply-To: References: <20141002113735.6068.22745.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21C59B2B@xmb-rcd-x14.cisco.com> <542D4FE3.2010607@cs.tcd.ie> Date: Thu, 2 Oct 2014 15:19:51 -0700 Message-ID: From: Dave Taht To: "Leddy, John" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Vz2NV8mBGJThd2Mo8po4zuH7Iog Cc: "Michael Behringer \(mbehring\)" , The IESG , "homenet@ietf.org" , Stephen Farrell , "anima@ietf.org" , Ted Lemon Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 22:19:55 -0000 On Thu, Oct 2, 2014 at 6:50 AM, Leddy, John wrote: > My worry on this topic is that we are referring to =C2=B3the Home=C2=B2 a= nd =C2=B3the > Enterprise=C2=B2. I have always approached homenet as a place to get standards that also work= for small business. Small business is the place (IMHO) where much of an ipv6 revolution could start to happen. > It isn=C2=B9t that clear of a distinction. This isn=C2=B9t just a simple= L2 flat > home vs. a Fortune 1000 enterprise. +1 > The home is getting more complex and includes work from home; IOT, home > security, hot spots, cloud services, policies, discovery etc. > Large numbers of SMB=C2=B9s look like more high end residential than they= do > large enterprises. +1 > > It would be ideal to have a solution that spans the range of size and > complexity for both residential and enterprise. > Perhaps enabling features/capabilities where required. > > Also, as far as IPV6 connectivity residential is probably ahead of > enterprises in adopting V6 centric architectures and services. > Residential doesn=C2=B9t have much of a choice, it just happens. Comcast's rollout has been quite impressive. Gfiber's also. Others, not so much. > > 2cents, John > > On 10/2/14, 9:15 AM, "Stephen Farrell" wrote: > >> >> >>On 02/10/14 13:49, Michael Behringer (mbehring) wrote: >>> My personal goal is that what we do in ANIMA is fully compatible with >>> and ideally used in homenet. It would feel wrong to me to have an >>> infrastructure that doesn't work in a homenet. >>> >>> The security bootstrap is a good example of what we can achieve, with >>> reasonable effort. >> >>FWIW, it is not clear to me that the reasonable requirements >>for provisioning device security information (or bootstrapping >>if we wanted to call it that) are the same. >> >>In enterprise environments we see fewer larger vendors of devices. >>In the home where we additionally have a large range of vendors >>many of whom are tiny and leverage a lot of OSS and who could >>perhaps not take part in the kind of provisioning infrastructure >>that is quite reasonable for enterprises and their vendors. >> >>I do think both want to end up in the same state, where devices >>are authorised for connection to the network and where there is >>some keying material usable for security, but I'd be surprised >>if one approach to getting there worked the same way for both >>homes and enterprises. >> >>S. >> >>_______________________________________________ >>homenet mailing list >>homenet@ietf.org >>https://www.ietf.org/mailman/listinfo/homenet >> > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --=20 Dave T=C3=A4ht https://www.bufferbloat.net/projects/make-wifi-fast From nobody Thu Oct 2 18:08:52 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680851ACFC0; Thu, 2 Oct 2014 18:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDEbw0qiWxHz; Thu, 2 Oct 2014 18:08:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D74231ACFBC; Thu, 2 Oct 2014 18:08:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNG53884; Fri, 03 Oct 2014 01:08:46 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 3 Oct 2014 02:08:45 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.22]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 3 Oct 2014 09:08:37 +0800 From: Sheng Jiang To: Brian E Carpenter , Kathleen Moriarty Thread-Topic: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) Thread-Index: AQHP3lNdDyKxxPpxxkWhYQMcuJmDjZwc0kIAgAC9DNI= Date: Fri, 3 Oct 2014 01:08:36 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF5E1FB@nkgeml512-mbx.china.huawei.com> References: <20141002113735.6068.22745.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21C59B2B@xmb-rcd-x14.cisco.com> <542D4FE3.2010607@cs.tcd.ie> , <542DC806.50406@gmail.com> In-Reply-To: <542DC806.50406@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.18.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/AZ4L83FsI0yzmyPZ4nSTHxc5C20 Cc: "Michael Behringer \(mbehring\)" , Ted Lemon , "homenet@ietf.org" , Stephen Farrell , "anima@ietf.org" , The IESG Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 01:08:50 -0000 I am fully agree with Brian and Kathleen. It is well understood that the ne= w WG would study on existing solutions and ongoing proposals to make sure i= t is necessary to create new mechanisms. Coordination and awareness is esse= ntial for the ANIMA group. Best regards, Sheng ________________________________________ From: homenet [homenet-bounces@ietf.org] on behalf of Brian E Carpenter [br= ian.e.carpenter@gmail.com] Sent: 03 October 2014 5:47 To: Kathleen Moriarty Cc: Michael Behringer (mbehring); The IESG; homenet@ietf.org; Stephen Farre= ll; anima@ietf.org; Ted Lemon Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-0= 9: (with BLOCK) On 03/10/2014 04:12, Kathleen Moriarty wrote: > On Thu, Oct 2, 2014 at 9:15 AM, Stephen Farrell > wrote: > >> >> On 02/10/14 13:49, Michael Behringer (mbehring) wrote: >>> My personal goal is that what we do in ANIMA is fully compatible with >>> and ideally used in homenet. It would feel wrong to me to have an >>> infrastructure that doesn't work in a homenet. >>> >>> The security bootstrap is a good example of what we can achieve, with >>> reasonable effort. >> FWIW, it is not clear to me that the reasonable requirements >> for provisioning device security information (or bootstrapping >> if we wanted to call it that) are the same. >> > > This is where we would have overlap with SACM and I2NSF. I've spoken in > Ops and Dan R has helped to try to recruit some folks to help in SACM. I= t > would be good to not solve this in multiple places. SACM and I2NSF are > de-conflicting what they cover. Provisioning and assessing security > information is part of those efforts already, hence my questions on the > charter as well. > >> In enterprise environments we see fewer larger vendors of devices. >> In the home where we additionally have a large range of vendors >> many of whom are tiny and leverage a lot of OSS and who could >> perhaps not take part in the kind of provisioning infrastructure >> that is quite reasonable for enterprises and their vendors. >> > > There is a push in the vendor space for this type of automation and I'm a= ll > for it, let's just coordinate on it so we don't wind up with too many way= s > to do it. Absolutely. It isn't surprising that Anima proponents are proposing specific approaches to security (or anything else), but there is an overriding sentence in the charter: "Where suitable protocols, models or methods exist, they will be preferred = over creating new ones. " Clerarly that calls for coordination and awareness. Brian > > >> I do think both want to end up in the same state, where devices >> are authorised for connection to the network and where there is >> some keying material usable for security, but I'd be surprised >> if one approach to getting there worked the same way for both >> homes and enterprises. >> > > I'd like to see this discusses more, but maybe it's not in this group? > > Thanks, > Kathleen > >> S. >> >> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet= From nobody Thu Oct 2 18:33:19 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1DE1ACFC9; Thu, 2 Oct 2014 18:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BNy7VuiJrg7; Thu, 2 Oct 2014 18:33:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966551ACFC8; Thu, 2 Oct 2014 18:33:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNG54887; Fri, 03 Oct 2014 01:33:15 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 3 Oct 2014 02:33:14 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.22]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 3 Oct 2014 09:33:10 +0800 From: Sheng Jiang To: Toerless Eckert , "Leddy, John" Thread-Topic: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) Thread-Index: AQHP3k73zVVeo6T02Ei+yPEMRwZGjZwdlU2F Date: Fri, 3 Oct 2014 01:33:08 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF5E248@nkgeml512-mbx.china.huawei.com> References: <20141002144136.GA1847@cisco.com> In-Reply-To: <20141002144136.GA1847@cisco.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.18.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/B01aH1WummYJYIGYAM2Pg2F6rRg Cc: "Michael Behringer \(mbehring\)" , Ted Lemon , "homenet@ietf.org" , Stephen Farrell , "anima@ietf.org" , The IESG Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 01:33:19 -0000 I also think ISP networks and enterprise networks are different from home n= etworks. Although many requirements may looks similar, particularly conside= ring the auto operation target, there are many preconditions are different.= It could result on different solution though some components may be reusab= le among these networks. For ANIMA, we should surely study what homenet is working on and identify t= he differentia. Only after then, we can produce necessary solution with con= fusing the world. Best regards, Sheng ________________________________________ From: homenet [homenet-bounces@ietf.org] on behalf of Toerless Eckert [ecke= rt@cisco.com] Sent: 02 October 2014 22:41 To: Leddy, John Cc: Michael Behringer (mbehring); The IESG; homenet@ietf.org; Stephen Farre= ll; anima@ietf.org; Ted Lemon Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-0= 9: (with BLOCK) Fully agreed. But does this imply that we will make most progress by blocking out a working group that is actively chartered to look at the problems in the market segments Homenet is not addressing ? If the BLOCK is meant to suggest a charter improvements for anima to better define our mutual desire to share whatever is applicable and not reinvent unnecessarily, then where is the proposed charter text change = ? Cheers Toerless P.S.: Also, if i may throw in some random tidbit of technology thoughts: I love home networks (and the WG for it), because it is the best place for IPv6 to eliminate IPv4 and start creating fresh, better IP network. I have a lot of doubt that we are anywhere close to going that route especially in larger enterprises, so the address management for IPv4 in those networks is going to be a crucial requirement where i don't think homenet could (or should) be any big help. And i am not sure if i wou= ld want to hold my breath for a lot of IPv4 adress complexity reduction in IoT either. But certainly autonomic processes cold rather help than hurt in that matter. On Thu, Oct 02, 2014 at 01:50:13PM +0000, Leddy, John wrote: > My worry on this topic is that we are referring to =B3the Home=B2 and =B3= the > Enterprise=B2. > It isn=B9t that clear of a distinction. This isn=B9t just a simple L2 fl= at > home vs. a Fortune 1000 enterprise. > > The home is getting more complex and includes work from home; IOT, home > security, hot spots, cloud services, policies, discovery etc. > Large numbers of SMB=B9s look like more high end residential than they do > large enterprises. > > It would be ideal to have a solution that spans the range of size and > complexity for both residential and enterprise. > Perhaps enabling features/capabilities where required. > > Also, as far as IPV6 connectivity residential is probably ahead of > enterprises in adopting V6 centric architectures and services. > Residential doesn=B9t have much of a choice, it just happens. > > 2cents, John > > On 10/2/14, 9:15 AM, "Stephen Farrell" wrote: > > > > > > >On 02/10/14 13:49, Michael Behringer (mbehring) wrote: > >> My personal goal is that what we do in ANIMA is fully compatible with > >> and ideally used in homenet. It would feel wrong to me to have an > >> infrastructure that doesn't work in a homenet. > >> > >> The security bootstrap is a good example of what we can achieve, with > >> reasonable effort. > > > >FWIW, it is not clear to me that the reasonable requirements > >for provisioning device security information (or bootstrapping > >if we wanted to call it that) are the same. > > > >In enterprise environments we see fewer larger vendors of devices. > >In the home where we additionally have a large range of vendors > >many of whom are tiny and leverage a lot of OSS and who could > >perhaps not take part in the kind of provisioning infrastructure > >that is quite reasonable for enterprises and their vendors. > > > >I do think both want to end up in the same state, where devices > >are authorised for connection to the network and where there is > >some keying material usable for security, but I'd be surprised > >if one approach to getting there worked the same way for both > >homes and enterprises. > > > >S. > > _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet= From nobody Fri Oct 3 00:12:09 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD51F1A00EA; Fri, 3 Oct 2014 00:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJy1dyWgL9Kp; Fri, 3 Oct 2014 00:12:05 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D025A1A886D; Fri, 3 Oct 2014 00:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2102; q=dns/txt; s=iport; t=1412320325; x=1413529925; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ow7ZP+UwKh1UBttk9SAECtXbt9eNQKZ3GAV4/qeBOTQ=; b=GMOXUPPX+hv8m/NrcOIc3IwUbQhOlPbS4/2Cs69j/UJjwZ1aIR92Ofx5 m1W4BYJoXXaL5QX/ltEGXj+uYqgSlOvcQr50wEMMrIq63RdfJSkxe6c6e zXjabPOga0NDUwbMcbolyRSejFnxgeA1nlYhH+bNX2bFmsxYRvtUslJfQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFANhLLlStJA2K/2dsb2JhbABggw5TWATKagqGeVQCgQYWAXuEAwEBAQMBAQEBNzQLBQcEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQiILggNvj8BEwSPdTEHBoMngR4FkXShRIIggUNsgUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,645,1406592000"; d="scan'208";a="83640560" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP; 03 Oct 2014 07:12:04 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s937C467004827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Oct 2014 07:12:04 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.204]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Fri, 3 Oct 2014 02:12:03 -0500 From: "Michael Behringer (mbehring)" To: Stephen Farrell , Ted Lemon , The IESG Thread-Topic: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) Thread-Index: AQHP3jVHokqaa0NBjkebeYQrfyizUZwcvPCwgABgRoCAANfw4A== Date: Fri, 3 Oct 2014 07:12:03 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21C5A650@xmb-rcd-x14.cisco.com> References: <20141002113735.6068.22745.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21C59B2B@xmb-rcd-x14.cisco.com> <542D4FE3.2010607@cs.tcd.ie> In-Reply-To: <542D4FE3.2010607@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/1oZFyUO1PLL9PTnNTtFi9dY3tCg Cc: "homenet@ietf.org" , "anima@ietf.org" Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 07:12:07 -0000 > -----Original Message----- > From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of Stephen > Farrell > Sent: 02 October 2014 15:15 > To: Michael Behringer (mbehring); Ted Lemon; The IESG > Cc: homenet@ietf.org; anima@ietf.org > Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima- > 00-09: (with BLOCK) >=20 >=20 >=20 > On 02/10/14 13:49, Michael Behringer (mbehring) wrote: > > My personal goal is that what we do in ANIMA is fully compatible with > > and ideally used in homenet. It would feel wrong to me to have an > > infrastructure that doesn't work in a homenet. > > > > The security bootstrap is a good example of what we can achieve, with > > reasonable effort. >=20 > FWIW, it is not clear to me that the reasonable requirements for > provisioning device security information (or bootstrapping if we wanted t= o > call it that) are the same. >=20 > In enterprise environments we see fewer larger vendors of devices. > In the home where we additionally have a large range of vendors many of > whom are tiny and leverage a lot of OSS and who could perhaps not take > part in the kind of provisioning infrastructure that is quite reasonable = for > enterprises and their vendors. >=20 > I do think both want to end up in the same state, where devices are > authorised for connection to the network and where there is some keying > material usable for security, but I'd be surprised if one approach to get= ting > there worked the same way for both homes and enterprises. Good points, thanks Stephen. I don't think we have clear answers at this po= int, but this is the job of the ANIMA group (together with the groups that = were mentioned) to figure out whether there should be a single approach, an= d if so, what it should be.=20 =20 Personally my starting point is "let's try whether a joint approach works",= but clearly there is no guarantee.=20 Michael > S. >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Fri Oct 3 00:31:51 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565DA1A19FA; Thu, 2 Oct 2014 08:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQUqJ41Oa74R; Thu, 2 Oct 2014 08:12:51 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 896011A0052; Thu, 2 Oct 2014 08:12:50 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id l4so2402827lbv.40 for ; Thu, 02 Oct 2014 08:12:48 -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; bh=u1nyXU/Z/lNcymRPBjuB0uFBJ/5dggsVUoKsJH3x6w8=; b=mS1a3iaqAxRpo7EkwxmqbU0INmdIkh6a8GIWnDMELsHWEFXSbmHdJrqmWHnfFkJzv3 OoK4RK7FBLy5jwxxMFmANfqUC61mwuTkYk8gIzy4B114x9HZCCbepkBlTNtWwwLhDZoj zCSgH7k4JlT02XWm8DdFH7aOr/pKoiyyOUDztDHt69nnierjt0e9AUJO3zyFjmVK+zkb TYNC4BXsRUrr3e1rrHQjSqsrVZMOY+qB6Fj7RwqE1EpzDlFZppU5LygBz38l/qVPvydd pbvrytD/8kWEM0BKMFL+yz7eyZKYMQAX4oGWu/mFxE2zHEDMXt6muPlE7ypKYsJjeUoe C0yw== MIME-Version: 1.0 X-Received: by 10.152.87.170 with SMTP id az10mr63865811lab.20.1412262768623; Thu, 02 Oct 2014 08:12:48 -0700 (PDT) Received: by 10.112.95.36 with HTTP; Thu, 2 Oct 2014 08:12:48 -0700 (PDT) In-Reply-To: <542D4FE3.2010607@cs.tcd.ie> References: <20141002113735.6068.22745.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21C59B2B@xmb-rcd-x14.cisco.com> <542D4FE3.2010607@cs.tcd.ie> Date: Thu, 2 Oct 2014 11:12:48 -0400 Message-ID: From: Kathleen Moriarty To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c223b6a743840504720cdf Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/w5oICgJzFcw7whsdtmHGVWMidY0 X-Mailman-Approved-At: Fri, 03 Oct 2014 00:31:47 -0700 Cc: "anima@ietf.org" , "homenet@ietf.org" , Ted Lemon , "Michael Behringer \(mbehring\)" , The IESG Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 15:12:54 -0000 --001a11c223b6a743840504720cdf Content-Type: text/plain; charset=UTF-8 On Thu, Oct 2, 2014 at 9:15 AM, Stephen Farrell wrote: > > > On 02/10/14 13:49, Michael Behringer (mbehring) wrote: > > My personal goal is that what we do in ANIMA is fully compatible with > > and ideally used in homenet. It would feel wrong to me to have an > > infrastructure that doesn't work in a homenet. > > > > The security bootstrap is a good example of what we can achieve, with > > reasonable effort. > > FWIW, it is not clear to me that the reasonable requirements > for provisioning device security information (or bootstrapping > if we wanted to call it that) are the same. > This is where we would have overlap with SACM and I2NSF. I've spoken in Ops and Dan R has helped to try to recruit some folks to help in SACM. It would be good to not solve this in multiple places. SACM and I2NSF are de-conflicting what they cover. Provisioning and assessing security information is part of those efforts already, hence my questions on the charter as well. > > In enterprise environments we see fewer larger vendors of devices. > In the home where we additionally have a large range of vendors > many of whom are tiny and leverage a lot of OSS and who could > perhaps not take part in the kind of provisioning infrastructure > that is quite reasonable for enterprises and their vendors. > There is a push in the vendor space for this type of automation and I'm all for it, let's just coordinate on it so we don't wind up with too many ways to do it. > > I do think both want to end up in the same state, where devices > are authorised for connection to the network and where there is > some keying material usable for security, but I'd be surprised > if one approach to getting there worked the same way for both > homes and enterprises. > I'd like to see this discusses more, but maybe it's not in this group? Thanks, Kathleen > > S. > > -- Best regards, Kathleen --001a11c223b6a743840504720cdf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 2, 2014 at 9:15 AM, Stephen Farrell <<= a href=3D"mailto:stephen.farrell@cs.tcd.ie" target=3D"_blank">stephen.farre= ll@cs.tcd.ie> wrote:


On 02/10/14 13:49, Michael Behringer (mbehring) wrote:
> My personal goal is that what we do in ANIMA is fully compatible with<= br> > and ideally used in homenet. It would feel wrong to me to have an
> infrastructure that doesn't work in a homenet.
>
> The security bootstrap is a good example of what we can achieve, with<= br> > reasonable effort.

FWIW, it is not clear to me that the reasonable requirements
for provisioning device security information (or bootstrapping
if we wanted to call it that) are the same.

=
This is where we would have overlap with SACM and I2NSF.=C2=A0 I'v= e spoken in Ops and Dan R has helped to try to recruit some folks to help i= n SACM.=C2=A0 It would be good to not solve this in multiple places.=C2=A0 = SACM and I2NSF are de-conflicting what they cover.=C2=A0 Provisioning and a= ssessing security information is part of those efforts already, hence my qu= estions on the charter as well.

In enterprise environments we see fewer larger vendors of devices.
In the home where we additionally have a large range of vendors
many of whom are tiny and leverage a lot of OSS and who could
perhaps not take part in the kind of provisioning infrastructure
that is quite reasonable for enterprises and their vendors.

There is a push in the vendor space for this type of a= utomation and I'm all for it, let's just coordinate on it so we don= 't wind up with too many ways to do it.
=C2=A0

I do think both want to end up in the same state, where devices
are authorised for connection to the network and where there is
some keying material usable for security, but I'd be surprised
if one approach to getting there worked the same way for both
homes and enterprises.

I'd like to = see this discusses more, but maybe it's not in this group?
Thanks,
Kathleen=C2=A0

S.




--

Best regards,
Kathleen
--001a11c223b6a743840504720cdf-- From nobody Fri Oct 3 06:39:15 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88FE91A1A94; Fri, 3 Oct 2014 06:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-V4t4LlLEC2; Fri, 3 Oct 2014 06:39:10 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E3891A1A2D; Fri, 3 Oct 2014 06:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7046; q=dns/txt; s=iport; t=1412343550; x=1413553150; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=D04q28daGTPAytSCjCNTsmuCosugiVhJ9pe9mbV/cWk=; b=YXL9PGp/kmBnh95EdfQvYabm1BOnqPnv5fQua5dDs8IK30nviz82jV2F NEUVFrYhPL3COrPkkrvGag4fbBnEg/zE2PAAXo0c4T3NMQrFbD/uarL8g hongltL/+8UAHfXR7l9UJxcJaGEIko/pP7/SMKorRsUTV4/ZtI2zq6It8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAEemLlStJV2P/2dsb2JhbABWCoMOU1gEgn7HdgqGeVQCGXEWAXuEAwEBAQQBAQExOgsQAgEIEQQBAQEEKAICJQsdCAIEAQ0FG4gjDYxRnEQGlX8BEwSBJokShRopGBsHgnGBWgWRdItKlgCCIIFDbIFIgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,647,1406592000"; d="scan'208";a="83782214" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP; 03 Oct 2014 13:39:09 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s93Dd9ux017353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Oct 2014 13:39:09 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Fri, 3 Oct 2014 08:39:09 -0500 From: "Acee Lindem (acee)" To: Sheng Jiang , "Toerless Eckert (eckert)" , "Leddy, John" Thread-Topic: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) Thread-Index: AQHP3k73okqaa0NBjkebeYQrfyizUZwd6ywAgACHyIA= Date: Fri, 3 Oct 2014 13:39:08 +0000 Message-ID: References: <20141002144136.GA1847@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AF5E248@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AF5E248@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="euc-kr" Content-ID: <8FA2558C15398048AF522B64B7110B00@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/xe5JBcfvkPnt-fyNz7OoD18YLG4 Cc: "Michael Behringer \(mbehring\)" , The IESG , "homenet@ietf.org" , Stephen Farrell , "anima@ietf.org" , Ted Lemon Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 13:39:12 -0000 T25lIHRoaW5nIHdlIG5lZWQgdG8gZG8gaW4gaG9tZW5ldCBpcyBhZ3JlZSBvbiB0aGUgbmV0d29y ayBhZG1pbmlzdHJhdGlvbg0KbW9kZWwuIEkgYmVsaWV2ZSBtYW55IG9mIHVzIHN0YXJ0ZWQgd2l0 aCB0aGUgYXNzdW1wdGlvbiBvZiBwbHVnIGFuZCBwbGF5DQpidXQgYXJlIG5vdyBhY2NlcHRpbmcg dGhlIGZhY3QgdGhhdCBtaW5pbWFsIGNvbmZpZ3VyYXRpb24gd2lsbCBiZSByZXF1aXJlZA0KdG8g dmV0IGRldmljZXMgb24gdGhlIGhvbWVuZXQuIElmIHdlIGNhbiBhZ3JlZSBvbiBzaW1pbGFyIG5l dHdvcmsgYWRtaW4NCm1vZGVscyBhbmQsIGFzIFRlZCBwb2ludGVkIG91dCwgcmVxdWlyZW1lbnRz IG9uIGNvbm5lY3RpbmcgZGV2aWNlcywgdGhlbg0Kd2UgYmUgbWF5IGFibGUgdG8gdXNlIHNpbWls YXIgc29sdXRpb25zLg0KDQpBY2VlIA0KDQpPbiAxMC8yLzE0LCA5OjMzIFBNLCAiU2hlbmcgSmlh bmciIDxqaWFuZ3NoZW5nQGh1YXdlaS5jb20+IHdyb3RlOg0KDQo+SSBhbHNvIHRoaW5rIElTUCBu ZXR3b3JrcyBhbmQgZW50ZXJwcmlzZSBuZXR3b3JrcyBhcmUgZGlmZmVyZW50IGZyb20gaG9tZQ0K Pm5ldHdvcmtzLiBBbHRob3VnaCBtYW55IHJlcXVpcmVtZW50cyBtYXkgbG9va3Mgc2ltaWxhciwg cGFydGljdWxhcmx5DQo+Y29uc2lkZXJpbmcgdGhlIGF1dG8gb3BlcmF0aW9uIHRhcmdldCwgdGhl cmUgYXJlIG1hbnkgcHJlY29uZGl0aW9ucyBhcmUNCj5kaWZmZXJlbnQuIEl0IGNvdWxkIHJlc3Vs dCBvbiBkaWZmZXJlbnQgc29sdXRpb24gdGhvdWdoIHNvbWUgY29tcG9uZW50cw0KPm1heSBiZSBy ZXVzYWJsZSBhbW9uZyB0aGVzZSBuZXR3b3Jrcy4NCj4NCj5Gb3IgQU5JTUEsIHdlIHNob3VsZCBz dXJlbHkgc3R1ZHkgd2hhdCBob21lbmV0IGlzIHdvcmtpbmcgb24gYW5kIGlkZW50aWZ5DQo+dGhl IGRpZmZlcmVudGlhLiBPbmx5IGFmdGVyIHRoZW4sIHdlIGNhbiBwcm9kdWNlIG5lY2Vzc2FyeSBz b2x1dGlvbiB3aXRoDQo+Y29uZnVzaW5nIHRoZSB3b3JsZC4NCj4NCj5CZXN0IHJlZ2FyZHMsDQo+ DQo+U2hlbmcNCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+RnJv bTogaG9tZW5ldCBbaG9tZW5ldC1ib3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgVG9lcmxl c3MgRWNrZXJ0DQo+W2Vja2VydEBjaXNjby5jb21dDQo+U2VudDogMDIgT2N0b2JlciAyMDE0IDIy OjQxDQo+VG86IExlZGR5LCBKb2huDQo+Q2M6IE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZyk7 IFRoZSBJRVNHOyBob21lbmV0QGlldGYub3JnOyBTdGVwaGVuDQo+RmFycmVsbDsgYW5pbWFAaWV0 Zi5vcmc7IFRlZCBMZW1vbg0KPlN1YmplY3Q6IFJlOiBbaG9tZW5ldF0gW0FuaW1hXSBUZWQgTGVt b24ncyBCbG9jayBvbg0KPmNoYXJ0ZXItaWV0Zi1hbmltYS0wMC0wOTogKHdpdGggQkxPQ0spDQo+ DQo+RnVsbHkgYWdyZWVkLiBCdXQgZG9lcyB0aGlzIGltcGx5IHRoYXQgd2Ugd2lsbCBtYWtlIG1v c3QgcHJvZ3Jlc3MgYnkNCj5ibG9ja2luZyBvdXQgYSB3b3JraW5nIGdyb3VwIHRoYXQgaXMgYWN0 aXZlbHkgY2hhcnRlcmVkIHRvIGxvb2sgYXQNCj50aGUgcHJvYmxlbXMgaW4gdGhlIG1hcmtldCBz ZWdtZW50cyBIb21lbmV0IGlzIG5vdCBhZGRyZXNzaW5nID8NCj4NCj5JZiB0aGUgQkxPQ0sgaXMg bWVhbnQgdG8gc3VnZ2VzdCBhIGNoYXJ0ZXIgaW1wcm92ZW1lbnRzIGZvciBhbmltYSB0bw0KPmJl dHRlciBkZWZpbmUgb3VyIG11dHVhbCBkZXNpcmUgdG8gc2hhcmUgd2hhdGV2ZXIgaXMgYXBwbGlj YWJsZSBhbmQNCj5ub3QgcmVpbnZlbnQgdW5uZWNlc3NhcmlseSwgdGhlbiB3aGVyZSBpcyB0aGUg cHJvcG9zZWQgY2hhcnRlciB0ZXh0DQo+Y2hhbmdlID8NCj4NCj5DaGVlcnMNCj4gICAgVG9lcmxl c3MNCj4NCj5QLlMuOiBBbHNvLCBpZiBpIG1heSB0aHJvdyBpbiBzb21lIHJhbmRvbSB0aWRiaXQg b2YgdGVjaG5vbG9neSB0aG91Z2h0czoNCj4NCj5JIGxvdmUgaG9tZSBuZXR3b3JrcyAoYW5kIHRo ZSBXRyBmb3IgaXQpLCBiZWNhdXNlIGl0IGlzIHRoZSBiZXN0IHBsYWNlDQo+Zm9yIElQdjYgdG8g ZWxpbWluYXRlIElQdjQgYW5kIHN0YXJ0IGNyZWF0aW5nIGZyZXNoLCBiZXR0ZXIgSVANCj5uZXR3 b3JrLiBJIGhhdmUgYSBsb3Qgb2YgZG91YnQgdGhhdCB3ZSBhcmUgYW55d2hlcmUgY2xvc2UgdG8g Z29pbmcgdGhhdA0KPnJvdXRlIGVzcGVjaWFsbHkgaW4gbGFyZ2VyIGVudGVycHJpc2VzLCBzbyB0 aGUgYWRkcmVzcyBtYW5hZ2VtZW50IGZvcg0KPklQdjQgaW4gdGhvc2UgbmV0d29ya3MgaXMgZ29p bmcgdG8gYmUgYSBjcnVjaWFsIHJlcXVpcmVtZW50IHdoZXJlIGkgZG9uJ3QNCj50aGluayBob21l bmV0IGNvdWxkIChvciBzaG91bGQpIGJlIGFueSBiaWcgaGVscC4gQW5kIGkgYW0gbm90IHN1cmUg aWYgaQ0KPndvdWxkDQo+d2FudCB0byBob2xkIG15IGJyZWF0aCBmb3IgYSBsb3Qgb2YgSVB2NCBh ZHJlc3MgY29tcGxleGl0eSByZWR1Y3Rpb24gaW4NCj5Jb1QgZWl0aGVyLiBCdXQgY2VydGFpbmx5 IGF1dG9ub21pYyBwcm9jZXNzZXMgY29sZCByYXRoZXIgaGVscCB0aGFuIGh1cnQNCj5pbiB0aGF0 IG1hdHRlci4NCj4NCj4NCj5PbiBUaHUsIE9jdCAwMiwgMjAxNCBhdCAwMTo1MDoxM1BNICswMDAw LCBMZWRkeSwgSm9obiB3cm90ZToNCj4+IE15IHdvcnJ5IG9uIHRoaXMgdG9waWMgaXMgdGhhdCB3 ZSBhcmUgcmVmZXJyaW5nIHRvIKn4dGhlIEhvbWWp9yBhbmQgqfh0aGUNCj4+IEVudGVycHJpc2Wp 9y4NCj4+IEl0IGlzbqn2dCB0aGF0IGNsZWFyIG9mIGEgZGlzdGluY3Rpb24uICBUaGlzIGlzbqn2 dCBqdXN0IGEgc2ltcGxlIEwyIGZsYXQNCj4+IGhvbWUgdnMuIGEgRm9ydHVuZSAxMDAwIGVudGVy cHJpc2UuDQo+Pg0KPj4gVGhlIGhvbWUgaXMgZ2V0dGluZyBtb3JlIGNvbXBsZXggYW5kIGluY2x1 ZGVzIHdvcmsgZnJvbSBob21lOyBJT1QsIGhvbWUNCj4+IHNlY3VyaXR5LCBob3Qgc3BvdHMsIGNs b3VkIHNlcnZpY2VzLCBwb2xpY2llcywgZGlzY292ZXJ5IGV0Yy4NCj4+IExhcmdlIG51bWJlcnMg b2YgU01CqfZzIGxvb2sgbGlrZSBtb3JlIGhpZ2ggZW5kIHJlc2lkZW50aWFsIHRoYW4gdGhleSBk bw0KPj4gbGFyZ2UgZW50ZXJwcmlzZXMuDQo+Pg0KPj4gSXQgd291bGQgYmUgaWRlYWwgdG8gaGF2 ZSBhIHNvbHV0aW9uIHRoYXQgc3BhbnMgdGhlIHJhbmdlIG9mIHNpemUgYW5kDQo+PiBjb21wbGV4 aXR5IGZvciBib3RoIHJlc2lkZW50aWFsIGFuZCBlbnRlcnByaXNlLg0KPj4gUGVyaGFwcyBlbmFi bGluZyBmZWF0dXJlcy9jYXBhYmlsaXRpZXMgd2hlcmUgcmVxdWlyZWQuDQo+Pg0KPj4gQWxzbywg YXMgZmFyIGFzIElQVjYgY29ubmVjdGl2aXR5IHJlc2lkZW50aWFsIGlzIHByb2JhYmx5IGFoZWFk IG9mDQo+PiBlbnRlcnByaXNlcyBpbiBhZG9wdGluZyBWNiBjZW50cmljIGFyY2hpdGVjdHVyZXMg YW5kIHNlcnZpY2VzLg0KPj4gUmVzaWRlbnRpYWwgZG9lc26p9nQgaGF2ZSBtdWNoIG9mIGEgY2hv aWNlLCBpdCBqdXN0IGhhcHBlbnMuDQo+Pg0KPj4gMmNlbnRzLCBKb2huDQo+Pg0KPj4gT24gMTAv Mi8xNCwgOToxNSBBTSwgIlN0ZXBoZW4gRmFycmVsbCIgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2Qu aWU+DQo+Pndyb3RlOg0KPj4NCj4+ID4NCj4+ID4NCj4+ID5PbiAwMi8xMC8xNCAxMzo0OSwgTWlj aGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKSB3cm90ZToNCj4+ID4+IE15IHBlcnNvbmFsIGdvYWwg aXMgdGhhdCB3aGF0IHdlIGRvIGluIEFOSU1BIGlzIGZ1bGx5IGNvbXBhdGlibGUgd2l0aA0KPj4g Pj4gYW5kIGlkZWFsbHkgdXNlZCBpbiBob21lbmV0LiBJdCB3b3VsZCBmZWVsIHdyb25nIHRvIG1l IHRvIGhhdmUgYW4NCj4+ID4+IGluZnJhc3RydWN0dXJlIHRoYXQgZG9lc24ndCB3b3JrIGluIGEg aG9tZW5ldC4NCj4+ID4+DQo+PiA+PiBUaGUgc2VjdXJpdHkgYm9vdHN0cmFwIGlzIGEgZ29vZCBl eGFtcGxlIG9mIHdoYXQgd2UgY2FuIGFjaGlldmUsIHdpdGgNCj4+ID4+IHJlYXNvbmFibGUgZWZm b3J0Lg0KPj4gPg0KPj4gPkZXSVcsIGl0IGlzIG5vdCBjbGVhciB0byBtZSB0aGF0IHRoZSByZWFz b25hYmxlIHJlcXVpcmVtZW50cw0KPj4gPmZvciBwcm92aXNpb25pbmcgZGV2aWNlIHNlY3VyaXR5 IGluZm9ybWF0aW9uIChvciBib290c3RyYXBwaW5nDQo+PiA+aWYgd2Ugd2FudGVkIHRvIGNhbGwg aXQgdGhhdCkgYXJlIHRoZSBzYW1lLg0KPj4gPg0KPj4gPkluIGVudGVycHJpc2UgZW52aXJvbm1l bnRzIHdlIHNlZSBmZXdlciBsYXJnZXIgdmVuZG9ycyBvZiBkZXZpY2VzLg0KPj4gPkluIHRoZSBo b21lIHdoZXJlIHdlIGFkZGl0aW9uYWxseSBoYXZlIGEgbGFyZ2UgcmFuZ2Ugb2YgdmVuZG9ycw0K Pj4gPm1hbnkgb2Ygd2hvbSBhcmUgdGlueSBhbmQgbGV2ZXJhZ2UgYSBsb3Qgb2YgT1NTIGFuZCB3 aG8gY291bGQNCj4+ID5wZXJoYXBzIG5vdCB0YWtlIHBhcnQgaW4gdGhlIGtpbmQgb2YgcHJvdmlz aW9uaW5nIGluZnJhc3RydWN0dXJlDQo+PiA+dGhhdCBpcyBxdWl0ZSByZWFzb25hYmxlIGZvciBl bnRlcnByaXNlcyBhbmQgdGhlaXIgdmVuZG9ycy4NCj4+ID4NCj4+ID5JIGRvIHRoaW5rIGJvdGgg d2FudCB0byBlbmQgdXAgaW4gdGhlIHNhbWUgc3RhdGUsIHdoZXJlIGRldmljZXMNCj4+ID5hcmUg YXV0aG9yaXNlZCBmb3IgY29ubmVjdGlvbiB0byB0aGUgbmV0d29yayBhbmQgd2hlcmUgdGhlcmUg aXMNCj4+ID5zb21lIGtleWluZyBtYXRlcmlhbCB1c2FibGUgZm9yIHNlY3VyaXR5LCBidXQgSSdk IGJlIHN1cnByaXNlZA0KPj4gPmlmIG9uZSBhcHByb2FjaCB0byBnZXR0aW5nIHRoZXJlIHdvcmtl ZCB0aGUgc2FtZSB3YXkgZm9yIGJvdGgNCj4+ID5ob21lcyBhbmQgZW50ZXJwcmlzZXMuDQo+PiA+ DQo+PiA+Uy4NCj4+ID4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPmhvbWVuZXQgbWFpbGluZyBsaXN0DQo+aG9tZW5ldEBpZXRmLm9yZw0KPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaG9tZW5ldA0KPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+aG9tZW5ldCBtYWlsaW5nIGxp c3QNCj5ob21lbmV0QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ob21lbmV0DQoNCg== From nobody Fri Oct 3 11:38:44 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D601A888F for ; Fri, 3 Oct 2014 11:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJNPgGyJCHzs for ; Fri, 3 Oct 2014 11:38:42 -0700 (PDT) Received: from chi.subsignal.org (cxd-2-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:ed::2]) by ietfa.amsl.com (Postfix) with ESMTP id E3BFF1A8884 for ; Fri, 3 Oct 2014 11:38:41 -0700 (PDT) Received: from [192.168.2.104] (p54B7B56A.dip0.t-ipconnect.de [84.183.181.106]) by chi.subsignal.org (Postfix) with ESMTPSA id 5FD8C1260C8 for ; Fri, 3 Oct 2014 20:39:47 +0200 (CEST) Message-ID: <542EED2F.6000501@openwrt.org> Date: Fri, 03 Oct 2014 20:38:39 +0200 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "homenet@ietf.org Group" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/V0u2Xme8uZDscx_chG6ekLrtFGs Subject: [homenet] HNCP Security & Trust Draft X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 18:38:43 -0000 Hi everyone, I took the last few days to gather some thoughts about threats, security and trust management in the context of HNCP and wrote it up under http://tools.ietf.org/html/draft-barth-homenet-hncp-security-trust-00 Quick overview over the topics: * Homenet Border * HNCP Payload Security * Trust Management * IGP-Considerations Please note that this draft is in a very early stage so please help to make additions, provide feedback and point out mistakes. Regards, Steven From nobody Fri Oct 3 16:34:47 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7241A86EC; Fri, 3 Oct 2014 16:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE9DhpTR4ehR; Fri, 3 Oct 2014 16:34:39 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0461A702E; Fri, 3 Oct 2014 16:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8626; q=dns/txt; s=iport; t=1412379279; x=1413588879; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Oec2dp59xK61qp7UIUUFWU3Kuk+lwexRbx6PdzqOOhw=; b=EXE/XwARJbKQQR47aRK+/fDjTcTdQs/n7LSMP60t1i4S+pF1NCDSfnF+ DWt84ev85o42OvGgAkXDtABNS4j2UzHxb6x4UPJSOG0g0WQzmKXFPwa3q s/p7kdpomcHVRW/8lfVflIGRJfZokEh+J0u1lCdIRbHTWuQiZ2YuMyMtZ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAPsxL1StJV2b/2dsb2JhbABWCoMOU00LBIJ+yAYKhnlUAhluFgF7hAMBAQEDAQEBATE6CwULAgEIEQQBAQEEFBQCAiULHQgCBAoEBRuIGwgNjEmcRAaWCAETBIEmiRKFGkEbBxiCWTyBHgWRdItKlgCCIIFDbIFIgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,651,1406592000"; d="scan'208";a="83925638" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 03 Oct 2014 23:34:38 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s93NYcpo008699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Oct 2014 23:34:38 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.49]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Fri, 3 Oct 2014 18:34:37 -0500 From: "Mark Baugher (mbaugher)" To: "Acee Lindem (acee)" Thread-Topic: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) Thread-Index: AQHP3k73okqaa0NBjkebeYQrfyizUZwd6ywAgACHyICAAOlwgA== Date: Fri, 3 Oct 2014 23:34:37 +0000 Message-ID: <7A9C7BA6-E8DD-48F0-9B0E-CC2F36CBA05A@cisco.com> References: <20141002144136.GA1847@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AF5E248@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.149.58] Content-Type: text/plain; charset="euc-kr" Content-ID: <0B22463189BCBB4FA7B0B59249AD2DB6@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/_A2LzyZuNx75yyq6VXkkqQPQoSI Cc: "Toerless Eckert \(eckert\)" , Ted Lemon , "Leddy, John" , "Michael Behringer \(mbehring\)" , The IESG , "homenet@ietf.org" , Stephen Farrell , "anima@ietf.org" , Sheng Jiang Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 23:34:42 -0000 SSB2b2ljZWQgdGhlIG9waW5pb24gdGhhdCBzb21lb25lIGhhcyB0byBvd24gdGhlIGhvbWVuZXQs IGFzIGRpc3RpbmN0DQpmcm9tIHdobyBtaWdodCBvd24gdGhlIENQRXMgYW5kIHJvdXRlcnMgb24g dGhlIGhvbWVuZXQuICBJbiB0aGUgc2FtZQ0Kd2F5IHRoYXQgc29tZSBJU1AgQ1BFcyBsZXQgdGhl IHVzZXIgc2V0IHRoZSBXaS1GaSBwYXNzd29yZCwgdGhlIHVzZXIgb3INCmFuIGFnZW50IGZvciB0 aGUgdXNlIG5lZWRzIHRvIHRha2UgaG9tZW5ldCBvd25lcnNoaXAgKG9yIGluIHRoZSBjYXNlIG9m DQphdXRvbm9taWMgZGV2aWNlcywgdHJhbnNmZXIgb3duZXJzaGlwKS4gIFRoaXMgY2Fubm90IGJl IGRvbmUgcGx1Zw0KYW5kIHBsYXksIHRoZXJlIG5lZWRzIHRvIGJlIHNvbWUgY2VyZW1vbnkuICBJ dCdzIGVuY291cmFnaW5nIHRoYXQNCnRoZSB2YXN0IG1ham9yaXR5IG9mIHVzZXJzIGluIGhvbWVz LCBzbWFsbCBvZmZpY2VzIGFuZCBzbWFsbCBidXNpbmVzc2VzDQptYW5hZ2UgdG8gY29uZmlndXJl IHRoZWlyIFdpLUZpIFByb3RlY3RlZCBBY2Nlc3MuICBTb21lIGNlcmVtb25pZXMNCndvcmsgdG8g aW1wcm92ZSBwcml2YWN5IGFuZCBzZWN1cml0eS4gDQoNClRoZSBob21lIG5ldHdvcmsgbmVlZHMg dG8gYmUgb3duZWQgYnkgdGhlIGhvbWUgdXNlcihzKSBvciBhZ2VudCAoY291bGQgDQpiZSB0aGUg SVNQIG9yIHNvbWUgb3Zlci10aGUtdG9wIHJldGFpbCBzb2x1dGlvbiwgZXRjLikuDQoNCk1hcmsN Cg0KT24gT2N0IDMsIDIwMTQsIGF0IDY6MzkgQU0sIEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBj aXNjby5jb20+IHdyb3RlOg0KDQo+IE9uZSB0aGluZyB3ZSBuZWVkIHRvIGRvIGluIGhvbWVuZXQg aXMgYWdyZWUgb24gdGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRpb24NCj4gbW9kZWwuIEkgYmVsaWV2 ZSBtYW55IG9mIHVzIHN0YXJ0ZWQgd2l0aCB0aGUgYXNzdW1wdGlvbiBvZiBwbHVnIGFuZCBwbGF5 DQo+IGJ1dCBhcmUgbm93IGFjY2VwdGluZyB0aGUgZmFjdCB0aGF0IG1pbmltYWwgY29uZmlndXJh dGlvbiB3aWxsIGJlIHJlcXVpcmVkDQo+IHRvIHZldCBkZXZpY2VzIG9uIHRoZSBob21lbmV0LiBJ ZiB3ZSBjYW4gYWdyZWUgb24gc2ltaWxhciBuZXR3b3JrIGFkbWluDQo+IG1vZGVscyBhbmQsIGFz IFRlZCBwb2ludGVkIG91dCwgcmVxdWlyZW1lbnRzIG9uIGNvbm5lY3RpbmcgZGV2aWNlcywgdGhl bg0KPiB3ZSBiZSBtYXkgYWJsZSB0byB1c2Ugc2ltaWxhciBzb2x1dGlvbnMuDQo+IA0KPiBBY2Vl IA0KPiANCj4gT24gMTAvMi8xNCwgOTozMyBQTSwgIlNoZW5nIEppYW5nIiA8amlhbmdzaGVuZ0Bo dWF3ZWkuY29tPiB3cm90ZToNCj4gDQo+PiBJIGFsc28gdGhpbmsgSVNQIG5ldHdvcmtzIGFuZCBl bnRlcnByaXNlIG5ldHdvcmtzIGFyZSBkaWZmZXJlbnQgZnJvbSBob21lDQo+PiBuZXR3b3Jrcy4g QWx0aG91Z2ggbWFueSByZXF1aXJlbWVudHMgbWF5IGxvb2tzIHNpbWlsYXIsIHBhcnRpY3VsYXJs eQ0KPj4gY29uc2lkZXJpbmcgdGhlIGF1dG8gb3BlcmF0aW9uIHRhcmdldCwgdGhlcmUgYXJlIG1h bnkgcHJlY29uZGl0aW9ucyBhcmUNCj4+IGRpZmZlcmVudC4gSXQgY291bGQgcmVzdWx0IG9uIGRp ZmZlcmVudCBzb2x1dGlvbiB0aG91Z2ggc29tZSBjb21wb25lbnRzDQo+PiBtYXkgYmUgcmV1c2Fi bGUgYW1vbmcgdGhlc2UgbmV0d29ya3MuDQo+PiANCj4+IEZvciBBTklNQSwgd2Ugc2hvdWxkIHN1 cmVseSBzdHVkeSB3aGF0IGhvbWVuZXQgaXMgd29ya2luZyBvbiBhbmQgaWRlbnRpZnkNCj4+IHRo ZSBkaWZmZXJlbnRpYS4gT25seSBhZnRlciB0aGVuLCB3ZSBjYW4gcHJvZHVjZSBuZWNlc3Nhcnkg c29sdXRpb24gd2l0aA0KPj4gY29uZnVzaW5nIHRoZSB3b3JsZC4NCj4+IA0KPj4gQmVzdCByZWdh cmRzLA0KPj4gDQo+PiBTaGVuZw0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gRnJvbTogaG9tZW5ldCBbaG9tZW5ldC1ib3VuY2VzQGlldGYub3JnXSBvbiBi ZWhhbGYgb2YgVG9lcmxlc3MgRWNrZXJ0DQo+PiBbZWNrZXJ0QGNpc2NvLmNvbV0NCj4+IFNlbnQ6 IDAyIE9jdG9iZXIgMjAxNCAyMjo0MQ0KPj4gVG86IExlZGR5LCBKb2huDQo+PiBDYzogTWljaGFl bCBCZWhyaW5nZXIgKG1iZWhyaW5nKTsgVGhlIElFU0c7IGhvbWVuZXRAaWV0Zi5vcmc7IFN0ZXBo ZW4NCj4+IEZhcnJlbGw7IGFuaW1hQGlldGYub3JnOyBUZWQgTGVtb24NCj4+IFN1YmplY3Q6IFJl OiBbaG9tZW5ldF0gW0FuaW1hXSBUZWQgTGVtb24ncyBCbG9jayBvbg0KPj4gY2hhcnRlci1pZXRm LWFuaW1hLTAwLTA5OiAod2l0aCBCTE9DSykNCj4+IA0KPj4gRnVsbHkgYWdyZWVkLiBCdXQgZG9l cyB0aGlzIGltcGx5IHRoYXQgd2Ugd2lsbCBtYWtlIG1vc3QgcHJvZ3Jlc3MgYnkNCj4+IGJsb2Nr aW5nIG91dCBhIHdvcmtpbmcgZ3JvdXAgdGhhdCBpcyBhY3RpdmVseSBjaGFydGVyZWQgdG8gbG9v ayBhdA0KPj4gdGhlIHByb2JsZW1zIGluIHRoZSBtYXJrZXQgc2VnbWVudHMgSG9tZW5ldCBpcyBu b3QgYWRkcmVzc2luZyA/DQo+PiANCj4+IElmIHRoZSBCTE9DSyBpcyBtZWFudCB0byBzdWdnZXN0 IGEgY2hhcnRlciBpbXByb3ZlbWVudHMgZm9yIGFuaW1hIHRvDQo+PiBiZXR0ZXIgZGVmaW5lIG91 ciBtdXR1YWwgZGVzaXJlIHRvIHNoYXJlIHdoYXRldmVyIGlzIGFwcGxpY2FibGUgYW5kDQo+PiBu b3QgcmVpbnZlbnQgdW5uZWNlc3NhcmlseSwgdGhlbiB3aGVyZSBpcyB0aGUgcHJvcG9zZWQgY2hh cnRlciB0ZXh0DQo+PiBjaGFuZ2UgPw0KPj4gDQo+PiBDaGVlcnMNCj4+ICAgVG9lcmxlc3MNCj4+ IA0KPj4gUC5TLjogQWxzbywgaWYgaSBtYXkgdGhyb3cgaW4gc29tZSByYW5kb20gdGlkYml0IG9m IHRlY2hub2xvZ3kgdGhvdWdodHM6DQo+PiANCj4+IEkgbG92ZSBob21lIG5ldHdvcmtzIChhbmQg dGhlIFdHIGZvciBpdCksIGJlY2F1c2UgaXQgaXMgdGhlIGJlc3QgcGxhY2UNCj4+IGZvciBJUHY2 IHRvIGVsaW1pbmF0ZSBJUHY0IGFuZCBzdGFydCBjcmVhdGluZyBmcmVzaCwgYmV0dGVyIElQDQo+ PiBuZXR3b3JrLiBJIGhhdmUgYSBsb3Qgb2YgZG91YnQgdGhhdCB3ZSBhcmUgYW55d2hlcmUgY2xv c2UgdG8gZ29pbmcgdGhhdA0KPj4gcm91dGUgZXNwZWNpYWxseSBpbiBsYXJnZXIgZW50ZXJwcmlz ZXMsIHNvIHRoZSBhZGRyZXNzIG1hbmFnZW1lbnQgZm9yDQo+PiBJUHY0IGluIHRob3NlIG5ldHdv cmtzIGlzIGdvaW5nIHRvIGJlIGEgY3J1Y2lhbCByZXF1aXJlbWVudCB3aGVyZSBpIGRvbid0DQo+ PiB0aGluayBob21lbmV0IGNvdWxkIChvciBzaG91bGQpIGJlIGFueSBiaWcgaGVscC4gQW5kIGkg YW0gbm90IHN1cmUgaWYgaQ0KPj4gd291bGQNCj4+IHdhbnQgdG8gaG9sZCBteSBicmVhdGggZm9y IGEgbG90IG9mIElQdjQgYWRyZXNzIGNvbXBsZXhpdHkgcmVkdWN0aW9uIGluDQo+PiBJb1QgZWl0 aGVyLiBCdXQgY2VydGFpbmx5IGF1dG9ub21pYyBwcm9jZXNzZXMgY29sZCByYXRoZXIgaGVscCB0 aGFuIGh1cnQNCj4+IGluIHRoYXQgbWF0dGVyLg0KPj4gDQo+PiANCj4+IE9uIFRodSwgT2N0IDAy LCAyMDE0IGF0IDAxOjUwOjEzUE0gKzAwMDAsIExlZGR5LCBKb2huIHdyb3RlOg0KPj4+IE15IHdv cnJ5IG9uIHRoaXMgdG9waWMgaXMgdGhhdCB3ZSBhcmUgcmVmZXJyaW5nIHRvIKn4dGhlIEhvbWWp 9yBhbmQgqfh0aGUNCj4+PiBFbnRlcnByaXNlqfcuDQo+Pj4gSXQgaXNuqfZ0IHRoYXQgY2xlYXIg b2YgYSBkaXN0aW5jdGlvbi4gIFRoaXMgaXNuqfZ0IGp1c3QgYSBzaW1wbGUgTDIgZmxhdA0KPj4+ IGhvbWUgdnMuIGEgRm9ydHVuZSAxMDAwIGVudGVycHJpc2UuDQo+Pj4gDQo+Pj4gVGhlIGhvbWUg aXMgZ2V0dGluZyBtb3JlIGNvbXBsZXggYW5kIGluY2x1ZGVzIHdvcmsgZnJvbSBob21lOyBJT1Qs IGhvbWUNCj4+PiBzZWN1cml0eSwgaG90IHNwb3RzLCBjbG91ZCBzZXJ2aWNlcywgcG9saWNpZXMs IGRpc2NvdmVyeSBldGMuDQo+Pj4gTGFyZ2UgbnVtYmVycyBvZiBTTUKp9nMgbG9vayBsaWtlIG1v cmUgaGlnaCBlbmQgcmVzaWRlbnRpYWwgdGhhbiB0aGV5IGRvDQo+Pj4gbGFyZ2UgZW50ZXJwcmlz ZXMuDQo+Pj4gDQo+Pj4gSXQgd291bGQgYmUgaWRlYWwgdG8gaGF2ZSBhIHNvbHV0aW9uIHRoYXQg c3BhbnMgdGhlIHJhbmdlIG9mIHNpemUgYW5kDQo+Pj4gY29tcGxleGl0eSBmb3IgYm90aCByZXNp ZGVudGlhbCBhbmQgZW50ZXJwcmlzZS4NCj4+PiBQZXJoYXBzIGVuYWJsaW5nIGZlYXR1cmVzL2Nh cGFiaWxpdGllcyB3aGVyZSByZXF1aXJlZC4NCj4+PiANCj4+PiBBbHNvLCBhcyBmYXIgYXMgSVBW NiBjb25uZWN0aXZpdHkgcmVzaWRlbnRpYWwgaXMgcHJvYmFibHkgYWhlYWQgb2YNCj4+PiBlbnRl cnByaXNlcyBpbiBhZG9wdGluZyBWNiBjZW50cmljIGFyY2hpdGVjdHVyZXMgYW5kIHNlcnZpY2Vz Lg0KPj4+IFJlc2lkZW50aWFsIGRvZXNuqfZ0IGhhdmUgbXVjaCBvZiBhIGNob2ljZSwgaXQganVz dCBoYXBwZW5zLg0KPj4+IA0KPj4+IDJjZW50cywgSm9obg0KPj4+IA0KPj4+IE9uIDEwLzIvMTQs IDk6MTUgQU0sICJTdGVwaGVuIEZhcnJlbGwiIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPg0K Pj4+IHdyb3RlOg0KPj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IE9uIDAyLzEwLzE0IDEzOjQ5LCBN aWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpIHdyb3RlOg0KPj4+Pj4gTXkgcGVyc29uYWwgZ29h bCBpcyB0aGF0IHdoYXQgd2UgZG8gaW4gQU5JTUEgaXMgZnVsbHkgY29tcGF0aWJsZSB3aXRoDQo+ Pj4+PiBhbmQgaWRlYWxseSB1c2VkIGluIGhvbWVuZXQuIEl0IHdvdWxkIGZlZWwgd3JvbmcgdG8g bWUgdG8gaGF2ZSBhbg0KPj4+Pj4gaW5mcmFzdHJ1Y3R1cmUgdGhhdCBkb2Vzbid0IHdvcmsgaW4g YSBob21lbmV0Lg0KPj4+Pj4gDQo+Pj4+PiBUaGUgc2VjdXJpdHkgYm9vdHN0cmFwIGlzIGEgZ29v ZCBleGFtcGxlIG9mIHdoYXQgd2UgY2FuIGFjaGlldmUsIHdpdGgNCj4+Pj4+IHJlYXNvbmFibGUg ZWZmb3J0Lg0KPj4+PiANCj4+Pj4gRldJVywgaXQgaXMgbm90IGNsZWFyIHRvIG1lIHRoYXQgdGhl IHJlYXNvbmFibGUgcmVxdWlyZW1lbnRzDQo+Pj4+IGZvciBwcm92aXNpb25pbmcgZGV2aWNlIHNl Y3VyaXR5IGluZm9ybWF0aW9uIChvciBib290c3RyYXBwaW5nDQo+Pj4+IGlmIHdlIHdhbnRlZCB0 byBjYWxsIGl0IHRoYXQpIGFyZSB0aGUgc2FtZS4NCj4+Pj4gDQo+Pj4+IEluIGVudGVycHJpc2Ug ZW52aXJvbm1lbnRzIHdlIHNlZSBmZXdlciBsYXJnZXIgdmVuZG9ycyBvZiBkZXZpY2VzLg0KPj4+ PiBJbiB0aGUgaG9tZSB3aGVyZSB3ZSBhZGRpdGlvbmFsbHkgaGF2ZSBhIGxhcmdlIHJhbmdlIG9m IHZlbmRvcnMNCj4+Pj4gbWFueSBvZiB3aG9tIGFyZSB0aW55IGFuZCBsZXZlcmFnZSBhIGxvdCBv ZiBPU1MgYW5kIHdobyBjb3VsZA0KPj4+PiBwZXJoYXBzIG5vdCB0YWtlIHBhcnQgaW4gdGhlIGtp bmQgb2YgcHJvdmlzaW9uaW5nIGluZnJhc3RydWN0dXJlDQo+Pj4+IHRoYXQgaXMgcXVpdGUgcmVh c29uYWJsZSBmb3IgZW50ZXJwcmlzZXMgYW5kIHRoZWlyIHZlbmRvcnMuDQo+Pj4+IA0KPj4+PiBJ IGRvIHRoaW5rIGJvdGggd2FudCB0byBlbmQgdXAgaW4gdGhlIHNhbWUgc3RhdGUsIHdoZXJlIGRl dmljZXMNCj4+Pj4gYXJlIGF1dGhvcmlzZWQgZm9yIGNvbm5lY3Rpb24gdG8gdGhlIG5ldHdvcmsg YW5kIHdoZXJlIHRoZXJlIGlzDQo+Pj4+IHNvbWUga2V5aW5nIG1hdGVyaWFsIHVzYWJsZSBmb3Ig c2VjdXJpdHksIGJ1dCBJJ2QgYmUgc3VycHJpc2VkDQo+Pj4+IGlmIG9uZSBhcHByb2FjaCB0byBn ZXR0aW5nIHRoZXJlIHdvcmtlZCB0aGUgc2FtZSB3YXkgZm9yIGJvdGgNCj4+Pj4gaG9tZXMgYW5k IGVudGVycHJpc2VzLg0KPj4+PiANCj4+Pj4gUy4NCj4+Pj4gDQo+PiANCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBob21lbmV0IG1haWxpbmcg bGlzdA0KPj4gaG9tZW5ldEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ob21lbmV0DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gaG9tZW5ldCBtYWlsaW5nIGxpc3QNCj4+IGhvbWVuZXRAaWV0Zi5v cmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaG9tZW5ldA0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gaG9t ZW5ldCBtYWlsaW5nIGxpc3QNCj4gaG9tZW5ldEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2hvbWVuZXQNCg0K From nobody Sat Oct 4 13:24:29 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6941A0258; Sat, 4 Oct 2014 13:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bqwCXNYxHp3; Sat, 4 Oct 2014 13:24:18 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD2EF1A0242; Sat, 4 Oct 2014 13:24:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9414; q=dns/txt; s=iport; t=1412454259; x=1413663859; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=a263We9qzNm4lng1UG7lixkeOFgLotQwpeWPJnOLU4k=; b=Xv4q+jmJYQ+4rMNwgs9AfRc7E+8nq3++DvB2Nstr9X+d4met4b3VVFIP tXvI8zfUJU34rYwTwF+bUe34rumeIHZOEBQ61PBxKR2dQGuwu6Z0hAYi/ CKY8qIJfdlbwOmE/x43gXLmS+oc7UId/E+RVQeEURuuZrMcKuYFPqWUCf 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8FALpWMFStJV2a/2dsb2JhbABWCoMOU00LBIJ+yCIKhnlUAhltFgF7hAMBAQEEAQEBMToLEAIBCBEEAQEBBBQUAgIlCx0IAgQKBAUbiCMNjRycRAaVLwETBIEmiSOFICkYGwcYglmBWgWRdItKlgCCIIFDbIFIgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,654,1406592000"; d="scan'208";a="360769224" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 04 Oct 2014 20:24:18 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s94KOHOW014430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 4 Oct 2014 20:24:17 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Sat, 4 Oct 2014 15:24:17 -0500 From: "Acee Lindem (acee)" To: "Mark Baugher (mbaugher)" Thread-Topic: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) Thread-Index: AQHP3k73okqaa0NBjkebeYQrfyizUZwd6ywAgACHyICAAOlwgIABGhUA Date: Sat, 4 Oct 2014 20:24:16 +0000 Message-ID: References: <20141002144136.GA1847@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AF5E248@nkgeml512-mbx.china.huawei.com> <7A9C7BA6-E8DD-48F0-9B0E-CC2F36CBA05A@cisco.com> In-Reply-To: <7A9C7BA6-E8DD-48F0-9B0E-CC2F36CBA05A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Xxop49iE074fq5vUGkCmhuTAxIA Cc: "Toerless Eckert \(eckert\)" , Ted Lemon , "Leddy, John" , "Michael Behringer \(mbehring\)" , The IESG , "homenet@ietf.org" , Stephen Farrell , "anima@ietf.org" , Sheng Jiang Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 20:24:21 -0000 UmlnaHQgLSBidXQgd2Ugc3RpbGwgaGF2ZSB0byBhZ3JlZSBvbiB0aGUgYWRtaW4gb3IsIGFzIHlv dSBwdXQgaXQsDQpvd25lcnNoaXAgbW9kZWwuIEF0IGxlYXN0IG9uZSBvZiB0aGUgcHJvcG9zYWwg Zm9yIGF1dG9ub21pYyBuZXR3b3JraW5nIGlzDQphIGNlbnRyYWxpemVkIGFwcHJvYWNoIGFzIG9w cG9zZWQgdG8gY29uZmlndXJpbmcgYSBzaW5nbGUgYXV0aGVudGljYXRpb24NCnBhc3N3b3JkIG9u IGVhY2ggbmV3IGRldmljZSAoYXMgb25lIHdpdGggZG8gd2l0aCBhIFdpRmkgbmV0d29yaykuDQpB Y2VlIA0KDQpPbiAxMC8zLzE0LCA3OjM0IFBNLCAiTWFyayBCYXVnaGVyIChtYmF1Z2hlcikiIDxt YmF1Z2hlckBjaXNjby5jb20+IHdyb3RlOg0KDQo+SSB2b2ljZWQgdGhlIG9waW5pb24gdGhhdCBz b21lb25lIGhhcyB0byBvd24gdGhlIGhvbWVuZXQsIGFzIGRpc3RpbmN0DQo+ZnJvbSB3aG8gbWln aHQgb3duIHRoZSBDUEVzIGFuZCByb3V0ZXJzIG9uIHRoZSBob21lbmV0LiAgSW4gdGhlIHNhbWUN Cj53YXkgdGhhdCBzb21lIElTUCBDUEVzIGxldCB0aGUgdXNlciBzZXQgdGhlIFdpLUZpIHBhc3N3 b3JkLCB0aGUgdXNlciBvcg0KPmFuIGFnZW50IGZvciB0aGUgdXNlIG5lZWRzIHRvIHRha2UgaG9t ZW5ldCBvd25lcnNoaXAgKG9yIGluIHRoZSBjYXNlIG9mDQo+YXV0b25vbWljIGRldmljZXMsIHRy YW5zZmVyIG93bmVyc2hpcCkuICBUaGlzIGNhbm5vdCBiZSBkb25lIHBsdWcNCj5hbmQgcGxheSwg dGhlcmUgbmVlZHMgdG8gYmUgc29tZSBjZXJlbW9ueS4gIEl0J3MgZW5jb3VyYWdpbmcgdGhhdA0K PnRoZSB2YXN0IG1ham9yaXR5IG9mIHVzZXJzIGluIGhvbWVzLCBzbWFsbCBvZmZpY2VzIGFuZCBz bWFsbCBidXNpbmVzc2VzDQo+bWFuYWdlIHRvIGNvbmZpZ3VyZSB0aGVpciBXaS1GaSBQcm90ZWN0 ZWQgQWNjZXNzLiAgU29tZSBjZXJlbW9uaWVzDQo+d29yayB0byBpbXByb3ZlIHByaXZhY3kgYW5k IHNlY3VyaXR5Lg0KPg0KPlRoZSBob21lIG5ldHdvcmsgbmVlZHMgdG8gYmUgb3duZWQgYnkgdGhl IGhvbWUgdXNlcihzKSBvciBhZ2VudCAoY291bGQNCj5iZSB0aGUgSVNQIG9yIHNvbWUgb3Zlci10 aGUtdG9wIHJldGFpbCBzb2x1dGlvbiwgZXRjLikuDQo+DQo+TWFyaw0KPg0KPk9uIE9jdCAzLCAy MDE0LCBhdCA2OjM5IEFNLCBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lzY28uY29tPiB3cm90 ZToNCj4NCj4+IE9uZSB0aGluZyB3ZSBuZWVkIHRvIGRvIGluIGhvbWVuZXQgaXMgYWdyZWUgb24g dGhlIG5ldHdvcmsNCj4+YWRtaW5pc3RyYXRpb24NCj4+IG1vZGVsLiBJIGJlbGlldmUgbWFueSBv ZiB1cyBzdGFydGVkIHdpdGggdGhlIGFzc3VtcHRpb24gb2YgcGx1ZyBhbmQgcGxheQ0KPj4gYnV0 IGFyZSBub3cgYWNjZXB0aW5nIHRoZSBmYWN0IHRoYXQgbWluaW1hbCBjb25maWd1cmF0aW9uIHdp bGwgYmUNCj4+cmVxdWlyZWQNCj4+IHRvIHZldCBkZXZpY2VzIG9uIHRoZSBob21lbmV0LiBJZiB3 ZSBjYW4gYWdyZWUgb24gc2ltaWxhciBuZXR3b3JrIGFkbWluDQo+PiBtb2RlbHMgYW5kLCBhcyBU ZWQgcG9pbnRlZCBvdXQsIHJlcXVpcmVtZW50cyBvbiBjb25uZWN0aW5nIGRldmljZXMsIHRoZW4N Cj4+IHdlIGJlIG1heSBhYmxlIHRvIHVzZSBzaW1pbGFyIHNvbHV0aW9ucy4NCj4+IA0KPj4gQWNl ZSANCj4+IA0KPj4gT24gMTAvMi8xNCwgOTozMyBQTSwgIlNoZW5nIEppYW5nIiA8amlhbmdzaGVu Z0BodWF3ZWkuY29tPiB3cm90ZToNCj4+IA0KPj4+IEkgYWxzbyB0aGluayBJU1AgbmV0d29ya3Mg YW5kIGVudGVycHJpc2UgbmV0d29ya3MgYXJlIGRpZmZlcmVudCBmcm9tDQo+Pj5ob21lDQo+Pj4g bmV0d29ya3MuIEFsdGhvdWdoIG1hbnkgcmVxdWlyZW1lbnRzIG1heSBsb29rcyBzaW1pbGFyLCBw YXJ0aWN1bGFybHkNCj4+PiBjb25zaWRlcmluZyB0aGUgYXV0byBvcGVyYXRpb24gdGFyZ2V0LCB0 aGVyZSBhcmUgbWFueSBwcmVjb25kaXRpb25zIGFyZQ0KPj4+IGRpZmZlcmVudC4gSXQgY291bGQg cmVzdWx0IG9uIGRpZmZlcmVudCBzb2x1dGlvbiB0aG91Z2ggc29tZSBjb21wb25lbnRzDQo+Pj4g bWF5IGJlIHJldXNhYmxlIGFtb25nIHRoZXNlIG5ldHdvcmtzLg0KPj4+IA0KPj4+IEZvciBBTklN QSwgd2Ugc2hvdWxkIHN1cmVseSBzdHVkeSB3aGF0IGhvbWVuZXQgaXMgd29ya2luZyBvbiBhbmQN Cj4+PmlkZW50aWZ5DQo+Pj4gdGhlIGRpZmZlcmVudGlhLiBPbmx5IGFmdGVyIHRoZW4sIHdlIGNh biBwcm9kdWNlIG5lY2Vzc2FyeSBzb2x1dGlvbg0KPj4+d2l0aA0KPj4+IGNvbmZ1c2luZyB0aGUg d29ybGQuDQo+Pj4gDQo+Pj4gQmVzdCByZWdhcmRzLA0KPj4+IA0KPj4+IFNoZW5nDQo+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IEZyb206IGhvbWVuZXQg W2hvbWVuZXQtYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mIFRvZXJsZXNzIEVja2VydA0K Pj4+IFtlY2tlcnRAY2lzY28uY29tXQ0KPj4+IFNlbnQ6IDAyIE9jdG9iZXIgMjAxNCAyMjo0MQ0K Pj4+IFRvOiBMZWRkeSwgSm9obg0KPj4+IENjOiBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcp OyBUaGUgSUVTRzsgaG9tZW5ldEBpZXRmLm9yZzsgU3RlcGhlbg0KPj4+IEZhcnJlbGw7IGFuaW1h QGlldGYub3JnOyBUZWQgTGVtb24NCj4+PiBTdWJqZWN0OiBSZTogW2hvbWVuZXRdIFtBbmltYV0g VGVkIExlbW9uJ3MgQmxvY2sgb24NCj4+PiBjaGFydGVyLWlldGYtYW5pbWEtMDAtMDk6ICh3aXRo IEJMT0NLKQ0KPj4+IA0KPj4+IEZ1bGx5IGFncmVlZC4gQnV0IGRvZXMgdGhpcyBpbXBseSB0aGF0 IHdlIHdpbGwgbWFrZSBtb3N0IHByb2dyZXNzIGJ5DQo+Pj4gYmxvY2tpbmcgb3V0IGEgd29ya2lu ZyBncm91cCB0aGF0IGlzIGFjdGl2ZWx5IGNoYXJ0ZXJlZCB0byBsb29rIGF0DQo+Pj4gdGhlIHBy b2JsZW1zIGluIHRoZSBtYXJrZXQgc2VnbWVudHMgSG9tZW5ldCBpcyBub3QgYWRkcmVzc2luZyA/ DQo+Pj4gDQo+Pj4gSWYgdGhlIEJMT0NLIGlzIG1lYW50IHRvIHN1Z2dlc3QgYSBjaGFydGVyIGlt cHJvdmVtZW50cyBmb3IgYW5pbWEgdG8NCj4+PiBiZXR0ZXIgZGVmaW5lIG91ciBtdXR1YWwgZGVz aXJlIHRvIHNoYXJlIHdoYXRldmVyIGlzIGFwcGxpY2FibGUgYW5kDQo+Pj4gbm90IHJlaW52ZW50 IHVubmVjZXNzYXJpbHksIHRoZW4gd2hlcmUgaXMgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgdGV4dA0K Pj4+IGNoYW5nZSA/DQo+Pj4gDQo+Pj4gQ2hlZXJzDQo+Pj4gICBUb2VybGVzcw0KPj4+IA0KPj4+ IFAuUy46IEFsc28sIGlmIGkgbWF5IHRocm93IGluIHNvbWUgcmFuZG9tIHRpZGJpdCBvZiB0ZWNo bm9sb2d5DQo+Pj50aG91Z2h0czoNCj4+PiANCj4+PiBJIGxvdmUgaG9tZSBuZXR3b3JrcyAoYW5k IHRoZSBXRyBmb3IgaXQpLCBiZWNhdXNlIGl0IGlzIHRoZSBiZXN0IHBsYWNlDQo+Pj4gZm9yIElQ djYgdG8gZWxpbWluYXRlIElQdjQgYW5kIHN0YXJ0IGNyZWF0aW5nIGZyZXNoLCBiZXR0ZXIgSVAN Cj4+PiBuZXR3b3JrLiBJIGhhdmUgYSBsb3Qgb2YgZG91YnQgdGhhdCB3ZSBhcmUgYW55d2hlcmUg Y2xvc2UgdG8gZ29pbmcgdGhhdA0KPj4+IHJvdXRlIGVzcGVjaWFsbHkgaW4gbGFyZ2VyIGVudGVy cHJpc2VzLCBzbyB0aGUgYWRkcmVzcyBtYW5hZ2VtZW50IGZvcg0KPj4+IElQdjQgaW4gdGhvc2Ug bmV0d29ya3MgaXMgZ29pbmcgdG8gYmUgYSBjcnVjaWFsIHJlcXVpcmVtZW50IHdoZXJlIGkNCj4+ PmRvbid0DQo+Pj4gdGhpbmsgaG9tZW5ldCBjb3VsZCAob3Igc2hvdWxkKSBiZSBhbnkgYmlnIGhl bHAuIEFuZCBpIGFtIG5vdCBzdXJlIGlmIGkNCj4+PiB3b3VsZA0KPj4+IHdhbnQgdG8gaG9sZCBt eSBicmVhdGggZm9yIGEgbG90IG9mIElQdjQgYWRyZXNzIGNvbXBsZXhpdHkgcmVkdWN0aW9uIGlu DQo+Pj4gSW9UIGVpdGhlci4gQnV0IGNlcnRhaW5seSBhdXRvbm9taWMgcHJvY2Vzc2VzIGNvbGQg cmF0aGVyIGhlbHAgdGhhbg0KPj4+aHVydA0KPj4+IGluIHRoYXQgbWF0dGVyLg0KPj4+IA0KPj4+ IA0KPj4+IE9uIFRodSwgT2N0IDAyLCAyMDE0IGF0IDAxOjUwOjEzUE0gKzAwMDAsIExlZGR5LCBK b2huIHdyb3RlOg0KPj4+PiBNeSB3b3JyeSBvbiB0aGlzIHRvcGljIGlzIHRoYXQgd2UgYXJlIHJl ZmVycmluZyB0byCp+HRoZSBIb21lqfcgYW5kIKn4dGhlDQo+Pj4+IEVudGVycHJpc2Wp9y4NCj4+ Pj4gSXQgaXNuqfZ0IHRoYXQgY2xlYXIgb2YgYSBkaXN0aW5jdGlvbi4gIFRoaXMgaXNuqfZ0IGp1 c3QgYSBzaW1wbGUgTDINCj4+Pj5mbGF0DQo+Pj4+IGhvbWUgdnMuIGEgRm9ydHVuZSAxMDAwIGVu dGVycHJpc2UuDQo+Pj4+IA0KPj4+PiBUaGUgaG9tZSBpcyBnZXR0aW5nIG1vcmUgY29tcGxleCBh bmQgaW5jbHVkZXMgd29yayBmcm9tIGhvbWU7IElPVCwNCj4+Pj5ob21lDQo+Pj4+IHNlY3VyaXR5 LCBob3Qgc3BvdHMsIGNsb3VkIHNlcnZpY2VzLCBwb2xpY2llcywgZGlzY292ZXJ5IGV0Yy4NCj4+ Pj4gTGFyZ2UgbnVtYmVycyBvZiBTTUKp9nMgbG9vayBsaWtlIG1vcmUgaGlnaCBlbmQgcmVzaWRl bnRpYWwgdGhhbiB0aGV5DQo+Pj4+ZG8NCj4+Pj4gbGFyZ2UgZW50ZXJwcmlzZXMuDQo+Pj4+IA0K Pj4+PiBJdCB3b3VsZCBiZSBpZGVhbCB0byBoYXZlIGEgc29sdXRpb24gdGhhdCBzcGFucyB0aGUg cmFuZ2Ugb2Ygc2l6ZSBhbmQNCj4+Pj4gY29tcGxleGl0eSBmb3IgYm90aCByZXNpZGVudGlhbCBh bmQgZW50ZXJwcmlzZS4NCj4+Pj4gUGVyaGFwcyBlbmFibGluZyBmZWF0dXJlcy9jYXBhYmlsaXRp ZXMgd2hlcmUgcmVxdWlyZWQuDQo+Pj4+IA0KPj4+PiBBbHNvLCBhcyBmYXIgYXMgSVBWNiBjb25u ZWN0aXZpdHkgcmVzaWRlbnRpYWwgaXMgcHJvYmFibHkgYWhlYWQgb2YNCj4+Pj4gZW50ZXJwcmlz ZXMgaW4gYWRvcHRpbmcgVjYgY2VudHJpYyBhcmNoaXRlY3R1cmVzIGFuZCBzZXJ2aWNlcy4NCj4+ Pj4gUmVzaWRlbnRpYWwgZG9lc26p9nQgaGF2ZSBtdWNoIG9mIGEgY2hvaWNlLCBpdCBqdXN0IGhh cHBlbnMuDQo+Pj4+IA0KPj4+PiAyY2VudHMsIEpvaG4NCj4+Pj4gDQo+Pj4+IE9uIDEwLzIvMTQs IDk6MTUgQU0sICJTdGVwaGVuIEZhcnJlbGwiIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPg0K Pj4+PiB3cm90ZToNCj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gT24gMDIvMTAvMTQgMTM6 NDksIE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZykgd3JvdGU6DQo+Pj4+Pj4gTXkgcGVyc29u YWwgZ29hbCBpcyB0aGF0IHdoYXQgd2UgZG8gaW4gQU5JTUEgaXMgZnVsbHkgY29tcGF0aWJsZQ0K Pj4+Pj4+d2l0aA0KPj4+Pj4+IGFuZCBpZGVhbGx5IHVzZWQgaW4gaG9tZW5ldC4gSXQgd291bGQg ZmVlbCB3cm9uZyB0byBtZSB0byBoYXZlIGFuDQo+Pj4+Pj4gaW5mcmFzdHJ1Y3R1cmUgdGhhdCBk b2Vzbid0IHdvcmsgaW4gYSBob21lbmV0Lg0KPj4+Pj4+IA0KPj4+Pj4+IFRoZSBzZWN1cml0eSBi b290c3RyYXAgaXMgYSBnb29kIGV4YW1wbGUgb2Ygd2hhdCB3ZSBjYW4gYWNoaWV2ZSwNCj4+Pj4+ PndpdGgNCj4+Pj4+PiByZWFzb25hYmxlIGVmZm9ydC4NCj4+Pj4+IA0KPj4+Pj4gRldJVywgaXQg aXMgbm90IGNsZWFyIHRvIG1lIHRoYXQgdGhlIHJlYXNvbmFibGUgcmVxdWlyZW1lbnRzDQo+Pj4+ PiBmb3IgcHJvdmlzaW9uaW5nIGRldmljZSBzZWN1cml0eSBpbmZvcm1hdGlvbiAob3IgYm9vdHN0 cmFwcGluZw0KPj4+Pj4gaWYgd2Ugd2FudGVkIHRvIGNhbGwgaXQgdGhhdCkgYXJlIHRoZSBzYW1l Lg0KPj4+Pj4gDQo+Pj4+PiBJbiBlbnRlcnByaXNlIGVudmlyb25tZW50cyB3ZSBzZWUgZmV3ZXIg bGFyZ2VyIHZlbmRvcnMgb2YgZGV2aWNlcy4NCj4+Pj4+IEluIHRoZSBob21lIHdoZXJlIHdlIGFk ZGl0aW9uYWxseSBoYXZlIGEgbGFyZ2UgcmFuZ2Ugb2YgdmVuZG9ycw0KPj4+Pj4gbWFueSBvZiB3 aG9tIGFyZSB0aW55IGFuZCBsZXZlcmFnZSBhIGxvdCBvZiBPU1MgYW5kIHdobyBjb3VsZA0KPj4+ Pj4gcGVyaGFwcyBub3QgdGFrZSBwYXJ0IGluIHRoZSBraW5kIG9mIHByb3Zpc2lvbmluZyBpbmZy YXN0cnVjdHVyZQ0KPj4+Pj4gdGhhdCBpcyBxdWl0ZSByZWFzb25hYmxlIGZvciBlbnRlcnByaXNl cyBhbmQgdGhlaXIgdmVuZG9ycy4NCj4+Pj4+IA0KPj4+Pj4gSSBkbyB0aGluayBib3RoIHdhbnQg dG8gZW5kIHVwIGluIHRoZSBzYW1lIHN0YXRlLCB3aGVyZSBkZXZpY2VzDQo+Pj4+PiBhcmUgYXV0 aG9yaXNlZCBmb3IgY29ubmVjdGlvbiB0byB0aGUgbmV0d29yayBhbmQgd2hlcmUgdGhlcmUgaXMN Cj4+Pj4+IHNvbWUga2V5aW5nIG1hdGVyaWFsIHVzYWJsZSBmb3Igc2VjdXJpdHksIGJ1dCBJJ2Qg YmUgc3VycHJpc2VkDQo+Pj4+PiBpZiBvbmUgYXBwcm9hY2ggdG8gZ2V0dGluZyB0aGVyZSB3b3Jr ZWQgdGhlIHNhbWUgd2F5IGZvciBib3RoDQo+Pj4+PiBob21lcyBhbmQgZW50ZXJwcmlzZXMuDQo+ Pj4+PiANCj4+Pj4+IFMuDQo+Pj4+PiANCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IGhvbWVuZXQgbWFpbGluZyBsaXN0DQo+Pj4g aG9tZW5ldEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaG9tZW5ldA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4gaG9tZW5ldCBtYWlsaW5nIGxpc3QNCj4+PiBob21lbmV0QGlldGYub3JnDQo+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ob21lbmV0DQo+PiANCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBob21l bmV0IG1haWxpbmcgbGlzdA0KPj4gaG9tZW5ldEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ob21lbmV0DQo+DQoNCg== From nobody Sat Oct 4 19:16:32 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6E91A037C; Sat, 4 Oct 2014 19:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSQ71pra5cGp; Sat, 4 Oct 2014 19:16:28 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 777991A00EB; Sat, 4 Oct 2014 19:16:28 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id fb1so3455762pad.39 for ; Sat, 04 Oct 2014 19:16:28 -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=ilLY+A4iJ8Rn9PnsDEjX1z89rSByYLo75B8171B03YU=; b=NgnTlsddWrzkwGv+wkLaUVmrj5CyiVKzdU+GURnlHPe/8UgTAXbrtZviHZoiwi1RTb FkJ5x/NkBzysMgv4ObGNEZ/b9Gw9hEeYTzoecksLvvMkYyrEeFrjhigmGwrO8/6FmLqp /Eml8ASJa2JuPnWctmYvQ4RAQGFVMDPJMqdYype5BmCSAU92+7mUuKcXojv7DSOjqERV Q5OMGHavfbvs8wef0GV/UpWk/qWxN2oAbLKhyLwmm7/IZT3W8otUd+u4Mr1wnyeOWRbG lyr9n/UZf51THIgf0w1E4eLUXrklfRZYX6du3MuaO2hxoaIycIFahwtuupd13kbv1EJg LvMg== X-Received: by 10.68.111.99 with SMTP id ih3mr62978pbb.124.1412475387991; Sat, 04 Oct 2014 19:16:27 -0700 (PDT) Received: from [192.168.178.23] (243.194.69.111.dynamic.snap.net.nz. [111.69.194.243]) by mx.google.com with ESMTPSA id hs8sm9811767pbc.35.2014.10.04.19.16.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Oct 2014 19:16:26 -0700 (PDT) Message-ID: <5430A9F4.3000802@gmail.com> Date: Sun, 05 Oct 2014 15:16:20 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Acee Lindem (acee)" References: <20141002144136.GA1847@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AF5E248@nkgeml512-mbx.china.huawei.com> <7A9C7BA6-E8DD-48F0-9B0E-CC2F36CBA05A@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/LvTI7vgK3NY4fa3qeutkvCTGiFs Cc: "Toerless Eckert \(eckert\)" , Ted Lemon , "Leddy, John" , "Michael Behringer \(mbehring\)" , The IESG , Sheng Jiang , "homenet@ietf.org" , Stephen Farrell , "anima@ietf.org" , "Mark Baugher \(mbaugher\)" Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 02:16:30 -0000 On 05/10/2014 09:24, Acee Lindem (acee) wrote: > Right - but we still have to agree on the admin or, as you put it, > ownership model. At least one of the proposal for autonomic networking = is > a centralized approach as opposed to configuring a single authenticatio= n > password on each new device (as one with do with a WiFi network). Let me check that I understand. Are you saying that there are two basic models for enrollment? 1. "Hello, I am Brian. Please enrol me; the shared secret is *!&$=C2=A3@.= " 2. "Hello, I am Brian. My public key is 12345, and should already be in your list. [Signed with my private key.]" Brian From nobody Sun Oct 5 10:13:06 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9D81A00E4; Sun, 5 Oct 2014 10:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql6zAN0pKdjr; Sun, 5 Oct 2014 10:12:56 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808EF1A00CD; Sun, 5 Oct 2014 10:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10116; q=dns/txt; s=iport; t=1412529177; x=1413738777; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Bikc/69KxV0e86eBA44YirGasxopt975moUyNqOTHd4=; b=VAYVqgwzsCQN+wr3geKGwWkt/d33TNH+nmp1FpAsZNX9q2pu2hWpncqd HoVBviqBuNDhOiVYBIOTF9l0E3TbX+UYcXTaph3tlyFQHV7UKJ99M2m6k gi/4v/rBFTn2IfxmpcHxeuoXM2qlRSjuc8Kj777B/iziisne/hH3obeV1 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkFAHJ7MVStJA2K/2dsb2JhbABUCoMOU00LBIJ+yQIKhnlUAhlmFgF7hAMBAQEDAQEBATE6CwULAgEIEQQBAQEEFBQCAiULHQgCBAoEBRuIGwgNjW6cRAaUVAETBIEmiSOFICkYGwcYglk8gR4FkXSLSpYAgiCBQ2yBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,660,1406592000"; d="scan'208";a="357701604" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP; 05 Oct 2014 17:12:56 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s95HCtAD027311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 5 Oct 2014 17:12:55 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.49]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Sun, 5 Oct 2014 12:12:54 -0500 From: "Mark Baugher (mbaugher)" To: "Acee Lindem (acee)" Thread-Topic: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) Thread-Index: AQHP3k73okqaa0NBjkebeYQrfyizUZwd6ywAgACHyICAAOlwgIABGhUAgAGf7YA= Date: Sun, 5 Oct 2014 17:12:53 +0000 Message-ID: <8E20D217-972F-42AF-AB0E-9DDD77EFCA84@cisco.com> References: <20141002144136.GA1847@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AF5E248@nkgeml512-mbx.china.huawei.com> <7A9C7BA6-E8DD-48F0-9B0E-CC2F36CBA05A@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.21.71.20] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/S5g0_WrmLguOH90qMVGbtcD0NCU Cc: "Toerless Eckert \(eckert\)" , Ted Lemon , "Leddy, John" , "Michael Behringer \(mbehring\)" , The IESG , "homenet@ietf.org" , Stephen Farrell , "anima@ietf.org" , Sheng Jiang Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 17:12:59 -0000 DQpPbiBPY3QgNCwgMjAxNCwgYXQgMToyNCBQTSwgQWNlZSBMaW5kZW0gKGFjZWUpIDxhY2VlQGNp c2NvLmNvbT4gd3JvdGU6DQoNCj4gUmlnaHQgLSBidXQgd2Ugc3RpbGwgaGF2ZSB0byBhZ3JlZSBv biB0aGUgYWRtaW4gb3IsIGFzIHlvdSBwdXQgaXQsDQo+IG93bmVyc2hpcCBtb2RlbC4gQXQgbGVh c3Qgb25lIG9mIHRoZSBwcm9wb3NhbCBmb3IgYXV0b25vbWljIG5ldHdvcmtpbmcgaXMNCj4gYSBj ZW50cmFsaXplZCBhcHByb2FjaCBhcyBvcHBvc2VkIHRvIGNvbmZpZ3VyaW5nIGEgc2luZ2xlIGF1 dGhlbnRpY2F0aW9uDQo+IHBhc3N3b3JkIG9uIGVhY2ggbmV3IGRldmljZSAoYXMgb25lIHdpdGgg ZG8gd2l0aCBhIFdpRmkgbmV0d29yaykuDQoNCkRvZXNuJ3QgdGhhdCBhc3N1bWUgdGhhdCBhbGwg bmV0d29yayBkZXZpY2VzLCBJU1AgQ1BFcyBhbmQgcmV0YWlsIGdhdGV3YXlzLA0KdXNlIHRoZSBj ZW50cmFsaXplZCBhcHByb2FjaD8gIEhhcyB0aGUgbXVsdGktYXV0aG9yaXR5IGlzc3VlIGJlZW4g c29sdmVkDQp5ZXQgZm9yIGF1dG9ub21pYyBzeXN0ZW1zPyAgSGFzIGl0IGJlZW4gYWRkcmVzc2Vk PyAgSSBkb24ndCBrbm93Lg0KDQpNYXJrDQoNCj4gQWNlZSANCj4gDQo+IE9uIDEwLzMvMTQsIDc6 MzQgUE0sICJNYXJrIEJhdWdoZXIgKG1iYXVnaGVyKSIgPG1iYXVnaGVyQGNpc2NvLmNvbT4gd3Jv dGU6DQo+IA0KPj4gSSB2b2ljZWQgdGhlIG9waW5pb24gdGhhdCBzb21lb25lIGhhcyB0byBvd24g dGhlIGhvbWVuZXQsIGFzIGRpc3RpbmN0DQo+PiBmcm9tIHdobyBtaWdodCBvd24gdGhlIENQRXMg YW5kIHJvdXRlcnMgb24gdGhlIGhvbWVuZXQuICBJbiB0aGUgc2FtZQ0KPj4gd2F5IHRoYXQgc29t ZSBJU1AgQ1BFcyBsZXQgdGhlIHVzZXIgc2V0IHRoZSBXaS1GaSBwYXNzd29yZCwgdGhlIHVzZXIg b3INCj4+IGFuIGFnZW50IGZvciB0aGUgdXNlIG5lZWRzIHRvIHRha2UgaG9tZW5ldCBvd25lcnNo aXAgKG9yIGluIHRoZSBjYXNlIG9mDQo+PiBhdXRvbm9taWMgZGV2aWNlcywgdHJhbnNmZXIgb3du ZXJzaGlwKS4gIFRoaXMgY2Fubm90IGJlIGRvbmUgcGx1Zw0KPj4gYW5kIHBsYXksIHRoZXJlIG5l ZWRzIHRvIGJlIHNvbWUgY2VyZW1vbnkuICBJdCdzIGVuY291cmFnaW5nIHRoYXQNCj4+IHRoZSB2 YXN0IG1ham9yaXR5IG9mIHVzZXJzIGluIGhvbWVzLCBzbWFsbCBvZmZpY2VzIGFuZCBzbWFsbCBi dXNpbmVzc2VzDQo+PiBtYW5hZ2UgdG8gY29uZmlndXJlIHRoZWlyIFdpLUZpIFByb3RlY3RlZCBB Y2Nlc3MuICBTb21lIGNlcmVtb25pZXMNCj4+IHdvcmsgdG8gaW1wcm92ZSBwcml2YWN5IGFuZCBz ZWN1cml0eS4NCj4+IA0KPj4gVGhlIGhvbWUgbmV0d29yayBuZWVkcyB0byBiZSBvd25lZCBieSB0 aGUgaG9tZSB1c2VyKHMpIG9yIGFnZW50IChjb3VsZA0KPj4gYmUgdGhlIElTUCBvciBzb21lIG92 ZXItdGhlLXRvcCByZXRhaWwgc29sdXRpb24sIGV0Yy4pLg0KPj4gDQo+PiBNYXJrDQo+PiANCj4+ IE9uIE9jdCAzLCAyMDE0LCBhdCA2OjM5IEFNLCBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lz Y28uY29tPiB3cm90ZToNCj4+IA0KPj4+IE9uZSB0aGluZyB3ZSBuZWVkIHRvIGRvIGluIGhvbWVu ZXQgaXMgYWdyZWUgb24gdGhlIG5ldHdvcmsNCj4+PiBhZG1pbmlzdHJhdGlvbg0KPj4+IG1vZGVs LiBJIGJlbGlldmUgbWFueSBvZiB1cyBzdGFydGVkIHdpdGggdGhlIGFzc3VtcHRpb24gb2YgcGx1 ZyBhbmQgcGxheQ0KPj4+IGJ1dCBhcmUgbm93IGFjY2VwdGluZyB0aGUgZmFjdCB0aGF0IG1pbmlt YWwgY29uZmlndXJhdGlvbiB3aWxsIGJlDQo+Pj4gcmVxdWlyZWQNCj4+PiB0byB2ZXQgZGV2aWNl cyBvbiB0aGUgaG9tZW5ldC4gSWYgd2UgY2FuIGFncmVlIG9uIHNpbWlsYXIgbmV0d29yayBhZG1p bg0KPj4+IG1vZGVscyBhbmQsIGFzIFRlZCBwb2ludGVkIG91dCwgcmVxdWlyZW1lbnRzIG9uIGNv bm5lY3RpbmcgZGV2aWNlcywgdGhlbg0KPj4+IHdlIGJlIG1heSBhYmxlIHRvIHVzZSBzaW1pbGFy IHNvbHV0aW9ucy4NCj4+PiANCj4+PiBBY2VlIA0KPj4+IA0KPj4+IE9uIDEwLzIvMTQsIDk6MzMg UE0sICJTaGVuZyBKaWFuZyIgPGppYW5nc2hlbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQo+Pj4gDQo+ Pj4+IEkgYWxzbyB0aGluayBJU1AgbmV0d29ya3MgYW5kIGVudGVycHJpc2UgbmV0d29ya3MgYXJl IGRpZmZlcmVudCBmcm9tDQo+Pj4+IGhvbWUNCj4+Pj4gbmV0d29ya3MuIEFsdGhvdWdoIG1hbnkg cmVxdWlyZW1lbnRzIG1heSBsb29rcyBzaW1pbGFyLCBwYXJ0aWN1bGFybHkNCj4+Pj4gY29uc2lk ZXJpbmcgdGhlIGF1dG8gb3BlcmF0aW9uIHRhcmdldCwgdGhlcmUgYXJlIG1hbnkgcHJlY29uZGl0 aW9ucyBhcmUNCj4+Pj4gZGlmZmVyZW50LiBJdCBjb3VsZCByZXN1bHQgb24gZGlmZmVyZW50IHNv bHV0aW9uIHRob3VnaCBzb21lIGNvbXBvbmVudHMNCj4+Pj4gbWF5IGJlIHJldXNhYmxlIGFtb25n IHRoZXNlIG5ldHdvcmtzLg0KPj4+PiANCj4+Pj4gRm9yIEFOSU1BLCB3ZSBzaG91bGQgc3VyZWx5 IHN0dWR5IHdoYXQgaG9tZW5ldCBpcyB3b3JraW5nIG9uIGFuZA0KPj4+PiBpZGVudGlmeQ0KPj4+ PiB0aGUgZGlmZmVyZW50aWEuIE9ubHkgYWZ0ZXIgdGhlbiwgd2UgY2FuIHByb2R1Y2UgbmVjZXNz YXJ5IHNvbHV0aW9uDQo+Pj4+IHdpdGgNCj4+Pj4gY29uZnVzaW5nIHRoZSB3b3JsZC4NCj4+Pj4g DQo+Pj4+IEJlc3QgcmVnYXJkcywNCj4+Pj4gDQo+Pj4+IFNoZW5nDQo+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gRnJvbTogaG9tZW5ldCBbaG9tZW5l dC1ib3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgVG9lcmxlc3MgRWNrZXJ0DQo+Pj4+IFtl Y2tlcnRAY2lzY28uY29tXQ0KPj4+PiBTZW50OiAwMiBPY3RvYmVyIDIwMTQgMjI6NDENCj4+Pj4g VG86IExlZGR5LCBKb2huDQo+Pj4+IENjOiBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpOyBU aGUgSUVTRzsgaG9tZW5ldEBpZXRmLm9yZzsgU3RlcGhlbg0KPj4+PiBGYXJyZWxsOyBhbmltYUBp ZXRmLm9yZzsgVGVkIExlbW9uDQo+Pj4+IFN1YmplY3Q6IFJlOiBbaG9tZW5ldF0gW0FuaW1hXSBU ZWQgTGVtb24ncyBCbG9jayBvbg0KPj4+PiBjaGFydGVyLWlldGYtYW5pbWEtMDAtMDk6ICh3aXRo IEJMT0NLKQ0KPj4+PiANCj4+Pj4gRnVsbHkgYWdyZWVkLiBCdXQgZG9lcyB0aGlzIGltcGx5IHRo YXQgd2Ugd2lsbCBtYWtlIG1vc3QgcHJvZ3Jlc3MgYnkNCj4+Pj4gYmxvY2tpbmcgb3V0IGEgd29y a2luZyBncm91cCB0aGF0IGlzIGFjdGl2ZWx5IGNoYXJ0ZXJlZCB0byBsb29rIGF0DQo+Pj4+IHRo ZSBwcm9ibGVtcyBpbiB0aGUgbWFya2V0IHNlZ21lbnRzIEhvbWVuZXQgaXMgbm90IGFkZHJlc3Np bmcgPw0KPj4+PiANCj4+Pj4gSWYgdGhlIEJMT0NLIGlzIG1lYW50IHRvIHN1Z2dlc3QgYSBjaGFy dGVyIGltcHJvdmVtZW50cyBmb3IgYW5pbWEgdG8NCj4+Pj4gYmV0dGVyIGRlZmluZSBvdXIgbXV0 dWFsIGRlc2lyZSB0byBzaGFyZSB3aGF0ZXZlciBpcyBhcHBsaWNhYmxlIGFuZA0KPj4+PiBub3Qg cmVpbnZlbnQgdW5uZWNlc3NhcmlseSwgdGhlbiB3aGVyZSBpcyB0aGUgcHJvcG9zZWQgY2hhcnRl ciB0ZXh0DQo+Pj4+IGNoYW5nZSA/DQo+Pj4+IA0KPj4+PiBDaGVlcnMNCj4+Pj4gIFRvZXJsZXNz DQo+Pj4+IA0KPj4+PiBQLlMuOiBBbHNvLCBpZiBpIG1heSB0aHJvdyBpbiBzb21lIHJhbmRvbSB0 aWRiaXQgb2YgdGVjaG5vbG9neQ0KPj4+PiB0aG91Z2h0czoNCj4+Pj4gDQo+Pj4+IEkgbG92ZSBo b21lIG5ldHdvcmtzIChhbmQgdGhlIFdHIGZvciBpdCksIGJlY2F1c2UgaXQgaXMgdGhlIGJlc3Qg cGxhY2UNCj4+Pj4gZm9yIElQdjYgdG8gZWxpbWluYXRlIElQdjQgYW5kIHN0YXJ0IGNyZWF0aW5n IGZyZXNoLCBiZXR0ZXIgSVANCj4+Pj4gbmV0d29yay4gSSBoYXZlIGEgbG90IG9mIGRvdWJ0IHRo YXQgd2UgYXJlIGFueXdoZXJlIGNsb3NlIHRvIGdvaW5nIHRoYXQNCj4+Pj4gcm91dGUgZXNwZWNp YWxseSBpbiBsYXJnZXIgZW50ZXJwcmlzZXMsIHNvIHRoZSBhZGRyZXNzIG1hbmFnZW1lbnQgZm9y DQo+Pj4+IElQdjQgaW4gdGhvc2UgbmV0d29ya3MgaXMgZ29pbmcgdG8gYmUgYSBjcnVjaWFsIHJl cXVpcmVtZW50IHdoZXJlIGkNCj4+Pj4gZG9uJ3QNCj4+Pj4gdGhpbmsgaG9tZW5ldCBjb3VsZCAo b3Igc2hvdWxkKSBiZSBhbnkgYmlnIGhlbHAuIEFuZCBpIGFtIG5vdCBzdXJlIGlmIGkNCj4+Pj4g d291bGQNCj4+Pj4gd2FudCB0byBob2xkIG15IGJyZWF0aCBmb3IgYSBsb3Qgb2YgSVB2NCBhZHJl c3MgY29tcGxleGl0eSByZWR1Y3Rpb24gaW4NCj4+Pj4gSW9UIGVpdGhlci4gQnV0IGNlcnRhaW5s eSBhdXRvbm9taWMgcHJvY2Vzc2VzIGNvbGQgcmF0aGVyIGhlbHAgdGhhbg0KPj4+PiBodXJ0DQo+ Pj4+IGluIHRoYXQgbWF0dGVyLg0KPj4+PiANCj4+Pj4gDQo+Pj4+IE9uIFRodSwgT2N0IDAyLCAy MDE0IGF0IDAxOjUwOjEzUE0gKzAwMDAsIExlZGR5LCBKb2huIHdyb3RlOg0KPj4+Pj4gTXkgd29y cnkgb24gdGhpcyB0b3BpYyBpcyB0aGF0IHdlIGFyZSByZWZlcnJpbmcgdG8gqfh0aGUgSG9tZan3 IGFuZCCp+HRoZQ0KPj4+Pj4gRW50ZXJwcmlzZan3Lg0KPj4+Pj4gSXQgaXNuqfZ0IHRoYXQgY2xl YXIgb2YgYSBkaXN0aW5jdGlvbi4gIFRoaXMgaXNuqfZ0IGp1c3QgYSBzaW1wbGUgTDINCj4+Pj4+ IGZsYXQNCj4+Pj4+IGhvbWUgdnMuIGEgRm9ydHVuZSAxMDAwIGVudGVycHJpc2UuDQo+Pj4+PiAN Cj4+Pj4+IFRoZSBob21lIGlzIGdldHRpbmcgbW9yZSBjb21wbGV4IGFuZCBpbmNsdWRlcyB3b3Jr IGZyb20gaG9tZTsgSU9ULA0KPj4+Pj4gaG9tZQ0KPj4+Pj4gc2VjdXJpdHksIGhvdCBzcG90cywg Y2xvdWQgc2VydmljZXMsIHBvbGljaWVzLCBkaXNjb3ZlcnkgZXRjLg0KPj4+Pj4gTGFyZ2UgbnVt YmVycyBvZiBTTUKp9nMgbG9vayBsaWtlIG1vcmUgaGlnaCBlbmQgcmVzaWRlbnRpYWwgdGhhbiB0 aGV5DQo+Pj4+PiBkbw0KPj4+Pj4gbGFyZ2UgZW50ZXJwcmlzZXMuDQo+Pj4+PiANCj4+Pj4+IEl0 IHdvdWxkIGJlIGlkZWFsIHRvIGhhdmUgYSBzb2x1dGlvbiB0aGF0IHNwYW5zIHRoZSByYW5nZSBv ZiBzaXplIGFuZA0KPj4+Pj4gY29tcGxleGl0eSBmb3IgYm90aCByZXNpZGVudGlhbCBhbmQgZW50 ZXJwcmlzZS4NCj4+Pj4+IFBlcmhhcHMgZW5hYmxpbmcgZmVhdHVyZXMvY2FwYWJpbGl0aWVzIHdo ZXJlIHJlcXVpcmVkLg0KPj4+Pj4gDQo+Pj4+PiBBbHNvLCBhcyBmYXIgYXMgSVBWNiBjb25uZWN0 aXZpdHkgcmVzaWRlbnRpYWwgaXMgcHJvYmFibHkgYWhlYWQgb2YNCj4+Pj4+IGVudGVycHJpc2Vz IGluIGFkb3B0aW5nIFY2IGNlbnRyaWMgYXJjaGl0ZWN0dXJlcyBhbmQgc2VydmljZXMuDQo+Pj4+ PiBSZXNpZGVudGlhbCBkb2Vzbqn2dCBoYXZlIG11Y2ggb2YgYSBjaG9pY2UsIGl0IGp1c3QgaGFw cGVucy4NCj4+Pj4+IA0KPj4+Pj4gMmNlbnRzLCBKb2huDQo+Pj4+PiANCj4+Pj4+IE9uIDEwLzIv MTQsIDk6MTUgQU0sICJTdGVwaGVuIEZhcnJlbGwiIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmll Pg0KPj4+Pj4gd3JvdGU6DQo+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBPbiAwMi8x MC8xNCAxMzo0OSwgTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKSB3cm90ZToNCj4+Pj4+Pj4g TXkgcGVyc29uYWwgZ29hbCBpcyB0aGF0IHdoYXQgd2UgZG8gaW4gQU5JTUEgaXMgZnVsbHkgY29t cGF0aWJsZQ0KPj4+Pj4+PiB3aXRoDQo+Pj4+Pj4+IGFuZCBpZGVhbGx5IHVzZWQgaW4gaG9tZW5l dC4gSXQgd291bGQgZmVlbCB3cm9uZyB0byBtZSB0byBoYXZlIGFuDQo+Pj4+Pj4+IGluZnJhc3Ry dWN0dXJlIHRoYXQgZG9lc24ndCB3b3JrIGluIGEgaG9tZW5ldC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+ IFRoZSBzZWN1cml0eSBib290c3RyYXAgaXMgYSBnb29kIGV4YW1wbGUgb2Ygd2hhdCB3ZSBjYW4g YWNoaWV2ZSwNCj4+Pj4+Pj4gd2l0aA0KPj4+Pj4+PiByZWFzb25hYmxlIGVmZm9ydC4NCj4+Pj4+ PiANCj4+Pj4+PiBGV0lXLCBpdCBpcyBub3QgY2xlYXIgdG8gbWUgdGhhdCB0aGUgcmVhc29uYWJs ZSByZXF1aXJlbWVudHMNCj4+Pj4+PiBmb3IgcHJvdmlzaW9uaW5nIGRldmljZSBzZWN1cml0eSBp bmZvcm1hdGlvbiAob3IgYm9vdHN0cmFwcGluZw0KPj4+Pj4+IGlmIHdlIHdhbnRlZCB0byBjYWxs IGl0IHRoYXQpIGFyZSB0aGUgc2FtZS4NCj4+Pj4+PiANCj4+Pj4+PiBJbiBlbnRlcnByaXNlIGVu dmlyb25tZW50cyB3ZSBzZWUgZmV3ZXIgbGFyZ2VyIHZlbmRvcnMgb2YgZGV2aWNlcy4NCj4+Pj4+ PiBJbiB0aGUgaG9tZSB3aGVyZSB3ZSBhZGRpdGlvbmFsbHkgaGF2ZSBhIGxhcmdlIHJhbmdlIG9m IHZlbmRvcnMNCj4+Pj4+PiBtYW55IG9mIHdob20gYXJlIHRpbnkgYW5kIGxldmVyYWdlIGEgbG90 IG9mIE9TUyBhbmQgd2hvIGNvdWxkDQo+Pj4+Pj4gcGVyaGFwcyBub3QgdGFrZSBwYXJ0IGluIHRo ZSBraW5kIG9mIHByb3Zpc2lvbmluZyBpbmZyYXN0cnVjdHVyZQ0KPj4+Pj4+IHRoYXQgaXMgcXVp dGUgcmVhc29uYWJsZSBmb3IgZW50ZXJwcmlzZXMgYW5kIHRoZWlyIHZlbmRvcnMuDQo+Pj4+Pj4g DQo+Pj4+Pj4gSSBkbyB0aGluayBib3RoIHdhbnQgdG8gZW5kIHVwIGluIHRoZSBzYW1lIHN0YXRl LCB3aGVyZSBkZXZpY2VzDQo+Pj4+Pj4gYXJlIGF1dGhvcmlzZWQgZm9yIGNvbm5lY3Rpb24gdG8g dGhlIG5ldHdvcmsgYW5kIHdoZXJlIHRoZXJlIGlzDQo+Pj4+Pj4gc29tZSBrZXlpbmcgbWF0ZXJp YWwgdXNhYmxlIGZvciBzZWN1cml0eSwgYnV0IEknZCBiZSBzdXJwcmlzZWQNCj4+Pj4+PiBpZiBv bmUgYXBwcm9hY2ggdG8gZ2V0dGluZyB0aGVyZSB3b3JrZWQgdGhlIHNhbWUgd2F5IGZvciBib3Ro DQo+Pj4+Pj4gaG9tZXMgYW5kIGVudGVycHJpc2VzLg0KPj4+Pj4+IA0KPj4+Pj4+IFMuDQo+Pj4+ Pj4gDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+PiBob21lbmV0IG1haWxpbmcgbGlzdA0KPj4+PiBob21lbmV0QGlldGYub3Jn DQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaG9tZW5ldA0KPj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBo b21lbmV0IG1haWxpbmcgbGlzdA0KPj4+PiBob21lbmV0QGlldGYub3JnDQo+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaG9tZW5ldA0KPj4+IA0KPj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gaG9tZW5ldCBtYWls aW5nIGxpc3QNCj4+PiBob21lbmV0QGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ob21lbmV0DQo+PiANCj4gDQoNCg== From nobody Sun Oct 5 12:51:29 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B00E1A1AF6; Sun, 5 Oct 2014 12:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkfmpD1pBA8w; Sun, 5 Oct 2014 12:51:19 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C531A1AF5; Sun, 5 Oct 2014 12:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1090; q=dns/txt; s=iport; t=1412538679; x=1413748279; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8MWjYrvrbBexEpNvk3nB+kAK0OMS1umU4kL3jb17lxA=; b=Nh8OGaNo9vRdwe1vvRi24dtGsefY0QEvd1OyFnUmuTN7LTI+zvbBGgGt 1o0j2JnN2IV6vNdhoG83JvUEopGcM9LR8srLZdZL5Lb9N9m8YWDnsJ47S OwJ1VlqqfQNix1zsUYbnAffmQ5bBptUxYMDo74aK2jfA1/4CzpYOunCSV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFALegMVStJA2B/2dsb2JhbABegw5TWATMDIdLAn8WAXuEAwEBAQMBeRACAQgYGBYhESUCBA4FCYghAwkIDbdpDYcYAReOFIIxBxiEMwWLHYZXiTmCEYEtg0KKQIJSg3+CIIFDbAGBR4ECAQEB X-IronPort-AV: E=Sophos;i="5.04,660,1406592000"; d="scan'208";a="360892003" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP; 05 Oct 2014 19:51:19 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s95JpIjO030915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 5 Oct 2014 19:51:18 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Sun, 5 Oct 2014 14:51:18 -0500 From: "Acee Lindem (acee)" To: Brian E Carpenter Thread-Topic: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) Thread-Index: AQHP3k73okqaa0NBjkebeYQrfyizUZwd6ywAgACHyICAAOlwgIABGhUAgAClbgCAAOOxAA== Date: Sun, 5 Oct 2014 19:51:17 +0000 Message-ID: References: <20141002144136.GA1847@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AF5E248@nkgeml512-mbx.china.huawei.com> <7A9C7BA6-E8DD-48F0-9B0E-CC2F36CBA05A@cisco.com> <5430A9F4.3000802@gmail.com> In-Reply-To: <5430A9F4.3000802@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4B3EAB3ECCCDD1468924767FA52A2D2C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/w8aN60V1Mrn5XQJvswUpGNUIdDs Cc: "Toerless Eckert \(eckert\)" , Ted Lemon , "Leddy, John" , "Michael Behringer \(mbehring\)" , The IESG , Sheng Jiang , "homenet@ietf.org" , Stephen Farrell , "anima@ietf.org" , "Mark Baugher \(mbaugher\)" Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 19:51:21 -0000 On 10/4/14, 10:16 PM, "Brian E Carpenter" wrote: >On 05/10/2014 09:24, Acee Lindem (acee) wrote: >> Right - but we still have to agree on the admin or, as you put it, >> ownership model. At least one of the proposal for autonomic networking >>is >> a centralized approach as opposed to configuring a single authentication >> password on each new device (as one with do with a WiFi network). > >Let me check that I understand. Are you saying that there are two basic >models for enrollment? > >1. "Hello, I am Brian. Please enrol me; the shared secret is *!&$=A3@." > >2. "Hello, I am Brian. My public key is 12345, and should already >be in your list. [Signed with my private key.]" That=B9s basically the trade-off although there are many variations of #2. Here is one example: http://www.ietf.org/id/draft-pritikin-bootstrapping-keyinfrastructures-01.t xt The question is what are we willing to accept in the homenet in terms of both device configuration and device requirements. Thanks, Acee=20 > > Brian > From nobody Sun Oct 5 14:55:22 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C861A0070; Sun, 5 Oct 2014 14:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtJ8p7iHPDRe; Sun, 5 Oct 2014 14:55:17 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201E11A006F; Sun, 5 Oct 2014 14:55:17 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y13so2266569pdi.19 for ; Sun, 05 Oct 2014 14:55:16 -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=WuqztmBnhucFyqX51iGDOYMBUbfbhp8M+wARmQh25c4=; b=WzWmOlhVFR/2tQpNx7hFX32V55HKMvOppjHjkTYx/K7WKvuuQ/E9geA8tSGB8h34Mq SHppDPWC7zjXkRZwpEB/GTK5R/6Yf6Trg5/6beCzVylEcYsE3ncL+x0MikAuRcjbkwUH kyEMkQuKnzn/CS0OUKNCmmRVTgtsVHrD4x9j5Zm19puyRXSfJ2qonoAt+ZPqPqC4XDZf 6qbhoaOl780kaGKQE4x9thu0oJqby3ZnyqWmgaw1Sx70xEGMwUzeeudVaaZiKD7FKoZ7 gSAOW4atNKMJlpnWInrMQkDnjHV4odNAUAcV8EJ8sVumzeiHYhUGfjDfvQXLW1oRstN0 cX0g== X-Received: by 10.70.8.195 with SMTP id t3mr14657195pda.62.1412546116815; Sun, 05 Oct 2014 14:55:16 -0700 (PDT) Received: from [192.168.178.23] (154.197.69.111.dynamic.snap.net.nz. [111.69.197.154]) by mx.google.com with ESMTPSA id ki1sm9351559pdb.59.2014.10.05.14.55.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 Oct 2014 14:55:15 -0700 (PDT) Message-ID: <5431BE3E.4@gmail.com> Date: Mon, 06 Oct 2014 10:55:10 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Acee Lindem (acee)" References: <20141002144136.GA1847@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AF5E248@nkgeml512-mbx.china.huawei.com> <7A9C7BA6-E8DD-48F0-9B0E-CC2F36CBA05A@cisco.com> <5430A9F4.3000802@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/FG4ojLLHCfHBKRYijVJusfEGA0k Cc: "Toerless Eckert \(eckert\)" , "Leddy, John" , "Michael Behringer \(mbehring\)" , "Mark Baugher \(mbaugher\)" , Sheng Jiang , "homenet@ietf.org" , Stephen Farrell , "anima@ietf.org" , Ted Lemon Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 21:55:18 -0000 (cc's trimmed. I'm not sure the whole IESG wants this in their inboxen.) On 06/10/2014 08:51, Acee Lindem (acee) wrote: >=20 > On 10/4/14, 10:16 PM, "Brian E Carpenter" = > wrote: >=20 >> On 05/10/2014 09:24, Acee Lindem (acee) wrote: >>> Right - but we still have to agree on the admin or, as you put it, >>> ownership model. At least one of the proposal for autonomic networkin= g >>> is >>> a centralized approach as opposed to configuring a single authenticat= ion >>> password on each new device (as one with do with a WiFi network). >> Let me check that I understand. Are you saying that there are two basi= c >> models for enrollment? >> >> 1. "Hello, I am Brian. Please enrol me; the shared secret is *!&$=C2=A3= @." >> >> 2. "Hello, I am Brian. My public key is 12345, and should already >> be in your list. [Signed with my private key.]" >=20 > That=C2=B9s basically the trade-off although there are many variations = of #2. > Here is one example: >=20 > http://www.ietf.org/id/draft-pritikin-bootstrapping-keyinfrastructures-= 01.txt >=20 > The question is what are we willing to accept in the homenet in terms o= f > both device configuration and device requirements. Right, thanks. And this is question Anima has to ask for the more general= case - of course draft-pritikin is a contender. So, in my opinion, model #1 (a shared secret known to every device) is pretty weak. It might be acceptable for a small home network with a very careful human owner, but not beyond that limit. This is exact= ly the kind of shared secret that people will write down and lose along with= their wallet, or simply throw out in their household garbage. IMHO, for a network of any size or complexity, we need model #2. Brian From nobody Sun Oct 5 17:09:37 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBA11A014F; Sun, 5 Oct 2014 17:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVFAQSD9yyHo; Sun, 5 Oct 2014 17:09:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9511A0149; Sun, 5 Oct 2014 17:09:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B7697BE07; Mon, 6 Oct 2014 01:09:25 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDb5k0zoCakP; Mon, 6 Oct 2014 01:09:24 +0100 (IST) Received: from [10.87.48.8] (unknown [86.41.59.144]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5B4AFBE03; Mon, 6 Oct 2014 01:09:24 +0100 (IST) Message-ID: <5431DDB3.7090208@cs.tcd.ie> Date: Mon, 06 Oct 2014 01:09:23 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Brian E Carpenter , "Acee Lindem (acee)" References: <20141002144136.GA1847@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AF5E248@nkgeml512-mbx.china.huawei.com> <7A9C7BA6-E8DD-48F0-9B0E-CC2F36CBA05A@cisco.com> <5430A9F4.3000802@gmail.com> <5431BE3E.4@gmail.com> In-Reply-To: <5431BE3E.4@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/HasiHwQyw1-IC-0OwamzIqacEY8 Cc: "Toerless Eckert \(eckert\)" , Ted Lemon , "Leddy, John" , "Michael Behringer \(mbehring\)" , "Mark Baugher \(mbaugher\)" , "homenet@ietf.org" , "anima@ietf.org" , Sheng Jiang Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 00:09:30 -0000 Hiya, On 05/10/14 22:55, Brian E Carpenter wrote: > So, in my opinion, model #1 (a shared secret known to every device) > is pretty weak. It might be acceptable for a small home network > with a very careful human owner, but not beyond that limit. This is exactly > the kind of shared secret that people will write down and lose along with > their wallet, or simply throw out in their household garbage. > IMHO, for a network of any size or complexity, we need model #2. Its not a question that needs to be answered now, but I don't see how model #2 is consistent with the open-source model of doing stuff. (I'm being intentionally vague there as many devices are sort-of developed in an open-source manner.) If there were a way to base things on a PKI for manufacturers that worked for open-source communities that'd be really good, but I don't think I've seen such a thing proposed so far. I'm also very very unsure how model#2 might work in the face of equipment being end-of-lifed by very small companies or what happens after a teeny-tiny manufacturer goes bust. Were the anima (or homenet) WG to try address those questions, I think that'd be great. (And to repeat, I'm not looking for answers right now, but just to see that a WG will commit to tackle this.) S. From nobody Sun Oct 5 17:15:57 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9101A01D5 for ; Sun, 5 Oct 2014 17:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0x01ZR8gch-X for ; Sun, 5 Oct 2014 17:15:48 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDF641A016A for ; Sun, 5 Oct 2014 17:15:46 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id s960FkVo008164 for ; Sun, 5 Oct 2014 17:15:46 -0700 Message-ID: <5431DF32.6010805@mtcc.com> Date: Sun, 05 Oct 2014 17:15:46 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: homenet@ietf.org References: <20141002144136.GA1847@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AF5E248@nkgeml512-mbx.china.huawei.com> <7A9C7BA6-E8DD-48F0-9B0E-CC2F36CBA05A@cisco.com> <5430A9F4.3000802@gmail.com> <5431BE3E.4@gmail.com> <5431DDB3.7090208@cs.tcd.ie> In-Reply-To: <5431DDB3.7090208@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/CapeULFM_ZN5AvsIu5UenDbAkNU Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 00:15:51 -0000 On 10/05/2014 05:09 PM, Stephen Farrell wrote: > Hiya, > > On 05/10/14 22:55, Brian E Carpenter wrote: >> So, in my opinion, model #1 (a shared secret known to every device) >> is pretty weak. It might be acceptable for a small home network >> with a very careful human owner, but not beyond that limit. This is exactly >> the kind of shared secret that people will write down and lose along with >> their wallet, or simply throw out in their household garbage. >> IMHO, for a network of any size or complexity, we need model #2. > Its not a question that needs to be answered now, but I don't see > how model #2 is consistent with the open-source model of doing > stuff. (I'm being intentionally vague there as many devices are > sort-of developed in an open-source manner.) > > If there were a way to base things on a PKI for manufacturers that > worked for open-source communities that'd be really good, but I > don't think I've seen such a thing proposed so far. > > I'm also very very unsure how model#2 might work in the face of > equipment being end-of-lifed by very small companies or what > happens after a teeny-tiny manufacturer goes bust. > > Were the anima (or homenet) WG to try address those questions, > I think that'd be great. (And to repeat, I'm not looking for answers > right now, but just to see that a WG will commit to tackle this.) > > Are you reading into Brian's message a big P PKI (ie, CA's, etc) for #2? I didn't read it that way. Mike, confused From nobody Sun Oct 5 18:01:57 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E5C1A0211 for ; Sun, 5 Oct 2014 18:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swnK5_9iP78g for ; Sun, 5 Oct 2014 18:01:54 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F101A01B0 for ; Sun, 5 Oct 2014 18:01:54 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id g10so2427821pdj.18 for ; Sun, 05 Oct 2014 18:01:54 -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=y11k98P1nBiTdq44TYY3l8XWnHCxmRZOYHVYrcG9oTk=; b=P27BvnfYdJDdfdV/itbHonCDW0mSnsAivVXNU/hWik4h0MIDU1iSlSfKNnutaGzS3g I6J6M+Ifbid+bH6MUjPfr+dYGjrwKiJXAaSlUjCksscqEjth4eqsXbZRanUF6RE2HYTb 7v8ylPUUh5rRCbEotjWBSYNJwlqozi32kRs9KYQKUEU/FOVV5/wzDLvjjdS8crRGEiH8 CvGZkFlPClLBNT0BXPaxctAYeRrn2lZ3/swiQj69eN/RodkDddGYcsiM8cwjdX5BxSfR F0kVl2JHIg8mFofFN/FBCN8DIoDfsA7BtVB5gX2OHj69w7hV6Skp6CAvkFYvtIybKoeW z4lA== X-Received: by 10.70.38.109 with SMTP id f13mr15251929pdk.74.1412557314407; Sun, 05 Oct 2014 18:01:54 -0700 (PDT) Received: from [192.168.178.23] (154.197.69.111.dynamic.snap.net.nz. [111.69.197.154]) by mx.google.com with ESMTPSA id my4sm1372402pdb.85.2014.10.05.18.01.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 Oct 2014 18:01:53 -0700 (PDT) Message-ID: <5431E9FD.5070805@gmail.com> Date: Mon, 06 Oct 2014 14:01:49 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Thomas References: <20141002144136.GA1847@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AF5E248@nkgeml512-mbx.china.huawei.com> <7A9C7BA6-E8DD-48F0-9B0E-CC2F36CBA05A@cisco.com> <5430A9F4.3000802@gmail.com> <5431BE3E.4@gmail.com> <5431DDB3.7090208@cs.tcd.ie> <5431DF32.6010805@mtcc.com> In-Reply-To: <5431DF32.6010805@mtcc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/e4s8cWhGMcIp_OPBI8k2gUnfCKs Cc: homenet@ietf.org Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 01:01:56 -0000 On 06/10/2014 13:15, Michael Thomas wrote: > On 10/05/2014 05:09 PM, Stephen Farrell wrote: >> Hiya, >> >> On 05/10/14 22:55, Brian E Carpenter wrote: >>> So, in my opinion, model #1 (a shared secret known to every device) >>> is pretty weak. It might be acceptable for a small home network >>> with a very careful human owner, but not beyond that limit. This is >>> exactly >>> the kind of shared secret that people will write down and lose along >>> with >>> their wallet, or simply throw out in their household garbage. >>> IMHO, for a network of any size or complexity, we need model #2. >> Its not a question that needs to be answered now, but I don't see >> how model #2 is consistent with the open-source model of doing >> stuff. (I'm being intentionally vague there as many devices are >> sort-of developed in an open-source manner.) >> >> If there were a way to base things on a PKI for manufacturers that >> worked for open-source communities that'd be really good, but I >> don't think I've seen such a thing proposed so far. >> >> I'm also very very unsure how model#2 might work in the face of >> equipment being end-of-lifed by very small companies or what >> happens after a teeny-tiny manufacturer goes bust. >> >> Were the anima (or homenet) WG to try address those questions, >> I think that'd be great. (And to repeat, I'm not looking for answers >> right now, but just to see that a WG will commit to tackle this.) >> >> > > Are you reading into Brian's message a big P PKI (ie, CA's, etc) for #2? > I didn't read it that way. That is a correct non-reading ;-). I think the assumption is that there would be a local trust anchor of some kind which would be somewhat equivalent to a local CA. That's why the word 'bootstrap' figures in draft-pritikin-. Brian From nobody Mon Oct 6 03:31:20 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242821A1B8E for ; Mon, 6 Oct 2014 03:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.737 X-Spam-Level: X-Spam-Status: No, score=-4.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJiMlXeG6wjV for ; Mon, 6 Oct 2014 03:31:16 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A338A1A1BAA for ; Mon, 6 Oct 2014 03:31:16 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A16FFA2; Mon, 6 Oct 2014 12:31:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1412591474; bh=dhV8LawJAY9AlydfPINYIkcHWlNdyPKCCLzNr47oozY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WiRjl3129c9h1U6WknkzkW4uQL7rausNjgSBdf67cTJw1M3cQOAIK58lNjMr2MUR6 /rwEEytZdruQ2RKRwt95EObFWYDEFiKx8K8DUFjMDRGxSOgjgK7qzSj5pSDBZYllSy mHDfwEDg5ph9OCNWeR4zjmv/VkighUaUOcyt3CiY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 94DC29F; Mon, 6 Oct 2014 12:31:14 +0200 (CEST) Date: Mon, 6 Oct 2014 12:31:14 +0200 (CEST) From: Mikael Abrahamsson To: Steven Barth In-Reply-To: <542EED2F.6000501@openwrt.org> Message-ID: References: <542EED2F.6000501@openwrt.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/sXQBzvIJq927ez6Y1KnnRFg_M1I Cc: "homenet@ietf.org Group" Subject: Re: [homenet] HNCP Security & Trust Draft X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 10:31:19 -0000 On Fri, 3 Oct 2014, Steven Barth wrote: > Please note that this draft is in a very early stage so please help to > make additions, provide feedback and point out mistakes. Being a crypto novice, let me write some text and please tell me if it makes sense in the context of your draft (thanks for writing it, it looks like a good summary). I like SSH. SSH generates its own public/private key, there are fingerprints I can put in SSHFP DNSSEC secured posts, etc. Are the public/private keys considered to be similar to self-signed "certificates"? Anyhow, let me propose a scenario: I get my first homenet router and power it up. It comes with a QR code on it, and it has a button (or NFC, similar principle). I scan the QR code on my smartphone (with a special homenet-control-app) which gives it enough information to connect to the wifi of the router, then I am asked to press a button on the router to allow my phone to become the administration device. The QR code contains wifi information and key fingerprint ID so my phone can decide that it's speaking to the correct device. Now, after this, my phone app can speak to the router, and when I hook up another device to that router, it detects the new device, fingerprint ID etc, and asks me before it's allowed. After I ACK that it's allowed to talk to my homenet (which previously only consisted of a single router), they exchange session keys (or something) for management, so they can continue to talk. Just like with SSH allowing key based login, the management of homenet devices would rely on the public key for each accepted device being known to all the other devices, and this is how things authenticate. This would be the "anchor" that everything else relies on when it comes to security. Now, the problem is what to do when I lose my phone and don't have any backup, so perhaps I need a user/password based login to add new administration devices, it seems hard to work around. If someone gets the private key of any of the accepted homenet devices, of course everything falls down, but I don't see any way around it apart from having TPM etc. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Oct 6 04:04:56 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14761A1BAA for ; Mon, 6 Oct 2014 04:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzEkRgZtwk8d for ; Mon, 6 Oct 2014 04:04:52 -0700 (PDT) Received: from chi.subsignal.org (cxd-2-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:ed::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0681A1BB4 for ; Mon, 6 Oct 2014 04:04:51 -0700 (PDT) Received: from [192.168.178.66] (55d44d5f.access.ecotel.net [85.212.77.95]) by chi.subsignal.org (Postfix) with ESMTPSA id 2CCAE126095; Mon, 6 Oct 2014 13:04:55 +0200 (CEST) Message-ID: <54327751.8090800@openwrt.org> Date: Mon, 06 Oct 2014 13:04:49 +0200 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Mikael Abrahamsson References: <542EED2F.6000501@openwrt.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/MzCfEUSDcsm6SOUmia3vgrG1VtA Cc: "homenet@ietf.org Group" Subject: Re: [homenet] HNCP Security & Trust Draft X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 11:04:54 -0000 Hi Mikael, thanks for your feedback. > Being a crypto novice, let me write some text and please tell me if it > makes sense in the context of your draft (thanks for writing it, it > looks like a good summary). I do not consider myself to be a crypto expert either which is one of the reasons I'd try to offload the actual crypto to something well-known. Also this probably means that what I drafted might not be 100% accurate but I hope some of the actual expert will review it. > > I like SSH. SSH generates its own public/private key, there are > fingerprints I can put in SSHFP DNSSEC secured posts, etc. Are the > public/private keys considered to be similar to self-signed > "certificates"? I'll answer this in the context of the consensus based trust-scheme I added in addition to the PSK and PKI-based trust scheme. Yes, using self-signed certs here is possible since it's simply X.509. > > Anyhow, let me propose a scenario: > > I get my first homenet router and power it up. It comes with a QR code > on it, and it has a button (or NFC, similar principle). I scan the QR > code on my smartphone (with a special homenet-control-app) which gives > it enough information to connect to the wifi of the router, then I am > asked to press a button on the router to allow my phone to become the > administration device. The QR code contains wifi information and key > fingerprint ID so my phone can decide that it's speaking to the > correct device. Right that would be possible and the QR-code would be an additional "trust bootstrap ceremony" in that context. I actually had a phone / homenet-app scenario in mind when drafting this. So I was thinking about two possible cases. Case #1: The app is bound to the router itself via some kind of vendor-specific RPC so it can control its configuration directly. That RPC allows the app to read / receive fingerprints and names when a new device attempts to join the homenet and allows the user to give a verdict (trusted / untrusted) which is then announced by the router itself and not the phone. Case #1 is pretty obvious because it isn't really problematic and not bound to the phone itself and you could probably do the using some kind of webinterface on such a router. Case #2: The app itself speaks HNCP, i.e. the base state synchronization part (not the routing, addressing, SD whatever). It is standalone (i.e. doesn't depend on a specific router, just has to peered with any HNCP router once so it is trusted) from then on it can itself announce trust verdicts about other routers. > > Now, after this, my phone app can speak to the router, and when I hook > up another device to that router, it detects the new device, > fingerprint ID etc, and asks me before it's allowed. After I ACK that > it's allowed to talk to my homenet (which previously only consisted of > a single router), they exchange session keys (or something) for > management, so they can continue to talk. In Case #1 above it could tell the router to announce a trust verdict (trusted / untrusted) or in Case #2 it would do so by itself. The session key exchange would then be done by the underlying protocol i.e. DTLS, IPsec/IKE, ... The only real addition here should be that this underlying protocol (or its implementation) needs to allow a custom verification hook (i.e. notifies the HNCP daemon that there is a an unknown certificate and allows it to be accepted or not). For DTLS e.g. this shouldn't be problematic since most libraries seem to support such a callback. > Just like with SSH allowing key based login, the management of homenet > devices would rely on the public key for each accepted device being > known to all the other devices, and this is how things authenticate. > This would be the "anchor" that everything else relies on when it > comes to security. Yes, each device would announce the fingerprints of the certificates or public keys (details TBD) that it trusts in its HNCP-state. > > Now, the problem is what to do when I lose my phone and don't have any > backup, so perhaps I need a user/password based login to add new > administration devices, it seems hard to work around. Each device may announce verdicts about public keys / certificates and verdicts of device which are absent are cached by other HNCP routers so your case and Case #2 above would work without the app/phone always being there. > > If someone gets the private key of any of the accepted homenet > devices, of course everything falls down, but I don't see any way > around it apart from having TPM etc. Yeah that's also the downside here. It's even more apparent if anyone can say someone else is trusted or not. But I guess ultimately its the same issue and once you are actually a trusted homenet router you can do more nasty things like messing with routing etc. than actually attacking the trust system itself, especially since most of the algorithms / applications run over HNCP are distributed / consensus based anyway. Cheers, Steven From nobody Tue Oct 7 02:01:01 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633991A9148 for ; Tue, 7 Oct 2014 02:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8z8tWw53tGfJ for ; Tue, 7 Oct 2014 02:00:55 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094871A8FD4 for ; Tue, 7 Oct 2014 02:00:54 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x13so8714190wgg.30 for ; Tue, 07 Oct 2014 02:00:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=vRRnPRue6cT5fWGB3TsLxoa+C/XyYefXSDq8eBu9sFY=; b=lYOtjCU6i/1O4NWcZcU2EKtmF7W3o3JiUTijXY01YsdCBNWJ2Iypz1AKzjX1+q2zKA sV/WsTycvFnPWcLA8oFjCwvy7FeYiKiqOj0nbTmkTCQ5mDK4r8vAf8WbW6/Zpqec9Ost AuZ2RoqMJfqKuvsumPwH6Y1v4VbAkdeXR2EI+ZBV96b3ejIrQ3Oj+1JVYSn6Tz783ycp TQtuoUP7ikLWmGr4Z/iFVIE9Owltbz8WaWqLqGi3nYt39FJYfWHtpSfyN1T6UZY56h1K wEuHx2V4dvIfUdvWL431T0S/KsvRQu7GJhW3P3AUOfwJjsigbJ11rOvcxMEr4SPxMyKy KwVw== X-Gm-Message-State: ALoCoQnz1LcdxxTUeEyc0PjpMqV5DZXNTXAkTkvxus5Z+pBZTqOGjFaQxYpUvPxKDQ6LJkgeViOc X-Received: by 10.194.78.238 with SMTP id e14mr2961419wjx.48.1412672453453; Tue, 07 Oct 2014 02:00:53 -0700 (PDT) Received: from [10.55.189.249] (173-38-208-170.cisco.com. [173.38.208.170]) by mx.google.com with ESMTPSA id he2sm1984949wib.4.2014.10.07.02.00.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 02:00:51 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-DDE14193-A7A2-4234-8924-AFA160246918 Mime-Version: 1.0 (1.0) From: Mark Townsley X-Mailer: iPad Mail (12A405) In-Reply-To: Date: Tue, 7 Oct 2014 11:00:50 +0200 Content-Transfer-Encoding: 7bit Message-Id: <626B3345-F1B9-4EF0-8957-8EBAA81540B1@townsley.net> References: <542BFFAE.1080105@cisco.com> <542C59B3.10700@gmail.com> <5F26857C-1C41-4D1F-AA4A-B7D9E947180F@townsley.net> <542CC380.1030600@gmail.com> To: Lorenzo Colitti Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/AHpbU4LJVruZ3IOUx6yVZJsE52I Cc: Benoit Claise , "homenet@ietf.org" , Markus Stenberg , "anima@ietf.org" Subject: Re: [homenet] [Anima] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 09:00:57 -0000 --Apple-Mail-DDE14193-A7A2-4234-8924-AFA160246918 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The charter as written now aims to develop building blocks which can be appl= ied commonly across a wide range of networks including enterprise, SP, (home= ?), and IOT, yet the very first use-case listed in order to provide WG focus= is restricted to carrier-only? (and, to Lorenzo's point, what does that act= ually mean with respect to IP address assignment?) If a carrier-only use-case is doing its job of focusing the WG, it will natu= rally lead to carrier-centric building blocks, contradictory to the stated g= oal of the group. - Mark > On Oct 2, 2014, at 8:26 AM, Lorenzo Colitti wrote: >=20 >> On Thu, Oct 2, 2014 at 12:16 PM, Brian E Carpenter wrote: >> > This use case is precisely what draft-ietf-homenet-prefix-assignment do= es (which has roots all the way back to draft-arkko-homenet-prefix-assignmen= t-00 in October 2011). So to homenet, this is a solved problem - with an alg= orithm that has been applied not just to HNCP, but to OSPF and ISIS. >>=20 >> Well, we have a bug in our short description, because the intention is to= >> support prefix assignment in a carrier scenario, which is different >> in many ways.=20 >=20 > Really? Which ways? =20 --Apple-Mail-DDE14193-A7A2-4234-8924-AFA160246918 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

The charter as written n= ow aims to develop building blocks which can be applied commonly across a wi= de range of networks including enterprise, SP, (home?), and IOT, yet the ver= y first use-case listed in order to provide WG focus is restricted to carrie= r-only? (and, to Lorenzo's point, what does that actually mean with respect t= o IP address assignment?)

If a carrier-only use-cas= e is doing its job of focusing the WG, it will naturally lead to carrier-cen= tric building blocks, contradictory to the stated goal of the group.

- Mark

On Oct 2, 2014, at 8:26 AM, Lorenzo C= olitti <lorenzo@google.com> w= rote:

On Thu, Oct 2, 2014 at 12:16 PM= , Brian E Carpenter <brian.e.carpenter@gmail.com> wr= ote:
> This use case is= precisely what draft-ietf-homenet-prefix-assignment does (which has roots a= ll the way back to draft-arkko-homenet-prefix-assignment-00 in October 2011)= . So to homenet, this is a solved problem - with an algorithm that has been a= pplied not just to HNCP, but to OSPF and ISIS.

Well, we have a bug in our short description, because the intention i= s to
support prefix assignment in a carrier scenario, which is different
in many ways. 

Really? Which ways? &nbs= p;  
= --Apple-Mail-DDE14193-A7A2-4234-8924-AFA160246918-- From nobody Tue Oct 7 05:44:15 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8361A1BBC; Tue, 7 Oct 2014 05:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.173 X-Spam-Level: X-Spam-Status: No, score=-1.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aE5JA6LEnNoA; Tue, 7 Oct 2014 05:44:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 813831A00ED; Tue, 7 Oct 2014 05:44:11 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 29B9E20012; Tue, 7 Oct 2014 08:44:12 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B934E63AED; Tue, 7 Oct 2014 08:44:09 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9C1FF638D7; Tue, 7 Oct 2014 08:44:09 -0400 (EDT) From: Michael Richardson To: "homenet\@ietf.org" , "anima\@ietf.org" In-Reply-To: <626B3345-F1B9-4EF0-8957-8EBAA81540B1@townsley.net> References: <542BFFAE.1080105@cisco.com> <542C59B3.10700@gmail.com> <5F26857C-1C41-4D1F-AA4A-B7D9E947180F@townsley.net> <542CC380.1030600@gmail.com> <626B3345-F1B9-4EF0-8957-8EBAA81540B1@townsley.net> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/U4DOHXH_QoovpJznRkFTPNAhd3Q Subject: Re: [homenet] [Anima] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 12:44:13 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Mark Townsley wrote: > The charter as written now aims to develop building blocks which can = be > applied commonly across a wide range of networks including enterprise, > SP, (home?), and IOT, yet the very first use-case listed in order to > provide WG focus is restricted to carrier-only? (and, to Lorenzo's > point, what does that actually mean with respect to IP address > assignment?) > If a carrier-only use-case is doing its job of focusing the WG, it wi= ll > naturally lead to carrier-centric building blocks, contradictory to t= he > stated goal of the group. I want to change the word "carrier-only" for "professionally-managed" in yo= ur wording, and therefore agree, and say, "Good" Managed networks, be they in ISPs or industrial IoT settings have different (perhaps simpler) solutions than in the home. I think the assumption that "IoT" implies homenet networks is incorrect: there are lots of IoT which is not in the home; and I totally agree that managed-solutions are inappropria= te in the home. I don't think one-size fits-all here. I suggest that ANIMA focus on "professionally-managed" networks first, with "Homenet" being a secondary consideration, akin to IPv4 is in the homenet W= G. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVDPgF4CLcPvd0N1lAQJ2MAf/b4fcu/N4vhHgF5VEr0Pgxh2wF51S9MHS VQdYZA4X8DDOi4clA6RfE4/4OacFcT1KW+u0s8SRTsX9E9okhL+MVvRtLvpreN7X C7ZsLe7AlbsKU7Fusr9hf6QhzuyWxgwYBZx/42XQrZJ48oBsZ+U9D5WaUrlAz+Fw QiOFjKdzKLxf5JM8FLPxdpIwpBSFCU+WDvjFpfgmvH9jR64rrMPDmcULd/jJRsAl Z2h3lLAxKgVtGa9CWBINfLiH8dKVQnq2p8HknZnLSZ23fe9js4IuqRKTL7EPTpax VhOljhPYO/i25RSC1339tp9oFA10j9wh6rJffDGuaZ8bO8hQtusurA== =/jb6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 7 07:13:40 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011401A6F2C for ; Tue, 7 Oct 2014 07:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WL7L4cibEN-Q for ; Tue, 7 Oct 2014 07:13:28 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A544D1A6F05 for ; Tue, 7 Oct 2014 07:13:27 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x12so9367686wgg.8 for ; Tue, 07 Oct 2014 07:13:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=s2BcDbr6V7+M8tCVGrZHbKrqNNIrabRiALyv0SgBNmY=; b=Q9gv08F44EzNe5CF4d6q+Hb9SYGnuYKdW2dn8djMGx6/DMOe9tQhSNPx4G8IG9Ojup hhW7uN441XDPyo7uBKarJMABbLQejNj2P2hq5iPaqECTNe3Ryp/AJmEMIo1BGIUsbw0t QiGAUREOXjL+Elozy1nY/uuYXXZ06s1+ohXaZMxH6lgam6okS02tqPVJu9nuyjB9WhE/ UyHSM9qHLT5X4LDYirMtUSInSupvSjbuanSmcp55gpJ9b6BlK6NtvpUJPFAxfuTB8LVa 2KyuQFclYGoPAMFCnc5sJPguInr8YdrDo7h6tk/rMzqIgIUSCAfl7bcl5e6+lec0oPrY hTmg== X-Gm-Message-State: ALoCoQmFfWNxXrPjivAGpKd1C2SWwGgcHooRIVvm7Z1wEFmFaLabzRfuXzk20dF4jYOwzgpd6lUo X-Received: by 10.194.234.66 with SMTP id uc2mr1034981wjc.26.1412691206157; Tue, 07 Oct 2014 07:13:26 -0700 (PDT) Received: from [10.55.189.249] (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id wx3sm20915518wjc.19.2014.10.07.07.13.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 07:13:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Mark Townsley X-Mailer: iPad Mail (12A405) In-Reply-To: <25295.1412685849@sandelman.ca> Date: Tue, 7 Oct 2014 16:13:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <542BFFAE.1080105@cisco.com> <542C59B3.10700@gmail.com> <5F26857C-1C41-4D1F-AA4A-B7D9E947180F@townsley.net> <542CC380.1030600@gmail.com> <626B3345-F1B9-4EF0-8957-8EBAA81540B1@townsley.net> <25295.1412685849@sandelman.ca> To: Michael Richardson Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/-5R3P3z3ULtYe79wu4eIcRdUYKs Cc: "homenet@ietf.org" , "anima@ietf.org" Subject: Re: [homenet] [Anima] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 14:13:30 -0000 > On Oct 7, 2014, at 2:44 PM, Michael Richardson wro= te: >=20 > I suggest that ANIMA focus on "professionally-managed" networks first, wit= h > "Homenet" being a secondary consideration, akin to IPv4 is in the homenet W= G. I like that suggestion, with a caveat. The caveat being that I think there i= s room for a "professionally managed" home network as well - something homen= et to date has touched on, but for the most part avoided.=20 It should be up to the user to decide to have their home network professiona= lly managed of course, but as long as that choice is made, a "professionally= managed network" WG might be able to provide tooling equally as well for th= e home as for an enterprise (or SOHO, etc, to Leddy's point). Here is where i= ncluding what homenet has already done is important for a new WG, if nothing= else but to coexist properly between the two solutions. For example, Homene= t has had to spend quite a bit of cycles dealing with what we think the home= network will look like by the time HNCP arrives (Hierarchical DHCPv6-PD, H= IPNET, etc.). Anima should be able to make the same consideration for how to= operate with HNCP in the network as well - e.g., new "professionally manage= d" solution when available, "non-managed" via HNCP otherwise. In terms of scope of work and where it is done, I'm not sure this means the "= professionally managed home" work should done in anima or homenet WGs, but I= do know we shouldn't do it with blinders on. - Mark= From nobody Tue Oct 7 07:23:24 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88631ACDB0 for ; Tue, 7 Oct 2014 07:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufL2U3lww7B2 for ; Tue, 7 Oct 2014 07:23:21 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4131ACD9D for ; Tue, 7 Oct 2014 07:23:21 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x12so9396153wgg.8 for ; Tue, 07 Oct 2014 07:23:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=eOj0Xzax3bcxC/LPHDw5dytO1MUCFeWa4/kG7Ob4bV4=; b=kA9K2prMNxVQXFohozrK6ATm4HrS26ta+7VDcJpiSZsEWzA2eSXkLDfHw7h7KtOk+w u78YApaL2HIh5Oqnwrp9nKDt80juzoyLPkIK3C3jb6ol7p8mqafEne5SWGmkF/UwSCBl xfUjGGK40KQubihyZXxmqHWFu+TiOSf9HoTBpZ3tkz6C48vyVo00CxMSzJ/H+v6YkG1N 6HC6fMSF9MnDRHPxZz5gN8DmYFP1+s4oH8JLqMK3U0WsOb9qfmnJ+RjPbAfRnIXi+sSb Npf4bs9s0hPnHwIPOBVHZH/p7Pgd3jCd9EhRF7azOxP6TJPdfW11mkzLDLbcrHkx7Igc Q4Fg== X-Gm-Message-State: ALoCoQmWRb3YfG1WDMIRHTcd9n8k5z5aiy+wm651257leo7okZg6pMhjtnjk1Z+jBy218sAfCb+G X-Received: by 10.180.90.71 with SMTP id bu7mr4846695wib.33.1412691800048; Tue, 07 Oct 2014 07:23:20 -0700 (PDT) Received: from [10.55.189.249] (173-38-208-170.cisco.com. [173.38.208.170]) by mx.google.com with ESMTPSA id dc9sm14935614wib.5.2014.10.07.07.23.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 07:23:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Mark Townsley X-Mailer: iPad Mail (12A405) In-Reply-To: <542DA4F7.4030406@gmail.com> Date: Tue, 7 Oct 2014 16:23:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6D258687-4D90-4AF3-AADF-BFA3EBBD8C33@townsley.net> References: <542BFFAE.1080105@cisco.com> <542C59B3.10700@gmail.com> <542DA4F7.4030406@gmail.com> To: Brian E Carpenter Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/I_Hr69IGt6_EGjSp4IjVlqMMXds Cc: Benoit Claise , "homenet@ietf.org" , Markus Stenberg , "anima@ietf.org" Subject: Re: [homenet] [Anima] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 14:23:24 -0000 > On Oct 2, 2014, at 9:18 PM, Brian E Carpenter wrote: >=20 > but I would expect HNCP to be much sooner than Anima. Then anima is going to have to deal with HNCP one day in any case. The hando= ff between the distributed manner in which HNCP carves up and allocates IP p= refixes will need to mesh with whatever anima comes up with. The good news is that homenet is far along enough that it has thought about t= his type of thing, with an algorithm, code, and drafts that include marking i= ndividual prefixes by manual "or other means" configuration while still supp= orting automatic determination of subnets that were not otherwise addressed.= This is the kind of thing that I want to be sure anima keeps in mind, lest o= ur worlds collide. - Mark >=20 >=20 >>> 2) I am also a little nervous about the IoT reference in the >>> charter. We haven't yet seen a use case description that would >>> apply to IoT (which has IMHO a much broader scope than home >>> networks, e.g. building services.) >>>=20 >>> I think the initial focus is indeed on enterprise and carrier >>> networks where the OPEX pain is greatest, but we should not >>> artificially limit the applicability either. >>=20 >> I would just say that you aim at enterprise networks and leave it at that= , then. Considering home networks, and even more so constrained devices in t= he IoT land have different management model and resources than your typical e= nterprise devices. >=20 > Yes, but we are (to be frank) trying to disrupt the current enterprise > model and I don't want to constrain the thinking by constraining > the scope. >=20 >>=20 >>> There are the existing NMRG documents and there will be an >>> overview document, but we are following quite specific direction >>> from the ADs about this. >>=20 >> Well, at least providing links to them in the charter would be probably g= ood idea then. As it is, it looks like =E2=80=98we have solution, here is th= e WG=E2=80=99 to me. >=20 > The NMRG drafts are cited in the charter. We are trying to avoid > claiming that existing solution proposals *are* the draft solutions, > because that's the WG's choice to make. >>=20 >>>> It is not also clear to me how well the suitability of the >>>> solution has been evaluated. For implementation of some >>>> autonomic, distributed algorithms, point-to-point negotiation >>>> protocol such as the suggested solution is far from optimal. >>>> In case of homenet, we moved from hierarchical DHCPv6 PD >>>> (point-to-point hierarchy) to a distributed algorithm >>>> (draft-ietf-homenet-prefix-assignment*) which was result of >>>> over two years of draft updates, academic proving of >>>> correctness etc. >>> There is a subtle point here. The idea is to produce generic >>> components that do *not* imply specific autonomic algorithms. If >>> we do it correctly, those components will support either a top >>> down or a distributed mechanism or even a blend of the two >>> approaches. So actually the solution choices come later: we >>> don=E2=80=99t have to decide in advance between top-down and peer-to-pee= r. >>=20 >> A protocol (draft-jiang-config-negotiation-protocol) that is essentially p= oint-to-point state push/pull mechanism does not seem like natural fit for t= hat (+- some discovery). >=20 > Well, I disagree, but that again is a job for the WG. >=20 >> The scalable solutions with such protocol require hierarchies of delegati= on. For example, given prefix delegation problem, the reasonable (=3Dlow num= ber of total message exchanges) solutions wind up subdividing the prefix hie= rarchically, or alternatively with some =E2=80=98god node=E2=80=99(s) that p= erform the allocations. It becomes harder if you have multiple sources of sa= me resource (=3Dprefix) or want to be robust in case of failure. >=20 > If a resource needs a hierarchy you would contstruct that on top of > the negotiation protocol, not as an intrinsic feature of the protocol. >=20 >>>> although it is covered >>>> only by one mention in the whole charter (and the rest does >>>> not seem very IoT oriented). >>> So should we say in the charter that the scope is everything but >>> the initial focus is enterprise and carrier? >>=20 >> Or that you are developing enterprise solution and it can work for anythi= ng with luck. >=20 > No, not with luck, if we do it right. That would be like saying that > DHCP(v4) was designed for campus networks but would work for > home networks with luck. >=20 >>=20 >>>> Looking at the solutions, from homenet developer / draft >>>> writer point of view, I would welcome a general trust >>>> bootstrapping framework. I am not convinced by the current >>>> solution draft for that (it assumes too many components for a >>>> home network case at least). A lot of the other things seem >>>> somewhat enterprise-y (control plane with IPsec, own routing >>>> protocol and ULAs? Not in IoT device at least, nor probably >>>> in constrained homenet router), or just unsuitable, such as >>>> the negotiation protocol that does not seem like a good fit >>>> for distributed decision making which is usually the key >>>> thing in autonomic networking. >>> That means we have explained the negotiation idea badly. It is >>> not top-down negotiation like >>> draft-boucadair-network-automation-requirements. It is peer to >>> peer with top-down as a special case. >>=20 >> Sure, it is simple =E2=80=98who is there=E2=80=99, =E2=80=99{can I haz X,= (yes|no|no but you can have Y)}+=E2=80=99 protocol as far as I can read th= e draft anyway (draft-jiang-config-negotiation-protocol-02) >=20 > Exactly. And that is pretty close to Turing-complete so it > could be used very generally. >=20 >>=20 >> It is not obvious to me how it would be even used to tell other all other= nodes about e.g. change in some network parameter (say, NTP server). Is it a= =E2=80=98request=E2=80=99? Who is it sent to? How to prevent duplication of= sending it to nodes that already did receive it? >=20 > Yes. I noticed that when considering Rene's comment about state > synchronization and it needs more work. Nobody is saying that > it is fully baked yet. >=20 >>=20 >> =46rom my point of view, a general network infra protocol needs >>=20 >> - discovery >> - state push/pull _network wide_ >>=20 >> HNCP does this; I am not sure how CDNP can be used for this, but I welcom= e examples. >=20 > It's intentionally peer-to-peer so network-wide requires propagation; > but I don't understand how HNCP could do some of the other things we > want. There will be a revised requirements in a forthcoming draft, so > I'd rather have that discussion later. >=20 > Let me be clear: if HNCP can be generalised to do what we need (which > would probably mean changing its name slightly) I'd be delighted. > There is absolutely nothing to be gained by having two protocols if > one will work. >=20 > Brian >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue Oct 7 10:51:15 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CDE1A86E1; Tue, 7 Oct 2014 10:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reCFV5Me01rR; Tue, 7 Oct 2014 10:51:09 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FB951A8029; Tue, 7 Oct 2014 10:51:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E52DA20012; Tue, 7 Oct 2014 13:51:10 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id C643463AED; Tue, 7 Oct 2014 13:51:07 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B036D638D7; Tue, 7 Oct 2014 13:51:07 -0400 (EDT) From: Michael Richardson To: Mark Townsley In-Reply-To: References: <542BFFAE.1080105@cisco.com> <542C59B3.10700@gmail.com> <5F26857C-1C41-4D1F-AA4A-B7D9E947180F@townsley.net> <542CC380.1030600@gmail.com> <626B3345-F1B9-4EF0-8957-8EBAA81540B1@townsley.net> <25295.1412685849@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/JmoYBrepHb6W_qbyXzIsfnK7aA0 Cc: "homenet@ietf.org" , "anima@ietf.org" Subject: Re: [homenet] [Anima] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 17:51:12 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Mark Townsley wrote: >> I suggest that ANIMA focus on "professionally-managed" networks firs= t, >> with "Homenet" being a secondary consideration, akin to IPv4 is in t= he >> homenet WG. > I like that suggestion, with a caveat. The caveat being that I think > there is room for a "professionally managed" home network as well - > something homenet to date has touched on, but for the most part > avoided. Sure; we have avoided it because I think most see the only professional nearby being the ISP, and few of *us* professionals want them mucking around in our home. That's the personal experience of IETF contributors as individuals. However, we also see in our architecture that we expect two be able to get service from two ISPs, so in the end, our pessimism about the ability of the ISP professional to manage our home network is legitimate. There can't be only one --- cooperation is required. There are other professional organizations that would like to help manage o= ur homes: Apple, Google and Microsoft come to mind. Yet, even there, we expect cooperation. That's why the secure bootstrap problem is more difficult in the home than it is, in for instance, an oil refinery. > It should be up to the user to decide to have their home network > professionally managed of course, but as long as that choice is made,= a > "professionally managed network" WG might be able to provide tooling > equally as well for the home as for an enterprise (or SOHO, etc, to > Leddy's point). Here is where including what homenet has already done > is important for a new WG, if nothing else but to coexist properly > between the two solutions. For example, Homenet has had to spend quite > a bit of cycles dealing with what we think the home network will look > like by the time HNCP arrives (Hierarchical DHCPv6-PD, HIPNET, > etc.). Anima should be able to make the same consideration for how to > operate with HNCP in the network as well - e.g., new "professionally > managed" solution when available, "non-managed" via HNCP otherwise. > In terms of scope of work and where it is done, I'm not sure this mea= ns > the "professionally managed home" work should done in anima or homenet > WGs, but I do know we shouldn't do it with blinders on. What do you mean "with blinders on" here? Usually that means that the horse has blinders to avoid distraction by thin= gs that aren't in front of them. So I think that you mean that professional managed ideas should be visible to Homenet and ANIMA, but do you really mea= n: ANIMA should pay attention to non-managed networks HOMENET should pay attention to managed networks =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVDQoCYCLcPvd0N1lAQI0zgf/Q7WXBwUz919Y1hIAIMaJl7MnXfkHSQkX 7c+GJ82v4DA8A2oqyLZSnqeodGFsJ3UPIfRwYqzwlIfQds48Fx9pLkK10JMAJEkd g2uNS26pvFX0XNIBZjfstTYaVpn05f548LZ1WUqL4YPPukOzW+A2gwKddvzrVqCI PbEZEHAPEsl1/YLdDUkee0/+Q/kr/CuCZyKQY4NFnhYb26KC2ptnjQfklOvMIDX/ MwHpwlJX9rEpp/udKYBquyz226R3Lch+5m6hywUTXTwTgXEFsafDK/tXkNDW0sHF yfTxuplxduZKdRfXgZxB8ru1uBNfYSXPpvnBYw3V9G8byh7OTT6MYg== =BrBD -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 7 11:13:03 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CE21A8715 for ; Tue, 7 Oct 2014 11:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLN209XQbTT1 for ; Tue, 7 Oct 2014 11:12:56 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300A01ACEF5 for ; Tue, 7 Oct 2014 11:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4205; q=dns/txt; s=iport; t=1412705560; x=1413915160; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2tQzCM8uKpEPD98M2fJuf14CNO4cYtJAS5XatYSWNls=; b=ZR+lbdilLeyehN+d4ZeizzETGue/QJSWwLWNHsvw5SvajYZ/cwd4SN5g 3l57I2+7+TfkvWVSJsSDXVj29mRPjcU1f0SsqXSgppEJ0MzQTzy0U/VLW DjwoX56RP9XFsR4pN6wSAJzgPBPiDkluTUKCJRGEnYXJFWDIAUb8bl2Te M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAEgsNFStJA2G/2dsb2JhbABfgw5TWATMegqGeVQCgRAWAXuEAwEBAQMBAQEBNzQLEAIBGgYeECcLFw4CBA4FG4gbCA3CIQETBJBEB4MtgR4FhGIzAoxfiHqCUoEtkFyDf4IggUNsgUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,672,1406592000"; d="scan'208";a="358256975" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP; 07 Oct 2014 18:12:39 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s97ICdKg013905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Oct 2014 18:12:39 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.49]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 7 Oct 2014 13:12:38 -0500 From: "Mark Baugher (mbaugher)" To: Michael Richardson Thread-Topic: Home-network support (was Re: [homenet] [Anima] Homenet feedback on the ANIMA charter Thread-Index: AQHP3gntSYpkVYyVR0+7l29ZRpFGlZwksh8AgAA+ZYCAABjwAIAAPNSAgAAGAwA= Date: Tue, 7 Oct 2014 18:12:38 +0000 Message-ID: <1DACA699-3FE9-406C-A79C-5CDC90DEC0A5@cisco.com> References: <542BFFAE.1080105@cisco.com> <542C59B3.10700@gmail.com> <5F26857C-1C41-4D1F-AA4A-B7D9E947180F@townsley.net> <542CC380.1030600@gmail.com> <626B3345-F1B9-4EF0-8957-8EBAA81540B1@townsley.net> <25295.1412685849@sandelman.ca> <23190.1412704267@sandelman.ca> In-Reply-To: <23190.1412704267@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.68.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/e6-RlvMaxxIkw6hFgyHKtydCkF0 Cc: "homenet@ietf.org" , Mark Townsley Subject: [homenet] Home-network support (was Re: [Anima] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 18:13:00 -0000 On Oct 7, 2014, at 10:51 AM, Michael Richardson wro= te: >=20 > Mark Townsley wrote: >>> I suggest that ANIMA focus on "professionally-managed" networks first, >>> with "Homenet" being a secondary consideration, akin to IPv4 is in the >>> homenet WG. >=20 >> I like that suggestion, with a caveat. The caveat being that I think >> there is room for a "professionally managed" home network as well - >> something homenet to date has touched on, but for the most part >> avoided. >=20 > Sure; we have avoided it because I think most see the only professional > nearby being the ISP, and few of *us* professionals want them mucking aro= und > in our home. That's the personal experience of IETF contributors as > individuals. The major retail brands also offer remote network support using tools that come with their routers. It should always be possible to plug a router in front of an ISP device for "over-the-top" support from whatever provider one trusts to do that. And I think most people would benefit from having professional support on their home network though few seem to be willing=20 to pay for it. The more competent ISPs often do it for free. But there's the problem of having routers owned by other entities on the network: An ISP device and a retail device is probably more common than two ISPs. >=20 > However, we also see in our architecture that we expect two be able to ge= t > service from two ISPs, so in the end, our pessimism about the ability of = the > ISP professional to manage our home network is legitimate. There can't b= e > only one --- cooperation is required. If the cooperation entails telling your competitors who your customers happ= en to be, then it's probably a requirement that won't be satisfied, at least not for a long time. >=20 > There are other professional organizations that would like to help manage= our > homes: Apple, Google and Microsoft come to mind. Yet, even there, we exp= ect > cooperation. That's why the secure bootstrap problem is more difficult = in > the home than it is, in for instance, an oil refinery. >=20 The only model that seems realistic to me is to have the home network owner take ownership of the home network, possibly with the help of a third=20 party that is contracted to provide professional support. =20 Mark >> It should be up to the user to decide to have their home network >> professionally managed of course, but as long as that choice is made, a >> "professionally managed network" WG might be able to provide tooling >> equally as well for the home as for an enterprise (or SOHO, etc, to >> Leddy's point). Here is where including what homenet has already done >> is important for a new WG, if nothing else but to coexist properly >> between the two solutions. For example, Homenet has had to spend quite >> a bit of cycles dealing with what we think the home network will look >> like by the time HNCP arrives (Hierarchical DHCPv6-PD, HIPNET, >> etc.). Anima should be able to make the same consideration for how to >> operate with HNCP in the network as well - e.g., new "professionally >> managed" solution when available, "non-managed" via HNCP otherwise. >=20 >> In terms of scope of work and where it is done, I'm not sure this means >> the "professionally managed home" work should done in anima or homenet >> WGs, but I do know we shouldn't do it with blinders on. >=20 > What do you mean "with blinders on" here? > Usually that means that the horse has blinders to avoid distraction by th= ings > that aren't in front of them. So I think that you mean that professiona= l > managed ideas should be visible to Homenet and ANIMA, but do you really m= ean: > ANIMA should pay attention to non-managed networks > HOMENET should pay attention to managed networks >=20 > --=20 > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Tue Oct 7 12:11:00 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E881A03A6; Tue, 7 Oct 2014 12:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksxuJApMy_WQ; Tue, 7 Oct 2014 12:10:50 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1EB1A039A; Tue, 7 Oct 2014 12:10:49 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id v10so5554742pde.20 for ; Tue, 07 Oct 2014 12:10:49 -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=ZzJqpFLNhFGoAmuYjJzUGUfEZuy6PzJwHu8m9q0k5Ac=; b=ti1HRFVPRzDulwAMzL6dxpEHv9d6Ow1vgTsRGzRPTQAUqt+C43rLVLLQITTFVICmpz tAnFBoqu6O8UnAJ5Ga9Ps89O22Do5EmgG+30E5YiVko4T7B9gwHLKFB/SYTI8Lhib/+5 iwdkqj3W3vxosmcBW5ZJUcEZFI1G87LUOU3e9SE9w64zS6n8MrGM+5nqeeh0inlHn3ZP QF44UtkblijiXFH3uV2y60gfzsFggHKB7P2ZlXODjQYmw3EgJ6cHM1aj6EfRRnw7t9/A PxxxEt8mWc918w7GEuiBNtzPtC2OM9uqMFaL/JjVIHhZYKYBd5BKv1MCHwW+BRehLw5h QkLQ== X-Received: by 10.66.240.197 with SMTP id wc5mr5432112pac.87.1412709049431; Tue, 07 Oct 2014 12:10:49 -0700 (PDT) Received: from [192.168.178.23] (224.200.69.111.dynamic.snap.net.nz. [111.69.200.224]) by mx.google.com with ESMTPSA id cq7sm14552997pdb.16.2014.10.07.12.10.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 12:10:48 -0700 (PDT) Message-ID: <54343AB9.2010706@gmail.com> Date: Wed, 08 Oct 2014 08:10:49 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson References: <542BFFAE.1080105@cisco.com> <542C59B3.10700@gmail.com> <5F26857C-1C41-4D1F-AA4A-B7D9E947180F@townsley.net> <542CC380.1030600@gmail.com> <626B3345-F1B9-4EF0-8957-8EBAA81540B1@townsley.net> <25295.1412685849@sandelman.ca> <23190.1412704267@sandelman.ca> In-Reply-To: <23190.1412704267@sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/A-EhhIWqn-o5nuYD8xGOPhWjnRU Cc: "homenet@ietf.org" , Mark Townsley , "anima@ietf.org" Subject: Re: [homenet] [Anima] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 19:10:56 -0000 On 08/10/2014 06:51, Michael Richardson wrote: > Mark Townsley wrote: > >> I suggest that ANIMA focus on "professionally-managed" networks first, > >> with "Homenet" being a secondary consideration, akin to IPv4 is in the > >> homenet WG. > > > I like that suggestion, with a caveat. The caveat being that I think > > there is room for a "professionally managed" home network as well - > > something homenet to date has touched on, but for the most part > > avoided. > > Sure; we have avoided it because I think most see the only professional > nearby being the ISP, and few of *us* professionals want them mucking around > in our home. That's the personal experience of IETF contributors as > individuals. As far as the Anima charter goes (see subject line), we need to use the use cases to *test* the Anima technical choices (when we make them) against the real world. So eventually we'd need all kinds of use cases, which is why the charter mentions a wide scope. But we need to start with a finite task, which is why the charter mentions a couple of specific cases. Brian From nobody Tue Oct 7 12:19:13 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B608E1A010E; Tue, 7 Oct 2014 12:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVYL83O0zzJD; Tue, 7 Oct 2014 12:19:02 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4C81A0398; Tue, 7 Oct 2014 12:18:42 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id ey11so7571819pad.41 for ; Tue, 07 Oct 2014 12:18:42 -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=ML0x3/hULZP/FDYM9CQIr/TcKcERM8PfMJ3Y6xD/wgs=; b=Gp6MxiePFJLHIAO9XcpWs3zFtLFjxmLH7mmr/dhbDK0wxJs36cFxVzyokl10E2xBxN eIpTQ3iUvBRMYT5rMPUddUTKVZFG0fn09qOYK9yeSl0O0yYxYcWhoU8G3tuwgL1CZcoG C1CTrGeRddpofju9fEAjtb6M+5jbzJQxJfPHaoicPFOqFhIRQxpbnZEYiMAHoYp+1Obu 5TCW5siSBMLaq0J+CUZO/Zor4mijWDI3sILhDj48rliFXa8Z3qDH8Qt2i5pJrCEN+i75 Usup93cnQMjD4SUO6FTlURkbwJ4OZZNXvVbqnUbvOlPwMi/dswUpZWHXLenfNCaw+X70 hciw== X-Received: by 10.68.239.135 with SMTP id vs7mr4114327pbc.32.1412709521986; Tue, 07 Oct 2014 12:18:41 -0700 (PDT) Received: from [192.168.178.23] (224.200.69.111.dynamic.snap.net.nz. [111.69.200.224]) by mx.google.com with ESMTPSA id wi10sm16567477pbc.95.2014.10.07.12.18.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 12:18:41 -0700 (PDT) Message-ID: <54343C90.5010702@gmail.com> Date: Wed, 08 Oct 2014 08:18:40 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Townsley References: <542BFFAE.1080105@cisco.com> <542C59B3.10700@gmail.com> <542DA4F7.4030406@gmail.com> <6D258687-4D90-4AF3-AADF-BFA3EBBD8C33@townsley.net> In-Reply-To: <6D258687-4D90-4AF3-AADF-BFA3EBBD8C33@townsley.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/lEFoL7_yRPJwXx92ItXO4QJHbRU Cc: Benoit Claise , "homenet@ietf.org" , Markus Stenberg , "anima@ietf.org" Subject: Re: [homenet] [Anima] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 19:19:07 -0000 On 08/10/2014 03:23, Mark Townsley wrote: >> On Oct 2, 2014, at 9:18 PM, Brian E Carpenter wrote: >> >> but I would expect HNCP to be much sooner than Anima. >=20 > Then anima is going to have to deal with HNCP one day in any case. The = handoff between the distributed manner in which HNCP carves up and alloca= tes IP prefixes will need to mesh with whatever anima comes up with. Indeed. It's a given that the anima solutions have to be able to coexist with what came before. > The good news is that homenet is far along enough that it has thought a= bout this type of thing, with an algorithm, code, and drafts that include= marking individual prefixes by manual "or other means" configuration whi= le still supporting automatic determination of subnets that were not othe= rwise addressed. This is the kind of thing that I want to be sure anima k= eeps in mind, lest our worlds collide. The negotiation model we have in mind for anima would allow one device to refuse a request from another - I think that is sufficient to allow a resource such as a prefix to be marked as assigned by another method and therefore not available for negotiation. Brian > - Mark >=20 >=20 >> >>>> 2) I am also a little nervous about the IoT reference in the >>>> charter. We haven't yet seen a use case description that would >>>> apply to IoT (which has IMHO a much broader scope than home >>>> networks, e.g. building services.) >>>> >>>> I think the initial focus is indeed on enterprise and carrier >>>> networks where the OPEX pain is greatest, but we should not >>>> artificially limit the applicability either. >>> I would just say that you aim at enterprise networks and leave it at = that, then. Considering home networks, and even more so constrained devic= es in the IoT land have different management model and resources than you= r typical enterprise devices. >> Yes, but we are (to be frank) trying to disrupt the current enterprise= >> model and I don't want to constrain the thinking by constraining >> the scope. >> >>>> There are the existing NMRG documents and there will be an >>>> overview document, but we are following quite specific direction >>>> from the ADs about this. >>> Well, at least providing links to them in the charter would be probab= ly good idea then. As it is, it looks like =E2=80=98we have solution, her= e is the WG=E2=80=99 to me. >> The NMRG drafts are cited in the charter. We are trying to avoid >> claiming that existing solution proposals *are* the draft solutions, >> because that's the WG's choice to make. >>>>> It is not also clear to me how well the suitability of the >>>>> solution has been evaluated. For implementation of some >>>>> autonomic, distributed algorithms, point-to-point negotiation >>>>> protocol such as the suggested solution is far from optimal. >>>>> In case of homenet, we moved from hierarchical DHCPv6 PD >>>>> (point-to-point hierarchy) to a distributed algorithm >>>>> (draft-ietf-homenet-prefix-assignment*) which was result of >>>>> over two years of draft updates, academic proving of >>>>> correctness etc. >>>> There is a subtle point here. The idea is to produce generic >>>> components that do *not* imply specific autonomic algorithms. If >>>> we do it correctly, those components will support either a top >>>> down or a distributed mechanism or even a blend of the two >>>> approaches. So actually the solution choices come later: we >>>> don=E2=80=99t have to decide in advance between top-down and peer-to= -peer. >>> A protocol (draft-jiang-config-negotiation-protocol) that is essentia= lly point-to-point state push/pull mechanism does not seem like natural f= it for that (+- some discovery). >> Well, I disagree, but that again is a job for the WG. >> >>> The scalable solutions with such protocol require hierarchies of dele= gation. For example, given prefix delegation problem, the reasonable (=3D= low number of total message exchanges) solutions wind up subdividing the = prefix hierarchically, or alternatively with some =E2=80=98god node=E2=80= =99(s) that perform the allocations. It becomes harder if you have multip= le sources of same resource (=3Dprefix) or want to be robust in case of f= ailure. >> If a resource needs a hierarchy you would contstruct that on top of >> the negotiation protocol, not as an intrinsic feature of the protocol.= >> >>>>> although it is covered >>>>> only by one mention in the whole charter (and the rest does >>>>> not seem very IoT oriented). >>>> So should we say in the charter that the scope is everything but >>>> the initial focus is enterprise and carrier? >>> Or that you are developing enterprise solution and it can work for an= ything with luck. >> No, not with luck, if we do it right. That would be like saying that >> DHCP(v4) was designed for campus networks but would work for >> home networks with luck. >> >>>>> Looking at the solutions, from homenet developer / draft >>>>> writer point of view, I would welcome a general trust >>>>> bootstrapping framework. I am not convinced by the current >>>>> solution draft for that (it assumes too many components for a >>>>> home network case at least). A lot of the other things seem >>>>> somewhat enterprise-y (control plane with IPsec, own routing >>>>> protocol and ULAs? Not in IoT device at least, nor probably >>>>> in constrained homenet router), or just unsuitable, such as >>>>> the negotiation protocol that does not seem like a good fit >>>>> for distributed decision making which is usually the key >>>>> thing in autonomic networking. >>>> That means we have explained the negotiation idea badly. It is >>>> not top-down negotiation like >>>> draft-boucadair-network-automation-requirements. It is peer to >>>> peer with top-down as a special case. >>> Sure, it is simple =E2=80=98who is there=E2=80=99, =E2=80=99{can I ha= z X, (yes|no|no but you can have Y)}+=E2=80=99 protocol as far as I can = read the draft anyway (draft-jiang-config-negotiation-protocol-02) >> Exactly. And that is pretty close to Turing-complete so it >> could be used very generally. >> >>> It is not obvious to me how it would be even used to tell other all o= ther nodes about e.g. change in some network parameter (say, NTP server).= Is it a =E2=80=98request=E2=80=99? Who is it sent to? How to prevent dup= lication of sending it to nodes that already did receive it? >> Yes. I noticed that when considering Rene's comment about state >> synchronization and it needs more work. Nobody is saying that >> it is fully baked yet. >> >>> From my point of view, a general network infra protocol needs >>> >>> - discovery >>> - state push/pull _network wide_ >>> >>> HNCP does this; I am not sure how CDNP can be used for this, but I we= lcome examples. >> It's intentionally peer-to-peer so network-wide requires propagation; >> but I don't understand how HNCP could do some of the other things we >> want. There will be a revised requirements in a forthcoming draft, so >> I'd rather have that discussion later. >> >> Let me be clear: if HNCP can be generalised to do what we need (which >> would probably mean changing its name slightly) I'd be delighted. >> There is absolutely nothing to be gained by having two protocols if >> one will work. >> >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Tue Oct 7 12:23:34 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296861A87D0 for ; Tue, 7 Oct 2014 12:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e450_VGo2Hhx for ; Tue, 7 Oct 2014 12:23:25 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF211A87D6 for ; Tue, 7 Oct 2014 12:21:19 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id r10so5464543igi.8 for ; Tue, 07 Oct 2014 12:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=JKqciJMROeD5zdcCTnTyFnUXtdF+II1Sdxq16BR/iVA=; b=lUofAykvPjsRCxpieijKcnri7kpPhtnsVlQdnTlZscPgnwhx5iVp6ZCGKqS9UZXRtk JQ36eSBtsrk4FWNKZaGprVNwuwfGX0UEPirZbS9jMEjw5KkP5PETa40fXOR/9jkgT6DO Pt41GCfOv7wtXKG1himC7FDrXDblGldC6CQ8vvcGA4MsuNN3FWyurrRy6c8+HItXUerI lTvf0fAjI72FKSTKTha5Eia1ilxCl40gX8RBWpHyhRDkH53mxQ9PNIiSj3ZmS14kSQVc rHjsrExjbvVi2Dyn2gcF3xIDDoPBHo8KQyxm+T0jomCeC5FZ0eJEYPXk/+ZVHBHvIQ+J Z+TA== X-Received: by 10.50.73.200 with SMTP id n8mr35530814igv.16.1412709677505; Tue, 07 Oct 2014 12:21:17 -0700 (PDT) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id an1sm12733006igc.7.2014.10.07.12.21.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Oct 2014 12:21:17 -0700 (PDT) Message-ID: <54343D2A.6050404@gmail.com> Date: Tue, 07 Oct 2014 15:21:14 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Mark Baugher (mbaugher)" , Michael Richardson References: <542BFFAE.1080105@cisco.com> <542C59B3.10700@gmail.com> <5F26857C-1C41-4D1F-AA4A-B7D9E947180F@townsley.net> <542CC380.1030600@gmail.com> <626B3345-F1B9-4EF0-8957-8EBAA81540B1@townsley.net> <25295.1412685849@sandelman.ca> <23190.1412704267@sandelman.ca> <1DACA699-3FE9-406C-A79C-5CDC90DEC0A5@cisco.com> In-Reply-To: <1DACA699-3FE9-406C-A79C-5CDC90DEC0A5@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/BLQt9gKakY51sEGo9v3In1dB0aQ Cc: "homenet@ietf.org" , Mark Townsley Subject: Re: [homenet] Home-network support (was Re: [Anima] Homenet feedback on the ANIMA charter X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 19:23:28 -0000 Dear colleagues: It seems that the definition of the coined term "professionally managed" is somewhat ambiguous. From an architectural point of view, I would like to see a) Design of management functionality with lots of flexibility as to which device(s) assume which role(s), with consideration of the entire device and network lifecycle. b) No assignment as to which devices assume which role(s) cast in stone (so, no hardcoding of assumptions or attempts to ossify business interests into an architectural design!). This allows both (what I believe some people mean with the term) "professionally managed" by the likes of ISPs, but also re-assignment of responsibilities (without, God forbid, "SIM lock-in behavior" of the usual suspects). If one accepts this, the aspect as to whether something is "professionally managed" or not becomes something that is a configuration parameter and one can focus on enabling the flexibility to let a million business model flowers bloom... Please also see the excerpt of minutes Anima (UCAN) BOF Minutes (see http://www.ietf.org/proceedings/90/minutes/minutes-90-ucan): o Rene Struik - Little verbiage around the use side of the usage scenarios. Need to understand the users dependency on the vendor over the long-run. From user perspective, one should aim for no forced lock-in by vendor by technical means, i.e., one needs "vendor dependency neutrality", similar to "network neutrality". Best regards, Rene On 10/7/2014 2:12 PM, Mark Baugher (mbaugher) wrote: > On Oct 7, 2014, at 10:51 AM, Michael Richardson wrote: > >> Mark Townsley wrote: >>>> I suggest that ANIMA focus on "professionally-managed" networks first, >>>> with "Homenet" being a secondary consideration, akin to IPv4 is in the >>>> homenet WG. >>> I like that suggestion, with a caveat. The caveat being that I think >>> there is room for a "professionally managed" home network as well - >>> something homenet to date has touched on, but for the most part >>> avoided. >> Sure; we have avoided it because I think most see the only professional >> nearby being the ISP, and few of *us* professionals want them mucking around >> in our home. That's the personal experience of IETF contributors as >> individuals. > The major retail brands also offer remote network support using tools that > come with their routers. It should always be possible to plug a router in > front of an ISP device for "over-the-top" support from whatever provider > one trusts to do that. And I think most people would benefit from having > professional support on their home network though few seem to be willing > to pay for it. The more competent ISPs often do it for free. But there's > the problem of having routers owned by other entities on the network: > An ISP device and a retail device is probably more common than two ISPs. > >> However, we also see in our architecture that we expect two be able to get >> service from two ISPs, so in the end, our pessimism about the ability of the >> ISP professional to manage our home network is legitimate. There can't be >> only one --- cooperation is required. > If the cooperation entails telling your competitors who your customers happen > to be, then it's probably a requirement that won't be satisfied, at least > not for a long time. > >> There are other professional organizations that would like to help manage our >> homes: Apple, Google and Microsoft come to mind. Yet, even there, we expect >> cooperation. That's why the secure bootstrap problem is more difficult in >> the home than it is, in for instance, an oil refinery. >> > The only model that seems realistic to me is to have the home network owner > take ownership of the home network, possibly with the help of a third > party that is contracted to provide professional support. > > Mark > > >>> It should be up to the user to decide to have their home network >>> professionally managed of course, but as long as that choice is made, a >>> "professionally managed network" WG might be able to provide tooling >>> equally as well for the home as for an enterprise (or SOHO, etc, to >>> Leddy's point). Here is where including what homenet has already done >>> is important for a new WG, if nothing else but to coexist properly >>> between the two solutions. For example, Homenet has had to spend quite >>> a bit of cycles dealing with what we think the home network will look >>> like by the time HNCP arrives (Hierarchical DHCPv6-PD, HIPNET, >>> etc.). Anima should be able to make the same consideration for how to >>> operate with HNCP in the network as well - e.g., new "professionally >>> managed" solution when available, "non-managed" via HNCP otherwise. >>> In terms of scope of work and where it is done, I'm not sure this means >>> the "professionally managed home" work should done in anima or homenet >>> WGs, but I do know we shouldn't do it with blinders on. >> What do you mean "with blinders on" here? >> Usually that means that the horse has blinders to avoid distraction by things >> that aren't in front of them. So I think that you mean that professional >> managed ideas should be visible to Homenet and ANIMA, but do you really mean: >> ANIMA should pay attention to non-managed networks >> HOMENET should pay attention to managed networks >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Tue Oct 7 16:14:16 2014 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045281A86F9 for ; Tue, 7 Oct 2014 16:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmgAK2R-KSpX for ; Tue, 7 Oct 2014 16:14:12 -0700 (PDT) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E09C1A6FFC for ; Tue, 7 Oct 2014 16:14:11 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id ij19so5726193vcb.32 for ; Tue, 07 Oct 2014 16:14:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=D0ptZHOT0BjG/5R6TXuwjoXTeSJWvcfmSP53wulvc4I=; b=lBWaaE86wzDyMAV+R+XJf5TFKEkxU20iWqGkuuU9WIsnX4AkN/gjYaGF3Bzm58VL/L qWCElHIMlWpjgQR1r9Jtdt5BxMh0lp2tir90JRFupUTXbqEouAzggOwD0G8V7TVfYhgX SNMROxsLXBqXmV/uNKc2/fP7jPMP7wIMojmJRrfFUwDnsYbq0STHvYpXu78b/E3aUp0p MhPRk1B0+7nG3nE6Y20bIY1IEIZU0r+titEKMBID08RxPPy36XSky5q+TvpfmB6N3Fw/ I2CqhOeyPL+aU+K2srUmstRH5gPEcHAibx8DHEWaOhpt/2rtUmopvhn310Det/yl4MH7 n6jw== X-Gm-Message-State: ALoCoQmDkWLz44S+FZU8tR2C7JiwFVbGkMbv9PWX6R7E7onemRex/BXekCWB/QIm9OUjceKogAbs MIME-Version: 1.0 X-Received: by 10.52.188.131 with SMTP id ga3mr5293670vdc.45.1412723651078; Tue, 07 Oct 2014 16:14:11 -0700 (PDT) Received: by 10.31.10.77 with HTTP; Tue, 7 Oct 2014 16:14:11 -0700 (PDT) Date: Tue, 7 Oct 2014 16:14:11 -0700 Message-ID: From: James Woodyatt To: HOMENET Working Group Content-Type: multipart/alternative; boundary=bcaec5489e69637fa30504dd5b2e Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/4v9sq5KhmEpiJv5tPamB0wTm9UQ Subject: [homenet] I-D.ietf-homenet-prefix-assignment X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 23:14:14 -0000 --bcaec5489e69637fa30504dd5b2e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Everyone=E2=80=94 I have skimmed I-D.ietf-homenet-prefix-assignment, and I have some questions and a concern about the topic of ULA Prefix Generation and specifically the requirements language used in section 9.1. 9.1 . ULA Prefix Generation A router MAY generate a ULA prefix when the two following conditions are met. o It is the Network Leader (Section 4.4 ). o No other ULA delegated prefix is advertised by any other router. A router MUST stop advertising a spontaneously generated ULA prefix whenever another router is advertising a ULA delegated prefix. The most recently used ULA prefix SHOULD be stored in stable storage by all routers and reused whenever choosing a new ULA delegated prefix. If no ULA prefix can be found in stable storage, it MUST be randomly generated, or generated from hardware specific values. The requirements keywords in this section make for a pretty serious interop clash with Thread networks , which generate their own ULA prefix based on a method defined by its current conventions. If a Thread border router cannot publish its ULA prefix into the HOMENET routing domain, unless it is the Network Leader (which it almost certainly never will be), then this language would seem to force Thread border routers not to use HOMENET standard protocols, and instead to implement some kind of non-standard tunneling overlay between devices inside the Thread mesh and hosts on the rest of the home network. Is that what the working group wants to happen? What is the intended purpose of this requirement? Is there a way the intended purpose can be served without breaking interop with Thread networks? (My apologies if I missed the relevant discussion. I was trying to pay attention, but regular life has been assailing me with other concerns over the last year or so. I'm on top of things now, though.) --=20 james woodyatt Nest Labs, Communications Engineering --bcaec5489e69637fa30504dd5b2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Everyone=E2=80=94

I have skimmed I-D.ietf-homen= et-prefix-assignment, and I have some questions and a concern about the top= ic of ULA Prefix Generation and specifically the requirements language used= in section 9.1.

9.1.  ULA =
Prefix Generation
   A router MAY generate a ULA prefix=
 when the two following conditions
   are met.
   o  It is the Network Leader (Section 4.4).
   o  No other ULA delegated prefix =
is advertised by any other router.
   A router MUST stop advertisin=
g a spontaneously generated ULA prefix
   whenever another router is advertising a ULA delegated prefix.
   The most recently used ULA prefix SHOULD be stored in stable storage=

   by all routers and reused when=
ever choosing a new ULA delegated
=
   prefix.  If no ULA prefix can be found in stable storage, it MUST be
   randomly generated, or generated f=
rom hardware specific values.

The=
 requirements keywords in this section make for a pretty serious interop cl=
ash with Thread networks <http://threadgroup.org/>, which generate their own ULA prefi=
x based on a method defined by its current conventions.

If a Thread border router cannot publish its ULA prefix into the HOME=
NET routing domain, unless it is the Network Leader (which it almost certai=
nly never will be), then this language would seem to force Thread border ro=
uters not to use HOMENET standard protocols, and instead to implement some =
kind of non-standard tunneling overlay between devices inside the Thread me=
sh and hosts on the rest of the home network.

Is t=
hat what the working group wants to happen? What is the intended purpose of=
 this requirement? Is there a way the intended purpose can be served withou=
t breaking interop with Thread networks?

(My apolo=
gies if I missed the relevant discussion. I was trying to pay attention, bu=
t regular life has been assailing me with other concerns over the last year=
 or so. I'm on top of things now, though.)

--=
 
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications =
Engineering




--bcaec5489e69637fa30504dd5b2e--


From nobody Tue Oct  7 16:15:20 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C337C1A8A59 for ; Tue,  7 Oct 2014 16:15:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCJJA9fTzEM7 for ; Tue,  7 Oct 2014 16:15:16 -0700 (PDT)
Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869C61A8A56 for ; Tue,  7 Oct 2014 16:15:16 -0700 (PDT)
Received: by mail-vc0-f178.google.com with SMTP id hq12so5596895vcb.23 for ; Tue, 07 Oct 2014 16:15:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=TJcwCDdU87e0Gd/gTaE+Gu6niIZRXCUxyaQ/3/0VVh8=; b=Xj7dazGi9tzoRFMX+0qI0xzq5J1gaWP/qutlsa5WzC4z0+BDnqFWpfITQc6BK4qhKv RIKPAh3viFCxH4kgF46sRmJKksaakcE+koIdahbrGYjwuG/JaB6fcMfz87R332TT8VLE qnOVV/tl2GrbkIb69c9aOVLM1juYTc/1SZPeOPHPuGUG+JMMO6wH85ng+Mehmagj6um+ 30xeyTniQxOQl+7o2CU2NtMRt+J+eY6ltEOaa7ar45SFKhU3r2+gFR+crEsuJvZgU5qw mgec+yaxAKTHvW5gTuQFEv5RD1aemSYjJpJWjC6FsrX6xzOQeeR42WF0+ZOTAgYTYl1V fzsA==
X-Gm-Message-State: ALoCoQkegZxWNIkcWfoTHAX+A1bWlo3W6lPMpjVrrG/WuvRUx9CSAw2z4qnvPb4rpS1zo+IOSjxf
MIME-Version: 1.0
X-Received: by 10.52.145.205 with SMTP id sw13mr5277000vdb.24.1412723715657; Tue, 07 Oct 2014 16:15:15 -0700 (PDT)
Received: by 10.31.10.77 with HTTP; Tue, 7 Oct 2014 16:15:15 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 7 Oct 2014 16:15:15 -0700
Message-ID: 
From: James Woodyatt 
To: HOMENET Working Group 
Content-Type: multipart/alternative; boundary=bcaec52c5e0b3ce57c0504dd5fc1
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/wz2rVzkgindJC8EXvhbgwqSGeAI
Subject: Re: [homenet] I-D.ietf-homenet-prefix-assignment
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Oct 2014 23:15:19 -0000

--bcaec52c5e0b3ce57c0504dd5fc1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Apologies for the duplicate. It was a manual error, not an automatic one.

On Tue, Oct 7, 2014 at 4:14 PM, James Woodyatt  wrote:

> Everyone=E2=80=94
>
> I have skimmed I-D.ietf-homenet-prefix-assignment, and I have some
> questions and a concern about the topic of ULA Prefix Generation and
> specifically the requirements language used in section 9.1.
>
>
>  
>
> 9.1 .  ULA Prefix Generation
>
>    A router MAY generate a ULA prefix when the two following conditions
>
>    are met.
>
>    o  It is the Network Leader (Section 4.4 ).
>
>    o  No other ULA delegated prefix is advertised by any other router.
>
>    A router MUST stop advertising a spontaneously generated ULA prefix
>
>    whenever another router is advertising a ULA delegated prefix.
>
>    The most recently used ULA prefix SHOULD be stored in stable storage
>
>    by all routers and reused whenever choosing a new ULA delegated
>
>    prefix.  If no ULA prefix can be found in stable storage, it MUST be
>
>    randomly generated, or generated from hardware specific values.
>
>
> The requirements keywords in this section make for a pretty serious
> interop clash with Thread networks , which
> generate their own ULA prefix based on a method defined by its current
> conventions.
>
> If a Thread border router cannot publish its ULA prefix into the HOMENET
> routing domain, unless it is the Network Leader (which it almost certainl=
y
> never will be), then this language would seem to force Thread border
> routers not to use HOMENET standard protocols, and instead to implement
> some kind of non-standard tunneling overlay between devices inside the
> Thread mesh and hosts on the rest of the home network.
>
> Is that what the working group wants to happen? What is the intended
> purpose of this requirement? Is there a way the intended purpose can be
> served without breaking interop with Thread networks?
>
> (My apologies if I missed the relevant discussion. I was trying to pay
> attention, but regular life has been assailing me with other concerns ove=
r
> the last year or so. I'm on top of things now, though.)
>
> --
> james woodyatt 
> Nest Labs, Communications Engineering
>



--=20
james woodyatt 
Nest Labs, Communications Engineering

--bcaec52c5e0b3ce57c0504dd5fc1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Apologies for the duplicate. It was a manual error, not an=
 automatic one.

On Tue, Oct 7, 2014 at 4:14 PM, James Woodyatt <jhw@nestlabs.com>=
; wrote:
Everyone=E2=80=94

I have skimm=
ed I-D.ietf-homenet-prefix-assignment, and I have some questions and a conc=
ern about the topic of ULA Prefix Generation and specifically the requireme=
nts language used in section 9.1.

<=
blockquote style=3D"font-family:arial,sans-serif;font-size:12.7272720336914=
px;margin:0px 0px 0px 40px;border:none;padding:0px">
9.1.  ULA Prefix Generation
   A router MAY generate a ULA prefix when the two following=
 conditions
   are met.
  =
 o  It is the Network Leader (Section 4.=
4).
   o  No other ULA delegated prefix is advertised by any ot=
her router.
   A router MUST stop advertising a spontaneously gener=
ated ULA prefix
   whenever anothe=
r router is advertising a ULA delegated prefix.
   The most recent=
ly used ULA prefix SHOULD be stored in stable storage
   by all routers and reused whenever choosing a new UL=
A delegated
   prefix.  If no ULA =
prefix can be found in stable storage, it MUST be
   randomly generated, or generated from hardware specific =
values.

The requirements keywords=
 in this section make for a pretty serious interop clash with Thread networ=
ks <http://threadg=
roup.org/>, which generate their own ULA prefix based on a method de=
fined by its current conventions.

If a Thread bord=
er router cannot publish its ULA prefix into the HOMENET routing domain, un=
less it is the Network Leader (which it almost certainly never will be), th=
en this language would seem to force Thread border routers not to use HOMEN=
ET standard protocols, and instead to implement some kind of non-standard t=
unneling overlay between devices inside the Thread mesh and hosts on the re=
st of the home network.

Is that what the working g=
roup wants to happen? What is the intended purpose of this requirement? Is =
there a way the intended purpose can be served without breaking interop wit=
h Thread networks?

(My apologies if I missed the r=
elevant discussion. I was trying to pay attention, but regular life has bee=
n assailing me with other concerns over the last year or so. I'm on top=
 of things now, though.)

-- 
=
james woodyatt <jh=
w@nestlabs.com>
Nest Labs, Communications Engineering







-- 
=

james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engin=
eering



--bcaec52c5e0b3ce57c0504dd5fc1--


From nobody Tue Oct  7 17:04:08 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8319B1A8026 for ; Tue,  7 Oct 2014 17:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.986
X-Spam-Level: 
X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8Rp0393LH_A for ; Tue,  7 Oct 2014 17:04:03 -0700 (PDT)
Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FDAC1A8AA4 for ; Tue,  7 Oct 2014 17:04:02 -0700 (PDT)
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 27f74345.2b3b57431940.1094497.00-2442.3076093.nbfkord-smmo07.seg.att.com (envelope-from );  Wed, 08 Oct 2014 00:04:02 +0000 (UTC)
X-MXL-Hash: 54347f7213dbfccf-10c36cf3bf7f4b2b8c1898058efd8e1161f05fbd
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id f6f74345.0.1094483.00-2368.3076049.nbfkord-smmo07.seg.att.com (envelope-from );  Wed, 08 Oct 2014 00:03:59 +0000 (UTC)
X-MXL-Hash: 54347f6f157dda01-44b08d40fd5f309748adb7bd3815a0abff9cc5cb
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9803wv2018771; Tue, 7 Oct 2014 20:03:58 -0400
Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9803rDx018736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 Oct 2014 20:03:55 -0400
Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi131.aldc.att.com (RSA Interceptor); Wed, 8 Oct 2014 00:03:35 GMT
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.240]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0195.001; Tue, 7 Oct 2014 20:03:35 -0400
From: "STARK, BARBARA H" 
To: Rene Struik , "homenet@ietf.org" 
Thread-Topic: [homenet] Home-network support (was Re: [Anima] Homenet feedback on the ANIMA charter
Thread-Index: AQHP4lpcxwa9BuUk3UmVYhJl1GjWMZwlRhEA///MDAA=
Date: Wed, 8 Oct 2014 00:03:35 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E61130E959A7@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <542BFFAE.1080105@cisco.com>  <542C59B3.10700@gmail.com> <5F26857C-1C41-4D1F-AA4A-B7D9E947180F@townsley.net> <542CC380.1030600@gmail.com>  <626B3345-F1B9-4EF0-8957-8EBAA81540B1@townsley.net> <25295.1412685849@sandelman.ca>  <23190.1412704267@sandelman.ca> <1DACA699-3FE9-406C-A79C-5CDC90DEC0A5@cisco.com> <54343D2A.6050404@gmail.com>
In-Reply-To: <54343D2A.6050404@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.236.88]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=ae/Wa2Ut c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=ofMgfj31e3cA:10 a=JmstMkiqptIA:10 a=BLceEmwcHowA:10 a=kj9]
X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=mn8Q3yoi7]
X-AnalysisOut: [-CzxJhf2ZQA:9 a=CjuIK1q_8ugA:10]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.23]
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/uRWfj45kGzFCWYIcSVfLFxNrSrM
Subject: Re: [homenet] Home-network support (was Re: [Anima] Homenet feedback on the ANIMA charter
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 00:04:06 -0000

> It seems that the definition of the coined term "professionally managed"
> is somewhat ambiguous.

+1

Here is the way I see things going. Note that I'm not proposing this as a d=
irection where IETF needs to drive things. I'm describing my pragmatic view=
 of "what is" based on my experiences and knowledge. [FYI: Personally, I do=
n't use ISP-managed routers in my home network; but I help design such devi=
ces and recognize that there are many consumers who like such devices and t=
he level of support ISPs can provide them through such devices; I also reco=
gnize that ISPs have been able to significantly drive down help desk costs =
through providing such devices to the mass of consumers.]

When talking about "service providers", I suggest considering the following=
 roles:
1. Internet Service Provider (ISP): the provider of *an* Internet connectio=
n into the  network; the ISP has incentive to offer basic support=
 to get Internet connectivity working into the  network
2. Application service provider (ASP): the provider of a specific applicati=
on that is used in the  network; e.g., voice, "TV", on-line gamin=
g; there are two main means of delivery:
   a. ASP-managed device(s): e.g., STBs, DVRs, game consoles, specialized <=
premises> routers, home control gateways, VoIP ATAs (some which are in spec=
ialized  routers), etc.; the ASP may have an entire "closed" netw=
ork segment as part of the  network
   b. ASP-supplied app; e.g., app or software installed by the user onto a =
PC/smartphone/tablet/etc.
3. Professional services provider / provider of contractual network managem=
ent services; these providers will generally insist on the use of specific =
networking devices (routers, switches, bridges, networking technologies) th=
at they are competent in managing; they may or may not try to specify end d=
evice capabilities.

A single "service provider" entity may offer to perform one or more of thes=
e roles to the "owner(s)" of a  network. Not all SPs who play a r=
ole in managing all or part of a  network are ISPs. Not all SPs h=
ave an ISP-provided CE router as their centralized point of management.

With this said, my preference for what *homenet* does, would be to focus on=
 none of these service provider roles, except to make sure that the owner(s=
) can enable security mechanisms for homenet protocols for implementation o=
n non-SP-managed devices to prevent ISPs and ASPs from doing things that th=
e "owner" doesn't approve of. Please note, though, that SP-managed devices =
can be *anywhere* in the homenet: in CE routers, internal routers, and host=
s. Please do not limit paranoia to a fear of the ISP and CE router. ASPs wh=
o have entire managed segments on the interior of the  network wi=
ll do this using equipment they supply and manage, that supports the protoc=
ols they want. If SPs (of any role) find they can use homenet protocols, th=
ey will specify implementation of these protocols in boxes they procure / s=
upply / manage. Expect SPs to be able to manage the trust relationships on =
all devices they manage.=20

I have no opinion on anima at this time. My personal interpretation of the =
reference to "ISP networks" in the proposed anima charter is that a  network is never an "ISP network". ISP networks IMO are the networks th=
at the ISP actually "owns" (e.g., the access network). If the intention of =
"ISP networks" in the proposed anima charter is to include professionally-m=
anaged-by-a-SP networks or ASP-managed segments or devices inside a  network, I would suggest they be explicit about this intention. If that=
 is indeed the intention, then I may have an opinion, after all.
Barbara


From nobody Tue Oct  7 17:32:09 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C9E1A8AB6 for ; Tue,  7 Oct 2014 17:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MT857e5nOfLU for ; Tue,  7 Oct 2014 17:32:06 -0700 (PDT)
Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD1A1A0110 for ; Tue,  7 Oct 2014 17:32:06 -0700 (PDT)
Received: by mail-pd0-f169.google.com with SMTP id w10so5957605pde.0 for ; Tue, 07 Oct 2014 17:32:06 -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=yspu0U1TPDJYuFdwFqLzubCUleqA83NqJD7r7eJIHds=; b=NaUtRRREcWXEy+B4rFDpw2dFvIQOW5bwyJNirjJve+FTt3I1TXtmHqCthl31T5D12t NgfvMEGBcdGIf5yzCOnPkt5IlsH0J3UTyHRy02FVvyrU3nKERgaXWv4bSOY6XyMnsFfp GVbCkiddYi2vmqWIcXrPLMlbYPuX+7PDu3EA12zRlSNouX0XizHriPXwJPkVYVioQ6Hx rsIdX6z9yP9CWg9JaDT6cSsd2yp67Z+s1df4kad4OTOJXRtz3WMRVAGs7n49TZdTOr2j VSl3+w3N4SW8YXP85UayiIEG60QQSWCmXIC3aKrBTFuybt8AaE79WdSnKk1BfcNOo9S9 AJiA==
X-Received: by 10.68.186.33 with SMTP id fh1mr6847440pbc.105.1412728326179; Tue, 07 Oct 2014 17:32:06 -0700 (PDT)
Received: from [192.168.178.23] (224.200.69.111.dynamic.snap.net.nz. [111.69.200.224]) by mx.google.com with ESMTPSA id f2sm14868903pdo.29.2014.10.07.17.32.02 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 17:32:05 -0700 (PDT)
Message-ID: <54348606.7010507@gmail.com>
Date: Wed, 08 Oct 2014 13:32:06 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: James Woodyatt 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/zMmYyvMcjxGPeT4bWCVmGbqDWjU
Cc: HOMENET Working Group 
Subject: Re: [homenet] I-D.ietf-homenet-prefix-assignment
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 00:32:07 -0000

On 08/10/2014 12:14, James Woodyatt wrote:

(quoting draft-ietf-homenet-prefix-assignment-00)

>    prefix.  If no ULA prefix can be found in stable storage, it MUST be
>    randomly generated, or generated from hardware specific values.

That sentence is not OK. It should be:

If no ULA prefix can be found in stable storage, it MUST be generated
as specified in [RFC4193].

> The requirements keywords in this section make for a pretty serious interop
> clash with Thread networks , which generate their
> own ULA prefix based on a method defined by its current conventions.

I sincerely hope that method conforms to RFC4193.

    Brian


From SRS0=W1if=67=darou.fr=pierre.pfister@bounces.m4x.org  Wed Oct  8 00:23:02 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBE61A0074 for ; Wed,  8 Oct 2014 00:23:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kp0lK2XZLcVz for ; Wed,  8 Oct 2014 00:22:57 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B8F1A0070 for ; Wed,  8 Oct 2014 00:22:57 -0700 (PDT)
Received: from [10.61.162.75] (173-38-208-170.cisco.com [173.38.208.170]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 3A66E14008F64; Wed,  8 Oct 2014 09:22:54 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E003AF2F-64D2-4305-BA36-25D9BC0036E6"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Pierre Pfister 
In-Reply-To: 
Date: Wed, 8 Oct 2014 09:22:56 +0200
Message-Id: <1ACBD67B-0B89-4909-8BC0-2F3E315D848A@darou.fr>
References: 
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Wed Oct 8 09:22:54 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/_hB9PVxKw868HFpLLZaUfIaAqdI
Cc: HOMENET Working Group 
Subject: Re: [homenet] I-D.ietf-homenet-prefix-assignment
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 07:23:19 -0000

--Apple-Mail=_E003AF2F-64D2-4305-BA36-25D9BC0036E6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hello James,

Thanks for your comment.

I understand your point. I think I was not clear enough in the draft. =
Nothing prevents multiple ULAs, but let me explain.

Section 9.1 refers to a spontaneous generation mechanism authorized when =
there is no available ULA delegated prefix.=20
It is mostly useful in order to enable IPv6 in-home networking when =
there is no IPv6 uplink, or allow using a ULA when desired

Section 4.3 tells how delegated prefixes may be created
4.3.  Obtaining a Delegated Prefix
   A Delegated Prefix can be obtained or generated through different
   means:
   o  It can be dynamically delegated, for instance using DHCPv6 PD.
   o  It can be created statically, specified in router's configuration.
   o  A ULA prefix may be spontaneously generated as defined in
      Section 9.1.
   o  An IPv4 private prefix may be spontaneously generated as defined
      in Section 9.2.

Prefixes that are obtained through DHCPv6 or manually configured CAN be =
ULAs.

In Thread Networks, do you need a specific ULA (provided by some server) =
to be used ?=20
If =91yes', you fit in case #2 and can generate as many ULAs as you =
want.
=20
Or maybe any ULA would work and you are just concerned by the =AB Being =
the network leader =BB choice ?=20
The reason for this was to avoid every router to generate their own ULA =
prefix when they boot together, and later remove it.=20
But you made a point here. I think I will allow non-leader routers to =
generate a ULA in a randomly delayed fashion.

Cheers,

- Pierre


Le 8 oct. 2014 =E0 01:14, James Woodyatt  a =E9crit :

> Everyone=97
>=20
> I have skimmed I-D.ietf-homenet-prefix-assignment, and I have some =
questions and a concern about the topic of ULA Prefix Generation and =
specifically the requirements language used in section 9.1.
>=20
> 9.1.  ULA Prefix Generation
>    A router MAY generate a ULA prefix when the two following =
conditions
>    are met.
>    o  It is the Network Leader (Section 4.4).
>    o  No other ULA delegated prefix is advertised by any other router.
>    A router MUST stop advertising a spontaneously generated ULA prefix
>    whenever another router is advertising a ULA delegated prefix.
>    The most recently used ULA prefix SHOULD be stored in stable =
storage
>    by all routers and reused whenever choosing a new ULA delegated
>    prefix.  If no ULA prefix can be found in stable storage, it MUST =
be
>    randomly generated, or generated from hardware specific values.
>=20
> The requirements keywords in this section make for a pretty serious =
interop clash with Thread networks , which =
generate their own ULA prefix based on a method defined by its current =
conventions.
>=20
> If a Thread border router cannot publish its ULA prefix into the =
HOMENET routing domain, unless it is the Network Leader (which it almost =
certainly never will be), then this language would seem to force Thread =
border routers not to use HOMENET standard protocols, and instead to =
implement some kind of non-standard tunneling overlay between devices =
inside the Thread mesh and hosts on the rest of the home network.
>=20
> Is that what the working group wants to happen? What is the intended =
purpose of this requirement? Is there a way the intended purpose can be =
served without breaking interop with Thread networks?
>=20
> (My apologies if I missed the relevant discussion. I was trying to pay =
attention, but regular life has been assailing me with other concerns =
over the last year or so. I'm on top of things now, though.)
>=20
> --=20
> james woodyatt 
> Nest Labs, Communications Engineering
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


--Apple-Mail=_E003AF2F-64D2-4305-BA36-25D9BC0036E6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


Hello James,

Thanks =
for your comment.

I understand your point. I =
think I was not clear enough in the draft. Nothing prevents multiple =
ULAs, but let me explain.

Section 9.1 refers to =
a spontaneous generation mechanism authorized when there is no available =
ULA delegated prefix. 
It is mostly useful in order to =
enable IPv6 in-home networking when there is no IPv6 uplink, or allow =
using a ULA when desired

Section 4.3 tells how =
delegated prefixes may be created
4.3.  =
Obtaining a Delegated Prefix

   A Delegated Prefix can be obtained or generated through different
   means:
   o  It can be dynamically delegated, for instance using DHCPv6 PD.
   o  It can be created statically, specified in router's configuration.
   o  A ULA prefix may be spontaneously generated as defined in
      Section 9.1.
   o  An IPv4 private prefix may be spontaneously generated as defined
      in Section 9.2.

Prefixes =
that are obtained through DHCPv6 or manually configured CAN be =
ULAs.

In Thread Networks, do you need a =
specific ULA (provided by some server) to be used ? 
If =
=91yes', you fit in case #2 and can generate as many ULAs as you =
want.
 
Or maybe any ULA would work and you are =
just concerned by the =AB Being the network leader =BB choice =
? 
The reason for this was to avoid every router to =
generate their own ULA prefix when they boot together, and later remove =
it. 
But you made a point here. I think I will allow =
non-leader routers to generate a ULA in a randomly delayed =
fashion.

Cheers,

- =
Pierre


Le 8 oct. 2014 =E0 01:14, James =
Woodyatt <jhw@nestlabs.com> =
a =E9crit :

Everyo=
ne=97

I =
have skimmed I-D.ietf-homenet-prefix-assignment, and I have some =
questions and a concern about the topic of ULA Prefix Generation and =
specifically the requirements language used in section 9.1.

9.1.  ULA Prefix Generation
   A =
router MAY generate a ULA prefix when the two following =
conditions
   are =
met.
   o  It is the Network Leader (Section 4.4).
   o  No =
other ULA delegated prefix is advertised by any other =
router.
   A router MUST stop advertising a spontaneously =
generated ULA prefix
   =
whenever another router is advertising a ULA delegated =
prefix.
   The most recently used ULA prefix SHOULD be =
stored in stable storage
   by =
all routers and reused whenever choosing a new ULA =
delegated
   prefix.  If no =
ULA prefix can be found in stable storage, it MUST =
be
   randomly generated, or =
generated from hardware specific values.
<=
br>
The requirements keywords in this section make for a =
pretty serious interop clash with Thread networks <http://threadgroup.org/>, which generate their =
own ULA prefix based on a method defined by its current =
conventions.

If a Thread border router cannot =
publish its ULA prefix into the HOMENET routing domain, unless it is the =
Network Leader (which it almost certainly never will be), then this =
language would seem to force Thread border routers not to use HOMENET =
standard protocols, and instead to implement some kind of non-standard =
tunneling overlay between devices inside the Thread mesh and hosts on =
the rest of the home network.

Is that what the =
working group wants to happen? What is the intended purpose of this =
requirement? Is there a way the intended purpose can be served without =
breaking interop with Thread networks?

(My =
apologies if I missed the relevant discussion. I was trying to pay =
attention, but regular life has been assailing me with other concerns =
over the last year or so. I'm on top of things now, =
though.)

-- 
james =
woodyatt <jhw@nestlabs.com>
Nest Labs, Communications =
Engineering



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

=

--Apple-Mail=_E003AF2F-64D2-4305-BA36-25D9BC0036E6--


From nobody Wed Oct  8 00:31:03 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741201A00AE for ; Wed,  8 Oct 2014 00:31:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baZqqkBIOXee for ; Wed,  8 Oct 2014 00:30:59 -0700 (PDT)
Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.234]) by ietfa.amsl.com (Postfix) with ESMTP id 294381A0072 for ; Wed,  8 Oct 2014 00:30:59 -0700 (PDT)
Received: from poro.lan (84.248.80.109) by jenni1.inet.fi (8.5.142.08) (authenticated as stenma-47) id 5419499101CC6B9F; Wed, 8 Oct 2014 10:30:55 +0300
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Markus Stenberg 
In-Reply-To: 
Date: Wed, 8 Oct 2014 10:30:53 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/k5YApypIAspDOJo7tRmPp6vdOiQ
Cc: HOMENET Working Group , Markus Stenberg 
Subject: Re: [homenet] I-D.ietf-homenet-prefix-assignment
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 07:31:01 -0000

On 8.10.2014, at 2.14, James Woodyatt  wrote:
> The requirements keywords in this section make for a pretty serious =
interop clash with Thread networks , which =
generate their own ULA prefix based on a method defined by its current =
conventions.

I do not think it precludes use of ULAs otherwise, just prevents their =
spontaneous generation according to that particular 0-1 =
ULAs-in-a-network algorithm.=20

> If a Thread border router cannot publish its ULA prefix into the =
HOMENET routing domain, unless it is the Network Leader (which it almost =
certainly never will be), then this language would seem to force Thread =
border routers not to use HOMENET standard protocols, and instead to =
implement some kind of non-standard tunneling overlay between devices =
inside the Thread mesh and hosts on the rest of the home network.
>=20
> Is that what the working group wants to happen? What is the intended =
purpose of this requirement? Is there a way the intended purpose can be =
served without breaking interop with Thread networks?
>=20
> (My apologies if I missed the relevant discussion. I was trying to pay =
attention, but regular life has been assailing me with other concerns =
over the last year or so. I=92m on top of things now, though.)

Just out of curiosity, have you experimented with actually providing =
ULAs and IPv4 connectivity only to normal hosts? We tried that =
experiment in late 2012 (Atlanta IETF 86) and the results based on =
variety of hosts IETF comers came to play with us at the time were =
somewhat mixed. Some hosts notably wanted to use the ULA instead of v4 =
(and in one case, even ULA over IPv6 GUA). That, combined with the fact =
that you more or less have to provide default route to have that ULA =
usable (thanks to MSR RA option being ignored by half the players out =
there currently), and you may have trouble.

Cheers,

-Markus=


From nobody Wed Oct  8 00:50:27 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51C71A009E for ; Wed,  8 Oct 2014 00:50:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSTp2LAqIBLx for ; Wed,  8 Oct 2014 00:50:22 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A88E1A0089 for ; Wed,  8 Oct 2014 00:50:22 -0700 (PDT)
Received: from [10.61.162.75] (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 6E8011408EEE6; Wed,  8 Oct 2014 09:50:20 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_C50B75DE-06FB-45C5-B5A1-E9473A912614"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Pierre Pfister 
In-Reply-To: <54348606.7010507@gmail.com>
Date: Wed, 8 Oct 2014 09:50:22 +0200
Message-Id: 
References:  <54348606.7010507@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Wed Oct 8 09:50:21 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/IydopzHH-FGIjEjLI3-OcX4sBHU
Cc: HOMENET Working Group , James Woodyatt 
Subject: Re: [homenet] I-D.ietf-homenet-prefix-assignment
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 07:50:26 -0000

--Apple-Mail=_C50B75DE-06FB-45C5-B5A1-E9473A912614
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hello Brian

Please find my answer inline.

Le 8 oct. 2014 =E0 02:32, Brian E Carpenter =
 a =E9crit :

> On 08/10/2014 12:14, James Woodyatt wrote:
>=20
> (quoting draft-ietf-homenet-prefix-assignment-00)
>=20
>>   prefix.  If no ULA prefix can be found in stable storage, it MUST =
be
>>   randomly generated, or generated from hardware specific values.
>=20
> That sentence is not OK. It should be:
>=20
> If no ULA prefix can be found in stable storage, it MUST be generated
> as specified in [RFC4193].

The point was to have a pseudo-random algorithm that always generates =
the same ULA.
Stable storage can be used, but on most crappy home routers, writing on =
the SSD too much will kill it in a few thousands writes.

[RFC4193] states:
3.2.1.  Locally Assigned Global IDs

   Locally assigned Global IDs MUST be generated with a pseudo-random
   algorithm consistent with [RANDOM].

If remembering the ULA prefix and using it again and again (using stable =
storage) is OK, I don=92t see why we would need cryptographic =
pseudo-randomness here.
And actually that=92s even worse. Why would a cryptographic =
pseudo-random function would be used with a *known* seed.=20
The ULA doesn=92t need to be secret. It just needs to be random enough =
to avoid collisions.

My point here is that if we conform to RFC4193, we lose the stability of =
the generated ULA, and IMHO we win nothing.
Correct me if I=92m wrong, but I think using hardware specific values as =
seed is perfectly fine with the collision-avoidance requirement.

Cheers,

Pierre

>=20
>> The requirements keywords in this section make for a pretty serious =
interop
>> clash with Thread networks , which generate =
their
>> own ULA prefix based on a method defined by its current conventions.
>=20
> I sincerely hope that method conforms to RFC4193.
>=20
>    Brian
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


--Apple-Mail=_C50B75DE-06FB-45C5-B5A1-E9473A912614
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


Hello Brian

Please =
find my answer inline.

Le 8 oct. 2014 =E0 02:32, =
Brian E Carpenter <brian.e.carpenter@gmail.com> a =E9crit :

On 08/10/2014 12:14, James Woodyatt =
wrote:

(quoting =
draft-ietf-homenet-prefix-assignment-00)

=
   prefix.  If no ULA prefix can be found in stable =
storage, it MUST be
   randomly generated, or generated =
from hardware specific values.

That sentence is not =
OK. It should be:

If no ULA prefix can be found in stable =
storage, it MUST be generated
as specified in =
[RFC4193].

The point was to have a =
pseudo-random algorithm that always generates the same =
ULA.
Stable storage can be used, but on most crappy home =
routers, writing on the SSD too much will kill it in a few thousands =
writes.

[RFC4193] states:
3.2.1.  Locally Assigned Global =
IDs


   Locally assigned Global IDs MUST be generated with a pseudo-random
   algorithm consistent with [RANDOM].

If =
remembering the ULA prefix and using it again and again (using stable =
storage) is OK, I don=92t see why we would need cryptographic =
pseudo-randomness here.
And actually that=92s even worse. Why =
would a cryptographic pseudo-random function would be used with a =
*known* seed. 
The ULA doesn=92t need to be secret. It =
just needs to be random enough to avoid =
collisions.

My point here is that if we conform =
to RFC4193, we lose the stability of the generated ULA, and IMHO we win =
nothing.
Correct me if I=92m wrong, but I think using hardware =
specific values as seed is perfectly fine with the collision-avoidance =
requirement.

Cheers,

Pie=
rre


The =
requirements keywords in this section make for a pretty serious =
interop
clash with Thread networks <http://threadgroup.org/>, which =
generate their
own ULA prefix based on a method defined by its =
current conventions.

I sincerely hope that method =
conforms to RFC4193.

 =
   Brian

___________________________________________=
____
homenet mailing list
homenet@ietf.org
https://www.ietf.=
org/mailman/listinfo/homenet

=

--Apple-Mail=_C50B75DE-06FB-45C5-B5A1-E9473A912614--


From nobody Wed Oct  8 03:10:23 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836A01A0169 for ; Wed,  8 Oct 2014 03:10:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arqiDb19r8PK for ; Wed,  8 Oct 2014 03:10:10 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6AA81A0167 for ; Wed,  8 Oct 2014 03:10:08 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s98AA6uk026627 for ; Wed, 8 Oct 2014 12:10:06 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5299E202C5C for ; Wed,  8 Oct 2014 12:11:11 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 49E2520121C for ; Wed,  8 Oct 2014 12:11:11 +0200 (CEST)
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 s98A9cim015138 for ; Wed, 8 Oct 2014 12:10:06 +0200
Message-ID: <54350D62.5050706@gmail.com>
Date: Wed, 08 Oct 2014 12:09:38 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: homenet@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/qp2rJEjM-O9d-dcx3RGfoLDoK5o
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 10:10:19 -0000

Hi Pierre,

Thanks for the draft update.  Now I have two questions:

> prefixes of size 64 are RECOMMENDED.

Why is this length recommended?  I think it may be because of Ethernet?

Maybe it would be advantageous to not make any recommendation on the 
prefix length.  Some times this may develop into a barrier beyond which 
it will be hard to go.

The other question is about the assumed capability to decide non between 
prefixes, such as to detect collisions.  Do you think it is possible to 
decide equality between prefixes?  I rather think prefixes have a more 
refined relationship than just equal/not-equal - e.g. they are also 
aggregated.

If Router1 advertises P1/64 and Router2 P2/65 aggregated in P1 do you 
think a 'collision' could be detected?  I doubt we have such an 
algorithm somewhere.

Alex



Le 30/06/2014 17:18, Pierre Pfister a écrit :
> Hello group,
>
> I’d like to inform you about the changes made in the two last homenet-prefix-assignment updates.
>
> http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-02
>
> The changes are mostly about fixing typos, but a few technical changes have been made as well (based on the experience gained from the implementation of the Prefix Assignment Algorithm over HNCP).
>
>
>   — Changes between 00 and 01
>
> - If a Delegated Prefix is included in another Delegated Prefix, it is ignored. This is intended to improve support for non-homenet routers that provide prefix sub-delegation. That way, sub-delegated prefixes are ignored.
>
> - Adding network leader definition (The router with the highest identifier).
>
> - Add a section about DHCPv6 downstream prefix delegation. For downstream RFC7084 routers support.
>
> - Adding Delegated Prefix deprecation procedure in order to differentiate prefix deprecation and node disconnection. When a node disconnect, the DPs advertised by this node may be kept some time (depending on the DP's lifetimes). But if a DP is actively deprecated, nodes must stop using it immediately.
>
>
>   — Changes between 01 and 02
>
> - Designated router election can make use of the information provided by the flooding protocol (i.e. when no router is designated yet, only the highest router id present on the link can become designated).
>
> - New implementation guideline in appendix concerning "prefix waste avoidance". It proposes an algorithm that provides a good trade-of between randomness, pseudo-randomness and prefix selection efficiency.
>
>
>
> Comments are welcome,
>
> Pierre Pfister
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
>



From nobody Wed Oct  8 04:28:41 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A61D1A02D1 for ; Wed,  8 Oct 2014 04:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_D0BRDZEJsz for ; Wed,  8 Oct 2014 04:28:37 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8541A0263 for ; Wed,  8 Oct 2014 04:28:36 -0700 (PDT)
Received: from [192.168.0.15] (roo49-3-88-173-49-87.fbx.proxad.net [88.173.49.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id AC014140000B3; Wed,  8 Oct 2014 13:28:34 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Pierre Pfister 
In-Reply-To: <54350D62.5050706@gmail.com>
Date: Wed, 8 Oct 2014 13:28:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>
References:  <54350D62.5050706@gmail.com>
To: Alexandru Petrescu 
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Wed Oct 8 13:28:35 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/H1hL8CuDimCYl7GLMPkKMc6oqSY
Cc: homenet@ietf.org
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 11:28:40 -0000

Hi Alex,

Reply is inlined,

Le 8 oct. 2014 =E0 12:09, Alexandru Petrescu =
 a =E9crit :

> Hi Pierre,
>=20
> Thanks for the draft update.  Now I have two questions:
>=20
>> prefixes of size 64 are RECOMMENDED.
>=20
> Why is this length recommended?  I think it may be because of =
Ethernet?

I=92m not a big fan of putting 64s everywhere neither. And I strongly =
disagree with mandating 64 bit long prefixes.=20
The prefix algorithm itself is agnostic on this side.

Nevertheless, some parts of this document are home-network specific.=20
Not even talking about crappy implementations, home network links should =
support SLAAC whenever possible.
Which is the reason why using 64bit long prefixes is RECOMMENDED.

But smaller prefixes are better than *no prefix at all*.=20
When there are not enough prefixes available (e.g. the ISP provides a =
single 64 while we have multiple links), smaller prefixes can be used =
(80 for instance).=20
Which means dhcpv6 must be used.
Our implementation supports it, and it works with my laptop.

But again, that should be avoided whenever possible. And ISPs MUST =
provided enough prefixes (IMO).

>=20
> Maybe it would be advantageous to not make any recommendation on the =
prefix length.  Some times this may develop into a barrier beyond which =
it will be hard to go.
>=20
> The other question is about the assumed capability to decide non =
between prefixes, such as to detect collisions.  Do you think it is =
possible to decide equality between prefixes?  I rather think prefixes =
have a more refined relationship than just equal/not-equal - e.g. they =
are also aggregated.
>=20
> If Router1 advertises P1/64 and Router2 P2/65 aggregated in P1 do you =
think a 'collision' could be detected?  I doubt we have such an =
algorithm somewhere.
>=20

Equality is never considered alone. Actually, most of the time, you will =
find considerations such as:
The prefix is not included or does not include any other Assigned
       Prefix with a higher precedence.

This is how collisions are detected.

Cheers,

- Pierre


> Alex
>=20
>=20
>=20
> Le 30/06/2014 17:18, Pierre Pfister a =E9crit :
>> Hello group,
>>=20
>> I=92d like to inform you about the changes made in the two last =
homenet-prefix-assignment updates.
>>=20
>> http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-02
>>=20
>> The changes are mostly about fixing typos, but a few technical =
changes have been made as well (based on the experience gained from the =
implementation of the Prefix Assignment Algorithm over HNCP).
>>=20
>>=20
>>  =97 Changes between 00 and 01
>>=20
>> - If a Delegated Prefix is included in another Delegated Prefix, it =
is ignored. This is intended to improve support for non-homenet routers =
that provide prefix sub-delegation. That way, sub-delegated prefixes are =
ignored.
>>=20
>> - Adding network leader definition (The router with the highest =
identifier).
>>=20
>> - Add a section about DHCPv6 downstream prefix delegation. For =
downstream RFC7084 routers support.
>>=20
>> - Adding Delegated Prefix deprecation procedure in order to =
differentiate prefix deprecation and node disconnection. When a node =
disconnect, the DPs advertised by this node may be kept some time =
(depending on the DP's lifetimes). But if a DP is actively deprecated, =
nodes must stop using it immediately.
>>=20
>>=20
>>  =97 Changes between 01 and 02
>>=20
>> - Designated router election can make use of the information provided =
by the flooding protocol (i.e. when no router is designated yet, only =
the highest router id present on the link can become designated).
>>=20
>> - New implementation guideline in appendix concerning "prefix waste =
avoidance". It proposes an algorithm that provides a good trade-of =
between randomness, pseudo-randomness and prefix selection efficiency.
>>=20
>>=20
>>=20
>> Comments are welcome,
>>=20
>> Pierre Pfister
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>>=20
>>=20
>=20
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From nobody Wed Oct  8 04:58:38 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2FF1A02EB for ; Wed,  8 Oct 2014 04:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3L-EmVpyPVE for ; Wed,  8 Oct 2014 04:58:32 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601301A02FE for ; Wed,  8 Oct 2014 04:58:29 -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 s98BwQPT008233; Wed, 8 Oct 2014 13:58:26 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 776032038A0; Wed,  8 Oct 2014 13:59:31 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6A93D2030AE; Wed,  8 Oct 2014 13:59:31 +0200 (CEST)
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 s98BwHON023779; Wed, 8 Oct 2014 13:58:26 +0200
Message-ID: <543526D9.2020107@gmail.com>
Date: Wed, 08 Oct 2014 13:58:17 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Pierre Pfister 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>
In-Reply-To: <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/JeLja5m_GTTwUau5UecM4Lr1unw
Cc: homenet@ietf.org
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 11:58:34 -0000

Hi Pierre,

Le 08/10/2014 13:28, Pierre Pfister a écrit :
> Hi Alex,
>
> Reply is inlined,
>
> Le 8 oct. 2014 ŕ 12:09, Alexandru Petrescu
>  a écrit :
>
>> Hi Pierre,
>>
>> Thanks for the draft update.  Now I have two questions:
>>
>>> prefixes of size 64 are RECOMMENDED.
>>
>> Why is this length recommended?  I think it may be because of
>> Ethernet?
>
> I’m not a big fan of putting 64s everywhere neither. And I strongly
> disagree with mandating 64 bit long prefixes. The prefix algorithm
> itself is agnostic on this side.
>
> Nevertheless, some parts of this document are home-network specific.
> Not even talking about crappy implementations, home network links
> should support SLAAC whenever possible. Which is the reason why using
> 64bit long prefixes is RECOMMENDED.

Ah, I see.  I doubt though SLAAC is 64.  Maybe Ethernet is.

> But smaller prefixes are better than *no prefix at all*. When there
> are not enough prefixes available (e.g. the ISP provides a single 64
> while we have multiple links), smaller prefixes can be used (80 for
> instance). Which means dhcpv6 must be used. Our implementation
> supports it, and it works with my laptop.

Ok.

> But again, that should be avoided whenever possible. And ISPs MUST
> provided enough prefixes (IMO).

I agree with you.

Last time I checked Free ISP seems to provide 8 /64 prefixes to my homenet:
2001:db8:0:ce10::/64
2001:db8:0:ce11::/64
...
2001:db8:0:ce17::/64
I dont think these could be aggregated into a single shorter prefix, or 
my math is missing.

Second, their (Free's) web interface asks me to put a next hop for each 
of these prefixes.

Do you think HNCP implementation may help fill in these fields 
automatically somehow?


>> Maybe it would be advantageous to not make any recommendation on
>> the prefix length.  Some times this may develop into a barrier
>> beyond which it will be hard to go.
>>
>> The other question is about the assumed capability to decide non
>> between prefixes, such as to detect collisions.  Do you think it is
>> possible to decide equality between prefixes?  I rather think
>> prefixes have a more refined relationship than just equal/not-equal
>> - e.g. they are also aggregated.
>>
>> If Router1 advertises P1/64 and Router2 P2/65 aggregated in P1 do
>> you think a 'collision' could be detected?  I doubt we have such an
>> algorithm somewhere.
>>
>
> Equality is never considered alone. Actually, most of the time, you
> will find considerations such as: The prefix is not included or does
> not include any other Assigned Prefix with a higher precedence.

I wonder about the implementability of this statement, but yes it may be 
possible to write one.

> This is how collisions are detected.

Ok.

Alex

>
> Cheers,
>
> - Pierre
>
>
>> Alex
>>
>>
>>
>> Le 30/06/2014 17:18, Pierre Pfister a écrit :
>>> Hello group,
>>>
>>> I’d like to inform you about the changes made in the two last
>>> homenet-prefix-assignment updates.
>>>
>>> http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-02
>>>
>>>
>>>
The changes are mostly about fixing typos, but a few technical changes 
have been made as well (based on the experience gained from the 
implementation of the Prefix Assignment Algorithm over HNCP).
>>>
>>>
>>> — Changes between 00 and 01
>>>
>>> - If a Delegated Prefix is included in another Delegated Prefix,
>>> it is ignored. This is intended to improve support for
>>> non-homenet routers that provide prefix sub-delegation. That way,
>>> sub-delegated prefixes are ignored.
>>>
>>> - Adding network leader definition (The router with the highest
>>> identifier).
>>>
>>> - Add a section about DHCPv6 downstream prefix delegation. For
>>> downstream RFC7084 routers support.
>>>
>>> - Adding Delegated Prefix deprecation procedure in order to
>>> differentiate prefix deprecation and node disconnection. When a
>>> node disconnect, the DPs advertised by this node may be kept some
>>> time (depending on the DP's lifetimes). But if a DP is actively
>>> deprecated, nodes must stop using it immediately.
>>>
>>>
>>> — Changes between 01 and 02
>>>
>>> - Designated router election can make use of the information
>>> provided by the flooding protocol (i.e. when no router is
>>> designated yet, only the highest router id present on the link
>>> can become designated).
>>>
>>> - New implementation guideline in appendix concerning "prefix
>>> waste avoidance". It proposes an algorithm that provides a good
>>> trade-of between randomness, pseudo-randomness and prefix
>>> selection efficiency.
>>>
>>>
>>>
>>> Comments are welcome,
>>>
>>> Pierre Pfister _______________________________________________
>>> homenet mailing list homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>>>
>>>
>>
>>
>> _______________________________________________ homenet mailing
>> list homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>
>
>



From nobody Wed Oct  8 05:13:38 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA40F1A0331 for ; Wed,  8 Oct 2014 05:13:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8DrocxGRg_n for ; Wed,  8 Oct 2014 05:13:34 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074AD1A0307 for ; Wed,  8 Oct 2014 05:13:33 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s98CDUuU032072; Wed, 8 Oct 2014 14:13:30 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EE1CA2038B0; Wed,  8 Oct 2014 14:14:34 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DD3A720897D; Wed,  8 Oct 2014 14:14:34 +0200 (CEST)
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 s98CDMQ4020983; Wed, 8 Oct 2014 14:13:29 +0200
Message-ID: <54352A62.2040605@gmail.com>
Date: Wed, 08 Oct 2014 14:13:22 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Pierre Pfister 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr> <543526D9.2020107@gmail.com>
In-Reply-To: <543526D9.2020107@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/66dnLcfiKqXylcXwK3cn2MOaBcg
Cc: homenet@ietf.org
Subject: Re: [homenet] on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 12:13:36 -0000

Pierre, just a small doubt, but I agree with you in general.

Le 08/10/2014 13:58, Alexandru Petrescu a écrit :
[...]
>> Equality is never considered alone. Actually, most of the time, you
>> will find considerations such as: The prefix is not included or does
>> not include any other Assigned Prefix with a higher precedence.

It is hard to say whether a prefix is included into another or not.  We 
do not have a published algorithm to say what it means for a prefix to 
include another.

In general, we have a common understanding (and not published algorithm) 
about what it means 'longest prefix match'.  But that compares an 
address to a prefix, not a prefix to a prefix.

Sure, one could assume that an address is just a /128 prefix and execute 
longest prefix match with it as if it were an address.

But then again which prefix has the role of the address and which is the 
role of the prefix?  In other words, when hearing two prefixes on a link 
and want to compare them, which of them should be compared against the 
other by using the longest-prefix match?  There are two possibilities 
and two different outputs for a particular tuple of prefixes, depending 
on the order of this longest prefix match.

Of course, I do not mention the easy case which compares two prefixes of 
precisely same length.

Just because the length is different may make think that the prefixes 
are different.  Or otherwise one could be aggregated into another.  But 
there are several types of aggregation: matching up to the shortest 
length, matching up to middle, up to longest length, beyond the longest 
length.

These cases are not documented and people may implement them in many 
different ways with different outputs when trying to tell whether this 
or that prefix are equal or included into one another.

Alex



From nobody Wed Oct  8 05:15:54 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C9D1A0310 for ; Wed,  8 Oct 2014 05:15:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zFI52hRsilu for ; Wed,  8 Oct 2014 05:15:48 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 591391A0307 for ; Wed,  8 Oct 2014 05:15:48 -0700 (PDT)
Received: from [192.168.0.15] (roo49-3-88-173-49-87.fbx.proxad.net [88.173.49.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 335C7140000B3; Wed,  8 Oct 2014 14:15:46 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Pierre Pfister 
In-Reply-To: <543526D9.2020107@gmail.com>
Date: Wed, 8 Oct 2014 14:15:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr> <543526D9.2020107@gmail.com>
To: Alexandru Petrescu 
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Wed Oct 8 14:15:46 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/uI6ValjebN7NCp_pSIPKd6s-4Og
Cc: homenet@ietf.org
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 12:15:51 -0000

Le 8 oct. 2014 =E0 13:58, Alexandru Petrescu =
 a =E9crit :

> Hi Pierre,
>=20
> Le 08/10/2014 13:28, Pierre Pfister a =E9crit :
>> Hi Alex,
>>=20
>> Reply is inlined,
>>=20
>> Le 8 oct. 2014 =E0 12:09, Alexandru Petrescu
>>  a =E9crit :
>>=20
>>> Hi Pierre,
>>>=20
>>> Thanks for the draft update.  Now I have two questions:
>>>=20
>>>> prefixes of size 64 are RECOMMENDED.
>>>=20
>>> Why is this length recommended?  I think it may be because of
>>> Ethernet?
>>=20
>> I=92m not a big fan of putting 64s everywhere neither. And I strongly
>> disagree with mandating 64 bit long prefixes. The prefix algorithm
>> itself is agnostic on this side.
>>=20
>> Nevertheless, some parts of this document are home-network specific.
>> Not even talking about crappy implementations, home network links
>> should support SLAAC whenever possible. Which is the reason why using
>> 64bit long prefixes is RECOMMENDED.
>=20
> Ah, I see.  I doubt though SLAAC is 64.  Maybe Ethernet is.

SLAAC relies on =91interface identifier=92. Ethernet uses the EUI-64.
I have no knowledge of other methods of generating an interface =
identifier.

The why64 draft is interesting (and sad) on that front.

>=20
>> But smaller prefixes are better than *no prefix at all*. When there
>> are not enough prefixes available (e.g. the ISP provides a single 64
>> while we have multiple links), smaller prefixes can be used (80 for
>> instance). Which means dhcpv6 must be used. Our implementation
>> supports it, and it works with my laptop.
>=20
> Ok.
>=20
>> But again, that should be avoided whenever possible. And ISPs MUST
>> provided enough prefixes (IMO).
>=20
> I agree with you.
>=20
> Last time I checked Free ISP seems to provide 8 /64 prefixes to my =
homenet:
> 2001:db8:0:ce10::/64
> 2001:db8:0:ce11::/64
> ...
> 2001:db8:0:ce17::/64
> I dont think these could be aggregated into a single shorter prefix, =
or my math is missing.

That is 2001:db8:0:ce10::/61

>=20
> Second, their (Free's) web interface asks me to put a next hop for =
each of these prefixes.
>=20
I=92m not sure what that means. Is that in the freebox ?
I guess it doesn=92t support DHCPv6-PD (yet). Could you check that ?

If you put a homenet router below your freebox, you will have to provide =
a prefix to the homenet router manually (which is supposed to be done by =
DHCPv6-PD).

> Do you think HNCP implementation may help fill in these fields =
automatically somehow?
>=20
>=20
>>> Maybe it would be advantageous to not make any recommendation on
>>> the prefix length.  Some times this may develop into a barrier
>>> beyond which it will be hard to go.
>>>=20
>>> The other question is about the assumed capability to decide non
>>> between prefixes, such as to detect collisions.  Do you think it is
>>> possible to decide equality between prefixes?  I rather think
>>> prefixes have a more refined relationship than just equal/not-equal
>>> - e.g. they are also aggregated.
>>>=20
>>> If Router1 advertises P1/64 and Router2 P2/65 aggregated in P1 do
>>> you think a 'collision' could be detected?  I doubt we have such an
>>> algorithm somewhere.
>>>=20
>>=20
>> Equality is never considered alone. Actually, most of the time, you
>> will find considerations such as: The prefix is not included or does
>> not include any other Assigned Prefix with a higher precedence.
>=20
> I wonder about the implementability of this statement, but yes it may =
be possible to write one.

I=92ll reply to your other mail concerning that.

>=20
>> This is how collisions are detected.
>=20
> Ok.
>=20
> Alex
>=20
>>=20
>> Cheers,
>>=20
>> - Pierre
>>=20
>>=20
>>> Alex
>>>=20
>>>=20
>>>=20
>>> Le 30/06/2014 17:18, Pierre Pfister a =E9crit :
>>>> Hello group,
>>>>=20
>>>> I=92d like to inform you about the changes made in the two last
>>>> homenet-prefix-assignment updates.
>>>>=20
>>>> =
http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-02
>>>>=20
>>>>=20
>>>>=20
> The changes are mostly about fixing typos, but a few technical changes =
have been made as well (based on the experience gained from the =
implementation of the Prefix Assignment Algorithm over HNCP).
>>>>=20
>>>>=20
>>>> =97 Changes between 00 and 01
>>>>=20
>>>> - If a Delegated Prefix is included in another Delegated Prefix,
>>>> it is ignored. This is intended to improve support for
>>>> non-homenet routers that provide prefix sub-delegation. That way,
>>>> sub-delegated prefixes are ignored.
>>>>=20
>>>> - Adding network leader definition (The router with the highest
>>>> identifier).
>>>>=20
>>>> - Add a section about DHCPv6 downstream prefix delegation. For
>>>> downstream RFC7084 routers support.
>>>>=20
>>>> - Adding Delegated Prefix deprecation procedure in order to
>>>> differentiate prefix deprecation and node disconnection. When a
>>>> node disconnect, the DPs advertised by this node may be kept some
>>>> time (depending on the DP's lifetimes). But if a DP is actively
>>>> deprecated, nodes must stop using it immediately.
>>>>=20
>>>>=20
>>>> =97 Changes between 01 and 02
>>>>=20
>>>> - Designated router election can make use of the information
>>>> provided by the flooding protocol (i.e. when no router is
>>>> designated yet, only the highest router id present on the link
>>>> can become designated).
>>>>=20
>>>> - New implementation guideline in appendix concerning "prefix
>>>> waste avoidance". It proposes an algorithm that provides a good
>>>> trade-of between randomness, pseudo-randomness and prefix
>>>> selection efficiency.
>>>>=20
>>>>=20
>>>>=20
>>>> Comments are welcome,
>>>>=20
>>>> Pierre Pfister _______________________________________________
>>>> homenet mailing list homenet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/homenet
>>>>=20
>>>>=20
>>>=20
>>>=20
>>> _______________________________________________ homenet mailing
>>> list homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>>=20
>>=20
>>=20
>=20
>=20


From nobody Wed Oct  8 05:25:47 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C0F1A0307 for ; Wed,  8 Oct 2014 05:25:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.002
X-Spam-Level: 
X-Spam-Status: No, score=-3.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npC9emOlXOq1 for ; Wed,  8 Oct 2014 05:25:42 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05FFD1A00AE for ; Wed,  8 Oct 2014 05:25:41 -0700 (PDT)
Received: from [192.168.0.15] (roo49-3-88-173-49-87.fbx.proxad.net [88.173.49.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 0AB71140000B3; Wed,  8 Oct 2014 14:25:39 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Pierre Pfister 
In-Reply-To: <54352A62.2040605@gmail.com>
Date: Wed, 8 Oct 2014 14:25:42 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4BCB9E4C-31F2-4769-A994-32F58490BD2B@darou.fr>
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr> <543526D9.2020107@gmail.com> <54352A62.2040605@gmail.com>
To: Alexandru Petrescu 
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Wed Oct 8 14:25:40 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/FC_y8673n69enxtYNEWZ67LEltY
Cc: homenet@ietf.org
Subject: Re: [homenet] on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 12:25:45 -0000

A prefix can only contain another prefix if its prefix length is =
smaller.

Here is some C-code that provides what you are looking for.

Cheers,

- Pierre


/* Tell whether a prefix contains an address */
uint8_t prefix_contains(const struct in6_addr *p, uint8_t plen, const =
struct in6_addr *addr)
{
	int blen =3D plen >> 3;
	if(blen && memcmp(p, addr, blen))
		return 0;

	int rem =3D plen & 0x07;
	if(rem && ((p->s6_addr[blen] ^ addr->s6_addr[blen]) >> (8 - =
rem)))
		return 0;

	return 1;
}

/* Tell whether a prefix contains another prefix */
uint8_t prefix_include(const struct in6_addr *p1, uint8_t plen1, const =
struct in6_addr *p2, uint8_t plen2)
{
	if(plen1 > plen2)
		return 0;
=09
	return prefix_contains(p1, plen1, p2);
}

/* Tell whether two prefixes are colliding */
uint8_t prefix_collision(const struct in6_addr *p1, uint8_t plen1, const =
struct in6_addr *p2, uint8_t plen2)
{
	return prefix_include(p1, plen1, p2, plen2) || =
prefix_include(p2, plen2, p1, plen1);
}


Le 8 oct. 2014 =E0 14:13, Alexandru Petrescu =
 a =E9crit :

> Pierre, just a small doubt, but I agree with you in general.
>=20
> Le 08/10/2014 13:58, Alexandru Petrescu a =E9crit :
> [...]
>>> Equality is never considered alone. Actually, most of the time, you
>>> will find considerations such as: The prefix is not included or does
>>> not include any other Assigned Prefix with a higher precedence.
>=20
> It is hard to say whether a prefix is included into another or not.  =
We do not have a published algorithm to say what it means for a prefix =
to include another.
>=20
> In general, we have a common understanding (and not published =
algorithm) about what it means 'longest prefix match'.  But that =
compares an address to a prefix, not a prefix to a prefix.
>=20
> Sure, one could assume that an address is just a /128 prefix and =
execute longest prefix match with it as if it were an address.
>=20
> But then again which prefix has the role of the address and which is =
the role of the prefix?  In other words, when hearing two prefixes on a =
link and want to compare them, which of them should be compared against =
the other by using the longest-prefix match?  There are two =
possibilities and two different outputs for a particular tuple of =
prefixes, depending on the order of this longest prefix match.
>=20
> Of course, I do not mention the easy case which compares two prefixes =
of precisely same length.
>=20
> Just because the length is different may make think that the prefixes =
are different.  Or otherwise one could be aggregated into another.  But =
there are several types of aggregation: matching up to the shortest =
length, matching up to middle, up to longest length, beyond the longest =
length.
>=20
> These cases are not documented and people may implement them in many =
different ways with different outputs when trying to tell whether this =
or that prefix are equal or included into one another.
>=20
> Alex
>=20
>=20


From nobody Wed Oct  8 05:29:51 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D661A0310 for ; Wed,  8 Oct 2014 05:29:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsCSuSL5nSWx for ; Wed,  8 Oct 2014 05:29:47 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2389D1A0334 for ; Wed,  8 Oct 2014 05:29:46 -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 s98CTirm022700; Wed, 8 Oct 2014 14:29:44 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B2C71208443; Wed,  8 Oct 2014 14:30:49 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A72782038A1; Wed,  8 Oct 2014 14:30:49 +0200 (CEST)
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 s98CTdZb003261; Wed, 8 Oct 2014 14:29:44 +0200
Message-ID: <54352E33.1030505@gmail.com>
Date: Wed, 08 Oct 2014 14:29:39 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Pierre Pfister 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr> <543526D9.2020107@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/PvRD-4XXR_J2PDwtgsETkhvVf1E
Cc: homenet@ietf.org
Subject: Re: [homenet] homenet-prefix-assignment update - behaviour at one ISP
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 12:29:50 -0000

Le 08/10/2014 14:15, Pierre Pfister a écrit :
>
> Le 8 oct. 2014 ŕ 13:58, Alexandru Petrescu
>  a écrit :
>
>> Hi Pierre,
>>
>> Le 08/10/2014 13:28, Pierre Pfister a écrit :
>>> Hi Alex,
>>>
>>> Reply is inlined,
>>>
>>> Le 8 oct. 2014 ŕ 12:09, Alexandru Petrescu
>>>  a écrit :
>>>
>>>> Hi Pierre,
>>>>
>>>> Thanks for the draft update.  Now I have two questions:
>>>>
>>>>> prefixes of size 64 are RECOMMENDED.
>>>>
>>>> Why is this length recommended?  I think it may be because of
>>>> Ethernet?
>>>
>>> I’m not a big fan of putting 64s everywhere neither. And I
>>> strongly disagree with mandating 64 bit long prefixes. The prefix
>>> algorithm itself is agnostic on this side.
>>>
>>> Nevertheless, some parts of this document are home-network
>>> specific. Not even talking about crappy implementations, home
>>> network links should support SLAAC whenever possible. Which is
>>> the reason why using 64bit long prefixes is RECOMMENDED.
>>
>> Ah, I see.  I doubt though SLAAC is 64.  Maybe Ethernet is.
>
> SLAAC relies on ‘interface identifier’. Ethernet uses the EUI-64. I
> have no knowledge of other methods of generating an interface
> identifier.
>
> The why64 draft is interesting (and sad) on that front.
>
>>
>>> But smaller prefixes are better than *no prefix at all*. When
>>> there are not enough prefixes available (e.g. the ISP provides a
>>> single 64 while we have multiple links), smaller prefixes can be
>>> used (80 for instance). Which means dhcpv6 must be used. Our
>>> implementation supports it, and it works with my laptop.
>>
>> Ok.
>>
>>> But again, that should be avoided whenever possible. And ISPs
>>> MUST provided enough prefixes (IMO).
>>
>> I agree with you.
>>
>> Last time I checked Free ISP seems to provide 8 /64 prefixes to my
>> homenet: 2001:db8:0:ce10::/64 2001:db8:0:ce11::/64 ...
>> 2001:db8:0:ce17::/64 I dont think these could be aggregated into a
>> single shorter prefix, or my math is missing.
>
> That is 2001:db8:0:ce10::/61

Right, sorry, my math was missing.  So I suppose Free ISP delegates a
single /61 to me then, not several /64s.  This is a local prefix
division performed in that router.  I do not necessarily agree with it,
as I could have divided it differently, or I could have announced the 
/61 in RA in the first link of the homenet, etc.

>
>>
>> Second, their (Free's) web interface asks me to put a next hop for
>> each of these prefixes.
>>
> I’m not sure what that means. Is that in the freebox ?

YEs, it is in the Freebox Server (not Player), the freebox OS 3.0, sorry 
no advertisement.

> I guess it doesn’t support DHCPv6-PD (yet). Could you check that ?

It does not support DHCPv6-PD Server on the ingress side, or otherwise 
these fields containing 'next-hop' would have not been there.

As DHCPv6-PD Client on the egress side - I dont know, no means to check 
unless I loose it.

> If you put a homenet router below your freebox, you will have to
> provide a prefix to the homenet router manually (which is supposed to
> be done by DHCPv6-PD).

Yes, I agree with  you.  No DHCP-PD at this time.

But if the freebox had a daemon listening to commands to fill in these 
next-hop fields then it would work.

I am saying this because I speculate the way in which this particular 
operator may work, but I have no affiliation with it.

Alex

>> Do you think HNCP implementation may help fill in these fields
>> automatically somehow?
>>
>>
>>>> Maybe it would be advantageous to not make any recommendation
>>>> on the prefix length.  Some times this may develop into a
>>>> barrier beyond which it will be hard to go.
>>>>
>>>> The other question is about the assumed capability to decide
>>>> non between prefixes, such as to detect collisions.  Do you
>>>> think it is possible to decide equality between prefixes?  I
>>>> rather think prefixes have a more refined relationship than
>>>> just equal/not-equal - e.g. they are also aggregated.
>>>>
>>>> If Router1 advertises P1/64 and Router2 P2/65 aggregated in P1
>>>> do you think a 'collision' could be detected?  I doubt we have
>>>> such an algorithm somewhere.
>>>>
>>>
>>> Equality is never considered alone. Actually, most of the time,
>>> you will find considerations such as: The prefix is not included
>>> or does not include any other Assigned Prefix with a higher
>>> precedence.
>>
>> I wonder about the implementability of this statement, but yes it
>> may be possible to write one.
>
> I’ll reply to your other mail concerning that.
>
>>
>>> This is how collisions are detected.
>>
>> Ok.
>>
>> Alex
>>
>>>
>>> Cheers,
>>>
>>> - Pierre
>>>
>>>
>>>> Alex
>>>>
>>>>
>>>>
>>>> Le 30/06/2014 17:18, Pierre Pfister a écrit :
>>>>> Hello group,
>>>>>
>>>>> I’d like to inform you about the changes made in the two
>>>>> last homenet-prefix-assignment updates.
>>>>>
>>>>> http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-02
>>>>>
>>>>>
>>>>>
>>
>>>>>
The changes are mostly about fixing typos, but a few technical changes 
have been made as well (based on the experience gained from the 
implementation of the Prefix Assignment Algorithm over HNCP).
>>>>>
>>>>>
>>>>> — Changes between 00 and 01
>>>>>
>>>>> - If a Delegated Prefix is included in another Delegated
>>>>> Prefix, it is ignored. This is intended to improve support
>>>>> for non-homenet routers that provide prefix sub-delegation.
>>>>> That way, sub-delegated prefixes are ignored.
>>>>>
>>>>> - Adding network leader definition (The router with the
>>>>> highest identifier).
>>>>>
>>>>> - Add a section about DHCPv6 downstream prefix delegation.
>>>>> For downstream RFC7084 routers support.
>>>>>
>>>>> - Adding Delegated Prefix deprecation procedure in order to
>>>>> differentiate prefix deprecation and node disconnection. When
>>>>> a node disconnect, the DPs advertised by this node may be
>>>>> kept some time (depending on the DP's lifetimes). But if a DP
>>>>> is actively deprecated, nodes must stop using it
>>>>> immediately.
>>>>>
>>>>>
>>>>> — Changes between 01 and 02
>>>>>
>>>>> - Designated router election can make use of the information
>>>>> provided by the flooding protocol (i.e. when no router is
>>>>> designated yet, only the highest router id present on the
>>>>> link can become designated).
>>>>>
>>>>> - New implementation guideline in appendix concerning
>>>>> "prefix waste avoidance". It proposes an algorithm that
>>>>> provides a good trade-of between randomness,
>>>>> pseudo-randomness and prefix selection efficiency.
>>>>>
>>>>>
>>>>>
>>>>> Comments are welcome,
>>>>>
>>>>> Pierre Pfister
>>>>> _______________________________________________ homenet
>>>>> mailing list homenet@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/homenet
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________ homenet
>>>> mailing list homenet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/homenet
>>>
>>>
>>>
>>
>>
>
>
>



From nobody Wed Oct  8 05:34:59 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536781A033B for ; Wed,  8 Oct 2014 05:34:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.737
X-Spam-Level: 
X-Spam-Status: No, score=-4.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scxaIqLw8Jmd for ; Wed,  8 Oct 2014 05:34:55 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2C61A0334 for ; Wed,  8 Oct 2014 05:34:55 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7E5D3A1; Wed,  8 Oct 2014 14:34:53 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1412771693; bh=OtfhOy8BUkyk+OPMZTEVZ/dEzACX+eqSj2pw8A7ctkU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ncrnLKJd9rvwCO5fH/sl/A/GciV2QagG0PdKy+bGbhDUisrzmMngnwrgvPzrpDRMz L0cYkjm8aRtkVLR1idpmCu5lN4Xx4mFUy1UlXMAcQhz02rbiA2DljmdWNo0rUGMH81 sqiGmKOpR5wW8j+2RtqVbevuxxXXduCodftq6iRw=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 73A009F; Wed,  8 Oct 2014 14:34:53 +0200 (CEST)
Date: Wed, 8 Oct 2014 14:34:53 +0200 (CEST)
From: Mikael Abrahamsson 
To: Alexandru Petrescu 
In-Reply-To: <54352E33.1030505@gmail.com>
Message-ID: 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr> <543526D9.2020107@gmail.com>  <54352E33.1030505@gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/_GSKcSKE39qprjnmW5F2mwH9_f0
Cc: homenet@ietf.org
Subject: Re: [homenet] homenet-prefix-assignment update - behaviour at one ISP
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 12:34:57 -0000

On Wed, 8 Oct 2014, Alexandru Petrescu wrote:

> as I could have divided it differently, or I could have announced the /61 in 
> RA in the first link of the homenet, etc.

Why on earth would you want to do that?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Wed Oct  8 05:50:04 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B777B1A0360 for ; Wed,  8 Oct 2014 05:50:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.235
X-Spam-Level: 
X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9h9NhpOOHe6y for ; Wed,  8 Oct 2014 05:50:00 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EBA71A0366 for ; Wed,  8 Oct 2014 05:49:58 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqwEABMyNVStJssW/2dsb2JhbABfg2FYyxsKhnlUAoEhAXuEAwEBAQMBAQEBaQIEBwULCxguIQYwBhOIKgMJCA2uc4tzDYcYAReOEoF/MweDLYEeBZY1VIFtgj2DPjyDCIoFQYZTgiCBRTsvgkoBAQE
X-IronPort-AV: E=Sophos;i="5.04,677,1406592000"; d="scan'208";a="199838481"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 08 Oct 2014 12:49:56 +0000
Received: from dhcp-10-61-101-129.cisco.com (dhcp-10-61-101-129.cisco.com [10.61.101.129]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s98Cntpw027378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Oct 2014 12:49:56 GMT
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Ole Troan 
In-Reply-To: <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>
Date: Wed, 8 Oct 2014 14:38:55 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>
To: Pierre Pfister 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/dCUMB7UC_RMtRoR5BkKrUn-ur8Y
Cc: Alexandru Petrescu , homenet@ietf.org
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 12:50:02 -0000

Pierre, Alex,

please make sure this document does comply with =
http://datatracker.ietf.org/doc/draft-ietf-6man-why64/
while I think the algorithm and data formats should support any prefix =
lengths, I don't think the sections dealing with "what if we've run out =
of prefixes" should be included in this document.

cheers,
Ole


> On 08 Oct 2014, at 13:28 , Pierre Pfister  =
wrote:
>=20
> Hi Alex,
>=20
> Reply is inlined,
>=20
> Le 8 oct. 2014 =E0 12:09, Alexandru Petrescu =
 a =E9crit :
>=20
>> Hi Pierre,
>>=20
>> Thanks for the draft update.  Now I have two questions:
>>=20
>>> prefixes of size 64 are RECOMMENDED.
>>=20
>> Why is this length recommended?  I think it may be because of =
Ethernet?
>=20
> I=92m not a big fan of putting 64s everywhere neither. And I strongly =
disagree with mandating 64 bit long prefixes.=20
> The prefix algorithm itself is agnostic on this side.
>=20
> Nevertheless, some parts of this document are home-network specific.=20=

> Not even talking about crappy implementations, home network links =
should support SLAAC whenever possible.
> Which is the reason why using 64bit long prefixes is RECOMMENDED.
>=20
> But smaller prefixes are better than *no prefix at all*.=20
> When there are not enough prefixes available (e.g. the ISP provides a =
single 64 while we have multiple links), smaller prefixes can be used =
(80 for instance).=20
> Which means dhcpv6 must be used.
> Our implementation supports it, and it works with my laptop.
>=20
> But again, that should be avoided whenever possible. And ISPs MUST =
provided enough prefixes (IMO).
>=20
>>=20
>> Maybe it would be advantageous to not make any recommendation on the =
prefix length.  Some times this may develop into a barrier beyond which =
it will be hard to go.
>>=20
>> The other question is about the assumed capability to decide non =
between prefixes, such as to detect collisions.  Do you think it is =
possible to decide equality between prefixes?  I rather think prefixes =
have a more refined relationship than just equal/not-equal - e.g. they =
are also aggregated.
>>=20
>> If Router1 advertises P1/64 and Router2 P2/65 aggregated in P1 do you =
think a 'collision' could be detected?  I doubt we have such an =
algorithm somewhere.
>>=20
>=20
> Equality is never considered alone. Actually, most of the time, you =
will find considerations such as:
> The prefix is not included or does not include any other Assigned
>       Prefix with a higher precedence.
>=20
> This is how collisions are detected.
>=20
> Cheers,
>=20
> - Pierre
>=20
>=20
>> Alex
>>=20
>>=20
>>=20
>> Le 30/06/2014 17:18, Pierre Pfister a =E9crit :
>>> Hello group,
>>>=20
>>> I=92d like to inform you about the changes made in the two last =
homenet-prefix-assignment updates.
>>>=20
>>> =
http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-02
>>>=20
>>> The changes are mostly about fixing typos, but a few technical =
changes have been made as well (based on the experience gained from the =
implementation of the Prefix Assignment Algorithm over HNCP).
>>>=20
>>>=20
>>> =97 Changes between 00 and 01
>>>=20
>>> - If a Delegated Prefix is included in another Delegated Prefix, it =
is ignored. This is intended to improve support for non-homenet routers =
that provide prefix sub-delegation. That way, sub-delegated prefixes are =
ignored.
>>>=20
>>> - Adding network leader definition (The router with the highest =
identifier).
>>>=20
>>> - Add a section about DHCPv6 downstream prefix delegation. For =
downstream RFC7084 routers support.
>>>=20
>>> - Adding Delegated Prefix deprecation procedure in order to =
differentiate prefix deprecation and node disconnection. When a node =
disconnect, the DPs advertised by this node may be kept some time =
(depending on the DP's lifetimes). But if a DP is actively deprecated, =
nodes must stop using it immediately.
>>>=20
>>>=20
>>> =97 Changes between 01 and 02
>>>=20
>>> - Designated router election can make use of the information =
provided by the flooding protocol (i.e. when no router is designated =
yet, only the highest router id present on the link can become =
designated).
>>>=20
>>> - New implementation guideline in appendix concerning "prefix waste =
avoidance". It proposes an algorithm that provides a good trade-of =
between randomness, pseudo-randomness and prefix selection efficiency.
>>>=20
>>>=20
>>>=20
>>> Comments are welcome,
>>>=20
>>> Pierre Pfister
>>> _______________________________________________
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>>>=20
>>>=20
>>=20
>>=20
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From nobody Wed Oct  8 05:51:42 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BA41A036D for ; Wed,  8 Oct 2014 05:51:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXRdYfM4WYh9 for ; Wed,  8 Oct 2014 05:51:37 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E28C1A0367 for ; Wed,  8 Oct 2014 05:51:37 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s98CpZwX014193; Wed, 8 Oct 2014 14:51:35 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DCD0E208C93; Wed,  8 Oct 2014 14:52:39 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C7252208E73; Wed,  8 Oct 2014 14:52:39 +0200 (CEST)
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 s98CpYBa003657; Wed, 8 Oct 2014 14:51:34 +0200
Message-ID: <54353356.1090805@gmail.com>
Date: Wed, 08 Oct 2014 14:51:34 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Mikael Abrahamsson 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr> <543526D9.2020107@gmail.com>  <54352E33.1030505@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/wvtWzKzOuSJlKjxfVslpmnu-QDA
Cc: homenet@ietf.org
Subject: Re: [homenet] homenet-prefix-assignment update - behaviour at one ISP
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 12:51:40 -0000

Le 08/10/2014 14:34, Mikael Abrahamsson a écrit :
> On Wed, 8 Oct 2014, Alexandru Petrescu wrote:
>
>> as I could have divided it differently, or I could have announced the
>> /61 in RA in the first link of the homenet, etc.
>
> Why on earth would you want to do that?

divide differently? or /61 in RA?

Alex



From nobody Wed Oct  8 05:51:44 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C841A036D for ; Wed,  8 Oct 2014 05:51:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.687
X-Spam-Level: 
X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oe9E8S7QnTaX for ; Wed,  8 Oct 2014 05:51:37 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id B9F0B1A0366 for ; Wed,  8 Oct 2014 05:51:37 -0700 (PDT)
Received: from [10.0.10.40] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id BFC1D2380840; Wed,  8 Oct 2014 08:51:36 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <54352E33.1030505@gmail.com>
Date: Wed, 8 Oct 2014 08:51:35 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <02E293C2-F574-4687-BBE7-EEA4524BA16E@fugue.com>
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr> <543526D9.2020107@gmail.com>  <54352E33.1030505@gmail.com>
To: Alexandru Petrescu 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/_q7O0NwXkypIilVxPVEaucrzJ-Q
Cc: homenet@ietf.org, Pierre Pfister 
Subject: Re: [homenet] homenet-prefix-assignment update - behaviour at one ISP
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 12:51:41 -0000

You guys are debating points that are long-since decided.

On Oct 8, 2014, at 8:29 AM, Alexandru Petrescu =
 wrote:

> Le 08/10/2014 14:15, Pierre Pfister a =E9crit :
>>=20
>> Le 8 oct. 2014 =E0 13:58, Alexandru Petrescu
>>  a =E9crit :
>>=20
>>> Hi Pierre,
>>>=20
>>> Le 08/10/2014 13:28, Pierre Pfister a =E9crit :
>>>> Hi Alex,
>>>>=20
>>>> Reply is inlined,
>>>>=20
>>>> Le 8 oct. 2014 =E0 12:09, Alexandru Petrescu
>>>>  a =E9crit :
>>>>=20
>>>>> Hi Pierre,
>>>>>=20
>>>>> Thanks for the draft update.  Now I have two questions:
>>>>>=20
>>>>>> prefixes of size 64 are RECOMMENDED.
>>>>>=20
>>>>> Why is this length recommended?  I think it may be because of
>>>>> Ethernet?
>>>>=20
>>>> I=92m not a big fan of putting 64s everywhere neither. And I
>>>> strongly disagree with mandating 64 bit long prefixes. The prefix
>>>> algorithm itself is agnostic on this side.
>>>>=20
>>>> Nevertheless, some parts of this document are home-network
>>>> specific. Not even talking about crappy implementations, home
>>>> network links should support SLAAC whenever possible. Which is
>>>> the reason why using 64bit long prefixes is RECOMMENDED.
>>>=20
>>> Ah, I see.  I doubt though SLAAC is 64.  Maybe Ethernet is.
>>=20
>> SLAAC relies on =91interface identifier=92. Ethernet uses the EUI-64. =
I
>> have no knowledge of other methods of generating an interface
>> identifier.
>>=20
>> The why64 draft is interesting (and sad) on that front.
>>=20
>>>=20
>>>> But smaller prefixes are better than *no prefix at all*. When
>>>> there are not enough prefixes available (e.g. the ISP provides a
>>>> single 64 while we have multiple links), smaller prefixes can be
>>>> used (80 for instance). Which means dhcpv6 must be used. Our
>>>> implementation supports it, and it works with my laptop.
>>>=20
>>> Ok.
>>>=20
>>>> But again, that should be avoided whenever possible. And ISPs
>>>> MUST provided enough prefixes (IMO).
>>>=20
>>> I agree with you.
>>>=20
>>> Last time I checked Free ISP seems to provide 8 /64 prefixes to my
>>> homenet: 2001:db8:0:ce10::/64 2001:db8:0:ce11::/64 ...
>>> 2001:db8:0:ce17::/64 I dont think these could be aggregated into a
>>> single shorter prefix, or my math is missing.
>>=20
>> That is 2001:db8:0:ce10::/61
>=20
> Right, sorry, my math was missing.  So I suppose Free ISP delegates a
> single /61 to me then, not several /64s.  This is a local prefix
> division performed in that router.  I do not necessarily agree with =
it,
> as I could have divided it differently, or I could have announced the =
/61 in RA in the first link of the homenet, etc.


From nobody Wed Oct  8 05:55:33 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48251A0371 for ; Wed,  8 Oct 2014 05:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_UN99bv8Q6p for ; Wed,  8 Oct 2014 05:55:29 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3E91A0367 for ; Wed,  8 Oct 2014 05:55:29 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id E8000A2; Wed,  8 Oct 2014 14:55:26 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1412772926; bh=tMW8RHoNfEB0qEn5pVIbhqSKfKM2hR+WmvUxtEfOrAY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=XHANa1XKPHUdc0H06ET9JbYRviwom8H3exYmDnwvu2gzGnsdalcVw8NbbsHF6/lXX oLfNjGT4O1xZvrKTCjLiGkoQBO6+1DVJkQxsiIhX5JO71jf1WJ6Iy3LymTpr7L3Z9j Ob6aRBwRneU9gXmfCvSfZfHNtx8wLObi53J2AacE=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E1A0E9F; Wed,  8 Oct 2014 14:55:26 +0200 (CEST)
Date: Wed, 8 Oct 2014 14:55:26 +0200 (CEST)
From: Mikael Abrahamsson 
To: Alexandru Petrescu 
In-Reply-To: <54353356.1090805@gmail.com>
Message-ID: 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr> <543526D9.2020107@gmail.com>  <54352E33.1030505@gmail.com>  <54353356.1090805@gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1574020629-1412772926=:14735"
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/mCQU5KtuMjhqZMPhQYHfNAE90vE
Cc: homenet@ietf.org
Subject: Re: [homenet] homenet-prefix-assignment update - behaviour at one ISP
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 12:55:31 -0000

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---137064504-1574020629-1412772926=:14735
Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8BIT

On Wed, 8 Oct 2014, Alexandru Petrescu wrote:

> Le 08/10/2014 14:34, Mikael Abrahamsson a écrit :
>> On Wed, 8 Oct 2014, Alexandru Petrescu wrote:
>> 
>>> as I could have divided it differently, or I could have announced the
>>> /61 in RA in the first link of the homenet, etc.
>> 
>> Why on earth would you want to do that?
>
> divide differently? or /61 in RA?

Divide at anything else than /64. A=1 in SLAAC doesn't work unless you're 
using /64 subnet size.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se
---137064504-1574020629-1412772926=:14735--


From nobody Wed Oct  8 06:01:27 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA53F1A03F9 for ; Wed,  8 Oct 2014 06:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbnDXF80SZzG for ; Wed,  8 Oct 2014 06:01:23 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EFD01A03A3 for ; Wed,  8 Oct 2014 06:01:21 -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 s98D1KUi002941; Wed, 8 Oct 2014 15:01:20 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0A6E2208E1A; Wed,  8 Oct 2014 15:02:25 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E93BC202FEA; Wed,  8 Oct 2014 15:02:24 +0200 (CEST)
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 s98D1Cis012162; Wed, 8 Oct 2014 15:01:20 +0200
Message-ID: <54353598.2050108@gmail.com>
Date: Wed, 08 Oct 2014 15:01:12 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Mikael Abrahamsson 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr> <543526D9.2020107@gmail.com>  <54352E33.1030505@gmail.com>  <54353356.1090805@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/JX3DMoPGCIlaf7V6gHsxynAbl6Q
Cc: homenet@ietf.org
Subject: Re: [homenet] homenet-prefix-assignment update - behaviour at one ISP
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 13:01:25 -0000

Le 08/10/2014 14:55, Mikael Abrahamsson a écrit :
> On Wed, 8 Oct 2014, Alexandru Petrescu wrote:
>
>> Le 08/10/2014 14:34, Mikael Abrahamsson a écrit :
>>> On Wed, 8 Oct 2014, Alexandru Petrescu wrote:
>>>
>>>> as I could have divided it differently, or I could have announced the
>>>> /61 in RA in the first link of the homenet, etc.
>>>
>>> Why on earth would you want to do that?
>>
>> divide differently? or /61 in RA?
>
> Divide at anything else than /64.

I meant a /61 can be divided in 8 /64s, or in 4 /64s plus 2 /63s, right? 
  There are some configuration advantages for the latter.


> A=1 in SLAAC doesn't work unless
> you're using /64 subnet size.

I didnt know that?  Can you elaborate?  Is it that I can not set radvd 
with A=1 and plen=63?  Or is it that the Host receiving this RA will not 
know what do with this RA?

Alex

>



From nobody Wed Oct  8 06:14:15 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C5E1A04BA for ; Wed,  8 Oct 2014 06:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.737
X-Spam-Level: 
X-Spam-Status: No, score=-4.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vC7kV65uMRAt for ; Wed,  8 Oct 2014 06:14:12 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62ACE1A03E1 for ; Wed,  8 Oct 2014 06:14:12 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id EA6D1A1; Wed,  8 Oct 2014 15:14:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1412774050; bh=eAyQHL4OSBzeusZY/3pL8AHXagH+6A0nlfMcah1GHw8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=oudmoup/dFeXyv6Ces60QDy+GvSqmOjoBBsFXXYFvQs6/mYK3o9tvvSiCzyspd7/1 ytIydOZ9Dm96OLXZWLSRX1jlBMWdg+2y3bAiLaAFqF/Hbe4IbMxsuUwFwxWzbEMLN+ aQKO0G+wUaDU+V7AXYpAF47oczCuw9Jdqx876yOg=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E302D9F; Wed,  8 Oct 2014 15:14:10 +0200 (CEST)
Date: Wed, 8 Oct 2014 15:14:10 +0200 (CEST)
From: Mikael Abrahamsson 
To: Alexandru Petrescu 
In-Reply-To: <54353598.2050108@gmail.com>
Message-ID: 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr> <543526D9.2020107@gmail.com>  <54352E33.1030505@gmail.com>  <54353356.1090805@gmail.com>  <54353598.2050108@gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/nFY_RX5S8WyanlAjRI_wdGp6lJY
Cc: homenet@ietf.org
Subject: Re: [homenet] homenet-prefix-assignment update - behaviour at one ISP
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 13:14:14 -0000

On Wed, 8 Oct 2014, Alexandru Petrescu wrote:

> I didnt know that?  Can you elaborate?  Is it that I can not set radvd 
> with A=1 and plen=63?  Or is it that the Host receiving this RA will not 
> know what do with this RA?

https://datatracker.ietf.org/doc/draft-ietf-6man-why64/?include_text=1

"As a result, RFC 4291 describes a method of forming interface
    identifiers from IEEE EUI-64 hardware addresses [IEEE802] and this
    specifies that such interface identifiers are 64 bits long."

If you set anything different than /64, then A=1 is meaningless and the 
host won't form SLAAC based addresses based on A=1.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Wed Oct  8 06:15:19 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5051A03FF for ; Wed,  8 Oct 2014 06:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqDMGHF1LFEQ for ; Wed,  8 Oct 2014 06:14:51 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0E71A0545 for ; Wed,  8 Oct 2014 06:14:50 -0700 (PDT)
Received: from dhcp-10-61-101-88.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id F298F140000B3; Wed,  8 Oct 2014 15:14:47 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Pierre Pfister 
In-Reply-To: 
Date: Wed, 8 Oct 2014 15:14:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr>
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr> 
To: Ole Troan 
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Wed Oct 8 15:14:48 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/82WFxNDcwSe5jhCW8nyr8unHzzY
Cc: Alexandru Petrescu , homenet@ietf.org
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 13:15:02 -0000
X-List-Received-Date: Wed, 08 Oct 2014 13:15:02 -0000

Hi Ole,

I remember we were supposed to discuss that at last IETF. Well, let=92s =
discuss it here now I guess.

First, that=92s why the use of 64 long prefixes is recommended. And I =
think it could be a fairly good consensus.
draft-ietf-6man-why64 is a very interesting document. An informational =
one. Correct me if I=92m wrong but I=92m not sure it=92s possible to =
=91comply=92 to an informational document.

In general, my opinion about this whole debate is that it=92s not =
because it happens that some implementations are broken that we should =
make specifications brake on purpose as well.
On a user perspective, IPv6 is barely deployed. Don=92t you think IPv6 =
implementations will get fixed if IETF stop telling them they are =
perfectly right to be broken ?

Our current implementation (http://www.homewrt.org) supports this backup =
scenario. And it works. And hosts obtain addresses using DHCPv6. And =
they receive RAs with prefix length which is not 64. And my Mac is fine, =
and linux laptops are fine too. I=92d rather have a /80 than no =
connectivity at all.

Why should we mandate homenet implementations to *brake* in situations =
where they could work fine ? Why should we voluntarily prevent a link =
from being configured if we actually can configure it ?

If MUSTs are the solution, then I would rather see a =91ISP MUST provide =
a /56 to customers=92 than =91Homenet MUST brake when the provided =
prefix is not big enough=92.

Also, this scarcity avoidance mechanism is optional. If the vendor =
considers it as too complex. He can drop it. And brake.

Cheers,

- Pierre

Le 8 oct. 2014 =E0 14:38, Ole Troan  a =E9crit :

> Pierre, Alex,
>=20
> please make sure this document does comply with =
http://datatracker.ietf.org/doc/draft-ietf-6man-why64/
> while I think the algorithm and data formats should support any prefix =
lengths, I don't think the sections dealing with "what if we've run out =
of prefixes" should be included in this document.
>=20
> cheers,
> Ole
>=20
>=20
>> On 08 Oct 2014, at 13:28 , Pierre Pfister  =
wrote:
>>=20
>> Hi Alex,
>>=20
>> Reply is inlined,
>>=20
>> Le 8 oct. 2014 =E0 12:09, Alexandru Petrescu =
 a =E9crit :
>>=20
>>> Hi Pierre,
>>>=20
>>> Thanks for the draft update.  Now I have two questions:
>>>=20
>>>> prefixes of size 64 are RECOMMENDED.
>>>=20
>>> Why is this length recommended?  I think it may be because of =
Ethernet?
>>=20
>> I=92m not a big fan of putting 64s everywhere neither. And I strongly =
disagree with mandating 64 bit long prefixes.=20
>> The prefix algorithm itself is agnostic on this side.
>>=20
>> Nevertheless, some parts of this document are home-network specific.=20=

>> Not even talking about crappy implementations, home network links =
should support SLAAC whenever possible.
>> Which is the reason why using 64bit long prefixes is RECOMMENDED.
>>=20
>> But smaller prefixes are better than *no prefix at all*.=20
>> When there are not enough prefixes available (e.g. the ISP provides a =
single 64 while we have multiple links), smaller prefixes can be used =
(80 for instance).=20
>> Which means dhcpv6 must be used.
>> Our implementation supports it, and it works with my laptop.
>>=20
>> But again, that should be avoided whenever possible. And ISPs MUST =
provided enough prefixes (IMO).
>>=20
>>>=20
>>> Maybe it would be advantageous to not make any recommendation on the =
prefix length.  Some times this may develop into a barrier beyond which =
it will be hard to go.
>>>=20
>>> The other question is about the assumed capability to decide non =
between prefixes, such as to detect collisions.  Do you think it is =
possible to decide equality between prefixes?  I rather think prefixes =
have a more refined relationship than just equal/not-equal - e.g. they =
are also aggregated.
>>>=20
>>> If Router1 advertises P1/64 and Router2 P2/65 aggregated in P1 do =
you think a 'collision' could be detected?  I doubt we have such an =
algorithm somewhere.
>>>=20
>>=20
>> Equality is never considered alone. Actually, most of the time, you =
will find considerations such as:
>> The prefix is not included or does not include any other Assigned
>>      Prefix with a higher precedence.
>>=20
>> This is how collisions are detected.
>>=20
>> Cheers,
>>=20
>> - Pierre
>>=20
>>=20
>>> Alex
>>>=20
>>>=20
>>>=20
>>> Le 30/06/2014 17:18, Pierre Pfister a =E9crit :
>>>> Hello group,
>>>>=20
>>>> I=92d like to inform you about the changes made in the two last =
homenet-prefix-assignment updates.
>>>>=20
>>>> =
http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-02
>>>>=20
>>>> The changes are mostly about fixing typos, but a few technical =
changes have been made as well (based on the experience gained from the =
implementation of the Prefix Assignment Algorithm over HNCP).
>>>>=20
>>>>=20
>>>> =97 Changes between 00 and 01
>>>>=20
>>>> - If a Delegated Prefix is included in another Delegated Prefix, it =
is ignored. This is intended to improve support for non-homenet routers =
that provide prefix sub-delegation. That way, sub-delegated prefixes are =
ignored.
>>>>=20
>>>> - Adding network leader definition (The router with the highest =
identifier).
>>>>=20
>>>> - Add a section about DHCPv6 downstream prefix delegation. For =
downstream RFC7084 routers support.
>>>>=20
>>>> - Adding Delegated Prefix deprecation procedure in order to =
differentiate prefix deprecation and node disconnection. When a node =
disconnect, the DPs advertised by this node may be kept some time =
(depending on the DP's lifetimes). But if a DP is actively deprecated, =
nodes must stop using it immediately.
>>>>=20
>>>>=20
>>>> =97 Changes between 01 and 02
>>>>=20
>>>> - Designated router election can make use of the information =
provided by the flooding protocol (i.e. when no router is designated =
yet, only the highest router id present on the link can become =
designated).
>>>>=20
>>>> - New implementation guideline in appendix concerning "prefix waste =
avoidance". It proposes an algorithm that provides a good trade-of =
between randomness, pseudo-randomness and prefix selection efficiency.
>>>>=20
>>>>=20
>>>>=20
>>>> Comments are welcome,
>>>>=20
>>>> Pierre Pfister
>>>> _______________________________________________
>>>> homenet mailing list
>>>> homenet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/homenet
>>>>=20
>>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>>=20
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>=20


From nobody Wed Oct  8 07:12:01 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583401A1B03 for ; Wed,  8 Oct 2014 07:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qt6xiUSRkrv for ; Wed,  8 Oct 2014 07:11:58 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868381A1B0C for ; Wed,  8 Oct 2014 07:11:58 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s98EB7Ma011030; Wed, 8 Oct 2014 16:11:07 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F4054208FA0; Wed,  8 Oct 2014 16:12:11 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DC8F4208F96; Wed,  8 Oct 2014 16:12:11 +0200 (CEST)
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 s98EAxFe030970; Wed, 8 Oct 2014 16:11:06 +0200
Message-ID: <543545F3.5090805@gmail.com>
Date: Wed, 08 Oct 2014 16:10:59 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Pierre Pfister , Ole Troan 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>  <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr>
In-Reply-To: <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/70x4lTmt1wKVxSecBtycyMlwbQE
Cc: homenet@ietf.org
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 14:12:00 -0000

Le 08/10/2014 15:14, Pierre Pfister a écrit :
[...]
> Why should we mandate homenet implementations to *break* in
> situations where they could work fine ? Why should we voluntarily
> prevent a link from being configured if we actually can configure it
> ?

Sorry, there is no intention to tell networks where 64 works that 64
must not work.

There is however an intention to not say 64, and just say 'n'.

Old:
> Although that choice is completely implementation specific, prefixes
> of size 64 are RECOMMENDED.

New:
 > Although that choice is completely implementation specific,
 > implementations MUST support prefixes of arbitrary length.

Alex


From nobody Wed Oct  8 07:23:01 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C424D1A1B24 for ; Wed,  8 Oct 2014 07:22:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.006
X-Spam-Level: 
X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGnIMS9W7OLE for ; Wed,  8 Oct 2014 07:22:55 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659221A1B2B for ; Wed,  8 Oct 2014 07:22:53 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s98ELfnE010189; Wed, 8 Oct 2014 15:21:41 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s98ELfnE010189
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1412778101; bh=FwhbJlS8Bm1HXHPoZt8XT3Q4pys=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=270iIaRqFSvij26ck4r/23bM4gVxi2WtuFqQCaFMuKjMMcQeEyJnCihqUtwxk2RYK lPimZFCORdLC0Du59GAc3uuBneD1WkR2zoVzDWqxS4g5O0hMfgvhDJ95cpPEOA0GsI Q/OjEsj8sDo8lAkQnQn27SNJsMlWvyUVcSIKgeqU=
Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from  with ESMTP (valid=N/A) id q97FLf3070111708wd ret-id none; Wed, 08 Oct 2014 15:21:41 +0100
Received: from [IPv6:2001:630:d0:ed10:8499:1c3c:701b:8c64] ([IPv6:2001:630:d0:ed10:8499:1c3c:701b:8c64]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s98ELdBG004456 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Oct 2014 15:21:39 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_1A9D3973-01B9-406A-9DEE-34E4B0259839"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Tim Chown 
In-Reply-To: <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr>
Date: Wed, 8 Oct 2014 15:21:38 +0100
Message-ID: 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>  <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr> <5308B561-200A-455C-B2E9-4B4824ED2A1D@ecs.soton.ac.uk>
To: Pierre Pfister 
X-Mailer: Apple Mail (2.1878.6)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=q97FLf307011170800; tid=q97FLf3070111708wd; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: s98ELfnE010189
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Iupejnp6T-9p7rI6SiOgC5qmI74
Cc: Ole Troan , homenet@ietf.org, Alexandru Petrescu 
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 14:22:58 -0000

--Apple-Mail=_1A9D3973-01B9-406A-9DEE-34E4B0259839
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On 8 Oct 2014, at 14:14, Pierre Pfister  wrote:
>=20
> Why should we mandate homenet implementations to *brake* in situations =
where they could work fine ? Why should we voluntarily prevent a link =
from being configured if we actually can configure it ?
>=20
> If MUSTs are the solution, then I would rather see a =91ISP MUST =
provide a /56 to customers=92 than =91Homenet MUST brake when the =
provided prefix is not big enough=92.

But this is what the homenet arch text says in Section 3.4.1:
http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.4.1

i.e. don=92t go longer than /64, and ISPs should provide enough =
prefixes.

The why64 text is very relevant here.

Tim=

--Apple-Mail=_1A9D3973-01B9-406A-9DEE-34E4B0259839
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252



On 8 Oct 2014, at 14:14, Pierre =
Pfister <pierre.pfister@darou.fr> =
wrote:

Why should we mandate homenet =
implementations to *brake* in situations where they could work fine ? =
Why should we voluntarily prevent a link from being configured if we =
actually can configure it ?

If MUSTs are the solution, then I =
would rather see a =91ISP MUST provide a /56 to customers=92 than =
=91Homenet MUST brake when the provided prefix is not big =
enough=92.

But this is what the homenet =
arch text says in Section 3.4.1:

i.e. don=92t go longer than /64, and ISPs =
should provide enough prefixes.

The why64 text =
is very relevant here.

Tim
=

--Apple-Mail=_1A9D3973-01B9-406A-9DEE-34E4B0259839--


From nobody Wed Oct  8 11:28:09 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297FF1ACE02 for ; Wed,  8 Oct 2014 11:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYmrLx4yw8By for ; Wed,  8 Oct 2014 11:28:06 -0700 (PDT)
Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C401ACDF3 for ; Wed,  8 Oct 2014 11:28:05 -0700 (PDT)
Received: by mail-vc0-f170.google.com with SMTP id hy10so7360122vcb.1 for ; Wed, 08 Oct 2014 11:28:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=JE1iK565zGfVbCpp640DLAUIYW2cLK+1cg5C1okI3/c=; b=IuF+ji3qL/m6G0Of6yaHHEe1JUZCWQPeZvxYwsqBkJyTlAAvdoZ1bpW/iOYjo1tvN+ wO6tOzmeRqK5PbLImPEff4TmITdhIrmz5q+zi5I4jMyQhMWXfInYvUE3lyqmGJvRGenx bciesn6rfRQKUVBTouI7wmoKFDsyE62/k5ldTAk3QlGixh4YpS4TuT+i4V5KVOn7rZjO oR1T8EerigVofJcr1jk5p8lxwgFabkeNzsf5Zmy/GBXMZPF7df9VkZbYXfMIUEx7GC99 S4znUMY/QF9ywqdn5vODFAJTpBwk7/7gx7lg9FS+91cLe7MH/witM6pLEEJdC7lbYorG ZYkw==
X-Gm-Message-State: ALoCoQlE6c5zcsq8QQ4i02J5vXKbY1XxsFOHG9+R12KtaiXYLsO7gvRdiJGlj/jhVILthlCQRIL4
MIME-Version: 1.0
X-Received: by 10.220.116.196 with SMTP id n4mr6939924vcq.6.1412792885135; Wed, 08 Oct 2014 11:28:05 -0700 (PDT)
Received: by 10.31.10.77 with HTTP; Wed, 8 Oct 2014 11:28:05 -0700 (PDT)
In-Reply-To: <54348606.7010507@gmail.com>
References:  <54348606.7010507@gmail.com>
Date: Wed, 8 Oct 2014 11:28:05 -0700
Message-ID: 
From: James Woodyatt 
To: HOMENET Working Group 
Content-Type: multipart/alternative; boundary=047d7b34354c0f5df90504ed7a0e
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Ua70W6MV0JfndHemP9ba145uKUc
Subject: Re: [homenet] I-D.ietf-homenet-prefix-assignment
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 18:28:08 -0000

--047d7b34354c0f5df90504ed7a0e
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 7, 2014 at 5:32 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 08/10/2014 12:14, James Woodyatt wrote:
> >
> > The requirements keywords in this section make for a pretty serious
> interop
> > clash with Thread networks , which generate
> their
> > own ULA prefix based on a method defined by its current conventions.
>
> I sincerely hope that method conforms to RFC4193.


Yes, it does.

-- 
james woodyatt 
Nest Labs, Communications Engineering

--047d7b34354c0f5df90504ed7a0e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Oct 7, 2014 at 5:32 PM, Brian E Carpenter <brian.e.carpenter=
@gmail.com> wrote:
On 08/10=
/2014 12:14, James Woodyatt wrote:
>

> The requirements keywords in this section make for a pretty serious in=
terop

> clash with Thread networks <http://threadgroup.org/>, which generate their

> own ULA prefix based on a method defined by its current conventions.


I sincerely hope that method conforms to RFC4193.
<=
br>
Yes, it does.=C2=A0

-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engineer=
ing




--047d7b34354c0f5df90504ed7a0e--


From nobody Wed Oct  8 12:09:00 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157D61A1A1B for ; Wed,  8 Oct 2014 12:08:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Etrl3dAbZkWu for ; Wed,  8 Oct 2014 12:08:54 -0700 (PDT)
Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 095F11A0322 for ; Wed,  8 Oct 2014 12:08:53 -0700 (PDT)
Received: by mail-vc0-f174.google.com with SMTP id hq12so7370343vcb.19 for ; Wed, 08 Oct 2014 12:08:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=jgcu50nOtB3vrcyzvUkm1jpNZC6gI77hVR1VWAEQXOY=; b=YCHIItX84JvE4VMekfuqdwFmtFo5buzF3DQ/F1/+lV+gOcO95j8HHTHEFxQhhTWL9n eeWmw49cy2rUKKzOeeAJQJsrWe0QDQiNAcgT23+8HWrD/9VKfADuPuiftMcD3V3YAqvU fljvYJoQ808P+n/SREc22QDQs9MxHwE1goimOe+e2v4aZICdjDvohA4OpEn299a1Lq5d ZD9rdEVEyN5SX94fmIefuFG2GeAi1QL9MuuwU+TPxgOODCDfM1AxN9Lu0PtFLhDmxqcJ /EJ994MUKRamNMdw4JAsqVIybc8uwHiA09ZqmjQ9H3gjK2vK+mRKcatR06wfX67FfNHQ b6gw==
X-Gm-Message-State: ALoCoQkQX+USAvVvn9CpB6f24Ow5mRCKLlycvgFN5CP0v4WaU36YwcwNLw4g6F/aLp/JKjj6xs86
MIME-Version: 1.0
X-Received: by 10.220.68.77 with SMTP id u13mr7627723vci.75.1412795333079; Wed, 08 Oct 2014 12:08:53 -0700 (PDT)
Received: by 10.31.10.77 with HTTP; Wed, 8 Oct 2014 12:08:52 -0700 (PDT)
In-Reply-To: 
References:  
Date: Wed, 8 Oct 2014 12:08:52 -0700
Message-ID: 
From: James Woodyatt 
To: HOMENET Working Group 
Content-Type: multipart/alternative; boundary=047d7b3a90aef8649a0504ee0bc0
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/G8gc4BXIVhsPvYcP8b3Xp0f-TIY
Subject: Re: [homenet] I-D.ietf-homenet-prefix-assignment
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 19:08:58 -0000

--047d7b3a90aef8649a0504ee0bc0
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 8, 2014 at 12:30 AM, Markus Stenberg 
wrote:

> On 8.10.2014, at 2.14, James Woodyatt  wrote:
> > The requirements keywords in this section make for a pretty serious
> interop clash with Thread networks , which
> generate their own ULA prefix based on a method defined by its current
> conventions.
>
> I do not think it precludes use of ULAs otherwise, just prevents their
> spontaneous generation according to that particular 0-1 ULAs-in-a-network
> algorithm.


That may be the intent, but if so then that wasn't clear to me in reading
it.


> Just out of curiosity, have you experimented with actually providing ULAs
> and IPv4 connectivity only to normal hosts? We tried that experiment in
> late 2012 (Atlanta IETF 86) and the results based on variety of hosts IETF
> comers came to play with us at the time were somewhat mixed. Some hosts
> notably wanted to use the ULA instead of v4 (and in one case, even ULA over
> IPv6 GUA). That, combined with the fact that you more or less have to
> provide default route to have that ULA usable (thanks to MSR RA option
> being ignored by half the players out there currently), and you may have
> trouble.
>

Experimented? We shipped already.

Yes, we have some problems with hosts running a certain family of operating
systems that don't process RFC 4191 MSR options. We reported the problem
several years ago, but there are very few signs of anything in the works to
help.

My hope is that we will eventually see industry adoption of HOMENET, which
will provide interior routing domains into which we may advertise our
Thread networks via our border routers, providing interoperability with
those hosts that don't accept MSR options in our RA messages.  In the
meantime, we must do something horrible, crude and proprietary where an
elegant, standard solution would be, of course, so much more preferable.


-- 
james woodyatt 
Nest Labs, Communications Engineering

--047d7b3a90aef8649a0504ee0bc0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On W=
ed, Oct 8, 2014 at 12:30 AM, Markus Stenberg <markus.stenberg@iki.fi=
> wrote:
O=
n 8.10.2014, at 2.14, James Woodyatt <jhw@nestlabs.com> wrote:

> The requirements keywords in this section make for a pretty serious in=
terop clash with Thread networks <http://threadgroup.org/>, which generate their own U=
LA prefix based on a method defined by its current conventions.



I do not think it precludes use of ULAs otherwise, just prevents the=
ir spontaneous generation according to that particular 0-1 ULAs-in-a-networ=
k algorithm.

That may be the intent, but if=
 so then that wasn't clear to me in reading it.
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">Just out of curiosity, have you experimented =
with actually providing ULAs and IPv4 connectivity only to normal hosts? We=
 tried that experiment in late 2012 (Atlanta IETF 86) and the results based=
 on variety of hosts IETF comers came to play with us at the time were some=
what mixed. Some hosts notably wanted to use the ULA instead of v4 (and in =
one case, even ULA over IPv6 GUA). That, combined with the fact that you mo=
re or less have to provide default route to have that ULA usable (thanks to=
 MSR RA option being ignored by half the players out there currently), and =
you may have trouble.=C2=A0

Experimented? We shipped already.

Yes, we have some problems with hos=
ts running a certain family of operating systems that don't process RFC=
 4191 MSR options. We reported the problem several years ago, but there are=
 very few signs of anything in the works to help.

My hope is that we will eventua=
lly see industry adoption of HOMENET, which will provide interior routing d=
omains into which we may advertise our Thread networks via our border route=
rs, providing interoperability with those hosts that don't accept MSR o=
ptions in our RA messages.=C2=A0 In the meantime, we must do something horr=
ible, crude and proprietary where an elegant, standard solution would be, o=
f course, so much more preferable.

-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs, Commun=
ications Engineering




--047d7b3a90aef8649a0504ee0bc0--


From nobody Wed Oct  8 13:17:05 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD861A026C for ; Wed,  8 Oct 2014 13:17:04 -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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zdnCpKn0ofZ for ; Wed,  8 Oct 2014 13:17:03 -0700 (PDT)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD231A0222 for ; Wed,  8 Oct 2014 13:17:02 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id cc10so11477296wib.7 for ; Wed, 08 Oct 2014 13:17:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ad3lzepf43PZqKUQ3iCze+e7Vd6AUHA4zyJ6/BhONnc=; b=alg6v2BBFvqtE7WZ5bzRPbDCkxp/H5IgC3Ygohf1PArSwP9qWVtuHkpLpEpBQvAcxe TiODxD6QbnY5bU2p1KLw9ByTJ53k01woM9TPT67puXIs3+7sY3oTLrSCdA+/t7jlSt46 yf/w6J+TAfi0D12KZnfnolNzrCgZelXCydHmz+TbvbIUweDyVTgamKS3DECXSwrjR3lK eCX/aqccYCu5/EyPG2LjSj2Gg641bUls0/DOwncUw2O3WxxP2OTB1xlltQjit4t6fun4 BaW+O0gL4WkTLKMPslcqBRNyII6RQSoqhVXKFu4z7Z/7+jJBBrMkjpRnbmbtUh46OlYS k7Aw==
X-Gm-Message-State: ALoCoQkfdSYk1itR/MEqBOsApXsvEpJC018z/Mgrz3DAX06NB/a7qW9Y68yoq7OH04GM5F5N5HrA
X-Received: by 10.180.99.163 with SMTP id er3mr35120155wib.23.1412799421436; Wed, 08 Oct 2014 13:17:01 -0700 (PDT)
Received: from ?IPv6:2001:420:c0c1:8:fc8f:3a9d:5a09:aa3f? ([2001:420:c0c1:8:fc8f:3a9d:5a09:aa3f]) by mx.google.com with ESMTPSA id ge1sm8596515wib.4.2014.10.08.13.17.00 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Oct 2014 13:17:00 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D8D72B78-41B5-4439-814E-7D49E50ED2D4"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Mark Townsley 
In-Reply-To: 
Date: Wed, 8 Oct 2014 22:16:58 +0200
Message-Id: <8160FF9B-86D6-4836-9D07-A7864508ABF6@townsley.net>
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>  <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr> <5308B561-200A-455C-B2E9-4B4824ED2A1D@ecs.soton.ac.uk> 
To: Tim Chown 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/aI6XroIxRd7jFwVJLKhhuESmRpg
Cc: Ole Troan , Pierre Pfister , homenet@ietf.org, Alexandru Petrescu 
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 20:17:05 -0000

--Apple-Mail=_D8D72B78-41B5-4439-814E-7D49E50ED2D4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


A homenet implementation may indeed decide to self-destruct in a puff of =
smoke before daring to step foot into the classful lowlands of the =
Interface ID, but I actually appreciate that the algorithm itself is =
more general; for robustness sake, in case it is ever used in a =
different context, in the event that why64 ends up being wrong, if ISPs =
don't listen to us and /64 becomes common and we have to do *something* =
to accommodate, etc.=20

Don't get me wrong, I've fought long and hard in many forums and venues =
to keep ISPs from thinking /64 is ever a good idea. I have no problem =
with the strongest language we can provide to try and enforce that. At =
the same time, hedge your bets.=20

- Mark

On Oct 8, 2014, at 4:21 PM, Tim Chown  wrote:

>=20
> On 8 Oct 2014, at 14:14, Pierre Pfister  =
wrote:
>>=20
>> Why should we mandate homenet implementations to *brake* in =
situations where they could work fine ? Why should we voluntarily =
prevent a link from being configured if we actually can configure it ?
>>=20
>> If MUSTs are the solution, then I would rather see a =91ISP MUST =
provide a /56 to customers=92 than =91Homenet MUST brake when the =
provided prefix is not big enough=92.
>=20
> But this is what the homenet arch text says in Section 3.4.1:
> http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.4.1
>=20
> i.e. don=92t go longer than /64, and ISPs should provide enough =
prefixes.
>=20
> The why64 text is very relevant here.
>=20
> Tim
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


--Apple-Mail=_D8D72B78-41B5-4439-814E-7D49E50ED2D4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252



A homenet implementation may =
indeed decide to self-destruct in a puff of smoke before daring to step =
foot into the classful lowlands of the Interface ID, but I actually =
appreciate that the algorithm itself is more general; for robustness =
sake, in case it is ever used in a different context, in the event that =
why64 ends up being wrong, if ISPs don't listen to us and /64 becomes =
common and we have to do *something* to accommodate, =
etc. 

Don't get me wrong, I've fought long =
and hard in many forums and venues to keep ISPs from thinking /64 is =
ever a good idea. I have no problem with the strongest language we can =
provide to try and enforce that. At the same time, hedge your =
bets. 

- Mark

On Oct 8, =
2014, at 4:21 PM, Tim Chown <tjc@ecs.soton.ac.uk> =
wrote:


On 8 Oct 2014, at 14:14, Pierre =
Pfister <pierre.pfister@darou.fr> =
wrote:

Why should we mandate homenet =
implementations to *brake* in situations where they could work fine ? =
Why should we voluntarily prevent a link from being configured if we =
actually can configure it ?

If MUSTs are the solution, then I =
would rather see a =91ISP MUST provide a /56 to customers=92 than =
=91Homenet MUST brake when the provided prefix is not big =
enough=92.

But this is what the homenet =
arch text says in Section 3.4.1:

i.e. don=92t go longer than /64, and ISPs =
should provide enough prefixes.

The why64 text =
is very relevant =
here.

Tim
____________________________=
___________________
homenet mailing list
homenet@ietf.org
https://www.ietf.=
org/mailman/listinfo/homenet

=

--Apple-Mail=_D8D72B78-41B5-4439-814E-7D49E50ED2D4--


From nobody Wed Oct  8 13:25:48 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2791A029D for ; Wed,  8 Oct 2014 13:25:45 -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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maBWO7qMX1ph for ; Wed,  8 Oct 2014 13:25:43 -0700 (PDT)
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B98621A026C for ; Wed,  8 Oct 2014 13:25:42 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id a1so12260019wgh.35 for ; Wed, 08 Oct 2014 13:25:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=bm318Ye41yIS/O4GLmDj3ZBL65j/SBpGnleNcc4JwF4=; b=XwKzmSF2AMEjwkIVJCHQv4NIMElsSLsn63kEoDtY+BMmgUvLqdqayJGfXWei8mIO8k +Jv5awpOgLwhpfFk8f+3sayYNRTlRVXv7s186A9c37xlplJ61ME5Wa1O67pyojpDhwk1 dR+cv4uGMBaMGtbqvNdNOmsMXRmqss8ssY3lxRj0s9C73aiJvorA/QvQlxOoU64j8QDe NFusoxMtbe7GKmp1e5Am95WQephXRHz+SR/tNdnSbxouiWFcHfjnrdurFBj7G0Id0xYv mWahc5dweWOaYi/WJvZZUB+XZgLNG+EwtzDFQClLvj/qwn74O8L6+Yhw2bUuVZrVj27L 77Uw==
X-Gm-Message-State: ALoCoQnp/5sQkcEYzhOHlMNYd9I7QMKw1JFE5+jNyWb7IJrdsfT4kSsdl/9c4B8ACxgJwd3RsLea
X-Received: by 10.180.89.134 with SMTP id bo6mr16174545wib.7.1412799941312; Wed, 08 Oct 2014 13:25:41 -0700 (PDT)
Received: from ?IPv6:2001:420:c0c1:8:fc8f:3a9d:5a09:aa3f? ([2001:420:c0c1:8:fc8f:3a9d:5a09:aa3f]) by mx.google.com with ESMTPSA id lm9sm528290wjc.45.2014.10.08.13.25.40 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Oct 2014 13:25:40 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_C72934FC-771B-4DD9-8435-FAD5C667E2F6"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Mark Townsley 
In-Reply-To: 
Date: Wed, 8 Oct 2014 22:25:39 +0200
Message-Id: <68942A91-BE0D-46B9-9728-CFE0BA0BFBE2@townsley.net>
References:   
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/2RELn3GHXNUNPLhpuYhhFZP8Y4I
Cc: HOMENET Working Group 
Subject: Re: [homenet] I-D.ietf-homenet-prefix-assignment
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Oct 2014 20:25:45 -0000

--Apple-Mail=_C72934FC-771B-4DD9-8435-FAD5C667E2F6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


I have a fairly clear memory of this being discussed during a meeting at =
least. My recollection of the summary was "don't preclude more than one =
ULA prefix, but try to control creating and announcing more than you =
really need whenever possible".

Let's be more clear about that in the text. Certainly, if we support =
multiple prefixes, we shouldn't care if there are one or more than one =
ULA as far as the routing system is concerned. Any limiting of ULAs =
should be more about the local decision to fire one up and announce it =
into the homenet, not whether the homenet accepts it. Conservative in =
what you send, liberal and what you accept.

- Mark

PS. All that said, as with any operation that causes memory to be =
allocated and state tracked, it wouldn't be unreasonable for an =
implementation to start getting suspicious if, say, there are 8x more =
ULAs than total homenet routers in a given network, or a similarly crazy =
number coming out of a single homenet router, etc. Avoid DOS vectors at =
all times ;-)


On Oct 8, 2014, at 9:08 PM, James Woodyatt  wrote:

> On Wed, Oct 8, 2014 at 12:30 AM, Markus Stenberg =
 wrote:
> On 8.10.2014, at 2.14, James Woodyatt  wrote:
> > The requirements keywords in this section make for a pretty serious =
interop clash with Thread networks , which =
generate their own ULA prefix based on a method defined by its current =
conventions.
>=20
> I do not think it precludes use of ULAs otherwise, just prevents their =
spontaneous generation according to that particular 0-1 =
ULAs-in-a-network algorithm.
>=20
> That may be the intent, but if so then that wasn't clear to me in =
reading it.
> =20
> Just out of curiosity, have you experimented with actually providing =
ULAs and IPv4 connectivity only to normal hosts? We tried that =
experiment in late 2012 (Atlanta IETF 86) and the results based on =
variety of hosts IETF comers came to play with us at the time were =
somewhat mixed. Some hosts notably wanted to use the ULA instead of v4 =
(and in one case, even ULA over IPv6 GUA). That, combined with the fact =
that you more or less have to provide default route to have that ULA =
usable (thanks to MSR RA option being ignored by half the players out =
there currently), and you may have trouble.=20
>=20
> Experimented? We shipped already.
>=20
> Yes, we have some problems with hosts running a certain family of =
operating systems that don't process RFC 4191 MSR options. We reported =
the problem several years ago, but there are very few signs of anything =
in the works to help.
>=20
> My hope is that we will eventually see industry adoption of HOMENET, =
which will provide interior routing domains into which we may advertise =
our Thread networks via our border routers, providing interoperability =
with those hosts that don't accept MSR options in our RA messages.  In =
the meantime, we must do something horrible, crude and proprietary where =
an elegant, standard solution would be, of course, so much more =
preferable.
>=20
>=20
> --=20
> james woodyatt 
> Nest Labs, Communications Engineering
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


--Apple-Mail=_C72934FC-771B-4DD9-8435-FAD5C667E2F6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



I have a fairly clear memory of =
this being discussed during a meeting at least. My recollection of the =
summary was "don't preclude more than one ULA prefix, but try to control =
creating and announcing more than you really need whenever =
possible".

Let's be more clear about that in =
the text. Certainly, if we support multiple prefixes, we shouldn't care =
if there are one or more than one ULA as far as the routing system is =
concerned. Any limiting of ULAs should be more about the local decision =
to fire one up and announce it into the homenet, not whether the homenet =
accepts it. Conservative in what you send, liberal and what you =
accept.

- Mark

PS. All =
that said, as with any operation that causes memory to be allocated and =
state tracked, it wouldn't be unreasonable for an implementation to =
start getting suspicious if, say, there are 8x more ULAs than total =
homenet routers in a given network, or a similarly crazy number coming =
out of a single homenet router, etc. Avoid DOS vectors at all times =
;-)


On Oct 8, 2014, at 9:08 PM, James =
Woodyatt <jhw@nestlabs.com> =
wrote:

On Wed, Oct 8, 2014 at 12:30 AM, Markus Stenberg =
<markus.stenberg@iki.fi> =
wrote:
On =
8.10.2014, at 2.14, James Woodyatt <jhw@nestlabs.com> wrote:

> The requirements keywords in this section make for a pretty serious =
interop clash with Thread networks <http://threadgroup.org/>, which generate their =
own ULA prefix based on a method defined by its current conventions.



I do not think it precludes use of ULAs otherwise, just prevents =
their spontaneous generation according to that particular 0-1 =
ULAs-in-a-network algorithm.

That may be =
the intent, but if so then that wasn't clear to me in reading =
it.
 
Just out of curiosity, have you experimented =
with actually providing ULAs and IPv4 connectivity only to normal hosts? =
We tried that experiment in late 2012 (Atlanta IETF 86) and the results =
based on variety of hosts IETF comers came to play with us at the time =
were somewhat mixed. Some hosts notably wanted to use the ULA instead of =
v4 (and in one case, even ULA over IPv6 GUA). That, combined with the =
fact that you more or less have to provide default route to have that =
ULA usable (thanks to MSR RA option being ignored by half the players =
out there currently), and you may have =
trouble. 

Experimented? We shipped =
already.

Yes, we have some problems with hosts running a =
certain family of operating systems that don't process RFC 4191 MSR =
options. We reported the problem several years ago, but there are very =
few signs of anything in the works to help.

My hope is =
that we will eventually see industry adoption of HOMENET, which will =
provide interior routing domains into which we may advertise our Thread =
networks via our border routers, providing interoperability with those =
hosts that don't accept MSR options in our RA messages.  In the =
meantime, we must do something horrible, crude and proprietary where an =
elegant, standard solution would be, of course, so much more =
preferable.


-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications =
Engineering



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

=

--Apple-Mail=_C72934FC-771B-4DD9-8435-FAD5C667E2F6--


From nobody Wed Oct  8 17:23:38 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDF01A8737 for ; Wed,  8 Oct 2014 17:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bVj-teS1Jkv for ; Wed,  8 Oct 2014 17:23:33 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CDF41A872C for ; Wed,  8 Oct 2014 17:23:33 -0700 (PDT)
Received: by mail-oi0-f48.google.com with SMTP id g201so435723oib.35 for ; Wed, 08 Oct 2014 17:23:32 -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=mH60x9yw+8tQteP1WZjw24ksDGMONPPbwp4nKPTbL9Q=; b=IJWbWGiJdzefx3GvBUR4F65N/AmsFxJMBMIYfKSNmLjAR+guTikUiIioSe2NbHi6D3 5gX4hqT1cShTw7i46vnzd0K2QlwP765hzz5p8kGWylEdQMx5OSQQkqzB0qKnNJeiVKKQ 0zTSJs7cztUjr2RaKD+t8/C4yCadf5Z+v+DGKmGelql+u/eM5KTiPnWUAQwT509cPP5M Fww6Ikprt9Fhkow6InW/sJIcerYySVACb5CjP6trQMrzrD2MyXhE9OHIB0Jt9/05S8Me kihRqljzywh6Sb+2KiNM5C69VK9oBbEmAfEBh8nX8UDSkeK9vRl3wMdKn6H+lxjQjcmB GfxA==
X-Received: by 10.182.28.100 with SMTP id a4mr17169401obh.24.1412814212834; Wed, 08 Oct 2014 17:23:32 -0700 (PDT)
Received: from [192.168.178.23] (129.195.69.111.dynamic.snap.net.nz. [111.69.195.129]) by mx.google.com with ESMTPSA id f15sm1334375obs.18.2014.10.08.17.23.29 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Oct 2014 17:23:31 -0700 (PDT)
Message-ID: <5435D586.20806@gmail.com>
Date: Thu, 09 Oct 2014 13:23:34 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Pierre Pfister 
References:  <54348606.7010507@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Bierjz7bHfiuHpWe01y2tnUJeLQ
Cc: HOMENET Working Group , James Woodyatt 
Subject: Re: [homenet] I-D.ietf-homenet-prefix-assignment (RFC 4193 conformance)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 00:23:35 -0000

On 08/10/2014 20:50, Pierre Pfister wrote:
> Hello Brian
>=20
> Please find my answer inline.
>=20
> Le 8 oct. 2014 =C3=A0 02:32, Brian E Carpenter  a =C3=A9crit :
>=20
>> On 08/10/2014 12:14, James Woodyatt wrote:
>>
>> (quoting draft-ietf-homenet-prefix-assignment-00)
>>
>>>   prefix.  If no ULA prefix can be found in stable storage, it MUST b=
e
>>>   randomly generated, or generated from hardware specific values.
>> That sentence is not OK. It should be:
>>
>> If no ULA prefix can be found in stable storage, it MUST be generated
>> as specified in [RFC4193].
>=20
> The point was to have a pseudo-random algorithm that always generates t=
he same ULA.
> Stable storage can be used, but on most crappy home routers, writing on=
 the SSD too much will kill it in a few thousands writes.

There is nothing in RFC 4193 that prevents saving the generated ULA in
stable storage for future use; so I think you need to be clearer that
when a ULA is generated, it SHOULD be stored for future use (until the
next factory reset). I don't see why that generates more than a very few
writes to SSD.

> [RFC4193] states:
> 3.2.1.  Locally Assigned Global IDs
>=20
>    Locally assigned Global IDs MUST be generated with a pseudo-random
>    algorithm consistent with [RANDOM].
>=20
> If remembering the ULA prefix and using it again and again (using stabl=
e storage) is OK, I don=E2=80=99t see why we would need cryptographic pse=
udo-randomness here.
> And actually that=E2=80=99s even worse. Why would a cryptographic pseud=
o-random function would be used with a *known* seed.=20
> The ULA doesn=E2=80=99t need to be secret. It just needs to be random e=
nough to avoid collisions.

Well, yes, but randomness is randomness, i.e. all values are equally like=
ly.
It's really the same thing. I think the assumption was that any box capab=
le
of generating a ULA would already have something better than rand() built=
 in
for other reasons.

> My point here is that if we conform to RFC4193, we lose the stability o=
f the generated ULA, and IMHO we win nothing.

But if you deviate from the standard you need to say so explicitly.
"This procedure deviates from [RFC4193] because...".

> Correct me if I=E2=80=99m wrong, but I think using hardware specific va=
lues as seed is perfectly fine with the collision-avoidance requirement.

I would expect so, and I'm not against what you propose, it just needs
to be clearly documented.

    Brian

> Cheers,
>=20
> Pierre
>=20
>>> The requirements keywords in this section make for a pretty serious i=
nterop
>>> clash with Thread networks , which generate =
their
>>> own ULA prefix based on a method defined by its current conventions.
>> I sincerely hope that method conforms to RFC4193.
>>
>>    Brian
>>
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>=20
>=20


From nobody Wed Oct  8 17:35:24 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723301A87AC for ; Wed,  8 Oct 2014 17:35:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4XrbYnRSWdv for ; Wed,  8 Oct 2014 17:35:20 -0700 (PDT)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78CCD1A87AF for ; Wed,  8 Oct 2014 17:35:17 -0700 (PDT)
Received: by mail-oi0-f44.google.com with SMTP id x69so469691oia.3 for ; Wed, 08 Oct 2014 17:35:16 -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=6rXdioSBymwfJ/cTyeeasKV1vittm/TUb9DDGdI8tzY=; b=IUW8xQ0eNTgM+lXhp1DclfJM+ehynHPwJ6wWg+mHvyf+gsV5ary/8kZg95FeshwfSB FrZgrgyj266kavlgxHd24pHL0/Ws8w7FNzseDZaAzSLdaKIXb1qKtE99CNsSrxruMWO8 rpPpz8u2i348/5DoByQ+jz+zjwTieHz2cVQ+xraClOqIadhsMqpDsfOq9YglfYgCHJQN GDGznlZTGnsZ5+XX0zrU50Yg5S7KTdnRPViDSt4hg0+87JzyKnStBF4SZHC2hsK4xeDE 4GloLt3EUChU5At17Ux0Bjd8GvsUc5y22pGnypARgXwoFicm+WbEnYzX5nzFwbnugDm+ Y1Cw==
X-Received: by 10.60.51.5 with SMTP id g5mr16970130oeo.19.1412814916866; Wed, 08 Oct 2014 17:35:16 -0700 (PDT)
Received: from [192.168.178.23] (129.195.69.111.dynamic.snap.net.nz. [111.69.195.129]) by mx.google.com with ESMTPSA id qi6sm1358654oeb.9.2014.10.08.17.35.12 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Oct 2014 17:35:15 -0700 (PDT)
Message-ID: <5435D845.9030108@gmail.com>
Date: Thu, 09 Oct 2014 13:35:17 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Tim Chown 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>  <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr> <5308B561-200A-455C-B2E9-4B4824ED2A1D@ecs.soton.ac.uk> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/aPJA-MYuu4NT1a_pVV9bEO10Yks
Cc: Ole Troan , Pierre Pfister , homenet@ietf.org, Alexandru Petrescu 
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 00:35:22 -0000

On 09/10/2014 03:21, Tim Chown wrote:
> On 8 Oct 2014, at 14:14, Pierre Pfister  wrote=
:
>> Why should we mandate homenet implementations to *brake* in situations=
 where they could work fine ? Why should we voluntarily prevent a link fr=
om being configured if we actually can configure it ?
>>
>> If MUSTs are the solution, then I would rather see a =E2=80=98ISP MUST=
 provide a /56 to customers=E2=80=99 than =E2=80=98Homenet MUST brake whe=
n the provided prefix is not big enough=E2=80=99.
>=20
> But this is what the homenet arch text says in Section 3.4.1:
> http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.4.1
>=20
> i.e. don=E2=80=99t go longer than /64, and ISPs should provide enough p=
refixes.
>=20
> The why64 text is very relevant here.

And could be added as a reference. It's already in IESG Evaluation
(with one open issue that was just flagged).

Certainly the mechanisms should support any prefix length, but
the reality remains that only /64 subnets work properly in all
circumstances today.

    Brian


From nobody Wed Oct  8 17:46:06 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462D51A87DB for ; Wed,  8 Oct 2014 17:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.687
X-Spam-Level: 
X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dn0l45vX1u5P for ; Wed,  8 Oct 2014 17:46:05 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109021A87D6 for ; Wed,  8 Oct 2014 17:46:05 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id EF99E1FCB5D; Thu,  9 Oct 2014 00:46:01 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1BAEC16005A; Thu,  9 Oct 2014 00:49:02 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id DDFA7160046; Thu,  9 Oct 2014 00:49:01 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 44A9E2106591; Thu,  9 Oct 2014 11:45:59 +1100 (EST)
To: Brian E Carpenter 
From: Mark Andrews 
References:  <54348606.7010507@gmail.com>  <5435D586.20806@gmail.com>
In-reply-to: Your message of "Thu, 09 Oct 2014 13:23:34 +1300." <5435D586.20806@gmail.com>
Date: Thu, 09 Oct 2014 11:45:59 +1100
Message-Id: <20141009004559.44A9E2106591@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/1LO-0ewB7a1lglkg6ydt3VlSAxk
Cc: James Woodyatt , HOMENET Working Group , Pierre Pfister 
Subject: Re: [homenet] I-D.ietf-homenet-prefix-assignment (RFC 4193 conformance)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 00:46:06 -0000

Why are we arguing about this?

You need to be able to *set* the ULA prefix to something that is
externally generated.  This needs to remembered across reboots,
power cycles etc.

There is no point in having a stable algorithm to generate a ULA
prefix.  As far as I can see the only purpose is to avoid having
any non-volatile memory in the box and I don't see that as a realistic
box.

You will also need non-volatile memory for internal prefix delegation
etc.  You you do want the same prefix to be handed to the same
internal router regardless of the request order.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


From nobody Wed Oct  8 22:25:38 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA36F1A90CA for ; Wed,  8 Oct 2014 22:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KshmefqV9uA for ; Wed,  8 Oct 2014 22:25:33 -0700 (PDT)
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4765F1A9096 for ; Wed,  8 Oct 2014 22:25:32 -0700 (PDT)
Received: by mail-wi0-f179.google.com with SMTP id d1so713648wiv.6 for ; Wed, 08 Oct 2014 22:25:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=uyk0JE4i3uUSw+gdyNcnDErRUMI77asu1ZVzObdvnHw=; b=Vaec7wZ6P07FFq9k+J38EIfxeoDIKS5+hCQozwq7w7tT2wjjpCeLzCae7WiakRnP0E JRWxsZtPESSe6TYae1M/U688jvMQgsuuj17c9Mz9SL3yV/9vU/iKB8d6OXn5XMmC73Sk D2G/Xf/FCoP+LQMacu30xO3GlKpf1EsFkHhhiVE2yfThd+axoZAq5klZBqE/jZbUJm0r fZgYgqX5uWdv1YdvPX5h6R3y0RP3ffQYpUGkas2ZmjmrLyBY96AUMssYeXvoGSAXdNHV qIE9K+yOZHt4sK5QK8ClubEbAzMwgGoNWtcZe9I+6xrSxMaPBQld6oUyhrsQwKMk+L5n mtlw==
X-Gm-Message-State: ALoCoQni8xPeJ1ptTrb3K6KWU+Ef+12NumKqL65UV0hgbykevga/j4QLtFXlouSAOZnt9UZG1DDV
X-Received: by 10.180.211.208 with SMTP id ne16mr37248115wic.71.1412832331743;  Wed, 08 Oct 2014 22:25:31 -0700 (PDT)
Received: from [192.168.1.37] (AMontsouris-652-1-129-184.w92-151.abo.wanadoo.fr. [92.151.176.184]) by mx.google.com with ESMTPSA id hp2sm2242666wjb.40.2014.10.08.22.25.30 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Oct 2014 22:25:30 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Mark Townsley 
X-Mailer: iPad Mail (12A405)
In-Reply-To: <5435D845.9030108@gmail.com>
Date: Thu, 9 Oct 2014 07:25:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>  <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr> <5308B561-200A-455C-B2E9-4B4824ED2A1D@ecs.soton.ac.uk>  <5435D845.9030108@gmail.com>
To: Brian E Carpenter 
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/gksodPZ5jE7Ha-F4C5ZCxhFJjL0
Cc: Tim Chown , "homenet@ietf.org" , Pierre Pfister , Ole Troan , Alexandru Petrescu 
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 05:25:36 -0000

> On Oct 9, 2014, at 2:35 AM, Brian E Carpenter  wrote:
>=20
>> On 09/10/2014 03:21, Tim Chown wrote:
>>> On 8 Oct 2014, at 14:14, Pierre Pfister  wrote:=

>>> Why should we mandate homenet implementations to *brake* in situations w=
here they could work fine ? Why should we voluntarily prevent a link from be=
ing configured if we actually can configure it ?
>>>=20
>>> If MUSTs are the solution, then I would rather see a =E2=80=98ISP MUST p=
rovide a /56 to customers=E2=80=99 than =E2=80=98Homenet MUST brake when the=
 provided prefix is not big enough=E2=80=99.
>>=20
>> But this is what the homenet arch text says in Section 3.4.1:
>> http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.4.1
>>=20
>> i.e. don=E2=80=99t go longer than /64, and ISPs should provide enough pre=
fixes.
>>=20
>> The why64 text is very relevant here.
>=20
> And could be added as a reference. It's already in IESG Evaluation
> (with one open issue that was just flagged).

Informative reference, as we don't want to create a downref over this.

>=20
> Certainly the mechanisms should support any prefix length,

I agree.

- Mark

> but
> the reality remains that only /64 subnets work properly in all
> circumstances today.
>=20
>    Brian
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From SRS0=7cAE=7A=darou.fr=pierre.pfister@bounces.m4x.org  Thu Oct  9 02:04:21 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9684C1ACCF0 for ; Thu,  9 Oct 2014 02:04:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q92_TNBYbM9n for ; Thu,  9 Oct 2014 02:04:18 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59AB01ACCF6 for ; Thu,  9 Oct 2014 02:04:18 -0700 (PDT)
Received: from [10.61.199.17] (173-38-208-170.cisco.com [173.38.208.170]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 1C2CF1400062D; Thu,  9 Oct 2014 11:04:14 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_76378C2E-9568-4500-BED0-847F48F04E6A"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Pierre Pfister 
In-Reply-To: <20141009004559.44A9E2106591@rock.dv.isc.org>
Date: Thu, 9 Oct 2014 11:04:21 +0200
Message-Id: <7E7C5904-3F5B-4B1A-A18D-C5C858B820CD@darou.fr>
References:  <54348606.7010507@gmail.com>  <5435D586.20806@gmail.com> <20141009004559.44A9E2106591@rock.dv.isc.org>
To: Brian E Carpenter , James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Thu Oct 9 11:04:15 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Wcusocn3RZxNsYsrBPe8gFHmAAA
Cc: HOMENET Working Group 
Subject: Re: [homenet] I-D.ietf-homenet-prefix-assignment (RFC 4193 conformance)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 09:04:37 -0000

--Apple-Mail=_76378C2E-9568-4500-BED0-847F48F04E6A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Hello James and Brian,

What do you think of the following proposal ?
It allows any router to generate a ULA (it adds more complexity because =
collisions must be avoided, even though the Backoff was necessary at =
boot anyway).
And it conforms to RFC4193 whenever possible (date is available and =
stable storage can be used).


9.1.  ULA Prefix Generation

   A router MAY spontaneously generate a ULA delegated prefix whenever
   the two following conditions are met.

   o  No other ULA delegated prefix is being advertised network-wide.

   o  The ULA Backoff Timer is not running.

   A router MUST stop advertising a spontaneously generated ULA prefix
   whenever another router is advertising a ULA delegated prefix.

   At startup, the ULA Backoff Timer is set to a random value between 0
   and ULA_DELAY_FACTOR * FLOODING_DELAY.  Whenever some other router
   starts advertising a ULA prefix, all routers except the Network
   Leader (Section 4.4) increase their Backoff Timer to a random value
   between 0 and ULA_DELAY_FACTOR * FLOODING_DELAY.

   ULA_DELAY_FACTOR initial value is 2 and is doubled each time the
   router has to withdraw its own spontaneously generated ULA prefix due
   to a collision.  The ULA_DELAY_FACTOR is reset to 2 if at least one
   ULA delegated prefix is advertised network-wide and no new ULA
   delegated prefix is advertised, for a lapse of time of 4 *
   FLOODING_DELAY.

   The most recently used ULA prefix SHOULD be stored in stable storage
   and reused whenever generating a ULA delegated prefix.  If no ULA
   prefix can be found in the stable storage, it MUST be randomly
   generated.

   ULA prefix generation SHOULD conform to [RFC4193].  Nevertheless, if
   the stable storage can't be used or the current date cannot be
   determined, the prefix CAN be pseudo-randomly generated based on
   hardware specific values.

   Not as well that this section doesn't prevent multiple ULA prefixes
   from existing simultaneously.  ULA prefixes may be provided by
   DHCPv6-PD or static configuration, as specified in Section 4.3, in
   which case they are not considered as 'spontaneously' generated and
   MUST NOT be withdrawn if another ULA delegated prefix is observed.



Le 9 oct. 2014 =E0 02:45, Mark Andrews  a =E9crit :

>=20
> Why are we arguing about this?
>=20
> You need to be able to *set* the ULA prefix to something that is
> externally generated.  This needs to remembered across reboots,
> power cycles etc.
>=20
> There is no point in having a stable algorithm to generate a ULA
> prefix.  As far as I can see the only purpose is to avoid having
> any non-volatile memory in the box and I don't see that as a realistic
> box.
>=20
> You will also need non-volatile memory for internal prefix delegation
> etc.  You you do want the same prefix to be handed to the same
> internal router regardless of the request order.
>=20
> --=20
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


--Apple-Mail=_76378C2E-9568-4500-BED0-847F48F04E6A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

Hello =
James and Brian,

What do you think of the following =
proposal ?
It allows any router to generate a ULA (it adds =
more complexity because collisions must be avoided, even though the =
Backoff was necessary at boot anyway).
And it conforms to =
RFC4193 whenever possible (date is available and stable storage can be =
used).


9.1.  ULA Prefix Generation

  =
 A router MAY spontaneously generate a ULA delegated prefix =
whenever
   the two =
following conditions are met.

  =
 o  No other ULA delegated prefix is being advertised =
network-wide.

  =
 o  The ULA Backoff Timer is not =
running.

  =
 A router MUST stop advertising a spontaneously generated ULA =
prefix
   whenever =
another router is advertising a ULA delegated =
prefix.

  =
 At startup, the ULA Backoff Timer is set to a random value between =
0
   and =
ULA_DELAY_FACTOR * FLOODING_DELAY.  Whenever some other =
router
   starts =
advertising a ULA prefix, all routers except the =
Network
   Leader =
(Section 4.4) increase their Backoff Timer to a random =
value
   between 0 and =
ULA_DELAY_FACTOR * FLOODING_DELAY.

  =
 ULA_DELAY_FACTOR initial value is 2 and is doubled each time =
the
   router has to =
withdraw its own spontaneously generated ULA prefix =
due
   to a collision. =
 The ULA_DELAY_FACTOR is reset to 2 if at least =
one
   ULA delegated =
prefix is advertised network-wide and no new ULA
   delegated prefix is advertised, for a =
lapse of time of 4 *
  =
 FLOODING_DELAY.

  =
 The most recently used ULA prefix SHOULD be stored in stable =
storage
   and reused =
whenever generating a ULA delegated prefix.  If no =
ULA
   prefix can be =
found in the stable storage, it MUST be randomly
   generated.

  =
 ULA prefix generation SHOULD conform to [RFC4193]. =
 Nevertheless, if
  =
 the stable storage can't be used or the current date cannot =
be
   determined, the =
prefix CAN be pseudo-randomly generated based on
   hardware specific =
values.

  =
 Not as well that this section doesn't prevent multiple ULA =
prefixes
   from =
existing simultaneously.  ULA prefixes may be provided =
by
   DHCPv6-PD or =
static configuration, as specified in Section 4.3, =
in
   which case they =
are not considered as 'spontaneously' generated =
and
   MUST NOT be =
withdrawn if another ULA delegated prefix is =
observed.



=

Le 9 oct. 2014 =E0 02:45, Mark Andrews <marka@isc.org> a =E9crit :


Why =
are we arguing about this?

You need to be able to *set* the ULA =
prefix to something that is
externally generated.  This needs to =
remembered across reboots,
power cycles etc.

There is no point =
in having a stable algorithm to generate a ULA
prefix.  As far =
as I can see the only purpose is to avoid having
any non-volatile =
memory in the box and I don't see that as a realistic
box.

You =
will also need non-volatile memory for internal prefix =
delegation
etc.  You you do want the same prefix to be handed to =
the same
internal router regardless of the request order.

-- =

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, =
Australia
PHONE: +61 2 9871 4742 =
            &n=
bsp;   INTERNET: marka@isc.org

___________________=
____________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.=
org/mailman/listinfo/homenet

=

--Apple-Mail=_76378C2E-9568-4500-BED0-847F48F04E6A--


From nobody Thu Oct  9 02:27:01 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D771ACD0F for ; Thu,  9 Oct 2014 02:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsHvfioMPJGH for ; Thu,  9 Oct 2014 02:26:54 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71B1C1ACD0D for ; Thu,  9 Oct 2014 02:26:54 -0700 (PDT)
Received: from [10.61.199.17] (173-38-208-170.cisco.com [173.38.208.170]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 5BF471400062D; Thu,  9 Oct 2014 11:26:51 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_156FA5DE-633C-48A5-A6EE-AB74B41A8863"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Pierre Pfister 
In-Reply-To: 
Date: Thu, 9 Oct 2014 11:26:56 +0200
Message-Id: 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>  <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr> <5308B561-200A-455C-B2E9-4B4824ED2A1D@ecs.soton.ac.uk>  <5435D845.9030108@gmail.com> 
To: Ole Troan 
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Thu Oct 9 11:26:52 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/gDJnB_C0kixhrezc4prJmKHpXcU
Cc: Mark Townsley , Tim Chown , "homenet@ietf.org" , Alexandru Petrescu 
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 09:26:57 -0000

--Apple-Mail=_156FA5DE-633C-48A5-A6EE-AB74B41A8863
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hello,

I=92m proposing this change then.

1. In case the provided prefix is 64, the default consist in assigning =
prefixes of length 64 first.
2. I=92m adding a reference to 6man-why64.

When the algorithm decides to make a new assignment, it first needs
   to specify the desired size of the assigned prefix.  Although this
   algorithm intends to remain generic, it was observed in
   [I-D.ietf-6man-why64] that hosts may malfunction when the prefix
   length is not 64.  Therefore, prefixes of length 64 are RECOMMENDED.
   The following table MAY be used as default values, where X is the
   length of the delegated prefix.

   If X <=3D 64:  Prefix length =3D 64

=85.

Processes proposed in the appendix are optional.
Our implementation supports some part of it, and it works fine in our =
test-cases.
I=92d rather have a /80 than no connectivity at all (And it just =
works.).
IMO, why64 is way too pessimistic on the current implementation state =
and even more when it comes to the progress implementations will do in =
the coming years.

And we either do that or let people do NAT66. ;)


Is it OK for you Ole ?

Cheers,

- Pierre

Le 9 oct. 2014 =E0 07:25, Mark Townsley  a =E9crit :

>=20
>=20
>> On Oct 9, 2014, at 2:35 AM, Brian E Carpenter =
 wrote:
>>=20
>>> On 09/10/2014 03:21, Tim Chown wrote:
>>>> On 8 Oct 2014, at 14:14, Pierre Pfister  =
wrote:
>>>> Why should we mandate homenet implementations to *brake* in =
situations where they could work fine ? Why should we voluntarily =
prevent a link from being configured if we actually can configure it ?
>>>>=20
>>>> If MUSTs are the solution, then I would rather see a =91ISP MUST =
provide a /56 to customers=92 than =91Homenet MUST brake when the =
provided prefix is not big enough=92.
>>>=20
>>> But this is what the homenet arch text says in Section 3.4.1:
>>> http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.4.1
>>>=20
>>> i.e. don=92t go longer than /64, and ISPs should provide enough =
prefixes.
>>>=20
>>> The why64 text is very relevant here.
>>=20
>> And could be added as a reference. It's already in IESG Evaluation
>> (with one open issue that was just flagged).
>=20
> Informative reference, as we don't want to create a downref over this.
>=20
>>=20
>> Certainly the mechanisms should support any prefix length,
>=20
> I agree.
>=20
> - Mark
>=20
>> but
>> the reality remains that only /64 subnets work properly in all
>> circumstances today.
>>=20
>>   Brian
>>=20
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


--Apple-Mail=_156FA5DE-633C-48A5-A6EE-AB74B41A8863
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


Hello,

I=92m proposing =
this change then.

1. In case the provided =
prefix is 64, the default consist in assigning prefixes of length 64 =
first.
2. I=92m adding a reference to =
6man-why64.

When =
the algorithm decides to make a new assignment, it first =
needs
   to specify =
the desired size of the assigned prefix.  Although =
this
   algorithm =
intends to remain generic, it was observed in
   [I-D.ietf-6man-why64] that hosts may =
malfunction when the prefix
 =
  length is not 64.  Therefore, prefixes of length 64 are =
RECOMMENDED.
  =
 The following table MAY be used as default values, where X is =
the
   length of the =
delegated prefix.

  =
 If X <=3D 64:  Prefix length =3D =
64

=85.

Processes proposed in the =
appendix are optional.
Our implementation supports some part =
of it, and it works fine in our test-cases.
I=92d rather have =
a /80 than no connectivity at all (And it just works.).
IMO, =
why64 is way too pessimistic on the current implementation state and =
even more when it comes to the progress implementations will do in the =
coming years.

And we either do that or let =
people do NAT66. ;)


Is it OK for =
you Ole ?

Cheers,

- =
Pierre

Le 9 oct. 2014 =E0 07:25, Mark Townsley <mark@townsley.net> a =E9crit =
:



On Oct 9, 2014, at 2:35 =
AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

On 09/10/2014 03:21, Tim =
Chown wrote:
On 8 Oct 2014, at 14:14, =
Pierre Pfister <pierre.pfister@darou.fr> =
wrote:
Why should we mandate homenet implementations to *brake* in =
situations where they could work fine ? Why should we voluntarily =
prevent a link from being configured if we actually can configure it =
?

If MUSTs are the solution, then I would rather see a =91ISP =
MUST provide a /56 to customers=92 than =91Homenet MUST brake when the =
provided prefix is not big enough=92.

But this is =
what the homenet arch text says in Section 3.4.1:
http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.4.1=


i.e. don=92t go longer than /64, and ISPs should provide enough =
prefixes.

The why64 text is very relevant =
here.

And could be added as a reference. It's =
already in IESG Evaluation
(with one open issue that was just =
flagged).

Informative reference, as we don't want to =
create a downref over this.


Certainly=
 the mechanisms should support any prefix length,

I =
agree.

- Mark

but
the reality =
remains that only /64 subnets work properly in all
circumstances =
today.

 =
  Brian

_______________________________________________homenet mailing list
homenet@ietf.org
https://www.ietf.=
org/mailman/listinfo/homenet

_________________________=
______________________
homenet mailing list
homenet@ietf.org
https://www.ietf.=
org/mailman/listinfo/homenet

=

--Apple-Mail=_156FA5DE-633C-48A5-A6EE-AB74B41A8863--


From nobody Thu Oct  9 02:29:22 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E531ACD07 for ; Thu,  9 Oct 2014 02:29:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.983
X-Spam-Level: 
X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wrCUAvB_3nA for ; Thu,  9 Oct 2014 02:29:16 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3EA1ACD04 for ; Thu,  9 Oct 2014 02:29:16 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s999T9xA024327; Thu, 9 Oct 2014 11:29:09 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8F0C9203E2E; Thu,  9 Oct 2014 11:30:15 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 79635203DF1; Thu,  9 Oct 2014 11:30:15 +0200 (CEST)
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 s999T88g014344; Thu, 9 Oct 2014 11:29:09 +0200
Message-ID: <54365564.5090703@gmail.com>
Date: Thu, 09 Oct 2014 11:29:08 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Pierre Pfister , Ole Troan 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>  <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr> <5308B561-200A-455C-B2E9-4B4824ED2A1D@ecs.soton.ac.uk>  <5435D845.9030108@gmail.com>  
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/JhkYVtUT6rcYMqPV2cB5My5XuQg
Cc: Tim Chown , "homenet@ietf.org" , Mark Townsley 
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 09:29:19 -0000

Thanks for updating.

Le 09/10/2014 11:26, Pierre Pfister a écrit :
> Hello,
>
> I’m proposing this change then.
>
> 1. In case the provided prefix is 64, the default consist in assigning
> prefixes of length 64 first.
> 2. I’m adding a reference to 6man-why64.
>
> When the algorithm decides to make a new assignment, it first needs
>     to specify the desired size of the assigned prefix.  Although this
>     algorithm intends to remain generic, it was observed in
>     [I-D.ietf-6man-why64] that hosts may malfunction when the prefix
>     length is not 64.  Therefore, prefixes of length 64 are RECOMMENDED.

With this text above, operators will be encouraged to read and give /64 
to end user sites.

Alex

>     The following table MAY be used as default values, where X is the
>     length of the delegated prefix.
>
>     If X <= 64:  Prefix length = 64
>
> ….
>
> Processes proposed in the appendix are optional.
> Our implementation supports some part of it, and it works fine in our
> test-cases.
> I’d rather have a /80 than no connectivity at all (And it just works.).
> IMO, why64 is way too pessimistic on the current implementation state
> and even more when it comes to the progress implementations will do in
> the coming years.
>
> And we either do that or let people do NAT66. ;)
>
>
> Is it OK for you Ole ?
>
> Cheers,
>
> - Pierre
>
> Le 9 oct. 2014 ŕ 07:25, Mark Townsley  > a écrit :
>
>>
>>
>>> On Oct 9, 2014, at 2:35 AM, Brian E Carpenter
>>> > wrote:
>>>
>>>> On 09/10/2014 03:21, Tim Chown wrote:
>>>>> On 8 Oct 2014, at 14:14, Pierre Pfister >>>> > wrote:
>>>>> Why should we mandate homenet implementations to *brake* in
>>>>> situations where they could work fine ? Why should we voluntarily
>>>>> prevent a link from being configured if we actually can configure it ?
>>>>>
>>>>> If MUSTs are the solution, then I would rather see a ‘ISP MUST
>>>>> provide a /56 to customers’ than ‘Homenet MUST brake when the
>>>>> provided prefix is not big enough’.
>>>>
>>>> But this is what the homenet arch text says in Section 3.4.1:
>>>> http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.4.1
>>>>
>>>> i.e. don’t go longer than /64, and ISPs should provide enough prefixes.
>>>>
>>>> The why64 text is very relevant here.
>>>
>>> And could be added as a reference. It's already in IESG Evaluation
>>> (with one open issue that was just flagged).
>>
>> Informative reference, as we don't want to create a downref over this.
>>
>>>
>>> Certainly the mechanisms should support any prefix length,
>>
>> I agree.
>>
>> - Mark
>>
>>> but
>>> the reality remains that only /64 subnets work properly in all
>>> circumstances today.
>>>
>>>   Brian
>>>
>>> _______________________________________________
>>> homenet mailing list
>>> homenet@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/homenet
>>
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org 
>> https://www.ietf.org/mailman/listinfo/homenet
>



From nobody Thu Oct  9 02:30:10 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B073A1ACD07 for ; Thu,  9 Oct 2014 02:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hICfh0Z2kDjQ for ; Thu,  9 Oct 2014 02:30:06 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7D5A1ACD04 for ; Thu,  9 Oct 2014 02:30:05 -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 s999TvG5029898; Thu, 9 Oct 2014 11:29:57 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CF25E203CAE; Thu,  9 Oct 2014 11:31:03 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BD21D203E79; Thu,  9 Oct 2014 11:31:03 +0200 (CEST)
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 s999TvQg014997; Thu, 9 Oct 2014 11:29:57 +0200
Message-ID: <54365595.9090200@gmail.com>
Date: Thu, 09 Oct 2014 11:29:57 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Brian E Carpenter , Tim Chown 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>  <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr> <5308B561-200A-455C-B2E9-4B4824ED2A1D@ecs.soton.ac.uk>  <5435D845.9030108@gmail.com>
In-Reply-To: <5435D845.9030108@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/sJcD12iNvXYLFeviSXMph-2A0Dg
Cc: Ole Troan , Pierre Pfister , homenet@ietf.org
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 09:30:07 -0000

Le 09/10/2014 02:35, Brian E Carpenter a Ă©crit :
> On 09/10/2014 03:21, Tim Chown wrote:
>> On 8 Oct 2014, at 14:14, Pierre Pfister  wrote:
>>> Why should we mandate homenet implementations to *brake* in situations where they could work fine ? Why should we voluntarily prevent a link from being configured if we actually can configure it ?
>>>
>>> If MUSTs are the solution, then I would rather see a â€ISP MUST provide a /56 to customers’ than â€Homenet MUST brake when the provided prefix is not big enough’.
>>
>> But this is what the homenet arch text says in Section 3.4.1:
>> http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.4.1
>>
>> i.e. don’t go longer than /64, and ISPs should provide enough prefixes.
>>
>> The why64 text is very relevant here.
>
> And could be added as a reference. It's already in IESG Evaluation
> (with one open issue that was just flagged).
>
> Certainly the mechanisms should support any prefix length, but
> the reality remains that only /64 subnets work properly in all
> circumstances today.

But this is new work, not work documenting existing practice.

Alex

>
>      Brian
>
>
>



From nobody Thu Oct  9 02:41:03 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF101ACD0F for ; Thu,  9 Oct 2014 02:41:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.983
X-Spam-Level: 
X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5O1Y5UGIzEE for ; Thu,  9 Oct 2014 02:40:58 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 135BE1A0144 for ; Thu,  9 Oct 2014 02:40:57 -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 s999eqdh020635; Thu, 9 Oct 2014 11:40:52 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4B9C0203E5A; Thu,  9 Oct 2014 11:41:58 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3593C203E59; Thu,  9 Oct 2014 11:41:58 +0200 (CEST)
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 s999eilg024061; Thu, 9 Oct 2014 11:40:51 +0200
Message-ID: <5436581C.5080405@gmail.com>
Date: Thu, 09 Oct 2014 11:40:44 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Pierre Pfister , Ole Troan 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>  <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr> <5308B561-200A-455C-B2E9-4B4824ED2A1D@ecs.soton.ac.uk>  <5435D845.9030108@gmail.com>  
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/OWSneOfiWjD36PBVf4Dt2bSQHHM
Cc: Tim Chown , "homenet@ietf.org" , Mark Townsley 
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 09:41:01 -0000

Hello Pierre,

Le 09/10/2014 11:26, Pierre Pfister a écrit :
[...]
>     The following table MAY be used as default values, where X is the
>     length of the delegated prefix.
>
>     If X <= 64:  Prefix length = 64

I disagree.  In general, for assigning prefixes, and subsequently 
routing to them, I do not understand why should one recommend any prefix 
length at all, and even less to make it default.

This default prefix len above may prohibit one in a homenet to be an ISP 
for other smaller IoT networks.

Look, we have another draft in 6man that calls for adoption, 
draft-boucadair-6man-prefix-routing-reco-00.  That draft recommends the 
following:
>    Forwarding and routing protocols MUST NOT restrict by design the
>    length of IPv6 prefixes.  In particular, forwarding and routing
>    processes MUST be designed to accept prefixes of any length up to
>    /128.

What do you think?

Alex


>
> ….
>
> Processes proposed in the appendix are optional.
> Our implementation supports some part of it, and it works fine in our
> test-cases.
> I’d rather have a /80 than no connectivity at all (And it just works.).
> IMO, why64 is way too pessimistic on the current implementation state
> and even more when it comes to the progress implementations will do in
> the coming years.
>
> And we either do that or let people do NAT66. ;)
>
>
> Is it OK for you Ole ?
>
> Cheers,
>
> - Pierre
>
> Le 9 oct. 2014 ŕ 07:25, Mark Townsley  > a écrit :
>
>>
>>
>>> On Oct 9, 2014, at 2:35 AM, Brian E Carpenter
>>> > wrote:
>>>
>>>> On 09/10/2014 03:21, Tim Chown wrote:
>>>>> On 8 Oct 2014, at 14:14, Pierre Pfister >>>> > wrote:
>>>>> Why should we mandate homenet implementations to *brake* in
>>>>> situations where they could work fine ? Why should we voluntarily
>>>>> prevent a link from being configured if we actually can configure it ?
>>>>>
>>>>> If MUSTs are the solution, then I would rather see a ‘ISP MUST
>>>>> provide a /56 to customers’ than ‘Homenet MUST brake when the
>>>>> provided prefix is not big enough’.
>>>>
>>>> But this is what the homenet arch text says in Section 3.4.1:
>>>> http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.4.1
>>>>
>>>> i.e. don’t go longer than /64, and ISPs should provide enough prefixes.
>>>>
>>>> The why64 text is very relevant here.
>>>
>>> And could be added as a reference. It's already in IESG Evaluation
>>> (with one open issue that was just flagged).
>>
>> Informative reference, as we don't want to create a downref over this.
>>
>>>
>>> Certainly the mechanisms should support any prefix length,
>>
>> I agree.
>>
>> - Mark
>>
>>> but
>>> the reality remains that only /64 subnets work properly in all
>>> circumstances today.
>>>
>>>   Brian
>>>
>>> _______________________________________________
>>> homenet mailing list
>>> homenet@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/homenet
>>
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org 
>> https://www.ietf.org/mailman/listinfo/homenet
>



From nobody Thu Oct  9 02:54:15 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69AC1ACD16; Thu,  9 Oct 2014 02:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xM6p5vFAyhu6; Thu,  9 Oct 2014 02:54:12 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B7A1ACD10; Thu,  9 Oct 2014 02:54:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23973; q=dns/txt; s=iport; t=1412848451; x=1414058051; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=P3f2DlDBCQMqC+mDzEiwC/++uMeFa7DhJ/ylaJN0/Lk=; b=QJr6wYuEta7WS3Bhu+vUxJLLKvzCB3qNhRRXAZTzZx8LRr9LxteO/DJu 8z5lIeGnNlrMAAYrZxculE5XK8MeldlWPUmb5psH5B8r10UkMuybyYXwz c40RqPParWRJ9yr2uBg6rCt1Bp1Lk1t3c9gzr+m5R9iH9HZMpi+8iYfsj A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiAFAI1aNlStJssW/2dsb2JhbABfgkiBcYhhygICgR0Be4QEAQEELUsBEAsYCRYBAQ0JAwIBAgFFBgEMAQcBAReII8YHAReQRAeESwEEj12NaIEuhjY7jW6DZTsvgkoBAQE
X-IronPort-AV: E=Sophos;i="5.04,683,1406592000";  d="scan'208,217";a="205516826"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 09 Oct 2014 09:54:09 +0000
Received: from [10.82.237.37] (rtp-vpn5-1312.cisco.com [10.82.237.37]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s999s743030418; Thu, 9 Oct 2014 09:54:08 GMT
Message-ID: <54365B3F.5070304@cisco.com>
Date: Thu, 09 Oct 2014 11:54:07 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Laurent Ciavaglia , Markus Stenberg 
References: <542BFFAE.1080105@cisco.com>  <542D422F.1090302@cisco.com> <542D4BAB.2060009@alcatel-lucent.com>
In-Reply-To: <542D4BAB.2060009@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="------------020600080702020401090903"
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/BE9wpDRTxqZVBMmHp94nSQVsPMg
Cc: homenet@ietf.org, "anima@ietf.org" 
Subject: Re: [homenet] [Anima]  Homenet feedback on the ANIMA charter
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 09:54:14 -0000

This is a multi-part message in MIME format.
--------------020600080702020401090903
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 02/10/2014 14:57, Laurent Ciavaglia wrote:
> Dear Benoit, Markus, all,
>
> On 02/10/2014 14:16, Benoit Claise wrote:
>> On 01/10/2014 18:27, Markus Stenberg wrote:
>>
>>> Notably, adoption of a solution (discovery+negotiation protocol) before adoption of use cases seems like putting cart before the horse.
>> Valid point.
>>
>> Regards, Benoit
>
> Indeed a valid point, however before concluding here, some insights 
> might help:
>     -OPS ADs gave guidance to focus on (applicability on) 2 use cases 
> only.
>     -The solution adoption milestone shall read as _applicability_ of 
> the protocols onto the two proposed/elected use cases (the milestone 
> should be rewritten in that sense for more clarity).
>     -The WG aims at developing protocols reusable _among __multiple_ 
> use cases.
>     -An initial step of the WG should be to extract, from these 
> multiple use cases, the boundaries / problems these protocols have to 
> solve.
The charter has been updated to reflect this.

Regards, Benoit
>
>
> HTH, best regards, Laurent.
>


--------------020600080702020401090903
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 02/10/2014 14:57, Laurent Ciavaglia
      wrote:

    

    

      
      Dear Benoit, Markus, all,

      

      
On 02/10/2014 14:16, Benoit Claise
        wrote:

      

      

        
On 01/10/2014 18:27, Markus
          Stenberg wrote:

        

        

        

          
Notably, adoption of a solution (discovery+negotiation protocol) before adoption of use cases seems like putting cart before the horse.

        

        Valid point.

        

        Regards, Benoit

      

      Indeed a valid point, however before concluding here, some
      insights might help:

          -OPS ADs gave guidance to focus on (applicability on) 2 use
      cases only.

          -The solution adoption milestone shall read as applicability
      of the protocols onto the two proposed/elected use cases (the
      milestone should be rewritten in that sense for more clarity). 

          -The WG aims at developing protocols reusable among multiple
      use cases.
      
      
      
      
      
      
      
      

          -An initial step of the WG should be to extract, from these
      multiple use cases, the boundaries / problems these protocols have
      to solve. 

    

    The charter has been updated to reflect this.

    

    Regards, Benoit

    
 

      

      HTH, best regards, Laurent.

      

    

    

  


--------------020600080702020401090903--


From nobody Thu Oct  9 02:55:43 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8560D1ACD29 for ; Thu,  9 Oct 2014 02:55:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhOVBtobnNGE for ; Thu,  9 Oct 2014 02:55:41 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D0E1ACD27 for ; Thu,  9 Oct 2014 02:55:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4505; q=dns/txt; s=iport; t=1412848541; x=1414058141; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=lZKt4AG2WpA8gwKPhXGm4amWhtiuoTV9opAinDb+nIY=; b=glaPos8ln+qXwghKxyNjfuPgLF5ZTUoDahB2Nag7+F8iF0Rg9YDpUPOu JkQBDQ/0m8rjSe20vjhYreZIiAiZBtt5iyuL0t3wEEhwHzT96soxYOwNs SJc+dZzjo3IE484Mtn7uxiNkfxrFSCJ6TS0DJU3K/wi5PL5unjqZHdwNl A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiEFAEJbNlStJssW/2dsb2JhbABfg2FYiGHCNIdNAoEdAXuEAwEBAQR4DQQPDQMBAgoWDwkDAgECATsCCBMGAgEBiDoNxXoBEwSQMxgGEIQ1BZY1hxCBLoY2hxSHFYNlOy+CSgEBAQ
X-IronPort-AV: E=Sophos;i="5.04,683,1406592000";  d="scan'208,217";a="204867247"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 09 Oct 2014 09:55:18 +0000
Received: from [10.82.237.37] (rtp-vpn5-1312.cisco.com [10.82.237.37]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s999tGZl032633 for ; Thu, 9 Oct 2014 09:55:17 GMT
Message-ID: <54365B84.6060208@cisco.com>
Date: Thu, 09 Oct 2014 11:55:16 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: homenet@ietf.org
References: <54365ACC.7040106@cisco.com>
In-Reply-To: <54365ACC.7040106@cisco.com>
X-Forwarded-Message-Id: <54365ACC.7040106@cisco.com>
Content-Type: multipart/alternative; boundary="------------070700050006000800020701"
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/k4mtwaBvR9WhojcWGBPhqyKaK_4
Subject: [homenet] Fwd: ANIMA charter: status update
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 09:55:42 -0000

This is a multi-part message in MIME format.
--------------070700050006000800020701
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

FYI, just in case you're not subscribed to ANIMA.

Regards, Benoit


-------- Original Message --------
Subject: 	ANIMA charter: status update
Date: 	Thu, 09 Oct 2014 11:52:12 +0200
From: 	Benoit Claise 
To: 	anima@ietf.org 



Dear all,

 From the minutes of the October 2, 2014 IESG Teleconference

      o Autonomic Networking Integrated Model and Approach (anima) - 4 of 4
         Area: OPS (Benoit Claise)

    The IESG approved the draft WG charter for IETF review pending edits to
    the text of the charter to be supplied by Benoit Claise.  The
    Secretariat will send a WG Review announcement, with a separate message
    tonew-work@ietf.org.

I updated the ANIMA charter based on the IESG feedback.
See https://datatracker.ietf.org/doc/charter-ietf-anima/

I have NOT included any of the HOMENET related feedback at this point.
My goal is to listen to all feedback during the external review period, 
and then to decide which of the WG or the second BoF is the most 
appropriate next step. Reminder: a slot has been secured in the agenda.
The discussion with HOMENET (and any other WG or potentially SDO) is 
both healthy and necessary.

Regards, Benoit



--------------070700050006000800020701
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    FYI, just in case you're not subscribed to ANIMA.

    

    Regards, Benoit

    


      

      -------- Original Message --------
      

        
          

            Subject:
            
            ANIMA charter: status update
          

          

            Date: 
            Thu, 09 Oct 2014 11:52:12 +0200
          

          

            From: 
            Benoit Claise <bclaise@cisco.com>
          

          

            To: 
            anima@ietf.org <anima@ietf.org>
          

        
      

      

      

      
      Dear all,

      

      From the minutes of the October 2, 2014 IESG Teleconference

      

        
 o Autonomic Networking Integrated Model and Approach (anima) - 4 of 4
    Area: OPS (Benoit Claise)

The IESG approved the draft WG charter for IETF review pending edits to 
the text of the charter to be supplied by Benoit Claise.  The 
Secretariat will send a WG Review announcement, with a separate message 
to new-work@ietf.org.

      

      I updated the ANIMA charter based on the IESG feedback.

      See https://datatracker.ietf.org/doc/charter-ietf-anima/

      

      I have NOT included any of the HOMENET related feedback at this
      point.

      My goal is to listen to all feedback during the external review
      period, and then to decide which of the WG or the second BoF is
      the most appropriate next step. Reminder: a slot has been secured
      in the agenda.

      The discussion with HOMENET (and any other WG or potentially SDO)
      is both healthy and necessary.

      

      Regards, Benoit

      

    

    

  


--------------070700050006000800020701--


From nobody Thu Oct  9 04:03:29 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E9D1ACD58 for ; Thu,  9 Oct 2014 04:03:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.235
X-Spam-Level: 
X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6ajK9AxMmnD for ; Thu,  9 Oct 2014 04:03:26 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675661ACD57 for ; Thu,  9 Oct 2014 04:03:26 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqAEAPpqNlStJssW/2dsb2JhbABf1x4CgR4Be4QEAQEDAXkFCwtGVwaISQizIpJoAReQETMHgy2BHgEEnnODRYoFgxaDf4IggUU7gnkBAQE
X-IronPort-AV: E=Sophos;i="5.04,684,1406592000"; d="scan'208";a="205565326"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 09 Oct 2014 11:03:24 +0000
Received: from dhcp-10-61-103-225.cisco.com (dhcp-10-61-103-225.cisco.com [10.61.103.225]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s99B3Nqb027268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Oct 2014 11:03:24 GMT
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Ole Troan 
In-Reply-To: 
Date: Thu, 9 Oct 2014 13:03:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D6BC65B-CD29-4C90-8787-365C79542DDC@employees.org>
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>  <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr> <5308B561-200A-455C-B2E9-4B4824ED2A1D@ecs.soton.ac.uk>  <5435D845.9030108@gmail.com>  
To: Pierre Pfister 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/W90H1hqgCz3rdEtkwvqfDaRl820
Cc: Tim Chown , Mark Townsley , "homenet@ietf.org" , Alexandru Petrescu 
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 11:03:28 -0000

Pierre,

I certainly understand your argument, and we don't disagree on the =
technical merit.

> I=92m proposing this change then.
>=20
> 1. In case the provided prefix is 64, the default consist in assigning =
prefixes of length 64 first.
> 2. I=92m adding a reference to 6man-why64.
>=20
> When the algorithm decides to make a new assignment, it first needs
>    to specify the desired size of the assigned prefix.  Although this
>    algorithm intends to remain generic, it was observed in
>    [I-D.ietf-6man-why64] that hosts may malfunction when the prefix
>    length is not 64.  Therefore, prefixes of length 64 are =
RECOMMENDED.
>    The following table MAY be used as default values, where X is the
>    length of the delegated prefix.
>=20
>    If X <=3D 64:  Prefix length =3D 64

the "may malfunction" is not the reason for why the IPv6 address is =
classful, so please don't put that as justification for a default of 64.

I would like this document to say as little as possible about the =
boundary.
RFC6204 says:
L-2:   The IPv6 CE router MUST assign a separate /64 from its
          delegated prefix(es) (and ULA prefix if configured to provide
          ULA addressing) for each of its LAN interfaces.

which you could tweak to fit this document as well. have text like that =
in one place, and then all other places threat it as an arbitrary =
length.

please remove the table with the description of what to do for various =
values of X.
I'd be happy with a statement like in RFC6204:
   WPD-3:  ...If the
           delegated prefix is too small to address all of its
           interfaces, the IPv6 CE router SHOULD log a system management
           error.

> Processes proposed in the appendix are optional.
> Our implementation supports some part of it, and it works fine in our =
test-cases.
> I=92d rather have a /80 than no connectivity at all (And it just =
works.).
> IMO, why64 is way too pessimistic on the current implementation state =
and even more when it comes to the progress implementations will do in =
the coming years.
>=20
> And we either do that or let people do NAT66. ;)
>=20
>=20
> Is it OK for you Ole ?

I'd also remove the appendix.
it doesn't make sense to specify something that breaks SLAAC.

protocol design is politics. we want to make it clear to the address =
delegation authorities that not delegating a large enough address block =
will lead to breakage.

in my view, if we let this principle slide, then the risk isn't that the =
delegations are /80s, but that they will be /128s. and you're back to =
IPv6 NAT anyhow.

cheers,
Ole


From nobody Thu Oct  9 04:45:08 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A591A028A for ; Thu,  9 Oct 2014 04:45:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkK2iIvpW3dx for ; Thu,  9 Oct 2014 04:45:00 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500681ACDA4 for ; Thu,  9 Oct 2014 04:45:00 -0700 (PDT)
Received: from [10.61.199.17] (173-38-208-170.cisco.com [173.38.208.170]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id DD22C1408EEE1; Thu,  9 Oct 2014 13:44:56 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Pierre Pfister 
In-Reply-To: <0D6BC65B-CD29-4C90-8787-365C79542DDC@employees.org>
Date: Thu, 9 Oct 2014 13:45:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>  <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr> <5308B561-200A-455C-B2E9-4B4824ED2A1D@ecs.soton.ac.uk>  <5435D845.9030108@gmail.com>   <0D6BC65B-CD29-4C90-8787-365C79542DDC@employees.org>
To: Ole Troan 
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Thu Oct 9 13:44:58 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/oF-G19hOgG9mZz3let9NVjxjACc
Cc: Tim Chown , Mark Townsley , "homenet@ietf.org" , Alexandru Petrescu 
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 11:45:07 -0000

Reply inline


Le 9 oct. 2014 =E0 13:03, Ole Troan  a =E9crit :

> Pierre,
>=20
> I certainly understand your argument, and we don't disagree on the =
technical merit.
>=20
>> I=92m proposing this change then.
>>=20
>> 1. In case the provided prefix is 64, the default consist in =
assigning prefixes of length 64 first.
>> 2. I=92m adding a reference to 6man-why64.
>>=20
>> When the algorithm decides to make a new assignment, it first needs
>>   to specify the desired size of the assigned prefix.  Although this
>>   algorithm intends to remain generic, it was observed in
>>   [I-D.ietf-6man-why64] that hosts may malfunction when the prefix
>>   length is not 64.  Therefore, prefixes of length 64 are =
RECOMMENDED.
>>   The following table MAY be used as default values, where X is the
>>   length of the delegated prefix.
>>=20
>>   If X <=3D 64:  Prefix length =3D 64
>=20
> the "may malfunction" is not the reason for why the IPv6 address is =
classful, so please don't put that as justification for a default of 64.

I=92ll change that into something more generic like: =AB Because of all =
the reasons listed in [I-D.ietf-6man-why64], prefixes of length 64 are =
RECOMMENDED. =BB.=20

>=20
> I would like this document to say as little as possible about the =
boundary.
> RFC6204 says:
> L-2:   The IPv6 CE router MUST assign a separate /64 from its
>          delegated prefix(es) (and ULA prefix if configured to provide
>          ULA addressing) for each of its LAN interfaces.
>=20
> which you could tweak to fit this document as well. have text like =
that in one place, and then all other places threat it as an arbitrary =
length.
>=20
> please remove the table with the description of what to do for various =
values of X.

The algorithm treats IPv4 and IPv6 the same way, as well as any prefix =
lengths.=20
That table is important for IPv4 support.

> I'd be happy with a statement like in RFC6204:
>   WPD-3:  ...If the
>           delegated prefix is too small to address all of its
>           interfaces, the IPv6 CE router SHOULD log a system =
management
>           error.
>=20
>> Processes proposed in the appendix are optional.
>> Our implementation supports some part of it, and it works fine in our =
test-cases.
>> I=92d rather have a /80 than no connectivity at all (And it just =
works.).
>> IMO, why64 is way too pessimistic on the current implementation state =
and even more when it comes to the progress implementations will do in =
the coming years.
>>=20
>> And we either do that or let people do NAT66. ;)
>>=20
>>=20
>> Is it OK for you Ole ?
>=20
> I'd also remove the appendix.
> it doesn't make sense to specify something that breaks SLAAC.

But you think it makes sense to specify something that breaks the =
network instead. That is, IMO, a curious tradeoff.

>=20
> protocol design is politics. we want to make it clear to the address =
delegation authorities that not delegating a large enough address block =
will lead to breakage.

It=92s not only about the size of the prefix. It=92s about all the =
variety of situations we will encounter.
Before the first homenet router is shipped, Hipnet-like routers (Those =
who do PD sub delegation) will be there.=20
Mostly as CPE routers. If the ISP is kind enough to give you a /56, they =
will probably give you a /60. If the ISP provides a /60, they will =
provide a /64.
The customer will buy a *homenet enabled* router. Put it behind one of =
these CPEs, and won=92t be able to provide a prefix on both wifi and =
wired networks. That works in ISP=97Homenet=97SubDelegation=97Homenet =
situations too.

And broadband ISPs are not the only kind of uplinks you will have to =
deal with.=20
- VPN service that provides you with a /64 only
- Virtualized networks
- Tethering with your phone=85 They are not going to provide a /56 for =
that (Or at least not soon enough).
- Electrical Company will probably not start giving 56s.
- etc=85

And on top of that, you=92ll have all the devices that require /64 =
prefixes and cut work without it.=20
The algorithm is able to provide them with /64s and deal with smaller =
prefixes on the rest of the network.

Let=92s dream about a world where every device will talk Homenet, but =
waiting for that time, we=92ll have to deal with hundreds of devices =
that behave differently.

>=20
> in my view, if we let this principle slide, then the risk isn't that =
the delegations are /80s, but that they will be /128s. and you're back =
to IPv6 NAT anyhow.
>=20

If that really is a valuable argument, we should start breaking IPv4 so =
that ISPs deploy IPv6 faster.

Cheers,

- Pierre=


From nobody Thu Oct  9 05:44:25 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4424A1ACE33 for ; Thu,  9 Oct 2014 05:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_DBL_ABUSE_SPAM=2] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPXcVfP0hvxo for ; Thu,  9 Oct 2014 05:44:19 -0700 (PDT)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8141ACE25 for ; Thu,  9 Oct 2014 05:44:18 -0700 (PDT)
Received: by mail-ig0-f173.google.com with SMTP id h18so12485167igc.6 for ; Thu, 09 Oct 2014 05:44:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=QjO8fJEfwuuxrLf4ZQyJh4lar4Z8O3anB6v82bw3SpA=; b=O0YX6LDYeYQK7P/hugxcy7KSvRzLkwHRPQ3RlknI7rTrOA0iJy8COiOVbPMroytEjh pPXfuMdU6E/nDshOlZBjHsIanYYpfWYGZfoaxY2HpsG297IEBkMl+KOG4+mDqvCf9CP/ PmGwPNVz2djZAlrhXLDLmTl8rRNnE2e25C9TewI15k0JvJeqNDJPAVpOz43PiGaMbT3Z X7V91189zTAQno8LhGl+ZX7JhYmzaxCB/i/zSVaDiCpnd7GAco0B9Z5Lta8RHILV6xmG 9vDFRjYwl90u4OnPjO/MmKUCyv0qAaRDi0IWEPTMb5aQDfTkqhP0N0ah9V/Hk/3YdJM4 6G7w==
MIME-Version: 1.0
X-Received: by 10.43.155.13 with SMTP id lg13mr7756176icc.15.1412858658284; Thu, 09 Oct 2014 05:44:18 -0700 (PDT)
Received: by 10.64.133.5 with HTTP; Thu, 9 Oct 2014 05:44:18 -0700 (PDT)
Date: Thu, 9 Oct 2014 21:44:18 +0900
Message-ID: 
From: "Mr. Jaehoon Paul Jeong" 
To: homenet@ietf.org
Content-Type: multipart/alternative; boundary=001a11c22eb67234ff0504fcca87
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/MneLYQD05C52674ZMyR9Q1_8ZQg
Subject: [homenet] Request for Comments on New Internet Draft for Homenet WG
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 12:44:23 -0000

--001a11c22eb67234ff0504fcca87
Content-Type: text/plain; charset=UTF-8

Hi all,

I submitted a new Internet Draft about "DNS name autoconfiguration for Home
network or IoT devices".

The DNS name autoconfiguration for home network devices will be useful
for the IPv6 stateless autoconfiguration of Home network (or IoT) devices
along with
RFC 6106 for "IPv6 Router Advertisement Options for DNS Configuration":
http://datatracker.ietf.org/doc/rfc6106/

The following is my draft information:
Title: DNS Name Autoconfiguration for Home Network Devices
       draft-jeong-homenet-device-name-autoconf-01

http://datatracker.ietf.org/doc/draft-jeong-homenet-device-name-autoconf/

Abstract:
   This document specifies an autoconfiguration scheme for DNS names of
   home network devices.  By this scheme, the DNS name of a home network
   device can be autoconfigured with the device's category and model in
   a home network.  This DNS name lets home residents easily identify
   each device for monitoring and remote-controlling it in a home
   network.

I would like to ask you to take a look at my new draft and give me your
valuable feedback.

In this IETF 91 meeting, I hope to present my draft and discuss with you
whether my new proposal can be developed for a new working item in Homenet
WG.

Thanks.

Best Regards,
Paul
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software /
Department of Computer Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-5119
Email: pauljeong@skku.edu, jaehoon.paul@gmail.com
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php

--001a11c22eb67234ff0504fcca87
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi all,

I submitted a new In=
ternet Draft about "DNS name autoconfiguration for Home network or IoT=
 devices".

The DNS name autoconfiguration for=
 home network devices will be useful
for the IPv6 stateless autoc=
onfiguration of Home network (or IoT) devices along with=C2=A0
RF=
C 6106 for "IPv6 Router Advertisement Options for DNS Configuration&qu=
ot;:

The followin=
g is my draft information:
Title: DNS Name Autoconfiguration for =
Home Network Devices
=C2=A0 =C2=A0 =C2=A0 =C2=A0draft-jeong-homen=
et-device-name-autoconf-01



In this IETF 91 meeting, I hope to present my draft and discuss with you=
=C2=A0


<=
div>Best Regards,
Paul




--001a11c22eb67234ff0504fcca87--


From nobody Thu Oct  9 07:28:19 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59201AD00E for ; Thu,  9 Oct 2014 07:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.279
X-Spam-Level: 
X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqZU9OOj07Ib for ; Thu,  9 Oct 2014 07:28:09 -0700 (PDT)
Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.197]) by ietfa.amsl.com (Postfix) with ESMTP id E60811ACFAA for ; Thu,  9 Oct 2014 07:25:00 -0700 (PDT)
Received: from poro.lan (84.248.80.109) by jenni2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 541686920226F54A; Thu, 9 Oct 2014 17:22:27 +0300
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Markus Stenberg 
In-Reply-To: 
Date: Thu, 9 Oct 2014 17:22:27 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: "Mr. Jaehoon Paul Jeong" 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/n7mPXZRf5IaHTARsbhOgkuyuc04
Cc: homenet@ietf.org, Markus Stenberg 
Subject: Re: [homenet] Request for Comments on New Internet Draft for Homenet WG
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 14:28:11 -0000

Heya,

it seems to be aiming to work only within link-local collision domain, =
and therefore it seems to be outside the work homenet WG is chartered to =
do. Perhaps dnssd is more appropriate for this work, although I am not =
sure about that either (they do more than just naming, as the focus is =
on service discovery).

Also, I am not sure why you are not just using mDNS (RFC6762) or SSDP =
(of UPnP) or something else; you get service discovery AND naming with =
them.

Finally, use of DNSSL option for this seems like a bad idea. For =
example, let=92s assume my ISP gives me =92services.isp.com=92 search =
path, and it gets propagated to my LAN. My devices start showing up =
under ..services.isp.com names (too) :-p

Cheers,

-Markus

P.S. Name construction scheme is interesting.=


From nobody Thu Oct  9 12:01:50 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91B01A1ABF for ; Thu,  9 Oct 2014 12:01:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzL9ieTJCbg5 for ; Thu,  9 Oct 2014 12:01:47 -0700 (PDT)
Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD311A1ABB for ; Thu,  9 Oct 2014 12:01:12 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id id10so1506660vcb.34 for ; Thu, 09 Oct 2014 12:01:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=mHOnIsju6SQ01v0vmBPTCG6qYHuvHSv2/+Ys65svx9w=; b=fkF2JJGj+7I6wWaoNhLd3thlFG5WIjk6DGL48ZA6XmM+9qID4U6SmOh6AHMaPxTgKS YnYhbLwBWH9+Nnkt+QGSXtp9CFid/oFW7uIycHUtl+mHEQ0MoS9iQNFGjXEL6oN6ft9r eIhs4QRjqEfBIdl7YZrBIqdpEs6jtf9EArRupQkH7ytFn+ZPspYYRQv7O0JzubevYptF VfVYM7qb2XPGfPvnHGQwCR7bW+ex9BTI+u3EaJFmnzrluQTltTCioHhcSsd2Kf5Cnpst Vwryc1ksB/eMk9y4REW3BPXJof0odAZbZTiNNutYt5oK+flBTwY0bgZlpVX8PK9kXD3n AsZw==
X-Gm-Message-State: ALoCoQmyILGQz3ksCe9R9m4QOYD2FIDU6kq5t7YK1JRgFoc7QvCj2B8xVurQ5xuqR1gQhRAurpQu
MIME-Version: 1.0
X-Received: by 10.52.128.104 with SMTP id nn8mr122282vdb.50.1412881271298; Thu, 09 Oct 2014 12:01:11 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Thu, 9 Oct 2014 12:01:11 -0700 (PDT)
In-Reply-To: <7E7C5904-3F5B-4B1A-A18D-C5C858B820CD@darou.fr>
References:  <54348606.7010507@gmail.com>  <5435D586.20806@gmail.com> <20141009004559.44A9E2106591@rock.dv.isc.org> <7E7C5904-3F5B-4B1A-A18D-C5C858B820CD@darou.fr>
Date: Thu, 9 Oct 2014 12:01:11 -0700
Message-ID: 
From: James Woodyatt 
To: HOMENET Working Group 
Content-Type: multipart/alternative; boundary=bcaec520f5af4939920505020eb2
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/lbA17gNpIBeM807DyDXg08JmpW0
Subject: Re: [homenet] I-D.ietf-homenet-prefix-assignment (RFC 4193 conformance)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 19:01:49 -0000

--bcaec520f5af4939920505020eb2
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 9, 2014 at 2:04 AM, Pierre Pfister 
wrote:

>
> What do you think of the following proposal ?
> It allows any router to generate a ULA (it adds more complexity because
> collisions must be avoided, even though the Backoff was necessary at boot
> anyway).
>

As this is a Standards Track requirements draft, I hope to be excused if
I'm seeming to be overly pedantic, but this revision still leaves me
concerned that we are setting requirements that do not admit Thread
networks into HOMENET routing domains.  Here is the excerpt that I find
most troubling:

ULA prefixes may be provided by DHCPv6-PD or static configuration, as
specified in Section 4.3, in which case they are not considered as
"spontaneously" generated and MUST NOT be withdrawn if another ULA
delegated prefix is observed.


My problem is that Thread networks autonomously number themselves with a
ULA /64 prefix, i.e. a ULA /48 prefix with a well-known 16-bit subnet
identifier. This happens when the first element in a disconnected network
commissions itself. Thread networks will keep this /64 prefix as more
elements are commissioned with network credentials to join the mesh. In the
highly likely event that one or more elements capable of acting as Thread
border routers to the HOMENET domain later join the mesh, then each of them
would naturally want to advertise into the HOMENET domain this autonomously
generated ULA /64 prefix. The language in this proposed revision still
seems to admit only ULA delegated prefixes obtained by DHCPv6-PD and by
*static* configuration, but neither of those are applicable in the case of
Thread networks.

I think my concern might be ameliorated by drawing a distinction in the
requirements between a single distinguished Home ULA Prefix and any number
of other Exterior ULA Prefix delegations.  The former prefix is
autonomously generated by the HOMENET router in the Leader role, whereas
the latter are delegated by exterior numbering authorities outside the
HOMENET domain, and they are just like any other globally scoped IPv6
network prefix.

Would it be helpful if I tried to write up a proposed set of edits for this?


-- 
james woodyatt 
Nest Labs, Communications Engineering

--bcaec520f5af4939920505020eb2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



ULA prefixes may be provided by DHCPv6-P=
D or static configuration, as specified in Section 4.3, in which case they =
are not considered as "spontaneously" generated and MUST NOT be w=
ithdrawn if another ULA delegated prefix is observed.
My problem is that Thread networks autono=
mously number themselves with a ULA /64 prefix, i.e. a ULA /48 prefix with =
a well-known 16-bit subnet identifier. This happens when the first element =
in a disconnected network commissions itself. Thread networks will keep thi=
s /64 prefix as more elements are commissioned with network credentials to =
join the mesh. In the highly likely event that one or more elements capable=
 of acting as Thread border routers to the HOMENET domain later join the me=
sh, then each of them would naturally want to advertise into the HOMENET do=
main this autonomously generated ULA /64 prefix. The language in this propo=
sed revision still seems to admit only ULA delegated prefixes obtained by D=
HCPv6-PD and by *static* configuration, but neither of those are applicable=
 in the case of Thread networks.

=

I think my concern might be ameliorated by drawi=
ng a distinction in the requirements between a single distinguished Home UL=
A Prefix and any number of other Exterior ULA Prefix delegations.=C2=A0 The=
 former prefix is autonomously generated by the HOMENET router in the Leade=
r role, whereas the latter are delegated by exterior numbering authorities =
outside the HOMENET domain, and they are just like any other globally scope=
d IPv6 network prefix.

Would it be helpful if I tried to write up a proposed set =
of edits for this?


-- 
james woodyatt <jhw@nestlabs.com><=
div>Nest Labs, Communications Engineering



--bcaec520f5af4939920505020eb2--


From nobody Thu Oct  9 12:12:01 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1452A1A1ADC for ; Thu,  9 Oct 2014 12:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_N1zlLTyxc1 for ; Thu,  9 Oct 2014 12:11:58 -0700 (PDT)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEA81A1ACC for ; Thu,  9 Oct 2014 12:11:58 -0700 (PDT)
Received: by mail-pa0-f50.google.com with SMTP id kx10so278054pab.37 for ; Thu, 09 Oct 2014 12:11:58 -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=V0kmfVBe6zTfWVzw1PtJJYr0lm+h08fCI29or1dbUeI=; b=mLLOCW3WDdtBEIqjIcOTy1I98YZQW+rrcNXiVJsGAxQTO8CkVIcOlWHFbHs3rkG9lL z3rMboNp9zW04+cbeOmgwzw47XbP5+iyru7p8exO6FbKbgzvHL48PnUvRvD1MlfizMmh jiAAyWSDsyYOF+DQnRfMTL1QGsiE0DuaczPkCfi+XuNL/GS3tl1ETqqjFZ4QAv5sszfQ MorQmh4vIk8iVl/+gtmd40yCr+lcSNeGBiCRy7RwTn5OlgvWXcT92TzbeBinHCBA2htd Dc6hGboOtgxcSt+7/qaOk4pyDtrm5AH+VgNstTBg2VXxJCvZ73YF2QZvUI+1/EFdpPw5 H4GA==
X-Received: by 10.70.39.67 with SMTP id n3mr1863pdk.99.1412881918114; Thu, 09 Oct 2014 12:11:58 -0700 (PDT)
Received: from [192.168.178.23] (247.192.69.111.dynamic.snap.net.nz. [111.69.192.247]) by mx.google.com with ESMTPSA id dj4sm1283394pdb.18.2014.10.09.12.11.54 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Oct 2014 12:11:57 -0700 (PDT)
Message-ID: <5436DE02.8070209@gmail.com>
Date: Fri, 10 Oct 2014 08:12:02 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Pierre Pfister 
References:  <54348606.7010507@gmail.com>  <5435D586.20806@gmail.com> <20141009004559.44A9E2106591@rock.dv.isc.org> <7E7C5904-3F5B-4B1A-A18D-C5C858B820CD@darou.fr>
In-Reply-To: <7E7C5904-3F5B-4B1A-A18D-C5C858B820CD@darou.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/kilnoxRm4LZ3KEeCLjGNkJUUF2o
Cc: HOMENET Working Group , James Woodyatt 
Subject: Re: [homenet] I-D.ietf-homenet-prefix-assignment (RFC 4193 conformance)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 19:12:00 -0000

Works for me, but for RFC 2119, s/CAN/MAY/.

Thanks
   Brian

On 09/10/2014 22:04, Pierre Pfister wrote:
> Hello James and Brian,
>=20
> What do you think of the following proposal ?
> It allows any router to generate a ULA (it adds more complexity because=
 collisions must be avoided, even though the Backoff was necessary at boo=
t anyway).
> And it conforms to RFC4193 whenever possible (date is available and sta=
ble storage can be used).
>=20
>=20
> 9.1.  ULA Prefix Generation
>=20
>    A router MAY spontaneously generate a ULA delegated prefix whenever
>    the two following conditions are met.
>=20
>    o  No other ULA delegated prefix is being advertised network-wide.
>=20
>    o  The ULA Backoff Timer is not running.
>=20
>    A router MUST stop advertising a spontaneously generated ULA prefix
>    whenever another router is advertising a ULA delegated prefix.
>=20
>    At startup, the ULA Backoff Timer is set to a random value between 0=

>    and ULA_DELAY_FACTOR * FLOODING_DELAY.  Whenever some other router
>    starts advertising a ULA prefix, all routers except the Network
>    Leader (Section 4.4) increase their Backoff Timer to a random value
>    between 0 and ULA_DELAY_FACTOR * FLOODING_DELAY.
>=20
>    ULA_DELAY_FACTOR initial value is 2 and is doubled each time the
>    router has to withdraw its own spontaneously generated ULA prefix du=
e
>    to a collision.  The ULA_DELAY_FACTOR is reset to 2 if at least one
>    ULA delegated prefix is advertised network-wide and no new ULA
>    delegated prefix is advertised, for a lapse of time of 4 *
>    FLOODING_DELAY.
>=20
>    The most recently used ULA prefix SHOULD be stored in stable storage=

>    and reused whenever generating a ULA delegated prefix.  If no ULA
>    prefix can be found in the stable storage, it MUST be randomly
>    generated.
>=20
>    ULA prefix generation SHOULD conform to [RFC4193].  Nevertheless, if=

>    the stable storage can't be used or the current date cannot be
>    determined, the prefix CAN be pseudo-randomly generated based on
>    hardware specific values.
>=20
>    Not as well that this section doesn't prevent multiple ULA prefixes
>    from existing simultaneously.  ULA prefixes may be provided by
>    DHCPv6-PD or static configuration, as specified in Section 4.3, in
>    which case they are not considered as 'spontaneously' generated and
>    MUST NOT be withdrawn if another ULA delegated prefix is observed.
>=20
>=20
>=20
> Le 9 oct. 2014 =C3=A0 02:45, Mark Andrews  a =C3=A9crit =
:
>=20
>> Why are we arguing about this?
>>
>> You need to be able to *set* the ULA prefix to something that is
>> externally generated.  This needs to remembered across reboots,
>> power cycles etc.
>>
>> There is no point in having a stable algorithm to generate a ULA
>> prefix.  As far as I can see the only purpose is to avoid having
>> any non-volatile memory in the box and I don't see that as a realistic=

>> box.
>>
>> You will also need non-volatile memory for internal prefix delegation
>> etc.  You you do want the same prefix to be handed to the same
>> internal router regardless of the request order.
>>
>> --=20
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
>>
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>=20
>=20


From nobody Thu Oct  9 12:17:35 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0A41A1B99 for ; Thu,  9 Oct 2014 12:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D_KCZ1lPyGAx for ; Thu,  9 Oct 2014 12:17:32 -0700 (PDT)
Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82A381A1B91 for ; Thu,  9 Oct 2014 12:17:32 -0700 (PDT)
Received: by mail-pd0-f178.google.com with SMTP id y10so268133pdj.37 for ; Thu, 09 Oct 2014 12:17:32 -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=VG2ToTbOzC8hEAFYQ1kHNsFfJru90UMqFGFMijuTF3s=; b=NEUjQqmzLK51Rp9SCTTVgmb9HOI8vaTrjIAILkG2dwGAZmgHqVt5Wej5R6LKBk++cr q7fArMNmdL2GQy7O75PiLRlMjkThGDJSuXr6d1bMzeAugbs8qukcPNE5i2OFSudvzz8A /x/g514uwHG51N53XFJ3W6d+D9vJN76+W59mWpsBpW738ldbzHPYrDfZEthsLa0/uQdq A7zmPm3IFTC5z1KPnNtW7Rk9WiWaU64Q5nYnIL4MNocZYXryB5ABWsylYKcWFXWGVz4a pTND2l2iq5R8ufI5qqncGWxo0sda+Tu5dsEwut9Bqb518luEFMVB/aI/ebUYUTjuzn2j 7YAQ==
X-Received: by 10.68.111.99 with SMTP id ih3mr140290pbb.124.1412882252271; Thu, 09 Oct 2014 12:17:32 -0700 (PDT)
Received: from [192.168.178.23] (247.192.69.111.dynamic.snap.net.nz. [111.69.192.247]) by mx.google.com with ESMTPSA id cw5sm1306028pbc.9.2014.10.09.12.17.28 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Oct 2014 12:17:31 -0700 (PDT)
Message-ID: <5436DF4F.3070209@gmail.com>
Date: Fri, 10 Oct 2014 08:17:35 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Alexandru Petrescu 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>  <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr> <5308B561-200A-455C-B2E9-4B4824ED2A1D@ecs.soton.ac.uk>  <5435D845.9030108@gmail.com>   <54365564.5090703@gmail.com>
In-Reply-To: <54365564.5090703@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/eauHakjDXQS27pHLj_cYEIpGgfA
Cc: Mark Townsley , Ole Troan , "homenet@ietf.org" , Pierre Pfister , Tim Chown 
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 19:17:34 -0000

On 09/10/2014 22:29, Alexandru Petrescu wrote:
> Thanks for updating.
>=20
> Le 09/10/2014 11:26, Pierre Pfister a =C3=A9crit :
>> Hello,
>>
>> I=E2=80=99m proposing this change then.
>>
>> 1. In case the provided prefix is 64, the default consist in assigning=

>> prefixes of length 64 first.
>> 2. I=E2=80=99m adding a reference to 6man-why64.
>>
>> When the algorithm decides to make a new assignment, it first needs
>>     to specify the desired size of the assigned prefix.  Although this=

>>     algorithm intends to remain generic, it was observed in
>>     [I-D.ietf-6man-why64] that hosts may malfunction when the prefix
>>     length is not 64.  Therefore, prefixes of length 64 are RECOMMENDE=
D.
>=20
> With this text above, operators will be encouraged to read and give /64=

> to end user sites.

Huh? This text is discussing internal subnets inside the homenet; it
has nothing to do with the ISP allocation, which is discussed in the
homenet architecture (and RFC 6177).

    Brian


From nobody Thu Oct  9 12:23:20 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40101A1A5C for ; Thu,  9 Oct 2014 12:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level: 
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkoMdEAVgW_C for ; Thu,  9 Oct 2014 12:23:17 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815721A1A42 for ; Thu,  9 Oct 2014 12:23:17 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s99JN4NW007630; Thu, 9 Oct 2014 20:23:05 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s99JN4NW007630
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1412882585; bh=h/JdJeWGbmun742SdJ0Gvzu6Dvk=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=5CWsjhH15SgR9ANqHEaMm0xv9HxpcmwwO7l1ViV22WA6ZuL2jqBzmt2o4IlTh2Fd2 J51ZbFhAlhrhqkxrEF1J4XqQO/N0jECFQjv5T4BL4EcpRxzT60TGENFca1D28iXs3/ 46WlAudqsF5QCjsXc2cHans5WNohIJW6ZvHUSehU=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from  with ESMTP (valid=N/A) id q98KN40302012769yE ret-id none; Thu, 09 Oct 2014 20:23:05 +0100
Received: from [192.168.1.108] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s99JMr0c010611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Oct 2014 20:22:54 +0100
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Tim Chown 
In-Reply-To: <0D6BC65B-CD29-4C90-8787-365C79542DDC@employees.org>
Date: Thu, 9 Oct 2014 20:22:53 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>  <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr> <5308B561-200A-455C-B2E9-4B4824ED2A1D@ecs.soton.ac.uk>  <5435D845.9030108@gmail.com>   <0D6BC65B-CD29-4C90-8787-365C79542DDC@employees.org> 
To: Ole Troan 
X-Mailer: Apple Mail (2.1878.6)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=q98KN4030201276900; tid=q98KN40302012769yE; client=relay,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: s99JN4NW007630
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/w1ScD8PtohT8-rcfkKEDgZPsNRQ
Cc: Townsley Mark , "homenet@ietf.org" , Pierre Pfister , Alexandru Petrescu 
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 19:23:19 -0000

On 9 Oct 2014, at 12:03, Ole Troan  wrote:

> it doesn't make sense to specify something that breaks SLAAC.
>=20
> protocol design is politics. we want to make it clear to the address =
delegation authorities that not delegating a large enough address block =
will lead to breakage.
>=20
> in my view, if we let this principle slide, then the risk isn't that =
the delegations are /80s, but that they will be /128s. and you're back =
to IPv6 NAT anyhow.

So - provocative question - should this draft be Experimental in status =
instead if it=92s diving below /64 boundary?

Tim=


From nobody Thu Oct  9 12:26:39 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8261A6ED8 for ; Thu,  9 Oct 2014 12:26:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xyc1qSenP5i6 for ; Thu,  9 Oct 2014 12:26:34 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239FB1A1BEC for ; Thu,  9 Oct 2014 12:26:33 -0700 (PDT)
Received: from dhcp-10-61-101-131.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 266BE1408EEEA; Thu,  9 Oct 2014 21:26:23 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_92CCF434-82F8-4134-8EF8-A5567604249A"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Pierre Pfister 
In-Reply-To: 
Date: Thu, 9 Oct 2014 21:26:29 +0200
Message-Id: 
References:  <54348606.7010507@gmail.com>  <5435D586.20806@gmail.com> <20141009004559.44A9E2106591@rock.dv.isc.org> <7E7C5904-3F5B-4B1A-A18D-C5C858B820CD@darou.fr> 
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Thu Oct 9 21:26:30 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/VEnsvhLXKH_oYGmL7tAQBuERdrM
Cc: HOMENET Working Group 
Subject: Re: [homenet] I-D.ietf-homenet-prefix-assignment (RFC 4193 conformance)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 19:26:37 -0000

--Apple-Mail=_92CCF434-82F8-4134-8EF8-A5567604249A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


>=20
> I think my concern might be ameliorated by drawing a distinction in =
the requirements between a single distinguished Home ULA Prefix and any =
number of other Exterior ULA Prefix delegations.  The former prefix is =
autonomously generated by the HOMENET router in the Leader role, whereas =
the latter are delegated by exterior numbering authorities outside the =
HOMENET domain, and they are just like any other globally scoped IPv6 =
network prefix.
>=20

There is no intent to prevent that at all. And I totally agree with you =
that ULAs are just prefixes like other.
The last paragraph I put here is just a reminder that, exactly as you =
want, you can have has many ULA prefixes as you want when they are =
provided by the mean of the two first points of section 4.3.

   o  It can be dynamically delegated, for instance using DHCPv6 PD.

   o  It can be created statically, specified in router's configuration.


The first point is what you want. "delegated by exterior numbering =
authorities outside the HOMENET" perfectly fits to the first point.
I mean, it can be using DHCP-PD, netconf, static conf, or any other =
means.

It=92s funny cause it looks like adding that last paragraph, that =
intended to clarify, i making it less clear.

But I=92m going to change it and making it more clear that authorities =
can provide their own prefixes. Even ULAs.

Cheers

- Pierre=

--Apple-Mail=_92CCF434-82F8-4134-8EF8-A5567604249A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252




I think my concern might be ameliorated by drawing =
a distinction in the requirements between a single distinguished Home =
ULA Prefix and any number of other Exterior ULA Prefix =
delegations.  The former prefix is autonomously generated by the =
HOMENET router in the Leader role, whereas the latter are delegated by =
exterior numbering authorities outside the HOMENET domain, and they are =
just like any other globally scoped IPv6 network prefix.


The=
re is no intent to prevent that at all. And I totally agree with you =
that ULAs are just prefixes like other.
The last paragraph I =
put here is just a reminder that, exactly as you want, you can have has =
many ULA prefixes as you want when they are provided by the mean of the =
two first points of section 4.3.

   o  It can be =
dynamically delegated, for instance using DHCPv6 PD.

   o  It can be created statically, specified in router's =
configuration.


The first =
point is what you want. "delegated by exterior numbering authorities =
outside the HOMENET" perfectly fits to the first point.
I =
mean, it can be using DHCP-PD, netconf, static conf, or any other =
means.

It=92s funny cause it looks like adding =
that last paragraph, that intended to clarify, i making it less =
clear.

But I=92m going to change it and making =
it more clear that authorities can provide their own prefixes. Even =
ULAs.

Cheers

- =
Pierre
=

--Apple-Mail=_92CCF434-82F8-4134-8EF8-A5567604249A--


From nobody Thu Oct  9 13:49:54 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AE81A87C7 for ; Thu,  9 Oct 2014 13:49:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6KZjJxjfd8D for ; Thu,  9 Oct 2014 13:49:52 -0700 (PDT)
Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB7BA1A87BC for ; Thu,  9 Oct 2014 13:49:51 -0700 (PDT)
Received: by mail-vc0-f173.google.com with SMTP id ij19so1680543vcb.4 for ; Thu, 09 Oct 2014 13:49:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=HdJ6gLwNkql96yKQEqQGflConTSTnmcAwRbaJjiPUk8=; b=Hv/LkBQCWSK2uYhksI7hKc2csczP5dO4yMnNyA4dueNRarcSyECeQ1MAYipJVRHM/s p6A5KCWm4WqWWjzcwXakhbAOS0k7xpJ6LP0MeATdM31K5o7MJB5IUpG+gFWXssCCireX fmQpnvwY5+/Beme8U3S8rSp+ty5JVWYQtgeMc6PPXnsRkr5VvKdoTvWfOUMsTd1ZeUTv daGU09zLbFvV+yF+hLuo36aVEB5qZDmXjnUyzeeN2jy0El/mEcFTY9NnUQth+HXBbjqO msT5kNPMjr2TYHz27Y8CTWASMIHT9GRRwVLCBRGjSJoqAcT5ahb2Oxt9FkRF7zdboaiw KPmg==
X-Gm-Message-State: ALoCoQlsvTbYCgID7jUSD1EDpdSnfNOeFTjEFeWps9Ql6mr/GEtb1hk60PF4+xq7C8f1dZcNG7la
MIME-Version: 1.0
X-Received: by 10.52.163.206 with SMTP id yk14mr849429vdb.6.1412887791089; Thu, 09 Oct 2014 13:49:51 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Thu, 9 Oct 2014 13:49:51 -0700 (PDT)
In-Reply-To: 
References:  <54348606.7010507@gmail.com>  <5435D586.20806@gmail.com> <20141009004559.44A9E2106591@rock.dv.isc.org> <7E7C5904-3F5B-4B1A-A18D-C5C858B820CD@darou.fr>  
Date: Thu, 9 Oct 2014 13:49:51 -0700
Message-ID: 
From: James Woodyatt 
To: HOMENET Working Group 
Content-Type: multipart/alternative; boundary=001a11c24e3ee55278050503924a
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/2s6XqFhQsVkE5b7I6H-jWctyIws
Subject: Re: [homenet] I-D.ietf-homenet-prefix-assignment (RFC 4193 conformance)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 20:49:53 -0000

--001a11c24e3ee55278050503924a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 9, 2014 at 12:26 PM, Pierre Pfister 
wrote:

>
> But I=E2=80=99m going to change it and making it more clear that authorit=
ies can
> provide their own prefixes. Even ULAs.
>

Thanks! I'm very pleased to see this agreement.


--=20
james woodyatt 
Nest Labs, Communications Engineering

--001a11c24e3ee55278050503924a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
hu, Oct 9, 2014 at 12:26 PM, Pierre Pfister <pierre.pfister@darou.=
fr> wrote:

But I=E2=80=99m going to change it and makin=
g it more clear that authorities can provide their own prefixes. Even ULAs.=


Thanks! I'm very pleased =
to see this agreement.
=C2=A0

-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engineering




--001a11c24e3ee55278050503924a--


From nobody Thu Oct  9 23:50:49 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FC41A0385 for ; Thu,  9 Oct 2014 23:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ED-yy-dbq34 for ; Thu,  9 Oct 2014 23:50:46 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9FA1A0390 for ; Thu,  9 Oct 2014 23:50:44 -0700 (PDT)
Received: from dhcp-10-61-101-131.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 287C01408EEEF; Fri, 10 Oct 2014 08:50:41 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CCA23AA5-D0CC-4CF1-82FC-E4931B599885"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Pierre Pfister 
In-Reply-To: 
Date: Fri, 10 Oct 2014 08:50:50 +0200
Message-Id: 
References:  <54348606.7010507@gmail.com>  <5435D586.20806@gmail.com> <20141009004559.44A9E2106591@rock.dv.isc.org> <7E7C5904-3F5B-4B1A-A18D-C5C858B820CD@darou.fr>   
To: James Woodyatt , Brian E Carpenter 
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Fri Oct 10 08:50:42 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/iXu0tO6cDToXMhinyAmgXv1TRGM
Cc: HOMENET Working Group 
Subject: Re: [homenet] I-D.ietf-homenet-prefix-assignment (RFC 4193 conformance)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 06:50:48 -0000

--Apple-Mail=_CCA23AA5-D0CC-4CF1-82FC-E4931B599885
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hello Brian and James,

Thanks for the heads up. CANs will be replaced in next version.

So I=92m clarifying the two first points in 4.3

   o  It can be delegated by a service provider (DHCPv6 PD, 6rd
      [RFC5969], etc..).

   o  It can be provisioned by an administrative authority (user
      configuration, netconf [RFC6241], etc... ).

And changing the last paragraph of the ULA generation section.

   Note as well that this section doesn't prevent multiple ULA prefixes
   from existing simultaneously.  ULA prefixes may be provided by
   different means, as specified in Section 4.3.  Delegated prefixes
   that are delegated by a service provider or provisioned by an
   authority differ from 'spontaneously' generated prefixes.  They MUST
   NOT be withdrawn if another ULA delegated prefix is observed.


Cheers,

- Pierre


Le 9 oct. 2014 =E0 22:49, James Woodyatt  a =E9crit :

> On Thu, Oct 9, 2014 at 12:26 PM, Pierre Pfister =
 wrote:
>=20
> But I=92m going to change it and making it more clear that authorities =
can provide their own prefixes. Even ULAs.
>=20
> Thanks! I'm very pleased to see this agreement.
> =20
>=20
> --=20
> james woodyatt 
> Nest Labs, Communications Engineering
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


--Apple-Mail=_CCA23AA5-D0CC-4CF1-82FC-E4931B599885
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


Hello Brian and =
James,

Thanks for the heads up. CANs will be =
replaced in next version.

So I=92m clarifying =
the two first points in 4.3

   o  It can be delegated by a service =
provider (DHCPv6 PD, 6rd
  =
    [RFC5969], etc..).

  =
 o  It can be provisioned by an administrative authority =
(user
      =
configuration, netconf [RFC6241], etc... =
).

And changing the last paragraph =
of the ULA generation section.

  =
 Note as well that this section doesn't prevent multiple ULA =
prefixes
   from =
existing simultaneously.  ULA prefixes may be provided =
by
   different means, =
as specified in Section 4.3.  Delegated =
prefixes
   that are =
delegated by a service provider or provisioned by =
an
   authority differ =
from 'spontaneously' generated prefixes.  They =
MUST
   NOT be =
withdrawn if another ULA delegated prefix is =
observed.


Cheers,
- Pierre


Le 9 oct. 2014 =E0=
 22:49, James Woodyatt <jhw@nestlabs.com> a =E9crit =
:

On Thu, Oct 9, 2014 at 12:26 PM, Pierre Pfister =
<pierre.pfister@darou.fr> =
wrote:

But I=92m going to =
change it and making it more clear that authorities can provide their =
own prefixes. Even ULAs.

Thanks! =
I'm very pleased to see this =
agreement.
 

-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications =
Engineering



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

=

--Apple-Mail=_CCA23AA5-D0CC-4CF1-82FC-E4931B599885--


From nobody Fri Oct 10 01:14:36 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80AE31A1BAA for ; Fri, 10 Oct 2014 01:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAyEgB7wPhKH for ; Fri, 10 Oct 2014 01:14:23 -0700 (PDT)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E831A1B36 for ; Fri, 10 Oct 2014 01:14:23 -0700 (PDT)
Received: by mail-ig0-f179.google.com with SMTP id h18so1755659igc.12 for ; Fri, 10 Oct 2014 01:14:22 -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; bh=5RbTnHDwM73UdyC+I5WmP0RFNIUq4459RJHvh1kxIEk=; b=SQReZsy/ABG33Fshzhk0fl6pYAGmvs5GWneTx2DG3zadjQCMaKoZwLOvmMCNxPRejy qsXxuoRb6WwSglPlcG2xmnhOy2NFbDAxCqR3HHbp3hyEJ5ttoPjlTV3Z9g6SYSLsukIg L0nx9ruhsaV5NsThUb4+6ZwY8wGTUJkq8tNFXIiLKYsaMR76QjoAzSLIeD33h0PY/uG6 aJS8UKzesXWTnIg+ik9XcLdA3Tyb/S/IqgP3AhioOSqEI27y6ERRJjM2sRQ/eOcx1Fkt Em2BoNrjx1V0McBwuvO+xLZYImy5JKD+sbcWSWPrFOcxrvJK7RCvoAal1A4/j0ETNOQ9 1wew==
MIME-Version: 1.0
X-Received: by 10.50.103.42 with SMTP id ft10mr4461219igb.40.1412928862736; Fri, 10 Oct 2014 01:14:22 -0700 (PDT)
Received: by 10.64.133.5 with HTTP; Fri, 10 Oct 2014 01:14:22 -0700 (PDT)
In-Reply-To: 
References:  
Date: Fri, 10 Oct 2014 17:14:22 +0900
Message-ID: 
From: "Mr. Jaehoon Paul Jeong" 
To: Markus Stenberg 
Content-Type: multipart/alternative; boundary=047d7b2e133df4d7fc05050d2222
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Blm_xpa8xNuGQ8TmYBRYcubWW18
Cc: homenet@ietf.org
Subject: Re: [homenet] Request for Comments on New Internet Draft for Homenet WG
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 08:14:30 -0000

--047d7b2e133df4d7fc05050d2222
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Markus,
First of all, thanks for your valuable feedback.

Let me answer your questions and comments.

First, as a basic domain, link-local collision domain is assumed,
but we can extend it into multiple links (or subnets) naturally
if a router can work as a proxy for IPv6 hosts.
That is, if a host tries to autoconfigure its DNS name in a subnet and
there exists another host with the same DNS name in an adjacent subnet,
a router interconnecting these two subnets can responds to the DAD
to tell the first host the duplication of the DNS name due to the second
host.

Second, our proposed scheme can be used along with mDNS or SSDP
for IoT devices (e.g., lamp, door lock, and light sensor) whose capacity
cannot afford to run mDNS by itself in terms of memory or processor
capacity.
It those tiny IoT devices with IPv6 stack and stateless autoconfiguration
functionality,
they will be able to support the DNS name services without the intervention
of a home network administrator.

At least, Device Name Generation (in Section 5.2.1) can be used to generate
a DNS name
for home network devices or IoT devices that run mDNS or SSDP.

Third, for DNSSL, DNS suffixes announced by a router within a home network
can be restricted
to a local domain, such as homenet. Since this can be decided by a local
policy within a home network,
we can eliminate the propagation of ISP DNS suffix into a home network.

Are there any other comments or questions?

Sincerely,
Paul




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software /
Department of Computer Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-5119
Email: pauljeong@skku.edu, jaehoon.paul@gmail.com
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php

On Thu, Oct 9, 2014 at 11:22 PM, Markus Stenberg 
wrote:

> Heya,
>
> it seems to be aiming to work only within link-local collision domain, an=
d
> therefore it seems to be outside the work homenet WG is chartered to do.
> Perhaps dnssd is more appropriate for this work, although I am not sure
> about that either (they do more than just naming, as the focus is on
> service discovery).
>
> Also, I am not sure why you are not just using mDNS (RFC6762) or SSDP (of
> UPnP) or something else; you get service discovery AND naming with them.
>
> Finally, use of DNSSL option for this seems like a bad idea. For example,
> let=E2=80=99s assume my ISP gives me =E2=80=99services.isp.com=E2=80=99 s=
earch path, and it gets
> propagated to my LAN. My devices start showing up under ..services.isp.co=
m
> names (too) :-p
>
> Cheers,
>
> -Markus
>
> P.S. Name construction scheme is interesting.

--047d7b2e133df4d7fc05050d2222
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Markus,
First of all, thanks for your valuable feed=
back.

Let me answer your questions and comments.

First, as a basic domain, link-local collision doma=
in is assumed,=C2=A0
but we can extend it into multiple links (or=
 subnets) naturally
if a router can work as a proxy for IPv6 host=
s.=C2=A0
That is, if a host tries to autoconfigure its DNS name i=
n a subnet and=C2=A0
there exists another host with the same DNS =
name in an adjacent subnet,
a router interconnecting these two su=
bnets can responds to the DAD=C2=A0
to tell the first host the du=
plication of the DNS name due to the second host.

=
Second, our proposed scheme can be used along with mDNS or SSDP
f=
or IoT devices (e.g., lamp, door lock, and light sensor) whose capacity
cannot afford to run mDNS by itself in terms of memory or processor =
capacity.=C2=A0
It those tiny IoT devices with IPv6 stack and sta=
teless autoconfiguration functionality,
they will be able to supp=
ort the DNS name services without the intervention of a home network admini=
strator.

At least, Device Name Generation (in Sect=
ion 5.2.1) can be used to generate a DNS name=C2=A0
for home netw=
ork devices or IoT devices that run mDNS or SSDP.

=
Third, for DNSSL, DNS suffixes announced by a router within a home network =
can be restricted=C2=A0
to a local domain, such as homenet. Since=
 this can be decided by a local policy within a home network,
we =
can eliminate the propagation of ISP DNS suffix into a home network.
<=
div>
Are there any other comments or questions?
Sincerely,
Paul




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professo=
r
Department of Software /
Department of Computer Engineering
Sung=
kyunkwan University
Office: +82-31-299-4957
Mobile: +82-10-4758-1765<=
br>Fax: +82-31-290-5119
Email: pauljeong@skku.edu, jaehoon.paul@gmail.com
CPS Lab Website: http://cpslab.skku.edu=

Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php


On Thu, Oct 9, 2014 at 11:22 PM, Markus Sten=
berg <markus.stenberg@iki.fi> wrote:
Heya,



it seems to be aiming to work only within link-local collision domain, and =
therefore it seems to be outside the work homenet WG is chartered to do. Pe=
rhaps dnssd is more appropriate for this work, although I am not sure about=
 that either (they do more than just naming, as the focus is on service dis=
covery).



Also, I am not sure why you are not just using mDNS (RFC6762) or SSDP (of U=
PnP) or something else; you get service discovery AND naming with them.



Finally, use of DNSSL option for this seems like a bad idea. For example, l=
et=E2=80=99s assume my ISP gives me =E2=80=99services.isp.com=E2=80=99 search path, and it g=
ets propagated to my LAN. My devices start showing up under ..services.isp.com names (too) :=
-p



Cheers,



-Markus



P.S. Name construction scheme is interesting.



--047d7b2e133df4d7fc05050d2222--


From nobody Fri Oct 10 01:37:08 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3AD1A6F56 for ; Fri, 10 Oct 2014 01:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2NlY49l7PzW for ; Fri, 10 Oct 2014 01:37:04 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557E11A6F49 for ; Fri, 10 Oct 2014 01:37:00 -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 s9A8Zq9X024360; Fri, 10 Oct 2014 10:35:52 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C6BD9204088; Fri, 10 Oct 2014 10:36:59 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B22A7204082; Fri, 10 Oct 2014 10:36:59 +0200 (CEST)
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 s9A8ZiDY027783; Fri, 10 Oct 2014 10:35:52 +0200
Message-ID: <54379A60.5000708@gmail.com>
Date: Fri, 10 Oct 2014 10:35:44 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Brian E Carpenter 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>  <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr> <5308B561-200A-455C-B2E9-4B4824ED2A1D@ecs.soton.ac.uk>  <5435D845.9030108@gmail.com>   <54365564.5090703@gmail.com> <5436DF4F.3070209@gmail.com>
In-Reply-To: <5436DF4F.3070209@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/kPhyWOzNiLZH1iFF4WljquVov0I
Cc: Mark Townsley , Ole Troan , "homenet@ietf.org" , Pierre Pfister , Tim Chown 
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 08:37:06 -0000

Le 09/10/2014 21:17, Brian E Carpenter a Ă©crit :
> On 09/10/2014 22:29, Alexandru Petrescu wrote:
>> Thanks for updating.
>>
>> Le 09/10/2014 11:26, Pierre Pfister a Ă©crit :
>>> Hello,
>>>
>>> I’m proposing this change then.
>>>
>>> 1. In case the provided prefix is 64, the default consist in assigning
>>> prefixes of length 64 first.
>>> 2. I’m adding a reference to 6man-why64.
>>>
>>> When the algorithm decides to make a new assignment, it first needs
>>>      to specify the desired size of the assigned prefix.  Although this
>>>      algorithm intends to remain generic, it was observed in
>>>      [I-D.ietf-6man-why64] that hosts may malfunction when the prefix
>>>      length is not 64.  Therefore, prefixes of length 64 are RECOMMENDED.
>>
>> With this text above, operators will be encouraged to read and give /64
>> to end user sites.
>
> Huh? This text is discussing internal subnets inside the homenet; it
> has nothing to do with the ISP allocation, which is discussed in the
> homenet architecture (and RFC 6177).

Yes, I looked at RFC 6177 and I agree in a sense.  It is the ISP 
out-of-ones-homenet that is concerned by RFC6177 to assign more than /64 
to homenet.

But, ISPs may be interested in populating one's homenet with more than 
just 1 or 2 boxes currently.  Theyd will rather use this HNCP document 
to build one's homenets, rather than an architecture document.

At that point that ISP may become an internal-subnet-ISP in one's 
homenet.  And will tend to allocate only /64s for anything one wants to 
do in one's homenet beyond the subnets ISP builds.  And that will forbid 
one again to go beyond what ISP allows.

Which may end up in the same /64 limit.

(I speculate that however many devices ISPs put in a homenet there will 
always be some other devices they forgot but need to be there).

(one recent announcement of many devices in home is from Orange, and one 
deployed practice of always-2 boxes is from Free).

Alex

>
>      Brian
>
>
>



From nobody Fri Oct 10 01:46:19 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31F91A00FB for ; Fri, 10 Oct 2014 01:46:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGAjdCYscIqA for ; Fri, 10 Oct 2014 01:46:16 -0700 (PDT)
Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.197]) by ietfa.amsl.com (Postfix) with ESMTP id 2453F1A6F9C for ; Fri, 10 Oct 2014 01:46:16 -0700 (PDT)
Received: from poro.lan (84.248.80.109) by kirsi1.inet.fi (8.5.142.08) (authenticated as stenma-47) id 542527360144087A; Fri, 10 Oct 2014 11:46:13 +0300
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Markus Stenberg 
In-Reply-To: 
Date: Fri, 10 Oct 2014 11:46:12 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   
To: "Mr. Jaehoon Paul Jeong" 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/pBxLtScsNY9aWotUybvfw3d35Ds
Cc: homenet@ietf.org, Markus Stenberg 
Subject: Re: [homenet] Request for Comments on New Internet Draft for Homenet WG
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 08:46:17 -0000

On 10.10.2014, at 11.14, Mr. Jaehoon Paul Jeong  =
wrote:
> First, as a basic domain, link-local collision domain is assumed,=20
> but we can extend it into multiple links (or subnets) naturally
> if a router can work as a proxy for IPv6 hosts.=20
> That is, if a host tries to autoconfigure its DNS name in a subnet and=20=

> there exists another host with the same DNS name in an adjacent =
subnet,
> a router interconnecting these two subnets can responds to the DAD=20
> to tell the first host the duplication of the DNS name due to the =
second host.

So let us assume my 4 home router topology I use for testing homenet =
stuff. Does this imply flooding of those ICMPs? Limited by TTL? =
Something else?

(And it starts to look like L2 bridge at some point.)

> Second, our proposed scheme can be used along with mDNS or SSDP
> for IoT devices (e.g., lamp, door lock, and light sensor) whose =
capacity
> cannot afford to run mDNS by itself in terms of memory or processor =
capacity.=20
> It those tiny IoT devices with IPv6 stack and stateless =
autoconfiguration functionality,
> they will be able to support the DNS name services without the =
intervention of a home network administrator.

There are small mdns daemons, and if you do not want full functionality =
(just names), I am sure it could be even smaller.

To provide a service, you have to be discoverable anyway, and that =
implies mdns, ssdp, or something else that _will use IP address_ to =
contact your particular device anyway.

> At least, Device Name Generation (in Section 5.2.1) can be used to =
generate a DNS name=20
> for home network devices or IoT devices that run mDNS or SSDP.

Use of sub-domains in mDNS is not allowed I think, or at least =
implementations behave badly with them. SSDP I cannot remember.

(They are specified to be flatname.local.)

> Third, for DNSSL, DNS suffixes announced by a router within a home =
network can be restricted=20
> to a local domain, such as homenet. Since this can be decided by a =
local policy within a home network,
> we can eliminate the propagation of ISP DNS suffix into a home =
network.

This implies MUST just to support this, not =91can=92..

And if ISP provides home users with information such as =91go =
http://coolservice', having it break suddenly sounds like a bad idea.

Cheers,

-Markus=


From nobody Fri Oct 10 04:43:31 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5603A1A8AF7 for ; Fri, 10 Oct 2014 04:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7D6xmVyy_2U for ; Fri, 10 Oct 2014 04:43:27 -0700 (PDT)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9B21A8A57 for ; Fri, 10 Oct 2014 04:43:26 -0700 (PDT)
Received: by mail-ig0-f173.google.com with SMTP id h18so2288407igc.12 for ; Fri, 10 Oct 2014 04:43:26 -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; bh=zT6SNoD0Blr34oayY25ew6JPD65IaApEHYfiWxQmFek=; b=soeCu0F2SlV+fa7BgDVeazRZ3WFqcPOuD4cGh2Yb3l2kdFG8o5XhNizIuY4I/fwVxS uurZRF2uoK+4hwI1q4vm8QcJbsN1SHxJeuKmtH3DdmmiuMNOFHyJKAIu7+uBGLHYab7v xMt9kbPP9f7hAuyP77QB97uB4D7F5p5hEPVmcc+W/1Dl6qSPwHKiuhiTQx89WlOxcaU3 Ob9xRQKnwLkpAJAcOmZSV39hxO/ki95vAgILB2cTbkvrCOcwt5W9s0yWGMN+XOMvq+6K auM9Li/V8xhYSFt9CFHX+knmKqBFAvd1qsY4P3KPLVdUSyfq62bMRnQo+W3sHUg67Bjp 87Gg==
MIME-Version: 1.0
X-Received: by 10.51.17.66 with SMTP id gc2mr6086487igd.40.1412941406338; Fri, 10 Oct 2014 04:43:26 -0700 (PDT)
Received: by 10.64.133.5 with HTTP; Fri, 10 Oct 2014 04:43:26 -0700 (PDT)
In-Reply-To: 
References:    
Date: Fri, 10 Oct 2014 20:43:26 +0900
Message-ID: 
From: "Mr. Jaehoon Paul Jeong" 
To: Markus Stenberg , homenet@ietf.org
Content-Type: multipart/alternative; boundary=001a1135f3a49d28250505100ea9
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Hhg-wsDWDQBDuR2D0P0bLeVkwVo
Cc: Jung-Soo Park 
Subject: Re: [homenet] Request for Comments on New Internet Draft for Homenet WG
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 11:43:29 -0000

--001a1135f3a49d28250505100ea9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Markus,
Here are my answers.

On Fri, Oct 10, 2014 at 5:46 PM, Markus Stenberg 
wrote:

> On 10.10.2014, at 11.14, Mr. Jaehoon Paul Jeong 
> wrote:
> > First, as a basic domain, link-local collision domain is assumed,
> > but we can extend it into multiple links (or subnets) naturally
> > if a router can work as a proxy for IPv6 hosts.
> > That is, if a host tries to autoconfigure its DNS name in a subnet and
> > there exists another host with the same DNS name in an adjacent subnet,
> > a router interconnecting these two subnets can responds to the DAD
> > to tell the first host the duplication of the DNS name due to the secon=
d
> host.
>
> So let us assume my 4 home router topology I use for testing homenet
> stuff. Does this imply flooding of those ICMPs? Limited by TTL? Something
> else?
>
>      =3D> Since a router collects DNS names of IoT devices in its subnets=
,
           it limits ICMP messages for Node Information Query to each
subnet.


> (And it starts to look like L2 bridge at some point.)
>
> > Second, our proposed scheme can be used along with mDNS or SSDP
> > for IoT devices (e.g., lamp, door lock, and light sensor) whose capacit=
y
> > cannot afford to run mDNS by itself in terms of memory or processor
> capacity.
> > It those tiny IoT devices with IPv6 stack and stateless
> autoconfiguration functionality,
> > they will be able to support the DNS name services without the
> intervention of a home network administrator.
>
> There are small mdns daemons, and if you do not want full functionality
> (just names), I am sure it could be even smaller.
>
     =3D> Sure mDNS can be implemented lightly. However, my proposal scheme
can be implemented easily with small overhead
          for low-capacity IoT devices.

>
> To provide a service, you have to be discoverable anyway, and that implie=
s
> mdns, ssdp, or something else that _will use IP address_ to contact your
> particular device anyway.
>
     =3D> Once the DNS names of IoT devices are collected by a router, they
are self-explanatory for the service types
          through device category and device model in DNS names.

>
> > At least, Device Name Generation (in Section 5.2.1) can be used to
> generate a DNS name
> > for home network devices or IoT devices that run mDNS or SSDP.
>
> Use of sub-domains in mDNS is not allowed I think, or at least
> implementations behave badly with them. SSDP I cannot remember.
>
> (They are specified to be flatname.local.)
>
    =3D> It seems like you are right in mDNS because .local is the DNS
top-level domain for a link-local scope network.
         However, I believe that my proposed DNS name format (i.e.,
unique_id.device_model.device_category.domain_name)
         can make it easy to perform service discovery by the DNS name
itself without actual network operations.

>
> > Third, for DNSSL, DNS suffixes announced by a router within a home
> network can be restricted
> > to a local domain, such as homenet. Since this can be decided by a loca=
l
> policy within a home network,
> > we can eliminate the propagation of ISP DNS suffix into a home network.
>
> This implies MUST just to support this, not =E2=80=98can=E2=80=99..
>
     =3D> If my proposal is accepted by IETF, MUST may be used. :-)

>
> And if ISP provides home users with information such as =E2=80=98go
> http://coolservice', having it break suddenly sounds like a bad idea.
>
> Cheers,
>
> -Markus



   Thanks for your constructive feedback.

   Regards,
   Paul

--001a1135f3a49d28250505100ea9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Markus,
Here are my answers.


On Fri, Oct 10, 2014 at 5:46 PM, Markus Sten=
berg <markus.stenberg@iki.fi> wrote:
On 10.10.2014, at 11.14, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrote:=


> First, as a basic domain, link-local collision domain is assumed,

> but we can extend it into multiple links (or subnets) naturally

> if a router can work as a proxy for IPv6 hosts.

> That is, if a host tries to autoconfigure its DNS name in a subnet and=


> there exists another host with the same DNS name in an adjacent subnet=
,

> a router interconnecting these two subnets can responds to the DAD

> to tell the first host the duplication of the DNS name due to the seco=
nd host.



So let us assume my 4 home router topology I use for testing homenet=
 stuff. Does this imply flooding of those ICMPs? Limited by TTL? Something =
else?


=C2=A0 =C2=A0 =C2=A0=3D> Since a router collects D=
NS names of IoT devices in its subnets,=C2=A0
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0it limits ICMP messages for Node Information Query =
to each subnet.
=C2=A0

(And it starts to look like L2 bridge at some point.)



> Second, our proposed scheme can be used along with mDNS or SSDP

> for IoT devices (e.g., lamp, door lock, and light sensor) whose capaci=
ty

> cannot afford to run mDNS by itself in terms of memory or processor ca=
pacity.

> It those tiny IoT devices with IPv6 stack and stateless autoconfigurat=
ion functionality,

> they will be able to support the DNS name services without the interve=
ntion of a home network administrator.



There are small mdns daemons, and if you do not want full functional=
ity (just names), I am sure it could be even smaller.
=
=C2=A0 =C2=A0 =C2=A0=3D> Sure mDNS can be implemented lightly. However, =
my proposal scheme can be implemented easily with small overhead=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for low-capacity IoT devices.



To provide a service, you have to be discoverable anyway, and that implies =
mdns, ssdp, or something else that _will use IP address_ to contact your pa=
rticular device anyway.
=C2=A0 =C2=A0 =C2=A0=3D> On=
ce the DNS names of IoT devices are collected by a router, they are self-ex=
planatory for the service types=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 through device category and device model in DNS names.



> At least, Device Name Generation (in Section 5.2.1) can be used to gen=
erate a DNS name

> for home network devices or IoT devices that run mDNS or SSDP.



Use of sub-domains in mDNS is not allowed I think, or at least imple=
mentations behave badly with them. SSDP I cannot remember.



(They are specified to be flatname.local.)
=C2=A0 =C2=
=A0 =3D> It seems like you are right in mDNS because .local is the DNS t=
op-level domain for a link-local scope network.=C2=A0
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0However, I believe that my proposed DNS name format=
 (i.e., unique_id.device_model.device_category.domain_name)
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can make it easy to perform service discover=
y by the DNS name itself without actual network operations.



> Third, for DNSSL, DNS suffixes announced by a router within a home net=
work can be restricted

> to a local domain, such as homenet. Since this can be decided by a loc=
al policy within a home network,

> we can eliminate the propagation of ISP DNS suffix into a home network=
.



This implies MUST just to support this, not =E2=80=98can=E2=80=99..<=
br>
=C2=A0 =C2=A0 =C2=A0=3D> If my proposal is accepted=
 by IETF, MUST may be used. :-)=C2=A0



And if ISP provides home users with information such as =E2=80=98go http://coolservice', havi=
ng it break suddenly sounds like a bad idea.



Cheers,



-Markus


=C2=A0 =C2=A0Thanks for your constructive feedback=
.

=C2=
=A0 =C2=A0Regards,
=C2=A0 =C2=A0Paul
<=
div class=3D"gmail_extra">


--001a1135f3a49d28250505100ea9--


From nobody Fri Oct 10 05:43:24 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B6C1ACCFB for ; Fri, 10 Oct 2014 05:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FxM--j6yv2H for ; Fri, 10 Oct 2014 05:43:20 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A231ACC83 for ; Fri, 10 Oct 2014 05:43:20 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id n3so1880057wiv.17 for ; Fri, 10 Oct 2014 05:43:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=UI30ckdy7orkVsJRrZ8cLRLO6LykTb0A93DW4OHdDzY=; b=BQl0nNEUksVIz6r8fJYTzUwgEusX2O+m16qxGPRMhroEmc8LQPZw+5IaoLwgRaJ+Jj IHYBHVqGmgzUsfFeQlSOMZyJ6ETODIsapC/jY1KeFEHZRi3kvX06mP2pUwsxswSoqcZo dbHnzXVo0i2HuUozOi7OAAM90lK3QHxuYVa5vDd50yO7pUYnBmbWUCStb5EzXDsVPfAo gdUcb4gGEEATAbXkGrpally/0hbJGmY4hGqjCihgvnTph9P2RmcdPUiWF7h+XGesWwOt AjYCYRm8UCO06rmISgxlB/xJa1J4UvP6Q7bv4LnCOff0mA8Vdxg7IkTcEZiYAbeUCQeL yoAQ==
X-Gm-Message-State: ALoCoQmztu3u9NIVuz2ncVpA4EFwAg335/VKTBPkOFEO3l68XOXFOiPsIL+WsSmY06UQWdcKiC2u
X-Received: by 10.180.107.42 with SMTP id gz10mr4484756wib.67.1412944998784; Fri, 10 Oct 2014 05:43:18 -0700 (PDT)
Received: from [192.168.1.38] (AMontsouris-654-1-51-143.w90-2.abo.wanadoo.fr. [90.2.178.143]) by mx.google.com with ESMTPSA id ey6sm2521799wib.16.2014.10.10.05.43.17 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Oct 2014 05:43:17 -0700 (PDT)
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>  <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr> <5308B561-200A-455C-B2E9-4B4824ED2A1D@ecs.soton.ac.uk>  <5435D845.9030108@gmail.com>   <0D6BC65B-CD29-4C90-8787-365C79542DDC@employees.org>  
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <842E6585-18FF-4286-8C6F-C683500D47FC@townsley.net>
X-Mailer: iPhone Mail (12A405)
From: "Townsley.net" 
Date: Fri, 10 Oct 2014 14:43:18 +0200
To: Tim Chown 
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/z93-HPYqyLkyEltMw-C42tk_eiM
Cc: Ole Troan , Pierre Pfister , "homenet@ietf.org" , Alexandru Petrescu 
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 12:43:22 -0000

> On Oct 9, 2014, at 9:22 PM, Tim Chown  wrote:
>=20
>> On 9 Oct 2014, at 12:03, Ole Troan  wrote:
>>=20
>> it doesn't make sense to specify something that breaks SLAAC.
>>=20
>> protocol design is politics. we want to make it clear to the address dele=
gation authorities that not delegating a large enough address block will lea=
d to breakage.
>>=20
>> in my view, if we let this principle slide, then the risk isn't that the d=
elegations are /80s, but that they will be /128s. and you're back to IPv6 NA=
T anyhow.
>=20
> So - provocative question - should this draft be Experimental in status in=
stead if it=E2=80=99s diving below /64 boundary?

No. I think you are putting way too much weight on an informational document=
 here.=20

- Mark

>=20
> Tim


From nobody Fri Oct 10 07:28:59 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3280E1A923B for ; Fri, 10 Oct 2014 07:28:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.006
X-Spam-Level: 
X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rckfuclsy8mL for ; Fri, 10 Oct 2014 07:28:54 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0129C1ACE16 for ; Fri, 10 Oct 2014 07:28:53 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s9AESb5M032533; Fri, 10 Oct 2014 15:28:37 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s9AESb5M032533
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1412951318; bh=wdNTZwIo8Tq1Dj0WMlFfkG8lKNI=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=tnsknf2qR09zZnniJWwY+k+CFAQOPGa949ctTSDQpctDO7QBW2gIGiXQS03PreSJU MuJyjEaGhaY0x75pRuLPpjxQ4eWAWg4ye5GEkImXtutkQbDRzfGqMSWFIvXU0NBRYs ZPlwmhlQHWPBP0Q1rWgtSEmnbw5pxf4uHAEN9sW4=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from  with ESMTP (valid=N/A) id q99FSb28086096267B ret-id none; Fri, 10 Oct 2014 15:28:38 +0100
Received: from [10.9.53.53] (b54gafwc1n1-ext.net.soton.ac.uk [152.78.0.25]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s9AESZTV024144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Oct 2014 15:28:35 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_0539ED87-5F97-4E18-84D0-A27FCCF3ACFF"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Tim Chown 
In-Reply-To: <842E6585-18FF-4286-8C6F-C683500D47FC@townsley.net>
Date: Fri, 10 Oct 2014 15:28:36 +0100
Message-ID: 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>  <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr> <5308B561-200A-455C-B2E9-4B4824ED2A1D@ecs.soton.ac.uk>  <5435D845.9030108@gmail.com>   <0D6BC65B-CD29-4C90-8787-365C79542DDC@employees.org>   <842E6585-18FF-4286-8C6F-C683500D47FC@townsley.net> <3D635F2F-15E1-45A7-869C-ACF82FDC60BF@ecs.soton.ac.uk>
To: Townsley Mark 
X-Mailer: Apple Mail (2.1878.6)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=q99FSb280860962600; tid=q99FSb28086096267B; client=relay,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: s9AESb5M032533
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/YoOzdwQYfH-6AMgXHmFC4PveLJc
Cc: Ole Troan , Pierre Pfister , "homenet@ietf.org" , Alexandru Petrescu 
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 14:28:58 -0000

--Apple-Mail=_0539ED87-5F97-4E18-84D0-A27FCCF3ACFF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

On 10 Oct 2014, at 13:43, Townsley.net  wrote:
>=20
>> On Oct 9, 2014, at 9:22 PM, Tim Chown  wrote:
>>=20
>>> On 9 Oct 2014, at 12:03, Ole Troan  wrote:
>>>=20
>>> it doesn't make sense to specify something that breaks SLAAC.
>>>=20
>>> protocol design is politics. we want to make it clear to the address =
delegation authorities that not delegating a large enough address block =
will lead to breakage.
>>>=20
>>> in my view, if we let this principle slide, then the risk isn't that =
the delegations are /80s, but that they will be /128s. and you're back =
to IPv6 NAT anyhow.
>>=20
>> So - provocative question - should this draft be Experimental in =
status instead if it=92s diving below /64 boundary?
>=20
> No. I think you are putting way too much weight on an informational =
document here.=20

Hmmm.. the draft says it=92s intended status is Standards Track, not =
Informational?  Just a typo?

Network Working Group                                         P. Pfister
Internet-Draft                                               B. Paterson
Intended status: Standards Track                           Cisco Systems
Expires: March 23, 2015                                         J. Arkko
                                                                Ericsson
                                                      September 19, 2014

Tim=

--Apple-Mail=_0539ED87-5F97-4E18-84D0-A27FCCF3ACFF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

On 10 =
Oct 2014, at 13:43, Townsley.net =
<mark@townsley.net> =
wrote:

On =
Oct 9, 2014, at 9:22 PM, Tim Chown <tjc@ecs.soton.ac.uk> =
wrote:

On 9 Oct 2014, at 12:03, Ole =
Troan <otroan@employees.org> =
wrote:

it doesn't make sense to specify something that breaks =
SLAAC.

protocol design is politics. we want to make it clear to =
the address delegation authorities that not delegating a large enough =
address block will lead to breakage.

in my view, if we let this =
principle slide, then the risk isn't that the delegations are /80s, but =
that they will be /128s. and you're back to IPv6 NAT =
anyhow.

So - provocative question - should this =
draft be Experimental in status instead if it=92s diving below /64 =
boundary?

No. I think you are putting way too much =
weight on an informational document here. =


Hmmm.. the draft says it=92s intended =
status is Standards Track, not Informational?  Just a =
typo?

Network Working =
Group                                         P. Pfister
Internet-Draft                                               B. Paterson
Intended status: Standards Track                           Cisco Systems
Expires: March 23, 2015                                         J. Arkko
                                                                Ericsson
                                                      September 19, =
2014

Tim
=

--Apple-Mail=_0539ED87-5F97-4E18-84D0-A27FCCF3ACFF--


From nobody Fri Oct 10 10:12:15 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D581C1A88B2 for ; Fri, 10 Oct 2014 10:12:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOgC5oujqS-K for ; Fri, 10 Oct 2014 10:12:11 -0700 (PDT)
Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8615D1A8905 for ; Fri, 10 Oct 2014 10:10:59 -0700 (PDT)
Received: by mail-vc0-f177.google.com with SMTP id hq11so2951240vcb.8 for ; Fri, 10 Oct 2014 10:10:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=+EfM4+qiDBghqt52Qp264W4eAnfZXeNm1FasPYz+M3k=; b=ORAK/iJ/QAWZq7nCZqVrTcW6SvWlc0M85wVNuJjGVlahsd1M69oa2EbxYI40JXIbVg wrTgF1jIqhaGYWwh5OOpeGbNZdADAe2IxlHqhZoIcjHSW61McCRRVktaRO74l8kEdS9i 1kTlXazaRqRygkhT/Z+OKBWm1zmux2rAZ4DLVNsM0eeTpI7l4PzKWLvYQ9hIBskr6luO KdihK0gLwriCuZUEF2VuxMFQnxEp6MAwtXaBTgBCBqxZU0BqONazCwVmgxEWsm6Ip56N xk+0fKYNZv4HAf6ZKYE8P7MuEWOJB8U+x7+lz3a4JwjfMc8XtJSrWPBApR8r9t3wf/bq WImQ==
X-Gm-Message-State: ALoCoQmPXlFZ/ob1cil6FtQGYQDT0DABo/jiW3miwKA68CJQP9I2qN14bR5ZwAZ3TT13YA4qjPkU
MIME-Version: 1.0
X-Received: by 10.220.80.210 with SMTP id u18mr6536466vck.13.1412961058504; Fri, 10 Oct 2014 10:10:58 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Fri, 10 Oct 2014 10:10:58 -0700 (PDT)
In-Reply-To: 
References:  <54348606.7010507@gmail.com>  <5435D586.20806@gmail.com> <20141009004559.44A9E2106591@rock.dv.isc.org> <7E7C5904-3F5B-4B1A-A18D-C5C858B820CD@darou.fr>    
Date: Fri, 10 Oct 2014 10:10:58 -0700
Message-ID: 
From: James Woodyatt 
To: Pierre Pfister , HOMENET Working Group 
Content-Type: multipart/alternative; boundary=047d7b3a85aef956f6050514a149
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/McYbyDLdZkLKWB1R7i2qP9bpLxs
Subject: Re: [homenet] I-D.ietf-homenet-prefix-assignment (RFC 4193 conformance)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 17:12:13 -0000

--047d7b3a85aef956f6050514a149
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This makes me feel a lot better. Thanks.

On Thu, Oct 9, 2014 at 11:50 PM, Pierre Pfister 
wrote:

> Hello Brian and James,
>
> Thanks for the heads up. CANs will be replaced in next version.
>
> So I=E2=80=99m clarifying the two first points in 4.3
>
>    o  It can be delegated by a service provider (DHCPv6 PD, 6rd
>       [RFC5969], etc..).
>
>    o  It can be provisioned by an administrative authority (user
>       configuration, netconf [RFC6241], etc... ).
>
> And changing the last paragraph of the ULA generation section.
>
>    Note as well that this section doesn't prevent multiple ULA prefixes
>    from existing simultaneously.  ULA prefixes may be provided by
>    different means, as specified in Section 4.3.  Delegated prefixes
>    that are delegated by a service provider or provisioned by an
>    authority differ from 'spontaneously' generated prefixes.  They MUST
>    NOT be withdrawn if another ULA delegated prefix is observed.
>
>
> Cheers,
>
> - Pierre
>
>
> Le 9 oct. 2014 =C3=A0 22:49, James Woodyatt  a =C3=A9cr=
it :
>
> On Thu, Oct 9, 2014 at 12:26 PM, Pierre Pfister 
> wrote:
>
>>
>> But I=E2=80=99m going to change it and making it more clear that authori=
ties can
>> provide their own prefixes. Even ULAs.
>>
>
> Thanks! I'm very pleased to see this agreement.
>
>
> --
> james woodyatt 
> Nest Labs, Communications Engineering
>  _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
>
>


--=20
james woodyatt 
Nest Labs, Communications Engineering

--047d7b3a85aef956f6050514a149
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


This makes me feel a lot better. Thanks.

On Thu, Oct 9, 2014 at 11:5=
0 PM, Pierre Pfister <pierre.pfister@darou.fr> wrote:<=
br>
=
Hello Brian and James,

Thanks for the heads up. CA=
Ns will be replaced in next version.

So I=E2=80=99=
m clarifying the two first points in 4.3

=C2=A0 =C2=A0o =C2=A0It can be delegated by a service pr=
ovider (DHCPv6 PD, 6rd
=C2=A0 =C2=
=A0 =C2=A0 [RFC5969], etc..).

<=
/font>
=C2=A0 =C2=A0o =C2=A0It can be prov=
isioned by an administrative authority (user
=C2=A0 =C2=A0 =C2=A0 configuration, netconf [RFC6241], etc... ).<=
/font>

And changing the last paragraph of th=
e ULA generation section.

=C2=A0 =C2=A0Note as well that this secti=
on doesn't prevent multiple ULA prefixes
=C2=A0 =C2=A0from existing simultaneously.=C2=A0 ULA prefixes may=
 be provided by
=C2=A0 =C2=A0differ=
ent means, as specified in Section 4.3.=C2=A0 Delegated prefixes
=C2=A0 =C2=A0that are delegated by a service =
provider or provisioned by an
=C2=
=A0 =C2=A0authority differ from 'spontaneously' generated prefixes.=
=C2=A0 They MUST
=
=C2=A0 =C2=A0NOT be withdrawn if another ULA delegated prefix is observed.<=
/font>

=

Cheers,

- Pierre


Le 9 oct. 2014 =C3=A0 22:49, James Woodyatt <jhw@nestlabs.com> a =C3=
=A9crit :

On Thu, Oct=
 9, 2014 at 12:26 PM, Pierre Pfister <pierre.pfister@darou.fr>=
; wrote:

But I=E2=80=99m going to change it and making it more clea=
r that authorities can provide their own prefixes. Even ULAs.

Thanks! I'm very pleased to see this agreemen=
t.
=C2=A0

-- 
james woody=
att <jhw@nestlabs.=
com>
Nest Labs, Communications Engineering



_______________________________________________
homenet mailing list
=
homenet@ietf.org<=
br>https://www.ietf.org/mailman/listinfo/homenet




-=
- 
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications=
 Engineering




--047d7b3a85aef956f6050514a149--


From nobody Tue Oct 14 00:37:36 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA2F1A6FCF for ; Tue, 14 Oct 2014 00:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.208
X-Spam-Level: 
X-Spam-Status: No, score=-0.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RCVD_IN_SORBS_WEB=0.77] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nnkPEgn1pdk for ; Tue, 14 Oct 2014 00:37:32 -0700 (PDT)
Received: from chi.subsignal.org (cxd-2-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:ed::2]) by ietfa.amsl.com (Postfix) with ESMTP id E32211A6FCD for ; Tue, 14 Oct 2014 00:37:31 -0700 (PDT)
Received: from ccyx-yoga (unknown [62.156.150.204]) by chi.subsignal.org (Postfix) with ESMTPSA id 889A512614F for ; Tue, 14 Oct 2014 09:37:56 +0200 (CEST)
Message-ID: <1413272248.3200.1.camel@openwrt.org>
From: Steven Barth 
To: "homenet@ietf.org Group" 
Date: Tue, 14 Oct 2014 09:37:28 +0200
In-Reply-To: <542EED2F.6000501@openwrt.org>
References: <542EED2F.6000501@openwrt.org>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.12.6-1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/fltAyzdwg-k4IZJhCqpbA0KAR5Q
Subject: Re: [homenet] HNCP Security & Trust Draft
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 07:37:34 -0000

I just pushed a new revision of the draft.
http://tools.ietf.org/html/draft-barth-homenet-hncp-security-trust-01


Most notable changes:

* Some clarifications to the consensus based trust scheme
* PSK-management now supports key-derivation for different protocols
(IGPs, ...)
* Underlying crypto scheme changed to DTLS for now
* Some spellchecking, idnits etc.



Am Freitag, den 03.10.2014, 20:38 +0200 schrieb Steven Barth:
> Hi everyone,
> 
> I took the last few days to gather some thoughts about threats, security 
> and trust management
> in the context of HNCP and wrote it up under 
> http://tools.ietf.org/html/draft-barth-homenet-hncp-security-trust-00
> 
> Quick overview over the topics:
> * Homenet Border
> * HNCP Payload Security
> * Trust Management
> * IGP-Considerations
> 
> Please note that this draft is in a very early stage so please help to 
> make additions, provide feedback
> and point out mistakes.
> 
> 
> Regards,
> 
> Steven
> 
> 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet



From SRS0=uufC=7F=darou.fr=pierre.pfister@bounces.m4x.org  Tue Oct 14 00:44:05 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D8B1A6FCB for ; Tue, 14 Oct 2014 00:44:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.208
X-Spam-Level: 
X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0m3VCf4tJ7h for ; Tue, 14 Oct 2014 00:44:02 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02911A6FC8 for ; Tue, 14 Oct 2014 00:44:02 -0700 (PDT)
Received: from ams3-vpn-dhcp8070.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id C411B1408EFA0 for ; Tue, 14 Oct 2014 09:43:59 +0200 (CEST)
From: Pierre Pfister 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>
Date: Tue, 14 Oct 2014 09:43:59 +0200
To: HOMENET Working Group 
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Tue Oct 14 09:44:00 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/VPugJgc4ikMIJKZ6MLhpdxAhjko
Subject: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 07:44:29 -0000

Hello group,

The architecture document states the following:
- A home network running IPv6 should deploy ULAs alongside its globally =
unique prefix(es) to allow stable communication between devices [...]

This translates into section 9.1 in the Prefix Assignment draft:
- A router MAY spontaneously generate a ULA delegated prefix [...]

So, that MAY should probably be a SHOULD. But the reason for this mail =
is one level higher:

Question: Should the generation of a stable ULA prefix be a MUST in any =
case ?

Advantages would be:
- In the protocol design process, we could assume in-home IPv6 =
connectivity. No need for special case for IPv4-only connectivity, no =
need for special TLVs, flags, or whatever.
- In the implementation process, it is way easier to handle one single =
IP version for all in-home traffic. Let it be IPv6 !
- This connectivity would be more stable than IPv4 (which only exists =
when there is an IPv4 uplink). IPv6 enabled apps would therefore behave =
*better* than IPv4-only. Which would in the end help for transitioning.

Disadvantages are:
- The best (and probably only correct) way of advertising in-home ULA =
connectivity is using RIOs. Which some (e.g. apple's) devices don't =
support (yet?).
- Some currently existing implementation may fail when facing ULA vs =
IPv4 choice.


It looks to me that disadvantages will be overcome in the coming years =
if IETF requires implementation to handle ULAs and RIOs better.

So the question is, should I change the Prefix Assignment draft and make =
ULA existence a MUST so that we/developers can rely on that in our =
protocol design and implementation process ?

Cheers,

Pierre


From nobody Tue Oct 14 01:13:05 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704E11A6FCD for ; Tue, 14 Oct 2014 01:13:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.171
X-Spam-Level: 
X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5EbVVMm8Ou5 for ; Tue, 14 Oct 2014 01:12:58 -0700 (PDT)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7D1E1A6FCB for ; Tue, 14 Oct 2014 01:12:57 -0700 (PDT)
Received: by mail-qg0-f51.google.com with SMTP id z107so7785819qgd.24 for ; Tue, 14 Oct 2014 01:12:57 -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; bh=TuxjpWsOxb3xh574I6bXdRgEax0QzRpnZ4qx7teOMxk=; b=O/pqStV1NazqtDX9oanvQKEQ2PrP1epigS/0D3ejKSIjBlUSWskxD1vhUIFlhEtMlh H1Wdlt5f17qqSUcqUK+qCDyw+37+LWFFOD4rXpxUI2NVxxsQnk6bK33Iazzc23xDfgxA T5E+hHjrKbzzhZ9HleUIadIvcveXML8lBP33iuaBDHGXxZ3y0jE65sLAR1VXc1T0sAxR w7MNL2iT0PiVES7n+BcJHqcPYZ8IEpSP+LxSFSUDPCU359P6qQlg8tona9vG7i3vw0YE lE6twxjTIuE5fkrU6YbZO91gic5BzcOtjN8+OusfnDDMXiv4m6qb1X3+4IdCn/ZK2Bzs SWEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TuxjpWsOxb3xh574I6bXdRgEax0QzRpnZ4qx7teOMxk=; b=SxZb57Nqy5TD97cY/4eEjQ8FVfm1nRGVkj/9aBXUk2TWmfC2RxmaU0nYuLBv9TyiGu B+xgaUKlY718PDBwLR2ZHF1q/6K1+e1BEUpKpXVEer+VfOrxptOKSI8aeONtFyvOxzTo hAd3gMpONXnwueWBrR3H+0n01J4uM464MwaGmDLrgLn9SPVuZpcRkY8ZCzvpbJRJ1/GU 4NPraSy2fkRAAA97h6+g1FMXh9b/n1yp42qPRUPCc7syEnRJTfALSMKBymwG3umJ1UwF DAACwiUO3JU/l7UVOmts8+nMLiawMI3exeILHzX5Tz7H8IeF/rPScERoIG86fOHCwTK2 4l8g==
X-Gm-Message-State: ALoCoQmankwLRsw+Iu4Vlg6qKJK26DPfTkeqlu+QemPCj2UqXVcyYudC1+soZe7S0ebV4/eIDIch
X-Received: by 10.140.40.227 with SMTP id x90mr5379958qgx.69.1413274376915; Tue, 14 Oct 2014 01:12:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.235.135 with HTTP; Tue, 14 Oct 2014 01:12:36 -0700 (PDT)
In-Reply-To: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>
From: Erik Kline 
Date: Tue, 14 Oct 2014 17:12:36 +0900
Message-ID: 
To: Pierre Pfister 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/wd2IWf-egW_KFXtrjbZ2zjqoMNk
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 08:13:00 -0000

I vote no, please don't make it MUST.

Among other things, if my home edge router losing it's upstream it (in
theory) doesn't have to deprecate the global prefix in the home, just
the default route.  Since I can't get to the Internet anyway, all I
need is (almost) any prefix, and the one I have is as good as a ULA
(if not better, since the upstream loss may just be a flap).

On Tue, Oct 14, 2014 at 4:43 PM, Pierre Pfister  wrote:
> Hello group,
>
> The architecture document states the following:
> - A home network running IPv6 should deploy ULAs alongside its globally unique prefix(es) to allow stable communication between devices [...]
>
> This translates into section 9.1 in the Prefix Assignment draft:
> - A router MAY spontaneously generate a ULA delegated prefix [...]
>
> So, that MAY should probably be a SHOULD. But the reason for this mail is one level higher:
>
> Question: Should the generation of a stable ULA prefix be a MUST in any case ?
>
> Advantages would be:
> - In the protocol design process, we could assume in-home IPv6 connectivity. No need for special case for IPv4-only connectivity, no need for special TLVs, flags, or whatever.
> - In the implementation process, it is way easier to handle one single IP version for all in-home traffic. Let it be IPv6 !
> - This connectivity would be more stable than IPv4 (which only exists when there is an IPv4 uplink). IPv6 enabled apps would therefore behave *better* than IPv4-only. Which would in the end help for transitioning.
>
> Disadvantages are:
> - The best (and probably only correct) way of advertising in-home ULA connectivity is using RIOs. Which some (e.g. apple's) devices don't support (yet?).
> - Some currently existing implementation may fail when facing ULA vs IPv4 choice.
>
>
> It looks to me that disadvantages will be overcome in the coming years if IETF requires implementation to handle ULAs and RIOs better.
>
> So the question is, should I change the Prefix Assignment draft and make ULA existence a MUST so that we/developers can rely on that in our protocol design and implementation process ?
>
> Cheers,
>
> Pierre
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From nobody Tue Oct 14 01:21:19 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41ABF1A6FCF for ; Tue, 14 Oct 2014 01:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.229
X-Spam-Level: 
X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, PLING_QUERY=0.994, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uuj68Cm_AwtF for ; Tue, 14 Oct 2014 01:21:14 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E701A6FD7 for ; Tue, 14 Oct 2014 01:21:14 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id EA3FBA1; Tue, 14 Oct 2014 10:21:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1413274871; bh=X3q4ySTV3G1N4wRlW525KTXf6jtf9xIy9KE7TgZRMwg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=CReQVh5lBP3nc102zAukzrquADuarjzO3cZRDLK8pOa7c+s0u66v6ErG6cc5AsjIo UETHVwFI8r5lHcDVPC5zo4OxksX4FD35kl32mJc69uBAzSoBWmAB3IyRd9GFVn1jdv JjvluTAbfsb7m7svi4r//7bni2ulW84UYKTnZKiE=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DEE8A9F; Tue, 14 Oct 2014 10:21:11 +0200 (CEST)
Date: Tue, 14 Oct 2014 10:21:11 +0200 (CEST)
From: Mikael Abrahamsson 
To: Erik Kline 
In-Reply-To: 
Message-ID: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr> 
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/9OOETpikCcZ8sQgafX5Xh96wz08
Cc: HOMENET Working Group , Pierre Pfister 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 08:21:16 -0000

On Tue, 14 Oct 2014, Erik Kline wrote:

> I vote no, please don't make it MUST.

I agree, ULA should be optional, not MUST.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Tue Oct 14 01:25:09 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6C51A6FD1 for ; Tue, 14 Oct 2014 01:25:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.387
X-Spam-Level: *
X-Spam-Status: No, score=1.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_NEUTRAL=0.779, URIBL_RHS_DOB=1.514] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIZBhthV9-sO for ; Tue, 14 Oct 2014 01:25:03 -0700 (PDT)
Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.197]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2951A6FCD for ; Tue, 14 Oct 2014 01:25:03 -0700 (PDT)
Received: from poro.lan (80.220.64.126) by jenni1.inet.fi (8.5.142.08) (authenticated as stenma-47) id 5419499102516763; Tue, 14 Oct 2014 11:24:58 +0300
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Markus Stenberg 
In-Reply-To: 
Date: Tue, 14 Oct 2014 11:24:57 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>  
To: Mikael Abrahamsson 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/yQ2_iOgm3wwVIdUyFLYL_9PTtIo
Cc: Erik Kline , HOMENET Working Group , Markus Stenberg , Pierre Pfister 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 08:25:06 -0000

On 14.10.2014, at 11.21, Mikael Abrahamsson  wrote:
> On Tue, 14 Oct 2014, Erik Kline wrote:
>> I vote no, please don't make it MUST.
> I agree, ULA should be optional, not MUST.

If we live in the land where we ignore existing broken implementations..

=46rom my point of view, it should be SHOULD _always_ generate ULA (so =
that privacy oriented things in a home have a sane default without need =
for trusting firewalling), and MUST generate if no GUA around.

Keeping GUA around as long as it has valid lease lifetime is fine too, =
of course.

Cheers,

-Markus=


From nobody Tue Oct 14 01:25:48 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559D41A6FDA for ; Tue, 14 Oct 2014 01:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.693
X-Spam-Level: 
X-Spam-Status: No, score=-6.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6W2goXt3xzBf for ; Tue, 14 Oct 2014 01:25:45 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D81C31A6FCD for ; Tue, 14 Oct 2014 01:25:44 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 243861FCB5C; Tue, 14 Oct 2014 08:25:42 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3AFF7160056; Tue, 14 Oct 2014 08:28:45 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 08440160053; Tue, 14 Oct 2014 08:28:45 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 1259921690CB; Tue, 14 Oct 2014 19:25:39 +1100 (EST)
To: Erik Kline 
From: Mark Andrews 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr> 
In-reply-to: Your message of "Tue, 14 Oct 2014 17:12:36 +0900." 
Date: Tue, 14 Oct 2014 19:25:39 +1100
Message-Id: <20141014082539.1259921690CB@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/w0bsiMaappg0HPBb2jsvq3Dl0mA
Cc: HOMENET Working Group , Pierre Pfister 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 08:25:46 -0000

In message , Erik Kline writes:
> I vote no, please don't make it MUST.
> 
> Among other things, if my home edge router losing it's upstream it (in
> theory) doesn't have to deprecate the global prefix in the home, just
> the default route.  Since I can't get to the Internet anyway, all I
> need is (almost) any prefix, and the one I have is as good as a ULA
> (if not better, since the upstream loss may just be a flap).

Deprecating the prefix doesn't make it unusable.   However by not
having a ULA prefix already you have the problem about when to
instantiate a ULA prefix.  You shouldn't be using a prefix beyond
the time it is delegated to you.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


From nobody Tue Oct 14 01:53:20 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1B41A00F0 for ; Tue, 14 Oct 2014 01:53:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.907
X-Spam-Level: 
X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUc8iHlTgtei for ; Tue, 14 Oct 2014 01:53:15 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0715.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:715]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893021A0035 for ; Tue, 14 Oct 2014 01:53:15 -0700 (PDT)
Received: from BN1PR0201MB0675.namprd02.prod.outlook.com (25.160.169.151) by BN1PR0201MB0562.namprd02.prod.outlook.com (25.160.169.143) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 08:52:52 +0000
Received: from BN1PR0201MB0674.namprd02.prod.outlook.com (25.160.169.150) by BN1PR0201MB0675.namprd02.prod.outlook.com (25.160.169.151) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 08:52:51 +0000
Received: from BN1PR0201MB0674.namprd02.prod.outlook.com ([25.160.169.150]) by BN1PR0201MB0674.namprd02.prod.outlook.com ([25.160.169.150]) with mapi id 15.00.1049.012; Tue, 14 Oct 2014 08:52:51 +0000
From: Wuyts Carl 
To: Erik Kline , Pierre Pfister 
Thread-Topic: [homenet] Let's make in-home ULA presence a MUST !?
Thread-Index: AQHP54K0vE/OjWpAb0mPoL0zPh7VxpwvPjQAgAAK7TA=
Date: Tue, 14 Oct 2014 08:52:51 +0000
Message-ID: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [95.172.74.66]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR0201MB0675;UriScan:;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 03648EFF89
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(24454002)(189002)(52314003)(13464003)(377454003)(51704005)(64706001)(74316001)(76176999)(54356999)(20776003)(46102003)(76482002)(66066001)(101416001)(85852003)(76576001)(99286002)(50986999)(85306004)(77096002)(99396003)(95666004)(31966008)(15975445006)(120916001)(105586002)(4396001)(21056001)(107046002)(40100003)(108616004)(19580395003)(33646002)(19580405001)(80022003)(92566001)(86362001)(106356001)(106116001)(2656002)(87936001)(122556002)(97736003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0201MB0675; H:BN1PR0201MB0674.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR0201MB0562;
X-OriginatorOrg: technicolor.com
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/36t9Hj9G87O-I56P7SY1ZmpnpSY
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 08:53:17 -0000

+1. Looking to what customers asks these days from CPE devices in IPv6 env,=
 we should not start pushing ULA as MUST req.  It can be an option of cours=
e.

Regs
Carl


-----Original Message-----
From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of Erik Kline
Sent: dinsdag 14 oktober 2014 10:13
To: Pierre Pfister
Cc: HOMENET Working Group
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?

I vote no, please don't make it MUST.

Among other things, if my home edge router losing it's upstream it (in
theory) doesn't have to deprecate the global prefix in the home, just the d=
efault route.  Since I can't get to the Internet anyway, all I need is (alm=
ost) any prefix, and the one I have is as good as a ULA (if not better, sin=
ce the upstream loss may just be a flap).

On Tue, Oct 14, 2014 at 4:43 PM, Pierre Pfister  w=
rote:
> Hello group,
>
> The architecture document states the following:
> - A home network running IPv6 should deploy ULAs alongside its=20
> globally unique prefix(es) to allow stable communication between=20
> devices [...]
>
> This translates into section 9.1 in the Prefix Assignment draft:
> - A router MAY spontaneously generate a ULA delegated prefix [...]
>
> So, that MAY should probably be a SHOULD. But the reason for this mail is=
 one level higher:
>
> Question: Should the generation of a stable ULA prefix be a MUST in any c=
ase ?
>
> Advantages would be:
> - In the protocol design process, we could assume in-home IPv6 connectivi=
ty. No need for special case for IPv4-only connectivity, no need for specia=
l TLVs, flags, or whatever.
> - In the implementation process, it is way easier to handle one single IP=
 version for all in-home traffic. Let it be IPv6 !
> - This connectivity would be more stable than IPv4 (which only exists whe=
n there is an IPv4 uplink). IPv6 enabled apps would therefore behave *bette=
r* than IPv4-only. Which would in the end help for transitioning.
>
> Disadvantages are:
> - The best (and probably only correct) way of advertising in-home ULA con=
nectivity is using RIOs. Which some (e.g. apple's) devices don't support (y=
et?).
> - Some currently existing implementation may fail when facing ULA vs IPv4=
 choice.
>
>
> It looks to me that disadvantages will be overcome in the coming years if=
 IETF requires implementation to handle ULAs and RIOs better.
>
> So the question is, should I change the Prefix Assignment draft and make =
ULA existence a MUST so that we/developers can rely on that in our protocol=
 design and implementation process ?
>
> Cheers,
>
> Pierre
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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


From nobody Tue Oct 14 02:33:33 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2244A1A6FF6 for ; Tue, 14 Oct 2014 02:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.694
X-Spam-Level: 
X-Spam-Status: No, score=-1.694 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjFr1nmVshdl for ; Tue, 14 Oct 2014 02:33:28 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C11E1A6FEC for ; Tue, 14 Oct 2014 02:33:28 -0700 (PDT)
Received: from ams3-vpn-dhcp8070.cisco.com (173-38-208-170.cisco.com [173.38.208.170]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 45750140A915E; Tue, 14 Oct 2014 11:33:21 +0200 (CEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Pierre Pfister 
In-Reply-To: 
Date: Tue, 14 Oct 2014 11:33:20 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5846C516-121C-4441-A8D8-62A77C6499D7@darou.fr>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   
To: Markus Stenberg 
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Tue Oct 14 11:33:24 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/x7sdabc8-8OxiYXNFETsoMw_Vps
Cc: Erik Kline , HOMENET Working Group , Mikael Abrahamsson 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 09:33:31 -0000

Looks like a good default policy to me.
So there always is at least one IPv6 prefix (if not a GUA, generate a =
ULA).

It still provides always-on IPv6 connectivity. And would therefore =
simplify protocol design and implementation.

Does it seems like a better compromise to you (Mikael, Erik, Wuyts) ?

- Pierre

Le 14 oct. 2014 =E0 10:24, Markus Stenberg  a =
=E9crit :

> On 14.10.2014, at 11.21, Mikael Abrahamsson  wrote:
>> On Tue, 14 Oct 2014, Erik Kline wrote:
>>> I vote no, please don't make it MUST.
>> I agree, ULA should be optional, not MUST.
>=20
> If we live in the land where we ignore existing broken =
implementations..
>=20
> =46rom my point of view, it should be SHOULD _always_ generate ULA (so =
that privacy oriented things in a home have a sane default without need =
for trusting firewalling), and MUST generate if no GUA around.
>=20
> Keeping GUA around as long as it has valid lease lifetime is fine too, =
of course.
>=20
> Cheers,
>=20
> -Markus
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From nobody Tue Oct 14 03:14:43 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2921A7032 for ; Tue, 14 Oct 2014 03:14:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.229
X-Spam-Level: 
X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, PLING_QUERY=0.994, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wslaBL5yovIP for ; Tue, 14 Oct 2014 03:14:37 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76E891A702A for ; Tue, 14 Oct 2014 03:14:37 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id E3F7EA1; Tue, 14 Oct 2014 12:14:35 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1413281675; bh=z7WfXU8rdmGlkgLExn5uqnqvAWa2PF0tT6JlUWo68bw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=SwCzt6qWCkHZQYe0J72BL3tJWWLTz5BBSI/oBuwWzfYYzufW5utoOdM9ySD1vpcJq FTTjU6N7HZFyJfl5A+TIco1lI0O97YJz15dAhq2qRUegpf3THbC9gAPYNTUhxWTL2/ 7++ch2/ndQo7oFv8BWcmhDF2rDjt2fNbY5do+j9M=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DD4B49F; Tue, 14 Oct 2014 12:14:35 +0200 (CEST)
Date: Tue, 14 Oct 2014 12:14:35 +0200 (CEST)
From: Mikael Abrahamsson 
To: Pierre Pfister 
In-Reply-To: <5846C516-121C-4441-A8D8-62A77C6499D7@darou.fr>
Message-ID: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>    <5846C516-121C-4441-A8D8-62A77C6499D7@darou.fr>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/hzwv6XA5xuyQ5Te2x-2kKWU4_iU
Cc: Erik Kline , HOMENET Working Group , Markus Stenberg 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 10:14:40 -0000

On Tue, 14 Oct 2014, Pierre Pfister wrote:

> Looks like a good default policy to me.
> So there always is at least one IPv6 prefix (if not a GUA, generate a ULA).
>
> It still provides always-on IPv6 connectivity. And would therefore simplify protocol design and implementation.
>
> Does it seems like a better compromise to you (Mikael, Erik, Wuyts) ?

I would like to see the following (configurable):

If you have GUA, don't use ULA.
When last GUA lease expires, just keep this GUA until something else shows 
up, then deprecate and move away from it.

I would really prefer to have RIO so host doesn't see default route using 
this GUA with no connectivity.

My rationale for this is to avoid to have GUA expire and popping up ULA, 
and then deprecating ULA again when GUA shows up.

Advantage of deprecating GUA as soon as outside connectivity goes away is 
that using 0 lifetime RAs for this prefix when there is no outside 
connectivity and popping up ULA, means RFC6724 hosts will do the right 
thing.

I'm conflicted as to what the correct behaviour is. RFC3484 hosts probably 
doesn't support RIO either, so we're screwed either way.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Tue Oct 14 03:16:56 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30E91A701E for ; Tue, 14 Oct 2014 03:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.606
X-Spam-Level: 
X-Spam-Status: No, score=0.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k27hux39Tn6 for ; Tue, 14 Oct 2014 03:16:53 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0702.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:702]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58DC11A702A for ; Tue, 14 Oct 2014 03:16:53 -0700 (PDT)
Received: from BN1PR0201MB0674.namprd02.prod.outlook.com (25.160.169.150) by BN1PR0201MB0676.namprd02.prod.outlook.com (25.160.169.152) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 10:16:30 +0000
Received: from BN1PR0201MB0674.namprd02.prod.outlook.com ([25.160.169.150]) by BN1PR0201MB0674.namprd02.prod.outlook.com ([25.160.169.150]) with mapi id 15.00.1049.012; Tue, 14 Oct 2014 10:16:30 +0000
From: Wuyts Carl 
To: Pierre Pfister , Markus Stenberg 
Thread-Topic: [homenet] Let's make in-home ULA presence a MUST !?
Thread-Index: AQHP54K0vE/OjWpAb0mPoL0zPh7VxpwvPjQAgAACZoCAAAENgIAAExsAgAAIOSA=
Date: Tue, 14 Oct 2014 10:16:30 +0000
Message-ID: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>    <5846C516-121C-4441-A8D8-62A77C6499D7@darou.fr>
In-Reply-To: <5846C516-121C-4441-A8D8-62A77C6499D7@darou.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [95.172.74.66]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR0201MB0676;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 03648EFF89
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(199003)(189002)(51704005)(76482002)(93886004)(85306004)(66066001)(20776003)(64706001)(97736003)(122556002)(108616004)(80022003)(46102003)(76576001)(21056001)(106356001)(120916001)(4396001)(2656002)(85852003)(19580405001)(105586002)(107046002)(87936001)(40100003)(15975445006)(74316001)(31966008)(33646002)(101416001)(566174002)(92566001)(19580395003)(106116001)(86362001)(95666004)(99286002)(99396003)(77096002)(50986999)(54356999)(76176999)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0201MB0676; H:BN1PR0201MB0674.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: technicolor.com
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Uh4gbxUoOBquTmLrNGLVIjfXf9s
Cc: Erik Kline , HOMENET Working Group , Mikael Abrahamsson 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 10:16:55 -0000

Hi,

Our operational mode is "managed CPE".  We can recommend our customer to us=
e a certain approach, i.e. e.g. use ULA/do not use ULA.  So in that sense, =
creating a ULA if no GUA is present is not an option, as it will be present=
 or not, no matter GUA delivered or not.  Of course, if it is enabled, this=
 would be ok for the below.  But not every customer wants ULA.  It increase=
s complexity for them, they can do as such nearly all without it, so go for=
 an option without it.

So, either the customer has chosen to use ULA or not.  So, let's assume we =
would adapt this, and all of a sudden bring on ULA's on the customer's CPEs=
, he would for sure not be too happy about it, as he might start getting Q'=
s on his helpdesk.
It is of course always open to discussion with a customer, but putting some=
 rules in place like "enable ULA on an intf is no other prefix is there" is=
 typically not an option.

Moreover, keep in mind that the operator can, at any time, switch of IPv6 o=
n/off (upto  interface level) breaking this possibility for whatever reason=
 (through TR-069).  Of course, this would "break" homenet stuff :-(.  Also =
the opposite is in place, i.e enable ULA remotely, but same principle appli=
es here: either the ISP goes got ULA or not.

Regs
Carl


-----Original Message-----
From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of Pierre Pfister
Sent: dinsdag 14 oktober 2014 11:33
To: Markus Stenberg
Cc: Erik Kline; HOMENET Working Group; Mikael Abrahamsson
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?

Looks like a good default policy to me.
So there always is at least one IPv6 prefix (if not a GUA, generate a ULA).

It still provides always-on IPv6 connectivity. And would therefore simplify=
 protocol design and implementation.

Does it seems like a better compromise to you (Mikael, Erik, Wuyts) ?

- Pierre

Le 14 oct. 2014 =E0 10:24, Markus Stenberg  a =E9cr=
it :

> On 14.10.2014, at 11.21, Mikael Abrahamsson  wrote:
>> On Tue, 14 Oct 2014, Erik Kline wrote:
>>> I vote no, please don't make it MUST.
>> I agree, ULA should be optional, not MUST.
>=20
> If we live in the land where we ignore existing broken implementations..
>=20
> From my point of view, it should be SHOULD _always_ generate ULA (so that=
 privacy oriented things in a home have a sane default without need for tru=
sting firewalling), and MUST generate if no GUA around.
>=20
> Keeping GUA around as long as it has valid lease lifetime is fine too, of=
 course.
>=20
> Cheers,
>=20
> -Markus
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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


From nobody Tue Oct 14 03:48:46 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5111A7D84 for ; Tue, 14 Oct 2014 03:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.508
X-Spam-Level: 
X-Spam-Status: No, score=0.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOneyjrK0VZZ for ; Tue, 14 Oct 2014 03:48:43 -0700 (PDT)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06BE61A6FD6 for ; Tue, 14 Oct 2014 03:48:42 -0700 (PDT)
Received: by mail-lb0-f170.google.com with SMTP id u10so8019526lbd.1 for ; Tue, 14 Oct 2014 03:48:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PPeHJnTeMt/P5QwFS1/NRslNMaVqqnd2fjHSA07u6WI=; b=cQDoqUI/LikcjzUeO9Pl5mSb58JKhEhMh/3Eipkj2/McRFLGGiQ/7Pr4X5RU2Am/nk qC8Vh5oGIvW5arwvRd0WZF1/QvKKYOopiYLjaL6Nl1cvWCT0DrVuAZ6InqBaz+8YBeCr Am67sDjGRD55xADVzZJkcmFOePXxCRQt20cRjXxDxSkl66/z7tIq4E/Ml0LS5kNcPOUk 1rW/LMZMr117NXziV/4NJT/v7J0QG/H8kKOQv6I1lGZeyVUXivxW48lPn5SFYpTyPENf 8+A4hzl34oX2oNC2EMsLv0TKbvphk4avTotaVDYjqosWIFrwRm1tNJoXCaHTcYJ4EVh0 aPIw==
X-Received: by 10.152.20.98 with SMTP id m2mr4481069lae.59.1413283721021; Tue, 14 Oct 2014 03:48:41 -0700 (PDT)
Received: from ?IPv6:2001:1bc8:101:f101:5d7f:21c4:af42:225c? ([2001:1bc8:101:f101:5d7f:21c4:af42:225c]) by mx.google.com with ESMTPSA id r1sm1040459lae.25.2014.10.14.03.48.39 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Oct 2014 03:48:40 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Jouni 
In-Reply-To: 
Date: Tue, 14 Oct 2014 13:48:37 +0300
Content-Transfer-Encoding: 7bit
Message-Id: <870AF1AD-6E43-4ACF-A7E8-1FD28DD40446@gmail.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>  
To: Mikael Abrahamsson 
X-Mailer: Apple Mail (2.1283)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/MSveDAlgKuzLUQ_4B0aO7-7CB1c
Cc: Erik Kline , HOMENET Working Group , Pierre Pfister 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 10:48:44 -0000

+1 as well. 

- Jouni

On Oct 14, 2014, at 11:21 AM, Mikael Abrahamsson wrote:

> On Tue, 14 Oct 2014, Erik Kline wrote:
> 
>> I vote no, please don't make it MUST.
> 
> I agree, ULA should be optional, not MUST.
> 
> -- 
> Mikael Abrahamsson    email: swmike@swm.pp.se
> 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From nobody Tue Oct 14 06:44:11 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC51C1A8779 for ; Tue, 14 Oct 2014 06:44:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level: 
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiWh-nXWk7_H for ; Tue, 14 Oct 2014 06:44:06 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A68131A8704 for ; Tue, 14 Oct 2014 06:44:06 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id AA4DE2380423; Tue, 14 Oct 2014 09:44:05 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Tue, 14 Oct 2014 08:44:03 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr> 
To: Erik Kline 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/K68os8uGra-Pjhz1ZHbUy2Cs6Hs
Cc: HOMENET Working Group , Pierre Pfister 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 13:44:08 -0000

On Oct 14, 2014, at 3:12 AM, Erik Kline  wrote:
> Among other things, if my home edge router losing it's upstream it (in
> theory) doesn't have to deprecate the global prefix in the home, just
> the default route.  Since I can't get to the Internet anyway, all I
> need is (almost) any prefix, and the one I have is as good as a ULA
> (if not better, since the upstream loss may just be a flap).

This is something we discussed at length back when we were doing the =
architecture document.   The problem with this approach is that it =
exposes you to flash renumbering when you get back online, or if you =
can't do flash renumbering, you could easily find yourself without =
connectivity because you are using the wrong source address.   =
Deprecating the global address when upstream connectivity goes away, and =
preferring the ULA for local communication, addresses this problem.   So =
I think that we need to have a really clear argument _against_ using =
ULAs to solve this problem in order for what you are saying to be true, =
and I don't remember that being an outcome of the previous discussion.

So while I am not sure I agree with Pierre's conclusion, I think his =
reasoning is pretty sound.


From nobody Tue Oct 14 07:27:57 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6472B1A8791 for ; Tue, 14 Oct 2014 07:27:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.692
X-Spam-Level: 
X-Spam-Status: No, score=-1.692 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKJsUXhBFthL for ; Tue, 14 Oct 2014 07:27:52 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0F261A8890 for ; Tue, 14 Oct 2014 07:27:48 -0700 (PDT)
X-Original-To: homenet@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 8FA2A6079A for ; Tue, 14 Oct 2014 16:27:46 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 50C6F6012B for ; Tue, 14 Oct 2014 16:27:46 +0200 (CEST)
Received: (qmail 12606 invoked by uid 1007); 14 Oct 2014 16:27:46 +0200
Date: Tue, 14 Oct 2014 16:27:46 +0200
From: Gert Doering 
To: Ted Lemon 
Message-ID: <20141014142746.GX31092@Space.Net>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/b19IK3zkkQwbG22eu-zZvy2FD8w
Cc: Erik Kline , HOMENET Working Group , Pierre Pfister 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 14:27:55 -0000

Hi,

On Tue, Oct 14, 2014 at 08:44:03AM -0500, Ted Lemon wrote:
> This is something we discussed at length back when we were doing
> the architecture document.   The problem with this approach is that
> it exposes you to flash renumbering when you get back online, or
> if you can't do flash renumbering, you could easily find yourself
> without connectivity because you are using the wrong source address.

"flash renumber is a problem" is pretty much a non-argument, as flash 
renumbering *will* happen, and devices in the home *will* have to handle it.

Carriers do it today - "here's a new /56, have fun", without even having
to reconnect.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279


From nobody Tue Oct 14 07:42:01 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF2B1A88C5 for ; Tue, 14 Oct 2014 07:41:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level: 
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNpiGqW_wWLs for ; Tue, 14 Oct 2014 07:41:58 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id D96BA1A87B2 for ; Tue, 14 Oct 2014 07:41:58 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 940572380423; Tue, 14 Oct 2014 10:41:57 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <20141014142746.GX31092@Space.Net>
Date: Tue, 14 Oct 2014 09:41:55 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net>
To: Gert Doering 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ssybVZT3Xd_SykRz0V4PLyWgZck
Cc: Erik Kline , HOMENET Working Group , Pierre Pfister 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 14:42:00 -0000

On Oct 14, 2014, at 9:27 AM, Gert Doering  wrote:
> "flash renumber is a problem" is pretty much a non-argument, as flash=20=

> renumbering *will* happen, and devices in the home *will* have to =
handle it.

Indeed.   The question is, should we increase the number of instances in =
which they are forced to handle it, or no?

> Carriers do it today - "here's a new /56, have fun", without even =
having
> to reconnect.

If this generates phone calls, they may change their minds.   It's early =
days yet.


From nobody Tue Oct 14 08:00:04 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394F21A88DC for ; Tue, 14 Oct 2014 07:59:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.692
X-Spam-Level: 
X-Spam-Status: No, score=-1.692 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZZmLEy5K4aX for ; Tue, 14 Oct 2014 07:59:56 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973781A8907 for ; Tue, 14 Oct 2014 07:59:31 -0700 (PDT)
X-Original-To: homenet@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 7137E60797 for ; Tue, 14 Oct 2014 16:59:30 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 37CED60765 for ; Tue, 14 Oct 2014 16:59:30 +0200 (CEST)
Received: (qmail 16318 invoked by uid 1007); 14 Oct 2014 16:59:30 +0200
Date: Tue, 14 Oct 2014 16:59:30 +0200
From: Gert Doering 
To: Ted Lemon 
Message-ID: <20141014145930.GY31092@Space.Net>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NHoqzdq0v3ncJ6I2"
Content-Disposition: inline
In-Reply-To: <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/MsE0VIY8LSgAH7jepLiIMn91yvs
Cc: Erik Kline , HOMENET Working Group , Pierre Pfister , Gert Doering 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 14:59:58 -0000

--NHoqzdq0v3ncJ6I2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Oct 14, 2014 at 09:41:55AM -0500, Ted Lemon wrote:
> On Oct 14, 2014, at 9:27 AM, Gert Doering  wrote:
> > "flash renumber is a problem" is pretty much a non-argument, as flash=
=20
> > renumbering *will* happen, and devices in the home *will* have to handl=
e it.
>=20
> Indeed.   The question is, should we increase the number of instances in =
which they are forced to handle it, or no?

Yes.

Because this is the only way that application developers will learn to
handle it.

(When I first learned that T-Online was forcing this on their customers,
I was quite upset.  After thinking about it for a few weeks, I came to the
conclusion that it's the inevitable and correct approach.  If you make
the homenet renumber only "every few months", like "when the router is
offline for longer than  hours", people and application developers
will start assuming that IPv6 addresses are something static - and then,
when that renumbering happens, you'll get uproar and support calls. =20
Force a prefix change on homenets once a week, and developers will learn=20
how to cope with it, without breaking every time, requiring application /=
=20
appliance restarts, etc)

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--NHoqzdq0v3ncJ6I2
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVD06Ud9WwGXkzn/FAQLr3g/+Nq3KnM0cc95QnzXr3A8lcvI9PZHhLnbM
5u/Q+BKn+cHEfHKPi1ilAgacyvvVBPbIev+H1EtR7V6abDfMrVyy99LWWAL0M3hV
hI5Q86LydLf0Lcxaq74fG4eIPYmO3NQJmfQSOq27u0sWfy3+LnCDFw62iTqSK3xo
hxM5p4Iwwa7y9xjnAxD4+PztvAvlDdS+4BTDly4Wz1c14eCByNEYALwJaYWhP3JD
LVQYz+h6Y89VcoM5aFftntLGldP4wIZCoU2KGz9tUvhmqF0v5o5b0Ezj1kC4T5Ud
qqf4syAWPt8+xXsPT5s63RgvHB/wX963upCFDYTDXE3jhbtK6ve71kVy7Mnf5/sw
9FbC5CEvFYedcPMRRy6ijIkNoP5S4EYIYjq7edT4gClmJfvKpMMrSr+IfFCgIpSl
v69YYRId3K5nnI5Gkv/3lhDbTrsKC0+Hyd069bbyN24nSoi26QyM9g6hb3Egg3eb
ao74FgDNKtnVuSEzRseBBSYhgZGHECskJXMqyvbXPsJZtDypeRCb2OWuneQ2EeBd
V2sAq54QdP8WEUmv6ecn677CP2pWt6YBWAGMRvfMbxK82UQf9DwDEQj1x8fS8+GO
R2tcZ9f0YsxppefNdz3LqzMJ2tC0I4LfgcYf65ckWrnZhCt1+qdOiV1bX8FQG1Ls
ewRrzyq9uB0=
=NLrh
-----END PGP SIGNATURE-----

--NHoqzdq0v3ncJ6I2--


From nobody Tue Oct 14 08:13:48 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1655E1A8924 for ; Tue, 14 Oct 2014 08:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level: 
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3wOmEjP4aT9 for ; Tue, 14 Oct 2014 08:13:38 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 67E971A88EC for ; Tue, 14 Oct 2014 08:13:38 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 190732380423; Tue, 14 Oct 2014 11:13:36 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <20141014145930.GY31092@Space.Net>
Date: Tue, 14 Oct 2014 10:13:34 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>
To: Gert Doering 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/iMWXgWl_O5RdB5wmP0w6cH2u3cw
Cc: Erik Kline , HOMENET Working Group , Pierre Pfister 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 15:13:41 -0000

On Oct 14, 2014, at 9:59 AM, Gert Doering  wrote:
>> Indeed.   The question is, should we increase the number of instances =
in which they are forced to handle it, or no?
>=20
> Because this is the only way that application developers will learn to
> handle it.

Application developers _can't_ handle it.   Applications have no control =
over routing, and making applications do source address selection is a =
really bad idea.

I haven't encountered any ISPs that do flash renumbering, and I'm =
surprised to hear you saying that T-Online is doing it: that's not my =
understanding.   In general, providers that renumber their customers use =
graceful renumbering, not flash renumbering.   There's no reason to do =
flash renumbering.


From nobody Tue Oct 14 08:21:02 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C6B1A88F7 for ; Tue, 14 Oct 2014 08:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.906
X-Spam-Level: 
X-Spam-Status: No, score=-2.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, PLING_QUERY=0.994] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8X5Asxq7CAXs for ; Tue, 14 Oct 2014 08:20:52 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABE11A88F2 for ; Tue, 14 Oct 2014 08:20:52 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1Xe3u7-0000BXC; Tue, 14 Oct 2014 17:20:51 +0200
Message-Id: 
To: Gert Doering 
From: Philip Homburg 
Sender: pch-bBB316E3E@u-1.phicoh.com
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> 
In-reply-to: Your message of "Tue, 14 Oct 2014 16:59:30 +0200 ." <20141014145930.GY31092@Space.Net> 
Date: Tue, 14 Oct 2014 17:20:50 +0200
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/0HDoE6TM0tkkqxA-nreLTXQRSEk
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 15:20:55 -0000

In your letter dated Tue, 14 Oct 2014 16:59:30 +0200 you wrote:
>Because this is the only way that application developers will learn to
>handle it.

I'm happy my ISP doesn't do that. I would probably just use a tunnel instead.

One of the advantages of IPv6 is that it is way easier to run publicly
accessible services at home. You still need to put an address in DNS, but
that's a one time action.

(It would have been nice if there was a way to signal that this prefix is
sort of stable and that home routers would remember that. But I'm not holding
my breath)

Hmm, if changing prefixes is such a great idea, then maybe RIRs should do
the same :-)



From nobody Tue Oct 14 08:21:30 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3EA41A8907 for ; Tue, 14 Oct 2014 08:21:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level: 
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myYNAIklXJ2H for ; Tue, 14 Oct 2014 08:21:15 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 84EA51A88D0 for ; Tue, 14 Oct 2014 08:21:15 -0700 (PDT)
Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 64B4F403B5 for ; Tue, 14 Oct 2014 11:21:14 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: JF Tremblay 
In-Reply-To: <20141014145930.GY31092@Space.Net>
Date: Tue, 14 Oct 2014 11:21:13 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <665DAC61-7846-4E16-B45F-3D4E75F1B85F@viagenie.ca>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>
To: HOMENET Working Group 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Tq8GmBN7HkZAMIb2xGsWyF9nLPA
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 15:21:21 -0000

On Oct 14, 2014, at 10:59 AM, Gert Doering  wrote:
> On Tue, Oct 14, 2014 at 09:41:55AM -0500, Ted Lemon wrote:
>> On Oct 14, 2014, at 9:27 AM, Gert Doering  wrote:
>>> "flash renumber is a problem" is pretty much a non-argument, as =
flash=20
>>> renumbering *will* happen, and devices in the home *will* have to =
handle it.
>>=20
>> Indeed.   The question is, should we increase the number of instances =
in which they are forced to handle it, or no?
>=20
> Yes.
> Because this is the only way that application developers will learn to
> handle it.

+1, renumbering will happen and should be properly handled.=20

A good example here is IPv6 renumbering from docsis domain splits in the =
cable world. In a typical case, a client would see a loss of upstream =
for 5-10 minutes followed with restoration with a new /56 GUA. Although =
techniques are available to limit renumbering during these events, they =
aren=92t always deployed, for practical, technical or political reasons. =
=46rom various discussions between cable operators, the rule of thumb is =
that this would typically happen roughly every 12 months for any single =
residential user. Cable users in areas seeing rapid growth or new =
technology deployments could expect shorter timeframes between =
renumbering events (every 4-6 months for example, or even shorter).    =20=


I like the approach Mikael described earlier. Keep the GUA until it =
expires, then generate a ULA if required, if nothing else exists. =
Keeping the GUA beyond expiration should be avoided IMHO. I=92ve seen =
broken implementations do this and causing a lot of headaches. The =
removal of the old GUA prefix before it=92s expiration is also a problem =
in many implementations, but that=92s probably a battle for another day. =
=20

JF

 =20


From nobody Tue Oct 14 08:29:38 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F00F1A8932 for ; Tue, 14 Oct 2014 08:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.683
X-Spam-Level: 
X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWK46n3X9f0b for ; Tue, 14 Oct 2014 08:29:25 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961581A8946 for ; Tue, 14 Oct 2014 08:29:25 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F2D0E203AB; Tue, 14 Oct 2014 11:29:49 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 039F963B40; Tue, 14 Oct 2014 11:29:22 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DF91363AD5; Tue, 14 Oct 2014 11:29:22 -0400 (EDT)
From: Michael Richardson 
To: Pierre Pfister 
In-Reply-To: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/lKZKaB1J1di8BudnXEULh7zpf3c
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 15:29:28 -0000

--=-=-=


Pierre Pfister  wrote:
    > The architecture document states the following: - A home network
    > running IPv6 should deploy ULAs alongside its globally unique
    > prefix(es) to allow stable communication between devices [...]

Doesn't RFC7084 (6204) already say this?

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBVD1BUICLcPvd0N1lAQKRaAgAiqEf4u2aamIxg7/o4dcC01bHUYcZ069g
ngXNM6+f9syP816p3CVJwav5NCQ0HWXyQmzcfMgIYzqp0x1m/8aMsLqg9HUCio8N
ZpSYg19A04ZJxBbPNY31Xp0Mdg1ReSvmEy7dUErr/uEJzkvpf8RDKuHOPHYpfxc9
95Aa+BLT6dK2z8tYSJd6/01j3u5UHP/CWHlhHfRcxzN6XV1XMLGxEnmlb1Jb4+Xq
ESVOv34Em/lGUlMoLIR5dl4OIxQsZUFNvSeTgdK2qbhaLe9h8ktL2ZOZC/7ohU4A
aUKRpWjX24i2gNwcXgINnWIdTgcQOX8qP9EqWpSFbyuHUE5mI1YHPw==
=OE1j
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Tue Oct 14 08:34:55 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5411A8946 for ; Tue, 14 Oct 2014 08:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level: 
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzRnOXzlVkz4 for ; Tue, 14 Oct 2014 08:34:53 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756851A8791 for ; Tue, 14 Oct 2014 08:34:53 -0700 (PDT)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id s9EFYq55028726 for ; Tue, 14 Oct 2014 08:34:53 -0700
Message-ID: <543D429C.5020302@mtcc.com>
Date: Tue, 14 Oct 2014 08:34:52 -0700
From: Michael Thomas 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: homenet@ietf.org
References: <542EED2F.6000501@openwrt.org> <1413272248.3200.1.camel@openwrt.org>
In-Reply-To: <1413272248.3200.1.camel@openwrt.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/pliIfbqQqJwFtBurGcivBqRoxHE
Subject: Re: [homenet] HNCP Security & Trust Draft
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 15:34:54 -0000

1) i was hopeful that this might be a threats kind of draft which is 
sorely needed. i was disappointed.
2) there is a huge set of possibilities in between PSK and PKI in 
section 6.1 and 6.2. see #1.

Mike


On 10/14/2014 12:37 AM, Steven Barth wrote:
> I just pushed a new revision of the draft.
> http://tools.ietf.org/html/draft-barth-homenet-hncp-security-trust-01
>
>
> Most notable changes:
>
> * Some clarifications to the consensus based trust scheme
> * PSK-management now supports key-derivation for different protocols
> (IGPs, ...)
> * Underlying crypto scheme changed to DTLS for now
> * Some spellchecking, idnits etc.
>
>
>
> Am Freitag, den 03.10.2014, 20:38 +0200 schrieb Steven Barth:
>> Hi everyone,
>>
>> I took the last few days to gather some thoughts about threats, security
>> and trust management
>> in the context of HNCP and wrote it up under
>> http://tools.ietf.org/html/draft-barth-homenet-hncp-security-trust-00
>>
>> Quick overview over the topics:
>> * Homenet Border
>> * HNCP Payload Security
>> * Trust Management
>> * IGP-Considerations
>>
>> Please note that this draft is in a very early stage so please help to
>> make additions, provide feedback
>> and point out mistakes.
>>
>>
>> Regards,
>>
>> Steven
>>
>>
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From nobody Tue Oct 14 08:35:12 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E50B1A894B for ; Tue, 14 Oct 2014 08:35:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.908
X-Spam-Level: 
X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVU9e6cz2-Zq for ; Tue, 14 Oct 2014 08:35:09 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:707]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5C641A8949 for ; Tue, 14 Oct 2014 08:35:09 -0700 (PDT)
Received: from BN1PR0201MB0674.namprd02.prod.outlook.com (25.160.169.150) by BN1PR0201MB0674.namprd02.prod.outlook.com (25.160.169.150) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 15:34:47 +0000
Received: from BN1PR0201MB0674.namprd02.prod.outlook.com ([25.160.169.150]) by BN1PR0201MB0674.namprd02.prod.outlook.com ([25.160.169.150]) with mapi id 15.00.1049.012; Tue, 14 Oct 2014 15:34:47 +0000
From: Wuyts Carl 
To: Gert Doering , Ted Lemon 
Thread-Topic: [homenet] Let's make in-home ULA presence a MUST !?
Thread-Index: AQHP54K0vE/OjWpAb0mPoL0zPh7VxpwvPjQAgABcm4CAAAw3AIAAEo0Q
Date: Tue, 14 Oct 2014 15:34:46 +0000
Message-ID: <343f28c2c9f04db7b82e827307ef95bc@BN1PR0201MB0674.namprd02.prod.outlook.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net>
In-Reply-To: <20141014142746.GX31092@Space.Net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [188.188.67.163]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR0201MB0674;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 03648EFF89
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51404002)(189002)(13464003)(199003)(24454002)(21056001)(50986999)(76482002)(95666004)(99286002)(120916001)(106356001)(93886004)(85306004)(77096002)(107046002)(40100003)(105586002)(106116001)(19580395003)(108616004)(19580405001)(99396003)(87936001)(101416001)(2656002)(74316001)(85852003)(86362001)(122556002)(80022003)(92566001)(46102003)(4396001)(64706001)(97736003)(54356999)(33646002)(15975445006)(76176999)(66066001)(20776003)(31966008)(76576001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0201MB0674; H:BN1PR0201MB0674.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: technicolor.com
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Lrg9fGYTYr-ZFLWrPUQGXbjXyBM
Cc: Erik Kline , HOMENET Working Group , Pierre Pfister 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 15:35:11 -0000

I can confirm that.  We have a customer handing out a new prefix every 4 da=
ys.

Regs
Carl


-----Original Message-----
From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of Gert Doering
Sent: dinsdag 14 oktober 2014 16:28
To: Ted Lemon
Cc: Erik Kline; HOMENET Working Group; Pierre Pfister
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?

Hi,

On Tue, Oct 14, 2014 at 08:44:03AM -0500, Ted Lemon wrote:
> This is something we discussed at length back when we were doing
> the architecture document.   The problem with this approach is that
> it exposes you to flash renumbering when you get back online, or if=20
> you can't do flash renumbering, you could easily find yourself without=20
> connectivity because you are using the wrong source address.

"flash renumber is a problem" is pretty much a non-argument, as flash renum=
bering *will* happen, and devices in the home *will* have to handle it.

Carriers do it today - "here's a new /56, have fun", without even having to=
 reconnect.

Gert Doering
        -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

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


From nobody Tue Oct 14 08:37:24 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744D91A8941 for ; Tue, 14 Oct 2014 08:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.907
X-Spam-Level: 
X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bjhIwI8afEF for ; Tue, 14 Oct 2014 08:37:19 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0775.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:775]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB1B1A8927 for ; Tue, 14 Oct 2014 08:37:19 -0700 (PDT)
Received: from BN1PR0201MB0674.namprd02.prod.outlook.com (25.160.169.150) by BN1PR0201MB0674.namprd02.prod.outlook.com (25.160.169.150) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 15:36:56 +0000
Received: from BN1PR0201MB0674.namprd02.prod.outlook.com ([25.160.169.150]) by BN1PR0201MB0674.namprd02.prod.outlook.com ([25.160.169.150]) with mapi id 15.00.1049.012; Tue, 14 Oct 2014 15:36:56 +0000
From: Wuyts Carl 
To: Ted Lemon , Gert Doering 
Thread-Topic: [homenet] Let's make in-home ULA presence a MUST !?
Thread-Index: AQHP54K0vE/OjWpAb0mPoL0zPh7VxpwvPjQAgABcm4CAAAw3AIAAA/SAgAAO1iA=
Date: Tue, 14 Oct 2014 15:36:56 +0000
Message-ID: <9092f8fc5c7849cba3485896b847466c@BN1PR0201MB0674.namprd02.prod.outlook.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com>
In-Reply-To: <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [188.188.67.163]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR0201MB0674;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 03648EFF89
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51404002)(189002)(13464003)(199003)(24454002)(21056001)(50986999)(76482002)(95666004)(99286002)(120916001)(106356001)(93886004)(85306004)(77096002)(107046002)(40100003)(105586002)(106116001)(19580395003)(108616004)(19580405001)(99396003)(87936001)(101416001)(2656002)(74316001)(85852003)(86362001)(122556002)(80022003)(92566001)(46102003)(4396001)(64706001)(97736003)(54356999)(33646002)(15975445006)(76176999)(66066001)(20776003)(31966008)(76576001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0201MB0674; H:BN1PR0201MB0674.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: technicolor.com
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/N1Y8GjwrypC3HYPahlLrPvW-4-M
Cc: Erik Kline , HOMENET Working Group , Pierre Pfister 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 15:37:21 -0000

Initially, the requested "old" prefix did not get nack'd after the expiry d=
ate, resulting in an "outage" of around 10 seconds, so approx. 10 secs with=
out v6 connectivity.  These days, the old requested / hinted prefix gets na=
cked by the dhcpv6 server, enforcing new state machine cycle.  This works v=
ery well.

Regs
Carl


-----Original Message-----
From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: dinsdag 14 oktober 2014 16:42
To: Gert Doering
Cc: Erik Kline; HOMENET Working Group; Pierre Pfister
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?

On Oct 14, 2014, at 9:27 AM, Gert Doering  wrote:
> "flash renumber is a problem" is pretty much a non-argument, as flash=20
> renumbering *will* happen, and devices in the home *will* have to handle =
it.

Indeed.   The question is, should we increase the number of instances in wh=
ich they are forced to handle it, or no?

> Carriers do it today - "here's a new /56, have fun", without even=20
> having to reconnect.

If this generates phone calls, they may change their minds.   It's early da=
ys yet.

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


From nobody Tue Oct 14 08:39:37 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203431A894D for ; Tue, 14 Oct 2014 08:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.907
X-Spam-Level: 
X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yX3ek6I6A2Q8 for ; Tue, 14 Oct 2014 08:39:34 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0135.outbound.protection.outlook.com [65.55.169.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24261A8949 for ; Tue, 14 Oct 2014 08:39:33 -0700 (PDT)
Received: from BN1PR0201MB0675.namprd02.prod.outlook.com (25.160.169.151) by BN1PR0201MB0723.namprd02.prod.outlook.com (25.160.169.22) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 15:39:32 +0000
Received: from BN1PR0201MB0674.namprd02.prod.outlook.com (25.160.169.150) by BN1PR0201MB0675.namprd02.prod.outlook.com (25.160.169.151) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 15:39:30 +0000
Received: from BN1PR0201MB0674.namprd02.prod.outlook.com ([25.160.169.150]) by BN1PR0201MB0674.namprd02.prod.outlook.com ([25.160.169.150]) with mapi id 15.00.1049.012; Tue, 14 Oct 2014 15:39:30 +0000
From: Wuyts Carl 
To: Michael Richardson , Pierre Pfister 
Thread-Topic: [homenet] Let's make in-home ULA presence a MUST !?
Thread-Index: AQHP54K0vE/OjWpAb0mPoL0zPh7VxpwvuDwAgAACwrA=
Date: Tue, 14 Oct 2014 15:39:29 +0000
Message-ID: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr> <5620.1413300562@sandelman.ca>
In-Reply-To: <5620.1413300562@sandelman.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [188.188.67.163]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR0201MB0675;UriScan:;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 03648EFF89
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(24454002)(199003)(13464003)(108616004)(40100003)(19580395003)(33646002)(99396003)(85306004)(107046002)(105586002)(21056001)(77096002)(4396001)(31966008)(95666004)(120916001)(2656002)(106116001)(106356001)(97736003)(122556002)(87936001)(19580405001)(80022003)(92566001)(86362001)(46102003)(20776003)(85852003)(101416001)(66066001)(76482002)(64706001)(74316001)(54356999)(76176999)(99286002)(76576001)(50986999)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0201MB0675; H:BN1PR0201MB0674.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR0201MB0723;
X-OriginatorOrg: technicolor.com
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/6av-HRKA2n7BBsMsyHlFk5Iq_FA
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 15:39:35 -0000

No:
The IPv6 CE router SHOULD be capable of generating a ULA
           prefix [RFC4193].

SHOULD, not MUST

-----Original Message-----
From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of Michael Richar=
dson
Sent: dinsdag 14 oktober 2014 17:29
To: Pierre Pfister
Cc: HOMENET Working Group
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?


Pierre Pfister  wrote:
    > The architecture document states the following: - A home network
    > running IPv6 should deploy ULAs alongside its globally unique
    > prefix(es) to allow stable communication between devices [...]

Doesn't RFC7084 (6204) already say this?

--
Michael Richardson , Sandelman Software Works  -=3D =
IPv6 IoT consulting =3D-




From nobody Tue Oct 14 08:41:25 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281B01A8949 for ; Tue, 14 Oct 2014 08:41:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.692
X-Spam-Level: 
X-Spam-Status: No, score=-3.692 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CM_M6ofqVpXq for ; Tue, 14 Oct 2014 08:41:21 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 451811A8919 for ; Tue, 14 Oct 2014 08:41:20 -0700 (PDT)
X-Original-To: homenet@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 40DB460785 for ; Tue, 14 Oct 2014 17:41:12 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id F36AD60152 for ; Tue, 14 Oct 2014 17:41:11 +0200 (CEST)
Received: (qmail 21039 invoked by uid 1007); 14 Oct 2014 17:41:11 +0200
Date: Tue, 14 Oct 2014 17:41:11 +0200
From: Gert Doering 
To: Philip Homburg 
Message-ID: <20141014154111.GZ31092@Space.Net>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f8a/qCj1okmCrN1U"
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/VF1VT0e7Ly_GaBhP7NdVAO3FjUU
Cc: HOMENET Working Group , Gert Doering 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 15:41:23 -0000

--f8a/qCj1okmCrN1U
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Oct 14, 2014 at 05:09:42PM +0200, Philip Homburg wrote:
> In your letter dated Tue, 14 Oct 2014 16:59:30 +0200 you wrote:
> >Because this is the only way that application developers will learn to
> >handle it.
>=20
> I'm happy my ISP doesn't do that. I would probably just use a tunnel inst=
ead.
>=20
> One of the advantages of IPv6 is that it is way easier to run publicly
> accessible services at home. You still need to put an address in DNS, but
> that's a one time action.
>=20
> Hmm, if changing prefixes is such a great idea, then maybe RIRs should do
> the same :-)

That reply doesn't surprise me the least, it's the standard answer from
every geek who has not spent a few weeks thinking about this :-)

My mom and dad do not put stuff in DNS.  If at all, their router does, and
*that* one perfectly well knows how to handle changing prefixes, and update
DNS if needed.  It has a menu listing currently active hosts, you pick a
host ID from it, give it a name, and it's published.  (It's not as good
as it could be, as you end up in the vendor's DNS tree and not in a=20
DNS domain of your choice, but it's "running code")

Now, please tell me who is more relevant for *homenet*?  A geek who is=20
stuck in "I want to do this the old way!  I have always done it that way!"
or "a standard mom and dad household"?

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--f8a/qCj1okmCrN1U
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVD1EF99WwGXkzn/FAQIytg/+KHzM+mUFsiJdyWIaTSJ/4EFM/EhtgJGm
oAhyBn3Fe/84aZoscjrVP/Om+XB15dPBTaoE67nr/e5RsUINoVaNxEI9OykrREVi
h3HhGikMbLp1kD1S/FO6awgc2/b2AZVrCSAyBIZbrOl55Id5yhOoJAwYCtXLEQvk
GNl2JJRADsX/TpbgOBN9YW+luwNVM6HXrdWKcGUzCsZkZ+KMrhBm37FnyrvG8kgg
j3xqqsTaNnO67FzriqKB+b6wZG5/vDAMWUquDrmKx+1fPZRgUaurpHyZZwVME0J6
usFYVo/khEBYF9KDvHGEuWjy+pNLEUA6QeyqjhYIb5rAmOtxrkv7lJRFK2OaMADZ
pZ8ZAdxSC4Dcx4yPZQkajIhGNPehsaE6o2AVpK+errAWwNgN55n1U8qyUeYQrL0Z
2pZ1amZEmVgU4YCffRzKchu83sF/TtRV3pfrNE0pCDK7SPIjyXEzuI3YRTgzeVPb
sMdaXYYNXXODxLFfIOZSBmvRwgeCCkSNA5DXUL1gKQGDJ3g0IW4Qw+CY+3FL/0EY
zmFL5zjHxs8erLiPTrisiMC4YDV9IytB9ZOpcPI3obbkLgvq0ouZnUQeVfzxJs0v
O+z2k26L9inBoo/hknWJbUYpP43XCm8nbPD6u9BDTI3abK4clWgJJeLfn/JLlIVq
3D+LeTWgSw0=
=2RFt
-----END PGP SIGNATURE-----

--f8a/qCj1okmCrN1U--


From nobody Tue Oct 14 08:46:12 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248E21A8944 for ; Tue, 14 Oct 2014 08:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.692
X-Spam-Level: 
X-Spam-Status: No, score=-1.692 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WN1jTR_2rOMZ for ; Tue, 14 Oct 2014 08:46:08 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3F21A892C for ; Tue, 14 Oct 2014 08:46:08 -0700 (PDT)
X-Original-To: homenet@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 33A2260792 for ; Tue, 14 Oct 2014 17:46:07 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id E5BBA60785 for ; Tue, 14 Oct 2014 17:46:06 +0200 (CEST)
Received: (qmail 21484 invoked by uid 1007); 14 Oct 2014 17:46:06 +0200
Date: Tue, 14 Oct 2014 17:46:06 +0200
From: Gert Doering 
To: Ted Lemon 
Message-ID: <20141014154606.GA31092@Space.Net>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+fuIvzTE++KkgPtL"
Content-Disposition: inline
In-Reply-To: <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/yDNB_jt8-YdAMNgknxY-SWUSUZk
Cc: Erik Kline , HOMENET Working Group , Pierre Pfister , Gert Doering 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 15:46:10 -0000

--+fuIvzTE++KkgPtL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Oct 14, 2014 at 10:13:34AM -0500, Ted Lemon wrote:
> On Oct 14, 2014, at 9:59 AM, Gert Doering  wrote:
> >> Indeed.   The question is, should we increase the number of instances =
in which they are forced to handle it, or no?
> >=20
> > Because this is the only way that application developers will learn to
> > handle it.
>=20
> Application developers _can't_ handle it.   Applications have no control =
over routing, and making applications do source address selection is a real=
ly bad idea.

Application developers MUST handle changing addresses, for example by not
doing silly things like "at startup, do some DNS resolving and socket
binding to a fixed address, and assume that the addresses you receive
are not changing".

I haven't even mentioned source address selection, as that doesn't come
into play for a singlehomed homenet - but as soon as the homenet gets
multihomed, applications would benefit a LOT from doing intelligent
source address selection.  Like in presenting users a selection menu
"use ISP? -> SpaceNet, HE.NET, don't care" and picking the appropriate
source address.

Yes, there's quite a bit of specifications missing to be able to do that
(like, how do I find a label to stick onto an address I find on my=20
interface), but for a *homenet*, this is the way it needs to be - nobody
will fiddle with the router to do "http goes to SpaceNet, bittorrent goes
to HE.NET", but if the application can do it, it greatly empowers users.


> I haven't encountered any ISPs that do flash renumbering, and I'm
> surprised to hear you saying that T-Online is doing it: that's not
> my understanding.   In general, providers that renumber their
> customers use graceful renumbering, not flash renumbering.   There's
> no reason to do flash renumbering.

In the end, at some point in time, the old prefix goes away, however
you phase it.  So if the application stubbornly clings to it, it will stop
working.

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--+fuIvzTE++KkgPtL
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVD1FPt9WwGXkzn/FAQL0ew/+OqaBqswOsJMD6c+2OwgEwMcILnM2NgPv
vQn4Sw9TPczI1EwdCVYL8r4MMDsoSa/kGvJarLB/WZ99QUqGcCKw1cVpSMLXGROU
qX5Ej7cUOMYtXzY+3YHqRV9073Q67LkLenH+/PllFajLOpBRL2H0rD13aghTattM
g9hY4V87uJda4BQPd2k/34Vp/GAuF8H39Nrj83ADz9w+C48SmRbNTMQsGXIEtEfF
XzoDglYKOYrZ+DhxPXf+egvhKeavx/zj/Z4hMtYBAMWslsfUvGNFzIk6TQqseD2u
Bgkau5Sfk9ld1GGiBiV+92LZnoBHwPs/v0bYOS8ZrNfK7XzDXMtZY/lTV19LLEnv
j1giwc7Vbv4lfWFEmvspkPx47f1QkMGjlxbB7v5/OsimQJz0Mv5WosbDRAy4nrIX
DUFOIIhKvYrgNfxPKujtMaMjFhh2OzITGLYyYNEesZ/SyRynsTOy9Xrm5XnZkJ53
xZdB9pwwuti+eT+vOLc8VObRu/fsB9APtpKFZTRCbDLsP7PhJ34bqgBkOCFwXa5k
/nBQwv4jY8LMAjWTDbbvd/DuE58ii3+tpvqsayPQKxAgzY5euR+oW5kIMDXZOL2c
tw6MemPtfiy4evBXSpolCYlPHz424D8MXh5y/lV33nD7a10HoTv2Ab1LVkdr60M/
oKIToLl2sGI=
=Qsgm
-----END PGP SIGNATURE-----

--+fuIvzTE++KkgPtL--


From nobody Tue Oct 14 09:17:34 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E831A8901 for ; Tue, 14 Oct 2014 09:17:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.906
X-Spam-Level: 
X-Spam-Status: No, score=-2.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, PLING_QUERY=0.994] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSPQqsGR3PDj for ; Tue, 14 Oct 2014 09:17:31 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id E89591A88DC for ; Tue, 14 Oct 2014 09:17:30 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1Xe4mv-0000BzC; Tue, 14 Oct 2014 18:17:29 +0200
Message-Id: 
To: Gert Doering 
From: Philip Homburg 
Sender: pch-bBB316E3E@u-1.phicoh.com
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net> 
In-reply-to: Your message of "Tue, 14 Oct 2014 17:41:11 +0200 ." <20141014154111.GZ31092@Space.Net> 
Date: Tue, 14 Oct 2014 18:17:28 +0200
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/HGOKqVIMsmotF2XBpDA6rzk8glQ
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 16:17:33 -0000

In your letter dated Tue, 14 Oct 2014 17:41:11 +0200 you wrote:
>Now, please tell me who is more relevant for *homenet*?  A geek who is
>stuck in "I want to do this the old way!  I have always done it that way!"
>or "a standard mom and dad household"?

Just every business does it 'the old way'. Everybody relies on stable prefixes.
Runs services like DNS not routers, etc, etc.

I can replicate that at home. 

But then when I tell other people, they can't do it. Because on a consumer lines
it is just too complicated.

Current state is that many home routers have all kinds of bugs. So just putting
more features on a home router that often gets selected by the ISP to be as cheap
as possible is just not the way to go.

So in the end, consumers can only be dumb clients who have to rely on services
provided by 'the cloud'.



From nobody Tue Oct 14 09:20:21 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EC01A87AF for ; Tue, 14 Oct 2014 09:20:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level: 
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3C7IuXCvvncu for ; Tue, 14 Oct 2014 09:20:13 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4161A8A08 for ; Tue, 14 Oct 2014 09:20:13 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id E94C12380423; Tue, 14 Oct 2014 12:20:11 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <343f28c2c9f04db7b82e827307ef95bc@BN1PR0201MB0674.namprd02.prod.outlook.com>
Date: Tue, 14 Oct 2014 11:20:10 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <343f28c2c9f04db7b82e827307ef95bc@BN1PR0201MB0674.namprd02.prod.outlook.com>
To: Wuyts Carl 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/MST2KlzmhCHkPihaOgNke_-6PI8
Cc: Erik Kline , HOMENET Working Group , Pierre Pfister , Gert Doering 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 16:20:15 -0000

On Oct 14, 2014, at 10:34 AM, Wuyts Carl  =
wrote:
> I can confirm that.  We have a customer handing out a new prefix every =
4 days.

But let's be clear: is your customer doing flash renumbering, or =
gracefully renumbering?   If they are flash renumbering, are they doing =
it because they had a choice, knew they had a choice, and chose flash =
renumbering over graceful renumbering, or are they doing it because it's =
the solution you offered them?


From nobody Tue Oct 14 09:21:18 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70F51A8901 for ; Tue, 14 Oct 2014 09:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level: 
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iathRPWVXP6k for ; Tue, 14 Oct 2014 09:21:15 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 168D91A89B4 for ; Tue, 14 Oct 2014 09:21:14 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 3D6AE2380423; Tue, 14 Oct 2014 12:21:12 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <20141014154111.GZ31092@Space.Net>
Date: Tue, 14 Oct 2014 11:21:12 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>
To: Gert Doering 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Sj2BpGjch_tMpnbYEKafipYoAo0
Cc: HOMENET Working Group , Philip Homburg 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 16:21:17 -0000

On Oct 14, 2014, at 10:41 AM, Gert Doering  wrote:
> That reply doesn't surprise me the least, it's the standard answer =
from
> every geek who has not spent a few weeks thinking about this :-)

This isn't a helpful response, Gert.   If you are right, you can explain =
the reason that you are right.   You don't have to accuse the people you =
are talking to of not thinking this through.


From nobody Tue Oct 14 09:21:56 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F0D1A89B4 for ; Tue, 14 Oct 2014 09:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.006
X-Spam-Level: 
X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwOupPi3Gv_L for ; Tue, 14 Oct 2014 09:21:49 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9B101A87AF for ; Tue, 14 Oct 2014 09:21:48 -0700 (PDT)
Received: by mail-oi0-f54.google.com with SMTP id v63so17259981oia.27 for ; Tue, 14 Oct 2014 09:21:48 -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; bh=Y4MYTKV2dqSGp/xp9SwQ2dIXXRUoOAZxXxI+XnI0DQ4=; b=rC+l1W6hRsdft6bey0AUX98YHpua4q06nKK5LQa7wWPLPeQO+dVJgSAUoamgsFk1Oj Fmi9B5dClSI3QnfrjFCs2js8Cs6+jYtXKJo5vS2whMRPyryIFshy/0ZsobwMSuSfhnsD aFtjOF/6sX+H3uO9hdB7h0t8sqZ3T00Yq67tnsXDEjzmJkd3fTYGitqoNi5G/d+wYxxm D1ZLDu9X6u4Ou/NedHo+p1DnamS8OwkcdYCYkHKBXgiXLLL5qnAojC85txWJWYqU4APC dYhOlUEQIz3DT3nsnbPCcb8amVNdZWX5yBIC/Fqo7XLSnqjfSE0GSr/gG+Ma43YLJirg UviQ==
MIME-Version: 1.0
X-Received: by 10.202.174.76 with SMTP id x73mr5324991oie.12.1413303708424; Tue, 14 Oct 2014 09:21:48 -0700 (PDT)
Received: by 10.202.227.211 with HTTP; Tue, 14 Oct 2014 09:21:48 -0700 (PDT)
In-Reply-To: <5620.1413300562@sandelman.ca>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr> <5620.1413300562@sandelman.ca>
Date: Tue, 14 Oct 2014 09:21:48 -0700
Message-ID: 
From: Dave Taht 
To: Michael Richardson 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/6Hxr-qPvGKkAu6fMzq-tjdJEiPo
Cc: HOMENET Working Group , Pierre Pfister 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 16:21:49 -0000

a data point: openwrt barrier breaker just shipped with ula generation enabled.

Another data point - I just deployed ipv6 source specific routing in
production. A box with an ipv6 address 5 hops deep in the network was
able to get out (through 4 routers without any ipv6 addresses, just
the fe80) Woot!

While the traceroute is weird, it's weirder with ulas. Each hop with
a ula generates a dns request which the local dns responder has no
idea what to do with,
and forwards upstream.

To me unless naming is solved thoroughly I'm really reluctant to
sprinkle ipv6 everywhere.


From nobody Tue Oct 14 09:22:46 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D4A1A8A28 for ; Tue, 14 Oct 2014 09:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.388
X-Spam-Level: *
X-Spam-Status: No, score=1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, PLING_QUERY=0.994, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ia-TYrbbyDHo for ; Tue, 14 Oct 2014 09:22:40 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B631A89E0 for ; Tue, 14 Oct 2014 09:22:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 691513C; Tue, 14 Oct 2014 18:22:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1413303752; bh=nUhtsw5x/KgrRTgIHyYeDRyjO/o3SI7SAdGASFV6y80=; b=U bT5gtYwKC3BIFUJQoMiLlrIUg3xGi6Ztd8KkdV1Et2n4esaYjMJE0auVS/mLPKmh zMx7Rcrojl/fv+2dwuhNyhmW3+bhEUZK07Gv2040F9cKHq+Wv+rdKR0cSC0+cWkj kWmyYl3HIyaihwfAwsuXTJJEpgtX3RYVJVZI7XKq4M=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pVSVxIT5c9-z; Tue, 14 Oct 2014 18:22:32 +0200 (CEST)
Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTPSA id C76BE3A; Tue, 14 Oct 2014 18:22:32 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Sander Steffann 
In-Reply-To: <20141014154606.GA31092@Space.Net>
Date: Tue, 14 Oct 2014 18:22:32 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com> <20141014154606.GA31092@Space.Net>
To: =?utf-8?Q?Gert_D=C3=B6ring?= 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/QmiNCJP3JAi33WG8Iv3vhdKoMm4
Cc: Erik Kline , HOMENET Working Group , Ted Lemon , Pierre Pfister 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 16:22:41 -0000

> I haven't even mentioned source address selection, as that doesn't =
come
> into play for a singlehomed homenet - but as soon as the homenet gets
> multihomed, applications would benefit a LOT from doing intelligent
> source address selection.  Like in presenting users a selection menu
> "use ISP? -> SpaceNet, HE.NET, don't care" and picking the appropriate
> source address.
>=20
> Yes, there's quite a bit of specifications missing to be able to do =
that
> (like, how do I find a label to stick onto an address I find on my=20
> interface), but for a *homenet*, this is the way it needs to be - =
nobody
> will fiddle with the router to do "http goes to SpaceNet, bittorrent =
goes
> to HE.NET", but if the application can do it, it greatly empowers =
users.

Indeed. And some devices like mobile phones already allow the user to =
say "only sync my photo album when on Wifi".

One thing that does worry me is every application developer having to =
re-invent the code for all of this (find labels, actually implement the =
networking code correctly etc). I think a standard API should be =
available for all of this. Otherwise all operating system vendors and =
distributions will come up with something completely different which =
will make it even harder for the application developers to do the right =
thing.

Cheers,
Sander


From nobody Tue Oct 14 09:23:12 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271FA1A8A6F for ; Tue, 14 Oct 2014 09:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level: 
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BC8QxY4KdMTl for ; Tue, 14 Oct 2014 09:23:08 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 865A21A8A28 for ; Tue, 14 Oct 2014 09:23:08 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id A4D772380423; Tue, 14 Oct 2014 12:23:07 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <20141014154606.GA31092@Space.Net>
Date: Tue, 14 Oct 2014 11:23:06 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <07DC5B90-B2A6-46FD-9C13-4EF06C0B6E1F@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com> <20141014154606.GA31092@Space.Net>
To: Gert Doering 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/i594-fzK_hz0778dvIbMM7HNRGA
Cc: Erik Kline , HOMENET Working Group , Pierre Pfister 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 16:23:10 -0000

On Oct 14, 2014, at 10:46 AM, Gert Doering  wrote:
> In the end, at some point in time, the old prefix goes away, however
> you phase it.  So if the application stubbornly clings to it, it will =
stop
> working.

This is correct, but if you have a preferred and a deprecated prefix, =
the stack will automatically choose the preferred prefix.   And if your =
ISP deprecates the prefix rather than withdrawing it, chances are that =
by the time it expires, there won't be any applications using it.

So please don't gloss over the distinction between graceful renumbering =
and flash renumbering.  IPv6 was designed to do graceful renumbering, =
and the claim that flash renumbering is no different is a major step =
backward from the functionality that was designed into IPv6.


From nobody Tue Oct 14 09:25:55 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7EA1A8A28 for ; Tue, 14 Oct 2014 09:25:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level: 
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSWao09TChiU for ; Tue, 14 Oct 2014 09:25:51 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id F25621A8963 for ; Tue, 14 Oct 2014 09:25:50 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id CD4F12380423; Tue, 14 Oct 2014 12:25:49 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <20141014154606.GA31092@Space.Net>
Date: Tue, 14 Oct 2014 11:25:48 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <9C17A8E0-2BE7-4FB3-9A66-576E197A059F@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com> <20141014154606.GA31092@Space.Net>
To: Gert Doering 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/0e53JO5_ZrcSv5yWTOBNScy4bxQ
Cc: Erik Kline , HOMENET Working Group , Pierre Pfister 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 16:25:52 -0000

On Oct 14, 2014, at 10:46 AM, Gert Doering  wrote:
> Application developers MUST handle changing addresses, for example by =
not
> doing silly things like "at startup, do some DNS resolving and socket
> binding to a fixed address, and assume that the addresses you receive
> are not changing".

This has little to do with renumbering on the network to which the =
application is connected.   I agree that applications should do this, =
and that applications that don't will break if the provider renumbers, =
but we are talking about renumbering in the homenet, not renumbering of =
network services outside the home.

If you are referring specifically to naming in the home, while it's true =
that applications should support service address renumbering in the =
home, that is orthogonal to the question of whether services in the home =
should be numbered using ULAs or GUAs.


From nobody Tue Oct 14 09:27:43 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05B81A8A98 for ; Tue, 14 Oct 2014 09:27:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level: 
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IzFvZQ9-VW0 for ; Tue, 14 Oct 2014 09:27:32 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0AF1A8A64 for ; Tue, 14 Oct 2014 09:27:32 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 390D22380423; Tue, 14 Oct 2014 12:27:30 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Tue, 14 Oct 2014 11:27:29 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <6231BC6A-CF83-4B5A-835A-D7B8BEDDC3AC@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com> <20141014154606.GA31092@Space.Net> 
To: Sander Steffann 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/jrxCjR-YZFH75G0SxiInlz6Zj2M
Cc: Erik Kline , HOMENET Working Group , Pierre Pfister , =?iso-8859-1?Q?Gert_D=F6ring?= 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 16:27:36 -0000

On Oct 14, 2014, at 11:22 AM, Sander Steffann  =
wrote:
> One thing that does worry me is every application developer having to =
re-invent the code for all of this (find labels, actually implement the =
networking code correctly etc). I think a standard API should be =
available for all of this. Otherwise all operating system vendors and =
distributions will come up with something completely different which =
will make it even harder for the application developers to do the right =
thing.

It would be helpful if you could participate in the MIF working group, =
which is working on solving this problem.


From nobody Tue Oct 14 09:38:05 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14F61A8A88 for ; Tue, 14 Oct 2014 09:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.088
X-Spam-Level: *
X-Spam-Status: No, score=1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, PLING_QUERY=0.994, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMTZAE4ODQKP for ; Tue, 14 Oct 2014 09:38:03 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5031A8A80 for ; Tue, 14 Oct 2014 09:38:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id C024C3C; Tue, 14 Oct 2014 18:38:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1413304680; bh=C+lRj1Ts5fvbU3qx08LZjmIQ1IIa3cI4uJVPOb118Go=; b=c iVGLIjyAqXZdGzVQbwAnL9Rr1HX703Vdfg91hXZLxQFLEo8uDjmFz1ENhKD5+qP5 3EBunizxTL0ZM+GjtADYSwz0JPGOiLH2ooH6ZcR36qwnzs1aUlg1S2gsZzopp9TH 4VNtreGDP11hMT9XJAWUFsgDrmHhBti4fLAm7pzCaA=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id T+Ljfz39OYKf; Tue, 14 Oct 2014 18:38:00 +0200 (CEST)
Received: from [IPv6:2a00:8640:1::f1ed:8dbb:2dc0:f63b] (unknown [IPv6:2a00:8640:1:0:f1ed:8dbb:2dc0:f63b]) by mail.sintact.nl (Postfix) with ESMTPSA id DFE873A; Tue, 14 Oct 2014 18:37:59 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Sander Steffann 
In-Reply-To: <6231BC6A-CF83-4B5A-835A-D7B8BEDDC3AC@fugue.com>
Date: Tue, 14 Oct 2014 18:37:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9695FA43-9CFC-4DE2-960A-1B3D0B61B5EF@steffann.nl>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com> <20141014154606.GA31092@Space.Net>  <6231BC6A-CF83-4B5A-835A-D7B8BEDDC3AC@fugue.com>
To: Ted Lemon 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/3KqIyEdU30_JxC5IJadBFHN3oyg
Cc: Erik Kline , HOMENET Working Group , Pierre Pfister , =?utf-8?Q?Gert_D=C3=B6ring?= 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 16:38:03 -0000

Hi,

> Op 14 okt. 2014, om 18:27 heeft Ted Lemon  het =
volgende geschreven:
>=20
> On Oct 14, 2014, at 11:22 AM, Sander Steffann  =
wrote:
>> One thing that does worry me is every application developer having to =
re-invent the code for all of this (find labels, actually implement the =
networking code correctly etc). I think a standard API should be =
available for all of this. Otherwise all operating system vendors and =
distributions will come up with something completely different which =
will make it even harder for the application developers to do the right =
thing.
>=20
> It would be helpful if you could participate in the MIF working group, =
which is working on solving this problem.

Will do :)
Sander


From nobody Tue Oct 14 11:44:43 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0631ACDB0 for ; Tue, 14 Oct 2014 11:44:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.229
X-Spam-Level: 
X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, PLING_QUERY=0.994, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVgl0odUvxAY for ; Tue, 14 Oct 2014 11:44:33 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226EB1A802F for ; Tue, 14 Oct 2014 11:44:33 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7DDDDA1; Tue, 14 Oct 2014 20:44:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1413312271; bh=nx6UhbDeJdOqc67ox1YctR0xqpFJmkVKSgM0DzYL+9U=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=QRDl6CWEwTv9OTTfWWlL8Det7LUcZHtHHnDXcCWj52qYVcdyLez9ZbfoUOOLeK2ds Ljecxc+4kfSyp00AF0e4Ur7xMWzGt9RT7shQGX0HOZg6IoRlxKvLMfgAtRWQusM9TB K1WkLAEN21rfBYXKRTTz3rIICQcWNyh2qVAEA2Gg=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 733DA9F; Tue, 14 Oct 2014 20:44:31 +0200 (CEST)
Date: Tue, 14 Oct 2014 20:44:31 +0200 (CEST)
From: Mikael Abrahamsson 
To: Ted Lemon 
In-Reply-To: <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com>
Message-ID: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Eov-v6bBVmQ64DkHaqqtq-lwEGA
Cc: Erik Kline , HOMENET Working Group , Pierre Pfister , Gert Doering 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 18:44:38 -0000

On Tue, 14 Oct 2014, Ted Lemon wrote:

> I haven't encountered any ISPs that do flash renumbering, and I'm 
> surprised to hear you saying that T-Online is doing it: that's not my 
> understanding.  In general, providers that renumber their customers use 
> graceful renumbering, not flash renumbering.  There's no reason to do 
> flash renumbering.

I know providers that cycle their PPPoE sessions once per day to give 
customers new IPv4 GUA once per day.

I have heard of some countries where customers expect to get new address 
all the time, otherwise they scream about lack of privacy.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Tue Oct 14 12:16:33 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3E81ACE95 for ; Tue, 14 Oct 2014 12:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.179
X-Spam-Level: 
X-Spam-Status: No, score=-0.179 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjgwgR7T-F-g for ; Tue, 14 Oct 2014 12:16:06 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 142181ACE60 for ; Tue, 14 Oct 2014 12:15:51 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 428162380423; Tue, 14 Oct 2014 15:15:49 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Tue, 14 Oct 2014 14:15:47 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <48942796-C098-48B6-B894-544499EEB5F3@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com> 
To: Mikael Abrahamsson 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/tg-OAlAetvR-6vQhtpoLiYc4omw
Cc: Erik Kline , HOMENET Working Group , Pierre Pfister , Gert Doering 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 19:16:19 -0000

On Oct 14, 2014, at 1:44 PM, Mikael Abrahamsson  =
wrote:
> I know providers that cycle their PPPoE sessions once per day to give =
customers new IPv4 GUA once per day.

Right.  This is IPv4.  In IPv4 we typically use a NAT on the local wire, =
so we get the effect we are trying to achieve either by retaining stale =
GUAs or using ULAs on the local wire in homenets.   IPv4 also does not =
provide graceful renumbering, so if the ISP wants to force an IPv4 =
address change, they have no choice but to do flash renumbering.   The =
UX is not good.


From nobody Tue Oct 14 12:20:53 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29661ACE37 for ; Tue, 14 Oct 2014 12:20:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.984
X-Spam-Level: 
X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuhZ_uFRF6Rw for ; Tue, 14 Oct 2014 12:20:45 -0700 (PDT)
Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7045B1ACE66 for ; Tue, 14 Oct 2014 12:19:58 -0700 (PDT)
Received: by mail-vc0-f169.google.com with SMTP id hy4so8059995vcb.14 for ; Tue, 14 Oct 2014 12:19:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=HGc5U0WtBRe3BFtmAH9bXu5aZktQApIfjVufa4zbUd0=; b=MEMtrUCeNTBqwd4iUNKVgtp/kWdDMnZbRUhYkgCBgD6Kzgstx/DWJ90PmDnwh1hlb0 5OR6+X/PboaRYSVhzp1O61LydTGQSRkZJrmpuU2V5feZhJ+uuxYqkMgXsnD2xWCO67Sv M966Mv29kng9NwqKlOzxhnmXvlFGGziQLFGMSUOlnZES0O53Zn1Jv5bq51MXtIeqCX6c YrfyrNDXhB5Kg94tRwNtxnJRvDNlyVdKE1sy2zlfd6aqT9KwoYks2Tzu9oKnn0+0dsRM OH0+AhiKgeQEzZpyk41ponmiowhRTGWUTtDt5kgZHmNqX7R2wqKE/AHbA9ut5zafv06X QFSg==
X-Gm-Message-State: ALoCoQmERJFHpfcDkew/zyesVJCdzssR+02qKS+iM+hxZ+JcCUnDMIn2u9VOMoQcxY8hq39tT/aa
MIME-Version: 1.0
X-Received: by 10.220.252.134 with SMTP id mw6mr3410667vcb.75.1413314396132; Tue, 14 Oct 2014 12:19:56 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Tue, 14 Oct 2014 12:19:56 -0700 (PDT)
In-Reply-To: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   
Date: Tue, 14 Oct 2014 12:19:56 -0700
Message-ID: 
From: James Woodyatt 
To: HOMENET Working Group 
Content-Type: multipart/alternative; boundary=089e011613d289ab6f050566e67a
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ouYWUghhbLUAmACKDU47tA09pnA
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 19:20:48 -0000

--089e011613d289ab6f050566e67a
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 14, 2014 at 1:24 AM, Markus Stenberg 
wrote:

>
> From my point of view, it should be SHOULD _always_ generate ULA (so that
> privacy oriented things in a home have a sane default without need for
> trusting firewalling), and MUST generate if no GUA around.
>

I don't understand [and I'm not sure I like seeing it] this clause about
"privacy oriented things" and "trusting firewalling" in the context of RFC
4193 unique local addressing. I suspect there is some conflation with RFC
1918 privacy addressing happening there [which is why I am frowning].

On the topic of the original question, if I were to editorialize here, then
I would want to see something like this:

A) An autonomously generated ULA prefix SHOULD be advertised when no other
delegated prefix is valid.

B) Whenever there is any valid delegated prefix, advertisements for an
existing autonomously generated ULA prefix MUST be deprecated, i.e. updated
with preferred lifetime of zero.

C) A deprecated autonomously generated ULA prefix MUST be withdrawn when it
expires, i.e. its valid time reaches zero.

D) Whenever there is no longer any valid delegated prefix, advertisements
for a previously deprecated autonomously generated ULA prefix MUST be
updated with non-zero preferred lifetime.


The idea here is to make sure IPv6 applications can generally rely on home
network interior routers to forward traffic among the multiple links in the
home, regardless of whether any first-mile Internet services are
provisioned, configured and operational, i.e. there shall always be at
least one preferred global scope network prefix, and there shall be an
autonomously generated local prefix available as a last resort whenever
there are no valid delegated prefixes.


-- 
james woodyatt 
Nest Labs, Communications Engineering

--089e011613d289ab6f050566e67a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Oct 14, 2014 at 1:24 AM, Markus Stenberg <markus.stenberg@iki.fi=
> wrote:


>From my point of view, it should be SHOULD _always_ generate ULA (so that p=
rivacy oriented things in a home have a sane default without need for trust=
ing firewalling), and MUST generate if no GUA around.

I don'=
t understand [and I'm not sure I like seeing it] this clause about &quo=
t;privacy oriented things" and "trusting firewalling" in the=
 context of RFC 4193 unique local addressing. I suspect there is some confl=
ation with RFC 1918 privacy addressing happening there [which is why I am f=
rowning].

=
On the topic of the original question, if I were to editorialize here, then=
 I would want to see something like this:
<=
br>
A) An auton=
omously generated ULA prefix SHOULD be advertised when no other delegated p=
refix is valid.
B) Whenever there is any valid delegated prefix, advertisemen=
ts for an existing autonomously generated ULA prefix MUST be deprecated, i.=
e. updated with preferred lifetime of zero.
C)=
 A deprecated autonomously generated ULA prefix MUST be withdrawn when it e=
xpires, i.e. its valid time reaches zero.
D) Whenever there is no longer any valid delegated prefix, adve=
rtisements for a previously deprecated autonomously generated ULA prefix MU=
ST be updated with non-zero preferred lifetime.

The idea here =
is to make sure IPv6 applications can generally rely on home network interi=
or routers to forward traffic among the multiple links in the home, regardl=
ess of whether any first-mile Internet services are provisioned, configured=
 and operational, i.e. there shall always be at least one preferred global =
scope network prefix, and there shall be an autonomously generated local pr=
efix available as a last resort whenever there are no valid delegated prefi=
xes.


-- 
<=
div dir=3D"ltr">james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engine=
ering




--089e011613d289ab6f050566e67a--


From nobody Tue Oct 14 12:31:48 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D74D1ACEBF for ; Tue, 14 Oct 2014 12:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level: 
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ayn9o2Mvqh3h for ; Tue, 14 Oct 2014 12:31:30 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 32FBB1ACEB4 for ; Tue, 14 Oct 2014 12:31:29 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 887B823803D1; Tue, 14 Oct 2014 15:31:28 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Tue, 14 Oct 2014 14:31:26 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>    
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/I9dkddSVSlIEVDemhkNsx5KiqXY
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 19:31:37 -0000

On Oct 14, 2014, at 2:19 PM, James Woodyatt  wrote:
> On the topic of the original question, if I were to editorialize here, =
then I would want to see something like this:

I get that you have an opinion on this, but you haven't actually stated =
any argument to support what you think we should do.   And there are =
some implications in what you are saying that I don't think are =
necessary.

> A) An autonomously generated ULA prefix SHOULD be advertised when no =
other delegated prefix is valid.

OK, although underspecified.

> B) Whenever there is any valid delegated prefix, advertisements for an =
existing autonomously generated ULA prefix MUST be deprecated, i.e. =
updated with preferred lifetime of zero.

Why?   What problem does this solve?   Given that it's going to mean =
additional work, there should be some benefit to doing it.

> C) A deprecated autonomously generated ULA prefix MUST be withdrawn =
when it expires, i.e. its valid time reaches zero.

Okay, given that a prefix expires, it should be withdrawn, whether it's =
a ULA or a GUA.

> D) Whenever there is no longer any valid delegated prefix, =
advertisements for a previously deprecated autonomously generated ULA =
prefix MUST be updated with non-zero preferred lifetime.

OK, but seems like unnecessary work.   You're essentially recapitulating =
the brokenness of IPv4 zeroconf.

> The idea here is to make sure IPv6 applications can generally rely on =
home network interior routers to forward traffic among the multiple =
links in the home, regardless of whether any first-mile Internet =
services are provisioned, configured and operational, i.e. there shall =
always be at least one preferred global scope network prefix, and there =
shall be an autonomously generated local prefix available as a last =
resort whenever there are no valid delegated prefixes.

This is where I am just completely puzzled.   We talked about this =
previously.   I thought the idea was that the homenet ULA should =
converge: that there should only be one, ultimately, and that when there =
are two, routing should still work.  You are stating this as if the ULAs =
are per-subnet of a homenet, and that routing across homenet routers =
using ULAs isn't supported.

If you really think that's how this should work, I can see why you want =
to deprecate them.   But that's not how they should work.


From nobody Tue Oct 14 12:44:37 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD561ACF0E for ; Tue, 14 Oct 2014 12:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.006
X-Spam-Level: 
X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-nPpctf0wQE for ; Tue, 14 Oct 2014 12:44:23 -0700 (PDT)
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35FAE1ACF05 for ; Tue, 14 Oct 2014 12:44:23 -0700 (PDT)
Received: by mail-pa0-f54.google.com with SMTP id ey11so8494356pad.27 for ; Tue, 14 Oct 2014 12:44:22 -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=qkRHkrzmnV2uibuwtzJ37c1kpggzrWr+PXmx8dtziEQ=; b=Ls7kamwKEb0Mm6o1xuZJd3W4vasMg/DLMP5+uOeCsELI3M/gm4Akd+ZN7mijrGJ3uP I78gBb6DJLriXVxRt3o9KkQIltYZH0T7mVIh+M6PgFFr5vnsHjuJUinJJbrK9J38xTuu i5UNi+7EzHIM6gkXktdhP53uu81Vas61BXI+0FLDc36Kh2RA9HJSvfYnVbokpXaGUZml BkbsxzwtkzOP5IRSly98B4lPAHX/QzK8p/v+Zo8IdNkFPwvWPm55MNL/Hz1etVV5begH u8vV1joz10yXBf+89YTG7oblpFbkXVbruKiLUGXfsMvlZVhBYXaDi0+lAVM0LLSQ9ruc qQQQ==
X-Received: by 10.67.21.194 with SMTP id hm2mr6853041pad.119.1413315862883; Tue, 14 Oct 2014 12:44:22 -0700 (PDT)
Received: from [192.168.178.23] (75.196.69.111.dynamic.snap.net.nz. [111.69.196.75]) by mx.google.com with ESMTPSA id dk7sm573262pdb.8.2014.10.14.12.44.19 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Oct 2014 12:44:21 -0700 (PDT)
Message-ID: <543D7D15.7010907@gmail.com>
Date: Wed, 15 Oct 2014 08:44:21 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ted Lemon 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>
In-Reply-To: <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/M-2CI976CwOQyITV5jEC5K08S10
Cc: HOMENET Working Group , James Woodyatt 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 19:44:24 -0000

On 15/10/2014 08:31, Ted Lemon wrote:
> On Oct 14, 2014, at 2:19 PM, James Woodyatt  wrote:
>> On the topic of the original question, if I were to editorialize here, then I would want to see something like this:
> 
> I get that you have an opinion on this, but you haven't actually stated any argument to support what you think we should do.   And there are some implications in what you are saying that I don't think are necessary.
> 
>> A) An autonomously generated ULA prefix SHOULD be advertised when no other delegated prefix is valid.
> 
> OK, although underspecified.
> 
>> B) Whenever there is any valid delegated prefix, advertisements for an existing autonomously generated ULA prefix MUST be deprecated, i.e. updated with preferred lifetime of zero.
> 
> Why?   What problem does this solve?   Given that it's going to mean additional work, there should be some benefit to doing it.

At a stroke this would destroy the main advantage of ULAs - namely,
invariant addresses for internal traffic. IPv6 assumes multiple
simultaneous addresses; there is no reason whatever to artificially
prevent use of ULAs alongside GUAs.

   Brian

>> C) A deprecated autonomously generated ULA prefix MUST be withdrawn when it expires, i.e. its valid time reaches zero.
> 
> Okay, given that a prefix expires, it should be withdrawn, whether it's a ULA or a GUA.
> 
>> D) Whenever there is no longer any valid delegated prefix, advertisements for a previously deprecated autonomously generated ULA prefix MUST be updated with non-zero preferred lifetime.
> 
> OK, but seems like unnecessary work.   You're essentially recapitulating the brokenness of IPv4 zeroconf.
> 
>> The idea here is to make sure IPv6 applications can generally rely on home network interior routers to forward traffic among the multiple links in the home, regardless of whether any first-mile Internet services are provisioned, configured and operational, i.e. there shall always be at least one preferred global scope network prefix, and there shall be an autonomously generated local prefix available as a last resort whenever there are no valid delegated prefixes.
> 
> This is where I am just completely puzzled.   We talked about this previously.   I thought the idea was that the homenet ULA should converge: that there should only be one, ultimately, and that when there are two, routing should still work.  You are stating this as if the ULAs are per-subnet of a homenet, and that routing across homenet routers using ULAs isn't supported.
> 
> If you really think that's how this should work, I can see why you want to deprecate them.   But that's not how they should work.
> 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


From nobody Tue Oct 14 14:31:12 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DAC1ACD19 for ; Tue, 14 Oct 2014 14:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.984
X-Spam-Level: 
X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcQaJsOiHygb for ; Tue, 14 Oct 2014 14:31:09 -0700 (PDT)
Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CFE51A9139 for ; Tue, 14 Oct 2014 14:31:09 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id hq11so8143176vcb.7 for ; Tue, 14 Oct 2014 14:31:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=hqMQbLyHuilRKDPLkWQmN+siRZACKZ7W9VNDo0dJGqY=; b=H4byYgVmYzjjMvQf6rBYHz4JfS660kqUEoei90BzFs4nMWMYmyc4RtApkk8DsFf/ap b0ciO/EJtmuVsHv4eCrhGOXxX55deawbrCUrFyV8i8GWG+YbhiS/W+YxtI+lIc88mIkQ QCVvc+TbvMKAWuqQA7QhCIND/QuuuCOfxGoAA0eWZ2Zh0qzyB7/Wy52xRjEGDPNXIPca xgyYplyVvZ+ZBujW3etrG7iJ+hE1m6r0IYyla4BD3l43V3jvM6SiCiSKIeuE3z9ilQNX 1RJ5EZr29QGhoFKrK76ByfM7cDj1osxKCC2/hEoj/FhKo/OpkH8DetgW3KTik7N8b8GQ vDgg==
X-Gm-Message-State: ALoCoQnttV8fYDgkHJYn0jFy8MIqWpk3Zou1Dgxji9Vy7g1hV23vb/sbO2ggHrfpUbipaby3/4l4
MIME-Version: 1.0
X-Received: by 10.52.150.148 with SMTP id ui20mr3381504vdb.72.1413322268393; Tue, 14 Oct 2014 14:31:08 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Tue, 14 Oct 2014 14:31:08 -0700 (PDT)
In-Reply-To: <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>
Date: Tue, 14 Oct 2014 14:31:08 -0700
Message-ID: 
From: James Woodyatt 
To: HOMENET Working Group 
Content-Type: multipart/alternative; boundary=bcaec51b97cfc2d9e4050568bbd3
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/T0CvzZhTlw1D980RPW7wlzSJiEs
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 21:31:11 -0000

--bcaec51b97cfc2d9e4050568bbd3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 14, 2014 at 12:31 PM, Ted Lemon  wrote:

> [...]
> This is where I am just completely puzzled.   We talked about this
> previously.   I thought the idea was that the homenet ULA should converge=
:
> that there should only be one, ultimately [...]


This is exactly what I'm trying to surface in my earlier comments about
I-D.ietf-homenet-prefix-delegation. That idea needs clarification if we're
going to interoperate with network layers like Thread which have their ULA
prefix that it would be good to advertise in HOMENET domains as a delegated
prefix.

If the idea is to minimize the need for a HOMENET autonomously generated
ULA prefix, then it should only be advertised when not other ULA prefix is
available and it should be deprecated and allowed to expire when it isn't
needed.  If on the other hand, we do not see a need to limit the number of
ULA prefixes advertised into the HOMENET domain, then a persistent one
should be generated when the network is commissioned by its first leader,
and it should always be advertised thereafter whether a first-mile service
is operational or not, and regardless whether the initiating leader leaves
the network.  (There is a problem with the latter case, which is that some
legacy host operating systems are still broken in an environment like that,
and it would be helpful to mitigate such brokenness. The former case
doesn't have that problem.  There is also the exception that arises when
two networks with different ULA prefixes are joined=E2=80=94 now you have o=
ne
network, with two ULA prefixes, neither of which can ever be allowed to
expire.)

On Tue, Oct 14, 2014 at 12:44 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

>
> At a stroke this would destroy the main advantage of ULAs -
> namely, invariant addresses for internal traffic. IPv6 assumes
> multiple simultaneous addresses; there is no reason whatever to
> artificially prevent use of ULAs alongside GUAs.
>

p1. I don't want to prevent the use of ULAs alongside GUAs. Indeed, I need
for this to be preserved, and I'm very concerned about requirement language
that would seem to interfere with that.

p2. While I'm in agreement there is a benefit in a guarantee for hosts on
home networks that they will always have valid addresses in the interior
routing domain, I'm not sure I can agree that the main reason to use a ULA
prefix is to encourage the supposition that a HOMENET generated ULA is more
stable and persistent than any GUA assigned by a first-mile service. I
suppose if the working group has already argued that to death, and
concluded that stable persistent addressing solves a problem that real
people are actually facing, then it's not worth rehashing that discussion.

If we're going to go with HOMENET always generating a ULA prefix at network
commissioning time and persisting for the life of the network, then I'm
going to need to understand better how we're handling network joins and
splits.


--=20
james woodyatt 
Nest Labs, Communications Engineering

--bcaec51b97cfc2d9e4050568bbd3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Oct 14, 2014 at 12:31 PM, Ted Lemon <mellon@fugue.com> wr=
ote:
[...]

This is where I am just completely puzzled.=C2=A0 =C2=A0We talked ab=
out this previously.=C2=A0 =C2=A0I thought the idea was that the homenet UL=
A should converge: that there should only be one, ultimately [...]

This is exactly what I'm=
 trying to surface in my earlier comments about I-D.ietf-homenet-prefix-del=
egation. That idea needs clarification if we're going to interoperate w=
ith network layers like Thread which have their ULA prefix that it would be=
 good to advertise in HOMENET domains as a delegated prefix.

If the idea is to mi=
nimize the need for a HOMENET autonomously generated ULA prefix, then it sh=
ould only be advertised when not other ULA prefix is available and it shoul=
d be deprecated and allowed to expire when it isn't needed.=C2=A0 If on=
 the other hand, we do not see a need to limit the number of ULA prefixes a=
dvertised into the HOMENET domain, then a persistent one should be generate=
d when the network is commissioned by its first leader, and it should alway=
s be advertised thereafter whether a first-mile service is operational or n=
ot, and regardless whether the initiating leader leaves the network. =C2=A0=
(There is a problem with the latter case, which is that some legacy host op=
erating systems are still broken in an environment like that, and it would =
be helpful to mitigate such brokenness. The former case doesn't have th=
at problem.=C2=A0 There is also the exception that arises when two networks=
 with different ULA prefixes are joined=E2=80=94 now you have one network, =
with two ULA prefixes, neither of which can ever be allowed to expire.)

On Tue, Oct 14, 2014 at 12:44 PM, Brian E=
 Carpenter=C2=A0<brian.e.carpenter@gmail.com>=C2=
=A0wrote:

At a stroke this =
would destroy the main advantage of ULAs - namely,=C2=A0invariant addresses=
 for internal traffic. IPv6 assumes multiple=C2=A0simultaneous addresses; t=
here is no reason whatever to artificially=C2=A0prevent use of ULAs alongsi=
de GUAs.

p1. I don't want to preven=
t the use of ULAs alongside GUAs. Indeed, I need for this to be preserved, =
and I'm very concerned about requirement language that would seem to in=
terfere with that.

p2. While I'm in agre=
ement there is a benefit in a guarantee for hosts on home networks that the=
y will always have valid addresses in the interior routing domain, I'm =
not sure I can agree that the main reason to use a ULA prefix is to encoura=
ge the supposition that a HOMENET generated ULA is more stable and persiste=
nt than any GUA assigned by a first-mile service. I suppose if the working =
group has already argued that to death, and concluded that stable persisten=
t addressing solves a problem that real people are actually facing, then it=
's not worth rehashing that discussion.

If we&=
#39;re going to go with HOMENET always generating a ULA prefix at network c=
ommissioning time and persisting for the life of the network, then I'm =
going to need to understand better how we're handling network joins and=
 splits.


-- 
james w=
oodyatt <jhw@nestl=
abs.com>
Nest Labs, Communications Engineering




--bcaec51b97cfc2d9e4050568bbd3--


From nobody Tue Oct 14 14:35:34 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C241ACD3C for ; Tue, 14 Oct 2014 14:35:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level: 
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DL6D9-ElAEno for ; Tue, 14 Oct 2014 14:35:32 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA3A1ACD19 for ; Tue, 14 Oct 2014 14:35:32 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 5D15723803D1; Tue, 14 Oct 2014 17:35:31 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Tue, 14 Oct 2014 16:35:26 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com> 
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/TcrudpTcAeMa2kwtDksNoffmwzo
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 21:35:33 -0000

On Oct 14, 2014, at 4:31 PM, James Woodyatt  wrote:
> There is also the exception that arises when two networks with =
different ULA prefixes are joined=97 now you have one network, with two =
ULA prefixes, neither of which can ever be allowed to expire.)

When we talked about this previously, I think the idea was that when two =
networks with two sets of ULA prefixes merge, you deprecate one of them. =
  And then, as you alluded to later in your message, the question is =
what "you" is.   Presumably this is something HNCP would have to take =
care of.


From nobody Tue Oct 14 14:40:39 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC02A1A00C3 for ; Tue, 14 Oct 2014 14:40:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.984
X-Spam-Level: 
X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4bcC6ZH-uxQ for ; Tue, 14 Oct 2014 14:40:37 -0700 (PDT)
Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF651A00AB for ; Tue, 14 Oct 2014 14:40:36 -0700 (PDT)
Received: by mail-vc0-f171.google.com with SMTP id hy10so8300467vcb.16 for ; Tue, 14 Oct 2014 14:40:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=9Ym2t5njoBFJrctquz+QlFx1cnL1JHKOdGsLa+QUUew=; b=ON34TOBlwMpV9+SWNgK5Bl7l9BVCsMypQAgpPsu5I3MjO9laKf8XnK6pqHgA6OFN+G p3sdQBxvitzcQwWLUz2f2lAgVgmwGcCrM1za4BFUWasQFeV1GIbjfXvI5c/dlb35SXKk OQGPon++nqkwOPiiSI8AdKMAjWYJ8YiZTyreX+G6ODa9j4/TLFriRaKXlmrkgW1VFAOB sQzwnD3h5O0zglClxqtxw/As/+3ZwQsy0rLmUKq6DeGcfRMU25D4ZvVa/8aJDp5unrwW FSlkoL8cQcy4OX1VQAGcCCOQc0sPiydI3YNtNnREtShTJ0C22GSKRJ86F3FVMQ/xdB8D zX0Q==
X-Gm-Message-State: ALoCoQntd63x8ohkKY703zEUN8ER65nKiIbulHOYJ+tgIlkkkbmJOBoeICfrn7At4jYBfE2CI/46
MIME-Version: 1.0
X-Received: by 10.221.3.195 with SMTP id nz3mr7979867vcb.43.1413322836246; Tue, 14 Oct 2014 14:40:36 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Tue, 14 Oct 2014 14:40:36 -0700 (PDT)
In-Reply-To: <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>
Date: Tue, 14 Oct 2014 14:40:36 -0700
Message-ID: 
From: James Woodyatt 
To: HOMENET Working Group 
Content-Type: multipart/alternative; boundary=089e01293fe49b98bf050568ddd4
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/4LjSFEb-1p_Y2hSFbYuQgl6Ozzc
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 21:40:38 -0000

--089e01293fe49b98bf050568ddd4
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 14, 2014 at 2:35 PM, Ted Lemon  wrote:

>
> When we talked about this previously, I think the idea was that when two
> networks with two sets of ULA prefixes merge, you deprecate one of them.
> [...]
>

Naturally, you deprecate one of them, but my concern is that they never
expire if the objective is for a ULA prefix to be invariant. So how many
times can a network join with others before it runs out of space for
deprecated and redundant but unexpired and invariant ULA prefixes?


-- 
james woodyatt 
Nest Labs, Communications Engineering

--089e01293fe49b98bf050568ddd4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Oct 14, 2014 at 2:35 PM, Ted Lemon <mellon@fugue.com> wro=
te:


When we talked about this previously, I think the idea was that when=
 two networks with two sets of ULA prefixes merge, you deprecate one of the=
m. [...]



Naturally, you deprecate one of them, but my concern is that they n=
ever expire if the objective is for a ULA prefix to be invariant. So how ma=
ny times can a network join with others before it runs out of space for dep=
recated and redundant but unexpired and invariant ULA prefixes?


-- 
james=
 woodyatt <jhw@nes=
tlabs.com>
Nest Labs, Communications Engineering




--089e01293fe49b98bf050568ddd4--


From nobody Tue Oct 14 14:49:42 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAAD1A9139 for ; Tue, 14 Oct 2014 14:49:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level: 
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfYA0L4Jmm92 for ; Tue, 14 Oct 2014 14:49:39 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id E23D11A00E0 for ; Tue, 14 Oct 2014 14:49:39 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 4FBF323803D1; Tue, 14 Oct 2014 17:49:39 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Tue, 14 Oct 2014 16:49:35 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com> 
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/DwYBpPUhyyUgVMfdSslA7nzw5oY
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 21:49:41 -0000

On Oct 14, 2014, at 4:40 PM, James Woodyatt  wrote:
> Naturally, you deprecate one of them, but my concern is that they =
never expire if the objective is for a ULA prefix to be invariant. So =
how many times can a network join with others before it runs out of =
space for deprecated and redundant but unexpired and invariant ULA =
prefixes?

I don't think the objective is for the ULA prefix to be invariant.   =
It's for the availability of a ULA prefix to be dependable, and for =
flash renumbering to be avoided whenever possible.   So there's no =
problem with deprecating a ULA when you have two, and no need for the =
ULA to remain stable over long periods of time.

The reason to want there to always be a ULA is that if you use a GUA as =
a ULA, the life cycle of your home network numbering is out of your =
control, and in the hands of whoever gave you the GUA.   That's the only =
thing I think the ULA prefix has to do on a homenet: provide you with =
dependable, graceful homenet-local numbering.


From nobody Tue Oct 14 15:15:09 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5251ACD3D for ; Tue, 14 Oct 2014 15:14:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.984
X-Spam-Level: 
X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eV4xVbn2GW2b for ; Tue, 14 Oct 2014 15:14:40 -0700 (PDT)
Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140471ACEA3 for ; Tue, 14 Oct 2014 15:14:38 -0700 (PDT)
Received: by mail-vc0-f180.google.com with SMTP id le20so19951vcb.25 for ; Tue, 14 Oct 2014 15:14:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=183Wh6Jw2Csp1kTBfqgKJ1E2P98DmeOzgVP28QCk1EE=; b=Y+HY2opes91Fcc/C+cQtGPW3Z7+ug8P6yNty643vhQd0h0/oDhU75IT2sw6j+fiHcW k6M24gs6NI0PgBYRTOICPYqDDB2lbvL59KqS7hE5BDZXrITf+cLKOU8UydSIBqCDDfCb hFMOgHbksQEuVVHr+INL3LWltthIWSIY1EoI8+oEHbOhylDgq3lLsA336UPQ8+VJ75RY /dTia/0J4k1EegCNF0au6pyoHk0P4O8ywxO/urUb7+uZQeR6unW9iEJ6D2N627Ug/i2L OBzUzr99hijvbu5UEYbslQwE0O02YKFxP+ORPKn00vVkhudcpnDm9hXB7dRZ7tWJ7MQF k5dA==
X-Gm-Message-State: ALoCoQmEN2KVy7xzChVrGT0FIKrLQgNXS2Qfdqs72pfKsUIWgMWcmB6V3lH0p/ZwaMz0Bop+MHme
MIME-Version: 1.0
X-Received: by 10.52.35.69 with SMTP id f5mr6853322vdj.35.1413324878102; Tue, 14 Oct 2014 15:14:38 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Tue, 14 Oct 2014 15:14:37 -0700 (PDT)
In-Reply-To: <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>
Date: Tue, 14 Oct 2014 15:14:37 -0700
Message-ID: 
From: James Woodyatt 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=20cf307cfcd44fd6560505695787
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/xicSSedBZ5ii-Zj8baVy5NiTKrI
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 22:14:44 -0000

--20cf307cfcd44fd6560505695787
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 14, 2014 at 2:49 PM, Ted Lemon  wrote:

>
> I don't think the objective is for the ULA prefix to be invariant.   It's
> for the availability of a ULA prefix to be dependable, and for flash
> renumbering to be avoided whenever possible.   So there's no problem with
> deprecating a ULA when you have two, and no need for the ULA to remain
> stable over long periods of time.
>

But there is a problem with only deprecating prefixes without expiring
them. If they never expire, then they accumulate without limit within
existing networks as they join with newly commissioned networks over the
course of their lifetimes.

The reason to want there to always be a ULA is that if you use a GUA as a
> ULA, the life cycle of your home network numbering is out of your control=
,
> and in the hands of whoever gave you the GUA. That's the only thing I thi=
nk
> the ULA prefix has to do on a homenet: provide you with dependable,
> graceful homenet-local numbering.
>

So what's the problem? My language above ensures that home network hosts
always have at least one gracefully renumbered IPv6 address routable
throughout the entire network. If we need a further guarantee that hosts
always have an *invariant* address=E2=80=94 which is an objective you've sa=
id above
that you think we don't actually have=E2=80=94 only then are we faced with =
the
problem of prefix accumulation through network joins, which is a problem
I'm not sure we know how to solve effectively. My proposal avoids that
trouble.

--

To answer a previous question: I would say the reason I thought it worth
expressly zeroing the preferred lifetime on the locally generate ULA prefix
when another prefix is advertised is to expedite the transition to
preferring any delegated ULA prefix over the locally generated one.
Admittedly this is perhaps not worth the effort, and I won't argue further
for it.

--=20
james woodyatt 
Nest Labs, Communications Engineering

--20cf307cfcd44fd6560505695787
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Oct 14, 2014 at 2:49 PM, Ted Lemon <mellon@fugue.com> wro=
te:


I don't think the objective is for the ULA prefix to be invarian=
t.=C2=A0 =C2=A0It's for the availability of a ULA prefix to be dependab=
le, and for flash renumbering to be avoided whenever possible.=C2=A0 =C2=A0=
So there's no problem with deprecating a ULA when you have two, and no =
need for the ULA to remain stable over long periods of time.

But there is a problem with only deprecating prefixes=
 without expiring them. If they never expire, then they accumulate without =
limit within existing networks as they join with newly commissioned network=
s=C2=A0over the course of their lifetimes.

The reason to want there to always be a ULA is that if you use a GUA a=
s a ULA, the life cycle of your home network numbering is out of your contr=
ol, and in the hands of whoever gave you the GUA. That's the only thing=
 I think the ULA prefix has to do on a homenet: provide you with dependable=
, graceful homenet-local numbering.

So what's the problem? My language above ensures th=
at home network hosts always have at least one gracefully renumbered IPv6 a=
ddress routable throughout the entire network. If we need a further guarant=
ee that hosts always have an *invariant* address=E2=80=94 which is an objec=
tive you've said above that you think we don't actually have=E2=80=
=94 only then are we faced with the problem of prefix accumulation through =
network joins, which is a problem I'm not sure we know how to solve eff=
ectively. My proposal avoids that trouble.
=

--
To answer a previous question: I would sa=
y the reason I thought it worth expressly zeroing the preferred lifetime on=
 the locally generate ULA prefix when another prefix is advertised is to ex=
pedite the transition to preferring any delegated ULA prefix over the local=
ly generated one.=C2=A0 Admittedly this is perhaps not worth the effort, an=
d I won't argue further for it.

-- 
=

james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engin=
eering




--20cf307cfcd44fd6560505695787--


From nobody Tue Oct 14 15:32:10 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDC31A0037 for ; Tue, 14 Oct 2014 15:32:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level: 
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i46tTAA83QjX for ; Tue, 14 Oct 2014 15:32:06 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3609E1A0024 for ; Tue, 14 Oct 2014 15:32:06 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 97CFD23803D1; Tue, 14 Oct 2014 18:32:05 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Tue, 14 Oct 2014 17:32:01 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com> 
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/KBKUSgJS9sjljBQNvNxwyhzLLOU
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 22:32:08 -0000

On Oct 14, 2014, at 5:14 PM, James Woodyatt  wrote:
> But there is a problem with only deprecating prefixes without expiring =
them. If they never expire, then they accumulate without limit within =
existing networks as they join with newly commissioned networks over the =
course of their lifetimes.

Ah, sorry, I didn't mean to say that we deprecate them but don't ever =
get rid of them.   I think once a deprecated ULA has expired, it should =
be gc'd.   If the homenet is partitioned, the two options are for the =
partitions to continue using one ULA and try to keep prefixes stable, in =
anticipation of the partition being healed later, or for both partitions =
to switch to new ULAs, or for one homenet router to "own" the ULA and =
get to keep it for use in whichever partition it winds up in, while the =
other partition has to choose a new ULA.

Personally I think keeping the ULA stable across partitions is =
preferable, but I'm not sure it's possible to do it without the risk of =
flash renumbering.

> So what's the problem? My language above ensures that home network =
hosts always have at least one gracefully renumbered IPv6 address =
routable throughout the entire network. If we need a further guarantee =
that hosts always have an *invariant* address=97 which is an objective =
you've said above that you think we don't actually have=97 only then are =
we faced with the problem of prefix accumulation through network joins, =
which is a problem I'm not sure we know how to solve effectively. My =
proposal avoids that trouble.

I understood your language to be trying to get rid of all ULAs if any =
GUAs are present.   Did I misunderstand?=


From nobody Tue Oct 14 16:40:53 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC0A1A0059 for ; Tue, 14 Oct 2014 16:40:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.006
X-Spam-Level: 
X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cThWCwJ5Gneo for ; Tue, 14 Oct 2014 16:40:51 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BED81A0056 for ; Tue, 14 Oct 2014 16:40:51 -0700 (PDT)
Received: by mail-oi0-f47.google.com with SMTP id a141so98450oig.34 for ; Tue, 14 Oct 2014 16:40:50 -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=s9VJxRaxBkfZOrOGvjCM6deix+2rYluptYd4JUDXnV4=; b=oevudq+JERPAYAkq++9dSQ/fj2YKJ/nNAc0ywRKiCGxsYmKuYqN6LSNZVZmzb9t8pI /s8AeWRW6X4+oQDGPSX6kaRHHhRV7HqWaQL4KF5gmCKe/ho34OUxU98wPP9C7trSm+v7 Kd6OAO2/3PfsP8t5p2Ian+3HpvTT42u6V2Ii/fC1H+TSbNaiKNh6DXHbOa6TzeSu5Olr f6DiNfRRHZiyYA4x7cHISnvg5E1dR22A7gmycbcpJGHktEVcc5aYTL/14Q7KBfIb1Bh9 VBNt+yhzH2ItNZE0qszjX75L2+I75NlmD9iFu3vMfd88ZYN/th2jk49syKYYU9aFTJu2 0KUQ==
MIME-Version: 1.0
X-Received: by 10.182.126.233 with SMTP id nb9mr4972484obb.48.1413330050779; Tue, 14 Oct 2014 16:40:50 -0700 (PDT)
Received: by 10.202.227.211 with HTTP; Tue, 14 Oct 2014 16:40:50 -0700 (PDT)
In-Reply-To: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com> 
Date: Tue, 14 Oct 2014 16:40:50 -0700
Message-ID: 
From: Dave Taht 
To: James Woodyatt 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/UO3nQs7tgETP2-SbfqMqymIcOkk
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Oct 2014 23:40:52 -0000

On Tue, Oct 14, 2014 at 2:40 PM, James Woodyatt  wrote:
> On Tue, Oct 14, 2014 at 2:35 PM, Ted Lemon  wrote:
>>
>>
>> When we talked about this previously, I think the idea was that when two
>> networks with two sets of ULA prefixes merge, you deprecate one of them.
>> [...]
>
>
> Naturally, you deprecate one of them, but my concern is that they never
> expire if the objective is for a ULA prefix to be invariant. So how many
> times can a network join with others before it runs out of space for
> deprecated and redundant but unexpired and invariant ULA prefixes?
>

2^56 times I think...

... but the network itself would expire long before then. :)

What's a more reasonable bound? What's the bound before a given
network would collapse from multicast joins alone?
> --
> james woodyatt 
> Nest Labs, Communications Engineering
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>



--=20
Dave T=C3=A4ht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks


From nobody Tue Oct 14 17:00:14 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5BE1A007E for ; Tue, 14 Oct 2014 17:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level: 
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBTrENw1qQZW for ; Tue, 14 Oct 2014 17:00:10 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF051A0081 for ; Tue, 14 Oct 2014 17:00:10 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 68553203AB; Tue, 14 Oct 2014 20:00:37 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 3C57763B40; Tue, 14 Oct 2014 20:00:09 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 240E163B3F; Tue, 14 Oct 2014 20:00:09 -0400 (EDT)
From: Michael Richardson 
To: James Woodyatt 
In-Reply-To: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>    
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/d455iR32osdwxFUR5egf_T7OX9Y
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 00:00:12 -0000

James Woodyatt  wrote:
    > A) An autonomously generated ULA prefix SHOULD be advertised when no
    > other delegated prefix is valid.

I think most people agree about this.

    > B) Whenever there is any valid delegated prefix, advertisements for an
    > existing autonomously generated ULA prefix MUST be deprecated,
    > i.e. updated with preferred lifetime of zero.

I'm not sure why this is a good thing.

    > D) Whenever there is no longer any valid delegated prefix,
    > advertisements for a previously deprecated autonomously generated ULA
    > prefix MUST be updated with non-zero preferred lifetime.

Does it have to be the same ULA?

Consider the case where there are multiple gateways, which can not see
whether the other gateways have GUA or not.
Given that, how can anyone know when to withdraw the ULA?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [




From nobody Tue Oct 14 17:09:31 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3481A006D for ; Tue, 14 Oct 2014 17:09:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level: 
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKR_bP8nY0Nd for ; Tue, 14 Oct 2014 17:09:28 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 44BEE1A0095 for ; Tue, 14 Oct 2014 17:09:28 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 7FACB2380423; Tue, 14 Oct 2014 20:09:27 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Tue, 14 Oct 2014 19:09:26 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <2AEF8281-D5B2-4A35-B5E6-3FFB33745BC8@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com> 
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/uwofwRXI1ZpDevLtdUOyg3OPEXA
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 00:09:29 -0000

On Oct 14, 2014, at 6:05 PM, James Woodyatt  wrote:
> p2. I do think a locally generated ULA prefix should not be renewed, =
i.e. it should be allowed to expire, when there is *any* prefix =
delegated [GUA or ULA].  Also when additional locally generated ULA =
prefixes are present after a network join. I recognize this view may be =
in a vocal minority, and I can live with a more persistent =
locally-generated ULA prefix so long as there is a standard scheme for =
dealing with prefix accumulation after network joins.

Minority versus majority isn't the issue.

The reason I object to this is that you have control over the lifetime =
of your ULA, but not over the lifetime of your GUA.   Do we really want =
a forced flash renumbering from the ISP to break connections on the =
local network?


From nobody Tue Oct 14 17:09:46 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0D31A00A6 for ; Tue, 14 Oct 2014 17:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.984
X-Spam-Level: 
X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17PqGrrHsV2t for ; Tue, 14 Oct 2014 17:09:37 -0700 (PDT)
Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE3F1A009C for ; Tue, 14 Oct 2014 17:09:37 -0700 (PDT)
Received: by mail-vc0-f180.google.com with SMTP id le20so139600vcb.11 for ; Tue, 14 Oct 2014 17:09:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=qzLep+62aH2BHpO9fM1vRuy7EoWKfOY1F3j7f2eJN08=; b=lsXXz+/IFH2Tw+Ldk5DGyZKp47dTJe4u9DX+Zo+3xY2z9TCmY9rs64YXrqZgKSRr94 ZKNbIGxZRkVB31c2pj3IkcTLvQiwntcm1NOPV2gkiHn5TnkIp4LxgugLd7+WK5ds09B1 WI6sgn2zMVhrr+u5AN6np3J0Dp/NgyGI8zU61tOvg8RlZEZLNeIX+Q5pDvUkdnB84R6n wQUgusAp9g6n7TSPxD/1UiaIZwfhsBiWT13Mwi9GMI5id4Mia49Xqfs7XvYgpFgXlXGX FkboNyL46rTA3e2csRqiAv1UCxh5l/lJ+ZQQoYgp3dmMW0fvVmNr6P44LxWhuYGrQZQ4 FSuw==
X-Gm-Message-State: ALoCoQk0CuN/apzxaeBFHLjUDrRmX6l9QL8IeAX2NBeHgKT08Lbj6Jozdvwj8n4zfCOBIzIm5dYY
MIME-Version: 1.0
X-Received: by 10.220.197.73 with SMTP id ej9mr8893635vcb.40.1413331776411; Tue, 14 Oct 2014 17:09:36 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Tue, 14 Oct 2014 17:09:36 -0700 (PDT)
In-Reply-To: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  
Date: Tue, 14 Oct 2014 17:09:36 -0700
Message-ID: 
From: James Woodyatt 
To: HOMENET Working Group 
Content-Type: multipart/alternative; boundary=001a11c1ebfe7bb21d05056af25c
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/AKiIhh4dnfKGQfiSOV0f8jpBXvA
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 00:09:39 -0000

--001a11c1ebfe7bb21d05056af25c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Consider a hypothetical router that has the regular automatic default
behavior of commissioning a new standalone network while discovering any
existing networks that it already possesses the credentials to join. Now
consider what happens when devices of this category are continually losing
and regaining their connectivity with the rest of the wireless network in
the home. Let's imagine this happens many times per hour. How many days
does it take before all your constrained-resource hosts have no space left
in their route tables for all the deprecated but still valid ULA prefixes?

I suggest it will not take very long at all. Any reasonably implemented
host will be dropping them before they expire anyway, but hosts will be
forced to use a crude heuristic to decide which prefix to expire first,
e.g. lowest valid lifetime then first-in first-out?  Routers are more
knowledgeable about which prefixes are the locally generated ones and which
ones are delegated.

On Tue, Oct 14, 2014 at 4:40 PM, Dave Taht  wrote:

> On Tue, Oct 14, 2014 at 2:40 PM, James Woodyatt  wrote:
> > On Tue, Oct 14, 2014 at 2:35 PM, Ted Lemon  wrote:
> >>
> >>
> >> When we talked about this previously, I think the idea was that when t=
wo
> >> networks with two sets of ULA prefixes merge, you deprecate one of the=
m.
> >> [...]
> >
> >
> > Naturally, you deprecate one of them, but my concern is that they never
> > expire if the objective is for a ULA prefix to be invariant. So how man=
y
> > times can a network join with others before it runs out of space for
> > deprecated and redundant but unexpired and invariant ULA prefixes?
> >
>
> 2^56 times I think...
>
> ... but the network itself would expire long before then. :)
>
> What's a more reasonable bound? What's the bound before a given
> network would collapse from multicast joins alone?
> > --
> > james woodyatt 
> > Nest Labs, Communications Engineering
> >
> > _______________________________________________
> > homenet mailing list
> > homenet@ietf.org
> > https://www.ietf.org/mailman/listinfo/homenet
> >
>
>
>
> --
> Dave T=C3=A4ht
>
> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
>



--=20
james woodyatt 
Nest Labs, Communications Engineering

--001a11c1ebfe7bb21d05056af25c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Consider a hypothetical router that has the regular automa=
tic default behavior of commissioning a new standalone network while discov=
ering any existing networks that it already possesses the credentials to jo=
in. Now consider what happens when devices of this category are continually=
 losing and regaining their connectivity with the rest of the wireless netw=
ork in the home. Let's imagine this happens many times per hour. How ma=
ny days does it take before all your constrained-resource hosts have no spa=
ce left in their route tables for all the deprecated but still valid ULA pr=
efixes?

I suggest it will not take very long at all. Any=
 reasonably implemented host will be dropping them before they expire anywa=
y, but hosts will be forced to use a crude heuristic to decide which prefix=
 to expire first, e.g. lowest valid lifetime then first-in first-out?=C2=A0=
 Routers are more knowledgeable about which prefixes are the locally genera=
ted ones and which ones are delegated.

=

On Tue, Oct 14, 2014 at 4:40 PM, Dave Taht <d=
ave.taht@gmail.com> wrote:
=
On Tue, Oct 14, 2014 at 2:40 PM, James Woodyatt <jhw@nestlabs.com> wrote:

> On Tue, Oct 14, 2014 at 2:35 PM, Ted Lemon <mellon@fugue.com> wrote:

>>

>>

>> When we talked about this previously, I think the idea was that wh=
en two

>> networks with two sets of ULA prefixes merge, you deprecate one of=
 them.

>> [...]

>

>

> Naturally, you deprecate one of them, but my concern is that they neve=
r

> expire if the objective is for a ULA prefix to be invariant. So how ma=
ny

> times can a network join with others before it runs out of space for
> deprecated and redundant but unexpired and invariant ULA prefixes?

>



2^56 times I think...



... but the network itself would expire long before then. :)



What's a more reasonable bound? What's the bound before a given

network would collapse from multicast joins alone?

> --

> james woodyatt <jhw@nestlabs.com>

> Nest Labs, Communications Engineering

>


> _______________________________________________

> homenet mailing list

> homenet@ietf.org=


> https://www.ietf.org/mailman/listinfo/homenet

>








--

Dave T=C3=A4ht



thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_T=
alks





-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Eng=
ineering




--001a11c1ebfe7bb21d05056af25c--


From nobody Tue Oct 14 18:17:59 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7571A010A for ; Tue, 14 Oct 2014 18:17:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level: 
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNu2fFuWzblT for ; Tue, 14 Oct 2014 18:17:55 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A108E1A010E for ; Tue, 14 Oct 2014 18:17:55 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 09D822380423; Tue, 14 Oct 2014 21:17:54 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Tue, 14 Oct 2014 20:17:53 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>   
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/UZzBbfj8J6H9O1yeo0wk8ji7I-s
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 01:17:57 -0000

On Oct 14, 2014, at 7:09 PM, James Woodyatt  wrote:
> Consider a hypothetical router that has the regular automatic default =
behavior of commissioning a new standalone network while discovering any =
existing networks that it already possesses the credentials to join. Now =
consider what happens when devices of this category are continually =
losing and regaining their connectivity with the rest of the wireless =
network in the home. Let's imagine this happens many times per hour. How =
many days does it take before all your constrained-resource hosts have =
no space left in their route tables for all the deprecated but still =
valid ULA prefixes?

I think you are arguing that the solution needs to prevent this =
happening.   I agree.


From nobody Tue Oct 14 21:58:16 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF6A1A0271 for ; Tue, 14 Oct 2014 21:58:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.794
X-Spam-Level: 
X-Spam-Status: No, score=0.794 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, PLING_QUERY=0.279, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_RHS_DOB=0.276] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Chx8j-dwyNl9 for ; Tue, 14 Oct 2014 21:58:14 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E91E1A026C for ; Tue, 14 Oct 2014 21:58:13 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5B636A1; Wed, 15 Oct 2014 06:58:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1413349091; bh=/mnNkAuMQmJJnVRj8U4Or5mrgG1zraAZ0NlZqLG4fYw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=XkAtIkURwpszISrMgFCGvCuECik1FwTL4WfCN5NJBWUXszmN/nFayCjiEcHnpS5HX yfpxFrvvRbksBp4nhSC+ChbiUGbtkolCRBczUA9zefTbpMR8QqGtP9KHqTORXZeKh2 5Ka437NGX+IQVIauf1PAIipg/96X1Y9dadfOiH8A=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4F5A19F; Wed, 15 Oct 2014 06:58:11 +0200 (CEST)
Date: Wed, 15 Oct 2014 06:58:11 +0200 (CEST)
From: Mikael Abrahamsson 
To: Ted Lemon 
In-Reply-To: <48942796-C098-48B6-B894-544499EEB5F3@fugue.com>
Message-ID: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com>  <48942796-C098-48B6-B894-544499EEB5F3@fugue.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/zFgTsV1rufOP5h_Rtp-cCL79i7k
Cc: Erik Kline , HOMENET Working Group , Pierre Pfister , Gert Doering 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 04:58:15 -0000

On Tue, 14 Oct 2014, Ted Lemon wrote:

> Right.  This is IPv4.  In IPv4 we typically use a NAT on the local wire, 
> so we get the effect we are trying to achieve either by retaining stale 
> GUAs or using ULAs on the local wire in homenets.  IPv4 also does not 
> provide graceful renumbering, so if the ISP wants to force an IPv4 
> address change, they have no choice but to do flash renumbering.  The UX 
> is not good.

Just to be clear, I am against flash renumbering, I want to see 
renumbering done with 30-60 minute overlap at least. I however do see that 
we really really need to support renumbering. One way of making sure that 
support works is to expose applications to frequent renumbering.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Wed Oct 15 01:02:44 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F521A0410 for ; Wed, 15 Oct 2014 01:02:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.387
X-Spam-Level: *
X-Spam-Status: No, score=1.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_NEUTRAL=0.779, URIBL_RHS_DOB=1.514] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qc9IeCAzi-CU for ; Wed, 15 Oct 2014 01:02:40 -0700 (PDT)
Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8314F1A040B for ; Wed, 15 Oct 2014 01:02:40 -0700 (PDT)
Received: from poro.lan (80.220.64.126) by jenni2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 543C16C90021EF49; Wed, 15 Oct 2014 11:02:33 +0300
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Markus Stenberg 
In-Reply-To: 
Date: Wed, 15 Oct 2014 11:02:26 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E43B678-A2F9-4289-93E9-A6A98BEE82A1@iki.fi>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com>  <48942796-C098-48B6-B894-544499EEB5F3@fugue.com> 
To: Mikael Abrahamsson 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/yIINvvUQkSwU6Mt1vqWpVwLfPmg
Cc: Markus Stenberg , Ted Lemon , Pierre Pfister , Erik Kline , HOMENET Working Group , Gert Doering 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 08:02:43 -0000

On 15.10.2014, at 7.58, Mikael Abrahamsson  wrote:
> On Tue, 14 Oct 2014, Ted Lemon wrote:
>> Right.  This is IPv4.  In IPv4 we typically use a NAT on the local =
wire, so we get the effect we are trying to achieve either by retaining =
stale GUAs or using ULAs on the local wire in homenets.  IPv4 also does =
not provide graceful renumbering, so if the ISP wants to force an IPv4 =
address change, they have no choice but to do flash renumbering.  The UX =
is not good.
> Just to be clear, I am against flash renumbering, I want to see =
renumbering done with 30-60 minute overlap at least. I however do see =
that we really really need to support renumbering. One way of making =
sure that support works is to expose applications to frequent =
renumbering.

So essentially IPv6 home network would be ultimately worse platform than =
IPv4 one?

Because no matter what ISP does, my IPv4 prefixes in my home _are_ =
stable. And IPv6 ones too (thanks to using statically configured tunnel, =
cough).

I would argue that flash renumbering is bad too, but I would also claim =
that overlap of less than session lifetime is not acceptable. .. some of =
my session lifetimes are in days (single TCP session). Or are we =
planning to ultimately deprecate TCP and advocate something else? MPTCP? =
Yes, I know typical home user has just HTTP requests, but I am not fond =
of idea of turning the network to short-lived-connections only model =
just because it seems currently the most popular way to do things.

Every time I hear about ISP-forced customer renumberings, the more I =
start to think that 1+ ULA prefixes per home is a MUST, not a SHOULD.

Cheers,

-Markus=


From nobody Wed Oct 15 02:48:57 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FBD1A017A for ; Wed, 15 Oct 2014 02:48:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.847
X-Spam-Level: 
X-Spam-Status: No, score=0.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_RHS_DOB=1.514] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czRpx2pfN988 for ; Wed, 15 Oct 2014 02:48:52 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59821A0072 for ; Wed, 15 Oct 2014 02:48:51 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 131EFA1; Wed, 15 Oct 2014 11:48:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1413366530; bh=+7Oc+icKngVsrgTjAN2RjCF0xQNcmY1dRSXOJLehOEY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=vMqKB0NU+wW+2jewkDPVbBuBaUG0BPEQiTcQOhcxxk/1E7Ac2YXuv0LD5gGhvO5cO dvaE+cqVkbd5rtSeGo/+lyzysPQSppht7Gz2o/JgzLTAQfvTqcXTFqxDvd86MY80au J1C6bn0i2dBlo6cimJBFsAhFpqVFfJak2OTo/BW8=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 081619F; Wed, 15 Oct 2014 11:48:50 +0200 (CEST)
Date: Wed, 15 Oct 2014 11:48:49 +0200 (CEST)
From: Mikael Abrahamsson 
To: Markus Stenberg 
In-Reply-To: <5E43B678-A2F9-4289-93E9-A6A98BEE82A1@iki.fi>
Message-ID: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com>  <48942796-C098-48B6-B894-544499EEB5F3@fugue.com>  <5E43B678-A2F9-4289-93E9-A6A98BEE82A1@iki.fi>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/IWnmDHQK4VSKOTy0krAcLUBOcKM
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 09:48:53 -0000

On Wed, 15 Oct 2014, Markus Stenberg wrote:

> Every time I hear about ISP-forced customer renumberings, the more I 
> start to think that 1+ ULA prefixes per home is a MUST, not a SHOULD.

For me this isn't just about ISP-forced customer renumberings, but to also 
handle power outages, equipment malfunction (so you lose your lease), 
equipment change, ISP change, and all other things that today will make 
you change the IPv4 address a few times a year or something.

I believe we should use SHIM6, MP-TCP, "mosh" and other similar techniques 
to make sure that we can move sessions around when doing renumbering.

IPv6 has the infrastructure on L3 to handle renumbering gracefully, now we 
just need L4 and applications to get with the program as well. I would 
really like to see us go in the way of IP addresses not being the single 
anchorpoint of all communication, we need to make sure that we have other 
mechanisms such as L4 protocols being "agile" when it comes to IP address 
change over time, and also having DNS or other mechanism being able to be 
updated with information over time to enable this mobility.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Wed Oct 15 04:14:34 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FB41A1AD6 for ; Wed, 15 Oct 2014 04:14:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.987
X-Spam-Level: **
X-Spam-Status: No, score=2.987 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, PLING_QUERY=0.994, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60_rG4wFFNTO for ; Wed, 15 Oct 2014 04:14:31 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1061A1AD5 for ; Wed, 15 Oct 2014 04:14:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id CEB0948; Wed, 15 Oct 2014 13:14:27 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1413371665; bh=Sf8YQeLxaepJHqZlC1AHrRQzeBS5uEwWZT7Zs2jy2B0=; b=V YecVSAZER6fTUp3qgjUX4NQenOWuuvYGJdJVKNIgXLjiaFnseRL+4C2eet4uUQX4 SgrtZ9HMh5ms7C4r5OQ7OQk1mc7g7GunQuO3Q9uEPVn7yivEw+fPkGBNToCCP1zZ S24psy/lnd9aRBLd2398daWos3c7H/VhSYR02XB0Xg=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id muGXbv1QMeUg; Wed, 15 Oct 2014 13:14:25 +0200 (CEST)
Received: from [IPv6:2a00:8640:1::a948:e9d0:959f:2316] (unknown [IPv6:2a00:8640:1:0:a948:e9d0:959f:2316]) by mail.sintact.nl (Postfix) with ESMTPSA id 65D913A; Wed, 15 Oct 2014 13:14:25 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Sander Steffann 
In-Reply-To: 
Date: Wed, 15 Oct 2014 13:14:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <828EDE1E-7697-44EF-AF8B-D6F945737073@steffann.nl>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>   
To: James Woodyatt 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/b0Ce24msaLA-53oiZpBEbp5J24I
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 11:14:32 -0000

Hi James,

> Consider a hypothetical router that has the regular automatic default =
behavior of commissioning a new standalone network while discovering any =
existing networks that it already possesses the credentials to join. Now =
consider what happens when devices of this category are continually =
losing and regaining their connectivity with the rest of the wireless =
network in the home. Let's imagine this happens many times per hour. How =
many days does it take before all your constrained-resource hosts have =
no space left in their route tables for all the deprecated but still =
valid ULA prefixes?

Does it have to be a *new* standalone network (ULA prefix)? The router =
could just generate a ULA prefix once and reuse it whenever it needs to, =
right? Generating a new prefix on every connect/disconnect would indeed =
cause a mess...

Cheers,
Sander


From nobody Wed Oct 15 07:49:01 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6321A870C for ; Wed, 15 Oct 2014 07:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.496
X-Spam-Level: **
X-Spam-Status: No, score=2.496 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_RHS_DOB=1.514] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6X6JltoWYOr for ; Wed, 15 Oct 2014 07:48:57 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 82C791A8711 for ; Wed, 15 Oct 2014 07:48:57 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 46524238045C; Wed, 15 Oct 2014 10:48:55 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <5E43B678-A2F9-4289-93E9-A6A98BEE82A1@iki.fi>
Date: Wed, 15 Oct 2014 09:48:53 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <3D9F27DB-C521-4D14-9FF6-CDE0F6B65C44@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com>  <48942796-C098-48B6-B894-544499EEB5F3@fugue.com>  <5E43B678-A2F9-4289-93E9-A6A98BEE82A1@iki.fi>
To: Markus Stenberg 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/8Weq1P37XnVu7CJf2OYBr5aK86o
Cc: Erik Kline , HOMENET Working Group , Pierre Pfister , Gert Doering , Mikael Abrahamsson 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 14:48:59 -0000

> On 15.10.2014, at 7.58, Mikael Abrahamsson  wrote:
>> Just to be clear, I am against flash renumbering, I want to see =
renumbering done with 30-60 minute overlap at least. I however do see =
that we really really need to support renumbering. One way of making =
sure that support works is to expose applications to frequent =
renumbering.

We do need to support renumbering.   For graceful renumbering, most =
common applications already support it with no problem, although 30-60 =
minutes is too short, because that will break for example a movie =
stream.   But a 30-60 minute overlap will work fine for web browsing and =
nearly all applications a typical end-user uses other than long movies.

There are applications that will fail because they bind to an address =
and have no error recovery mechanism for when the address goes away, but =
AFAIK these are quite uncommon.   So really you are proposing a very =
expensive cure for an insignificant problem.

On Oct 15, 2014, at 3:02 AM, Markus Stenberg  =
wrote:
> Every time I hear about ISP-forced customer renumberings, the more I =
start to think that 1+ ULA prefixes per home is a MUST, not a SHOULD.

I'm not sure I'd go that far, but it's definitely a really strong =
SHOULD.=


From nobody Wed Oct 15 07:52:40 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71AFF1A870C for ; Wed, 15 Oct 2014 07:52:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.983
X-Spam-Level: 
X-Spam-Status: No, score=0.983 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, PLING_QUERY=0.994, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDpaD3nlZKvq for ; Wed, 15 Oct 2014 07:52:36 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580461A1ADC for ; Wed, 15 Oct 2014 07:52:36 -0700 (PDT)
X-Original-To: homenet@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 5E249608AC for ; Wed, 15 Oct 2014 16:52:34 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 342B560885 for ; Wed, 15 Oct 2014 16:52:34 +0200 (CEST)
Received: (qmail 75371 invoked by uid 1007); 15 Oct 2014 16:52:34 +0200
Date: Wed, 15 Oct 2014 16:52:34 +0200
From: Gert Doering 
To: Mikael Abrahamsson 
Message-ID: <20141015145234.GU31092@Space.Net>
References:  <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com>  <48942796-C098-48B6-B894-544499EEB5F3@fugue.com>  <5E43B678-A2F9-4289-93E9-A6A98BEE82A1@iki.fi> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/JriLu8Of_5tqE5wqYHNmz2ypDNk
Cc: HOMENET Working Group , Markus Stenberg 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 14:52:38 -0000

Hi,

On Wed, Oct 15, 2014 at 11:48:49AM +0200, Mikael Abrahamsson wrote:
> I believe we should use SHIM6, MP-TCP, "mosh" and other similar techniques 
> to make sure that we can move sessions around when doing renumbering.
> 
> IPv6 has the infrastructure on L3 to handle renumbering gracefully, now we 
> just need L4 and applications to get with the program as well. I would 
> really like to see us go in the way of IP addresses not being the single 
> anchorpoint of all communication, we need to make sure that we have other 
> mechanisms such as L4 protocols being "agile" when it comes to IP address 
> change over time, and also having DNS or other mechanism being able to be 
> updated with information over time to enable this mobility.

This.

(And yes, stable IPv6 addresses are so much more convenient, you can put
them into /etc/hosts and all that.  Wait, /etc/hosts got deprecated?  When
did that happen?  Right :-) ).

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279


From nobody Wed Oct 15 07:58:48 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C581A872F for ; Wed, 15 Oct 2014 07:58:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.983
X-Spam-Level: 
X-Spam-Status: No, score=0.983 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, PLING_QUERY=0.994, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4i3Bv-OUAnE for ; Wed, 15 Oct 2014 07:58:45 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B5C1A1ADA for ; Wed, 15 Oct 2014 07:58:44 -0700 (PDT)
X-Original-To: homenet@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 6A2A360983 for ; Wed, 15 Oct 2014 16:58:43 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 2DCA2608AC for ; Wed, 15 Oct 2014 16:58:43 +0200 (CEST)
Received: (qmail 76097 invoked by uid 1007); 15 Oct 2014 16:58:43 +0200
Date: Wed, 15 Oct 2014 16:58:43 +0200
From: Gert Doering 
To: Philip Homburg 
Message-ID: <20141015145843.GV31092@Space.Net>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0MLgmWdLrzBmKqS8"
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/WnBM4LvtxKCjsuJN0A86ZbpwHiM
Cc: HOMENET Working Group , Gert Doering 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 14:58:46 -0000

--0MLgmWdLrzBmKqS8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Oct 14, 2014 at 06:17:28PM +0200, Philip Homburg wrote:
> But then when I tell other people, they can't do it. Because on a consume=
r lines
> it is just too complicated.

Isn't the main thing that "other people are just plain not interested in=20
doing so in the first place"...?

Please understand that there are way more non-geeks out there that have
no interest in computers except "use them" than there are geeks who care
about IP addressing.  *Our* job is to make it work for *them*, without
forcing our world view on them ("they need to be able to put a static
IP address in DNS!" - no, my mom doesn't need to do that)

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--0MLgmWdLrzBmKqS8
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVD6Lot9WwGXkzn/FAQJXVA/+KAJaJgXw66xIA/DNOnQUAaYhnrBMFAjM
3VW3/CEPC4/ygGdLvYsNpClIqjaB37bpRjMVlErWNMmXn4aIKuciZIqzWjXa6d9/
RDlGkUHyS4n3voIf+lQtbQ+17EfXxwDIczWljYYA50z6wPY8Hh4Y+drJzgE8jmG+
BOGZP4KU68q/iAijzZ7QuMfr9jXQn/XMWQyhhUArQPlyHcwP6q00c+zER8dzdOzg
2XdrARNB6EMv4OgCkqsJIfL17ggbpQ2el4f404FKPGgdvaQFL/40wdQO4Iq073iF
mx6fHBFqgZ+8E4Ms7dHOf18Tt1VdslbE/xFQaQQ1OajbctCPlJE3FjRb7U2/jFoI
0cllbcVBWNNirGjp+WqKKcQ0UDDAGLNuvYHj4MTxLi2zb11DLnhE6nyRTa+WLQ7h
xqLNanqWKxmxTWYyQFw851vLyKKRkJ1VaHtQYZ5tARUhCGGIBWYMQQO2zDsuzWwm
y64DBjTtP6XARxUWINZh8/7v6rA7Idb2dV3xICcPJWWEqUN5u0ApOOgITD9FcMAx
HOKyg3SsuIrXpw0gouuw141v60yscOIZckXbWGIfV2QwVQtWJbf6/2OFWczIZG1p
f9ugTpko3EHktO6Sd4JGXX/DeBEpBUVw8MpDCVMe+wlQ9UrBB+g+grfdQfrBZxrt
nowyqTMYBrU=
=szwc
-----END PGP SIGNATURE-----

--0MLgmWdLrzBmKqS8--


From nobody Wed Oct 15 08:04:46 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BEA1A8768 for ; Wed, 15 Oct 2014 08:04:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.983
X-Spam-Level: 
X-Spam-Status: No, score=0.983 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, PLING_QUERY=0.994, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY6VVYKtBHQu for ; Wed, 15 Oct 2014 08:04:36 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8DA71A874C for ; Wed, 15 Oct 2014 08:04:24 -0700 (PDT)
X-Original-To: homenet@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C8232609A3 for ; Wed, 15 Oct 2014 17:04:22 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 878966032F for ; Wed, 15 Oct 2014 17:04:22 +0200 (CEST)
Received: (qmail 77093 invoked by uid 1007); 15 Oct 2014 17:04:22 +0200
Date: Wed, 15 Oct 2014 17:04:22 +0200
From: Gert Doering 
To: Ted Lemon 
Message-ID: <20141015150422.GW31092@Space.Net>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JfAz7WldtWFtponG"
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/YwyB90QGG1LMBzosbz63TA4T-K0
Cc: HOMENET Working Group , Philip Homburg , Gert Doering 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 15:04:37 -0000

--JfAz7WldtWFtponG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Oct 14, 2014 at 11:21:12AM -0500, Ted Lemon wrote:
> On Oct 14, 2014, at 10:41 AM, Gert Doering  wrote:
> > That reply doesn't surprise me the least, it's the standard answer from
> > every geek who has not spent a few weeks thinking about this :-)
>=20
> This isn't a helpful response, Gert.   If you are right, you can
> explain the reason that you are right.   You don't have to accuse
> the people you are talking to of not thinking this through.

I explained my reasoning.  Multiple times.  Here and on other lists.  Again
and again.  And I spend a lot of time testing things, running against walls,
and telling people what needs to be improved to make it work.  Since years.

But I still run headlong into the typical geek response "I do things in
my network that are not compatible to this" - and, well, so do I, but
that is a completely irrelevant point of view when talking about homenets
that are used by millions of non-geeks plus a few IETF geeks.

*This* is the widening of horizon that is needed for meaningful contribution
to this discussion.  "I'll just get me a tunnel" is not.

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--JfAz7WldtWFtponG
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVD6M9t9WwGXkzn/FAQK1sg//Y7JR+8o11koTiDWjbDu5LBKLYFZu7Wma
HZRITIQ8Y/+upyns599ywPph0LO6yvyVa8WXQ+qNbhU44cbjUSETqoot6KRPkzBp
kZZK7YvjW80l+mbhDe7QkbvtDiKViHeJ2dw3HR5xQkzueepr1Ymyx0Y8NFahJii0
srTs41LDec3zuYzYftRy79D25jVm0YNk6kcYayTYZ/tz7h9UoQ90iotZXOy12vBf
ADDJ7MCWcPFlS18ldWA7n6pVBeFhNB5eL3HSt19tW0d3yUgsGnwB4ryotKIQAOYL
suPmZfUzA+gTjUAfFDnHugBkPDKhCPsoO+3MV145xODSbohzAigDXlMz7cGLuNIP
7lS/X7bTuRQgoclILRlAF98xgW4gVXI1dG4DnjpRk8xYhjftg4TERq+cD6a0bmqZ
Cq6BxyyDhR5jiQGrRQF5Psj6WnNnf/eDbX3Ytygulg+HAsGSZIQqQuv9HGVjvkVV
hKxDx7sh+cKgybxRgqM+E1+VkYg+jzhYFYt3lmhUQ4QeKsjgyiuEpPWQx8hDEiG2
8XiqiVunYzAedRAaRkoRnuZpkz2kbPe2op6mrgB/6LXhS2J2o8NJxjvSqhmURTsz
quDD4zRwBp+yvjGrcStlk8IpSWTHyISXRbNRjqrwCWG6QUw0P2fOAcUnfFRHcoMH
SUTXr2JHKC0=
=hgGq
-----END PGP SIGNATURE-----

--JfAz7WldtWFtponG--


From nobody Wed Oct 15 08:21:19 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC351A8744 for ; Wed, 15 Oct 2014 08:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.137
X-Spam-Level: 
X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJ3tD6TAFv6m for ; Wed, 15 Oct 2014 08:21:15 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697021A1B1C for ; Wed, 15 Oct 2014 08:21:15 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s9FFLCOu019138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Oct 2014 18:21:12 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s9FFLBc9016841; Wed, 15 Oct 2014 18:21:11 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21566.37095.559360.571810@fireball.kivinen.iki.fi>
Date: Wed, 15 Oct 2014 18:21:11 +0300
From: Tero Kivinen 
To: Markus Stenberg 
In-Reply-To: <5E43B678-A2F9-4289-93E9-A6A98BEE82A1@iki.fi>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com>  <48942796-C098-48B6-B894-544499EEB5F3@fugue.com>  <5E43B678-A2F9-4289-93E9-A6A98BEE82A1@iki.fi>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 13 min
X-Total-Time: 14 min
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/nyCZ8ptg_qhpyPP1Z5KhB59Acy4
Cc: Ted Lemon , Pierre Pfister , Erik Kline , HOMENET Working Group , Gert Doering , Mikael Abrahamsson 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 15:21:17 -0000

Markus Stenberg writes:
> Because no matter what ISP does, my IPv4 prefixes in my home _are_
> stable. And IPv6 ones too (thanks to using statically configured
> tunnel, cough).

When we defined a recommendation for ISPs in Finland for IPv6, we
suggested that ISPs should always give same prefix to same customer,
and when giving out the addresses, they should set the preferred
lifetime to 7 days, and valid lifetime to be 30 days, i.e. even if the
network connection is down for several weeks, the IPv6 addresses
inside the house are still usable. Of course if there is power outage
and every device in the network looses power, and there is no network
connectivity when they come back up, that usually means there is no
valid IPv6 addresses anymore, unless they are statically configured
somewhere (or stored to the stable storage by the routers). 

> I would argue that flash renumbering is bad too, but I would also
> claim that overlap of less than session lifetime is not acceptable.
> .. some of my session lifetimes are in days (single TCP session). Or
> are we planning to ultimately deprecate TCP and advocate something
> else? MPTCP? Yes, I know typical home user has just HTTP requests,
> but I am not fond of idea of turning the network to
> short-lived-connections only model just because it seems currently
> the most popular way to do things. 

My ssh connections are usually up and running for ever. They only go
down when I update my firewall, there is network problems, or our
company firewall is reset for some reason. Usually that means the ssh
connection is up for few months... I would be very unhappy I would
need to restart my TCP connections every month, so any ISP giving me
such notwork, would not be consider as proper ISP, and I would
immediately switch to another ISP if my ISP starts doing things that
break my connections. 

> Every time I hear about ISP-forced customer renumberings, the more I
> start to think that 1+ ULA prefixes per home is a MUST, not a
> SHOULD. 

Most of my long lived connections are from my office to my home, or
from my home to my summer house. I.e there are some connections inside
my home which are longlived, but also the global IP-addresses need to
be stable enough for my use cases, i.e. ULA would not help me that
much. 
-- 
kivinen@iki.fi


From nobody Wed Oct 15 08:34:23 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16921A87EC for ; Wed, 15 Oct 2014 08:34:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkHOF_x2MzaN for ; Wed, 15 Oct 2014 08:34:20 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6E06B1A87EB for ; Wed, 15 Oct 2014 08:34:20 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 8ADC82381535; Wed, 15 Oct 2014 11:34:19 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <20141015150422.GW31092@Space.Net>
Date: Wed, 15 Oct 2014 10:34:17 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net>
To: Gert Doering 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/0Zb0DjpdcommMg1SGRBhKLraDxw
Cc: HOMENET Working Group , Philip Homburg 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 15:34:21 -0000

On Oct 15, 2014, at 10:04 AM, Gert Doering  wrote:
> I explained my reasoning.  Multiple times.  Here and on other lists.  =
Again
> and again.

When you repeat yourself again and again, people stop listening to you.  =
 There was a consensus call done on this, and the architecture document =
contains the results of that consensus.   If you have some additional =
objection to raise, you should raise it, but I'm very sorry, you do have =
to show your work.   You can't just make assertions about what you think =
is true, and expect your opinion to count in the consensus call.   We =
don't vote in the IETF, so opinions just don't make sense in that =
context.

In particular, you appear to be arguing as if ULAs and GUAs are treated =
identically by IPv6 stacks, but they are not.   So while I agree that =
there is a real problem making this work for multi-homed homenets (a =
problem, by the way, which homenet has decided to try to solve), this is =
completely orthogonal to the question of whether we should use ULAs in =
the homenet.


From nobody Wed Oct 15 08:47:18 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC4F1A8873 for ; Wed, 15 Oct 2014 08:47:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.906
X-Spam-Level: 
X-Spam-Status: No, score=-0.906 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8r0YvWjoCIqR for ; Wed, 15 Oct 2014 08:47:06 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 97E871A8865 for ; Wed, 15 Oct 2014 08:47:05 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XeQn2-0000I3C; Wed, 15 Oct 2014 17:47:04 +0200
Message-Id: 
To: Gert Doering 
From: Philip Homburg 
Sender: pch-bBB316E3E@u-1.phicoh.com
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015145843.GV31092@Space.Net> 
In-reply-to: Your message of "Wed, 15 Oct 2014 16:58:43 +0200 ." <20141015145843.GV31092@Space.Net> 
Date: Wed, 15 Oct 2014 17:47:02 +0200
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/gDJ4l_4HaQRWxoglNyyB3xx6GVw
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 15:47:15 -0000

In your letter dated Wed, 15 Oct 2014 16:58:43 +0200 you wrote:
>Please understand that there are way more non-geeks out there that have
>no interest in computers except "use them" than there are geeks who care
>about IP addressing.  *Our* job is to make it work for *them*, without
>forcing our world view on them ("they need to be able to put a static
>IP address in DNS!" - no, my mom doesn't need to do that)

Our current 'world view' is that companies get stable addresses. Consumers get
crap.

We invent complicated stuff like dynamically turning ULA on and off that nobody
else uses. We force renumbering in the name of privacy, etc.

We start by giving consumers a swamp and then try to build something on top of
it.

We make choices, like the DNS server has to be in the router, because only the
router knows about the current prefix, etc.



From nobody Wed Oct 15 08:48:55 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B6B1A887E for ; Wed, 15 Oct 2014 08:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.983
X-Spam-Level: 
X-Spam-Status: No, score=0.983 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, PLING_QUERY=0.994, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbX-KaE4Ls8Q for ; Wed, 15 Oct 2014 08:48:43 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812F61A8866 for ; Wed, 15 Oct 2014 08:48:43 -0700 (PDT)
X-Original-To: homenet@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 333906095F for ; Wed, 15 Oct 2014 17:48:42 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id F29B060765 for ; Wed, 15 Oct 2014 17:48:41 +0200 (CEST)
Received: (qmail 82460 invoked by uid 1007); 15 Oct 2014 17:48:41 +0200
Date: Wed, 15 Oct 2014 17:48:41 +0200
From: Gert Doering 
To: Ted Lemon 
Message-ID: <20141015154841.GY31092@Space.Net>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QwVuF0T/sxuZ/Zeu"
Content-Disposition: inline
In-Reply-To: <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Dr0FPYLBeKsGIbuenw1k6WItIMk
Cc: HOMENET Working Group , Philip Homburg , Gert Doering 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 15:48:44 -0000

--QwVuF0T/sxuZ/Zeu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, Oct 15, 2014 at 10:34:17AM -0500, Ted Lemon wrote:
> On Oct 15, 2014, at 10:04 AM, Gert Doering  wrote:
> > I explained my reasoning.  Multiple times.  Here and on other lists.  A=
gain
> > and again.
>=20
> When you repeat yourself again and again, people stop listening to you.  =
=20

Well, there are some people in the IETF that really don't know how to
listen, but that's not particular to *me*...

Some other people seem to understand what I say, and agree with it, or
sometimes disagree with the particulars, based on practical experience,
or on understanding my points.

> There was a consensus call done on this, and the architecture document=20
> contains the results of that consensus.   If you have some additional=20
> objection to raise, you should raise it, but I'm very sorry, you do=20
> have to show your work.   You can't just make assertions about what you=
=20
> think is true, and expect your opinion to count in the consensus call.  =
=20
> We don't vote in the IETF, so opinions just don't make sense in that cont=
ext.

Huh, what?  Maybe I have problems listening as well.  I fully fail to
see how this paragraph relates to anything I have stated in the thread
- which strayed from the subject of "ULA or not" quite a bit to "what
happens out there in the real world".


> In particular, you appear to be arguing as if ULAs and GUAs are
> treated identically by IPv6 stacks, but they are not.  =20

This was not my point, and isn't, as it is not relevant.

My point in this discussion is that applications need to handle changing
addresses under their feet, while the application is running, and in
quite a number of cases, while a session is established (to pick
up the "I ssh to my summer house and leave that session running for
months" example - well, add homenet multihoming to the mix, and you=20
really want MPTCP, shim6 or something like mosh to handle "oh, and=20
I really want my SSH session to stay up even if one of my ISPs goes=20
down for a few days").

This is fully independent of the question "do we add ULA to the mix or=20
not", as ULAs are irrelevant for communication to partners outside the=20
home (as long as nobody puts ULAs into global DNS).

As far as "SHOULD or MUST", I don't have a strong opinion either way,
as local communication is just a special case of global communication - and
if global comms can handle changing addresses, getting that right for
local comms is *so* much easier.  My homenet test setup works nicely
with two ISPs, four partially-meshed HNCP routers, and no ULAs at all,=20
but having another address won't make much difference...


> So while I
> agree that there is a real problem making this work for multi-homed
> homenets (a problem, by the way, which homenet has decided to try
> to solve), this is completely orthogonal to the question of whether
> we should use ULAs in the homenet.

Indeed.

Could you remind me what your point was?

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--QwVuF0T/sxuZ/Zeu
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVD6XWd9WwGXkzn/FAQKarBAAnL4OObvS3B68bws2WF97DTesDBJmsE/S
VldgoYrkZNhROIhf6+WH1w5DNeHLrd2OdSgBv2rdFNqjyHx0QZjsaheapJrT1EHg
FmRhBUd/sedpWhNe8Li0XjDToV43RAGEYdkrm4pCJfLDrYN336ZQzcvWZdeIRh9b
6A83m50SrmIrs5k4ta3oSIYI32h8RogmJ+gVQk3jlRANvC0+z5Vtxdb61k/1waAP
RKw7w/r54JFKdv+7gPCQpy77fjdXseet3D9tiho2+AlsqxhnvdpTjw3cNViP/AvV
JRna5QEKnv0jFK6mnAnBH9vAdwyde23nrIyNewWhgYYjC5KeLOmlGZJgWRRvNK2b
kTnkMjtWYIdcR5I1X8Wn5tktzB83z6xZQAsJ0OYQMjvx36Cw3sIfydCxuHJ8eHXi
7lp0sCsOlSWkfuBga0W0IBqSAXdtTqjBuDiwfrcGi1ueVPl2xiIPBxTbaWxeiTeU
z45vpYKc9rmXZF8UzsxIgrZWdLQERkHq0l09Aw1FY7mZs52ISs3aNNA/10alMgfK
3Cx0c7eCWhHQf7eqzwyH58E5S/FUQMfTZa4sLiodiX3MO3sosVSiH0Csq+GJVhDk
vLmYOdhxfNM6NxMv4PanDQvOJ4DozUjRocdtMJQag5HgQpvZABvjM5Clj0gXy7YK
sbwDB/B7x3E=
=l6aK
-----END PGP SIGNATURE-----

--QwVuF0T/sxuZ/Zeu--


From nobody Wed Oct 15 08:58:34 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793C81A887D for ; Wed, 15 Oct 2014 08:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.216
X-Spam-Level: 
X-Spam-Status: No, score=-0.216 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, PLING_QUERY=0.994, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6xxkoKEDoh3 for ; Wed, 15 Oct 2014 08:58:29 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 863FF1A8885 for ; Wed, 15 Oct 2014 08:58:28 -0700 (PDT)
X-Original-To: homenet@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3EC56608AC for ; Wed, 15 Oct 2014 17:58:27 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 03446602B3 for ; Wed, 15 Oct 2014 17:58:27 +0200 (CEST)
Received: (qmail 83443 invoked by uid 1007); 15 Oct 2014 17:58:26 +0200
Date: Wed, 15 Oct 2014 17:58:26 +0200
From: Gert Doering 
To: Philip Homburg 
Message-ID: <20141015155826.GZ31092@Space.Net>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015145843.GV31092@Space.Net> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vXro1L/x2znvSlmN"
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/d3eAodgkGUc9nKvrmaSStZ5bTTM
Cc: HOMENET Working Group , Gert Doering 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 15:58:31 -0000

--vXro1L/x2znvSlmN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, Oct 15, 2014 at 05:47:02PM +0200, Philip Homburg wrote:
> In your letter dated Wed, 15 Oct 2014 16:58:43 +0200 you wrote:
> >Please understand that there are way more non-geeks out there that have
> >no interest in computers except "use them" than there are geeks who care
> >about IP addressing.  *Our* job is to make it work for *them*, without
> >forcing our world view on them ("they need to be able to put a static
> >IP address in DNS!" - no, my mom doesn't need to do that)
>=20
> Our current 'world view' is that companies get stable addresses. Consumer=
s get
> crap.

Well, "we" are not calling it "crap", we call it "make it work and scale",
but otherwise, I agree that there is a difference between "large companies"
and "SOHO companies and end users" (the homenet approach works perfectly
well for a typical SOHO network - a few PCs, a printer, some file storage,
mail server hosted "as a service with filtering" elsewhere, etc.) - and
that's the numbers of each.


> We invent complicated stuff like dynamically turning ULA on and off that =
nobody
> else uses. We force renumbering in the name of privacy, etc.

Thing is, we invented DNS, so people do not have to rely on fixed addresses
in their /etc/hosts.  Then people invented mDNS so inside the home, nobody
would have to understand how to handle a DNS zone.

So you think DNS and mDNS should have never done either, because it paves=
=20
the way down the hill?

Unless you can come up with a routing architecture that can handle stable
end users addresses (as in "whatever the customer does, wherever he moves
his ISP connection to, and how many ISPs he's going to have") for all
the end users out there, your world view is not actually very helpful.

DNS, mDNS, SIP register, and such stuff exist that nobody has to rely on=20
IP addresses never changing, and that people can focus on useful labels
instead (like, "hostnames" or "telephone numbers", which in itself are
only useful because phone books exist to map a name to a number and
traditional phones could not call names).

Gert Doering
        -- NetMaster
--=20
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

--vXro1L/x2znvSlmN
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVD6Zot9WwGXkzn/FAQK94hAAkW6XKvFC3Y1WQx1ES4YP2F4LU4bULU9H
c7NwEp1fDRKBBfLljrDBgtWSq5b2eYVeeF9paQPEb+kKVCKvlu3Czjj6Uwn+RAI4
KcBbrDxVdlJJgEF+vcWrWcQFisRmIHvZLoOVvHJZz5HG7b3AWVOn7uHOaxqtjUyJ
oOYC/Gg+aHpYctQxbL3hk1Ggvbb4SIhfOOLYzu6tZYMwHFgZUBCFSRr4UwdnVQGC
it+7TD4xTIALxtSV2cPUKNdotGkB1aCzZuASYqaCFqCQqpraqVLU3k6yZj02x2Wt
agwAXI+JT3BEYNtASA8i0A2Ty5IZ9cTA6mTASL9HTxLBrXZzU8FCCn2IOOjv6Smb
8J9PD5MZUzy9mD67FsLvVdGswWg0++bY5F18qK7Aa8k+/YNHxuUl8gJYoK3dK6to
54n48QixZdr0/GL3DMaWZYmakyds3qwcDZthc0kB8Jk03gbAVCMV4cCdQy0BEn64
OGyM8l/fum7KDuU1q/IypYd7MKedg+b5fCMikGNyO9sR7xkD57Ts2DIffbNY8mJZ
ouQT6flsi3seY7RutRoe5hHVjXvwvQsTG6LA1n5G5J0A4Gtx0FC1H81/MOz+QOn2
qs6m2FRQ6mtu///cAVLsp7pf+Er3nA/BXJUJdOr7b68P3YYVlPHSMLGOLni0XILy
VHdWOTrQRxA=
=oTLi
-----END PGP SIGNATURE-----

--vXro1L/x2znvSlmN--


From nobody Wed Oct 15 09:01:05 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36441A88A1 for ; Wed, 15 Oct 2014 09:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.006
X-Spam-Level: 
X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b63fLlYF5c-i for ; Wed, 15 Oct 2014 09:00:56 -0700 (PDT)
Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7861A88A3 for ; Wed, 15 Oct 2014 09:00:56 -0700 (PDT)
Received: by mail-qa0-f50.google.com with SMTP id w8so1033234qac.37 for ; Wed, 15 Oct 2014 09:00:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9JooNwt8esseaGu43cX9P+pRfqw8jcWkT4r1eraT84s=; b=fJ9K5USws3dDoc7KR53Iov4ZgcQhsslToBYwfCmLuNmBKZvNHnHXNQfMhPFkJApH6u v0kMw2Bu7NA6btzjcXaQHrxGwqeWBPlHLaMWKNRSb05dxtIcqDIQNeyqFgLro/EcQP2v G+HZgajw4Iiq5zsNx3PfjvyDrbMGMrG3EKZST05H6O5yloHCN4KpWoCMX7nOa0Fzr+qV 9ci5a4TqvzOWtAeu8q2WE3jIIHhW3sm9Mv3cfkeGtTRaQJvSeRAnBcnbDhceZXZgAaFU a8zja5gkjwOjX0Se+MNHSRJVOsSMp84LdOPBtNzgpy6FuqiEZMOfG6y1iO+jDA1iQWuB faqA==
X-Received: by 10.224.130.130 with SMTP id t2mr22619910qas.2.1413388855734; Wed, 15 Oct 2014 09:00:55 -0700 (PDT)
Received: from [10.131.36.125] (rtp-isp-nat-pool1-1.cisco.com. [64.102.254.34]) by mx.google.com with ESMTPSA id p5sm18536294qah.3.2014.10.15.09.00.53 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 09:00:54 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ralph Droms 
In-Reply-To: <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com>
Date: Wed, 15 Oct 2014 12:00:52 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <794E4A5D-24F6-42B7-B3A2-52D5D8861ADB@gmail.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com>
To: Ted Lemon 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/o5Zjsm38rP9g6nJk1aC0Z4KAo18
Cc: HOMENET Working Group , Philip Homburg , Gert Doering 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 16:00:58 -0000

Ted - you wrote something that surprised me (in line)...

On Oct 15, 2014, at 11:34 AM 10/15/14, Ted Lemon  =
wrote:

> On Oct 15, 2014, at 10:04 AM, Gert Doering  wrote:
>> I explained my reasoning.  Multiple times.  Here and on other lists.  =
Again
>> and again.
>=20
> When you repeat yourself again and again, people stop listening to =
you.   There was a consensus call done on this, and the architecture =
document contains the results of that consensus.   If you have some =
additional objection to raise, you should raise it, but I'm very sorry, =
you do have to show your work.   You can't just make assertions about =
what you think is true, and expect your opinion to count in the =
consensus call.   We don't vote in the IETF, so opinions just don't make =
sense in that context.
>=20
> In particular, you appear to be arguing as if ULAs and GUAs are =
treated identically by IPv6 stacks, but they are not.

Really?  In what way are they not treated identically by IPv6 stacks?

- Ralph

>    So while I agree that there is a real problem making this work for =
multi-homed homenets (a problem, by the way, which homenet has decided =
to try to solve), this is completely orthogonal to the question of =
whether we should use ULAs in the homenet.
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From nobody Wed Oct 15 09:27:53 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C0D1A892E for ; Wed, 15 Oct 2014 09:27:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.088
X-Spam-Level: *
X-Spam-Status: No, score=1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, PLING_QUERY=0.994, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPW3cMhyE8TG for ; Wed, 15 Oct 2014 09:27:50 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034151A047A for ; Wed, 15 Oct 2014 09:27:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 5C2E349; Wed, 15 Oct 2014 18:27:48 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1413390466; bh=Ft+hDlHpXFH7imqBgAN2f5YQjZjuweT6CQg5NUcllgI=; b=Y 0CHCoD8esaanYsmTZXmK01H5X/mEEbAxOC0rggTid99EVfpauEkkM7LwlpIca6L2 tKpNIFucMYj4d3yzKeKYaoZUKhDzOxZq+PCsxK00WzkyyYzKfZeCHDkak1OBE6Zz KTr+k60oO6m6Bhl2J53J+pXCSpCupHPRG47k3wS1u0=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dWrzNH44FIdZ; Wed, 15 Oct 2014 18:27:46 +0200 (CEST)
Received: from [IPv6:2a00:8640:1::a948:e9d0:959f:2316] (unknown [IPv6:2a00:8640:1:0:a948:e9d0:959f:2316]) by mail.sintact.nl (Postfix) with ESMTPSA id 592DF3A; Wed, 15 Oct 2014 18:27:46 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Sander Steffann 
In-Reply-To: <794E4A5D-24F6-42B7-B3A2-52D5D8861ADB@gmail.com>
Date: Wed, 15 Oct 2014 18:27:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <94B70B36-0257-4840-A60D-D7A7C55F7216@steffann.nl>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <794E4A5D-24F6-42B7-B3A2-52D5D8861ADB@gmail.com>
To: Ralph Droms 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/PIzVIWzJvsgzm6BPjs7fmGXqQ2c
Cc: HOMENET Working Group , Philip Homburg , Ted Lemon , =?utf-8?Q?Gert_D=C3=B6ring?= 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 16:27:51 -0000

Hi Ralph,

>> In particular, you appear to be arguing as if ULAs and GUAs are =
treated identically by IPv6 stacks, but they are not.
>=20
> Really?  In what way are they not treated identically by IPv6 stacks?

ULA space does have a separate entry in the policy table of RFC 6724 =
(https://tools.ietf.org/html/rfc6724#section-2.1)

Chees,
Sander


From nobody Wed Oct 15 09:28:08 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262CA1A8965 for ; Wed, 15 Oct 2014 09:28:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdO0x_AinNA1 for ; Wed, 15 Oct 2014 09:28:05 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 174ED1A047A for ; Wed, 15 Oct 2014 09:28:05 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id E39762381535; Wed, 15 Oct 2014 12:28:03 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <20141015154841.GY31092@Space.Net>
Date: Wed, 15 Oct 2014 11:28:01 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>
To: Gert Doering 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/I01mdo-6rmS0biB0RFKoYcn-228
Cc: HOMENET Working Group , Philip Homburg 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 16:28:07 -0000

On Oct 15, 2014, at 10:48 AM, Gert Doering  wrote:
> Could you remind me what your point was?

My point was that homenets should have ULAs, and should not use GUAs for =
local communication, because GUAs can be flash renumbered, and the use =
of them on the local wire has the potential to cause disruptions on the =
local wire that could be prevented by using ULAs.   And that there is no =
real downside to having ULAs on the local network.=


From nobody Wed Oct 15 09:35:23 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12CF1A8987 for ; Wed, 15 Oct 2014 09:35:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.282
X-Spam-Level: *
X-Spam-Status: No, score=1.282 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_ALL=0.8, PLING_QUERY=0.994, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4Bnfd5gpfdw for ; Wed, 15 Oct 2014 09:35:21 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250EB1A898D for ; Wed, 15 Oct 2014 09:35:21 -0700 (PDT)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id s9FGZKHb026531 for ; Wed, 15 Oct 2014 09:35:20 -0700
Message-ID: <543EA248.2080700@mtcc.com>
Date: Wed, 15 Oct 2014 09:35:20 -0700
From: Michael Thomas 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: homenet@ietf.org
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/SPdv_zoTK3fi0DhrAh81T2qQWEk
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 16:35:21 -0000

On 10/15/2014 09:28 AM, Ted Lemon wrote:
> On Oct 15, 2014, at 10:48 AM, Gert Doering  wrote:
>> Could you remind me what your point was?
> My point was that homenets should have ULAs, and should not use GUAs for local communication, because GUAs can be flash renumbered, and the use of them on the local wire has the potential to cause disruptions on the local wire that could be prevented by using ULAs.   And that there is no real downside to having ULAs on the local network.
>

What about when my device is wandering back and forth between my ap and 
my neighbor's?

Mike


From nobody Wed Oct 15 09:45:41 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31F31A8A95 for ; Wed, 15 Oct 2014 09:45:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.088
X-Spam-Level: *
X-Spam-Status: No, score=1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, PLING_QUERY=0.994, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eh_JzEXfwdSg for ; Wed, 15 Oct 2014 09:45:38 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFBBB1A8A79 for ; Wed, 15 Oct 2014 09:45:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id BDC8E4A; Wed, 15 Oct 2014 18:45:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1413391500; bh=kUwGxUUBiG5Kd7b+t/Ty2lWWWfvv+ZQMj9MicRIYQdI=; b=m 7O0s93mpWgG5gmyao/eQe2ydu61TSos2LK9e8U61CA9LQrVffm10C3HWWRPgYhet HhAAm4XGfhC0P8R2PJtmssjRVnfYfm+Wsqt+cV/VRp7CzF0PnfGlrvhROmoBCpB3 sVtfwh1jT/3ZC5KaQF0q6ga3bL8OHLM7zXwgAVckQ4=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jGSDU-yniU-N; Wed, 15 Oct 2014 18:45:00 +0200 (CEST)
Received: from [IPv6:2a00:8640:1::a948:e9d0:959f:2316] (unknown [IPv6:2a00:8640:1:0:a948:e9d0:959f:2316]) by mail.sintact.nl (Postfix) with ESMTPSA id E923749; Wed, 15 Oct 2014 18:44:59 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Sander Steffann 
In-Reply-To: 
Date: Wed, 15 Oct 2014 18:44:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net> 
To: Ted Lemon 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/SwukckLmLMPLWVb_IC6oWrnvoyQ
Cc: HOMENET Working Group , Philip Homburg , =?utf-8?Q?Gert_D=C3=B6ring?= 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 16:45:40 -0000

Hi Ted,

> My point was that homenets should have ULAs, and should not use GUAs =
for local communication, because GUAs can be flash renumbered, and the =
use of them on the local wire has the potential to cause disruptions on =
the local wire that could be prevented by using ULAs.   And that there =
is no real downside to having ULAs on the local network.

I am starting to agree.

I think we should see if we can come up with a good way to manage the =
ULAs when splitting/merging/etc networks though. If we can't find =
something good for that then the solution might be worse than the =
original problem.

Cheers,
Sander


From nobody Wed Oct 15 10:30:01 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716761AC3CE for ; Wed, 15 Oct 2014 10:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.984
X-Spam-Level: 
X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPpMItZMT_Xb for ; Wed, 15 Oct 2014 10:29:52 -0700 (PDT)
Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D01FA1AC3D2 for ; Wed, 15 Oct 2014 10:29:51 -0700 (PDT)
Received: by mail-vc0-f173.google.com with SMTP id ij19so1357982vcb.32 for ; Wed, 15 Oct 2014 10:29:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=wtUgDHzraGABpAz8hrJv05F0yfGda3xBJ8GYeOOXVbw=; b=RuF9trPhzmHvZtvVaZs/YR2nDN7t6jSvykaSDM7FdwDzZBtXuqatcJiRKeJDBRsJnJ O4Y+mNSO2yDUQ1bWt3VQm3B8hpn+/5c5lOWr6nvh4Tg4bnrHQbsL5twcI59izJVmdET7 bMc4+RxC8h202hROtfA/NdsjJuFAuVTGQFR0zpEb1dkvG5ITwTVShnHDfCShOlWnybTd GkL1V5FLNtisdS59RZWTMGh3rL4Gzj8CZut5S93baQI6wOcpbDkIpQoveOje/aNewhEd vpRkzRopkc5yrE0Ku4vMHmjxnldyoguKz1bwwKBV8yfQv+BF2tcU/lC+MLu3L9rCsExQ r74Q==
X-Gm-Message-State: ALoCoQmB5okzYovavc20BlQcy0nhhn7CPMMB+4tViNTbm5316lOvNNrcqN0d4wVDQeb3EBLMttyy
MIME-Version: 1.0
X-Received: by 10.221.31.136 with SMTP id sg8mr13803276vcb.20.1413394190425; Wed, 15 Oct 2014 10:29:50 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Wed, 15 Oct 2014 10:29:50 -0700 (PDT)
In-Reply-To: <828EDE1E-7697-44EF-AF8B-D6F945737073@steffann.nl>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>    <828EDE1E-7697-44EF-AF8B-D6F945737073@steffann.nl>
Date: Wed, 15 Oct 2014 10:29:50 -0700
Message-ID: 
From: James Woodyatt 
To: HOMENET Working Group 
Content-Type: multipart/alternative; boundary=001a11337b56a5f3dd0505797a5e
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/a6QRIurTdmNHetpiLtJ93jTomEk
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 17:29:54 -0000

--001a11337b56a5f3dd0505797a5e
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 15, 2014 at 4:14 AM, Sander Steffann  wrote:

> [I wrote:]

> Consider a hypothetical router that has the regular automatic default
> behavior of commissioning a new standalone network while discovering any
> existing networks that it already possesses the credentials to join. Now
> consider what happens when devices of this category are continually losing
> and regaining their connectivity with the rest of the wireless network in
> the home. Let's imagine this happens many times per hour. How many days
> does it take before all your constrained-resource hosts have no space left
> in their route tables for all the deprecated but still valid ULA prefixes?
>
> Does it have to be a *new* standalone network (ULA prefix)? The router
> could just generate a ULA prefix once and reuse it whenever it needs to,
> right? Generating a new prefix on every connect/disconnect would indeed
> cause a mess...
>

No, the router can't do that. Consider that ULA prefixes may be advertised
through tunnels to one or more exterior private routing domains that
communicate with multiple home networks simultaneously. Because the locally
generated ULA prefix is copied from the commissioning router to all the
other routers in the home network, a router must therefore generate a new
ULA prefix at every network commissioning to preserve the property that ULA
prefixes are statistically unlikely to collide. Otherwise, every time a
single device is used to commission a new network with the same ULA prefix,
that prefix will collide with existing previously commissioned networks at
the exterior domain gateway.


-- 
james woodyatt 
Nest Labs, Communications Engineering

--001a11337b56a5f3dd0505797a5e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On W=
ed, Oct 15, 2014 at 4:14 AM, Sander Steffann <sander@steffann.nl>=
 wrote:
[I wrote:]=C2=A0=


> Consider a hypothetical router that has the regular automatic default =
behavior of commissioning a new standalone network while discovering any ex=
isting networks that it already possesses the credentials to join. Now cons=
ider what happens when devices of this category are continually losing and =
regaining their connectivity with the rest of the wireless network in the h=
ome. Let's imagine this happens many times per hour. How many days does=
 it take before all your constrained-resource hosts have no space left in t=
heir route tables for all the deprecated but still valid ULA prefixes?



Does it have to be a *new* standalone network (ULA prefix)? The rout=
er could just generate a ULA prefix once and reuse it whenever it needs to,=
 right? Generating a new prefix on every connect/disconnect would indeed ca=
use a mess...=C2=A0

No, the router can't do that. Consider t=
hat ULA prefixes may be advertised through tunnels to one or more exterior =
private routing domains that communicate with multiple home networks simult=
aneously. Because the locally generated ULA prefix is copied from the commi=
ssioning router to all the other routers in the home network, a router must=
 therefore generate a new ULA prefix at every network commissioning to pres=
erve the property that ULA prefixes are statistically unlikely to collide. =
Otherwise, every time a single device is used to commission a new network w=
ith the same ULA prefix, that prefix will collide with existing previously =
commissioned networks at the exterior domain gateway.


-- 




--001a11337b56a5f3dd0505797a5e--


From nobody Wed Oct 15 10:50:50 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00A91AC422 for ; Wed, 15 Oct 2014 10:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIWk48m1BwH1 for ; Wed, 15 Oct 2014 10:50:46 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id BD09C1A1AB5 for ; Wed, 15 Oct 2014 10:50:46 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id D3F43238045C; Wed, 15 Oct 2014 13:50:45 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <543EA248.2080700@mtcc.com>
Date: Wed, 15 Oct 2014 12:50:43 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>
To: Michael Thomas 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Q4H0dFrVFEkMU3Wc_WM_G80ILig
Cc: homenet@ietf.org
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 17:50:48 -0000

On Oct 15, 2014, at 11:35 AM, Michael Thomas  wrote:
> What about when my device is wandering back and forth between my ap =
and my neighbor's?

I don't think that's a problem that we're scoped to solve, unless your =
and your neighbors' homenets are a single homenet, in which case life is =
good.


From nobody Wed Oct 15 11:34:43 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670851A8F49 for ; Wed, 15 Oct 2014 11:34:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.118
X-Spam-Level: 
X-Spam-Status: No, score=-0.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, PLING_QUERY=0.994, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9UgnQ2gQcJ6 for ; Wed, 15 Oct 2014 11:34:41 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56761A1AB2 for ; Wed, 15 Oct 2014 11:34:41 -0700 (PDT)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id s9FIYeDu008064 for ; Wed, 15 Oct 2014 11:34:41 -0700
Message-ID: <543EBE40.3030201@mtcc.com>
Date: Wed, 15 Oct 2014 11:34:40 -0700
From: Michael Thomas 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: homenet@ietf.org
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/1HF1krXTxb0Pn8xIfIPGpirYhTo
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 18:34:42 -0000

On 10/15/2014 10:50 AM, Ted Lemon wrote:
> On Oct 15, 2014, at 11:35 AM, Michael Thomas  wrote:
>> What about when my device is wandering back and forth between my ap and my neighbor's?
> I don't think that's a problem that we're scoped to solve, unless your and your neighbors' homenets are a single homenet, in which case life is good.
>
>

I'm just pushing back that ULA's aren't necessarily without problems. 
It's easy to see how they
can cause weird connectivity breaks across administrative domains. 
Though it's obviously not
just homenets, wandering back and forth between neighboring networks is 
probably more likely
with homenets, IMO.

Mike


From nobody Wed Oct 15 11:57:31 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C886B1A912B for ; Wed, 15 Oct 2014 11:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJtCPLjpbWgj for ; Wed, 15 Oct 2014 11:57:27 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id EE8CB1A9126 for ; Wed, 15 Oct 2014 11:57:23 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 65D722381535; Wed, 15 Oct 2014 14:57:23 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <543EBE40.3030201@mtcc.com>
Date: Wed, 15 Oct 2014 13:57:21 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>
To: Michael Thomas 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/8cffst_9JJVBt8m7IRDm_XxvwUM
Cc: homenet@ietf.org
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 18:57:28 -0000

On Oct 15, 2014, at 1:34 PM, Michael Thomas  wrote:
> I'm just pushing back that ULA's aren't necessarily without problems. =
It's easy to see how they
> can cause weird connectivity breaks across administrative domains. =
Though it's obviously not
> just homenets, wandering back and forth between neighboring networks =
is probably more likely
> with homenets, IMO.

Fair enough, but this is like answering a question about whether butter =
is good with bread by suggesting that people with Celiac's should avoid =
it.   True, but not germane to the discussion.   Ideally your device =
should not be hopping back and forth between networks.   If it does, =
there is no work for homenet to do to address the problems that arise.

There has been talk about working on some formal presentation layer that =
could be used to address these problems, but that is not something that =
Homenet is chartered to work on, nor is this really where the right =
people congregate.


From nobody Wed Oct 15 12:14:04 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AD81A9138 for ; Wed, 15 Oct 2014 12:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.006
X-Spam-Level: 
X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bS67g7AEZAKN for ; Wed, 15 Oct 2014 12:14:02 -0700 (PDT)
Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1A21A9137 for ; Wed, 15 Oct 2014 12:14:02 -0700 (PDT)
Received: by mail-pa0-f45.google.com with SMTP id rd3so1857125pab.18 for ; Wed, 15 Oct 2014 12:14:02 -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=ZhKb7ETq1aTm2e/NPW/cZxix/l4T4+QM6uAXdZN2oqQ=; b=IGOour8dZ9Rx+1w//hI2poE8bN8cQPNuPClD1+YyVqIiXpzzw2N763j2Zx/mueM3fn h/ml1J4uyTwU8qGFxA6X2N16Lc1nLOcT9muNv5ql5PK+kCa2hEXXQELZE0vaL9SqLSDK Le6pJvYCwp0LSZ/Rf4IwVfML28AVF3+M3pgskzdX9f1CzgeO+Y6daw3+7Adw3daObuaK APIZeFpa1rGU8CgcdTTQe+PewLJY9ztR6W82bnnuGro4/pDF97rkACCSo9j/XaT8p0LM 60G8Prl50HdM/+DLPFSFVaRmqI1aoWVsnqc9t4ZpwU3snZbzU3QKMs+64JIROC5mxjYv TVjQ==
X-Received: by 10.68.220.233 with SMTP id pz9mr14521928pbc.5.1413400442323; Wed, 15 Oct 2014 12:14:02 -0700 (PDT)
Received: from [172.17.1.55] (219-89-120-188.adsl.xtra.co.nz. [219.89.120.188]) by mx.google.com with ESMTPSA id dg5sm16576257pdb.54.2014.10.15.12.13.58 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 12:14:01 -0700 (PDT)
Message-ID: <543EC77B.9090605@gmail.com>
Date: Thu, 16 Oct 2014 08:14:03 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Mikael Abrahamsson 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com>  <48942796-C098-48B6-B894-544499EEB5F3@fugue.com>  <5E43B678-A2F9-4289-93E9-A6A98BEE82A1@iki.fi> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/t2H3ryb_3E5CDmpIbfwoyD-EjwU
Cc: HOMENET Working Group , Markus Stenberg 
Subject: [homenet] On renumbering [was: Let's make in-home ULA presence a MUST !?]
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 19:14:03 -0000

On 15/10/2014 22:48, Mikael Abrahamsson wrote:
> On Wed, 15 Oct 2014, Markus Stenberg wrote:
> 
>> Every time I hear about ISP-forced customer renumberings, the more I
>> start to think that 1+ ULA prefixes per home is a MUST, not a SHOULD.
> 
> For me this isn't just about ISP-forced customer renumberings, but to
> also handle power outages, equipment malfunction (so you lose your
> lease), equipment change, ISP change, and all other things that today
> will make you change the IPv4 address a few times a year or something.
> 
> I believe we should use SHIM6, MP-TCP, "mosh" and other similar
> techniques to make sure that we can move sessions around when doing
> renumbering.

Shim6 is unfortunately broken, until the day when all middleboxes
allow the extension headers to pass, which is far from true today.
MPTCP only works for TCP. Mosh aparently only works for SSH. Happy
eyeballs only works for browsers. This is far from a closed topic.

> IPv6 has the infrastructure on L3 to handle renumbering gracefully, 

That's unclear to me. Anyway, it might be worth reviewing the
gap analysis at http://tools.ietf.org/html/rfc7010
(which was mainly aimed at enterprises) to see how it looks
for homenets.

> now
> we just need L4 and applications to get with the program as well. I
> would really like to see us go in the way of IP addresses not being the
> single anchorpoint of all communication, we need to make sure that we
> have other mechanisms such as L4 protocols being "agile" when it comes
> to IP address change over time, and also having DNS or other mechanism
> being able to be updated with information over time to enable this
> mobility.

"Just"?? Anyway, see my rant in CCR:
http://www.sigcomm.org/sites/default/files/ccr/papers/2014/April/0000000-0000008.pdf

   Brian


From nobody Wed Oct 15 13:01:56 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F5B1A916B for ; Wed, 15 Oct 2014 13:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.118
X-Spam-Level: 
X-Spam-Status: No, score=-0.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, PLING_QUERY=0.994, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PibJrlyk3Tjm for ; Wed, 15 Oct 2014 13:01:53 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE521A6FCF for ; Wed, 15 Oct 2014 13:01:53 -0700 (PDT)
Received: from [10.1.10.18] (c-50-148-182-215.hsd1.ca.comcast.net [50.148.182.215]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id s9FK1n9L017089; Wed, 15 Oct 2014 13:01:50 -0700
Message-ID: <543ED2A7.3090409@mtcc.com>
Date: Wed, 15 Oct 2014 13:01:43 -0700
From: Michael Thomas 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ted Lemon 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/bllLG_rcc733Kq-AkzgO7s_I1H4
Cc: homenet@ietf.org
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 20:01:54 -0000

On 10/15/14, 11:57 AM, Ted Lemon wrote:
>
> Ideally your device should not be hopping back and forth between networks.   If it does, there is no work for homenet to do to address the problems that arise.
>

See, I don't find that ideal at all. If I'm swinging around on my 
backyard trapeze watching
the flying wallendas instructional video from my home jukebox, I really 
don't want to have
my network break connectivity because I happened to switch to my 
neighbor's wifi and I
was using a ULA when I could have kept connectivity with a GUA.

As far as homenet goes, i'd rather it not bake in any assumptions about 
ULA's beyond what
is already there.

Mike, ::splat::


From nobody Wed Oct 15 13:28:29 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A8C1A8935 for ; Wed, 15 Oct 2014 13:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.984
X-Spam-Level: 
X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvDm2HfAqIc4 for ; Wed, 15 Oct 2014 13:28:27 -0700 (PDT)
Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B001ACCE6 for ; Wed, 15 Oct 2014 13:28:27 -0700 (PDT)
Received: by mail-vc0-f170.google.com with SMTP id hy10so1647436vcb.1 for ; Wed, 15 Oct 2014 13:28:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=w/DJGBd5YtMyAEcKLAtHnT0tYL7itB0s0K3eM1PqVAQ=; b=TCtm/AcNLjkkYPyhkmNpXj0PDt33rxAc4RNALQTf8+TX0zNWFQ7GkNqp74477Ry0tQ V0daLiIcPub3GNGe8hF6Vd05hrfrm3PieFSIU0X9Vnkh74ZW274T2Fe4nYRtP5KV5iZg yl3syKPihbAQbyRXgCnOqClaHXTENgh0OmgYqJDMVX31MxW2NgdjhASGD/IZhAQVR2U0 864pFO/d/Zpw148B14beXosHDk2cJFEAnGPJyhQrq0NpLVDqLY0C+vZiqRbIVSi50dPe H4gmwoifmPKcmuTyqDoGmJWMwplLGuVeRNttcpJ6fvaestWgJF4AYzTj6Ewjw0PmSelX PFvA==
X-Gm-Message-State: ALoCoQmunckkiR2wfP1aG63aEYIZKjilHlj6ZOdAdG4x41GTnaCURh2JvBGhw5dLcpJk02Q5NmS5
MIME-Version: 1.0
X-Received: by 10.52.30.232 with SMTP id v8mr12576290vdh.24.1413404906553; Wed, 15 Oct 2014 13:28:26 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Wed, 15 Oct 2014 13:28:26 -0700 (PDT)
In-Reply-To: <543ED2A7.3090409@mtcc.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com>
Date: Wed, 15 Oct 2014 13:28:26 -0700
Message-ID: 
From: James Woodyatt 
To: HOMENET Working Group 
Content-Type: multipart/alternative; boundary=bcaec51d2d9661196c05057bf9e8
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/4I4PDZTFRiap-qmLjBw4o_f1DFc
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 20:28:29 -0000

--bcaec51d2d9661196c05057bf9e8
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 15, 2014 at 1:01 PM, Michael Thomas  wrote:

> [...] I really don't want to have my network break connectivity because I
> happened to switch to my neighbor's wifi and I was using a ULA when I could
> have kept connectivity with a GUA.
>

Except REC-49 in RFC 6092 does not recommend transparency as the default
operating mode of residential gateway firewalls. And very few in actual
deployments are transparent by default. So this can't be expected to work
even with GUA instead of ULA.

-- 
james woodyatt 
Nest Labs, Communications Engineering

--bcaec51d2d9661196c05057bf9e8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On W=
ed, Oct 15, 2014 at 1:01 PM, Michael Thomas <mike@mtcc.com> wr=
ote:
[...] I really don't want to have=C2=A0my netw=
ork break connectivity because I happened to switch to my neighbor's wi=
fi and I=C2=A0was using a ULA when I could have kept connectivity with a GU=
A.



Except REC-49 in RF=
C 6092 does not recommend transparency as the default operating mode of res=
idential gateway firewalls. And very few in actual deployments are transpar=
ent by default. So this can't be expected to work even with GUA instead=
 of ULA.


--bcaec51d2d9661196c05057bf9e8--


From nobody Wed Oct 15 14:15:34 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098A21ACD92 for ; Wed, 15 Oct 2014 14:15:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.117
X-Spam-Level: 
X-Spam-Status: No, score=-0.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, PLING_QUERY=0.994, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sssWx89l43Jd for ; Wed, 15 Oct 2014 14:15:29 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2B1C1ACD8B for ; Wed, 15 Oct 2014 14:15:29 -0700 (PDT)
Received: from [10.1.10.18] (c-50-148-182-215.hsd1.ca.comcast.net [50.148.182.215]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id s9FLFSSK024765 for ; Wed, 15 Oct 2014 14:15:28 -0700
Message-ID: <543EE3EA.2090902@mtcc.com>
Date: Wed, 15 Oct 2014 14:15:22 -0700
From: Michael Thomas 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: homenet@ietf.org
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080802070809080408030005"
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/j2d1rmU7sivv6w6MsMMTqSbTWh8
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 21:15:31 -0000

This is a multi-part message in MIME format.
--------------080802070809080408030005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


On 10/15/14, 1:28 PM, James Woodyatt wrote:
> On Wed, Oct 15, 2014 at 1:01 PM, Michael Thomas  > wrote:
>
>     [...] I really don't want to have my network break connectivity
>     because I happened to switch to my neighbor's wifi and I was using
>     a ULA when I could have kept connectivity with a GUA.
>
>
> Except REC-49 in RFC 6092 does not recommend transparency as the 
> default operating mode of residential gateway firewalls. And very few 
> in actual deployments are transparent by default. So this can't be 
> expected to work even with GUA instead of ULA.
>

If I want to have internet available servers/services available from my 
home network, that's
my business, not rfc 6092's. This is a feature, not a bug and frankly 
the horse has long departed
the barn with things like, oh say, wifi cams, security systems, and dare 
I say internet enabled
thermostats.

Mike

--------------080802070809080408030005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
On 10/15/14, 1:28 PM, James Woodyatt
      wrote:

    

    

      

        

          
On Wed, Oct 15, 2014 at 1:01 PM,
            Michael Thomas <mike@mtcc.com> wrote:

            
[...]
              I really don't want to have my network break connectivity
              because I happened to switch to my neighbor's wifi and
              I was using a ULA when I could have kept connectivity with
              a GUA.

            

          

          


          

          Except REC-49 in RFC 6092 does not recommend transparency as
          the default operating mode of residential gateway firewalls.
          And very few in actual deployments are transparent by default.
          So this can't be expected to work even with GUA instead of
          ULA.

        

      

    

    

    If I want to have internet available servers/services available from
    my home network, that's 

    my business, not rfc 6092's. This is a feature, not a bug and
    frankly the horse has long departed

    the barn with things like, oh say, wifi cams, security systems, and
    dare I say internet enabled

    thermostats.

    

    Mike

  


--------------080802070809080408030005--


From nobody Wed Oct 15 15:49:45 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5B41A87CE for ; Wed, 15 Oct 2014 15:49:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBsBT3TR9S0a for ; Wed, 15 Oct 2014 15:49:39 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2260F1A87D9 for ; Wed, 15 Oct 2014 15:49:39 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 866F42381535; Wed, 15 Oct 2014 18:49:38 -0400 (EDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <543ED2A7.3090409@mtcc.com>
Date: Wed, 15 Oct 2014 17:49:36 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com>
To: Michael Thomas 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/yp7SFzmt2Ivc05VPuqXFtqdZ7mc
Cc: homenet@ietf.org
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 22:49:41 -0000

On Oct 15, 2014, at 3:01 PM, Michael Thomas  wrote:
> See, I don't find that ideal at all. If I'm swinging around on my =
backyard trapeze watching
> the flying wallendas instructional video from my home jukebox, I =
really don't want to have
> my network break connectivity because I happened to switch to my =
neighbor's wifi and I
> was using a ULA when I could have kept connectivity with a GUA.

This is simply a non-sequitur.   It has nothing to do with homenet.   It =
has to do with how the stack works on your home, and what the =
propagation of radio waves looks like in your back yard.   The =
assumption that you will be able to access your jukebox over your =
neighbor's wifi contains packed in it so much new protocol work we could =
fork several working groups to handle it.

> As far as homenet goes, i'd rather it not bake in any assumptions =
about ULA's beyond what
> is already there.

I hear you.   But why should the working group care what you prefer?   I =
don't say that to be dismissive, but to encourage you to give a reason =
that isn't just an opinion.


From nobody Wed Oct 15 15:58:03 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D291ACDFC for ; Wed, 15 Oct 2014 15:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.781
X-Spam-Level: *
X-Spam-Status: No, score=1.781 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_ALL=0.8, PLING_QUERY=0.994, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6ua1sswE6tF for ; Wed, 15 Oct 2014 15:58:00 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE23E1A87CE for ; Wed, 15 Oct 2014 15:57:59 -0700 (PDT)
Received: from [10.1.10.18] (c-50-148-182-215.hsd1.ca.comcast.net [50.148.182.215]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id s9FMvwf4002973; Wed, 15 Oct 2014 15:57:58 -0700
Message-ID: <543EFBF1.6040101@mtcc.com>
Date: Wed, 15 Oct 2014 15:57:53 -0700
From: Michael Thomas 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ted Lemon 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com>
In-Reply-To: <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/kAQJu7kXeuNZ8If3RNcRvUTEUNY
Cc: homenet@ietf.org
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 22:58:01 -0000

On 10/15/14, 3:49 PM, Ted Lemon wrote:
> On Oct 15, 2014, at 3:01 PM, Michael Thomas  wrote:
>> See, I don't find that ideal at all. If I'm swinging around on my backyard trapeze watching
>> the flying wallendas instructional video from my home jukebox, I really don't want to have
>> my network break connectivity because I happened to switch to my neighbor's wifi and I
>> was using a ULA when I could have kept connectivity with a GUA.
> This is simply a non-sequitur.   It has nothing to do with homenet.   It has to do with how the stack works on your home, and what the propagation of radio waves looks like in your back yard.   The assumption that you will be able to access your jukebox over your neighbor's wifi contains packed in it so much new protocol work we could fork several working groups to handle it.
If I use a GUA to my jukebox, the routing will just work regardless of which
AP I'm currently connected to. With ULA's, not so much. That's hardly a 
non-sequitur.

ULA's with mobility are very problematic IMO. I'm a lot more likely to 
wander onto my
neighbor's home network than to suffer a flash renumbering from one of 
my providers.
Mobility considerations aren't a distant future, they're now.

Mike


From nobody Wed Oct 15 16:06:40 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3891ACE0F for ; Wed, 15 Oct 2014 16:06:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Q8isCssG5P8 for ; Wed, 15 Oct 2014 16:06:32 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id AC3AD1ACE11 for ; Wed, 15 Oct 2014 16:06:30 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 820862381535; Wed, 15 Oct 2014 19:06:29 -0400 (EDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <543EFBF1.6040101@mtcc.com>
Date: Wed, 15 Oct 2014 18:06:27 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <457D177C-232E-4590-A9ED-80048140157F@fugue.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com>
To: Michael Thomas 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/d1jYyF4DTB-boqP8df3rzF_GYzk
Cc: homenet@ietf.org
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 23:06:34 -0000

On Oct 15, 2014, at 5:57 PM, Michael Thomas  wrote:
> If I use a GUA to my jukebox, the routing will just work regardless of =
which
> AP I'm currently connected to. With ULA's, not so much. That's hardly =
a non-sequitur.

You appear to have some misconceptions both about how IP routing works =
and how streaming works.

Suppose you are connected to your homenet.   You are streaming video =
from your jukebox using your ULA.   Now your device switches to your =
neighbor's Wifi, which is advertising a different GUA and a different =
ULA.   At this point your device does a flash renumber because it =
realizes it's no longer on the same network, and that the prefixes it =
had are no longer valid.

At this point, your application should get a notification from the stack =
that the connection has broken, at which point it should reconnect to =
your jukebox.  Supposing that your jukebox is reachable from the =
outside, the ULA that your neighbor's WiFi is advertising won't match =
the ULA your jukebox is advertising, so your device will attempt to =
reconnect using a GUA, not a ULA.

So whether you have a ULA on your homenet or not, two things will be =
true.  First, if your app isn't smart enough to re-connect, your stream =
will die.   Second, if it is smart enough, then it will succeed in =
reconnecting, whether you have a ULA configured on your homenet or not.

This is why I say that the concern you have raised is a non-sequitur.


From nobody Wed Oct 15 16:15:40 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4961F1ACDA2 for ; Wed, 15 Oct 2014 16:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.118
X-Spam-Level: 
X-Spam-Status: No, score=-0.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, PLING_QUERY=0.994, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKqyRXFv-5cJ for ; Wed, 15 Oct 2014 16:15:37 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CC9F1ACDFA for ; Wed, 15 Oct 2014 16:15:37 -0700 (PDT)
Received: from [10.1.10.18] (c-50-148-182-215.hsd1.ca.comcast.net [50.148.182.215]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id s9FNFauc005025 for ; Wed, 15 Oct 2014 16:15:36 -0700
Message-ID: <543F0013.8000400@mtcc.com>
Date: Wed, 15 Oct 2014 16:15:31 -0700
From: Michael Thomas 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: homenet@ietf.org
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>
In-Reply-To: <457D177C-232E-4590-A9ED-80048140157F@fugue.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/w7Vvxpq89PumLx6Jfq9ma6g5y4k
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 23:15:38 -0000

On 10/15/14, 4:06 PM, Ted Lemon wrote:
> On Oct 15, 2014, at 5:57 PM, Michael Thomas  wrote:
>> If I use a GUA to my jukebox, the routing will just work regardless of which
>> AP I'm currently connected to. With ULA's, not so much. That's hardly a non-sequitur.
> You appear to have some misconceptions both about how IP routing works and how streaming works.
>
> Suppose you are connected to your homenet.   You are streaming video from your jukebox using your ULA.   Now your device switches to your neighbor's Wifi, which is advertising a different GUA and a different ULA.   At this point your device does a flash renumber because it realizes it's no longer on the same network, and that the prefixes it had are no longer valid.

I'm talking about the server, not the client. ULA == unreachable on my 
neighbor's wifi.
Don't want assumptions that servers on my home network will only be 
reachable by ULA's.

Mike


From nobody Wed Oct 15 16:21:26 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28671ACE03 for ; Wed, 15 Oct 2014 16:21:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ni3MyZC3uogt for ; Wed, 15 Oct 2014 16:21:22 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 01B151ACE06 for ; Wed, 15 Oct 2014 16:21:20 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 643AB2381535; Wed, 15 Oct 2014 19:21:19 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <543F0013.8000400@mtcc.com>
Date: Wed, 15 Oct 2014 18:21:17 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com> <543F0013.8000400@mtcc.com>
To: Michael Thomas 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/RdeQ8sv1Lg-afbxW_ikBJF-o3eg
Cc: homenet@ietf.org
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 23:21:24 -0000

On Oct 15, 2014, at 6:15 PM, Michael Thomas  wrote:
> I'm talking about the server, not the client. ULA =3D=3D unreachable =
on my neighbor's wifi.
> Don't want assumptions that servers on my home network will only be =
reachable by ULA's.

If a GUA is being advertised on your homenet, presumably your server =
will have both a GUA and a ULA.


From nobody Wed Oct 15 16:26:31 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D301ACE2F for ; Wed, 15 Oct 2014 16:26:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.917
X-Spam-Level: 
X-Spam-Status: No, score=-5.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EM0CWKQXSIG9 for ; Wed, 15 Oct 2014 16:26:27 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56AFB1ACDFA for ; Wed, 15 Oct 2014 16:26:27 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 32AD01FCAB3; Wed, 15 Oct 2014 23:26:23 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0A8E4160058; Wed, 15 Oct 2014 23:29:27 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 9F6E4160056; Wed, 15 Oct 2014 23:29:26 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id D687121808CE; Thu, 16 Oct 2014 10:26:19 +1100 (EST)
To: Michael Thomas 
From: Mark Andrews 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com>
In-reply-to: Your message of "Wed, 15 Oct 2014 15:57:53 -0700." <543EFBF1.6040101@mtcc.com>
Date: Thu, 16 Oct 2014 10:26:19 +1100
Message-Id: <20141015232619.D687121808CE@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Z9LlIg3YPFm7uYSX1YnrVbrWMho
Cc: homenet@ietf.org, Ted Lemon 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 23:26:30 -0000

In message <543EFBF1.6040101@mtcc.com>, Michael Thomas writes:
> 
> On 10/15/14, 3:49 PM, Ted Lemon wrote:
> > On Oct 15, 2014, at 3:01 PM, Michael Thomas  wrote:
> >> See, I don't find that ideal at all. If I'm swinging around on my backyard
>  trapeze watching
> >> the flying wallendas instructional video from my home jukebox, I really do
> n't want to have
> >> my network break connectivity because I happened to switch to my neighbor'
> s wifi and I
> >> was using a ULA when I could have kept connectivity with a GUA.
> > This is simply a non-sequitur.   It has nothing to do with homenet.   It ha
> s to do with how the stack works on your home, and what the propagation of ra
> dio waves looks like in your back yard.   The assumption that you will be abl
> e to access your jukebox over your neighbor's wifi contains packed in it so m
> uch new protocol work we could fork several working groups to handle it.
> If I use a GUA to my jukebox, the routing will just work regardless of which
> AP I'm currently connected to. With ULA's, not so much. That's hardly a 
> non-sequitur.
> 
> ULA's with mobility are very problematic IMO. I'm a lot more likely to 
> wander onto my
> neighbor's home network than to suffer a flash renumbering from one of 
> my providers.
> Mobility considerations aren't a distant future, they're now.
> 
> Mike

And when you move onto your neighbour's net you will be switching
ssid's and even if you open up your router to allow the traffic in
the BCP 38 filtering should be blocking your packets leaving your
neighbors router.

Now if you want to set up a tunnel between you and your neighbour
to make this work that's fine.  If you don't you will have a different
set of addresses on either network including ULA addresses.  Unless
you have really old stacks your device will pick the new GUA first
to talk to your jukebox when you are on your neighbor's network and
the ULA to talk to it when you are on your own.

Even if you have a old stack, if the application has taken the
lessons from Happy Eyeballs and made it more generic by decreasing
the time before starting the next connection attempt to 100's if
milliseconds when you have multiple server addresses, the resulting
HE algorithms would have fixed the issue for you when it fast failed
to the GUA of the jukebox after changing ssids.  Longest match would
result in the new GUA being used rather than the new ULA.

I tried hard to get the IETF to listen to this for HE.

Mark

> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


From nobody Wed Oct 15 18:39:52 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8EA1ACE96 for ; Wed, 15 Oct 2014 18:39:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.006
X-Spam-Level: 
X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvBnW8e2CVp0 for ; Wed, 15 Oct 2014 18:39:50 -0700 (PDT)
Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1DB1A1ADF for ; Wed, 15 Oct 2014 18:39:50 -0700 (PDT)
Received: by mail-pd0-f180.google.com with SMTP id fp1so2266492pdb.39 for ; Wed, 15 Oct 2014 18:39:50 -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=uedTA3F4Oh36BxmAKXmzFd9LhBb4vy14oyHuc5LMZjk=; b=o96KtRPlcSh97QDxNQQdzvg6XL0TK1vBMKBOzQObJc9zCljb7HRH0/du+pZcVi+XiT UCGwyD/VISMriavg/jIK18hPY4T+6ZBYQIEIpaXrWfm6368JNpmJAWY+Ud+K1UsuPCIW Wh0Kels2L6TAZmqk5bskc4yETLHkKeUGfj/EyEMkC98AUIuIzE3ySjIrWttfxcFhnuMb yKlXOIyDnJ0840XtbW0aribLAV8wU2/Z45OfyLuUwBm+Ves1OW6mIQpzr53SyHrYsfG5 tu5peVkdITVkmL4Hv24sLQtRXedKLq2PlnBsmzdah7lppQQL6qhdj20+mgQjNSGgFzdS nY8g==
X-Received: by 10.66.251.194 with SMTP id zm2mr16616096pac.33.1413423590293; Wed, 15 Oct 2014 18:39:50 -0700 (PDT)
Received: from [172.17.1.55] (219-89-120-188.adsl.xtra.co.nz. [219.89.120.188]) by mx.google.com with ESMTPSA id qx4sm18231583pbc.14.2014.10.15.18.39.46 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 18:39:49 -0700 (PDT)
Message-ID: <543F21E7.5050005@gmail.com>
Date: Thu, 16 Oct 2014 14:39:51 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Michael Thomas 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com>
In-Reply-To: <543EFBF1.6040101@mtcc.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/3ec8nxFTOd-UexspPzRHudMPOQc
Cc: homenet@ietf.org, Ted Lemon 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 01:39:51 -0000

On 16/10/2014 11:57, Michael Thomas wrote:
> 
> On 10/15/14, 3:49 PM, Ted Lemon wrote:
>> On Oct 15, 2014, at 3:01 PM, Michael Thomas  wrote:
>>> See, I don't find that ideal at all. If I'm swinging around on my
>>> backyard trapeze watching
>>> the flying wallendas instructional video from my home jukebox, I
>>> really don't want to have
>>> my network break connectivity because I happened to switch to my
>>> neighbor's wifi and I
>>> was using a ULA when I could have kept connectivity with a GUA.
>> This is simply a non-sequitur.   It has nothing to do with homenet.  
>> It has to do with how the stack works on your home, and what the
>> propagation of radio waves looks like in your back yard.   The
>> assumption that you will be able to access your jukebox over your
>> neighbor's wifi contains packed in it so much new protocol work we
>> could fork several working groups to handle it.
> If I use a GUA to my jukebox, the routing will just work regardless of
> which
> AP I'm currently connected to. With ULA's, not so much. That's hardly a
> non-sequitur.
> 
> ULA's with mobility are very problematic IMO. I'm a lot more likely to
> wander onto my
> neighbor's home network than to suffer a flash renumbering from one of
> my providers.
> Mobility considerations aren't a distant future, they're now.

Sure, but that is *exactly* why you might want your personal
printer or your personal porn server or whatever to have an
address that can never be accessible from your neighbour's
yard. (Yes, I know that isn't "Security" with a big S but actually
it's part of a secure environment.)

    Brian


From nobody Thu Oct 16 00:14:49 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5011A037A for ; Thu, 16 Oct 2014 00:14:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.967
X-Spam-Level: 
X-Spam-Status: No, score=-2.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, PLING_QUERY=0.994, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flGuIT0Hd_cK for ; Thu, 16 Oct 2014 00:14:43 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31FB11A0381 for ; Thu, 16 Oct 2014 00:14:43 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0074CA1; Thu, 16 Oct 2014 09:14:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1413443681; bh=su/lYHjI1bc1Vx8rOdF1DsWaqiKLAU2gEck6uLzyWYg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WK80YcbSoQQ4/iVxt1VBpZj36gTEqwsqLkzdL01qQlJftBgZK44h22hRhay1Z8aL3 sUCHBR3KZSDIcKz9oc/aZF1n4zlWcztl6/5nQYZQvuvvR6U7RX207sytGYTDewnKMM g/G4l345FTJOU2mX8G8bBOBNm/yb8gJJizUhjNpA=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id ECCD09F; Thu, 16 Oct 2014 09:14:40 +0200 (CEST)
Date: Thu, 16 Oct 2014 09:14:40 +0200 (CEST)
From: Mikael Abrahamsson 
To: Ted Lemon 
In-Reply-To: <3D9F27DB-C521-4D14-9FF6-CDE0F6B65C44@fugue.com>
Message-ID: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com>  <48942796-C098-48B6-B894-544499EEB5F3@fugue.com>  <5E43B678-A2F9-4289-93E9-A6A98BEE82A1@iki.fi> <3D9F27DB-C521-4D14-9FF6-CDE0F6B65C44@fugue.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Anfq2WrJ0y5BSRapiIrNlUwo-UI
Cc: Erik Kline , HOMENET Working Group , Markus Stenberg , Pierre Pfister , Gert Doering 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 07:14:45 -0000

On Wed, 15 Oct 2014, Ted Lemon wrote:

> minutes is too short, because that will break for example a movie 
> stream.  But a 30-60 minute overlap will work fine for web browsing and 
> nearly all applications a typical end-user uses other than long movies.

I'd say a lot of the "movie" applications will work fine as well because 
a lot of them isn't a single TCP session over long time anyway, but that's 
another story.

What I most worry about is for instance SSH. However, I would like all 
applications to behave like "mosh" does (from a user point of view, not 
necessarily from a protocol point of view), in that an existing session 
can be moved between IPs, regardless if the change is gracefully handed 
over, or "hard" handed over (as in IP goes away, you get different 
connectivity with different IP 2 minutes later, and you can continue). We 
need this for video conferencing, VoIP calls, terminal sessions, basically 
*everything* that lasts more than 10-20 seconds on average.

This is of course not something the average application developer should 
need to handle, they should only need to use an API that says "please keep 
me connected to this DNS name" and then everything should be handled for 
them.

> There are applications that will fail because they bind to an address 
> and have no error recovery mechanism for when the address goes away, but 
> AFAIK these are quite uncommon.  So really you are proposing a very 
> expensive cure for an insignificant problem.

I don't consider the problem insignificant.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Thu Oct 16 00:18:59 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549791A037A for ; Thu, 16 Oct 2014 00:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.667
X-Spam-Level: 
X-Spam-Status: No, score=-0.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UipvO4DKUEsK for ; Thu, 16 Oct 2014 00:18:57 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C311A036C for ; Thu, 16 Oct 2014 00:18:57 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id CB125A1; Thu, 16 Oct 2014 09:18:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1413443935; bh=bniauQrDbtpjawORuAhGBABiGqVy9v/sDHbVdoB0CPA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=q8zIjzhdbbBnGdOacAqL8Ua72+AjXTLjh2U6v/gyfzy05lBbJTaZzXlXQEHtg2MNS Lb4/itlgz3yBXDuSoM/i7SUeEblU4KStDmA3TebsceApCMG2fSnqfmA5xq2tJeZoX/ cGcDZvi2TE8Pkx5N/k95+899CVR+5JSlRf/AUGXk=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C26DA9F; Thu, 16 Oct 2014 09:18:55 +0200 (CEST)
Date: Thu, 16 Oct 2014 09:18:55 +0200 (CEST)
From: Mikael Abrahamsson 
To: Tero Kivinen 
In-Reply-To: <21566.37095.559360.571810@fireball.kivinen.iki.fi>
Message-ID: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com>  <48942796-C098-48B6-B894-544499EEB5F3@fugue.com>  <5E43B678-A2F9-4289-93E9-A6A98BEE82A1@iki.fi> <21566.37095.559360.571810@fireball.kivinen.iki.fi>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/AeCTKIxCOokYm-RezML9IxXE57M
Cc: Markus Stenberg , Ted Lemon , Pierre Pfister , Erik Kline , HOMENET Working Group , Gert Doering 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 07:18:58 -0000

On Wed, 15 Oct 2014, Tero Kivinen wrote:

> My ssh connections are usually up and running for ever. They only go 
> down when I update my firewall, there is network problems, or our 
> company firewall is reset for some reason. Usually that means the ssh 
> connection is up for few months... I would be very unhappy I would need 
> to restart my TCP connections every month, so any ISP giving me such 
> notwork, would not be consider as proper ISP, and I would immediately 
> switch to another ISP if my ISP starts doing things that break my 
> connections.

I use MOSH. I never really notice when I change IPs because I move from 
wifi to wired to mobile and to a different wifi, it just seamlessly 
connects, usually before I am even able to type my password on my 
computer. I want all applications to behave like this.

Quasi stable addressing makes application developers take the "stable" 
part for granted. Networks go down and come back up again, TCP sessions 
hang due to stateful things in the network losing state etc. This is 
something an application developer needs to handle. If it only happens 2-4 
times per year, they'll blame the network and not their application.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Thu Oct 16 00:29:58 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075381A037A for ; Thu, 16 Oct 2014 00:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.967
X-Spam-Level: 
X-Spam-Status: No, score=-2.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, PLING_QUERY=0.994, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjW-fyWFXkye for ; Thu, 16 Oct 2014 00:29:56 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB411A0369 for ; Thu, 16 Oct 2014 00:29:54 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 33149A1; Thu, 16 Oct 2014 09:29:53 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1413444593; bh=kiLP7cG6BjuqsSUv1Xi9Nw9nfC4CyoxBek8x9UHBTjE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=oE1LlT+3NC1MHoqr9Ay3aZSxS/IxqIIoERaEiibW+7gblym9jSu5lgjEoPGbri5ZN 04d45Ntmu3vEAY1kQN2hzUIw4TRTuaKiYx3G5HY8e9LP5O/xindL/dQKDmx/fKnxhj NCKc9Ho9yIOM8J9w7PZQQ2TWWfi8aXiCWddAlRFQ=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 270C59F; Thu, 16 Oct 2014 09:29:53 +0200 (CEST)
Date: Thu, 16 Oct 2014 09:29:53 +0200 (CEST)
From: Mikael Abrahamsson 
To: Brian E Carpenter 
In-Reply-To: <543EC77B.9090605@gmail.com>
Message-ID: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com>  <48942796-C098-48B6-B894-544499EEB5F3@fugue.com>  <5E43B678-A2F9-4289-93E9-A6A98BEE82A1@iki.fi>  <543EC77B.9090605@gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/svIHUlTP3gX788AkNg33Z_FFVBw
Cc: HOMENET Working Group , Markus Stenberg 
Subject: Re: [homenet] On renumbering [was: Let's make in-home ULA presence a MUST !?]
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 07:29:58 -0000

On Thu, 16 Oct 2014, Brian E Carpenter wrote:

> Shim6 is unfortunately broken, until the day when all middleboxes allow 
> the extension headers to pass, which is far from true today. MPTCP only 
> works for TCP. Mosh aparently only works for SSH. Happy eyeballs only 
> works for browsers. This is far from a closed topic.

Absolutely, there is a huge amount of work needed in this area. That's why 
I wrote "similar techniques".

> "Just"?? Anyway, see my rant in CCR:
> http://www.sigcomm.org/sites/default/files/ccr/papers/2014/April/0000000-0000008.pdf

Yes, I have read it and it's an excellent document I think is very 
valuable.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Thu Oct 16 01:51:34 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3ACA1A1AB6 for ; Thu, 16 Oct 2014 01:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.989
X-Spam-Level: 
X-Spam-Status: No, score=-3.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, PLING_QUERY=0.994, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnS3XWBaGz8k for ; Thu, 16 Oct 2014 01:51:29 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92CAB1A038F for ; Thu, 16 Oct 2014 01:51:29 -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 s9G8pR5u005578 for ; Thu, 16 Oct 2014 10:51:27 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 26EA6205D65 for ; Thu, 16 Oct 2014 10:52:44 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1F83C20584E for ; Thu, 16 Oct 2014 10:52:44 +0200 (CEST)
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 s9G8oSZd005201 for ; Thu, 16 Oct 2014 10:51:27 +0200
Message-ID: <543F86D2.4020802@gmail.com>
Date: Thu, 16 Oct 2014 10:50:26 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: homenet@ietf.org
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com>
In-Reply-To: <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/KIh3ICQJho067MA1OIuoEXWssBs
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 08:51:32 -0000

Le 16/10/2014 00:49, Ted Lemon a écrit :
> On Oct 15, 2014, at 3:01 PM, Michael Thomas  wrote:
>> See, I don't find that ideal at all. If I'm swinging around on my
>> backyard trapeze watching the flying wallendas instructional video
>> from my home jukebox, I really don't want to have my network break
>> connectivity because I happened to switch to my neighbor's wifi and
>> I was using a ULA when I could have kept connectivity with a GUA.
>
> This is simply a non-sequitur.   It has nothing to do with homenet.

I agree it has nothing to do with homenet.

It is a problem at work, at airport, in public garden, in the street, at 
the restaurant - in general in every place where WiFi arrived.

It is an entirely WiFi connection management problem.  In Windows it can 
be avoided by unchecking the "Automatically Connect To" attached to that 
WiFi ESSID, or more brutally by removing that undesired profile completely.

Alex

> It has to do with how the stack works on your home, and what the
> propagation of radio waves looks like in your back yard.   The
> assumption that you will be able to access your jukebox over your
> neighbor's wifi contains packed in it so much new protocol work we
> could fork several working groups to handle it.
>
>> As far as homenet goes, i'd rather it not bake in any assumptions
>> about ULA's beyond what is already there.
>
> I hear you.   But why should the working group care what you prefer?
> I don't say that to be dismissive, but to encourage you to give a
> reason that isn't just an opinion.
>
> _______________________________________________ homenet mailing list
> homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
>



From nobody Thu Oct 16 01:55:38 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F4A1A1F73 for ; Thu, 16 Oct 2014 01:55:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.989
X-Spam-Level: 
X-Spam-Status: No, score=-3.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, PLING_QUERY=0.994, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHw2oNQmwOWu for ; Thu, 16 Oct 2014 01:55:32 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DED2E1A1AE0 for ; Thu, 16 Oct 2014 01:55:31 -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 s9G8tUkt017415 for ; Thu, 16 Oct 2014 10:55:30 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9BF96205EB3 for ; Thu, 16 Oct 2014 10:56:46 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 949A9205D65 for ; Thu, 16 Oct 2014 10:56:46 +0200 (CEST)
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 s9G8tSO1010197 for ; Thu, 16 Oct 2014 10:55:29 +0200
Message-ID: <543F8800.1060507@gmail.com>
Date: Thu, 16 Oct 2014 10:55:28 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: homenet@ietf.org
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com>
In-Reply-To: <543EFBF1.6040101@mtcc.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/np20rC9klP4vAOJajdlUEGgTX8E
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 08:55:36 -0000

Le 16/10/2014 00:57, Michael Thomas a écrit :
>
> On 10/15/14, 3:49 PM, Ted Lemon wrote:
>> On Oct 15, 2014, at 3:01 PM, Michael Thomas  wrote:
>>> See, I don't find that ideal at all. If I'm swinging around on my
>>> backyard trapeze watching the flying wallendas instructional
>>> video from my home jukebox, I really don't want to have my
>>> network break connectivity because I happened to switch to my
>>> neighbor's wifi and I was using a ULA when I could have kept
>>> connectivity with a GUA.
>> This is simply a non-sequitur.   It has nothing to do with homenet.
>> It has to do with how the stack works on your home, and what the
>> propagation of radio waves looks like in your back yard. The
>> assumption that you will be able to access your jukebox over your
>> neighbor's wifi contains packed in it so much new protocol work we
>> could fork several working groups to handle it.
>
> If I use a GUA to my jukebox, the routing will just work regardless
> of which AP I'm currently connected to. With ULA's, not so much.
> That's hardly a non-sequitur.
>
> ULA's with mobility are very problematic IMO.

I think this is right, mobility and ULAs may have some issues.

If by mobility we understand Mobile IP then assigning a GUA to HA (or
some form of protocol forwarding from the Box to the HA) only may allow
to then use ULAs for the mobile devices.  The implications of NATv6 may
vary.

> I'm a lot more likely to wander onto my neighbor's home network than
> to suffer a flash renumbering from one of my providers.

Yes and no.  WiFi wandering is completely under the enduser's control.

> Mobility considerations aren't a distant future, they're now.

I agree.

Alex

>
> Mike
>
> _______________________________________________ homenet mailing list
> homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
>



From nobody Thu Oct 16 05:25:03 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BC91A1AED for ; Thu, 16 Oct 2014 05:25:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9xAcpl5-Dsz for ; Thu, 16 Oct 2014 05:25:00 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id F0EA31A1AE1 for ; Thu, 16 Oct 2014 05:24:59 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 14AAA238050E; Thu, 16 Oct 2014 08:24:56 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Thu, 16 Oct 2014 07:24:55 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B2BBF22-D11B-4972-B380-EB37E8D606EF@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com>  <48942796-C098-48B6-B894-544499EEB5F3@fugue.com>  <5E43B678-A2F9-4289-93E9-A6A98BEE82A1@iki.fi> <3D9F27DB-C521-4D14-9FF6-CDE0F6B65C44@fugue.com> 
To: Mikael Abrahamsson 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/61jW31AveuVGlbG-jxpc9Qhsl_k
Cc: Erik Kline , HOMENET Working Group , Markus Stenberg , Pierre Pfister , Gert Doering 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 12:25:01 -0000

On Oct 16, 2014, at 2:14 AM, Mikael Abrahamsson  =
wrote:
> What I most worry about is for instance SSH.

Mikael, I think we have strayed sufficiently far off the topic that it =
is harmful for us to continue discussing it on the homenet mailing list. =
  I agree with you that better presentation layer support would be a =
good thing, but it is a thing that is not in homenet's charter.


From nobody Thu Oct 16 05:58:34 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4591A1B30 for ; Thu, 16 Oct 2014 05:58:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.394
X-Spam-Level: 
X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTNtquyhVYRQ for ; Thu, 16 Oct 2014 05:58:25 -0700 (PDT)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF781A1B0C for ; Thu, 16 Oct 2014 05:58:21 -0700 (PDT)
Received: by mail-ig0-f178.google.com with SMTP id h3so3338390igd.11 for ; Thu, 16 Oct 2014 05:58:20 -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; bh=FbDigoFBsUjtTid341R/5/IL7956MLdWgz5EEcd0RLM=; b=FoaMeO1smUFfcas3HL0P6XLnwSbIZxkyWI80bbudz3YhsiZ1t5HW/HrxFQqO2EVZNz pXizYV2wOmGRaRKJSHm5JYCHP4Kbz9WsQ+yJx/CH5KSGB9Deu2eownijrTe82gkHYD7D UHOzNUGAy8O97b3axCdraMdeusT+39F+ax6gdl0LoaXc9dqmvMplX9dmo+jsWPL3hWA5 XJ/q3otrmIc5YeFspz5TQm9SAIEHba40ySP0ymLKRvseFj6Jtitzk+vqpX5VBklJb1Lv I5FS++hN6y1ASeAKwxgxMkfb7WOupexQKDVHlOcZFFk75RNqhU7GwQVJagCOBgF3/bKH 6cOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FbDigoFBsUjtTid341R/5/IL7956MLdWgz5EEcd0RLM=; b=UcX/eX8wzp68l9Atu8FDta10houb4OYeJNuSV/EkmJEBijWFYymUAAx8D1hpNAZLrG /aiPLmh6R3FWHqh2pUqv0RFGP8jz0uCQaNcxD+p1HlJsAMMftkStzWW1BtqnWMX5nrrN iSgSSvAioF7kwRtESCGBe0HaGKiSLRAZ+4amtP/4bvqDbYxqf5fgXJuzxhk0xoiUvieo hWOPz/mtiwi16DoOg5BkpRjxHGrFeccl3baFvaKIoOeM3TtFnZ9xJnOU4jZRnoFHISMf hIsfhbCNQtyo9VWJb+jHYoLyySsTA/20LLaMTq57Otfqs+LU4H29uPPO3U9EGxeMqfsh 62Xg==
X-Gm-Message-State: ALoCoQm99tZpk8Zx0XrhuLWHiJqkv8iywZE8ITplUYxaJNGwMsRljiovJihM156sB7V4o22osQkg
X-Received: by 10.107.162.16 with SMTP id l16mr1422375ioe.54.1413464300588; Thu, 16 Oct 2014 05:58:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.8.242 with HTTP; Thu, 16 Oct 2014 05:58:00 -0700 (PDT)
In-Reply-To: <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net> <7D59D80C-2BF0-428B-A872-B2922B2D0F98@fugue.com>
From: Lorenzo Colitti 
Date: Thu, 16 Oct 2014 21:58:00 +0900
Message-ID: 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=001a1140a1b48a3b1c050589cd68
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/PtctEacHpZka9ezABs8_o-krb2c
Cc: Erik Kline , HOMENET Working Group , Pierre Pfister , Gert Doering 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 12:58:26 -0000

--001a1140a1b48a3b1c050589cd68
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 15, 2014 at 12:13 AM, Ted Lemon  wrote:

> There's no reason to do flash renumbering.


I think you'll find that the reason is that [ hardware manufacturers
support | operators are willing to spend router resources for ] only one
forwarding entry per customer at a time.

--001a1140a1b48a3b1c050589cd68
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On W=
ed, Oct 15, 2014 at 12:13 AM, Ted Lemon <mellon@fugue.com> wr=
ote:
There's no reason to do flash re=
numbering.

I think you'll find that the=
 reason is that [ hardware manufacturers support | operators are willing to=
 spend router resources for ] only one forwarding entry per customer at a t=
ime.


--001a1140a1b48a3b1c050589cd68--


From nobody Thu Oct 16 06:11:20 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17291A1B7A for ; Thu, 16 Oct 2014 06:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.394
X-Spam-Level: 
X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r75RAl5qmi-z for ; Thu, 16 Oct 2014 06:11:17 -0700 (PDT)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FAE31A003A for ; Thu, 16 Oct 2014 06:11:17 -0700 (PDT)
Received: by mail-ig0-f172.google.com with SMTP id r2so19278836igi.11 for ; Thu, 16 Oct 2014 06:11:17 -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; bh=DQu/tH/HJb+AD44oGVyhVJHjzhd/mYcDgzEtdqKNfGY=; b=m5ZXW2XiJsFNPTDBUekP8OIaWfjWdXx2H862L16U10LoF6oVjF3Xs6XHE277mCRdcF snFOcapsYkRnsrr1qz8mZ5lNuEaE7Csj+58zI8S0TSe6slbrpEhoMg/fb+Tp6GzhbLwO JILqVCS7zJXmdA1+VOSAq7ilEM2MaRHgc3BCxUc0EdbtkSSghHApeSZAg4MnaO6GRtSO zoXq7Ju75ARFJLmFRhIF5wT5L8XrRq9DW3jrnBOQ9teu5XJaH0ci+9IBhhiFtnBJGH/C Q+n4xHAzHHbRsAKIKfoEvdYyGfAN1XBj6mglUCWIgaYahj5iGPwEF26liZl/D7gQege5 SSvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DQu/tH/HJb+AD44oGVyhVJHjzhd/mYcDgzEtdqKNfGY=; b=iEkZ3FnEX/dJa80dljJmX2DHzXSAF/oB/Fr7Dq6+88ShHiqbFcR5RVs+fRJzMuiAVL 9/3VkUvMzBhMRMuTb2F1LCnm2F4hM5MtmmeJYFXP+qjMG2HXktc6iVMOmCAaV1BhkCFu vfq9fn5NHhTgYSEO5Zf588X7Y01AHXj7vPeRMbRHXLZ4A8dCuNiKRKCyGIQMD2ZdFCpc 1z/oBFOybJcokz7PpKXrmVOskibbokjIBoHs3pUIFq7BPiTBSjHZWO392UCY2Z+31uNS Gi1HcJjrio7ijW7tULzUM3Dw2pQRuE3v75tyIL7S8KVSxu2W/mH9yMvubqcujctD3TuL obrQ==
X-Gm-Message-State: ALoCoQmZvQSIS+RTmIka/4q/JsjFykZ9ghcpGAtlMXw5q2b5BOgokr7eHoewqNIJodnwi7TFdnjo
X-Received: by 10.42.20.195 with SMTP id h3mr2350983icb.59.1413465076792; Thu, 16 Oct 2014 06:11:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.8.242 with HTTP; Thu, 16 Oct 2014 06:10:56 -0700 (PDT)
In-Reply-To: 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net> 
From: Lorenzo Colitti 
Date: Thu, 16 Oct 2014 22:10:56 +0900
Message-ID: 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=90e6ba1821b0ce339c050589fbfe
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/sCXApzVMFenlwga_itxUOXOuJ1g
Cc: HOMENET Working Group , Philip Homburg , Gert Doering 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 13:11:18 -0000

--90e6ba1821b0ce339c050589fbfe
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 16, 2014 at 1:28 AM, Ted Lemon  wrote:

> My point was that homenets should have ULAs, and should not use GUAs for
> local communication, because GUAs can be flash renumbered,


Actually, they can't.

http://tools.ietf.org/html/rfc4862#section-5.5.3 paragraph e) 3.

--90e6ba1821b0ce339c050589fbfe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
hu, Oct 16, 2014 at 1:28 AM, Ted Lemon <mellon@fugue.com> wro=
te:
My point was that homenets should have ULAs, and sh=
ould not use GUAs for local communication, because GUAs can be flash renumb=
ered,

Actually, they can't.
<=
br>
<=
/div>


--90e6ba1821b0ce339c050589fbfe--


From nobody Thu Oct 16 06:15:28 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03671A003A for ; Thu, 16 Oct 2014 06:15:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.394
X-Spam-Level: 
X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHA0SBNTBKfg for ; Thu, 16 Oct 2014 06:15:25 -0700 (PDT)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66BA21A1B91 for ; Thu, 16 Oct 2014 06:15:25 -0700 (PDT)
Received: by mail-ig0-f173.google.com with SMTP id h18so19340740igc.12 for ; Thu, 16 Oct 2014 06:15:24 -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; bh=OyQV9mKkQxTaOnXIBO6TBxTnIi6+0cjbPYhrNpynO1s=; b=ZavtZdprh4t5PmSaJyjoGmf2k+aM01wz14ZQzfGJu0KMsiaWPTvqFHzqqB6rP+mDqA TgOa50TaCfHDk5FDFwndgaIs8FilvEA7U7ZasUok5/8j7P+Bcx0IKLQUlTD4DKBszvu3 s/jaJDr74WEjBSSKmvtFlVJs6SGJv3Ygjr0bPLyL6UabciY8tMM9K6tFTbGTPwrrmf1h vXQaK2kn8yyf7lWzmjP8dWcx5uFEW1/JvQkKxxyzHYJIpPWFbc6OqMlO08jYzSYJ8jAC H5ncVr4vn6HdazJv39h7j++7o8DUGN6I5IxL5e8X9LVsTjUVr7/vZtCbxE2rXwHVSnAl dU4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OyQV9mKkQxTaOnXIBO6TBxTnIi6+0cjbPYhrNpynO1s=; b=Hi7cCLyz6ZpeINJ9APdHwiCcEXJ2wAZerg3mbunQo6m5hDRJjseohHcdc+80nbJZrZ 8jC8g8emIA9HkO1eLwp507pv4t9TqoX5WivUFNcISd6FTdoWw8fGKpy7TlasaL3yu2tz X8GdO/aXar3w04bXzcaZk+YJO9v3VBuPtdi7QHQ6e+4bQj8pdBrVGsLJqsZ9TJ7BmWPM JsC1f/55Bjf8w6ARHslHjilGPj0O4reDYK1e1mYoRfJVxAL3zNMg46/w3CWhD/LTgV9s AYpvhHW4whBoIxpZnJWg4FeV/1jRju2HOK8HuNen13N66WvONvGMJoK3ABw8qsCPMdqp UlqQ==
X-Gm-Message-State: ALoCoQnB/7LSKLj9KHj6fM+JXhCT1xyhJtXdRlbRl8izZTkJ6mtlmY7eDKPG+4rbYVDdfqGqTdUX
X-Received: by 10.107.167.66 with SMTP id q63mr1471937ioe.23.1413465324802; Thu, 16 Oct 2014 06:15:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.8.242 with HTTP; Thu, 16 Oct 2014 06:15:04 -0700 (PDT)
In-Reply-To: <457D177C-232E-4590-A9ED-80048140157F@fugue.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>
From: Lorenzo Colitti 
Date: Thu, 16 Oct 2014 22:15:04 +0900
Message-ID: 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=001a1141dd08967ffb05058a0a6f
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/91g-3xmkyorEEb6Op5srLOgPips
Cc: "homenet@ietf.org" , Michael Thomas 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 13:15:27 -0000

--001a1141dd08967ffb05058a0a6f
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 16, 2014 at 8:06 AM, Ted Lemon  wrote:

> Suppose you are connected to your homenet.   You are streaming video from
> your jukebox using your ULA.   Now your device switches to your neighbor's
> Wifi, which is advertising a different GUA and a different ULA.   At this
> point your device does a flash renumber because it realizes it's no longer
> on the same network, and that the prefixes it had are no longer valid.
>
> At this point, your application should get a notification from the stack
> that the connection has broken, at which point it should reconnect to your
> jukebox.


Ted, you're going in circles here. You've been arguing for many messages
that we should use ULAs because GUAs can be flash renumbered. And now you
provide an example of an event that *is* a flash renumbering, and then
proceed to say that everything will be fine because the application will
reconnect.

Pick one position or the other?

--001a1141dd08967ffb05058a0a6f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
hu, Oct 16, 2014 at 8:06 AM, Ted Lemon <mellon@fugue.com> wro=
te:
Suppose you are connected to your hom=
enet.=C2=A0 =C2=A0You are streaming video from your jukebox using your ULA.=
=C2=A0 =C2=A0Now your device switches to your neighbor's Wifi, which is=
 advertising a different GUA and a different ULA.=C2=A0 =C2=A0At this point=
 your device does a flash renumber because it realizes it's no longer o=
n the same network, and that the prefixes it had are no longer valid.



At this point, your application should get a notification from the stack th=
at the connection has broken, at which point it should reconnect to your ju=
kebox. =C2=A0

Ted, you're going in circ=
les here. You've been arguing for many messages that we should use ULAs=
 because GUAs can be flash renumbered. And now you provide an example of an=
 event that *is* a flash renumbering, and then proceed to say that everythi=
ng will be fine because the application will reconnect.

Pick one position or the other?


--001a1141dd08967ffb05058a0a6f--


From nobody Thu Oct 16 06:22:26 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821181A1B85 for ; Thu, 16 Oct 2014 06:22:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.394
X-Spam-Level: 
X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOA-DPRnkG2K for ; Thu, 16 Oct 2014 06:22:24 -0700 (PDT)
Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48C271A1B78 for ; Thu, 16 Oct 2014 06:22:24 -0700 (PDT)
Received: by mail-ig0-f181.google.com with SMTP id r10so3392215igi.8 for ; Thu, 16 Oct 2014 06:22:23 -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; bh=grfic+G91QnikX31UXPrrhf1xsCA8y/xC10qGrBuVUI=; b=T5rZRBPWOEmiRURurcq87JJ+VYHsrMCYWz1niMXU8LiRD74XMQxbJnx08vLVpAcxCn 7IC8VBtF3e1SOAB15Cm0bATwb4Xtq2AdohQCAE1stta6yYHc3+9hPhzMZQWIj+6jU2Wx P3W6jj5f8Tuf+tazLW+/V/vEhkxZXwHpP0islne2aSWR22pUR5hgIKViLlhOKDtIVvEl cmGQxImyGO+5EiuFhd/K5epS6/+zbd5umMEM6amKd94RXam43kq6emeuPX6nOTV8EhYs f2JhJClQBWky+OyxRKaFKPlQboBLTklaZquN04S8YDyMl6IY1WLnofWavYpLRoERoV7K TWMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=grfic+G91QnikX31UXPrrhf1xsCA8y/xC10qGrBuVUI=; b=kloY95cUFBjSmlHtJMFLMqMhA9GWOuFV+XmaVS1ITUophen5ClvN1rKNt0plu0oZhr joYtwYGG2ODZiT/bQ5SwzF2kq2sHKtM1L0j0U4vg5bjIe1XJJEIlTlamD60vQiYT4K+0 GJ6E3J/fhV6l9ussU8BXQ1Q4VOBxwDinyynGyhDz9Ra76F3jxPYEa2iOsLAv9rX7hxti HiwhV9SkpbrRlH2t1YjznXV103zsTlJJRYHEg3hAOyK9KkHiRTcau6vPcOLzq3/dKqst kekNmrZ+Dqr2NNabAlGIDo9bnSX5Bnq4X42Yq353ehFoQH4HeV+cwO8jMnFO8bw2Nhmp 5Vbg==
X-Gm-Message-State: ALoCoQmJtuh+Fok/rNXIz3zstdsDlozlPv4JTunXgYdtFDiX7sxJf4kufXUcgG+D1UN0VTAIUWzB
X-Received: by 10.42.27.82 with SMTP id i18mr4148822icc.28.1413465743653; Thu, 16 Oct 2014 06:22:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.8.242 with HTTP; Thu, 16 Oct 2014 06:22:03 -0700 (PDT)
In-Reply-To: <20141015232619.D687121808CE@rock.dv.isc.org>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <20141015232619.D687121808CE@rock.dv.isc.org>
From: Lorenzo Colitti 
Date: Thu, 16 Oct 2014 22:22:03 +0900
Message-ID: 
To: Mark Andrews 
Content-Type: multipart/alternative; boundary=20cf303dd7088da2c005058a23d9
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/oQrmWvf7QTknbiU3au-hOz5lB44
Cc: "homenet@ietf.org" , Michael Thomas , Ted Lemon 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 13:22:25 -0000

--20cf303dd7088da2c005058a23d9
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 16, 2014 at 8:26 AM, Mark Andrews  wrote:

> Unless you have really old stacks your device will pick the new GUA first to
> talk to your jukebox when you are on your neighbor's network and the ULA
> to talk to it when you are on your own.
>

No, it won't. It will pick GUA->GUA both times.

Per the table in http://tools.ietf.org/html/rfc6724#section-2.1 it will
pick the GUA as a destination address, and per Rule 6, it will choose the
GUA to connect to it.

Which means that if you *want* to force it to use ULA inside the network
and GUA outside, the only scalable option is to use split-tunnel DNS. You
could change the policy table too, but most users won't, unless the
standards change, and major OSes change the policy tables.

--20cf303dd7088da2c005058a23d9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
hu, Oct 16, 2014 at 8:26 AM, Mark Andrews <marka@isc.org> wrote:=

Unless=C2=A0you =
have really old stacks your device will pick the new GUA first=C2=A0=
to talk to your jukebox when you are on=
 your neighbor's network and=C2=A0the ULA to talk to it when you are on your own.

No, it won't. It will pick GUA->GUA bo=
th times.

Per the table in http://tools.ietf.org/html/rfc6724#sect=
ion-2.1 it will pick the GUA as a destination address, and per Rule 6, =
it will choose the GUA to connect to it.

Which mea=
ns that if you *want* to force it to use ULA inside the network and GUA out=
side, the only scalable option is to use split-tunnel DNS. You could change=
 the policy table too, but most users won't, unless the standards chang=
e, and major OSes change the policy tables.


--20cf303dd7088da2c005058a23d9--


From nobody Thu Oct 16 06:33:24 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEF01A1BCA for ; Thu, 16 Oct 2014 06:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mapPFCt6aVjW for ; Thu, 16 Oct 2014 06:33:22 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5A91A1B9B for ; Thu, 16 Oct 2014 06:33:22 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 8FC111FCAAC; Thu, 16 Oct 2014 13:33:15 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D85BC160056; Thu, 16 Oct 2014 13:36:19 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id A8CEB16004A; Thu, 16 Oct 2014 13:36:19 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E110E219B2F2; Fri, 17 Oct 2014 00:33:12 +1100 (EST)
To: Lorenzo Colitti 
From: Mark Andrews 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <20141015232619.D687121808CE@rock.dv.isc.org> 
In-reply-to: Your message of "Thu, 16 Oct 2014 22:22:03 +0900." 
Date: Fri, 17 Oct 2014 00:33:12 +1100
Message-Id: <20141016133312.E110E219B2F2@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/txgObbijJDPEcLJ4DxaLTi_z8HM
Cc: "homenet@ietf.org" , Michael Thomas , Ted Lemon 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 13:33:23 -0000

In message , Lorenzo Colitti write
s:
> --20cf303dd7088da2c005058a23d9
> Content-Type: text/plain; charset=UTF-8
> 
> On Thu, Oct 16, 2014 at 8:26 AM, Mark Andrews  wrote:
> 
> > Unless you have really old stacks your device will pick the new GUA first to
> > talk to your jukebox when you are on your neighbor's network and the ULA
> > to talk to it when you are on your own.
> >
> 
> No, it won't. It will pick GUA->GUA both times.

Actually it depends on which address has the longest match.  With
old stacks they are both treats as GUA.  ULA has at least 8 bits
in common but may have up to 47 bits in common.  The GUA is likely
to have 16+ bits in common.  There is no guarentee that the old
pair of addresses have been flushed to only leave the GUA.

> Per the table in http://tools.ietf.org/html/rfc6724#section-2.1 it will
> pick the GUA as a destination address, and per Rule 6, it will choose the
> GUA to connect to it.
> 
> Which means that if you *want* to force it to use ULA inside the network
> and GUA outside, the only scalable option is to use split-tunnel DNS. You
> could change the policy table too, but most users won't, unless the
> standards change, and major OSes change the policy tables.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


From nobody Thu Oct 16 06:34:07 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAD61A1B9B for ; Thu, 16 Oct 2014 06:34:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob9419Q5nFJL for ; Thu, 16 Oct 2014 06:34:04 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 910F81A037A for ; Thu, 16 Oct 2014 06:34:04 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 73AF223802B7; Thu, 16 Oct 2014 09:34:03 -0400 (EDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Thu, 16 Oct 2014 08:34:01 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com> 
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/eVSZPmKjFzs739g5FE9woCpdGps
Cc: "homenet@ietf.org" , Michael Thomas 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 13:34:05 -0000

On Oct 16, 2014, at 8:15 AM, Lorenzo Colitti  wrote:
> Ted, you're going in circles here. You've been arguing for many =
messages that we should use ULAs because GUAs can be flash renumbered. =
And now you provide an example of an event that *is* a flash =
renumbering, and then proceed to say that everything will be fine =
because the application will reconnect.

No, what I'm saying is that in this case you can't avoid the renumbering =
issue, so you just have to accept what the application does.   This in =
no way contradicts my point that flash renumbering is better avoided.

> On Thu, Oct 16, 2014 at 1:28 AM, Ted Lemon  wrote:
>> My point was that homenets should have ULAs, and should not use GUAs =
for local communication, because GUAs can be flash renumbered,
>>=20
> Actually, they can't.

Yes they can, as you just agreed:

> On Wed, Oct 15, 2014 at 12:13 AM, Ted Lemon  wrote:
>> There's no reason to do flash renumbering.
>>=20
> I think you'll find that the reason is that [ hardware manufacturers =
support | operators are willing to spend router resources for ] only one =
forwarding entry per customer at a time.


That seems to me to be begging for trouble.   As a rule routers have too =
much memory, not too little, so I find this reasoning unconvincing.   =
Taking a little memory away from the buffer cache to make the forwarding =
table bigger seems like a really good idea.

> Which means that if you *want* to force it to use ULA inside the =
network and GUA outside, the only scalable option is to use split-tunnel =
DNS. You could change the policy table too, but most users won't, unless =
the standards change, and major OSes change the policy tables.

We have already talked about good reasons for doing split-horizon DNS: =
you don't really want to advertise all the hosts on the local wire, just =
the ones you want to be globally-reachable.   And changing the policy =
table isn't that hard: if we want to have a special policy for the local =
ULA, we already have a mechanism for doing it that does not require O.S. =
vendors to hard-code a different policy table nor users to select one =
manually: stateless DHCPv6.   And for those who consider the use of =
DHCPv6 d=E9class=E9, it will still work without: you just won't be =
protected from a provider doing flash renumbering.


From nobody Thu Oct 16 06:35:08 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888CE1A037A for ; Thu, 16 Oct 2014 06:35:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.216
X-Spam-Level: 
X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZMwim8JB_Y2 for ; Thu, 16 Oct 2014 06:35:03 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B7861A1BDE for ; Thu, 16 Oct 2014 06:35:01 -0700 (PDT)
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 589cf345.2b34de409940.5898821.00-2438.16615200.nbfkord-smmo06.seg.att.com (envelope-from );  Thu, 16 Oct 2014 13:35:01 +0000 (UTC)
X-MXL-Hash: 543fc9850dcd9ddd-5acca46a56825ae156219af4b1b4e89e68d56451
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id b79cf345.0.5898738.00-2360.16614872.nbfkord-smmo06.seg.att.com (envelope-from );  Thu, 16 Oct 2014 13:34:54 +0000 (UTC)
X-MXL-Hash: 543fc97e333044da-d7ecb196462c26f570a62d2b8fb6f33873e91976
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9GDYouZ017869; Thu, 16 Oct 2014 09:34:51 -0400
Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9GDYTlX017579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Oct 2014 09:34:33 -0400
Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 16 Oct 2014 13:34:16 GMT
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.152]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 09:33:45 -0400
From: "STARK, BARBARA H" 
To: Lorenzo Colitti , Mark Andrews 
Thread-Topic: [homenet] Let's make in-home ULA presence a MUST !?
Thread-Index: AQHP54K2GqII5KZ8KUCnHFPeq3UJB5wvgUIAgABcm4CAAAw3AIAAA/SAgAAE6gD//8i16IAATh4AgAF83gCAAAhbgIAABAaAgAAK/oCAAAILAIAAFRCAgAAMRwCAAAZXgIAAEfyAgAAu6ACAAAJQgP//xPHsgAEsgYD//71HgA==
Date: Thu, 16 Oct 2014 13:34:15 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E61130EA399B@GAALPA1MSGUSRBF.ITServices.sbc.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <20141015232619.D687121808CE@rock.dv.isc.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.44.85]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=dshs/Sc4 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=ofMgfj31e3cA:10 a=MkazQOY1ecYA:10 a=BLceEmwcHowA:10 a=Ikc]
X-AnalysisOut: [TkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA]
X-AnalysisOut: [AAA:8 a=bZyJZ8YEHzDYQbDhC2gA:9 a=QEXdDO2ut3YA:10 a=qd5V-7c]
X-AnalysisOut: [jCYOk_nrG:21 a=NwIQ2Tw0st0MaM3h:21]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.23]
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/TZOYmOtY-VMOnT2fO2rDg9pC_pI
Cc: "homenet@ietf.org" , Michael Thomas , Ted Lemon 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 13:35:06 -0000

Pj4gVW5sZXNzwqB5b3UgaGF2ZSByZWFsbHkgb2xkIHN0YWNrcyB5b3VyIGRldmljZSB3aWxsIHBp
Y2sgdGhlIG5ldyBHVUEgZmlyc3TCoHRvIHRhbGsgdG8geW91ciBqdWtlYm94IHdoZW4geW91IGFy
ZSBvbiB5b3VyIG5laWdoYm9yJ3MgbmV0d29yayBhbmTCoHRoZSBVTEEgdG8gIHRhbGsgdG8gaXQg
d2hlbiB5b3UgYXJlIG9uIHlvdXIgb3duLg0KDQo+IE5vLCBpdCB3b24ndC4gSXQgd2lsbCBwaWNr
IEdVQS0+R1VBIGJvdGggdGltZXMuDQoNCj4gUGVyIHRoZSB0YWJsZSBpbiBodHRwOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9yZmM2NzI0I3NlY3Rpb24tMi4xIGl0IHdpbGwgcGljayB0aGUgR1VBIGFz
IGEgZGVzdGluYXRpb24gYWRkcmVzcywgYW5kIHBlciBSdWxlIDYsIGl0IHdpbGwgY2hvb3NlIHRo
ZSBHVUEgdG8gY29ubmVjdCB0byBpdC4NCg0KPiBXaGljaCBtZWFucyB0aGF0IGlmIHlvdSAqd2Fu
dCogdG8gZm9yY2UgaXQgdG8gdXNlIFVMQSBpbnNpZGUgdGhlIG5ldHdvcmsgYW5kIEdVQSBvdXRz
aWRlLCB0aGUgb25seSBzY2FsYWJsZSBvcHRpb24gaXMgdG8gdXNlIHNwbGl0LXR1bm5lbCBETlMu
IFlvdSBjb3VsZCBjaGFuZ2UgdGhlIHBvbGljeSB0YWJsZSB0b28sIGJ1dCBtb3N0IHVzZXJzIHdv
bid0LCB1bmxlc3MgdGhlIHN0YW5kYXJkcyBjaGFuZ2UsIGFuZCBtYWpvciBPU2VzIGNoYW5nZSB0
aGUgcG9saWN5IHRhYmxlcy4NCg0KTm8sIHRoZSBSRkMgNjcyNCBydWxlcyBhcmUgcmVjb21tZW5k
ZWQgKmRlZmF1bHQqIHJ1bGVzLiBUaGUgYXV0aG9ycyBvZiB0aGF0IFJGQyBkaWQgYW4gZXhjZWxs
ZW50IGpvYiBhdCBtYWtpbmcgdGhhdCBjbGVhci4gSU1PLCB1c2VycyAod2hvIGtub3cgaG93KSBz
aG91bGQgYmUgZnJlZSB0byBjaGFuZ2UgdGhlIGRlZmF1bHQgcnVsZXMgaW4gdGhlaXIgZGV2aWNl
cyBpZiB0aGV5IGRvbid0IGxpa2UgdGhvc2UgcnVsZXMuIEFwcGxpY2F0aW9uIGRldmVsb3BlcnMg
YXJlIGZyZWUgdG8gaW1wbGVtZW50IHdoYXRldmVyIHJ1bGVzIG1ha2Ugc2Vuc2UgZm9yIHRoZWly
IGFwcGxpY2F0aW9ucy4gSSd2ZSBiZWVuIGludm9sdmVkIHdpdGggYXBwbGljYXRpb25zIHdoZXJl
IHRoZSBkZWZhdWx0IHJ1bGVzIHdvdWxkIGhhdmUgY2F1c2VkIGluY3JlYXNlZCBjb21wbGV4aXR5
IGluIGFwcGxpY2F0aW9uIGRlc2lnbiwgc28gcnVsZXMgdGhhdCBtYWRlIHNlbnNlIGZvciB0aGF0
IGFwcCB3ZXJlIHVzZWQgaW5zdGVhZC4gDQo=


From nobody Thu Oct 16 06:37:39 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C25C1A1BC5 for ; Thu, 16 Oct 2014 06:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.394
X-Spam-Level: 
X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOJUJ5YjHgpo for ; Thu, 16 Oct 2014 06:37:35 -0700 (PDT)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C20B1A1BCA for ; Thu, 16 Oct 2014 06:37:34 -0700 (PDT)
Received: by mail-ig0-f177.google.com with SMTP id a13so3390057igq.16 for ; Thu, 16 Oct 2014 06:37:34 -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; bh=gwR6Ag6nD2f0tcDbhu4jseC1LxwdGE7v9+TBLosDuDo=; b=VFRckXBUoTAteoP4muaFDKU4aAjN19nRGF+c/2Qm0wM1a3f/6zbDzMlQ2Tlcs7As3I ewx9MwLrAIvVtHorgk/CA0ci1gAyjNbLfgqyjtWX3hKbInpGc9Mi85eQhVan/etnjswy R7Crzh4zW7BT5n1yBg12TzJAPy8IE5Ysznc10hOfbFknnq87ahljYMPpZt4NUwD9xmgC zC48AuJaE8fvNsuZXzNQ7MhfoBtnvwVtOHCAof7xEe4SqqUumoIyQ3QJQIlSNN/8i7dK z2ERwIOTITm2POQOLtl8IGZG+mY5iHj9gd7xXOsIKerE6vUOkYdiZf0POe1j3/1wL7FM rk1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gwR6Ag6nD2f0tcDbhu4jseC1LxwdGE7v9+TBLosDuDo=; b=G/aKaVO59UF/JUatF2r+q/7rsbSAoi3rzLsD+FBd6sVIDKjD/OdgMmudRjTnzhQUv5 9fcDkKrGRRNtzfW899O9ZUIQL27vJFtNekhWwWF4gxw3I+752inUuJrchDTkQChGdo25 GG9zmb8wnn+oKdiJ7EEzI5nhOwTBaUpEsV/iQiT28H9+rJOjhmlWiljxFxg7XJ1Z/Pyj Ip7QETUXbdlpXrRTBxGufABrEMcST3hFaE+h5l1ud+OW0ublhg/p1tW0BILAAajp/XKL 3+7+QzwqQVr4zZ5ajUuF6IDGiC/SgtHyIslZQskFa1/5tFXdLz5cy21oVRpM3TfWy0LS 6xcw==
X-Gm-Message-State: ALoCoQnqs4wkW0BVqpR06yXlre5OZ44pz6WAhStrpV9zqz2aR54i3bZmBzfftlcwtfUkXzxzXuc5
X-Received: by 10.107.15.224 with SMTP id 93mr1637682iop.86.1413466654332; Thu, 16 Oct 2014 06:37:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.8.242 with HTTP; Thu, 16 Oct 2014 06:37:13 -0700 (PDT)
In-Reply-To: <20141016133312.E110E219B2F2@rock.dv.isc.org>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <20141015232619.D687121808CE@rock.dv.isc.org>  <20141016133312.E110E219B2F2@rock.dv.isc.org>
From: Lorenzo Colitti 
Date: Thu, 16 Oct 2014 22:37:13 +0900
Message-ID: 
To: Mark Andrews 
Content-Type: multipart/alternative; boundary=001a113fe228d5a50f05058a599c
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/FTASEprcHDCUYdPX377ytKzvSoM
Cc: "homenet@ietf.org" , Michael Thomas , Ted Lemon 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 13:37:36 -0000

--001a113fe228d5a50f05058a599c
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 16, 2014 at 10:33 PM, Mark Andrews  wrote:

> > > Unless you have really old stacks your device will pick the new GUA
> first to
> > > talk to your jukebox when you are on your neighbor's network and the
> ULA
> > > to talk to it when you are on your own.
> > >
> >
> > No, it won't. It will pick GUA->GUA both times.
>
> Actually it depends on which address has the longest match.  With
> old stacks they are both treats as GUA.  ULA has at least 8 bits
> in common but may have up to 47 bits in common.  The GUA is likely
> to have 16+ bits in common.  There is no guarentee that the old
> pair of addresses have been flushed to only leave the GUA.
>

No, it doesn't. Please read RFC 6724 again, or at least read the links I
provided.

--001a113fe228d5a50f05058a599c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
hu, Oct 16, 2014 at 10:33 PM, Mark Andrews <marka@isc.org> wrote=
:
> > Unless you have really =
old stacks your device will pick the new GUA first to

> > talk to your jukebox when you are on your neighbor's network =
and the ULA

> > to talk to it when you are on your own.

> >

>

> No, it won't. It will pick GUA->GUA both times.



Actually it depends on which address has the longest match.=C2=A0 Wi=
th

old stacks they are both treats as GUA.=C2=A0 ULA has at least 8 bits

in common but may have up to 47 bits in common.=C2=A0 The GUA is likely

to have 16+ bits in common.=C2=A0 There is no guarentee that the old

pair of addresses have been flushed to only leave the GUA.
=


No, it doesn't. Please read RFC 6724 again, or at l=
east read the links I provided.


--001a113fe228d5a50f05058a599c--


From nobody Thu Oct 16 06:43:57 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B6D1A010C for ; Thu, 16 Oct 2014 06:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.394
X-Spam-Level: 
X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIbznxXft94l for ; Thu, 16 Oct 2014 06:43:53 -0700 (PDT)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F4F1A008C for ; Thu, 16 Oct 2014 06:43:52 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id rd18so3481093iec.1 for ; Thu, 16 Oct 2014 06:43:52 -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; bh=R8WEIU9xHWE7hT8hbdZrp9KZchlQItvliXYvNT6B59M=; b=asVJcrCk9CVUFCznYclZRypsGiA6SSGauj+AvW1dAyfCmtLnmcowJTorHVsN+aaQn8 Vsd90uBnB3ULkV3S+9S7Q4HITwWwkO+K3Rfyp/78wIEjReM1h2C+GIYuU0e6XbXCzZVQ tJ4sRrxs4HVe1OvkHKlsx1tXmvUIBkf9tWiAFONuuKDcZswbutV5nqGsXlJNZWZecz9v aD45kPAcIvbp5eas6pvVO5Wf4G9v203kWg0/ayXOMPo8oDr/Jqh1LhIMsxFMZZBa+OoN WRgJteDXqsBjC6V6jT7ZcFQokVJyiXlunBbsljwX74p09EY5oH35q0luUYMRykQct1dT bxtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=R8WEIU9xHWE7hT8hbdZrp9KZchlQItvliXYvNT6B59M=; b=B4LYohdSI10gKIcD0XWqU7FIYh8tqhUcttgVYynNFZ6viIGcGhx4OqnvCH8gAJ/RxU 10hZc5pxRCU1BPJSGMnniu6Lo3YCMDm1Zt6KNkSMSIW243e8IBfwi0HjVKSdEl4bT8jA LTliFPsIQq6t2q0PpOy+OFHuLb1+l/UprO+Sul3N7vEpojvzNS2LkFMrGreQI/5BDbgj I/XNLHeTFuVkdbW3VfBc31ejfkA0u7rlEpl2/aXECphrDCJjswwb7Owkpiq1eGnc/n3m GlP5vIqd3YUSfjpMgjsf1jzK0UyZIpT/FmH8nHU4c7xWpLqyoLoxIKCFIc+voi1GbKwi bXpA==
X-Gm-Message-State: ALoCoQmm2JAAZUB81BTzI4L84B67iDIou/ERZXf+cmnqjnHNNOrdopG3SRjrQ8DgIRaUZmqznClr
X-Received: by 10.107.130.136 with SMTP id m8mr1764568ioi.8.1413467032356; Thu, 16 Oct 2014 06:43:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.8.242 with HTTP; Thu, 16 Oct 2014 06:43:31 -0700 (PDT)
In-Reply-To: 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>  
From: Lorenzo Colitti 
Date: Thu, 16 Oct 2014 22:43:31 +0900
Message-ID: 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=001a113ed31c5de2eb05058a7086
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/XNhywkRA8sza70w5zZc6S3H5Dbo
Cc: "homenet@ietf.org" , Michael Thomas 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 13:43:54 -0000

--001a113ed31c5de2eb05058a7086
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 16, 2014 at 10:34 PM, Ted Lemon  wrote:

> >> My point was that homenets should have ULAs, and should not use GUAs
> for local communication, because GUAs can be flash renumbered,
> >>
> > Actually, they can't.
>
> Yes they can, as you just agreed:
>

No, I didn't.

You seem to define flash renumbering as "your ISP invalidates your prefix
and gives you a new one". But such an event does *not* mean that the host
can't use its previous addresses any more, because the RA sent to the hosts
cannot reduce the valid lifetime below 2 hours. So in effect that's still
graceful renumbering with a 2-hour window.

That seems to me to be begging for trouble.   As a rule routers have too
> much memory, not too little, so I find this reasoning unconvincing.
>  Taking a little memory away from the buffer cache to make the forwarding
> table bigger seems like a really good idea.
>

Routers have many different types of memories, at very different costs.
DRAM is cheap. The stuff they store forwarding tables in is not. It's
expensive and hot.


> And changing the policy table isn't that hard: if we want to have a
> special policy for the local ULA, we already have a mechanism for doing i=
t
> that does not require O.S. vendors to hard-code a different policy table
> nor users to select one manually: stateless DHCPv6.   And for those who
> consider the use of DHCPv6 d=C3=A9class=C3=A9, it will still work without=
: you just
> won't be protected from a provider doing flash renumbering.
>

And when your ISP renumbers you, or a new ULA joins the network, you're
going to tell the hosts about the new prefix policy using what type of
packet? There's no reconfigure in stateless DHCPv6.

--001a113ed31c5de2eb05058a7086
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
hu, Oct 16, 2014 at 10:34 PM, Ted Lemon <mellon@fugue.com> wr=
ote:
>> My point w=
as that homenets should have ULAs, and should not use GUAs for local commun=
ication, because GUAs can be flash renumbered,

>>

> Actually, they can't.



Yes they can, as you just agreed:

No, I didn't.

You seem to define flash renum=
bering as "your ISP invalidates your prefix and gives you a new one&qu=
ot;. But such an event does *not* mean that the host can't use its prev=
ious addresses any more, because the RA sent to the hosts cannot reduce the=
 valid lifetime below 2 hours. So in effect that's still graceful renum=
bering with a 2-hour window.

That seems to me to be begging for trouble.=C2=A0 =C2=A0As a rule rout=
ers have too much memory, not too little, so I find this reasoning unconvin=
cing.=C2=A0 =C2=A0Taking a little memory away from the buffer cache to make=
 the forwarding table bigger seems like a really good idea.

Routers have many different types of memories, at very=
 different costs. DRAM is cheap. The stuff they store forwarding tables in =
is not. It's expensive and hot.
=C2=A0
And changing the policy table isn't that hard: if we want=
 to have a special policy for the local ULA, we already have a mechanism fo=
r doing it that does not require O.S. vendors to hard-code a different poli=
cy table nor users to select one manually: stateless DHCPv6.=C2=A0 =C2=A0An=
d for those who consider the use of DHCPv6 d=C3=A9class=C3=A9, it will stil=
l work without: you just won't be protected from a provider doing flash=
 renumbering.

And when your ISP renumbe=
rs you, or a new ULA joins the network, you're going to tell the hosts =
about the new prefix policy using what type of packet? There's no recon=
figure in stateless DHCPv6.


--001a113ed31c5de2eb05058a7086--


From nobody Thu Oct 16 06:47:02 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E851A00F1 for ; Thu, 16 Oct 2014 06:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.394
X-Spam-Level: 
X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYPZn7CP1D33 for ; Thu, 16 Oct 2014 06:46:59 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3BD1A0123 for ; Thu, 16 Oct 2014 06:46:59 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id tp5so3457867ieb.32 for ; Thu, 16 Oct 2014 06:46:58 -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; bh=AOH8MSOTIGsxbFiPDwtX2Ya7pjBV0gw5SoiJ5OUT1Qo=; b=M5zbw+g0y9NzdQm0uOa/xYoxhY9jSqyZ8dI4jH32XKb7XCFGZi3k9tyBDwHgpJXs3Z BbjJNbxdSZ2S/oQTcjCaU4UPPEM8en4IJnYvr9EbWvaNXycreTMfMSnoTAwyA0tiSPC9 DpCAko0IJDRzs2VENuyihgxhK1HPuZJzEWhAAEol/aqlENk7t4emXs9m/xxA218GCjSa U7OFNxbmYoW+4ZAOM0qmt6UG221l9vv6en6y87cJMBLj1I1EBm7Yjq5XDV5D3ZU7VlEm 1LLqi87r/i+kQMF7BgriBBtFxtpIi3QhQxSrFRw1r3MBsSKxO6RLKrRqKvZWCW4GYLRU 43pA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=AOH8MSOTIGsxbFiPDwtX2Ya7pjBV0gw5SoiJ5OUT1Qo=; b=TnsguY7AvEd5h3nif+jwMxMbqauu3SLmIeGujZ5lMcmSER3Skp4pdOK3jvYN1282jH P/CCcZShD0qqCPXILbhHidyJGQn6t8FtEG21yo8NbvaMWwoPW7b7f2Sze7gZA96Nfdo1 kGkqqs7/dCIJFpwZBMKaY47uF5DEh1qKTm8SEd3Exly4D0RPpnFESZ3EGMAZ86/TEfH7 UbFpIH/uH2Ndp3ejns1vBRoFzRp17LXiMjsQYiqUF10xTNKjTfeT2KcPEiAQ74Mb7xhk spG5FBq36TLkM5jj/FAuO0NQ8GX1F569J8SCpP8rlv9MQwYjkLWraUC5sGx0aqqJ3FRc VSqQ==
X-Gm-Message-State: ALoCoQlmCKtINw+jQMU2FQkIXtZcDiHzK7hxtGR0aH4okQMgULJo3wAAHla+vZnseTT4mNdEaZZu
X-Received: by 10.107.17.206 with SMTP id 75mr1670810ior.90.1413467218707; Thu, 16 Oct 2014 06:46:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.8.242 with HTTP; Thu, 16 Oct 2014 06:46:38 -0700 (PDT)
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130EA399B@GAALPA1MSGUSRBF.ITServices.sbc.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <20141015232619.D687121808CE@rock.dv.isc.org>  <2D09D61DDFA73D4C884805CC7865E61130EA399B@GAALPA1MSGUSRBF.ITServices.sbc.com>
From: Lorenzo Colitti 
Date: Thu, 16 Oct 2014 22:46:38 +0900
Message-ID: 
To: "STARK, BARBARA H" 
Content-Type: multipart/alternative; boundary=001a113f4fd679393605058a7b65
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/RODw07fJentYwU4scGW39QlFTSY
Cc: "homenet@ietf.org" , Michael Thomas , Ted Lemon , Mark Andrews 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 13:47:00 -0000

--001a113f4fd679393605058a7b65
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 16, 2014 at 10:34 PM, STARK, BARBARA H  wrote:

> No, the RFC 6724 rules are recommended *default* rules. The authors of
> that RFC did an excellent job at making that clear. IMO, users (who know
> how) should be free to change the default rules in their devices if they
> don't like those rules. Application developers are free to implement
> whatever rules make sense for their applications. I've been involved with
> applications where the default rules would have caused increased complexity
> in application design, so rules that made sense for that app were used
> instead.
>

It seems to me that if you were more of an application developer and less
of a network engineer you would not have such a high opinion of the degree
of knowledge about (and interest for) networking generally possessed by
application developers. :-)

--001a113f4fd679393605058a7b65
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
hu, Oct 16, 2014 at 10:34 PM, STARK, BARBARA H <bs7652@att.com>=
 wrote:
No, the RFC 6724 rules are recommended *default* rules. The au=
thors of that RFC did an excellent job at making that clear. IMO, users (wh=
o know how) should be free to change the default rules in their devices if =
they don't like those rules. Application developers are free to impleme=
nt whatever rules make sense for their applications. I've been involved=
 with applications where the default rules would have caused increased comp=
lexity in application design, so rules that made sense for that app were us=
ed instead.



It seems to me that=
 if you were more of an application developer and less of a network enginee=
r you would not have such a high opinion of the degree of knowledge about (=
and interest for) networking generally possessed by application developers.=
 :-)


--001a113f4fd679393605058a7b65--


From nobody Thu Oct 16 07:06:23 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27F01A1A37 for ; Thu, 16 Oct 2014 07:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04XfcJzwfq9O for ; Thu, 16 Oct 2014 07:06:19 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 10B601A1A52 for ; Thu, 16 Oct 2014 07:06:19 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id BD07C238045C; Thu, 16 Oct 2014 10:06:17 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Thu, 16 Oct 2014 09:06:15 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>   
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/4Bq34xprYEpEyEzoeaCxhvJ11vE
Cc: "homenet@ietf.org" , Michael Thomas 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 14:06:20 -0000

On Oct 16, 2014, at 8:43 AM, Lorenzo Colitti  wrote:
> And when your ISP renumbers you, or a new ULA joins the network, =
you're going to tell the hosts about the new prefix policy using what =
type of packet? There's no reconfigure in stateless DHCPv6.

Wouldn't the host do a DHCP Information Request when it sees a new =
prefix?


From nobody Thu Oct 16 07:09:00 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3121A1A66 for ; Thu, 16 Oct 2014 07:08:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.394
X-Spam-Level: 
X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8SibshlxcaP for ; Thu, 16 Oct 2014 07:08:53 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20BAC1A1A28 for ; Thu, 16 Oct 2014 07:08:52 -0700 (PDT)
Received: by mail-ie0-f175.google.com with SMTP id x19so3509394ier.20 for ; Thu, 16 Oct 2014 07:08:51 -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; bh=W4+tlGikaai5L96XSTazmpTA2jT5zr0gJGUFwbGMVIc=; b=V5BYh9/ZltSxLPRa6tM/x2NWbCjDPCZjxWwtWpYM9E1KmlucHVIIjAM24RodsvJS8e 9A9skooUo+gdPByE6ohqao97yoOgF82GGs0Oa4qjSNB77iAAc/7GF/GAybL2vCX0GZWS dI9Ok++JE3ykMQ9X0j5bZOOF9AFcuPp1ZTwNp9xDubibI/pcyDJ1FWep3+jcQNZKM07e hWmclOvazG0cLd0ekOKWq1s79tUlb9V6TCLis/qEJQ+W1FRYU+hjjvV/ZHV//gvYnIdf xnapWIqoDh+zWNEOXnyKhNVZiYruqOhD5XJhtg4PAxdi2Mm45mYm7Px9zRLJrW5VGX5l HZTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=W4+tlGikaai5L96XSTazmpTA2jT5zr0gJGUFwbGMVIc=; b=NkcF/kbGdiVC5nKeh/Iz/qeW16Pmir04NmAnMXZAoGsGhcRNS/l4Jb7R1HXleF6fLI IldngPHz8aL12JYT6AKblZ8pIG7D+SKzaFKmuildA+IEIcGNYAphp8K7gN4izEy9D7Jj 7kOw75T9aSk2+qlTbW0LnwK5A0isCXrZtB5/HAqk7eVEgDx7oIVmEfEAIhzvkE2HDjm3 7QxsQ0NL93oedu4Akvv6PIoBTnR/lyKdc+0ZsFgeRj1stIi0E2/RvUqwBudmmlZsELyZ vNuUlZmKGfmUvVVUxmid2dSHj6Aqe1Go4gA4h4xUzao+AbUJxuHWB6Sl22OZ20p129Wi ML2w==
X-Gm-Message-State: ALoCoQlLKBrkGeyj326X3y6bGPTIC8LvoDoj8IfbWwXDmH/ZP8EBR2igLm3qlPmvyHKMP3Qpy+9k
X-Received: by 10.50.6.2 with SMTP id w2mr21701216igw.29.1413468531298; Thu, 16 Oct 2014 07:08:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.8.242 with HTTP; Thu, 16 Oct 2014 07:08:31 -0700 (PDT)
In-Reply-To: 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>    
From: Lorenzo Colitti 
Date: Thu, 16 Oct 2014 23:08:31 +0900
Message-ID: 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=047d7bd6c2d8b5bcb505058ac908
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/_5gQbVQIwMWPiQZIIspFThpXb2U
Cc: "homenet@ietf.org" , Michael Thomas 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 14:08:55 -0000

--047d7bd6c2d8b5bcb505058ac908
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 16, 2014 at 11:06 PM, Ted Lemon  wrote:

> On Oct 16, 2014, at 8:43 AM, Lorenzo Colitti  wrote:
> > And when your ISP renumbers you, or a new ULA joins the network, you're
> going to tell the hosts about the new prefix policy using what type of
> packet? There's no reconfigure in stateless DHCPv6.
>
> Wouldn't the host do a DHCP Information Request when it sees a new prefix?
>

Um, no? Why would it?

--047d7bd6c2d8b5bcb505058ac908
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
hu, Oct 16, 2014 at 11:06 PM, Ted Lemon <mellon@fugue.com> wr=
ote:
On Oct 16, 2014, at=
 8:43 AM, Lorenzo Colitti <lorenzo=
@google.com> wrote:

> And when your ISP renumbers you, or a new ULA joins the network, you&#=
39;re going to tell the hosts about the new prefix policy using what type o=
f packet? There's no reconfigure in stateless DHCPv6.



Wouldn't the host do a DHCP Information Request when it sees a n=
ew prefix?

Um, no? Why would it?=C2=A0<=
/div>



--047d7bd6c2d8b5bcb505058ac908--


From nobody Thu Oct 16 07:11:21 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36AC1A1A70 for ; Thu, 16 Oct 2014 07:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0EYHd8-WCjh for ; Thu, 16 Oct 2014 07:11:18 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A970E1A1A5B for ; Thu, 16 Oct 2014 07:11:15 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id B1CC2238045C; Thu, 16 Oct 2014 10:11:14 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Thu, 16 Oct 2014 09:11:11 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <94C19398-AC5A-416F-8C3E-EA6B1750C22C@fugue.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>     
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ZjEUJK9OE8l28JXDGkgpIdL9hAM
Cc: "homenet@ietf.org" , Michael Thomas 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 14:11:18 -0000

On Oct 16, 2014, at 9:08 AM, Lorenzo Colitti  wrote:
> Um, no? Why would it? 

Because that's an indication that there is new information to be had.


From nobody Thu Oct 16 07:19:13 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D821A1AA9 for ; Thu, 16 Oct 2014 07:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.394
X-Spam-Level: 
X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7D-drvObxzs for ; Thu, 16 Oct 2014 07:19:10 -0700 (PDT)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB7E1A1A7F for ; Thu, 16 Oct 2014 07:19:10 -0700 (PDT)
Received: by mail-ig0-f170.google.com with SMTP id hn15so1121407igb.5 for ; Thu, 16 Oct 2014 07:19:09 -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; bh=aVu3l32HR2zTEWXCmefZwWmz3ilQJoS2sy8sWq4JXLg=; b=E8oh/NZdObGxyly9zWa6yNDMqoqdiKLspQeLthHdUAtUk60DrtYge9aEE5Y4AYNzDM KdWoyOt+iG7Wk1oyzFXemSrW2Oa/VR64MRoY8ucMLcxOLQ+QzW7LorTMHnsHiK1xOHuJ U/qxDHMUgnbuEUR0YQVzLink3ozN8PqeIG4tnRd3vWSWWMJCYLXw5VsUvwoEJGzfHfCS ffvWrVZE8vS+V1g2XbaDly7+WBk6J8f8JNvTUJCTwzVhkOKqEZYJeIys0HKcl6QEBarB eKNKTztk+c4Tg8aoBjRaEMrYsmK5141JTthkDy83s7tQOTQcDQYR1gKKtVkB6z/YE12c ui4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aVu3l32HR2zTEWXCmefZwWmz3ilQJoS2sy8sWq4JXLg=; b=Y1caUzjktTEUP5p/sXuncCoVb5vlIePDXGEvB3CIZhsDH2Gdp12mX14Y+WuJOEWD1F l++sN9XLVa+JzVyYRiIONHqvCVl/TDKByA/ZEgLB6DUrpVbsveS8sm/tL5fMYYiAev62 FpSJkCNfSzcIt151k4UH2rgcLH65iUufSm8wCfB2MkbnUr1tjHQuGgd7QpRyyeghAD9y btXQtZATpZgoG2SXWAWdyLvH1/d09UCoUJcXWHqmn8+/zwi+LkYETpoKP2CsaLhiIR3u f3vHbMuJZ9rfZu2GgUkbiDxAtxJqwTgMcuKZ3mLq8+qWc3eBhpHyDI87v7GjaU5AyJOu y5vw==
X-Gm-Message-State: ALoCoQm1q2EYt5cdBRaJMV2Vy7T/YQiVAnIUCqf0BFv1zbhNskFUi90ZbBFv0/i7Y/ysmCpXaFeP
X-Received: by 10.50.164.233 with SMTP id yt9mr5437445igb.2.1413469149571; Thu, 16 Oct 2014 07:19:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.8.242 with HTTP; Thu, 16 Oct 2014 07:18:49 -0700 (PDT)
In-Reply-To: <94C19398-AC5A-416F-8C3E-EA6B1750C22C@fugue.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>     <94C19398-AC5A-416F-8C3E-EA6B1750C22C@fugue.com>
From: Lorenzo Colitti 
Date: Thu, 16 Oct 2014 23:18:49 +0900
Message-ID: 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=089e0149beac8fd8b505058aee63
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/VpcPZOSmXi5ceD-enbXqVho_ncw
Cc: "homenet@ietf.org" , Michael Thomas 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 14:19:11 -0000

--089e0149beac8fd8b505058aee63
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 16, 2014 at 11:11 PM, Ted Lemon  wrote:

> On Oct 16, 2014, at 9:08 AM, Lorenzo Colitti  wrote:
> > Um, no? Why would it?
>
> Because that's an indication that there is new information to be had.
>

So every time a new prefix comes in, hosts should restart DHCPv6? That
seems pretty dubious (and expensive). I don't think any DHCP implementation
works that way.

--089e0149beac8fd8b505058aee63
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
hu, Oct 16, 2014 at 11:11 PM, Ted Lemon <mellon@fugue.com> wr=
ote:
On Oct 16, 2014, at=
 9:08 AM, Lorenzo Colitti <lorenzo=
@google.com> wrote:

> Um, no? Why would it?



Because that's an indication that there is new information to be=
 had.

So every time a new prefix comes =
in, hosts should restart DHCPv6? That seems pretty dubious (and expensive).=
 I don't think any DHCP implementation works that way.=C2=A0



--089e0149beac8fd8b505058aee63--


From nobody Thu Oct 16 07:27:31 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E707B1A19FC for ; Thu, 16 Oct 2014 07:27:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.006
X-Spam-Level: 
X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBUEgzeYGN-G for ; Thu, 16 Oct 2014 07:27:29 -0700 (PDT)
Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00F401A1A28 for ; Thu, 16 Oct 2014 07:27:28 -0700 (PDT)
Received: by mail-qa0-f44.google.com with SMTP id x12so2485898qac.3 for ; Thu, 16 Oct 2014 07:27:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=o/o/YI11/yy3o/D64krftP2bSxHqDPlfvrvE3AkjwSQ=; b=kRhmemWmoiA/QV76g1uRIRZC017vPFmpx27g4xAPHU6REfkhbl51wW1VcTnGR5l9PD x7ZxcIuByXih3YmwTN6Jp4/TuWgN8qsry13qXNsivoaQn8qnHlp0ByXH3yYd9KXEm+0F OK7EkVj15E0AFlEgIDlFXEtjBociltUgKDOpwWWIw3EWEZiX3DDMdg1q6RujEajew38W qQbRBN2ysM5ieCM2b+GVwT4QWnc8lX8Mt6ZBhhjqYuf6Z5B0+xDK8zVWFdBXpIijS/5a 2R8Ub5M6oOjDE26rZ2eZEKDo36SJglbz892jPofVSLPohH9sH7lg5axyozoOvISBs/zL cDcQ==
X-Received: by 10.140.33.183 with SMTP id j52mr2272725qgj.95.1413469648087; Thu, 16 Oct 2014 07:27:28 -0700 (PDT)
Received: from che-vpn-cluster-2-136.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id d8sm21113456qam.46.2014.10.16.07.27.26 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 07:27:27 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ralph Droms 
In-Reply-To: 
Date: Thu, 16 Oct 2014 10:27:28 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <3A175899-19B3-4801-9A2D-3DEEF03D6897@gmail.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>     <94C19398-AC5A-416F-8C3E-EA6B1750C22C@fugue.com> 
To: Lorenzo Colitti , Ted Lemon 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/STPVvmlAlujmnUANwvzDxFAEoA4
Cc: "homenet@ietf.org" , Michael Thomas 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 14:27:30 -0000

On Oct 16, 2014, at 10:18 AM 10/16/14, Lorenzo Colitti =
 wrote:

> On Thu, Oct 16, 2014 at 11:11 PM, Ted Lemon  wrote:
> On Oct 16, 2014, at 9:08 AM, Lorenzo Colitti  =
wrote:
> > Um, no? Why would it?
>=20
> Because that's an indication that there is new information to be had.
>=20
> So every time a new prefix comes in, hosts should restart DHCPv6? That =
seems pretty dubious (and expensive).

Dubious?  Perhaps.  I don't know of any specification that suggests =
sending an Information-request message upon receipt of information about =
a new prefix or prefixes.

Expensive?  Can you prove "expensive"?  In my opinion and experience, =
this claim is more FUD about how "expensive" DHCPv6 is.

Way off course for this discussion?  Almost certainly.

- Ralph

> I don't think any DHCP implementation works that way.=20


From nobody Thu Oct 16 07:27:58 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBF71A1AEC for ; Thu, 16 Oct 2014 07:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_igFfTSI8_s for ; Thu, 16 Oct 2014 07:27:51 -0700 (PDT)
Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32DE1A1A66 for ; Thu, 16 Oct 2014 07:27:50 -0700 (PDT)
Received: by mail-wg0-f46.google.com with SMTP id l18so3877584wgh.5 for ; Thu, 16 Oct 2014 07:27:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=RFJ97pLpPS4964ORjMHfmumiCj2Kr0FnJOFCzpYlXw4=; b=YVwq+HWi0HVFQsdG74orEHeVHn+kLON15hCCkd2bKOz0YW/c93SNDnVGoLQvUF67O2 M7OsWxjr/qgWvmggCImHmu/RqGC7AezPXloMhoNSF4m0bN1ldAhEYTW7PoctFXIocduH o0uARQHzaRpsx3L9VU5KHaNVaY69zJ5AH6HBGimGQE3kE/wR06UIVwxE2A2Qq/ydFeZi B0nGZa66JrGZNCn+fJaVrdY1kHUvDSjQh2aZtH8cihILHTY885rN7uhgiY39/NZCgDtS g7wM7WSjWyr+VVpFYzty8VuThD5OdWZAyrkuinv4j4gQKOWQbkFVd7GHJ556EKzxy454 3+HQ==
X-Gm-Message-State: ALoCoQnXGHugsomScUX5Gl1xBXzjpgEi/VPD8NrYEzjoVT88y+O5qItqhtrsXtbKvkeZ5/3vVTOJ
X-Received: by 10.180.73.244 with SMTP id o20mr6607976wiv.9.1413469669198; Thu, 16 Oct 2014 07:27:49 -0700 (PDT)
Received: from [100.100.19.14] (135.16.90.92.rev.sfr.net. [92.90.16.135]) by mx.google.com with ESMTPSA id hr10sm2195816wib.9.2014.10.16.07.27.45 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 07:27:48 -0700 (PDT)
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr>  <37213B35-CAE1-4AF7-B94D-2B5EAD1C4A39@darou.fr> <5308B561-200A-455C-B2E9-4B4824ED2A1D@ecs.soton.ac.uk>  <5435D845.9030108@gmail.com>   <0D6BC65B-CD29-4C90-8787-365C79542DDC@employees.org>   <842E6585-18FF-4286-8C6F-C683500D47FC@townsley.net> <3D635F2F-15E1-45A7-869C-ACF82FDC60BF@ecs.soton.ac.uk> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-6A913918-E646-40B8-95B0-EEA1AA9BAC08
Content-Transfer-Encoding: 7bit
Message-Id: <142FE72F-8FD9-4CCA-AA02-F8A35CFBCB42@townsley.net>
X-Mailer: iPhone Mail (12A405)
From: "Townsley.net" 
Date: Thu, 16 Oct 2014 16:27:40 +0200
To: Tim Chown 
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/3Fm2bNTa1aypFxZlYQAaG84j9Gg
Cc: Ole Troan , Pierre Pfister , "homenet@ietf.org" , Alexandru Petrescu 
Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 14:27:56 -0000

--Apple-Mail-6A913918-E646-40B8-95B0-EEA1AA9BAC08
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable





> On Oct 10, 2014, at 4:28 PM, Tim Chown  wrote:
>=20
>> On 10 Oct 2014, at 13:43, Townsley.net  wrote:
>>=20
>>>> On Oct 9, 2014, at 9:22 PM, Tim Chown  wrote:
>>>>=20
>>>> On 9 Oct 2014, at 12:03, Ole Troan  wrote:
>>>>=20
>>>> it doesn't make sense to specify something that breaks SLAAC.
>>>>=20
>>>> protocol design is politics. we want to make it clear to the address de=
legation authorities that not delegating a large enough address block will l=
ead to breakage.
>>>>=20
>>>> in my view, if we let this principle slide, then the risk isn't that th=
e delegations are /80s, but that they will be /128s. and you're back to IPv6=
 NAT anyhow.
>>>=20
>>> So - provocative question - should this draft be Experimental in status i=
nstead if it=E2=80=99s diving below /64 boundary?
>>=20
>> No. I think you are putting way too much weight on an informational docum=
ent here.
>=20
> Hmmm.. the draft says it=E2=80=99s intended status is Standards Track, not=
 Informational?  Just a typo?

I was referring to the why64 document.

- Mark=20

>=20
> Network Working Group                                         P. Pfister
> Internet-Draft                                               B. Paterson
> Intended status: Standards Track                           Cisco Systems
> Expires: March 23, 2015                                         J. Arkko
>                                                                 Ericsson
>                                                       September 19, 2014
>=20
> Tim

--Apple-Mail-6A913918-E646-40B8-95B0-EEA1AA9BAC08
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable






=
On Oct 10, 2014, at 4:28 PM, Tim Chown <tjc@ecs.soton.ac.uk> wrote:

On 10 Oct 2014, at 13:43, Townsl=
ey.net <mark@townsley.net>=
; wrote:

On Oct 9=
, 2014, at 9:22 PM, Tim Chown <tjc=
@ecs.soton.ac.uk> wrote:

On 9 Oct 20=
14, at 12:03, Ole Troan <otroan@e=
mployees.org> wrote:

it doesn't make sense to specify somethin=
g that breaks SLAAC.

protocol design is politics. we want to make it c=
lear to the address delegation authorities that not delegating a large enoug=
h address block will lead to breakage.

in my view, if we let this pri=
nciple slide, then the risk isn't that the delegations are /80s, but that th=
ey will be /128s. and you're back to IPv6 NAT anyhow.

So=
 - provocative question - should this draft be Experimental in status instea=
d if it=E2=80=99s diving below /64 boundary?

No. I think=
 you are putting way too much weight on an informational document here. 
=


Hmmm.. the draft says it=E2=80=99s intended stat=
us is Standards Track, not Informational?  Just a typo?

I was referring to the why64 document.

- Mark 

<=
br>
Network Working Group                            =
             P. Pfister
Internet-Draft                                               B. Paterson
Intended status: Standards Track                           Cisco Systems
Expires: March 23, 2015                                         J. Arkko
                                                                Ericsson
                                                      September 19, 2014

Tim
=

--Apple-Mail-6A913918-E646-40B8-95B0-EEA1AA9BAC08--


From nobody Thu Oct 16 07:51:12 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5147B1A1BE5 for ; Thu, 16 Oct 2014 07:51:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yy29tc7JuYi2 for ; Thu, 16 Oct 2014 07:51:06 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id D8A601A1BDD for ; Thu, 16 Oct 2014 07:51:06 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 64DD8238050E; Thu, 16 Oct 2014 10:51:05 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Thu, 16 Oct 2014 09:51:04 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>     <94C19398-AC5A-416F-8C3E-EA6B1750C22C@fugue.com> 
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/eHAOCEkwKJziY_ypa_J66wb0vM4
Cc: "homenet@ietf.org" , Michael Thomas 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 14:51:08 -0000

On Oct 16, 2014, at 9:18 AM, Lorenzo Colitti  wrote:
> So every time a new prefix comes in, hosts should restart DHCPv6? That =
seems pretty dubious (and expensive). I don't think any DHCP =
implementation works that way.=20

How do they work, then?   And why would you describe this as expensive?  =
 How often do new prefixes appear on your networks?


From nobody Thu Oct 16 09:40:17 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5DD1A004B for ; Thu, 16 Oct 2014 09:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.216
X-Spam-Level: 
X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rYXySezZ6Ko for ; Thu, 16 Oct 2014 09:40:13 -0700 (PDT)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9E61A004C for ; Thu, 16 Oct 2014 09:40:12 -0700 (PDT)
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id ce4ff345.2ae4b6e8a940.1332403.00-2413.3783269.nbfkord-smmo05.seg.att.com (envelope-from );  Thu, 16 Oct 2014 16:40:12 +0000 (UTC)
X-MXL-Hash: 543ff4ec14b69ef4-40c7720c7bec6b4ae2f9e4c0db8706564de75a07
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 8c4ff345.0.1332009.00-2252.3782118.nbfkord-smmo05.seg.att.com (envelope-from );  Thu, 16 Oct 2014 16:39:38 +0000 (UTC)
X-MXL-Hash: 543ff4ca738eddbd-fa3549e9a31d33b8dd1d80146b10208d023dfe5d
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9GGdale013387; Thu, 16 Oct 2014 12:39:36 -0400
Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9GGdPT7013217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Oct 2014 12:39:26 -0400
Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 16 Oct 2014 16:39:13 GMT
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.152]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 12:38:41 -0400
From: "STARK, BARBARA H" 
To: Ted Lemon , Lorenzo Colitti 
Thread-Topic: [homenet] Let's make in-home ULA presence a MUST !?
Thread-Index: AQHP54K2GqII5KZ8KUCnHFPeq3UJB5wvgUIAgABcm4CAAAw3AIAAA/SAgAAE6gD//8i16IAATh4AgAF83gCAAAhbgIAABAaAgAAK/oCAAAILAIAAFRCAgAAMRwCAAAZXgIAAEfyAgAAu6ACAAAJQgIAAAmWAgADtGgCAAAVLgIAAAqiAgAAGWoCAAACigIAAAL6AgAACIoCAAAkDAP//2QJg
Date: Thu, 16 Oct 2014 16:39:13 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>     <94C19398-AC5A-416F-8C3E-EA6B1750C22C@fugue.com>  <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com>
In-Reply-To: <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.44.85]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=MK7Xbrll c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=ofMgfj31e3cA:10 a=MkazQOY1ecYA:10 a=BLceEmwcHowA:10 a=kj9]
X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=1XWaLZrsA]
X-AnalysisOut: [AAA:8 a=fv22Sc-DCBGjbY_DeU0A:9 a=CjuIK1q_8ugA:10 a=UTB_XpH]
X-AnalysisOut: [je0EA:10 a=oo_GkSDWOFmZr6oc:21 a=HKX04-7EINzVHQtx:21]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.23]
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/dMZsLo3DT34CgNHmFlxFHC_RTEA
Cc: "homenet@ietf.org" , Michael Thomas 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 16:40:14 -0000

> On Oct 16, 2014, at 9:18 AM, Lorenzo Colitti  wrote:
> > So every time a new prefix comes in, hosts should restart DHCPv6? That
> seems pretty dubious (and expensive). I don't think any DHCP
> implementation works that way.
>=20
> How do they work, then?   And why would you describe this as expensive?
> How often do new prefixes appear on your networks?

[responding on homenet, since I don't think my response is about what shoul=
d or shouldn't be done to RFC 3315]

Many hosts don't even implement DHCPv6. It's totally optional (RFC 6434). E=
ven when implemented, it may be disabled. So relying on host DHCPv6 behavio=
r (of any sort) for proper homenet functioning, including proper address se=
lection, would be a bad idea, IMO. If DHCPv6 is *required* in any way in or=
der to implement address selection policy in a host, I think we're in troub=
le [no matter if something is or isn't done to RFC 3315 to make information=
 request behavior more predictable].=20

I think support for receiving more specific routes in RA messages (RFC 4191=
) would be easier to get hosts to implement than DHCPv6.

In any case, I think there needs to be a solution that *always* works in ho=
menet hosts.
Barbara


From nobody Thu Oct 16 10:37:21 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB8B1A19EF for ; Thu, 16 Oct 2014 10:37:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfedZu7AsPr2 for ; Thu, 16 Oct 2014 10:37:16 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9EF1A0636 for ; Thu, 16 Oct 2014 10:37:16 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 8BEF9238045C; Thu, 16 Oct 2014 13:37:14 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com>
Date: Thu, 16 Oct 2014 12:37:10 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>     <94C19398-AC5A-416F-8C3E-EA6B1750C22C@fugue.com>  <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com>
To: "STARK, BARBARA H" 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Hu1yGYZKTV1uWm3ijWsNTkFMcH4
Cc: "homenet@ietf.org" , Michael Thomas , Lorenzo Colitti 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 17:37:17 -0000

On Oct 16, 2014, at 11:39 AM, STARK, BARBARA H  wrote:
> I think support for receiving more specific routes in RA messages (RFC =
4191) would be easier to get hosts to implement than DHCPv6.

This wouldn't help, because there's nothing to differentiate the GUA =
from the ULA.

> In any case, I think there needs to be a solution that *always* works =
in homenet hosts.

As I mentioned earlier, the downside to not doing this is that if a site =
gets flash-renumbered, connections on the local network that might not =
have broken if a ULA were used will break.   This is a fairly mild =
problem.   Additionally, we talked about advertising ULAs in DNS on the =
local network, and GUAs externally, so even devices that don't do DHCPv6 =
would benefit from this.


From nobody Thu Oct 16 23:36:23 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0041A90E7 for ; Thu, 16 Oct 2014 23:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.394
X-Spam-Level: 
X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYBmJ4xhhoFO for ; Thu, 16 Oct 2014 23:36:20 -0700 (PDT)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D1D1A90E6 for ; Thu, 16 Oct 2014 23:36:20 -0700 (PDT)
Received: by mail-ig0-f176.google.com with SMTP id hn15so1029858igb.9 for ; Thu, 16 Oct 2014 23:36:19 -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; bh=leCDPt/3hwTCxM7gAh4NgZxFMewXapxw3Yo5Dxben8M=; b=eraDMLtUJFd1nYizaXWUSWLPkxwY2liHpTiElqawRQ5WXrk9CpnoGCTN8CPaN+cphS /+X4rcdM6hT+qj9ozy2B/Y0SDrn8EaYfFUiMTjTQ1pvBNdb6yUsEjVPmgGJRLI4xa0PI QeshyRbo10zCHeYes4fafZNl4EhtcH+QxmHnahMWwIruzmPGjmRJ07cozEBwBOBpNDwf C15i5mmEIBrmc6CnyTCrSdm9xmI6/mOhlE8sVszawpHZoHZ6ZoesAqFIQ45sSkCwhJee id8UR5CX2HckgD/wqyHnor3Z8M25+5nCJ2S+S576AvtNg50SFCWqwWuEFvYCX2zEGt8/ 5Ayg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=leCDPt/3hwTCxM7gAh4NgZxFMewXapxw3Yo5Dxben8M=; b=cShqyW39S8tat3XTKOTFrbyEP9NOuSp/4Da6Y/v4raeAZnvknhcvp90TMCgJR3IUtU Hu9o9ERpf7QzC0eWMTIaj9afOw7231Wtqw3As/Jpp1yfpdAo5abjeocRDU5oT5u11F8Q 1lQteD0AS4PhUSBSQltzd23KAy1IhrLNC79ufYQvh2k5VsFI1btKhe2MbM/qYTc82hT/ 2cbFp42fWh4ADVxOKQhWFfy878vQq9Sx6lzX1OfEVk/jQg9nHk9wYYA1HbWhcJR1gwiR qy7C+hFlFmjj5y7p3OH9U/MMUoNTADEXtnhnZ1KjZOsvRwkMJdgjdLnMiHB9csrbvdw4 F3YA==
X-Gm-Message-State: ALoCoQnqTxAIdL+M+XdL5JsAQP1Z5Xeb+eS8GfJZ9E7j7SExmPXsQjYkWz5EjSvPI6ChaE7KCz01
X-Received: by 10.42.167.1 with SMTP id q1mr8466301icy.48.1413527779676; Thu, 16 Oct 2014 23:36:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.8.242 with HTTP; Thu, 16 Oct 2014 23:35:59 -0700 (PDT)
In-Reply-To: <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>    <94C19398-AC5A-416F-8C3E-EA6B1750C22C@fugue.com>  <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>
From: Lorenzo Colitti 
Date: Fri, 17 Oct 2014 15:35:59 +0900
Message-ID: 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=90e6ba6e8ca430573d05059895aa
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/KkVO3WVMS-wQyvLXSxXYTUVQqD0
Cc: "homenet@ietf.org" , Michael Thomas , "STARK, BARBARA H" 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 06:36:21 -0000

--90e6ba6e8ca430573d05059895aa
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 17, 2014 at 2:37 AM, Ted Lemon  wrote:

> > In any case, I think there needs to be a solution that *always* works in
> homenet hosts.
>
> As I mentioned earlier, the downside to not doing this is that if a site
> gets flash-renumbered, connections on the local network that might not have
> broken if a ULA were used will break.


You keep mentioning this, but you're incorrect. Even if the ISP
flash-renumbers, hosts will not lower the lifetime of their IP addresses
below 2 hours, per RFC 4862.

--90e6ba6e8ca430573d05059895aa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On F=
ri, Oct 17, 2014 at 2:37 AM, Ted Lemon <mellon@fugue.com> wro=
te:
> In any case, I =
think there needs to be a solution that *always* works in homenet hosts.


As I mentioned earlier, the downside to not doing this is that if a =
site gets flash-renumbered, connections on the local network that might not=
 have broken if a ULA were used will break.

You keep mentioning this, but you're incorrect. Even if the ISP flash-=
renumbers, hosts will not lower the lifetime of their IP addresses below 2 =
hours, per RFC 4862.


--90e6ba6e8ca430573d05059895aa--


From nobody Thu Oct 16 23:45:27 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCBC1A90D6 for ; Thu, 16 Oct 2014 23:45:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.967
X-Spam-Level: 
X-Spam-Status: No, score=-2.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, PLING_QUERY=0.994, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5aHPS1qEqYW for ; Thu, 16 Oct 2014 23:45:25 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46701A90ED for ; Thu, 16 Oct 2014 23:45:24 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1A821A1; Fri, 17 Oct 2014 08:45:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1413528323; bh=jfCreuG9x+G/KMrvSjuDSac/JOCnYJGJsrcE2oVcNko=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=RnigJsP5/aX9G1h94seNITsfoHBwUVhzSN69rOUlzmKNZeRjxY3Hnc6MY8Xpodj2g sLpFgvZQT/ZISkJjMjaLby4cIgcc8oO5YJXgV1XhsNX/vCP8HimKqKsxnDLjALoyQM 6Q4xIBJ6onG4tPQ2U/kVCRoN11wa2Z015S/GWXC8=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 153C99F; Fri, 17 Oct 2014 08:45:23 +0200 (CEST)
Date: Fri, 17 Oct 2014 08:45:23 +0200 (CEST)
From: Mikael Abrahamsson 
To: Lorenzo Colitti 
In-Reply-To: 
Message-ID: 
References:  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>    <94C19398-AC5A-416F-8C3E-EA6B1750C22C@fugue.com>  <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com> 
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ilu8S-j8MlghNfomDYzpj5zOxeI
Cc: "homenet@ietf.org" , Ted Lemon 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 06:45:27 -0000

On Fri, 17 Oct 2014, Lorenzo Colitti wrote:

> You keep mentioning this, but you're incorrect. Even if the ISP 
> flash-renumbers, hosts will not lower the lifetime of their IP addresses 
> below 2 hours, per RFC 4862.

Where in RFC4862 is this described?

A lot of time was spent on RF7084 and its predecessor, making sure it was 
a requirement to send RAs with zero-lifetime for the on-link prefix if the 
delegated prefix went away, so hosts would stop using it very quickly.

So my expectation if the ISP flash-renumbered (ie reset the PPPoE session, 
the physical uplink went down or the DHCPv6-PD lease expired), an RFC7084 
compatible router would send out RAs with zero-lifetime and hosts would 
immediately stop using these IPs for new connections. Am I wrong, and 
where can I read up on the behaviour you're describing?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From SRS0=h9VX=7I=darou.fr=pierre.pfister@bounces.m4x.org  Thu Oct 16 23:52:21 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9751A9062 for ; Thu, 16 Oct 2014 23:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.208
X-Spam-Level: 
X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Es1H8PFStPrC for ; Thu, 16 Oct 2014 23:52:19 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499CD1A903C for ; Thu, 16 Oct 2014 23:52:19 -0700 (PDT)
Received: from ams3-vpn-dhcp4746.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 3C9DA1408EFA1; Fri, 17 Oct 2014 08:52:16 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Pierre Pfister 
In-Reply-To: 
Date: Fri, 17 Oct 2014 08:52:25 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <79AED438-4212-482A-8E74-B0FCEF13C2C9@darou.fr>
References:  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>    <94C19398-AC5A-416F-8C3E-EA6B1750C22C@fugue.com>  <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>  
To: Mikael Abrahamsson 
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Fri Oct 17 08:52:17 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/2SCCK-U6LN4klHbJZaqmg-i2kfE
Cc: "homenet@ietf.org" , Ted Lemon , Lorenzo Colitti 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 06:52:35 -0000

Hello Mikael,

Le 17 oct. 2014 =E0 08:45, Mikael Abrahamsson  a =E9crit=
 :

> On Fri, 17 Oct 2014, Lorenzo Colitti wrote:
>=20
>> You keep mentioning this, but you're incorrect. Even if the ISP =
flash-renumbers, hosts will not lower the lifetime of their IP addresses =
below 2 hours, per RFC 4862.
>=20
> Where in RFC4862 is this described?
>=20
> A lot of time was spent on RF7084 and its predecessor, making sure it =
was a requirement to send RAs with zero-lifetime for the on-link prefix =
if the delegated prefix went away, so hosts would stop using it very =
quickly.

There are two different things

If you loose WAN connectivity, you send RAs with router-lifetime set to =
zero. Meaning you are not a default route.  (RFC7084 - G-4)
If you loose a DP, you send RAs with PIO lifetimes set to =91prefered=92=3D=
0 and =91valid=92=3Dmin(DP lifetime, 2 hours).  (RFC7084 - L-13)

So the host can keep using the prefix during 2 hours. The preferred =
lifetime set to zero would of course suggest him to use a different one =
instead.

>=20
> So my expectation if the ISP flash-renumbered (ie reset the PPPoE =
session, the physical uplink went down or the DHCPv6-PD lease expired), =
an RFC7084 compatible router would send out RAs with zero-lifetime and =
hosts would immediately stop using these IPs for new connections. Am I =
wrong, and where can I read up on the behaviour you're describing?
>=20
> --=20
> Mikael Abrahamsson    email: swmike@swm.pp.se
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From nobody Thu Oct 16 23:53:38 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820C91A9062 for ; Thu, 16 Oct 2014 23:53:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.394
X-Spam-Level: 
X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGvS8XUSE4bb for ; Thu, 16 Oct 2014 23:53:36 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D50F1A899B for ; Thu, 16 Oct 2014 23:53:36 -0700 (PDT)
Received: by mail-ie0-f175.google.com with SMTP id x19so180118ier.6 for ; Thu, 16 Oct 2014 23:53:35 -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; bh=fDSuHnFIo+9HExi/WryKbTZizbqgamf+p4fqSEQy4z4=; b=Ne9SHAzAvkJ91hW5ps1uJgMor/pEL4os3y35BiYwRJAkTHTfqfOVrHUxJdO6YKw2ze vWjDCVIz11hAtT1a320o5yOWGPCkPhVoeXWn7hJKObmCuTt9nwtgzbqyIrPh9WKo3Q8u iooWFH5dF8JfGX7jei+1VRJqw4/39oXpHh7GuHvd5CLyws9fFUZR000Hhj4A5RomSS6+ 2jeQwHsOsdlBd1wZqHxfonIbrw6Dkj8lPlNsbRtZjw1keodhCkDscyMVeciFm/ooch3g FE9IIIgCGVV1Iz0OYyo+4LfURZK6In4JBqLvlh2wVFQYGuDj+HH5qM71bZNSedmH89iE Lksg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fDSuHnFIo+9HExi/WryKbTZizbqgamf+p4fqSEQy4z4=; b=G4tpj7ameh7UHnXebSntZZ/dDlcYDczWuqU+NYHUr5NpF4W0bDqT6ZdHJgo6Kkl1hV UhUG8Ub1WxvZn+vAisd56PPCKbzn5857Yo6VcN2WX6FQ8oZCtguzUVqVPMjwiNwIikHT GZGJvAEKk9IbuNmMBU8dmLbs38zFX4UjnX2e67OWgranHHD4H18uMnNL4pUG+JvPBPUy GMm1qtVgLlfHxRkfKuHgJzNnSyiv60OFEnO32fsNjtqmXr2xVc19+VFbBnuUlPN55lBp xC6UNHGDcgwiW7zqhgH0eg29HKQCPgJ8kR7xF9vm/TkxzmCVtgQJRajJJ5ixZfVySTev +eOw==
X-Gm-Message-State: ALoCoQnn6tjXoWEI/lQ4+cre17Iek4s69BMubujX7hjhR7GGy5e4WNAER8jzWV1m6Dhc5fiVmMAV
X-Received: by 10.50.60.97 with SMTP id g1mr720795igr.2.1413528815670; Thu, 16 Oct 2014 23:53:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.8.242 with HTTP; Thu, 16 Oct 2014 23:53:15 -0700 (PDT)
In-Reply-To: 
References:  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>    <94C19398-AC5A-416F-8C3E-EA6B1750C22C@fugue.com>  <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>  
From: Lorenzo Colitti 
Date: Fri, 17 Oct 2014 15:53:15 +0900
Message-ID: 
To: Mikael Abrahamsson 
Content-Type: multipart/alternative; boundary=047d7b10cea7f03bf3050598d203
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/8LmyC9WUowrDwYKgFxTnEtQItZ8
Cc: "homenet@ietf.org" , Ted Lemon 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 06:53:37 -0000

--047d7b10cea7f03bf3050598d203
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 17, 2014 at 3:45 PM, Mikael Abrahamsson 
wrote:

> You keep mentioning this, but you're incorrect. Even if the ISP
>> flash-renumbers, hosts will not lower the lifetime of their IP addresses
>> below 2 hours, per RFC 4862.
>>
>
> Where in RFC4862 is this described?
>

http://tools.ietf.org/html/rfc4862#section-5.5.3 point e).


>
> A lot of time was spent on RF7084 and its predecessor, making sure it was
> a requirement to send RAs with zero-lifetime for the on-link prefix if the
> delegated prefix went away, so hosts would stop using it very quickly.


> So my expectation if the ISP flash-renumbered (ie reset the PPPoE session,
> the physical uplink went down or the DHCPv6-PD lease expired), an RFC7084
> compatible router would send out RAs with zero-lifetime and hosts would
> immediately stop using these IPs for new connections. Am I wrong, and where
> can I read up on the behaviour you're describing?


Deprecated addresses can still be used until their valid lifetime expires.

--047d7b10cea7f03bf3050598d203
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On F=
ri, Oct 17, 2014 at 3:45 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
You keep=
 mentioning this, but you're incorrect. Even if the ISP flash-renumbers=
, hosts will not lower the lifetime of their IP addresses below 2 hours, pe=
r RFC 4862.





Where in RFC4862 is this described?

=C2=A0



A lot of time was spent on RF7084 and its predecessor, making sure it was a=
 requirement to send RAs with zero-lifetime for the on-link prefix if the d=
elegated prefix went away, so hosts would stop using it very quickly.=C2=A0=




So my expectation if the ISP flash-renumbered (ie reset the PPPoE session, =
the physical uplink went down or the DHCPv6-PD lease expired), an RFC7084 c=
ompatible router would send out RAs with zero-lifetime and hosts would imme=
diately stop using these IPs for new connections. Am I wrong, and where can=
 I read up on the behaviour you're describing?

Deprecated addresses can still be used until their valid lifetime e=
xpires.=C2=A0


--047d7b10cea7f03bf3050598d203--


From nobody Fri Oct 17 00:09:04 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFE01A90F4 for ; Fri, 17 Oct 2014 00:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.667
X-Spam-Level: 
X-Spam-Status: No, score=-0.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-2D1aS94fG6 for ; Fri, 17 Oct 2014 00:08:53 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCF3F1A90F3 for ; Fri, 17 Oct 2014 00:08:52 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id A5CDFA1; Fri, 17 Oct 2014 09:08:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1413529730; bh=O1IBANvnM4EbAwkQnAXgV5dcb/AFl2wOP86YROQlwk0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Poc+gm+zIipRAYtSecszWUT9pTtuD/NIazXBbQG2yCaZf+wVciYK6majqKQCrgTg2 12bgWXJXUEndCPRvAe2GD8P8kTXa+RhuYlnWWsUU+Q1M7SV2VBrlM0QV6Mvg9qfZE/ xUbR5xxFL5LQ93pD1Xmps+BOjAKtuAmehd1nnXCU=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 992F29F; Fri, 17 Oct 2014 09:08:50 +0200 (CEST)
Date: Fri, 17 Oct 2014 09:08:50 +0200 (CEST)
From: Mikael Abrahamsson 
To: Lorenzo Colitti 
In-Reply-To: 
Message-ID: 
References:   <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>    <94C19398-AC5A-416F-8C3E-EA6B1750C22C@fugue.com>  <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>   
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/7s_9_8AD4Ic0k6lza_uahXRzxS0
Cc: "homenet@ietf.org" , Ted Lemon 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 07:08:53 -0000

On Fri, 17 Oct 2014, Lorenzo Colitti wrote:

> Deprecated addresses can still be used until their valid lifetime 
> expires.

Ok, got it. It won't be used for new connections if there is something 
around with a non-zero preferred lifetime, but old ones within the home 
will still work. Check.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Fri Oct 17 05:24:17 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DDE1ACD33 for ; Fri, 17 Oct 2014 05:24:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.088
X-Spam-Level: *
X-Spam-Status: No, score=1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, PLING_QUERY=0.994, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PP-6xZCvaoeL for ; Fri, 17 Oct 2014 05:24:12 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08241ACD30 for ; Fri, 17 Oct 2014 05:24:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 2D25649; Fri, 17 Oct 2014 14:24:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1413548649; bh=d6l8t+5re5+tLjhxHLstNyci0FkWlKEykD7HMlBT1rA=; b=Q 64pV9NhxbMOVgceAYKjVOcWgtXpsSVqOwZQ5dATmhsUKUG1FHrQ01ZRpGSUn4VxU h+c5FPQAhMMwwE+DJmm8qsyXg44M+DLccqCDKo1WL9+ra9rN/nMrYRIuFhz6hYVs mwGxoJGZgoY5nrAavOPwNOh8CYGMi+OqkSGZxyKbT4=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sBB9vyGLLLaH; Fri, 17 Oct 2014 14:24:09 +0200 (CEST)
Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTPSA id E2EDB3F; Fri, 17 Oct 2014 14:24:08 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Sander Steffann 
In-Reply-To: 
Date: Fri, 17 Oct 2014 14:24:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7FCFE883-68CA-4140-A9C1-5A664A340ABB@steffann.nl>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <20141015232619.D687121808CE@rock.dv.isc.org> 
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/T3mwFuAzjWTl-0RhppaIsYFxl4g
Cc: "homenet@ietf.org" 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 12:24:14 -0000

Hi,

> Op 16 okt. 2014, om 15:22 heeft Lorenzo Colitti  =
het volgende geschreven:
>=20
> Per the table in http://tools.ietf.org/html/rfc6724#section-2.1 it =
will pick the GUA as a destination address, and per Rule 6, it will =
choose the GUA to connect to it.

Do you know if anything implements =
http://tools.ietf.org/html/rfc6724#section-10.6 (a site-specific policy =
entry for the local ULA prefix)?

Cheers,
Sander


From nobody Fri Oct 17 05:26:56 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8951B1ACD3D for ; Fri, 17 Oct 2014 05:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.906
X-Spam-Level: 
X-Spam-Status: No, score=-0.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eosjzXcJbU8L for ; Fri, 17 Oct 2014 05:26:54 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0148.outbound.protection.outlook.com [207.46.100.148]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E911ACD3F for ; Fri, 17 Oct 2014 05:26:53 -0700 (PDT)
Received: from BN1PR0201MB0676.namprd02.prod.outlook.com (25.160.169.152) by BN1PR0201MB0690.namprd02.prod.outlook.com (25.160.169.154) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Fri, 17 Oct 2014 12:26:52 +0000
Received: from BN1PR0201MB0674.namprd02.prod.outlook.com (25.160.169.150) by BN1PR0201MB0676.namprd02.prod.outlook.com (25.160.169.152) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Fri, 17 Oct 2014 12:26:51 +0000
Received: from BN1PR0201MB0674.namprd02.prod.outlook.com ([25.160.169.150]) by BN1PR0201MB0674.namprd02.prod.outlook.com ([25.160.169.150]) with mapi id 15.00.1054.004; Fri, 17 Oct 2014 12:26:51 +0000
From: Wuyts Carl 
To: Lorenzo Colitti , Ted Lemon 
Thread-Topic: [homenet] Let's make in-home ULA presence a MUST !?
Thread-Index: AQHP54K0vE/OjWpAb0mPoL0zPh7VxpwvPjQAgABcm4CAAAw3AIAAA/SAgAAE6gCAAAu7QYAACxgAgAF83QCAAAhcgIAABAaAgAAK/oCAAAILAIAAFRCAgAAMRwCAAAZXgIAAEfyAgAAu6ACAAAJQgIAAAmWAgADtGgCAAAVLgIAAAqeAgAAGWoCAAACjgIAAAL6AgAACIoCAAWmFkA==
Date: Fri, 17 Oct 2014 12:26:51 +0000
Message-ID: 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>     <94C19398-AC5A-416F-8C3E-EA6B1750C22C@fugue.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [95.172.74.68]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR0201MB0676;UriScan:;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 0367A50BB1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(377454003)(24454002)(189002)(93886004)(50986999)(4396001)(80022003)(85852003)(86362001)(92566001)(76576001)(15975445006)(19580395003)(16236675004)(85306004)(77096002)(54356999)(15202345003)(46102003)(108616004)(74316001)(87936001)(2656002)(76176999)(19580405001)(40100003)(19625215002)(101416001)(97736003)(95666004)(99286002)(122556002)(76482002)(99396003)(120916001)(33646002)(20776003)(21056001)(105586002)(106116001)(66066001)(31966008)(107046002)(19300405004)(64706001)(106356001)(276003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0201MB0676; H:BN1PR0201MB0674.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_ce786e8c245e4be4a5347af2efa728c3BN1PR0201MB0674namprd02_"
MIME-Version: 1.0
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR0201MB0690;
X-OriginatorOrg: technicolor.com
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/02znx-ITJj5MJ7GP3z5Pw_FHJDM
Cc: "homenet@ietf.org" , Michael Thomas 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 12:26:55 -0000

--_000_ce786e8c245e4be4a5347af2efa728c3BN1PR0201MB0674namprd02_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Q29ycmVjdC4NCg0KREhDUHY2IGhhcyBpdHMgb3duIHN0YXRlIG1hY2hpbmUsIHNvIEkgd291bGQg
c2F5LCB0YWtpbmcgaW50byBhY2NvdW50IHRoZSAyaHIgdmFsaWQgbGlmZXRpbWUgbWluaW11bSwg
dG8ganVzdCBtYWtlIHN1cmUgdG8gaGF2ZSBhIGxlYXNldGltZSBzaG9ydCBlbm91Z2ggdG8gY29w
ZSB3aXRoIHRoZXNlIGNoYW5nZXMgcmF0aGVyIHRoYW4gc3RhcnQgZW5mb3JjaW5nIHRoZSBnbHVl
aW5nIG9mIFJBIGFuZCBESENQdjYuDQpPSywgc2hvcnRlciBsZWFzZSB0aW1lIHdpbGwgaW50cm9k
dWNlIHNvbWUgbW9yZSB0cmFmZmljLCBidXQgaW1obywgbm90IHRoYXQgYmlnIG92ZXJoZWFkIGFu
ZCBvbmx5IGxvY2FsIHRyYWZmaWMNCg0KDQoNCkZyb206IGhvbWVuZXQgW21haWx0bzpob21lbmV0
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMb3JlbnpvIENvbGl0dGkNClNlbnQ6IGRv
bmRlcmRhZyAxNiBva3RvYmVyIDIwMTQgMTY6MTkNClRvOiBUZWQgTGVtb24NCkNjOiBob21lbmV0
QGlldGYub3JnOyBNaWNoYWVsIFRob21hcw0KU3ViamVjdDogUmU6IFtob21lbmV0XSBMZXQncyBt
YWtlIGluLWhvbWUgVUxBIHByZXNlbmNlIGEgTVVTVCAhPw0KDQpPbiBUaHUsIE9jdCAxNiwgMjAx
NCBhdCAxMToxMSBQTSwgVGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPG1haWx0bzptZWxsb25A
ZnVndWUuY29tPj4gd3JvdGU6DQpPbiBPY3QgMTYsIDIwMTQsIGF0IDk6MDggQU0sIExvcmVuem8g
Q29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPG1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20+PiB3
cm90ZToNCj4gVW0sIG5vPyBXaHkgd291bGQgaXQ/DQoNCkJlY2F1c2UgdGhhdCdzIGFuIGluZGlj
YXRpb24gdGhhdCB0aGVyZSBpcyBuZXcgaW5mb3JtYXRpb24gdG8gYmUgaGFkLg0KDQpTbyBldmVy
eSB0aW1lIGEgbmV3IHByZWZpeCBjb21lcyBpbiwgaG9zdHMgc2hvdWxkIHJlc3RhcnQgREhDUHY2
PyBUaGF0IHNlZW1zIHByZXR0eSBkdWJpb3VzIChhbmQgZXhwZW5zaXZlKS4gSSBkb24ndCB0aGlu
ayBhbnkgREhDUCBpbXBsZW1lbnRhdGlvbiB3b3JrcyB0aGF0IHdheS4NCg0K

--_000_ce786e8c245e4be4a5347af2efa728c3BN1PR0201MB0674namprd02_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg
NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh
bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCi8qIFN0eWxl
IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs
DQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w
cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw
YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K
CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu
a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4
dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw
b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBX
b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAu
ODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0
aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh
dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86
aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb
ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJOTC1CRSIgbGluaz0iYmx1ZSIgdmxpbms9
InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij5Db3JyZWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ESENQdjYgaGFz
IGl0cyBvd24gc3RhdGUgbWFjaGluZSwgc28gSSB3b3VsZCBzYXksIHRha2luZyBpbnRvIGFjY291
bnQgdGhlIDJociB2YWxpZCBsaWZldGltZSBtaW5pbXVtLCB0byBqdXN0IG1ha2Ugc3VyZSB0byBo
YXZlIGEgbGVhc2V0aW1lIHNob3J0DQogZW5vdWdoIHRvIGNvcGUgd2l0aCB0aGVzZSBjaGFuZ2Vz
IHJhdGhlciB0aGFuIHN0YXJ0IGVuZm9yY2luZyB0aGUgZ2x1ZWluZyBvZiBSQSBhbmQgREhDUHY2
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T0ssIHNob3J0ZXIg
bGVhc2UgdGltZSB3aWxsIGludHJvZHVjZSBzb21lIG1vcmUgdHJhZmZpYywgYnV0IGltaG8sIG5v
dCB0aGF0IGJpZyBvdmVyaGVhZCBhbmQgb25seSBsb2NhbCB0cmFmZmljPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t
Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gaG9t
ZW5ldCBbbWFpbHRvOmhvbWVuZXQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8
L2I+TG9yZW56byBDb2xpdHRpPGJyPg0KPGI+U2VudDo8L2I+IGRvbmRlcmRhZyAxNiBva3RvYmVy
IDIwMTQgMTY6MTk8YnI+DQo8Yj5Ubzo8L2I+IFRlZCBMZW1vbjxicj4NCjxiPkNjOjwvYj4gaG9t
ZW5ldEBpZXRmLm9yZzsgTWljaGFlbCBUaG9tYXM8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFto
b21lbmV0XSBMZXQncyBtYWtlIGluLWhvbWUgVUxBIHByZXNlbmNlIGEgTVVTVCAhPzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBPY3Qg
MTYsIDIwMTQgYXQgMTE6MTEgUE0sIFRlZCBMZW1vbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1lbGxv
bkBmdWd1ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tZWxsb25AZnVndWUuY29tPC9hPiZndDsgd3Jv
dGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBPY3QgMTYsIDIwMTQs
IGF0IDk6MDggQU0sIExvcmVuem8gQ29saXR0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxvcmVuem9A
Z29vZ2xlLmNvbSI+bG9yZW56b0Bnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBV
bSwgbm8/IFdoeSB3b3VsZCBpdD88YnI+DQo8YnI+DQpCZWNhdXNlIHRoYXQncyBhbiBpbmRpY2F0
aW9uIHRoYXQgdGhlcmUgaXMgbmV3IGluZm9ybWF0aW9uIHRvIGJlIGhhZC48bzpwPjwvbzpwPjwv
cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGV2ZXJ5IHRpbWUgYSBuZXcgcHJl
Zml4IGNvbWVzIGluLCBob3N0cyBzaG91bGQgcmVzdGFydCBESENQdjY/IFRoYXQgc2VlbXMgcHJl
dHR5IGR1YmlvdXMgKGFuZCBleHBlbnNpdmUpLiBJIGRvbid0IHRoaW5rIGFueSBESENQIGltcGxl
bWVudGF0aW9uIHdvcmtzIHRoYXQgd2F5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_ce786e8c245e4be4a5347af2efa728c3BN1PR0201MB0674namprd02_--


From nobody Fri Oct 17 06:29:34 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C5F1ACDC5 for ; Fri, 17 Oct 2014 06:29:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKc4Xe9fWpNU for ; Fri, 17 Oct 2014 06:29:31 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7E01ACDBD for ; Fri, 17 Oct 2014 06:29:31 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id C81DD238050E; Fri, 17 Oct 2014 09:29:29 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Fri, 17 Oct 2014 08:29:28 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>    <94C19398-AC5A-416F-8C3E-EA6B1750C22C@fugue.com>  <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com> 
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/DzSX2FwMKzCSoXQyC106_wHGOfE
Cc: "homenet@ietf.org" , Michael Thomas , "STARK, BARBARA H" 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 13:29:33 -0000

On Oct 17, 2014, at 1:35 AM, Lorenzo Colitti  wrote:
> You keep mentioning this, but you're incorrect. Even if the ISP =
flash-renumbers, hosts will not lower the lifetime of their IP addresses =
below 2 hours, per RFC 4862.

You are technically correct, and I will admit to having gone slightly =
into the weeds there, but let me remind you of how this conversation =
started: someone again proposed that we retain a stale GUA rather than =
having a ULA.   So if you go offline and then come back online, your =
stale GUA gets flash-renumbered even if your ISP doesn't have a policy =
of doing flash renumbering.   When I say it gets flash-renumbered, I =
mean that the ISP is no longer offering service on that GUA, regardless =
of whether hosts may still consider it valid.

Why do we care?   Because you are now advertising an invalid GUA on the =
homenet.   Hosts will think that they can use that GUA to communicate =
_off_ the homenet, and lossage will ensue.   Apps that do happy eyeballs =
will be less affected by this, but not all apps do happy eyeballs.   So =
when the upstream gets flash renumbered, you _really want_ to tell hosts =
on the local network that that prefix has a valid lifetime of zero, so =
that they don't mistakenly use it for communication off-homenet.

And then there's the long-lived connection _in_ the homenet.   If we =
insist on using non-stable GUAs, then my ssh connection to my home =
server, which I often do keep open overnight doing something, would be =
killed by the renumbering that has to happen when the upstream is =
renumbered and there is no stable ULA.   For those who still do X =
windows, any of their X window connections to hosts on the homenet would =
be dropped.

So this is why I am arguing that homenets SHOULD have ULAs, and why =
Markus is arguing that they MUST.   We really do want hosts to prefer =
the ULA if they can use it, and we really do want to always have a ULA.  =
 Hosts that are communicating on intra-homenet should not be using GUAs =
to do so, and it is worth a little effort to try to ensure that that is =
the case.


From nobody Fri Oct 17 06:48:06 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC6A1ACDDA for ; Fri, 17 Oct 2014 06:48:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.394
X-Spam-Level: 
X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fjgYRcGt_pw for ; Fri, 17 Oct 2014 06:48:02 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63B41ACDD9 for ; Fri, 17 Oct 2014 06:47:16 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id rp18so754008iec.21 for ; Fri, 17 Oct 2014 06:47:16 -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; bh=Y+5+Psy1E15x1tMggFRsjQxm9win1m4ZMAeTNw+ymnw=; b=cdpbJUtwt1nBlY5mI09zFbIH2+va4VBZ91w9tfJ0bkY5eanGzZRj5fLXHyrr+eB4Uo D5MG+H0eYfHe7V4lTGbdqMLrhkvgCDIc0VKAg56VmBY+tSC8/REg+rbMxspj468KX6vz Eqk7adVtiNogwqNbY7Wvs8ffW4Hl0B9xJzcziLr0GujmxXAPXTFZS18fegyl6xkNubVa KVikNtnpZRlkV8PuIh5Fhm5WvftaX3f4HGyuYKxv3M/eB/+qBR3MGdv1aOfcqtdnU3Vj ai0I229DxyGJEX8NxCPJrwYV1feD38E2VmWaocfnUDU0NPkSOSlbu36owG3OK+0t897/ f0cA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Y+5+Psy1E15x1tMggFRsjQxm9win1m4ZMAeTNw+ymnw=; b=Z/dmnZNQ7SkSxBsoZ6UiOotvRLp/PreOXqH4BR233kUAGqlUjlN72MhFChXXeCG2Z9 OxTpSohgSnxGMEmZfZkk9WHhI2x3R0Rij6rez13NYI2oMyJgBsGNhc3hq6ZYgDLhgwBr mFigmE3aCDPi0LJxa/TpWkktODxkgefQiSIqOpJrmuHzn3D7VCxGdEmQ+4Tf97qB4+pq XWDtjg3QwZCgnHdIfBePW258clAqWaZ1iTZRkdSkcKdBi8+zyDaYd07ZnGhFE6/MrtFT a9EIIVhg5cczVi/D/I0H5CRNHaAW7vE9GmGW3DzUGs47z6xa67JNgIaXcpcIFGueFR7g YaPg==
X-Gm-Message-State: ALoCoQm3RHQ2k3H0qhXSzOmcVLSMAgkBR+ujGWBTMJsRuBQ90uwG8ZwE2u9bx16FNtYtSHHaX/0S
X-Received: by 10.50.164.233 with SMTP id yt9mr12645235igb.2.1413553636020; Fri, 17 Oct 2014 06:47:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.8.242 with HTTP; Fri, 17 Oct 2014 06:46:55 -0700 (PDT)
In-Reply-To: <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>   <94C19398-AC5A-416F-8C3E-EA6B1750C22C@fugue.com>  <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>  <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com>
From: Lorenzo Colitti 
Date: Fri, 17 Oct 2014 22:46:55 +0900
Message-ID: 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=089e0149beac58e5b405059e9a65
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/G2nB6je9NyvYbaxFiDSnVyG85BQ
Cc: "homenet@ietf.org" , Michael Thomas , "STARK, BARBARA H" 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 13:48:04 -0000

--089e0149beac58e5b405059e9a65
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 17, 2014 at 10:29 PM, Ted Lemon  wrote:

> On Oct 17, 2014, at 1:35 AM, Lorenzo Colitti  wrote:
> > You keep mentioning this, but you're incorrect. Even if the ISP
> flash-renumbers, hosts will not lower the lifetime of their IP addresses
> below 2 hours, per RFC 4862.
>
> You are technically correct, and I will admit to having gone slightly into
> the weeds there, but let me remind you of how this conversation started:
> someone again proposed that we retain a stale GUA rather than having a
> ULA.   So if you go offline and then come back online, your stale GUA gets
> flash-renumbered even if your ISP doesn't have a policy of doing flash
> renumbering.   When I say it gets flash-renumbered, I mean that the ISP is
> no longer offering service on that GUA, regardless of whether hosts may
> still consider it valid.
>
> Why do we care?   Because you are now advertising an invalid GUA on the
> homenet.   Hosts will think that they can use that GUA to communicate _off_
> the homenet, and lossage will ensue.


No, they won't. The old GUA will be deprecated, and the hosts will not use
it if they have another GUA. If they don't have another GUA, they will
either use the deprecated GUA or the ULA, but it doesn't matter which they
use, because none of them will work anyway. Note that they *will* attempt
to use the ULA to talk to the outside world if they don't have a GUA, so
please don't come back saying "the hosts will know not to use it". :-)


> So when the upstream gets flash renumbered, you _really want_ to tell
> hosts on the local network that that prefix has a valid lifetime of zero,
> so that they don't mistakenly use it for communication off-homenet.
>

No, you don't want to tell them it has a valid lifetime of zero, you want
to tell them it has a preferred lifetime of zero. Which I think everyone
agrees with.


> And then there's the long-lived connection _in_ the homenet.   If we
> insist on using non-stable GUAs, then my ssh connection to my home server,
> which I often do keep open overnight doing something, would be killed by
> the renumbering that has to happen when the upstream is renumbered and
> there is no stable ULA.


Yes (but again, it won't be killed by the renumbering; it will be killed
*when its source address expires*). But I really doubt that real users have
long-lived connections from apps that don't reconnect on failure. Geeks
like us might, but that's not really who we should be designing for,
because geeks like us will know enough to pick an ISP that doesn't renumber
all the time.

Not all ISPs do constant renumbering. My prefix has been static for over
two years and it even followed me across an apartment move. And I just have
a standard residential service. US ISPs tend to renumber their users very
rarely (once every few weeks, at most).

So this is why I am arguing that homenets SHOULD have ULAs, and why Markus
> is arguing that they MUST.   We really do want hosts to prefer the ULA if
> they can use it, and we really do want to always have a ULA.   Hosts that
> are communicating on intra-homenet should not be using GUAs to do so, and
> it is worth a little effort to try to ensure that that is the case.
>

Oh, ULAs and stable addressing sound good on paper, sure. But as soon as
you actually try to use them, then suddenly there are a boatload of
scenarios that you need to deal with like the ones presented by James many
messages ago. What happens on splits? What happens on joins? Do you need to
keep old ULAs around? How many? Will implementations age them out? (I can
tell you the answer to that one: "no"; they're more likely to stop
accepting new ones than to have new ones replace old ones). And so on and
so forth.

I really don't think that it's worth accepting this complexity (and
brittleness, because home gateways are not the most well-tested or
frequently-upgraded of products) just for the sake of what is most likely a
minority of ISPs renumbering and breaking a tiny minority of users.

To my mind, ULAs are good for one thing, and one thing only: connectivity
when the network is bootstrapping or isolated and has no GUA. But using
them in that situation may well be an easier problem to solve.

--089e0149beac58e5b405059e9a65
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On F=
ri, Oct 17, 2014 at 10:29 PM, Ted Lemon <mellon@fugue.com> wr=
ote:
On Oct 17, 2014, at 1:35 AM, Lore=
nzo Colitti <lorenzo@google.com> wrote:

> You keep mentioning this, but you're incorrect. Even if the ISP fl=
ash-renumbers, hosts will not lower the lifetime of their IP addresses belo=
w 2 hours, per RFC 4862.



You are technically correct, and I will admit to having gone slightl=
y into the weeds there, but let me remind you of how this conversation star=
ted: someone again proposed that we retain a stale GUA rather than having a=
 ULA.=C2=A0 =C2=A0So if you go offline and then come back online, your stal=
e GUA gets flash-renumbered even if your ISP doesn't have a policy of d=
oing flash renumbering.=C2=A0 =C2=A0When I say it gets flash-renumbered, I =
mean that the ISP is no longer offering service on that GUA, regardless of =
whether hosts may still consider it valid.



Why do we care?=C2=A0 =C2=A0Because you are now advertising an invalid GUA =
on the homenet.=C2=A0 =C2=A0Hosts will think that they can use that GUA to =
communicate _off_ the homenet, and lossage will ensue.
So wh=
en the upstream gets flash renumbered, you _really want_ to tell hosts on t=
he local network that that prefix has a valid lifetime of zero, so that the=
y don't mistakenly use it for communication off-homenet.

No, you don't want to tell them it has a valid li=
fetime of zero, you want to tell them it has a preferred lifetime of zero. =
Which I think everyone agrees with.
=C2=A0
=
And then there's the long-lived connection _in_ the homenet.=C2=A0 =C2=
=A0If we insist on using non-stable GUAs, then my ssh connection to my home=
 server, which I often do keep open overnight doing something, would be kil=
led by the renumbering that has to happen when the upstream is renumbered a=
nd there is no stable ULA.

Yes (but again, =
it won't be killed by the renumbering; it will be killed *when its sour=
ce address expires*). But I really doubt that real users have long-lived co=
nnections from apps that don't reconnect on failure. Geeks like us migh=
t, but that's not really who we should be designing for, because geeks =
like us will know enough to pick an ISP that doesn't renumber all the t=
ime.

Not all ISPs do constant renumbering. My pref=
ix has been static for over two years and it even followed me across an apa=
rtment move. And I just have a standard residential service. US ISPs tend t=
o renumber their users very rarely (once every few weeks, at most).

So this is why I am arguing that homenets SHO=
ULD have ULAs, and why Markus is arguing that they MUST.=C2=A0 =C2=A0We rea=
lly do want hosts to prefer the ULA if they can use it, and we really do wa=
nt to always have a ULA.=C2=A0 =C2=A0Hosts that are communicating on intra-=
homenet should not be using GUAs to do so, and it is worth a little effort =
to try to ensure that that is the case.

Oh, ULAs and stable addressing sound good on paper, sure. But as soon as y=
ou actually try to use them, then suddenly there are a boatload of scenario=
s that you need to deal with like the ones presented by James many messages=
 ago. What happens on splits? What happens on joins? Do you need to keep ol=
d ULAs around? How many? Will implementations age them out? (I can tell you=
 the answer to that one: "no"; they're more likely to stop ac=
cepting new ones than to have new ones replace old ones). And so on and so =
forth.




--089e0149beac58e5b405059e9a65--


From nobody Fri Oct 17 07:18:05 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E5B1A0047 for ; Fri, 17 Oct 2014 07:18:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEn40FRf9i8t for ; Fri, 17 Oct 2014 07:18:02 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A5CA01A001A for ; Fri, 17 Oct 2014 07:18:02 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 1090623805E2; Fri, 17 Oct 2014 10:18:00 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Fri, 17 Oct 2014 09:17:59 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <8352C2EF-A888-4279-BFFF-37E204A0E2D3@fugue.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>   <94C19398-AC5A-416F-8C3E -EA6B1750C22C@fugue.com>  <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>  <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com> 
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/qr2eZM0vNWiAQYuVIXLDMQS-9kE
Cc: "homenet@ietf.org" , Michael Thomas , "STARK, BARBARA H" 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 14:18:03 -0000

On Oct 17, 2014, at 8:46 AM, Lorenzo Colitti  wrote:
> Yes (but again, it won't be killed by the renumbering; it will be =
killed *when its source address expires*). But I really doubt that real =
users have long-lived connections from apps that don't reconnect on =
failure. Geeks like us might, but that's not really who we should be =
designing for, because geeks like us will know enough to pick an ISP =
that doesn't renumber all the time.

I think that we should design our protocols to work independent of what =
prognostications we are able to make about what users might do today, =
rather than making decisions that will ensure that certain perfectly =
valid uses of the network will fail tomorrow.

> Not all ISPs do constant renumbering. My prefix has been static for =
over two years and it even followed me across an apartment move. And I =
just have a standard residential service. US ISPs tend to renumber their =
users very rarely (once every few weeks, at most).

This is true, but I at least have been renumbered by Comcast several =
times over the past six months, and I am not okay with connections on my =
local network failing when these renumbering events occur.   And we need =
to design for all uses cases, not just for your use case.

> Oh, ULAs and stable addressing sound good on paper, sure. But as soon =
as you actually try to use them, then suddenly there are a boatload of =
scenarios that you need to deal with like the ones presented by James =
many messages ago. What happens on splits? What happens on joins? Do you =
need to keep old ULAs around? How many? Will implementations age them =
out? (I can tell you the answer to that one: "no"; they're more likely =
to stop accepting new ones than to have new ones replace old ones). And =
so on and so forth.

You may have missed the message where I responded to James with concrete =
proposals for how to solve these problems.   It is entirely possible =
that if we explore that solution space we will conclude, as you have, =
that no solution is reliable and not brittle, but I don't think we have =
explored it, so I think your conclusion that we will not come up with a =
good solution is premature.


From nobody Fri Oct 17 07:50:31 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0091A01AA for ; Fri, 17 Oct 2014 07:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.394
X-Spam-Level: 
X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jo6aAw1ppfD9 for ; Fri, 17 Oct 2014 07:50:26 -0700 (PDT)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5321A0172 for ; Fri, 17 Oct 2014 07:50:26 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id rd18so886033iec.29 for ; Fri, 17 Oct 2014 07:50:25 -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; bh=orStnjVHfbgqFlBe7IhtIZSE6IIUr5ifqc1oGPCMdYg=; b=AbsiTRFm+XN3hl+2VoQKMiHt3v84ZTE1JYKY2qAph51+GPU227O7awsom7xb2rTdVU EGWlIkUyHniW3rRtwhVnOnKpT9uPGLFEfEVIOtlgf60MKih0ep/7tNEOsGl8f2FBHv2i TIQBZVzl3kBKl+x+Mdo82H2QBOfYGL+5vQQ1HoaOvhAE+UKo4Fw4oogJEcEjWyt7TLh6 ParGGW0XBDgnutiJNYUxBBL6V66zY7Kr9vfOmhRDCjh2MvIsARJ5019evS4vwDZBAUkO LbS9adt5CP6VXRcpSGd/EmDLzyGkmh4M0TU3pcOYv0tIdA5LIDawRGEYzffs7UhRtPKs vEEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=orStnjVHfbgqFlBe7IhtIZSE6IIUr5ifqc1oGPCMdYg=; b=Cwt9y+SO5tauot5O/IXeLv4KmBDz61T2q5sxv8v7xnx8d41wvZ4ZSwOtERZLiPdgvL 3E8IHfa5HNnNNAL1nZmFWfLxNhiyQc1lBF1dRsXo+aPEwZI2Kft16fbsXZHxHegpHJmM 6YYHD7OBky2IEuF1z9oOkbXQvV1OOcLmqwRdb575dbr78Bss3JWG76mPodLos6Wqj7Cg mrWcEyYEwfXdrdxL7tTi6adig/cIPHqN7e121pal0BmJB4LS4issil+SZY6P5Cg84tC4 JvJz3L8xACcJ/DyMduAdESbu86rwjLmPfuOKbYrbpTlKtJlCRHWBSEnCHq2yjz/c68hZ uMLg==
X-Gm-Message-State: ALoCoQkoKqukdH9K02VZYfCJLdbP7F40kWT57BJR71fIs+Mk7EAnr/uVHsYykeN/PNmXkM0T1Kjr
X-Received: by 10.42.25.204 with SMTP id b12mr10792499icc.14.1413557425773; Fri, 17 Oct 2014 07:50:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.8.242 with HTTP; Fri, 17 Oct 2014 07:50:05 -0700 (PDT)
In-Reply-To: <8352C2EF-A888-4279-BFFF-37E204A0E2D3@fugue.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>    <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>  <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com>  <8352C2EF-A888-4279-BFFF-37E204A0E2D3@fugue.com>
From: Lorenzo Colitti 
Date: Fri, 17 Oct 2014 23:50:05 +0900
Message-ID: 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=20cf303f6dfc3be32705059f7c14
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/1cfFTiNIAl5SxEWvuoEdnwHVgcQ
Cc: "homenet@ietf.org" , Michael Thomas , "STARK, BARBARA H" 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 14:50:28 -0000

--20cf303f6dfc3be32705059f7c14
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 17, 2014 at 11:17 PM, Ted Lemon  wrote:

> I think that we should design our protocols to work independent of what
> prognostications we are able to make about what users might do today,
> rather than making decisions that will ensure that certain perfectly valid
> uses of the network will fail tomorrow.
>

But you're saying you want ULAs because you want to continue to do what you
were doing yesterday: persistent connections, like SSH and X-windows. I
think you're trying to fix the problem at the wrong layer. But I don't
expect we'll agree with me on that.

--20cf303f6dfc3be32705059f7c14
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On F=
ri, Oct 17, 2014 at 11:17 PM, Ted Lemon <mellon@fugue.com> wr=
ote:
I think that we should design our pr=
otocols to work independent of what prognostications we are able to make ab=
out what users might do today, rather than making decisions that will ensur=
e that certain perfectly valid uses of the network will fail tomorrow.
<=
/blockquote>

But you're saying you want ULAs because=
 you want to continue to do what you were doing yesterday: persistent conne=
ctions, like SSH and X-windows. I think you're trying to fix the proble=
m at the wrong layer. But I don't expect we'll agree with me on tha=
t.


--20cf303f6dfc3be32705059f7c14--


From nobody Fri Oct 17 08:30:31 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3ED11A1B55 for ; Fri, 17 Oct 2014 08:30:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiUAfk6sHlpy for ; Fri, 17 Oct 2014 08:30:25 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 629451A1B4A for ; Fri, 17 Oct 2014 08:30:25 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 6B10C238050E; Fri, 17 Oct 2014 11:30:24 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Fri, 17 Oct 2014 10:30:20 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>    <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>  <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com>  <8352C2EF-A888-4279-BFFF-37E204A0E2D3@fugue.com> 
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/PPlb68UIRRZlr9MakZMSARxP2Mo
Cc: "homenet@ietf.org" , Michael Thomas , "STARK, BARBARA H" 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 15:30:27 -0000

On Oct 17, 2014, at 9:50 AM, Lorenzo Colitti  wrote:
> But you're saying you want ULAs because you want to continue to do =
what you were doing yesterday: persistent connections, like SSH and =
X-windows. I think you're trying to fix the problem at the wrong layer. =
But I don't expect we'll agree with me on that.

The current IP architecture effectively assumes that this gets fixed on =
layer 3.   I agree that this is a problem, but since we don't have a =
real layer 4 solution, I think it's worth making sure that we make =
things as stable as we can at layer 3.   This does not preclude working =
on a solution at layer 4.   Indeed, there are several people here who =
think that's important; perhaps you should put your heads together.   =
Nothing gets done until someone does it.   But beware: several ships =
have foundered against these rocks already.


From nobody Fri Oct 17 08:45:49 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E83B1A1B7D for ; Fri, 17 Oct 2014 08:45:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.907
X-Spam-Level: 
X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIQpnp0smfTH for ; Fri, 17 Oct 2014 08:45:45 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E81601A1B7C for ; Fri, 17 Oct 2014 08:45:44 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DABCB20028 for ; Fri, 17 Oct 2014 11:46:20 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id A7DF563A80; Fri, 17 Oct 2014 11:45:43 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 93C5D63A1F for ; Fri, 17 Oct 2014 11:45:43 -0400 (EDT)
From: Michael Richardson 
To: "homenet\@ietf.org" 
In-Reply-To: <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>    <94C19398-AC5A-416F-8C3E-EA6B1750C22C@fugue.com>  <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>  <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/uW4QpvFtACeppf_CcgAfnPV7sQI
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 15:45:46 -0000

--=-=-=


Ted Lemon  wrote:
    > So this is why I am arguing that homenets SHOULD have ULAs, and why
    > Markus is arguing that they MUST.  We really do want hosts to prefer
    > the ULA if they can use it, and we really do want to always have a ULA.
    > Hosts that are communicating on intra-homenet should not be using GUAs
    > to do so, and it is worth a little effort to try to ensure that that is
    > the case.

Again, 7084 says ULAs are a SHOULD (I remembered a MUST).

In my mind, the kind of reason for a CPE device *NOT* to offer a ULA is because
the administrator typed in their own (provider independant) GUA over the ULA.

I.e. one of the 8 people in this conversation (perhaps the world) who
*actually* has their own allocation that they use in their home.. (not via a tunnel)
{my swap /24 is no longer at my home, and despite LRSA'ing it, I can't get my
own /40 from ARIN unless I'm willing to cough up $1250/year}

Perhaps there are other scenarios where the CPE needs to support turning off
the ULA generation and advertisement, but other than that, I read that SHOULD
as being pretty much a "MUST"

This is why I think the discussion is moot.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBVEE5p4CLcPvd0N1lAQJ0lAf/am0YBcF96sn/p+8qLEZNgdI9OWnOsFyF
dQyN7i94NAA61nEswK+8JFL3DJPGNUvkSbs56fBu1z8EST5cWNsgthHZLZT/bCve
2Zsd/k38RWoFhnSYnIayzQDUdxT558IkCbztv/v57M40pMmvAvCC8E4ALdj1Mpnm
dK5pqOUra9HhkQOVtQ0gADrmzVWZQAfPJyAr6gmCCHso+veq+kctcVN2H1/PhMvT
4HkPD8CodTCBzoKuuzIapo330yLc0s59WUz90H4gJgcKPiptg5cXtApnBX9a0916
A8Lsqy3zE40hyOIgMz98SaPj+5v0mOwbdJZbMdLHCEBjAFSQGKqmpw==
=fdn0
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Fri Oct 17 08:51:36 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6701A1BA5 for ; Fri, 17 Oct 2014 08:51:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUadhxNCix2o for ; Fri, 17 Oct 2014 08:51:26 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 905D91A1BA3 for ; Fri, 17 Oct 2014 08:51:26 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 79D80238050E; Fri, 17 Oct 2014 11:51:25 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <3626.1413560743@sandelman.ca>
Date: Fri, 17 Oct 2014 10:51:22 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>    <94C19398-AC5A-416F-8C3E-EA6B1750C22C@fugue.com>  <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>  <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com> <3626.1413560743@sandelman.ca>
To: Michael Richardson 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/dSlpcWepmJj9hhGKF5PBP9JJ7aM
Cc: "homenet@ietf.org" 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 15:51:27 -0000

On Oct 17, 2014, at 10:45 AM, Michael Richardson  =
wrote:
> In my mind, the kind of reason for a CPE device *NOT* to offer a ULA =
is because
> the administrator typed in their own (provider independant) GUA over =
the ULA.

Good point.


From nobody Fri Oct 17 08:54:39 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A531A1B86 for ; Fri, 17 Oct 2014 08:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.907
X-Spam-Level: 
X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUd76mezibc2 for ; Fri, 17 Oct 2014 08:54:36 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612AB1A1B80 for ; Fri, 17 Oct 2014 08:54:36 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CF2BB20028; Fri, 17 Oct 2014 11:55:12 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 995AB63A80; Fri, 17 Oct 2014 11:54:35 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8094B63A1F; Fri, 17 Oct 2014 11:54:35 -0400 (EDT)
From: Michael Richardson 
To: Lorenzo Colitti 
In-Reply-To: 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>    <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>  <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com>  <8352C2EF-A888-4279-BFFF-37E204A0E2D3@fugue.com> 
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/7IveQCv8zHFmE6QkkxNZY2EJaVQ
Cc: "homenet@ietf.org" , Michael Thomas , Ted Lemon , "STARK, BARBARA H" 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 15:54:37 -0000

--=-=-=


Lorenzo Colitti  wrote:
    >> I think that we should design our protocols to work independent of
    >> what prognostications we are able to make about what users might do
    >> today, rather than making decisions that will ensure that certain
    >> perfectly valid uses of the network will fail tomorrow.

    > But you're saying you want ULAs because you want to continue to do what
    > you were doing yesterday: persistent connections, like SSH and
    > X-windows. I think you're trying to fix the problem at the wrong
    > layer. But I don't expect we'll agree with me on that.

It's not about whether or not SSH and X-windows can reconnect or not.

It's that, even if they try, the target host has been given a new address,
and there are long-lived credentials which have been tied to the name
and the address.  We did this in the days when we didn't have mDNS, and
we couldn't trust that well DNS, and putting the IPv6 address (the ULA),
of that ssh-enabled powered bar into my /etc/hosts (or .ssh/config or
registry, or shell script) seems like an entirely sensible thing to do.

I will go back and read James' message about joins and splits.
It seems that we have this problem with GUAs as well, and it seems that
the whole address selection issue exists without ULAs, as long as one has
multiple ISPs.

And LLNs will be installed with ULAs, and in some cases, we might really
want to route that into the homenet, so ULAs show up even if CPE devices
don't create them.

{BTW: I've never been a fan of ULA-Random, and I really really would like
to fine some way to make non-routable IPv6 globally unique addresses, that
include reverse DNS and whois, available for a low enough price that nobody
has to think twice about getting them.  But, in this case for the home of the
unsophisticated user, ULA-Random, seems correct}


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBVEE7u4CLcPvd0N1lAQJJCQf+OqjTXW2bBZXKdrV3zRj4AfkTzP7jOXuV
3IE+ZkuTbRSJQRp9z0ZLmDUU+pyPmqjehWaKT4+34TMgULXlWH2rvWeN/MpZ9SHP
PgWXSMRlm5YbUpjdJaZw3PTVur0DZx1CkQpnWh7LIyz7evHDYL5II6jgX52VGe4C
nhPdJkju3FfxYGgvpUXyEftQw9+EiFY0IciaJ/7Hoq3Pi3ml4zFqpMkqEJeRxhUe
ayGzjcJ5Y0Y03hYYp7bJIN+CgIq4QJYgAnok6tzgon3HHu0sZoG5vZno6fzl90LO
/o+eQ41e/KDNwvy1+7Ztsx+ZlMwQfO7UWwU+f5ABY5q/XHnA6Fe74g==
=HixS
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Fri Oct 17 09:03:23 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60711A1A52 for ; Fri, 17 Oct 2014 09:03:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2VmlpLIp1n5 for ; Fri, 17 Oct 2014 09:03:21 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7321A1B70 for ; Fri, 17 Oct 2014 09:03:21 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id B9E1C238050E; Fri, 17 Oct 2014 12:03:19 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <8532.1413561275@sandelman.ca>
Date: Fri, 17 Oct 2014 11:03:16 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <99F5F70B-C81A-489A-B271-9C6A6AA94FC5@fugue.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>    <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>  <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com>  <8352C2EF-A888-4279-BFFF-37E204A0E2D3@fugue.com>  <8532.1413561275@sandelman.ca>
To: Michael Richardson 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/TSUFZd4cZnvXKxoAGXCoVXoD8T8
Cc: "homenet@ietf.org" , Michael Thomas , "STARK, BARBARA H" , Lorenzo Colitti 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 16:03:22 -0000

On Oct 17, 2014, at 10:54 AM, Michael Richardson  =
wrote:
> I will go back and read James' message about joins and splits.
> It seems that we have this problem with GUAs as well, and it seems =
that
> the whole address selection issue exists without ULAs, as long as one =
has
> multiple ISPs.

The issue with joins and splits is that you would like your numbering to =
survive a temporary network partition, but to not survive a permanent =
network partition.   I think this problem is solvable, and have some =
ideas about how to do it, which are half-baked and probably won't work =
without tweaking.

E.g., when a homenet chooses a ULA, it could divide the /64s evenly =
between all of the participating homenet routers.   If there's a =
partition, the homenet routers get to keep the /64s they got to begin =
with, but if after some period of time (TBD) the partition hasn't =
healed, one of them (chosen back when the network wasn't partitioned) =
begins a transition to a new randomly-chosen ULA.   If new routers are =
added to a homenet, HNCP should be able to balance out the pool of free =
/64s so that every router has some to keep during a partition.

If two homenets each with their own ULA are joined, one of the ULAs is =
deprecated with a long tail.   It would also be worth factoring =
power-cycling into this: if a homenet router that had a ULA is powered =
off, then powered back on, connected to a new homenet, its ULA is =
probably the one that should be deprecated.   This will still fail in =
the case that there are devices that are still using the prefix, but I =
think we're now down in the really unlikely scenarios that we don't have =
to solve.


From nobody Fri Oct 17 09:13:51 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832D71A1BB0 for ; Fri, 17 Oct 2014 09:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.506
X-Spam-Level: *
X-Spam-Status: No, score=1.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=2.511, PLING_QUERY=0.994, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTFoAzN2wplz for ; Fri, 17 Oct 2014 09:13:39 -0700 (PDT)
Received: from nm15-vm4.access.bullet.mail.gq1.yahoo.com (nm15-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.103]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00BB81A1BBE for ; Fri, 17 Oct 2014 09:13:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1413562417; bh=EeAdXPh8/nsRMivRIPNgcpBQ883I349OlswkCeQvAjo=; h=Date:Subject:From:To:CC:References:In-Reply-To:From:Subject; b=yH7fYjtuqImtNSByOV1rvPfpPJYXnnSzoxpw1KPVSdP6+O9UwL+2a4ik9t4E6W9S3NJgCuH2/eCQ6YIQbPbRQ4HNfW+gU+r9Z5T4BUDVePzF3e1f0t0DT7/5OYDGmZBY6nea9dHEl4GCs0NC8jGqmfsbb05561jlB6yXhAmrG/k=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=att.net; b=4QL1wXX/HTewWqhz4p8u98/VyLky6Z8cyzMwzoS+6U/yVx6Sq1XW9RfuEwtxB2BT12ILNSXdOtLTLoVXMNmaCanLRCt0CIHSuVuqyy+RVAHRuO2AHuzP3+5tJyNwT64HiFuoFildarBGRh+p/Kw4vUlNlGVcBLFApZL3w3D+T0A=;
Received: from [216.39.60.176] by nm15.access.bullet.mail.gq1.yahoo.com with NNFMP; 17 Oct 2014 16:13:37 -0000
Received: from [98.138.226.244] by tm12.access.bullet.mail.gq1.yahoo.com with NNFMP; 17 Oct 2014 16:13:37 -0000
Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 17 Oct 2014 16:13:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1413562417; bh=EeAdXPh8/nsRMivRIPNgcpBQ883I349OlswkCeQvAjo=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:References:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=VwC/Zln2/qrXSjSaPImH1KvkhMX87I8n8tyVqhwa8h3QGFFM2T6/dLMBesHxPISXFz9fNRlbAHa2zPxVyt2lv6oJHhU3quVTILTKzfFUwa2lp3MyJmksgwuZIBKS5pRqJvXNNMj+n2znLf+Ao+CPFo3W2OsByX9oLglbebXo71w=
X-Yahoo-Newman-Id: 273354.47950.bm@smtp115.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: LaGVJskVM1m2lMdRbmijIPEZ5tKUd7TXrYSQeri1kms1oMk qM1AQn6qRCuG.jm4BBD3NOAIEb0ZLbP633UH6R.QqfjEI4Bx3sCzyFr_BFLN PyMnM5RhvzcMukimS.dnMT4_MAzjT.UvtxnekvYUa0NNUzsT0KDk2neagivi fBSjowpRLKIpR9wFhp7cX7trK.yGWA8rO.cPGjegkkz0m4sgnMAll9NolYwh UPElQWhXLASvdyML88Jbd7vfnfPSEUUdBNo2agcnKtpkMIi7BlLBPsvIK_5j UDY0Fko9iEftpblE8HjBPoHzE5_Ez.F4ACoEh5fslqz7d5rwPo2.L_x4wYpm RvP7qDFF3uqWsCCAf6DWrPwxoGM1nJSIDP.x5RX3f8ooknS8IexOb5SQKegd Y.RNk1XVMltephkfHHlCXgcQPZ2j1c1siKGbKcLRTjO7CfqiIQTJPQk1e0Ln 1Q2u3NDDIr7cYDpRP0_CmubO.QTGFRhT440Ihfg1C3CKhkSQeZwizyUgzEnO oHbM59swtNmE7h99ob_T9kXmRJ3uO67VU4ZBjfW8K
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
User-Agent: Microsoft-MacOutlook/14.4.5.141003
Date: Fri, 17 Oct 2014 09:10:51 -0700
From: Don Sturek 
To: Ted Lemon , Michael Richardson 
Message-ID: 
Thread-Topic: [homenet] Let's make in-home ULA presence a MUST !?
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>   <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>  <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com>  <8352C2EF-A888-4279-BFFF-37E204A0E2D3@fugue.com>  <8532.1413561275@sandelman.ca> <99F5F70B-C81A-489A-B271-9C6A6AA94FC5@fugue.com>
In-Reply-To: <99F5F70B-C81A-489A-B271-9C6A6AA94FC5@fugue.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/QAv9fKAWarTxE9qrj4I18X0Lyv0
Cc: "homenet@ietf.org" , Michael Thomas , "STARK, BARBARA H" , Lorenzo Colitti 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 16:13:41 -0000

Hi Ted and Michael,

What this home network join/split topic with respect to ULA's is a draft
that targets becoming at least Informational.

I think several of these e-mails have hit on the problem, I don't see any
existing I-D's or RFCs that solve the problem.

Don


On 10/17/14 9:03 AM, "Ted Lemon"  wrote:

>On Oct 17, 2014, at 10:54 AM, Michael Richardson 
>wrote:
>> I will go back and read James' message about joins and splits.
>> It seems that we have this problem with GUAs as well, and it seems that
>> the whole address selection issue exists without ULAs, as long as one
>>has
>> multiple ISPs.
>
>The issue with joins and splits is that you would like your numbering to
>survive a temporary network partition, but to not survive a permanent
>network partition.   I think this problem is solvable, and have some
>ideas about how to do it, which are half-baked and probably won't work
>without tweaking.
>
>E.g., when a homenet chooses a ULA, it could divide the /64s evenly
>between all of the participating homenet routers.   If there's a
>partition, the homenet routers get to keep the /64s they got to begin
>with, but if after some period of time (TBD) the partition hasn't healed,
>one of them (chosen back when the network wasn't partitioned) begins a
>transition to a new randomly-chosen ULA.   If new routers are added to a
>homenet, HNCP should be able to balance out the pool of free /64s so that
>every router has some to keep during a partition.
>
>If two homenets each with their own ULA are joined, one of the ULAs is
>deprecated with a long tail.   It would also be worth factoring
>power-cycling into this: if a homenet router that had a ULA is powered
>off, then powered back on, connected to a new homenet, its ULA is
>probably the one that should be deprecated.   This will still fail in the
>case that there are devices that are still using the prefix, but I think
>we're now down in the really unlikely scenarios that we don't have to
>solve.
>
>_______________________________________________
>homenet mailing list
>homenet@ietf.org
>https://www.ietf.org/mailman/listinfo/homenet



From nobody Fri Oct 17 12:49:17 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A61F1A6FC5 for ; Fri, 17 Oct 2014 12:49:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.984
X-Spam-Level: 
X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuHVeYGvbAdf for ; Fri, 17 Oct 2014 12:49:14 -0700 (PDT)
Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F4A1A6FC4 for ; Fri, 17 Oct 2014 12:49:13 -0700 (PDT)
Received: by mail-vc0-f178.google.com with SMTP id hq12so1152310vcb.9 for ; Fri, 17 Oct 2014 12:49:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=o6nDty8QO3Ju17o333FGC/tTOPuqIY+X6I5Of/SVFXQ=; b=exluVdbvvcc+Vrg8RdbDw9TcYDhAZpTSRfx18za9zEq8AtvrSLBbCjlymITR2YFP9n VTFsoo4ACyCuqCWRTaOOFN/7KSY7NxrMfWDuqcqBRwckIGaRhFLeidZZQ89+XsIB4lPt 08KjccDVy6/75S1fPJ8iob4e5UvAqJiep39YWBMPUsUkFVx95cp6uVxhGndrxrGMBdWM 5gACx0jAmyLPIFdrpRU6zQv6BNpmIr28Jl//1IsGjHRDDK9lX7IuIGTaO5dOsf3boACO Lu65hxIVhIUJxmM4PFBiYF7SmEYkRRj0HJwtdyrxygq1KF8okKGNubs4fpx5CXY47IIl pQ3A==
X-Gm-Message-State: ALoCoQkw9QU6MJkp5eacYOuuhbUgF7o7i8bjK1/L33egb/JNjOiJd30EQD8NNjJ7RVVONh0blNX+
MIME-Version: 1.0
X-Received: by 10.221.68.199 with SMTP id xz7mr9169512vcb.7.1413575352901; Fri, 17 Oct 2014 12:49:12 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Fri, 17 Oct 2014 12:49:12 -0700 (PDT)
In-Reply-To: <8352C2EF-A888-4279-BFFF-37E204A0E2D3@fugue.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>    <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>  <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com>  <8352C2EF-A888-4279-BFFF-37E204A0E2D3@fugue.com>
Date: Fri, 17 Oct 2014 12:49:12 -0700
Message-ID: 
From: James Woodyatt 
To: HOMENET Working Group 
Content-Type: multipart/alternative; boundary=001a11339ffac5fe450505a3a8b3
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/e0m2jAkWeu-YVZD_SvqUWKpp4To
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 19:49:16 -0000

--001a11339ffac5fe450505a3a8b3
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 17, 2014 at 7:17 AM, Ted Lemon  wrote:

> On Oct 17, 2014, at 8:46 AM, Lorenzo Colitti  wrote:
>
> > Oh, ULAs and stable addressing sound good on paper, sure. But as soon as
> you actually try to use them, then suddenly there are a boatload of
> scenarios that you need to deal with like the ones presented by James many
> messages ago. What happens on splits? What happens on joins? Do you need to
> keep old ULAs around? How many? Will implementations age them out? (I can
> tell you the answer to that one: "no"; they're more likely to stop
> accepting new ones than to have new ones replace old ones). And so on and
> so forth.
>
> You may have missed the message where I responded to James with concrete
> proposals for how to solve these problems.   It is entirely possible that
> if we explore that solution space we will conclude, as you have, that no
> solution is reliable and not brittle, but I don't think we have explored
> it, so I think your conclusion that we will not come up with a good
> solution is premature.
>

As I recall, the proposals in your response were less than concrete and
didn't solve the problems. In particular, I remain curious about how to
expire the locally generated ULA prefixes that accumulate over repeated
network joins and splits.  I remember explaining how those events could be
rather more frequent than people might be assuming, and that's where the
discourse seemed to stop.


-- 
james woodyatt 
Nest Labs, Communications Engineering

--001a11339ffac5fe450505a3a8b3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On F=
ri, Oct 17, 2014 at 7:17 AM, Ted Lemon <mellon@fugue.com> wro=
te:
On Oct 17, 2014, at =
8:46 AM, Lorenzo Colitti <lorenzo@=
google.com> wrote:


> Oh, ULAs and stable addressing sound good on paper, sure. But as soon =
as you actually try to use them, then suddenly there are a boatload of scen=
arios that you need to deal with like the ones presented by James many mess=
ages ago. What happens on splits? What happens on joins? Do you need to kee=
p old ULAs around? How many? Will implementations age them out? (I can tell=
 you the answer to that one: "no"; they're more likely to sto=
p accepting new ones than to have new ones replace old ones). And so on and=
 so forth.



You may have missed the message where I responded to James with conc=
rete proposals for how to solve these problems.=C2=A0 =C2=A0It is entirely =
possible that if we explore that solution space we will conclude, as you ha=
ve, that no solution is reliable and not brittle, but I don't think we =
have explored it, so I think your conclusion that we will not come up with =
a good solution is premature.



As I recall, the proposals in your respons=
e were less than concrete and didn't solve the problems. In particular,=
 I remain curious about how to expire the locally generated ULA prefixes th=
at accumulate over repeated network joins and splits.=C2=A0 I remember expl=
aining how those events could be rather more frequent than people might be =
assuming, and that's where the discourse seemed to stop.


-- 
james woodyatt <=
;jhw@nestlabs.com=
>
Nest Labs, Communications Engineering




--001a11339ffac5fe450505a3a8b3--


From nobody Fri Oct 17 12:55:06 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDE91A6FCB for ; Fri, 17 Oct 2014 12:55:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DebWwJToyR-l for ; Fri, 17 Oct 2014 12:55:04 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id B66E11A6FC4 for ; Fri, 17 Oct 2014 12:55:04 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id BE42D238050E; Fri, 17 Oct 2014 15:55:03 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Fri, 17 Oct 2014 14:54:56 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <41E2A52A-C689-49A4-A480-DB9C3624E618@fugue.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>    <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>  <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com>  <8352C2EF-A888-4279-BFFF-37E204A0E2D3@fugue.com> 
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/HZ7NacQnlV7AxYebCyDTVjDcGQM
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 19:55:05 -0000

On Oct 17, 2014, at 2:49 PM, James Woodyatt  wrote:
> As I recall, the proposals in your response were less than concrete =
and didn't solve the problems. In particular, I remain curious about how =
to expire the locally generated ULA prefixes that accumulate over =
repeated network joins and splits.  I remember explaining how those =
events could be rather more frequent than people might be assuming, and =
that's where the discourse seemed to stop.

If you don't burn a ULA prefix every time you split and rejoin, then I =
don't see why there would be any kind of significant growth in prefixes. =
  That's why I suggested the algorithm that I suggested.


From nobody Fri Oct 17 12:57:05 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3AD1A6FB5 for ; Fri, 17 Oct 2014 12:57:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.508
X-Spam-Level: *
X-Spam-Status: No, score=1.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=2.511, MIME_QP_LONG_LINE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uLHLmQy_ssm for ; Fri, 17 Oct 2014 12:57:01 -0700 (PDT)
Received: from nm15-vm7.access.bullet.mail.gq1.yahoo.com (nm15-vm7.access.bullet.mail.gq1.yahoo.com [216.39.63.193]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482301A6F9C for ; Fri, 17 Oct 2014 12:57:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1413575821; bh=8pY4D45/WD2XfwSTRUThziI420qynxUiRi9QDPywv+Y=; h=Date:Subject:From:To:References:In-Reply-To:From:Subject; b=WFt7PxMsYjCPljj9f3yJLT0gnmgT8RlMLzWo1Qs5ihYFXwXd5eVH6ShsqmW9qW604OpYQGz29XRQ/HUeL87e617D6wFZ/pwGhoBbg7n1YHEJ/F3Qj9IHtTbgUYfq4Ro6JR9jPX/wEa7OMdgNbUYFqtB3eIYSKohZtHfQqrgVNjo=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=att.net; b=HFK8N9ZypzzjKzAVOO0Ynl2HSuYVHhokbY6QmJtIXjWa0R3CRdU8okHh5Eg9+u7FAeE5FnyngZVzwkcOkPtKxUjW38AtcyT6i/zUBnnI6Y4NCOsvReDYT0Y6XzBXwbR25JrOSrGA0LyNQTXJhlL0na5TWTMGIqfjDVsPTZVH8P0=;
Received: from [216.39.60.166] by nm15.access.bullet.mail.gq1.yahoo.com with NNFMP; 17 Oct 2014 19:57:01 -0000
Received: from [98.138.104.96] by tm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 17 Oct 2014 19:57:00 -0000
Received: from [127.0.0.1] by smtp116.sbc.mail.ne1.yahoo.com with NNFMP; 17 Oct 2014 19:57:00 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1413575820; bh=8pY4D45/WD2XfwSTRUThziI420qynxUiRi9QDPywv+Y=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To:Mime-version:Content-type; b=0GAOLshPEvpxOwzWBSR5G/v3yizJHqgy7tXVSQI3PpQRF2QqcCQFvWP2HHMflaJi9BnS75K4TEnEZa+86tz1rlMWjuFnU2qk8NoC6MTAhGnDknkEVFbEgXo8MCMh164k3pp8eFWfZZkIOYzO7AZ4QR1PrPmNaNQ1SaGosDMUS9U=
X-Yahoo-Newman-Id: 741776.45022.bm@smtp116.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 7Tyfy.sVM1lLnyfi.SeJpFK53sjvbg4i4KXC75tGkDyVTrY ZEJ1xO7ZW7Rrh7DIofS5blfvghCMaUpobVBPKCYwK9MfFtqc8xorrZ9vZ_NF C.lEY64Dd048l6FYCQg0ZzwOxq.zOcQ0bj3SEZLp2t4IIkItGrMzVhdcQIff V9OEHDUIX4gCZ.H3HJD9xVYRrw0uGf5m3KevHYEOUqcLkxjNCfY6cctmkeg5 mdjh1AOL0rJGPjhHs1YugAcOo6exEx0fhpmllsHEgguJYYTk9tKPX2cO2HFQ 9.Uy6d1lPJnyppGI5dX7bL5ZPC3ThG_IyawWBpcWuAedSPg_PX5kErzsb.BM Qdulue.gw7A67kApBsJspApzjikXtbqHzCcfEO8RiJFDB4P6.M5FFKT2ddNJ RMKULBlxF8r3Don3Iklh2YLJu9F0s71tEyxCX4x_lI1ITF6R22UAKpzWPmOA Tl0Hvo98296AtmRkdvdeJZ8p4lMqtJfCZXes6nUXeSJL7r5bEn8KOsDk0pKC 8AH_xMQnlerHD0djsFTzlLSv7RqilNcqZOFqk6jBW
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
User-Agent: Microsoft-MacOutlook/14.4.5.141003
Date: Fri, 17 Oct 2014 12:56:56 -0700
From: Don Sturek 
To: James Woodyatt , HOMENET Working Group 
Message-ID: 
Thread-Topic: [homenet] Let's make in-home ULA presence a MUST !?
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>    <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>  <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com>  <8352C2EF-A888-4279-BFFF-37E204A0E2D3@fugue.com> 
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3496395419_1479581"
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/jNSvwIV_Wi7I9rC-JOSTxr_jfWs
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 19:57:03 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3496395419_1479581
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hi James,

One more issue that maybe needs some consideration:    How would a router
know the boundary for dissemination of ULA prefixes?  Here I am thinking of
the case where there may be more than one ISP interface and particularly in
the case of network splits and joins in the home.

So really I think there are a couple of different topics ripe for I-Ds:
1)  How to handle splits/joins of networks in the home where different ULA
prefixes are in use
2)  Guidance on when (and when not) to propagate ULA prefixes.  I think I
have heard anecdotally that most ISP see traffic using ULAs on their ISP
interface (which they drop).  It would be nice to have a definitive draft
that clearly states when this traffic should not be routed (so at least
dilligent implementers can attempt to do the right thing).  Again, I think
this topic is fairly obvious in a home with a single ISP and all devices are
connected from day 1 but it is less than clear when merging two or more
networks in your home (or attempting to split the networks)

Don


From:  James Woodyatt 
Date:  Friday, October 17, 2014 12:49 PM
To:  HOMENET Working Group 
Subject:  Re: [homenet] Let's make in-home ULA presence a MUST !?

On Fri, Oct 17, 2014 at 7:17 AM, Ted Lemon  wrote:
> On Oct 17, 2014, at 8:46 AM, Lorenzo Colitti  wrote:
> 
>> > Oh, ULAs and stable addressing sound good on paper, sure. But as soon as
>> you actually try to use them, then suddenly there are a boatload of scenarios
>> that you need to deal with like the ones presented by James many messages
>> ago. What happens on splits? What happens on joins? Do you need to keep old
>> ULAs around? How many? Will implementations age them out? (I can tell you the
>> answer to that one: "no"; they're more likely to stop accepting new ones than
>> to have new ones replace old ones). And so on and so forth.
> 
> You may have missed the message where I responded to James with concrete
> proposals for how to solve these problems.   It is entirely possible that if
> we explore that solution space we will conclude, as you have, that no solution
> is reliable and not brittle, but I don't think we have explored it, so I think
> your conclusion that we will not come up with a good solution is premature.

As I recall, the proposals in your response were less than concrete and
didn't solve the problems. In particular, I remain curious about how to
expire the locally generated ULA prefixes that accumulate over repeated
network joins and splits.  I remember explaining how those events could be
rather more frequent than people might be assuming, and that's where the
discourse seemed to stop.


-- 
james woodyatt 
Nest Labs, Communications Engineering
_______________________________________________ homenet mailing list
homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet


--B_3496395419_1479581
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable


Hi James,

One more issue that maybe needs some consideration:    Ho=
w would a router know the boundary for dissemination of ULA prefixes?  =
Here I am thinking of the case where there may be more than one ISP interfac=
e and particularly in the case of network splits and joins in the home.

So really I think there are a couple of different topic=
s ripe for I-Ds:
1)  How to handle splits/joins of networks i=
n the home where different ULA prefixes are in use
2)  Guidan=
ce on when (and when not) to propagate ULA prefixes.  I think I have he=
ard anecdotally that most ISP see traffic using ULAs on their ISP interface =
(which they drop).  It would be nice to have a definitive draft that cl=
early states when this traffic should not be routed (so at least dilligent i=
mplementers can attempt to do the right thing).  Again, I think this to=
pic is fairly obvious in a home with a single ISP and all devices are connec=
ted from day 1 but it is less than clear when merging two or more networks i=
n your home (or attempting to split the networks)

D=
on


From:  James Woodyatt <jhw@nestlabs.com>
Date:  Friday, October 17, 20=
14 12:49 PM
To:  HOMENET Working Gr=
oup <homenet@ietf.org>
Subject:  Re: [homenet] Let's make in-home U=
LA presence a MUST !?

On Fri, Oct 17, 2014 at 7:17 AM, Ted Lemo=
n <mell=
on@fugue.com> wrote:
On Oct 17, 2014, at 8:46 AM, Lorenzo Colitti <lorenzo@google.com> wrote:


> Oh, ULAs and stable addressing sound good on paper, sure. But as soon =
as you actually try to use them, then suddenly there are a boatload of scena=
rios that you need to deal with like the ones presented by James many messag=
es ago. What happens on splits? What happens on joins? Do you need to keep o=
ld ULAs around? How many? Will implementations age them out? (I can tell you=
 the answer to that one: "no"; they're more likely to stop accepting new one=
s than to have new ones replace old ones). And so on and so forth.

You may have missed the message where I responded to James with concret=
e proposals for how to solve these problems.   It is entirely poss=
ible that if we explore that solution space we will conclude, as you have, t=
hat no solution is reliable and not brittle, but I don't think we have explo=
red it, so I think your conclusion that we will not come up with a good solu=
tion is premature.

As I recall, the proposals i=
n your response were less than concrete and didn't solve the problems. In pa=
rticular, I remain curious about how to expire the locally generated ULA pre=
fixes that accumulate over repeated network joins and splits.  I rememb=
er explaining how those events could be rather more frequent than people mig=
ht be assuming, and that's where the discourse seemed to stop.


-- 
james woodyatt <jhw@nestlabs.com>
=
Nest Labs, Communications Engineering

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.or=
g/mailman/listinfo/homenet


--B_3496395419_1479581--



From nobody Fri Oct 17 12:59:50 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EF01A6FB0 for ; Fri, 17 Oct 2014 12:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnVqF5DKt-7H for ; Fri, 17 Oct 2014 12:59:48 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A26DD1A01FA for ; Fri, 17 Oct 2014 12:59:48 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id E8BF8238050E; Fri, 17 Oct 2014 15:59:47 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Fri, 17 Oct 2014 14:59:41 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <417E68B0-02BB-4074-98DF-0358DB57E669@fugue.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>    <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>  <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com>  <8352C2EF-A888-4279-BFFF-37E204A0E2D3@fugue.com>  
To: Don Sturek 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ZF6udI-ukDZFz89Ibw9IF_XkEXU
Cc: HOMENET Working Group , James Woodyatt 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 19:59:49 -0000

On Oct 17, 2014, at 2:56 PM, Don Sturek  wrote:
>  How would a router know the boundary for dissemination of ULA =
prefixes?

Isn't that the same boundary as the homenet boundary?   I think we =
already solve that problem.


From nobody Fri Oct 17 13:08:29 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B441A1BA0 for ; Fri, 17 Oct 2014 13:08:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.506
X-Spam-Level: *
X-Spam-Status: No, score=1.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=2.511, PLING_QUERY=0.994, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIQMOG9z-HDl for ; Fri, 17 Oct 2014 13:08:22 -0700 (PDT)
Received: from nm22-vm1.access.bullet.mail.gq1.yahoo.com (nm22-vm1.access.bullet.mail.gq1.yahoo.com [216.39.63.20]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C961A00BB for ; Fri, 17 Oct 2014 13:08:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1413576502; bh=4dIyTEi+Xj/+1k5P3efw2wItZgFTo8AuSCqTeTXBZKY=; h=Date:Subject:From:To:CC:References:In-Reply-To:From:Subject; b=L+aCw7BlShnZG4TPlapVVaqIYBUjAkSceWB0d6AoKU9yJ0/2Z0y57UoBDjxK4dD46NZXtVlHEkbXtQCr+jGjBFx1Uo9v+eQ83TQ4dlS60zCfpDj9yHm4CY9WqlhyIqmx3n9tunRfBLAz9mZc92Zj85qy1oUepWECY9iPUkR0K/8=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=att.net; b=afYKVEWGMJpyedUqxVzTWXIA1V7iB6UVIZtwq1zz6zZmCSjCn+6oKRi9vq9d9H+V4/RZVAg8msU8fbstx/aSkNlPmIdCi5ijXDFgqmZTkhYwDzIyQbLfd/GAlwQ31of/gWj4CTvUXwNl1xZB5QZlN4JM5VK1lMMhSc/LiSlHLpM=;
Received: from [216.39.60.173] by nm22.access.bullet.mail.gq1.yahoo.com with NNFMP; 17 Oct 2014 20:08:22 -0000
Received: from [98.138.226.240] by tm9.access.bullet.mail.gq1.yahoo.com with NNFMP; 17 Oct 2014 20:08:21 -0000
Received: from [127.0.0.1] by smtp111.sbc.mail.ne1.yahoo.com with NNFMP; 17 Oct 2014 20:08:21 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1413576501; bh=4dIyTEi+Xj/+1k5P3efw2wItZgFTo8AuSCqTeTXBZKY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:References:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=4dMAEabWPqZPxcXckm9ri99YSdHK3gZ2y5lRkEuke8jmVvs6DTBicu+GbZ81df5D4IwZFkKGFs4i0iQmPxM3vxO2vhfKnRXsKxw2S4o5x6QjuLktIUgrlY9ZSUx94lKuSOGiCtJS/xzzjFQH9PVK9FKThwxlIu//8XU3PnirRv8=
X-Yahoo-Newman-Id: 703259.83650.bm@smtp111.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: m5.f9PQVM1lmL13VrZ_Os31LWlFIaUnh63ibn1LMZp2286m 4risTPcH0uemLcgBBEm3kBWyAvXsJw8AaI.0j6Rw.4V7LsX_z6trzPBA.J2H U10fhEBM3e1eUih87wTmeoeEVyXf.LMsineFjb5jobZ54KstAN._nX3SAnGo 0Xt29ttlP0n5MEEpSRvPqMR9aWqIpf6NaiFqybNh3gnEyERWjJ5AamQWWWDv KpWhQvDs7MLJTJkKbEyotphgcnzBWKb2GLqFIG6SRMOUIWwcy1x1jUfK9UzU Mmumo.wb2WtqgDfC2KktardyM0xJGHJkfOrUFHrr9Do2kpdMw4Ab5siguOpw 4DdDJYW9b3wZ3svIfa9X9D72glOZ.XSCmyZYZZp8wDWeBGJq9gjmFEins8ge vGLdkMjA.Z8mCxOh3p_o_tbAPqt2mImBNYslTnnu8QgA_ucN96XfJG9ICub_ eI0u.OHYTSX6yVyZQ8enpiwUP1sh73TlINQ01kOHn76UnWFucqfTGBQ6gsRp PrX7tudc2JcJjbiRNXXGeTp7tTTJzbuPhbj5Sc6QG
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
User-Agent: Microsoft-MacOutlook/14.4.5.141003
Date: Fri, 17 Oct 2014 13:08:17 -0700
From: Don Sturek 
To: Ted Lemon 
Message-ID: 
Thread-Topic: [homenet] Let's make in-home ULA presence a MUST !?
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>   <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>  <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com>  <8352C2EF-A888-4279-BFFF-37E204A0E2D3@fugue.com>   <417E68B0-02BB-4074-98DF-0358DB57E669@fugue.com>
In-Reply-To: <417E68B0-02BB-4074-98DF-0358DB57E669@fugue.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/24nBsru1qidTCVz-u7CJulONbiA
Cc: HOMENET Working Group , James Woodyatt 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 20:08:25 -0000

Hi Ted,

Here is the scenario that I am thinking might not be covered:
1)  Router A (say your internet service provider) has an ISP interface
with prefix 2001:: then has a ULA prefix for devices it is currently
communicating with
2)  Router B (in the same home connected via cellular) has a different ISP
interface with prefix 2002:: and also has a different ULA prefix for a
colleciton of devices it communicates with
3)  Router A is now connected to Router B via an interface in the home
(the join case).  Obviously, one of them needs to be the owner of *the*
ULA prefix in the home and the other should stop providing its prefix.

Same scenario for the split:
1)   I have two networks that were joined with Router A and Router B
linked.  I decide to island one of my networks (for example, I have a
lighting system using Router B but discovered there has been a security
breach and I don't want it exposed to the internet through Router A).
2)   Is it clear in terms of ULA prefix generation/propagation what Router
A and Router B should be doing regarding forwarding prefix information on
their internal (and by reference external interfaces)?

Maybe this would be covered by the splits/joins topic but it does seem
like ULA propagation changes in addition to the renumbering of the devices
in the home using ULA prefixes.

Don


On 10/17/14 12:59 PM, "Ted Lemon"  wrote:

>On Oct 17, 2014, at 2:56 PM, Don Sturek  wrote:
>>  How would a router know the boundary for dissemination of ULA prefixes?
>
>Isn't that the same boundary as the homenet boundary?   I think we
>already solve that problem.
>
>_______________________________________________
>homenet mailing list
>homenet@ietf.org
>https://www.ietf.org/mailman/listinfo/homenet



From nobody Fri Oct 17 13:17:18 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EB41A00CD for ; Fri, 17 Oct 2014 13:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnFXbhtg7B4s for ; Fri, 17 Oct 2014 13:17:15 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id C31971A00A6 for ; Fri, 17 Oct 2014 13:17:15 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 9F4B7238050E; Fri, 17 Oct 2014 16:17:14 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Fri, 17 Oct 2014 15:17:07 -0500
Content-Transfer-Encoding: 7bit
Message-Id: 
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>   <4D6F2B13-D63E-4FEE-A136 -B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>  <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com>  <8352C2EF-A888-4279-BFFF-37E204A0E2D3@fugue.com>   <417E68B0-02BB-4074-98DF-0358DB57E669@fugue.com> 
To: Don Sturek 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/pT1g9V2dvHSO_pPklvmCvc8wTjQ
Cc: HOMENET Working Group , James Woodyatt 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 20:17:16 -0000

On Oct 17, 2014, at 3:08 PM, Don Sturek  wrote:
> Maybe this would be covered by the splits/joins topic but it does seem
> like ULA propagation changes in addition to the renumbering of the devices
> in the home using ULA prefixes.

I already covered both of those scenarios in a previous message.


From nobody Fri Oct 17 14:41:32 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E0C1A86DE for ; Fri, 17 Oct 2014 14:41:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.984
X-Spam-Level: 
X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEMayPVkbQIK for ; Fri, 17 Oct 2014 14:41:29 -0700 (PDT)
Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EAD81A702A for ; Fri, 17 Oct 2014 14:41:29 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id id10so1254367vcb.34 for ; Fri, 17 Oct 2014 14:41:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=zw41ho1vEo3VCYdU+1cABOyDCgQO9oPHssvGvI4k0gE=; b=g7BTgpLx15o2LzG+afSdkuQDB5UyfF8dKjv5TAjU3dPK5SnNfo4vpTdn7VewMpyrd2 qTLHP+OfZkxzr2j3GOrZU9kDXwOI5/z7Kb4XA9oOpEi7ELiCphRXAVWCdBfp94RohejH HIVmL+m8/FwbM0SSIvRh82Y8t6a1JH9/QzRvqGsg6Bxrc0VWYKRe4Z4d/z2SSvacGDX8 YuELXbnAZs8sTKE0f6N0n8ZP2V57dFc2LXzNlmUGfEddH49H9fNQnmW7Li5vKOvjkAUs LykW6ve0fkvvVM0tB0LteNq9vKGrK3pR4tnXefMS9JtQPxpQkAWz9mfwri8qyq7hykQx DKgw==
X-Gm-Message-State: ALoCoQkNc0BaCzu1L65zOPrHo2whnknSmyfQhCJRY5av6F+ZC21D+9FYWWNnc+D/NFD620ahvRDG
MIME-Version: 1.0
X-Received: by 10.52.145.136 with SMTP id su8mr8044290vdb.8.1413582088218; Fri, 17 Oct 2014 14:41:28 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Fri, 17 Oct 2014 14:41:28 -0700 (PDT)
In-Reply-To: <41E2A52A-C689-49A4-A480-DB9C3624E618@fugue.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>   <4D6F2B13-D63E-4FEE-A136-B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>  <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com>  <8352C2EF-A888-4279-BFFF-37E204A0E2D3@fugue.com>  <41E2A52A-C689-49A4-A480-DB9C3624E618@fugue.com>
Date: Fri, 17 Oct 2014 14:41:28 -0700
Message-ID: 
From: James Woodyatt 
To: HOMENET Working Group 
Content-Type: multipart/alternative; boundary=bcaec52d571d3ac0d30505a53a85
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/WIfjp7lYrdhu-yazUHN44gq8AsU
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 21:41:30 -0000

--bcaec52d571d3ac0d30505a53a85
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 17, 2014 at 12:54 PM, Ted Lemon  wrote:

> On Oct 17, 2014, at 2:49 PM, James Woodyatt  wrote:
> > As I recall, the proposals in your response were less than concrete and
> didn't solve the problems. In particular, I remain curious about how to
> expire the locally generated ULA prefixes that accumulate over repeated
> network joins and splits.  I remember explaining how those events could be
> rather more frequent than people might be assuming, and that's where the
> discourse seemed to stop.
>
> If you don't burn a ULA prefix every time you split and rejoin, then I
> don't see why there would be any kind of significant growth in prefixes.
>  That's why I suggested the algorithm that I suggested.
>

I explained why you must generate a new ULA prefix every time you
commission a new network.

It's true that not every split entails commissioning a new network,
especially when the AAA service for the previously commissioned network is
still available on both sides of the split, but that isn't always true, and
besides, human user behavior must still be accounted. Whenever you have AAA
service, you are attempting to automate what humans think about who is and
who isn't allowed to do what. Sometimes people change their plans.
Sometimes people don't plan at all. Sometimes people make plans and don't
tell anyone, much less the silicon beasties in their house. Sometimes they
make plans without even recognizing it. Routers have to operate mostly in
the dark when a split happens. They may not be able to determine whether
they are still expected to be members of the previously commissioned
network or if they have been repurposed into a new network until well after
they have been operating split for some time, and perhaps joined with other
networks in the meantime. After a split, they may need to operate in a mode
that allows them to commission a new standalone network at any time when
they are split from a previously commissioned network.

In any case, we have defined a way for locally generated ULA prefixes
distributed in persistent storage of HOMENET interior routers to accumulate
without limit when independently commissioned networks join. Offering the
view that sensible people don't commission new networks very frequently is
not a solution to the problem. It's a way of implying the problem isn't
relevant to your interests. The problem may not be relevant to your
interests, but it is to mine.


-- 
james woodyatt 
Nest Labs, Communications Engineering

--bcaec52d571d3ac0d30505a53a85
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Oct 17, 2014 at 12:54 PM, Ted Lemon <mellon@fugue.com> wrote:
On Oct 17, =
2014, at 2:49 PM, James Woodyatt <jh=
w@nestlabs.com> wrote:

> As I recall, the proposals in your response were less than concrete an=
d didn't solve the problems. In particular, I remain curious about how =
to expire the locally generated ULA prefixes that accumulate over repeated =
network joins and splits.=C2=A0 I remember explaining how those events coul=
d be rather more frequent than people might be assuming, and that's whe=
re the discourse seemed to stop.



If you don't burn a ULA prefix every time you split and rejoin, =
then I don't see why there would be any kind of significant growth in p=
refixes.=C2=A0 =C2=A0That's why I suggested the algorithm that I sugges=
ted.



I explained why you must generate a new ULA prefix every time you c=
ommission a new network.

It's true that not every split entails commissioning=
 a new network, especially when the AAA service for the previously commissi=
oned network is still available on both sides of the split, but that isn=
9;t always true, and besides, human user behavior must still be accounted. =
Whenever you have AAA service, you are attempting to automate what humans t=
hink about who is and who isn't allowed to do what. Sometimes people ch=
ange their plans. Sometimes people don't plan at all. Sometimes people =
make plans and don't tell anyone, much less the silicon beasties in the=
ir house. Sometimes they make plans without even recognizing it. Routers ha=
ve to operate mostly in the dark when a split happens. They may not be able=
 to determine whether they are still expected to be members of the previous=
ly commissioned network or if they have been repurposed into a new network =
until well after they have been operating split for some time, and perhaps =
joined with other networks in the meantime. After a split, they may need to=
 operate in a mode that allows them to commission a new standalone network =
at any time when they are split from a previously commissioned network.

In any ca=
se, we have defined a way for locally generated ULA prefixes distributed in=
 persistent storage of HOMENET interior routers to accumulate without limit=
 when independently commissioned networks join. Offering the view that sens=
ible people don't commission new networks very frequently is not a solu=
tion to the problem. It's a way of implying the problem isn't relev=
ant to your interests. The problem may not be relevant to your interests, b=
ut it is to mine.


-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engineering




--bcaec52d571d3ac0d30505a53a85--


From nobody Fri Oct 17 14:46:41 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72931A86F2 for ; Fri, 17 Oct 2014 14:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHVq8w2UadTq for ; Fri, 17 Oct 2014 14:46:39 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB511A86EF for ; Fri, 17 Oct 2014 14:46:39 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 46E9623802B7; Fri, 17 Oct 2014 17:46:37 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Fri, 17 Oct 2014 16:46:36 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <0AF5E505-3D12-4E4C-8DD8-91B326D02EB8@fugue.com>
References:   <20141014142746.GX31092@Space.Net> <69B1F2CB-88C6-4211-83F3-11C8A3E7BFD2@fugue.com> <20141014145930.GY31092@Space.Net>  <20141014154111.GZ31092@Space.Net>  <20141015150422.GW31092@Space.Net> <4E2E154E-D231-4E79-860A-56948A13CDD4@fugue.com> <20141015154841.GY31092@Space.Net>  <543EA248.2080700@mtcc.com>  <543EBE40.3030201@mtcc.com>  <543ED2A7.3090409@mtcc.com> <1569644A-50C4-47B6-908E-262BC62BCD14@fugue.com> <543EFBF1.6040101@mtcc.com> <457D177C-232E-4590-A9ED-80048140157F@fugue.com>   <4D6F2B13-D63E-4FEE-A136 -B510126CC1C9@fugue.com> <2D09D61DDFA73D4C884805CC7865E61130EA3B9A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1AA5DBBD-C3C5-4AFD-A043-6A69AE7FBDB9@fugue.com>  <3F36952F-CF6A-4F21-A713-A8A7DE7BDC42@fugue.com>  <8352C2EF-A888-4279-BFFF-37E204A0E2D3@fugue.com>  <41E2A52A-C689-49A4-A480-DB9C3624E618@fugue.com> 
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/FDM_YSmWCbnXYp-5JzjaVpl93BU
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 21:46:39 -0000

On Oct 17, 2014, at 4:41 PM, James Woodyatt  wrote:
> I explained why you must generate a new ULA prefix every time you =
commission a new network.

Yes, you did, and I believe the mechanism I proposed for handling =
network splits addressed the problem you described.   If you think it =
didn't, can you explain why not, not by expressing reasons to doubt, but =
by walking through specific scenarios where what I proposed wouldn't =
work?


From nobody Fri Oct 17 15:16:51 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36DE1A1A30 for ; Fri, 17 Oct 2014 15:16:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.416
X-Spam-Level: 
X-Spam-Status: No, score=0.416 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSqANVwYLxtY for ; Fri, 17 Oct 2014 15:16:46 -0700 (PDT)
Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB691A1A0F for ; Fri, 17 Oct 2014 15:16:45 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id hq11so1280299vcb.21 for ; Fri, 17 Oct 2014 15:16:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=/5YrBnsOmaKGZRxbs9wSz478ZeQGlRgGkkhHnMPfSgw=; b=QUIqOGqx8bV0SnZjntfo7/swiigN/V7kwkOXdBQUqMIhoDzTgXvOts3ZFC4a8nGQio +P52RH92RHWwYdHE85CSkKKdVs4Ya8VyH5fQg9Z3naL+aY6tgE9FSAwQo4lSV7k7xvSN YRWBHOpN+10HuEPnwlRum88zRbqcma9IIvqtIOH5V5Xl7+r4xmS/tK7OIr6J8Jgmot04 hL3vAJRCzVnGuWb7n5Yt5PnbpkHRW2AS+iRwk8fl7rR1yHkZGiKr5C9NrEByYPP/jwJT bD91woXgAq58LhfGAiK2QTwvsj4usa83B6RAkjVe73TL84TQ76i/pbXpyz0krwo4vOyf 7x9A==
X-Gm-Message-State: ALoCoQlDF+KDa7WUp3EtAk2MTEqHSX5ImjhCnFzXUjmPlisJvEjoLc+26T2WjVF12vxT6+74o7e9
MIME-Version: 1.0
X-Received: by 10.52.248.76 with SMTP id yk12mr8060931vdc.1.1413584205158; Fri, 17 Oct 2014 15:16:45 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Fri, 17 Oct 2014 15:16:44 -0700 (PDT)
In-Reply-To: <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>
Date: Fri, 17 Oct 2014 15:16:44 -0700
Message-ID: 
From: James Woodyatt 
To: HOMENET Working Group 
Content-Type: multipart/alternative; boundary=001a1133ea5868e3830505a5b804
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/z7v-8_Cj0KlsVG_VxxBTRNKOqqY
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 22:16:48 -0000

--001a1133ea5868e3830505a5b804
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 14, 2014 at 3:28 PM, Ted Lemon  wrote:

> On Oct 14, 2014, at 5:14 PM, James Woodyatt  wrote:
> > But there is a problem with only deprecating prefixes without expiring
> them. If they never expire, then they accumulate without limit within
> existing networks as they join with newly commissioned networks over the
> course of their lifetimes.
>
> Ah, sorry, I didn't mean to say that we deprecate them but don't ever get
> rid of them.   I think once a deprecated ULA has expired, it should be
> gc'd.   If the homenet is partitioned, the two options are for the
> partitions to continue using one ULA and try to keep prefixes stable, in
> anticipation of the partition being healed later, or for both partitions =
to
> switch to new ULAs, or for one homenet router to "own" the ULA and get to
> keep it for use in whichever partition it winds up in, while the other
> partition has to choose a new ULA.
>
> Personally I think keeping the ULA stable across partitions is preferable=
,
> but I'm not sure it's possible to do it without the risk of flash
> renumbering.
>
> > So what's the problem? My language above ensures that home network host=
s
> always have at least one gracefully renumbered IPv6 address routable
> throughout the entire network. If we need a further guarantee that hosts
> always have an *invariant* address=E2=80=94 which is an objective you've =
said above
> that you think we don't actually have=E2=80=94 only then are we faced wit=
h the
> problem of prefix accumulation through network joins, which is a problem
> I'm not sure we know how to solve effectively. My proposal avoids that
> trouble.
>
> I understood your language to be trying to get rid of all ULAs if any GUA=
s
> are present.   Did I misunderstand?
>

Mr. Lemon, this is the only message in this thread where I can find you
saying anything about the expiration of locally generate ULA prefixes.

p1. It looks like you agree that locally generate ULA prefixes should be
allowed to expire. What I don't see is any conceptual outline for deciding,
in a distributed methodology, which prefixes to renew and which to release
when their valid lifetime expires. Without seeing that, I can't agree that
you've proposed anything that solves the problem I keep yammering about,
much less offered a better solution than the one I proposed earlier in the
thread.

p2. I also remain confused about the reasoning behind calling for a
persistent locally-generated ULA prefix. In a previous message you said
that it's okay for locally-generated ULA prefixes to expire, because there
is no need for hosts on home networks to have any guarantee that at least
one of its interface addresses is invariant over time, just that at least
one of their addresses is never flash renumbered when a delegated prefix
changes. As Lorenzo has demonstrated earlier today, this quality of never
being flash-renumbered is easily met by delegated ULA and ordinary GUA
prefixes.

Returning to my question: why do we always need a locally-generated ULA
prefix?  If it's to provide a time-invariant locally routable address to
hosts, then locally generated ULA prefixes cannot ever be permitted to
expire for any reason.  If they are ever allowed to expire, then they don't
provide the time-invariant property.  However, if we don't actually need
the time-invariant property, then what does a locally-generated ULA prefix
do for us whenever one or more delegated prefixes is also present? It's not
clear to me they are anything but absolutely redundant and unnecessary in
that situation.

--=20
james woodyatt 
Nest Labs, Communications Engineering

--001a1133ea5868e3830505a5b804
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Oct 14, 2014 at 3:28 PM, Ted Lemon <mellon@fugue.com> wro=
te:
On Oct 14, 2014, at =
5:14 PM, James Woodyatt <jhw@nestlab=
s.com> wrote:

> But there is a problem with only deprecating prefixes without expiring=
 them. If they never expire, then they accumulate without limit within exis=
ting networks as they join with newly commissioned networks over the course=
 of their lifetimes.



Ah, sorry, I didn't mean to say that we deprecate them but don&#=
39;t ever get rid of them.=C2=A0 =C2=A0I think once a deprecated ULA has ex=
pired, it should be gc'd.=C2=A0 =C2=A0If the homenet is partitioned, th=
e two options are for the partitions to continue using one ULA and try to k=
eep prefixes stable, in anticipation of the partition being healed later, o=
r for both partitions to switch to new ULAs, or for one homenet router to &=
quot;own" the ULA and get to keep it for use in whichever partition it=
 winds up in, while the other partition has to choose a new ULA.



Personally I think keeping the ULA stable across partitions is preferable, =
but I'm not sure it's possible to do it without the risk of flash r=
enumbering.



> So what's the problem? My language above ensures that home network=
 hosts always have at least one gracefully renumbered IPv6 address routable=
 throughout the entire network. If we need a further guarantee that hosts a=
lways have an *invariant* address=E2=80=94 which is an objective you've=
 said above that you think we don't actually have=E2=80=94 only then ar=
e we faced with the problem of prefix accumulation through network joins, w=
hich is a problem I'm not sure we know how to solve effectively. My pro=
posal avoids that trouble.



I understood your language to be trying to get rid of all ULAs if an=
y GUAs are present.=C2=A0 =C2=A0Did I misunderstand?
=


Mr. Lemon, this is the only message in=
 this thread where I can find you saying anything about the expiration of l=
ocally generate ULA prefixes.

p1. It looks like you agree that locally generate U=
LA prefixes should be allowed to expire. What I don't see is any concep=
tual outline for deciding, in a distributed methodology, which prefixes to =
renew and which to release when their valid lifetime expires. Without seein=
g that, I can't agree that you've proposed anything that solves the=
 problem I keep yammering about, much less offered a better solution than t=
he one I proposed earlier in the thread.
p2. I also remain confused about the rea=
soning behind calling for a persistent locally-generated ULA prefix. In a p=
revious message you said that it's okay for locally-generated ULA prefi=
xes to expire, because there is no need for hosts on home networks to have =
any guarantee that at least one of its interface addresses is invariant ove=
r time, just that at least one of their addresses is never flash renumbered=
 when a delegated prefix changes. As Lorenzo has demonstrated earlier today=
, this quality of never being flash-renumbered is easily met by delegated U=
LA and ordinary GUA prefixes.

Returnin=
g to my question: why do we always need a locally-generated ULA prefix?=C2=
=A0 If it's to provide a time-invariant locally routable address to hos=
ts, then locally generated ULA prefixes cannot ever be permitted to expire =
for any reason.=C2=A0 If they are ever allowed to expire, then they don'=
;t provide the time-invariant property.=C2=A0 However, if we don't actu=
ally need the time-invariant property, then what does a locally-generated U=
LA prefix do for us whenever one or more delegated prefixes is also present=
? It's not clear to me they are anything but absolutely redundant and u=
nnecessary in that situation.

-- 
j=
ames woodyatt <jhw=
@nestlabs.com>
Nest Labs, Communications Engineering




--001a1133ea5868e3830505a5b804--


From nobody Fri Oct 17 15:37:54 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998AE1A86ED for ; Fri, 17 Oct 2014 15:37:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4pnoUqLSQMI for ; Fri, 17 Oct 2014 15:37:51 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2381A7D84 for ; Fri, 17 Oct 2014 15:37:51 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id BCE85238045C; Fri, 17 Oct 2014 18:37:50 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Fri, 17 Oct 2014 17:37:48 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com> 
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/cC4UHuVR8sztJFa1JXSEP7Ap3KM
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Oct 2014 22:37:52 -0000

On Oct 17, 2014, at 5:16 PM, James Woodyatt  wrote:
> p1. It looks like you agree that locally generate ULA prefixes should =
be allowed to expire. What I don't see is any conceptual outline for =
deciding, in a distributed methodology, which prefixes to renew and =
which to release when their valid lifetime expires. Without seeing that, =
I can't agree that you've proposed anything that solves the problem I =
keep yammering about, much less offered a better solution than the one I =
proposed earlier in the thread.

Please don't put words in my mouth.

I did explain how to do that: before the network partitions, divide the =
ULA into 64k /64 prefixes, and distribute these evenly among attached =
routers.   Routers other than the ones that own a particular /64 are not =
allowed ever to use that /64 unless the router that owns it relinquishes =
it to them explicitly.   Prior to partition, an agreement is made that =
one of the routers gets to keep the ULA in the event of a long-term =
partition.   When a partition happens, the routers that aren't able to =
reach that router anymore need to start a process of deprecating the ULA =
and adding a new ULA.   Presumably after something like half the total =
partition/abandon timeout period, they generate a new ULA and deprecate =
the old ULA.   If the network is reconnected after that, the new ULA is =
deprecated, the old ULA is advertised as preferred, and things heal.

> p2. I also remain confused about the reasoning behind calling for a =
persistent locally-generated ULA prefix. In a previous message you said =
that it's okay for locally-generated ULA prefixes to expire, because =
there is no need for hosts on home networks to have any guarantee that =
at least one of its interface addresses is invariant over time, just =
that at least one of their addresses is never flash renumbered when a =
delegated prefix changes. As Lorenzo has demonstrated earlier today, =
this quality of never being flash-renumbered is easily met by delegated =
ULA and ordinary GUA prefixes.

No, I actually said that it's worth making some effort to avoid having =
ULAs expire.   But it's impossible to eliminate situations in which they =
must.   My goal is simply to avoid having things like simple =
reconfigurations of the network topology result in the generation of new =
ULAs.

> Returning to my question: why do we always need a locally-generated =
ULA prefix?  If it's to provide a time-invariant locally routable =
address to hosts, then locally generated ULA prefixes cannot ever be =
permitted to expire for any reason.  If they are ever allowed to expire, =
then they don't provide the time-invariant property.  However, if we =
don't actually need the time-invariant property, then what does a =
locally-generated ULA prefix do for us whenever one or more delegated =
prefixes is also present? It's not clear to me they are anything but =
absolutely redundant and unnecessary in that situation.

This is a bit of a straw man (see previous comment).   I think trying to =
keep a permanent ULA is a good thing.   We can't always succeed, but we =
can make the set of circumstances under which we fail as small as =
possible.   This is in contrast to what you are proposing, which is that =
we essentially set out to fail, and see deprecation events whenever the =
upstream network goes down.=


From nobody Fri Oct 17 21:25:34 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874731A0252 for ; Fri, 17 Oct 2014 21:25:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.006
X-Spam-Level: 
X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ownncE7AMYIm for ; Fri, 17 Oct 2014 21:25:31 -0700 (PDT)
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC811A0179 for ; Fri, 17 Oct 2014 21:25:31 -0700 (PDT)
Received: by mail-pa0-f54.google.com with SMTP id ey11so1918382pad.41 for ; Fri, 17 Oct 2014 21:25:31 -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=eSMPfEMLaVLjeeEFoXWG565VASSJjZlNkyQKIwevFFc=; b=M//D69L0WFmnhtzX8ZrlFNseCdYzgVkn4hnPBf4vnKjAMJoUrO25i1GjmsBcVYx85n 94rT7oHOpW1wyz+bNBs49c5B13unTzeceuLgoTwpqHDLtHWdAmn/nVaHVD57GudQO0pd Qzj4DqccNqiSbE+/Fz3FkNeac73aWn1FFXAjHMsKvhiSoFYM0uNFf7HbnAZ6hHJN5TML F9j4Isd5ZN9ablpqS9urevC3SjSehE1ObRmPF3QCy61ATsR9gUk9NHpGLUqjdQ5CRHQW tywoZIYw9g5Rc4c600yoS/c0swmV37qzWI51B/icFxXGhC91WbBMwGxBAQN5tEUkYOSM 5gJg==
X-Received: by 10.70.38.232 with SMTP id j8mr13051101pdk.44.1413606331222; Fri, 17 Oct 2014 21:25:31 -0700 (PDT)
Received: from [172.17.1.55] (219-89-120-188.adsl.xtra.co.nz. [219.89.120.188]) by mx.google.com with ESMTPSA id ah2sm2921657pad.10.2014.10.17.21.25.27 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 21:25:29 -0700 (PDT)
Message-ID: <5441EBC2.30905@gmail.com>
Date: Sat, 18 Oct 2014 17:25:38 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ted Lemon 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>
In-Reply-To: <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/7MQ4oif7Z4RRtovOLlMx1C4Dwhs
Cc: HOMENET Working Group , James Woodyatt 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Oct 2014 04:25:32 -0000

Ted,

On 18/10/2014 11:37, Ted Lemon wrote:
> On Oct 17, 2014, at 5:16 PM, James Woodyatt  wrote:
>> p1. It looks like you agree that locally generate ULA prefixes should be allowed to expire. What I don't see is any conceptual outline for deciding, in a distributed methodology, which prefixes to renew and which to release when their valid lifetime expires. Without seeing that, I can't agree that you've proposed anything that solves the problem I keep yammering about, much less offered a better solution than the one I proposed earlier in the thread.
> 
> Please don't put words in my mouth.
> 
> I did explain how to do that: before the network partitions, 

That seems to imply that you know in advance that the network
will partition. I assume that it will usually be a surprise.
Normally there is no human manager, although a human might
randomly disconnect cables or switch off a power socket.

So I think you mean: as soon as the network has generated its ULA...

> divide the ULA into 64k /64 prefixes, and distribute these evenly among attached routers.

...but that will break when another router attaches itself later,
unless the (re)distribution process is continuous.

>  Routers other than the ones that own a particular /64 are not allowed ever to use that /64 unless the router that owns it relinquishes it to them explicitly.

Sure, and this needs to be supported by HNCP (or something else).

>   Prior to partition, an agreement is made that one of the routers gets to keep the ULA in the event of a long-term partition. 

Again: that has to happen as soon as the ULA is generated, since partition
is unpredictable.

   Brian


From nobody Sat Oct 18 05:57:39 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1FB1A86DD for ; Sat, 18 Oct 2014 05:57:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRS_pPjd_dj0 for ; Sat, 18 Oct 2014 05:57:36 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAFA1A802C for ; Sat, 18 Oct 2014 05:57:36 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id 92CEB238039E; Sat, 18 Oct 2014 08:57:33 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <5441EBC2.30905@gmail.com>
Date: Sat, 18 Oct 2014 07:57:32 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <58C46D6F-BF91-443C-B44A-DF5B52C3F77A@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com> <5441EBC2.30905@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ruir0_4D80sHKopikqTmy5dbCFM
Cc: HOMENET Working Group , James Woodyatt 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Oct 2014 12:57:38 -0000

On Oct 17, 2014, at 11:25 PM, Brian E Carpenter =
 wrote:
>> I did explain how to do that: before the network partitions,=20
>=20
> That seems to imply that you know in advance that the network
> will partition. I assume that it will usually be a surprise.
> Normally there is no human manager, although a human might
> randomly disconnect cables or switch off a power socket.
>=20
> So I think you mean: as soon as the network has generated its ULA...

That is indeed what I meant, sorry for not saying so explicitly.

>> divide the ULA into 64k /64 prefixes, and distribute these evenly =
among attached routers.
>=20
> ...but that will break when another router attaches itself later,
> unless the (re)distribution process is continuous.

Which is the reason we have HNCP.

>> Routers other than the ones that own a particular /64 are not allowed =
ever to use that /64 unless the router that owns it relinquishes it to =
them explicitly.
>=20
> Sure, and this needs to be supported by HNCP (or something else).

Yup.

>>  Prior to partition, an agreement is made that one of the routers =
gets to keep the ULA in the event of a long-term partition.=20
>=20
> Again: that has to happen as soon as the ULA is generated, since =
partition
> is unpredictable.

To clarify, yes, when the ULA is generated you have to do this, but you =
may revisit the decision subsequently, prior to partition.   You don't =
know when partition happens, but that doesn't preclude making new =
choices later.   E.g., if you only have one internet connection, you =
might want the device connected to that link to be the one that holds =
the token.   Or you may have a dedicated server on-link which would be =
ideal for stuff like this, although we really haven't talked about =
non-router servers participating in HNCP.


From nobody Sat Oct 18 06:11:55 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C111A8704 for ; Sat, 18 Oct 2014 06:11:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqMKE9Aiz_Yi for ; Sat, 18 Oct 2014 06:11:50 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 67CA41A86EC for ; Sat, 18 Oct 2014 06:11:50 -0700 (PDT)
Received: from [192.168.1.63] (c-71-201-198-58.hsd1.il.comcast.net [71.201.198.58]) by toccata.fugue.com (Postfix) with ESMTPSA id A71A5238039E; Sat, 18 Oct 2014 09:11:49 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <58C46D6F-BF91-443C-B44A-DF5B52C3F77A@fugue.com>
Date: Sat, 18 Oct 2014 08:11:47 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <0AB8132B-EB56-4F8C-A24A-8F394E7F27F1@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com> <5441EBC2.30905@gmail.com> <58C46D6F-BF91-443C-B44A-DF5B52C3F77A@fugue.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/_qDcFFy0NXYrA6uQ54zLAJMBVsE
Cc: HOMENET Working Group , James Woodyatt 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Oct 2014 13:11:51 -0000

On Oct 18, 2014, at 7:57 AM, Ted Lemon  wrote:
> To clarify, yes, when the ULA is generated you have to do this, but =
you may revisit the decision subsequently, prior to partition.   You =
don't know when partition happens, but that doesn't preclude making new =
choices later.   E.g., if you only have one internet connection, you =
might want the device connected to that link to be the one that holds =
the token.   Or you may have a dedicated server on-link which would be =
ideal for stuff like this, although we really haven't talked about =
non-router servers participating in HNCP.

And by "you" here I am of course anthropomorphizing the homenet...


From nobody Mon Oct 20 11:00:50 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E591A8A7A for ; Mon, 20 Oct 2014 11:00:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.915
X-Spam-Level: 
X-Spam-Status: No, score=0.915 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pndjorKo6uLI for ; Mon, 20 Oct 2014 11:00:44 -0700 (PDT)
Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54E81A8A79 for ; Mon, 20 Oct 2014 11:00:40 -0700 (PDT)
Received: by mail-vc0-f180.google.com with SMTP id le20so3858781vcb.25 for ; Mon, 20 Oct 2014 11:00:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+Druzmux9vMR72/YyGXWQfba9D2mVpAdIuiSvsHuojs=; b=ITG8yVwe+5+oQ/eJ1fDoNaw12zGy3kTf39Q89rhwTnh6ted/zJXL4QzOrdpRIliYlZ 8hi+lFfB6iDjZt9M+WR1PP+cHam571ALHqvyCM2vuM5jeIvB/ftqjOAL8boYsL7OPLGJ uJiBbM6gedpHiQajafk2U+sBeCR1Kxo61dY6oc53iLYwHFAKBG9fjc/eqj0ZWuIVM7lq 4RQJlWzGfW9LmJ7GLMw6uONMxUWa1Pm4HNnQAa+SmAbMVuf71SzTe3huyDfPw0pvlB9x xPpqlrQFaP+AX9mGwYhoH1qMj5BUb47Tm0Zwlv5ZHxkPAWIjy++jxwWDzpWNnjW6HUZr g3lQ==
X-Gm-Message-State: ALoCoQl7ZM+DkGjMGPdK6cLNiG/fKrz05iAvm5UoiW+/oyuw1WEorsEYEZzirBhSfw1yT7CYC5Sk
MIME-Version: 1.0
X-Received: by 10.221.66.12 with SMTP id xo12mr2636275vcb.72.1413828039349; Mon, 20 Oct 2014 11:00:39 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Mon, 20 Oct 2014 11:00:39 -0700 (PDT)
In-Reply-To: <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>
Date: Mon, 20 Oct 2014 11:00:39 -0700
Message-ID: 
From: James Woodyatt 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=001a113653080f35480505de7e20
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ERzD_UU8dPx9mcDlD139AoSBnRM
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 18:00:49 -0000

--001a113653080f35480505de7e20
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 17, 2014 at 3:37 PM, Ted Lemon  wrote:

> [...] before the network partitions, divide the ULA into 64k /64 prefixes,
> and distribute these evenly among attached routers.   Routers other than
> the ones that own a particular /64 are not allowed ever to use that /64
> unless the router that owns it relinquishes it to them explicitly.   Prior
> to partition, an agreement is made that one of the routers gets to keep the
> ULA in the event of a long-term partition.   When a partition happens, the
> routers that aren't able to reach that router anymore need to start a
> process of deprecating the ULA and adding a new ULA.   Presumably after
> something like half the total partition/abandon timeout period, they
> generate a new ULA and deprecate the old ULA.   If the network is
> reconnected after that, the new ULA is deprecated, the old ULA is
> advertised as preferred, and things heal.
>

My apologies, but this is the first I've seen this basic idea outlined
here.  If you explained it previously, then I missed it due to my
inattention, and I apologize.

I do think this idea should needs a more rigorous description before I can
give it more thoughtful consideration. Some questions: "an agreement is
made" how? "aren't able to reach that router anymore" why (and how is that
detected)? "the new ULA is deprecated, the old ULA is advertised as
preferred" which is which, and how is it recognized (e.g. by NTP time
stamp)?


> > p2. I also remain confused about the reasoning behind calling for a
> persistent locally-generated ULA prefix. In a previous message you said
> that it's okay for locally-generated ULA prefixes to expire, because there
> is no need for hosts on home networks to have any guarantee that at least
> one of its interface addresses is invariant over time, just that at least
> one of their addresses is never flash renumbered when a delegated prefix
> changes. As Lorenzo has demonstrated earlier today, this quality of never
> being flash-renumbered is easily met by delegated ULA and ordinary GUA
> prefixes.
>
> No, I actually said that it's worth making some effort to avoid having
> ULAs expire.   But it's impossible to eliminate situations in which they
> must.   My goal is simply to avoid having things like simple
> reconfigurations of the network topology result in the generation of new
> ULAs.


Okay... except it seems you're admitting that my scenario where a simple
reconfiguration of a network topology, e.g. one caused by an intermittent
RF interference on an unlicensed band of the radio spectrum, would result
in a fully regular and normalized generation of a ULA prefix that would
subsequently be deprecated on network rejoin and subsequently deprecated
again. This could happen several times per hour, right?


> > Returning to my question: why do we always need a locally-generated ULA
> prefix?  If it's to provide a time-invariant locally routable address to
> hosts, then locally generated ULA prefixes cannot ever be permitted to
> expire for any reason.  If they are ever allowed to expire, then they don't
> provide the time-invariant property.  However, if we don't actually need
> the time-invariant property, then what does a locally-generated ULA prefix
> do for us whenever one or more delegated prefixes is also present? It's not
> clear to me they are anything but absolutely redundant and unnecessary in
> that situation.
>
> This is a bit of a straw man (see previous comment).   I think trying to
> keep a permanent ULA is a good thing.   We can't always succeed, but we can
> make the set of circumstances under which we fail as small as possible.
>  This is in contrast to what you are proposing, which is that we
> essentially set out to fail, and see deprecation events whenever the
> upstream network goes down.


I certainly would agree with your observation that I don't see keeping a
permanent ULA as a good thing in itself. I keep asking why that would be
beneficial, and the answers continue to leave me scratching my head. Please
count me as one of the people here who has read Brian Carpenter's rant in
SIGCOMM about IP Addresses Considered Harmful, and who generally agrees.
I'm uncomfortable trying too hard to achieve some partial and dubious
success at establishing a persistent ULA prefix in the home network. I
think we should put our efforts more into making persistent the local
namespace for service registration and discovery.


-- 
james woodyatt 
Nest Labs, Communications Engineering

--001a113653080f35480505de7e20
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On F=
ri, Oct 17, 2014 at 3:37 PM, Ted Lemon <mellon@fugue.com> wro=
te:
[...] before the network partitions, divide the ULA=
 into 64k /64 prefixes, and distribute these evenly among attached routers.=
=C2=A0 =C2=A0Routers other than the ones that own a particular /64 are not =
allowed ever to use that /64 unless the router that owns it relinquishes it=
 to them explicitly.=C2=A0 =C2=A0Prior to partition, an agreement is made t=
hat one of the routers gets to keep the ULA in the event of a long-term par=
tition.=C2=A0 =C2=A0When a partition happens, the routers that aren't a=
ble to reach that router anymore need to start a process of deprecating the=
 ULA and adding a new ULA.=C2=A0 =C2=A0Presumably after something like half=
 the total partition/abandon timeout period, they generate a new ULA and de=
precate the old ULA.=C2=A0 =C2=A0If the network is reconnected after that, =
the new ULA is deprecated, the old ULA is advertised as preferred, and thin=
gs heal.

My apologies, but this is the =
first I've seen this basic idea outlined here.=C2=A0 If you explained i=
t previously, then I missed it due to my inattention, and I apologize.

I do think this idea should needs a more rigorous desc=
ription before I can give it more thoughtful consideration. Some questions:=
 "an agreement is made" how? "aren't able to reach that =
router anymore" why (and how is that detected)? "the new ULA is d=
eprecated, the old ULA is advertised as preferred" which is which, and=
 how is it recognized (e.g. by NTP time stamp)?
=C2=A0
> p2. I also remain confused about the reas=
oning behind calling for a persistent locally-generated ULA prefix. In a pr=
evious message you said that it's okay for locally-generated ULA prefix=
es to expire, because there is no need for hosts on home networks to have a=
ny guarantee that at least one of its interface addresses is invariant over=
 time, just that at least one of their addresses is never flash renumbered =
when a delegated prefix changes. As Lorenzo has demonstrated earlier today,=
 this quality of never being flash-renumbered is easily met by delegated UL=
A and ordinary GUA prefixes.



No, I actually said that it's worth making some effort to avoid =
having ULAs expire.=C2=A0 =C2=A0But it's impossible to eliminate situat=
ions in which they must.=C2=A0 =C2=A0My goal is simply to avoid having thin=
gs like simple reconfigurations of the network topology result in the gener=
ation of new ULAs.

Okay... except it seems =
you're admitting that my scenario where a simple reconfiguration of a n=
etwork topology, e.g. one caused by an intermittent RF interference on an u=
nlicensed band of the radio spectrum, would result in a fully regular and n=
ormalized generation of a ULA prefix that would subsequently be deprecated =
on network rejoin and subsequently deprecated again. This could happen seve=
ral times per hour, right?
=C2=A0
> Returning to my question: why do we always need a locally-gene=
rated ULA prefix?=C2=A0 If it's to provide a time-invariant locally rou=
table address to hosts, then locally generated ULA prefixes cannot ever be =
permitted to expire for any reason.=C2=A0 If they are ever allowed to expir=
e, then they don't provide the time-invariant property.=C2=A0 However, =
if we don't actually need the time-invariant property, then what does a=
 locally-generated ULA prefix do for us whenever one or more delegated pref=
ixes is also present? It's not clear to me they are anything but absolu=
tely redundant and unnecessary in that situation.



This is a bit of a straw man (see previous comment).=C2=A0 =C2=A0I t=
hink trying to keep a permanent ULA is a good thing.=C2=A0 =C2=A0We can'=
;t always succeed, but we can make the set of circumstances under which we =
fail as small as possible.=C2=A0 =C2=A0This is in contrast to what you are =
proposing, which is that we essentially set out to fail, and see deprecatio=
n events whenever the upstream network goes down.

I c=
ertainly would agree with your observation that I don't see keeping a p=
ermanent ULA as a good thing in itself. I keep asking why that would be ben=
eficial, and the answers continue to leave me scratching my head. Please co=
unt me as one of the people here who has read Brian Carpenter's rant in=
 SIGCOMM about IP Addresses Considered Harmful, and who generally agrees. I=
'm uncomfortable trying too hard to achieve some partial and dubious su=
ccess at establishing a persistent ULA prefix in the home network. I think =
we should put our efforts more into making persistent the local namespace f=
or service registration and discovery.


-- 
james woodyatt <jhw@nestlabs.com>=

Nest Labs, Communications Engineering




--001a113653080f35480505de7e20--


From nobody Mon Oct 20 12:34:43 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23701AC42A for ; Mon, 20 Oct 2014 12:34:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.483
X-Spam-Level: 
X-Spam-Status: No, score=0.483 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMr2Jb6P1LQS for ; Mon, 20 Oct 2014 12:34:38 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id F25F91AC429 for ; Mon, 20 Oct 2014 12:34:37 -0700 (PDT)
Received: from [10.0.10.40] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id 43A5A23802B7; Mon, 20 Oct 2014 15:34:36 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Mon, 20 Oct 2014 15:34:32 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com> 
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/k2t0DKFT2Fn_ESkfA2iVzL7MZwo
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 19:34:39 -0000

On Oct 20, 2014, at 2:00 PM, James Woodyatt  wrote:
> Okay... except it seems you're admitting that my scenario where a =
simple reconfiguration of a network topology, e.g. one caused by an =
intermittent RF interference on an unlicensed band of the radio =
spectrum, would result in a fully regular and normalized generation of a =
ULA prefix that would subsequently be deprecated on network rejoin and =
subsequently deprecated again. This could happen several times per hour, =
right?

No, if it's done right the network would have to be partitioned for on =
the order of a week or two before the new ULA would be generated.

>>> > Returning to my question: why do we always need a =
locally-generated ULA prefix?  If it's to provide a time-invariant =
locally routable address to hosts, then locally generated ULA prefixes =
cannot ever be permitted to expire for any reason.  If they are ever =
allowed to expire, then they don't provide the time-invariant property.  =
However, if we don't actually need the time-invariant property, then =
what does a locally-generated ULA prefix do for us whenever one or more =
delegated prefixes is also present? It's not clear to me they are =
anything but absolutely redundant and unnecessary in that situation.
>>>=20
>> This is a bit of a straw man (see previous comment).   I think trying =
to keep a permanent ULA is a good thing.   We can't always succeed, but =
we can make the set of circumstances under which we fail as small as =
possible.   This is in contrast to what you are proposing, which is that =
we essentially set out to fail, and see deprecation events whenever the =
upstream network goes down.
>>=20
> I certainly would agree with your observation that I don't see keeping =
a permanent ULA as a good thing in itself. I keep asking why that would =
be beneficial, and the answers continue to leave me scratching my head. =
Please count me as one of the people here who has read Brian Carpenter's =
rant in SIGCOMM about IP Addresses Considered Harmful, and who generally =
agrees. I'm uncomfortable trying too hard to achieve some partial and =
dubious success at establishing a persistent ULA prefix in the home =
network. I think we should put our efforts more into making persistent =
the local namespace for service registration and discovery.

The reason I think it's beneficial is that it reduces to the minimum the =
number of instances where a long-lived connection will have to be broken =
because of a renumbering event.   I don't think we can reduce that =
number to zero, but I think we can make it a lot less likely than it =
would be if we renumber every time the upstream link goes away.


From nobody Mon Oct 20 13:24:16 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D58B1ACDF4 for ; Mon, 20 Oct 2014 13:24:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.984
X-Spam-Level: 
X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUuHjdVOYnym for ; Mon, 20 Oct 2014 13:24:11 -0700 (PDT)
Received: from mail-yh0-f47.google.com (mail-yh0-f47.google.com [209.85.213.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715671ACDE0 for ; Mon, 20 Oct 2014 13:24:11 -0700 (PDT)
Received: by mail-yh0-f47.google.com with SMTP id c41so3939526yho.34 for ; Mon, 20 Oct 2014 13:24:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=zLHWIH25/ijxnorfIi2OkNvkJo8ewQQFKzFMJWlWpJc=; b=HHI5IF7Q3dSUD/bwQtKovxpKWxrBjf7Fa+r0WRxmbElWTgNZKQZu/Hvk0X9FQq3LUt PtKxqjIFzxgR/E9q5s0D86A5cD25XUdVnnzuc4ZQF4pZG6mY8KEllBQ+LTE3IFPq7rNx 8Qvw6Xh65RV5OgNYDGLBs5snk3Y+zv2QWnTG2xGDtDUu9VSBw7+5F4J4t0cBUWhwnWhW RDjcK8XWg6s7fN2eSCd0fUly7VXqR+HblIMW10v2mDXC2UbbAFizgMlXwclqN0D3l12d 7T53KCefdmVAjXCgMdOx5VyP3skwss2wqDVEGfUpyEsFvA6uVcJvWvOu/j431PBVNElD pxSA==
X-Gm-Message-State: ALoCoQnzcd7OZsMdHl+04QPsd76rttnyD5xyJ5SKhSPjE/Qfbkd7L6L4OWR0M6vlBmYDlgQadup9
MIME-Version: 1.0
X-Received: by 10.53.5.132 with SMTP id cm4mr15862835vdd.50.1413836650626; Mon, 20 Oct 2014 13:24:10 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Mon, 20 Oct 2014 13:24:10 -0700 (PDT)
In-Reply-To: <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>  <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com>
Date: Mon, 20 Oct 2014 13:24:10 -0700
Message-ID: 
From: James Woodyatt 
To: HOMENET Working Group 
Content-Type: multipart/alternative; boundary=001a1133eda25508730505e07f26
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Dqy4xIcdytIENetWWjwgyQm_V6M
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 20:24:13 -0000

--001a1133eda25508730505e07f26
Content-Type: text/plain; charset=UTF-8

On Mon, Oct 20, 2014 at 12:34 PM, Ted Lemon  wrote:

> On Oct 20, 2014, at 2:00 PM, James Woodyatt  wrote:
> > Okay... except it seems you're admitting that my scenario where a simple
> reconfiguration of a network topology, e.g. one caused by an intermittent
> RF interference on an unlicensed band of the radio spectrum, would result
> in a fully regular and normalized generation of a ULA prefix that would
> subsequently be deprecated on network rejoin and subsequently deprecated
> again. This could happen several times per hour, right?
>
> No, if it's done right the network would have to be partitioned for on the
> order of a week or two before the new ULA would be generated.


Did you respond to my previous criticism of this idea? If so, then I missed
it. It's not a good idea to commission a new standalone network with the
same ULA as a previously commissioned network, because it destroys the main
property of ULA prefixes that makes them useful: the statistical
unlikelihood of merge collisions in the global address realm.


> The reason I think it's beneficial is that it reduces to the minimum the
> number of instances where a long-lived connection will have to be broken
> because of a renumbering event.   I don't think we can reduce that number
> to zero, but I think we can make it a lot less likely than it would be if
> we renumber every time the upstream link goes away.
>

Sounds to me like a benefit of very dubious value at best.  It's a fact
that applications cannot depend on the network never encountering a
renumbering event. That's the whole reason addresses have valid and
preferred lifetimes in the first place.  Applications that use long-lived
IPv6 connections cannot escape the problem that interface addresses may
expire at any time.  If they're not coded to recover from such events, then
it's their logic error, not ours.

I see no reason to work very hard to provide applications with a class of
global scope interface addresses that IETF documents encourage developers
to assume will never reach vltime=0 except when that assumption is
mysteriously invalid anyway because reasons. If there is a good reason for
it, which I'm missing, then I'm happy to consider it.


-- 
james woodyatt 
Nest Labs, Communications Engineering

--001a1133eda25508730505e07f26
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, Oct 20, 2014 at 12:34 PM, Ted Lemon <mellon@fugue.com> wr=
ote:
On Oct 20, 2014, at=
 2:00 PM, James Woodyatt <jhw@nestla=
bs.com> wrote:

> Okay... except it seems you're admitting that my scenario where a =
simple reconfiguration of a network topology, e.g. one caused by an intermi=
ttent RF interference on an unlicensed band of the radio spectrum, would re=
sult in a fully regular and normalized generation of a ULA prefix that woul=
d subsequently be deprecated on network rejoin and subsequently deprecated =
again. This could happen several times per hour, right?



No, if it's done right the network would have to be partitioned =
for on the order of a week or two before the new ULA would be generated.

Did you respond to my previous criticism of t=
his idea? If so, then I missed it. It's not a good idea to commission a=
 new standalone network with the same ULA as a previously commissioned netw=
ork, because it destroys the main property of ULA prefixes that makes them =
useful: the statistical unlikelihood of merge collisions in the global addr=
ess realm.
=C2=A0
The reason =
I think it's beneficial is that it reduces to the minimum the number of=
 instances where a long-lived connection will have to be broken because of =
a renumbering event.=C2=A0 =C2=A0I don't think we can reduce that numbe=
r to zero, but I think we can make it a lot less likely than it would be if=
 we renumber every time the upstream link goes away.



Sounds to me like a benefit of very dubious value at=
 best.=C2=A0 It's a fact that applications cannot depend on the network=
 never encountering a renumbering event. That's the whole reason addres=
ses have valid and preferred lifetimes in the first place.=C2=A0 Applicatio=
ns that use long-lived IPv6 connections cannot escape the problem that inte=
rface addresses may expire at any time.=C2=A0 If they're not coded to r=
ecover from such events, then it's their logic error, not ours.

I see no reas=
on to work very hard to provide applications with a class of global scope i=
nterface addresses that IETF documents encourage developers to assume will =
never reach vltime=3D0 except when that assumption is mysteriously invalid =
anyway because reasons. If there is a good reason for it, which I'm mis=
sing, then I'm happy to consider it.


-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communicati=
ons Engineering




--001a1133eda25508730505e07f26--


From nobody Mon Oct 20 13:32:36 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1B91ACE23 for ; Mon, 20 Oct 2014 13:32:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HKkv3QUxNjU for ; Mon, 20 Oct 2014 13:32:33 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id CD7F71ACE25 for ; Mon, 20 Oct 2014 13:32:33 -0700 (PDT)
Received: from [10.0.10.40] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id A1B3E238013F; Mon, 20 Oct 2014 16:32:32 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Mon, 20 Oct 2014 16:32:27 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>  <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com> 
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/zuEcUIz8qx5VQWmLbOq63JXpAJk
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 20:32:34 -0000

On Oct 20, 2014, at 4:24 PM, James Woodyatt  wrote:
> Did you respond to my previous criticism of this idea? If so, then I =
missed it. It's not a good idea to commission a new standalone network =
with the same ULA as a previously commissioned network, because it =
destroys the main property of ULA prefixes that makes them useful: the =
statistical unlikelihood of merge collisions in the global address =
realm.

Yes, I read your explanation, and the solution I proposed takes it into =
account.   Please stop arguing to win and actually read what I wrote.

>> The reason I think it's beneficial is that it reduces to the minimum =
the number of instances where a long-lived connection will have to be =
broken because of a renumbering event.   I don't think we can reduce =
that number to zero, but I think we can make it a lot less likely than =
it would be if we renumber every time the upstream link goes away.
>>=20
> Sounds to me like a benefit of very dubious value at best.

Look at it this way: if you have a network and it occasionally gets =
reconfigured in a way that an application connection _cannot_ survive, =
that's bad, but we do accept that such situations occur from time to =
time.   But what if you have a network that is mainly stable, but you =
have a provider that isn't entirely reliable.   Is this network =
equivalent to one where you have a monkey who comes in every thirty =
minutes and swaps all the cables around?

Yes, we have to ride out unusual configuration change events.   But is =
it really "of very dubious value" to try to minimize the impact these =
events have on the stable operation of the network?  I don't think it =
is.

BTW, your flaky radio scenario isn't actually better if you have a GUA; =
arguably it's worse, particularly since it's probably an LLN that =
expects flakiness and knows how to ride it out, but does _not_ expect to =
be renumbered on a regular basis.   Please diagram that scenario and =
make sure you understand all the state transitions before you use it as =
a justification for not bothering to try to have a stable ULA.


From nobody Mon Oct 20 13:52:52 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F5D1A0105 for ; Mon, 20 Oct 2014 13:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.984
X-Spam-Level: 
X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdxXc-13HE-d for ; Mon, 20 Oct 2014 13:52:50 -0700 (PDT)
Received: from mail-yh0-f47.google.com (mail-yh0-f47.google.com [209.85.213.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9D81ACE93 for ; Mon, 20 Oct 2014 13:52:50 -0700 (PDT)
Received: by mail-yh0-f47.google.com with SMTP id c41so4003696yho.20 for ; Mon, 20 Oct 2014 13:52:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=CTCJCvmvPx388xEb0szbnoO5l9XjQ4mYgr58KEYzqB8=; b=fGnTpLGAANZ5Vyi8bGZQNmfdjGU5QHUXhXaEyVB/9iJDGBNtn0nHmWguik4fYyQznv CECK6K/dfGLxh7iPu+yQTTJCyBNBuU5aX55TC21NKYDMBOb96dLwWDCDpLGGtyPrJ41i v1bZgCAEwPWkURQecudHRtqh3G58cWI+9zKEP/QQ1iJ5xIpPOI6iyNe1TayMCr/8LkKk EdOfxiD8895MhHlIbIRkLdHvCmRaRiIJQN/D33hdcWm0qBc9+zD5p1174i9joNbelPsx 0QNL8JZ9kdcPyUzp1L1ITjd0xC8DrzN8du1sl2sqpXwofTh0Xa09H+r8aXf/YdIsWF4T 5yyQ==
X-Gm-Message-State: ALoCoQm19VWWmmG1UB4Gcb8CJm/NZ6TNZwR2Wj9WvH70cEC8ysXljEmZcjVkKTlLQ+hBEDJ2Xvt0
MIME-Version: 1.0
X-Received: by 10.220.87.203 with SMTP id x11mr3555157vcl.58.1413838369727; Mon, 20 Oct 2014 13:52:49 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Mon, 20 Oct 2014 13:52:49 -0700 (PDT)
In-Reply-To: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>  <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com>  
Date: Mon, 20 Oct 2014 13:52:49 -0700
Message-ID: 
From: James Woodyatt 
To: HOMENET Working Group 
Content-Type: multipart/alternative; boundary=047d7b3a8eaacc3a590505e0e567
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/-z7b7VEUIX6r_gcbicWCKNOiCCM
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 20:52:51 -0000

--047d7b3a8eaacc3a590505e0e567
Content-Type: text/plain; charset=UTF-8

On Mon, Oct 20, 2014 at 1:32 PM, Ted Lemon  wrote:

>
> Yes, I read your explanation, and the solution I proposed takes it into
> account.   Please stop arguing to win and actually read what I wrote.
>

I did read what you wrote, and I do not agree that you are taking into
account my concerns.  Nevertheless, I shall stop arguing my case, and I
will accept that I've lost it.


-- 
james woodyatt 
Nest Labs, Communications Engineering

--047d7b3a8eaacc3a590505e0e567
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, Oct 20, 2014 at 1:32 PM, Ted Lemon <mellon@fugue.com> wro=
te:


Yes, I read your explanation, and the solution I proposed takes it i=
nto account.=C2=A0 =C2=A0Please stop arguing to win and actually read what =
I wrote.

I did read what you wrote, and=
 I do not agree that you are taking into account my concerns.=C2=A0 Neverth=
eless, I shall stop arguing my case, and I will accept that I've lost i=
t.=C2=A0


-- 
james woodyatt <=
jhw@nestlabs.com>
Nest Labs, Communications Engineering




--047d7b3a8eaacc3a590505e0e567--


From nobody Mon Oct 20 14:00:45 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889EF1ACE9B for ; Mon, 20 Oct 2014 14:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eb0SS0Owl_bu for ; Mon, 20 Oct 2014 14:00:42 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 7930F1ACE92 for ; Mon, 20 Oct 2014 14:00:42 -0700 (PDT)
Received: from [10.0.10.40] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id 929502380299; Mon, 20 Oct 2014 17:00:41 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Mon, 20 Oct 2014 17:00:06 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D269223-52B5-4B58-A46F-3B787EAFE4F3@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>  <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com>   
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/87nXNPouldRgfRgaQpjQCyslsws
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Oct 2014 21:00:43 -0000

On Oct 20, 2014, at 4:52 PM, James Woodyatt  wrote:
> I did read what you wrote, and I do not agree that you are taking into =
account my concerns.  Nevertheless, I shall stop arguing my case, and I =
will accept that I've lost it.=20

I persist in thinking that we are failing to communicate, but it would =
be a fair criticism to raise that this stuff is difficult to converge on =
in an email conversation, and a draft would be easier to discuss.  So I =
will try to write one up in my copious free time this week, and then we =
can probably converge.   I hesitate to write the draft because I am not =
convinced we will wind up actually doing what I am proposing, but it's =
probably worth it even if we don't actually proceed with it.


From SRS0=2pWH=7M=darou.fr=pierre.pfister@bounces.m4x.org  Tue Oct 21 01:28:24 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E042E1A01BA for ; Tue, 21 Oct 2014 01:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.207
X-Spam-Level: 
X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYUsTjR9yuJT for ; Tue, 21 Oct 2014 01:28:19 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D011AD3DF for ; Tue, 21 Oct 2014 01:26:08 -0700 (PDT)
Received: from ams3-vpn-dhcp8081.cisco.com (173-38-208-170.cisco.com [173.38.208.170]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 80D761408EEE4; Tue, 21 Oct 2014 10:26:05 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_ED8B5977-52D5-4B5D-9D9F-A08135563F9B"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Pierre Pfister 
In-Reply-To: <1D269223-52B5-4B58-A46F-3B787EAFE4F3@fugue.com>
Date: Tue, 21 Oct 2014 10:26:07 +0200
Message-Id: <802A6061-3B41-4296-B739-E740DCF4873F@darou.fr>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>  <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com>    <1D269223-52B5-4B58-A46F-3B787EAFE4F3@fugue.com>
To: Ted Lemon 
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Tue Oct 21 10:26:06 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/0NZx-E3FY3esnG5BkxgFhS4JbRU
Cc: HOMENET Working Group , James Woodyatt 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 08:40:24 -0000

--Apple-Mail=_ED8B5977-52D5-4B5D-9D9F-A08135563F9B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hello,

I tried to make a proposal which would deal with these network splits.
Even though I must say that the PA draft in the first place did not =
cause any problem when network splits and joins later (collisions are =
dealt with). This adds quite a bunch of complexity, and provides the =
conceptually pleasant idea that splited home networks will end-up using =
different ULAs (even thought it=92s not a problem if they do).

So here it is:

9.1.  ULA Prefix Generation

   ULA prefixes can be randomly generated as specified in [RFC4193],
   enabling stable in-home IPv6 connectivity.

   In this section, we say a ULA delegated prefix is 'stable' if it has
   been the only advertised ULA delegated prefix for at least
   2*FLOODING_DELAY seconds.  The behaviour specified in the following
   sections tend to reuse a stable ULA prefix as long as its preferred
   lifetime is not null.

   Additionaly, we say a router is the owner of a spontaneously
   generated ULA prefix if it randomly created the prefix in the first
   place.  A router SHOULD NOT create more than one prefix this way, and
   MUST remember all the prefixes they own.  As stated in the following
   sections, only the owner of a prefix can extend its lifetimes.

9.1.1.  Choosing the ULA prefix

   When a stable ULA prefix is advertised, all routers SHOULD remember
   that prefix alongwith its associated valid and preferred lifetime.
   If this prefix stops being advertised (e.g. due to a network split)
   while its preferred lifetime is not null, the same ULA prefix SHOULD
   be selected using the same valid and preferred lifetimes.

   If there was no stable ULA prefix advertised, or if the preferred
   lifetime of the prefix was null, a prefix generated as specified in
   [RFC4193] SHOULD be used.  In case the stable storage can't be used
   or the current date cannot be determined, the prefix MAY be pseudo-
   randomly generated based on hardware specific values.

9.1.2.  Advertising a ULA prefix

   A router MAY start advertising a ULA prefix whenever the two
   following conditions are met:

   o  It is the network leader.

   o  There is no other advertised ULA prefix.

   If no IPv6 prefix is available at all, the network leader SHOULD
   start advertising a ULA delegated prefix.

   Additionaly, a router SHOULD start advertising its own ULA prefix
   whenever the three following conditions are met:

   o  A stable ULA prefix is advertised by another router.

   o  The router owns the advertised stable ULA prefix.

   o  The preferred lifetime of the advertised ULA prefix is below 10
      minutes.

   This allows a router to restart advertising a owned prefix whenever
   the preferred lifetime is approaching zero.  Which later allows him
   to extend the lifetime of the prefix.

   A router MUST stop advertising a spontaenously generated ULA prefix
   whenever one of the two following condition is met:

   o  A different ULA prefix is being advertised.

   o  The same prefix is advertised by another router, and the router
      doesn't own that prefix.

9.1.3.  Extending prefix lifetime

   Routers MUST regularly extend the valid and preferred lifetimes of
   the ULA delegated prefix they advertise and own, so that they never
   drop to zero.

   When a router advertises a prefix it doesn't own, lifetimes are never
   extended.  When the preferred lifetime of the prefix approaches zero,
   either the owner of the prefix will start advertising the prefix with
   a non-zero preferred lifetime, or a new prefix will be generated.

9.1.4.  Authoritative ULAs

   This section doesn't prevent multiple ULA prefixes from existing
   simultaneously.  ULA prefixes may be provided by different means, as
   specified in Section 4.3.  Delegated prefixes that are delegated by a
   service provider or provisioned by an authority differ from
   'spontaneously' generated prefixes.  They MUST NOT be withdrawn if
   another ULA delegated prefix is observed.

   When at least one of such ULA prefixes is used, spontaneously
   generated ULA prefixes are withdrawned.



Le 20 oct. 2014 =E0 23:00, Ted Lemon  a =E9crit :

> On Oct 20, 2014, at 4:52 PM, James Woodyatt  wrote:
>> I did read what you wrote, and I do not agree that you are taking =
into account my concerns.  Nevertheless, I shall stop arguing my case, =
and I will accept that I've lost it.=20
>=20
> I persist in thinking that we are failing to communicate, but it would =
be a fair criticism to raise that this stuff is difficult to converge on =
in an email conversation, and a draft would be easier to discuss.  So I =
will try to write one up in my copious free time this week, and then we =
can probably converge.   I hesitate to write the draft because I am not =
convinced we will wind up actually doing what I am proposing, but it's =
probably worth it even if we don't actually proceed with it.
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


--Apple-Mail=_ED8B5977-52D5-4B5D-9D9F-A08135563F9B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


Hello,

I tried to make =
a proposal which would deal with these network splits.
Even =
though I must say that the PA draft in the first place did not cause any =
problem when network splits and joins later (collisions are dealt with). =
This adds quite a bunch of complexity, and provides the conceptually =
pleasant idea that splited home networks will end-up using different =
ULAs (even thought it=92s not a problem if they =
do).

So here it is:

9.1. =
 ULA Prefix Generation

  =
 ULA prefixes can be randomly generated as specified in =
[RFC4193],
   enabling =
stable in-home IPv6 connectivity.

  =
 In this section, we say a ULA delegated prefix is 'stable' if it =
has
   been the only =
advertised ULA delegated prefix for at least
   2*FLOODING_DELAY seconds.  The =
behaviour specified in the following
   sections tend to reuse a stable ULA prefix =
as long as its preferred
  =
 lifetime is not null.

  =
 Additionaly, we say a router is the owner of a =
spontaneously
  =
 generated ULA prefix if it randomly created the prefix in the =
first
   place. =
 A router SHOULD NOT create more than one prefix this way, =
and
   MUST remember =
all the prefixes they own.  As stated in the =
following
   sections, =
only the owner of a prefix can extend its =
lifetimes.

9.1.1. =
 Choosing the ULA prefix

  =
 When a stable ULA prefix is advertised, all routers SHOULD =
remember
   that =
prefix alongwith its associated valid and preferred =
lifetime.
   If this =
prefix stops being advertised (e.g. due to a network =
split)
   while its =
preferred lifetime is not null, the same ULA prefix =
SHOULD
   be selected =
using the same valid and preferred lifetimes.

  =
 If there was no stable ULA prefix advertised, or if the =
preferred
   lifetime =
of the prefix was null, a prefix generated as specified =
in
   [RFC4193] SHOULD =
be used.  In case the stable storage can't be =
used
   or the current =
date cannot be determined, the prefix MAY be =
pseudo-
   randomly =
generated based on hardware specific values.

9.1.2. =
 Advertising a ULA prefix

  =
 A router MAY start advertising a ULA prefix whenever the =
two
   following =
conditions are met:

  =
 o  It is the network leader.

  =
 o  There is no other advertised ULA =
prefix.

  =
 If no IPv6 prefix is available at all, the network leader =
SHOULD
   start =
advertising a ULA delegated prefix.

  =
 Additionaly, a router SHOULD start advertising its own ULA =
prefix
   whenever the =
three following conditions are met:

  =
 o  A stable ULA prefix is advertised by another =
router.

  =
 o  The router owns the advertised stable ULA =
prefix.

  =
 o  The preferred lifetime of the advertised ULA prefix is =
below 10
      =
minutes.

  =
 This allows a router to restart advertising a owned prefix =
whenever
   the =
preferred lifetime is approaching zero.  Which later allows =
him
   to extend the =
lifetime of the prefix.

  =
 A router MUST stop advertising a spontaenously generated ULA =
prefix
   whenever one =
of the two following condition is met:

  =
 o  A different ULA prefix is being =
advertised.

  =
 o  The same prefix is advertised by another router, and the =
router
      =
doesn't own that prefix.

9.1.3. =
 Extending prefix lifetime

  =
 Routers MUST regularly extend the valid and preferred lifetimes =
of
   the ULA =
delegated prefix they advertise and own, so that they =
never
   drop to =
zero.

   When a router advertises a prefix it =
doesn't own, lifetimes are never
   extended.  When the preferred =
lifetime of the prefix approaches zero,
   either the owner of the prefix will start =
advertising the prefix with
 =
  a non-zero preferred lifetime, or a new prefix will be =
generated.

9.1.4. =
 Authoritative ULAs

  =
 This section doesn't prevent multiple ULA prefixes from =
existing
  =
 simultaneously.  ULA prefixes may be provided by different =
means, as
   specified =
in Section 4.3.  Delegated prefixes that are delegated by =
a
   service provider =
or provisioned by an authority differ from
   'spontaneously' generated prefixes. =
 They MUST NOT be withdrawn if
   another ULA delegated prefix is =
observed.

  =
 When at least one of such ULA prefixes is used, =
spontaneously
  =
 generated ULA prefixes are =
withdrawned.



Le 20 oct. 2014 =E0 23:00, Ted Lemon <mellon@fugue.com> a =E9crit =
:

On Oct 20, 2014, at 4:52 PM, James Woodyatt <jhw@nestlabs.com> =
wrote:
I did read what you wrote, and I do =
not agree that you are taking into account my concerns. =
 Nevertheless, I shall stop arguing my case, and I will accept that =
I've lost it. 

I persist in thinking that we are =
failing to communicate, but it would be a fair criticism to raise that =
this stuff is difficult to converge on in an email conversation, and a =
draft would be easier to discuss.  So I will try to write one up in =
my copious free time this week, and then we can probably converge. =
  I hesitate to write the draft because I am not convinced we =
will wind up actually doing what I am proposing, but it's probably worth =
it even if we don't actually proceed with =
it.

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

=

--Apple-Mail=_ED8B5977-52D5-4B5D-9D9F-A08135563F9B--


From nobody Tue Oct 21 06:17:57 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5787E1A1BB5 for ; Tue, 21 Oct 2014 06:17:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.907
X-Spam-Level: 
X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWGvBr7qpu_W for ; Tue, 21 Oct 2014 06:17:47 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0194D1A1BB3 for ; Tue, 21 Oct 2014 06:17:36 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CC79320012; Tue, 21 Oct 2014 09:18:25 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 32AFD63A84; Tue, 21 Oct 2014 09:17:35 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1F2CF63A21; Tue, 21 Oct 2014 09:17:35 -0400 (EDT)
From: Michael Richardson 
To: Pierre Pfister 
In-Reply-To: <802A6061-3B41-4296-B739-E740DCF4873F@darou.fr>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>  <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com>    <1D269223-52B5-4B58-A46F-3B787EAFE4F3@fugue.com> <802A6061-3B41-4296-B739-E740DCF4873F@darou.fr>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/aKtXVv1evXV06Ovfv_Jb9UsymmM
Cc: James Woodyatt , HOMENET Working Group , Ted Lemon 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 13:17:49 -0000

--=-=-=


Pierre Pfister  wrote:
    > 9.1.2.  Advertising a ULA prefix

    >    A router MAY start advertising a ULA prefix whenever the two
    > following conditions are met:

    >    o It is the network leader.

    >    o There is no other advertised ULA prefix.

I am concerned about this part.

Consider a home automation LLN, installed at home construction time, and
therefore provisioned with a ULA by the installers.  There is gateway from
the LLN to the home network, which likely has a dangling cable until the
owner moves in.
It is useful for that cable to advertise a ULA that can be used by various
parties (installers, realtors, home owners camping on the living room floor
while wait for the moving van) to control the home.  We can argue about
whether or not this gateway will be an application layer gateway, or a
router into the Home LLN; I would claim that it will be both for a long time.

okay, so it seems that there is always an advertised ULA from the LLN.
Should the homenet use that one, or should it somehow know to ignore it for
addressing purposes (accepting routing for it, though), and create another
one?

Maybe the word "advertised" here is mis-understood.

Does it mean via Router Advertisements, or does it mean via HNCP? Probably
that's explained in some other part of the draft.   I think that the HNCP
would permit the network leader to *defend* it's ULA, not just advertise it.


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBVEZc7ICLcPvd0N1lAQLb4Qf9FEaJEhCNKqS/zzq1pMWahKt/ejMv8xI8
GzHmP6KkOAmFG+wqILoq5zSPwdo/+zy4UVoeIZp/5kLty3F0RuvD4v3JK45shzAH
7KoGOIOuFWGd9LkC6gAB+i+cUANY6pp6CayE4PDzoDh2tfa7KNfNZMrGrX/8lwqV
lJvcxDkxo9VUx1CzCwKYfs7XKT0LPuZ4/ux/O/4MuuzCZFxVPhnrp0+u3C3kLxyD
G0it+XrLpsq7ob342YHI79WxruZuC7JJtFc12lywTRrLAdedHp96JHibPGWTWCEG
QgBWgox9dF2KGH/FvilY7WxA4onbkOPAEmCZHJ2lbciQZxdwb75rSw==
=j7cw
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Tue Oct 21 10:12:34 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878A31A0B76 for ; Tue, 21 Oct 2014 10:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level: 
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKBlD3xhQUKG for ; Tue, 21 Oct 2014 10:12:16 -0700 (PDT)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 983E81A047A for ; Tue, 21 Oct 2014 10:11:47 -0700 (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 Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 31D39DA01AE for ; Tue, 21 Oct 2014 17:14:13 +0000 (UTC)
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 ESMTP id 70D5553E080 for ; Tue, 21 Oct 2014 10:11:17 -0700 (PDT)
Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 21 Oct 2014 10:11:17 -0700
From: Ted Lemon 
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 21 Oct 2014 13:11:15 -0400
References: <20141021160652.24101.60334.idtracker@ietfa.amsl.com>
To: HOMENET Working Group 
Message-ID: <4BBD7952-84F7-40F9-9034-8DD7A1F2A05C@nominum.com>
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/nPtqaWKwVojUEWEii1a-33mxAPE
Subject: [homenet] =?windows-1252?q?Fwd=3A_New_Liaison_Statement=2C_=22Bro?= =?windows-1252?q?adband_Forum_Work_on_=93Hybrid_Access_for_Broadband_Netw?= =?windows-1252?q?orks=94_=28WT-348=29=22?=
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 17:12:18 -0000

This work in the Broadband Forum might be worth paying attention to.

Begin forwarded message:

> From: Liaison Statement Management Tool 
> Subject: New Liaison Statement, "Broadband Forum Work on =93Hybrid =
Access for Broadband Networks=94 (WT-348)"
> Date: October 21, 2014 at 12:06:52 PM GMT-4
> To: The IETF Chair 
> Cc: , , =
, , The =
IESG , David Sinicrope , =
, , =

>=20
> Title: Broadband Forum Work on =93Hybrid Access for Broadband =
Networks=94 (WT-348)
> Submission Date: 2014-10-21
> URL of the IETF Web page: http://datatracker.ietf.org/liaison/1355/
>=20
> From: Broadband Forum (Christophe Alter )
> To: The IETF (The IETF Chair )
> Cc: The IESG ,David Sinicrope =
,christophe.alter@orange.com,david.i.allan@e=
ricsson.com,david.j.thorne@bt.com,sven.ooghe@alcatel-lucent.com,guiu.fabre=
gas@alcatel-lucent.com,rmersh@broadband-forum.org,gbingham@broadband-forum=
.org
> Response Contact:=20
> Technical Contact:=20
> Purpose: For information
>=20
> Body: Dear IETF and 3GPP colleagues,
>=20
> At the Broadband Forum Meeting held recently in Dublin, Ireland, the =
End to End Architecture
> Working Group has approved and begun work on a new project called =
=93WT-348 Hybrid Access for
> Broadband Networks=94 defining architectural requirements to allow =
coordinated and, when
> needed, simultaneous use of fixed broadband access and 3GPP access =
networks for
> converged operators.
>=20
> The business drivers for this work include enabling service providers =
to offer faster service
> provisioning and fulfillment, higher throughput and increased WAN =
reliability.
>=20
> We will keep you informed of this work as it progresses.
>=20
> The Broadband Forum=92s Q4 meeting will be held December 8 - 12, 2014 =
in Taipei, Taiwan.
>=20
> Sincerely,
> Christophe Alter,
> Broadband Forum Technical Committee Chair
> Attachments:
>=20
>    Broadband Forum Work on =93Hybrid Access for Broadband Networks=94 =
(WT-348)
>    =
https://datatracker.ietf.org/documents/LIAISON/liaison-2014-10-21-broadban=
d-forum-the-ietf-broadband-forum-work-on-hybrid-access-for-broadband-netwo=
rks-wt-348-attachment-1.pdf


From nobody Tue Oct 21 11:55:50 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3D01A8775 for ; Tue, 21 Oct 2014 11:55:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level: 
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIiUoNiiVbvW for ; Tue, 21 Oct 2014 11:55:46 -0700 (PDT)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA32D1A87DF for ; Tue, 21 Oct 2014 11:55:43 -0700 (PDT)
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id d2ca6445.0.3945207.00-2138.11113600.nbfkord-smmo05.seg.att.com (envelope-from );  Tue, 21 Oct 2014 18:55:44 +0000 (UTC)
X-MXL-Hash: 5446ac30270961d2-7a38c2b06822c7d227002d23a776ed21722e66b1
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9LItd37031483; Tue, 21 Oct 2014 14:55:40 -0400
Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9LItb0r031465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Oct 2014 14:55:38 -0400
Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi133.aldc.att.com (RSA Interceptor); Tue, 21 Oct 2014 18:55:28 GMT
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.152]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 14:55:28 -0400
From: "STARK, BARBARA H" 
To: Ted Lemon , HOMENET Working Group 
Thread-Topic: =?Windows-1252?Q?[homenet]_Fwd:_New_Liaison_Statement, _"Broadband_Forum_W?= =?Windows-1252?Q?ork_on_=93Hybrid_Access_for_Broadband_Networks=94_(WT-34?= =?Windows-1252?Q?8)"?=
Thread-Index: AQHP7VI5kR3vi6cq9ky1juC7e8Fpg5w65SRQ
Date: Tue, 21 Oct 2014 18:55:28 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E61130EA59FC@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <20141021160652.24101.60334.idtracker@ietfa.amsl.com> <4BBD7952-84F7-40F9-9034-8DD7A1F2A05C@nominum.com>
In-Reply-To: <4BBD7952-84F7-40F9-9034-8DD7A1F2A05C@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.198.73]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=MK7Xbrll c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=ofMgfj31e3cA:10 a=jPJDawAOAc8A:10 a=DqxaApEnIo0A:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=N659UExz7-8A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=0FD05c-RAAAA:8 a=gxZvrgisAAAA:8 ]
X-AnalysisOut: [a=mYPrF8hoAAAA:8 a=e9qsufxtAAAA:8 a=z9tbli-vAAAA:8 a=Rg5jO]
X-AnalysisOut: [eRUAAAA:8 a=sVqDmnacAAAA:8 a=OioCgzKtAAAA:8 a=32i_UN9tAAAA]
X-AnalysisOut: [:8 a=PNc3i3ZFKcnmjkBZ490A:9 a=pILNOxqGKmIA:10 a=IcfWiavFb3]
X-AnalysisOut: [IA:10 a=LsvIQ2l3lSoA:10 a=ZHPOVDayY2UA:10 a=lZB815dzVvQA:1]
X-AnalysisOut: [0 a=f7GxY0FH8QIA:10 a=3FZX-ydVlcEA:10 a=ft5PHLbN7jsA:10 a=]
X-AnalysisOut: [W1qU_X6G3J8A:10 a=oAXR_kdF8uMA:10 a=TogUlYArI9dHig6_:21 a=]
X-AnalysisOut: [VLH3H33wbECqmVxa:21]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.23]
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ZOb8HHpjcXqTEPICpEkr3wte4xQ
Subject: [homenet] =?windows-1252?q?=3D=3FWindows-1252=3FQ=3FRE=3A=5F=5FFw?= =?windows-1252?q?d=3A=5FNew=5FLiaison=5FStatement=2C_=5F=22Broadband=5FFo?= =?windows-1252?q?r=3F=3D_um_Work_on_=93Hybrid_Access_for_Broadband_Networ?= =?windows-1252?q?ks=94_=28WT-348=29=22?=
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 18:55:48 -0000

FYI. I made sure they were aware of IETF mif and homenet activities in this=
 area. I intend to try to prevent having to track efforts that try to do th=
e same thing in two different ways. But some of the BBF effort may be focus=
ed on what can be done around "bonding" of multiple interfaces that are und=
er the control of a single service provider. I don't see this in mif or hom=
enet.
Barbara

> -----Original Message-----
> From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of Ted
> Lemon
> Sent: Tuesday, October 21, 2014 1:11 PM
> To: HOMENET Working Group
> Subject: [homenet] Fwd: New Liaison Statement, "Broadband Forum Work
> on =93Hybrid Access for Broadband Networks=94 (WT-348)"
>=20
> This work in the Broadband Forum might be worth paying attention to.
>=20
> Begin forwarded message:
>=20
> > From: Liaison Statement Management Tool 
> > Subject: New Liaison Statement, "Broadband Forum Work on =93Hybrid
> Access for Broadband Networks=94 (WT-348)"
> > Date: October 21, 2014 at 12:06:52 PM GMT-4
> > To: The IETF Chair 
> > Cc: , ,
> > , ,
> > The IESG , David Sinicrope
> > , ,
> > , 
> >
> > Title: Broadband Forum Work on =93Hybrid Access for Broadband Networks=
=94
> > (WT-348) Submission Date: 2014-10-21 URL of the IETF Web page:
> > http://datatracker.ietf.org/liaison/1355/
> >
> > From: Broadband Forum (Christophe Alter
> )
> > To: The IETF (The IETF Chair )
> > Cc: The IESG ,David Sinicrope
> > ,christophe.alter@orange.com,david.i.all
> > an@ericsson.com,david.j.thorne@bt.com,sven.ooghe@alcatel-
> lucent.com,gu
> > iu.fabregas@alcatel-lucent.com,rmersh@broadband-
> forum.org,gbingham@bro
> > adband-forum.org
> > Response Contact:
> > Technical Contact:
> > Purpose: For information
> >
> > Body: Dear IETF and 3GPP colleagues,
> >
> > At the Broadband Forum Meeting held recently in Dublin, Ireland, the
> > End to End Architecture Working Group has approved and begun work on a
> > new project called =93WT-348 Hybrid Access for Broadband Networks=94
> > defining architectural requirements to allow coordinated and, when
> > needed, simultaneous use of fixed broadband access and 3GPP access
> networks for converged operators.
> >
> > The business drivers for this work include enabling service providers
> > to offer faster service provisioning and fulfillment, higher throughput=
 and
> increased WAN reliability.
> >
> > We will keep you informed of this work as it progresses.
> >
> > The Broadband Forum=92s Q4 meeting will be held December 8 - 12, 2014 i=
n
> Taipei, Taiwan.
> >
> > Sincerely,
> > Christophe Alter,
> > Broadband Forum Technical Committee Chair
> > Attachments:
> >
> >    Broadband Forum Work on =93Hybrid Access for Broadband Networks=94
> (WT-348)
> >
> > https://datatracker.ietf.org/documents/LIAISON/liaison-2014-10-21-broa
> > dband-forum-the-ietf-broadband-forum-work-on-hybrid-access-for-
> broadba
> > nd-networks-wt-348-attachment-1.pdf
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From nobody Tue Oct 21 12:06:11 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542F21A88B5 for ; Tue, 21 Oct 2014 12:06:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level: 
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWL7VDhjloI4 for ; Tue, 21 Oct 2014 12:06:04 -0700 (PDT)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B611A88F3 for ; Tue, 21 Oct 2014 12:05:34 -0700 (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 Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 4A2DFDA01B5 for ; Tue, 21 Oct 2014 19:08:00 +0000 (UTC)
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 ESMTP id 010A053E080; Tue, 21 Oct 2014 12:05:04 -0700 (PDT)
Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 21 Oct 2014 12:05:04 -0700
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130EA59FC@GAALPA1MSGUSRBF.ITServices.sbc.com>
Date: Tue, 21 Oct 2014 15:04:57 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <20141021160652.24101.60334.idtracker@ietfa.amsl.com> <4BBD7952-84F7-40F9-9034-8DD7A1F2A05C@nominum.com> <2D09D61DDFA73D4C884805CC7865E61130EA59FC@GAALPA1MSGUSRBF.ITServices.sbc.com>
To: "STARK, BARBARA H" 
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/mo4rk1fkdGFjQsRjTy9YktkhEn4
Cc: HOMENET Working Group 
Subject: Re: [homenet] =?windows-1252?q?Fwd=3A_New_Liaison_Statement=2C_=22Bro?= =?windows-1252?q?adband_Forum_Work_on_=93Hybrid_Access_for_Broadband_Netw?= =?windows-1252?q?orks=94_=28WT-348=29=22?=
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Oct 2014 19:06:05 -0000

On Oct 21, 2014, at 2:55 PM, STARK, BARBARA H  wrote:
> FYI. I made sure they were aware of IETF mif and homenet activities in =
this area. I intend to try to prevent having to track efforts that try =
to do the same thing in two different ways. But some of the BBF effort =
may be focused on what can be done around "bonding" of multiple =
interfaces that are under the control of a single service provider. I =
don't see this in mif or homenet.

Thanks.   I couldn't really tell what was being proposed from the =
Liaison statement, so this information is helpful.


From nobody Tue Oct 21 18:02:53 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4CD1A88B5 for ; Tue, 21 Oct 2014 18:02:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vZTJdO0Fr3x for ; Tue, 21 Oct 2014 18:02:49 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D399F1A88C7 for ; Tue, 21 Oct 2014 18:02:49 -0700 (PDT)
Received: by mail-pa0-f51.google.com with SMTP id lj1so2570739pab.10 for ; Tue, 21 Oct 2014 18:02:49 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=E1QGXNBEQ1LBx787fyHPUlgfP3a/c3gyxV37alP4P6E=; b=LrDwDv1q+j0vwnNKX/gsfYuxIS8GGM0IceUGkZp9OCW/ETcw9hfmcawLQ1SZwXV7D7 DsksMyAS8gFEyIsETATV3m0rRZ8FaUstYdE9r0oJk0+AUvIrhhhw2MGdhFZ2ip54dDxT qg411F5rMC7belttDCOaFWKKG9dCzZ2Y0pFheq6PQOd6tv90IHTRvlxhOCP2mfC+SD54 tAIaIfEl99aziXAeCMMyEyikKjpRM8EQeQH9mkSoxSO58tG24Oav4Kce/Wmpcj3MOjV/ Q7MhCQr4jegEuUhIoJKRFc7IVH91IrLxfBD61rD3MRldbHTdR7nmcMWulcDG/4PUv3PJ ZY+Q==
X-Received: by 10.70.43.168 with SMTP id x8mr31426003pdl.107.1413939769448; Tue, 21 Oct 2014 18:02:49 -0700 (PDT)
Received: from [192.168.178.23] (176.199.69.111.dynamic.snap.net.nz. [111.69.199.176]) by mx.google.com with ESMTPSA id c8sm13116945pat.6.2014.10.21.18.02.46 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 18:02:47 -0700 (PDT)
Message-ID: <5447023B.4030104@gmail.com>
Date: Wed, 22 Oct 2014 14:02:51 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: homenet@ietf.org
References: <20141014071141.5753.35124.idtracker@ietfa.amsl.com>
In-Reply-To: <20141014071141.5753.35124.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/dFM6O9RHAMay08Q0YhKJ69iYKKM
Subject: Re: [homenet] I-D Action: draft-barth-homenet-hncp-security-trust-01.txt
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 01:02:51 -0000

Hi,

I agree with whoever it was that said there is not enough explanation
of the threat model in this draft. The result is that I really can't
evaluate whether the proposed solution is complete or adequate.

The other thing that bothers me is that we need a secure homenet, not
just a secure HNCP. Protecting HNCP will be pointless if the network
is insecure for other reasons. So, what we *really* needs is a full homenet
threat analysis. That is not to be found in the architecture RFC-to-be
and is not in the WG charter, but I think it should be.

Up one more level: the charter looks pretty out of date in general.

Regards
   Brian


From nobody Tue Oct 21 18:36:18 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F631A8978 for ; Tue, 21 Oct 2014 18:36:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nCuQSWd7axg for ; Tue, 21 Oct 2014 18:36:14 -0700 (PDT)
Received: from chi.subsignal.org (chi.subsignal.org [188.40.166.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6A42E1A896C for ; Tue, 21 Oct 2014 18:36:14 -0700 (PDT)
Received: from ccyx-yoga (55d4021f.access.ecotel.net [85.212.2.31]) by chi.subsignal.org (Postfix) with ESMTPSA id 5370B1BE006; Wed, 22 Oct 2014 03:36:59 +0200 (CEST)
Message-ID: <1413941713.1526.1.camel@openwrt.org>
From: Steven Barth 
To: Brian E Carpenter 
Date: Wed, 22 Oct 2014 03:35:13 +0200
In-Reply-To: <5447023B.4030104@gmail.com>
References: <20141014071141.5753.35124.idtracker@ietfa.amsl.com> <5447023B.4030104@gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.12.6-1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/hSkGB6YieZeaWSn8IgAYH1r18u4
Cc: homenet@ietf.org
Subject: Re: [homenet] I-D Action: draft-barth-homenet-hncp-security-trust-01.txt
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 01:36:16 -0000

> I agree with whoever it was that said there is not enough explanation
> of the threat model in this draft. The result is that I really can't
> evaluate whether the proposed solution is complete or adequate.
>From my point of view there are two vectors through which you can attack
HNCP - as mentioned. First is auto-border-discovery (if you happen to
use it) and second is attacking the protocol itself.

For #2 the effects of most of the attacks one can probably think of i.e.
spoofing, replay, ... as well as simply pretending to be an HNCP/IGP
pariticipating router (i.e. speak the protocols regularly) can both lead
to various forms of manipulation of the HNCP state. Since the algorithms
on top (at least the ones currently defined) are mostly distributed /
consensus-based in nature you can pretty much mess with the state
without attacking a specific router's HNCP traffic and by just
pretending to be a homenet router yourself.


Besides most standard end-to-end security solutions cover
authentication, encryption, replay protection etc. so should cover most
of the attack vectors on the unicast channel which leaves us with the
multicast channel which is explained in the draft. TBH replies like
"it's not what I expected" or "not enough explanation" doesn't really
help if you don't give an explanation or any other form of pointer on
how the draft can be improved or what is missing in your mind.



As for security of the homenet:

The draft briefly mentions securing other protocols like IGPs and the
issues with that and proposes that HNCP manages a PSK for them (since
thats what IGPs tend to support in terms of authentication).

Besides that I don't really want to cover the whole homenet in this
draft since this draft should probably be merged with the HNCP main
draft at some point. That doesn't me I'm against a separate generic
homenet threats draft if anyone volunteers to write one.


Cheers,

Steven




From nobody Wed Oct 22 00:20:08 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1AA1A8A99 for ; Wed, 22 Oct 2014 00:20:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.573
X-Spam-Level: **
X-Spam-Status: No, score=2.573 tagged_above=-999 required=5 tests=[BAYES_50=0.8, PLING_QUERY=0.994, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enStvy7p6ksW for ; Wed, 22 Oct 2014 00:20:02 -0700 (PDT)
Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.194]) by ietfa.amsl.com (Postfix) with ESMTP id E8A1F1A897B for ; Wed, 22 Oct 2014 00:20:01 -0700 (PDT)
Received: from poro.lan (80.220.64.126) by jenni2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 543C16C900B0F2B4; Wed, 22 Oct 2014 10:19:55 +0300
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Markus Stenberg 
In-Reply-To: <802A6061-3B41-4296-B739-E740DCF4873F@darou.fr>
Date: Wed, 22 Oct 2014 10:19:50 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <648DEA84-6A8F-4075-85B1-AD135719CFC0@iki.fi>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>  <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com>    <1D269223-52B5-4B58-A46F-3B787EAFE4F3@fugue.com> <802A6061-3B41-4296-B739-E740DCF4873F@darou.fr>
To: Pierre Pfister 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/LYoin3plJWgc_hY18egrOT0ZTjk
Cc: James Woodyatt , HOMENET Working Group , Markus Stenberg , Ted Lemon 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 07:20:04 -0000

TL;DR: I do not understand the reason for new text, and would vote =
against it.

I am probably being thick, but I can see three cases of ULAs in home =
network:

[1] something not from HNCP (e.g. from ISP, from some IoT gateway =
device, configuration, ..) that are essentially static from HNCP point =
of view, and just routable to,

[2] something not from HNCP (e.g. from ISP, from some IoT gateway =
device, configuration, ..) that also (partially) delegated to HNCP (also =
obviously routable to),

and

[3] HNCP generated (spontaneous) ULA (relatively dynamic), exactly 1 of =
them (or 0 if you buy the SHOULD argument which I do not).

My assertion:

Given HNCP generated one spans whole administrative domain, _and_ should =
not have routing anywhere outside it, it=92s uniqueness does not =
_matter_.=20

Therefore, what is the case for having to deal with ULA changing in case =
of network split/merge?

Case 1: Let us imagine split; I give one of my homenet routers to my =
neighbor. My neighbor winds up using same ULA. It has different owner, =
it does not talk with my network devices, and nobody knows they have =
same ULA nor cares if they do.

Case 2: Eventually, my neighbor gives the router back to me. I give it =
either physical access (wire) or appropriate wireless credentials. =
Again, it does not matter it has the same ULA, as long as the /64s it =
has assigned on it=92s interfaces do not conflict what is in the rest of =
the network, and given it is [3] prefix, HNCP should take care of it.
(Hell, even [2] type prefix would be fine too in this case).

Only case where having same ULA in multiple places would matter, if you =
plan to route traffic between those places. Due to that, [3] case MUST =
NOT conflict with whatever comes from [1]/[2], but within [3] type, it =
does not matter at all. Internal is internal.

However, the case 2 looks much different if the ULA prefixes in the =
merge are different. Then you have to renumber either devices connected =
to the added router, or to the rest of the homenet. Due to that, I would =
advocate clearing ULA state before doing the merge to prevent wrong side =
of the fence winning the ULA allocation arms race. And having 2 ULAs in =
a home network as result of that is just wrong, from my point of view. =
Still, renumbering devices connected to router being added to your =
homenet sounds perfectly acceptable in case the ULA is of type [3]. If =
it is [1]/[2], just more than one ULA is also fine so it would not be =
applicable here anyway.

I have not looked at the draft text, but expressing these ideas should =
not be hard. The new text I strongly disagree with.

Cheers,

-Markus=


From nobody Wed Oct 22 02:49:01 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1274F1A8F4C; Wed, 22 Oct 2014 02:49:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level: 
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-YAkwJ0e9yZ; Wed, 22 Oct 2014 02:48:58 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B231A8F3E; Wed, 22 Oct 2014 02:48:56 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNX59050; Wed, 22 Oct 2014 09:48:55 +0000 (GMT)
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Oct 2014 10:48:38 +0100
Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.168]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 22 Oct 2014 17:48:25 +0800
From: Xueli 
To: Ted Lemon , "STARK, BARBARA H" 
Thread-Topic: =?Windows-1252?Q?[homenet]_Fwd:_New_Liaison_Statement, _"Broadband_Forum_W?= =?Windows-1252?Q?ork_on_=93Hybrid_Access_for_Broadband_Networks=94_(WT-34?= =?Windows-1252?Q?8)"?=
Thread-Index: AQHP7WIcOm96HPXJ7U2H19EDbAXxJpw7zesg
Date: Wed, 22 Oct 2014 09:48:25 +0000
Message-ID: <01FE63842C181246BBE4CF183BD159B4490350AD@nkgeml504-mbx.china.huawei.com>
References: <20141021160652.24101.60334.idtracker@ietfa.amsl.com> <4BBD7952-84F7-40F9-9034-8DD7A1F2A05C@nominum.com> <2D09D61DDFA73D4C884805CC7865E61130EA59FC@GAALPA1MSGUSRBF.ITServices.sbc.com> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.97.86]
Content-Type: multipart/related; boundary="_004_01FE63842C181246BBE4CF183BD159B4490350ADnkgeml504mbxchi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/fOIr7w74JKCBgotpC25Bl3I0tiQ
Cc: HOMENET Working Group , "mif@ietf.org" 
Subject: [homenet] =?windows-1252?q?=3D=3FWindows-1252=3FQ=3FRE=3A=5F=5FFw?= =?windows-1252?q?d=3A=5FNew=5FLiaison=5FStatement=2C_=5F=22Broadband=5FFo?= =?windows-1252?q?r=3F=3D_um_Work_on_=93Hybrid_Access_for_Broadband_Networ?= =?windows-1252?q?ks=94_=28WT-348=29=22?=
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 09:49:00 -0000

--_004_01FE63842C181246BBE4CF183BD159B4490350ADnkgeml504mbxchi_
Content-Type: multipart/alternative;
	boundary="_000_01FE63842C181246BBE4CF183BD159B4490350ADnkgeml504mbxchi_"

--_000_01FE63842C181246BBE4CF183BD159B4490350ADnkgeml504mbxchi_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hello



Thanks Barbara to send this liaison out.

Hybrid Access network is that Residential gateway (RG, or CPE) is extended =
with more than two access lines

(e.g. DSL + LTE) in order to provide higher bandwidth for the customers. Th=
e scenario and architecture are shown as follows

[cid:image002.jpg@01CF9A07.BF8CD480]



Right now, we have two individual drafts, one for architecture and requirem=
ents, and the other one is for an optional solution.

The draft (http://tools.ietf.org/html/draft-lhwxz-hybrid-access-network-arc=
hitecture-00 ; ) proposes the architecture and gap analysis.

The solution draft proposes one option for the solutions, http://tools.ietf=
.org/html/draft-heileyli-gre-notifications-00

We did not combine them as one draft, because we believe there may be other=
 candidates, and we would like to have further discussions in the related g=
roups and IETF.

We used to present it in Homenet in Toronto.



Now the authors have invited Orange to join this architecture work. We will=
 send out the new version of these drafts soon.

We are glad to invite the experts for comments.



Best Regards

Li Xue on the co-authors behalf





-----Original Message-----

From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of Ted Lemon

Sent: Wednesday, October 22, 2014 3:05 AM

To: STARK, BARBARA H

Cc: HOMENET Working Group

Subject: Re: [homenet] Fwd: New Liaison Statement, "Broadband Forum Work on=
 =93Hybrid Access for Broadband Networks=94 (WT-348)"



On Oct 21, 2014, at 2:55 PM, STARK, BARBARA H  wrote:

> FYI. I made sure they were aware of IETF mif and homenet activities in th=
is area. I intend to try to prevent having to track efforts that try to do =
the same thing in two different ways. But some of the BBF effort may be foc=
used on what can be done around "bonding" of multiple interfaces that are u=
nder the control of a single service provider. I don't see this in mif or h=
omenet.



Thanks.   I couldn't really tell what was being proposed from the Liaison s=
tatement, so this information is helpful.



_______________________________________________

homenet mailing list

homenet@ietf.org

https://www.ietf.org/mailman/listinfo/homenet

--_000_01FE63842C181246BBE4CF183BD159B4490350ADnkgeml504mbxchi_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable











Hello 


 


Thanks Barbara to send this =
liaison out.


Hybrid Access network is tha=
t Residential gateway (RG, or CPE) is extended with more than two access li=
nes



(e.g. DSL + LTE) in orde=
r to provide higher bandwidth for the customers. The scenario and architect=
ure are shown as follows



3D"cid:image002.jpg@01CF9A07.BF8CD480"=



 


Right now, we have two indiv=
idual drafts, one for architecture and requirements, and the other one is f=
or an optional solution.


The draft (htt=
p://tools.ietf.org/html/draft-lhwxz-hybrid-access-network-architecture-00 ; ) proposes the architecture and gap
 analysis.


The solution draft proposes =
one option for the solutions,
=
http://tools.ietf.org/html/draft-heileyli-gre-notifications-00  


We did not combine them as o=
ne draft, because we believe there may be other candidates, and we would li=
ke to have further discussions in the related groups and IETF.


We used to present it in Hom=
enet in Toronto.



 


Now the authors have invited=
 Orange to join this architecture work. We will send out the new version of=
 these drafts soon.


We are glad to invite the ex=
perts for comments.


 


Best Regards


Li Xue on the co-authors beh=
alf


 


 


-----Original Message-----


From: homenet [mailto:homene=
t-bounces@ietf.org] On Behalf Of Ted Lemon


Sent: Wednesday, October 22,=
 2014 3:05 AM


To: STARK, BARBARA H


Cc: HOMENET Working Group


Subject: Re: [homenet] Fwd: =
New Liaison Statement, "Broadband Forum Work on
=
=93Hybrid Access for Broadband Networks<=
span lang=3D"EN-US" style=3D"font-family:"Courier New"">=94 (WT-348)"


 


On Oct 21, 2014, at 2:55 PM,=
 STARK, BARBARA H <bs7652@att.com> wrote:


> FYI. I made sure they w=
ere aware of IETF mif and homenet activities in this area. I intend to try =
to prevent having to track efforts that try to do the same thing in two dif=
ferent ways. But some of the BBF effort
 may be focused on what can be done around "bonding" of multiple =
interfaces that are under the control of a single service provider. I don't=
 see this in mif or homenet.


 


Thanks.   I couldn=
't really tell what was being proposed from the Liaison statement, so this =
information is helpful.


 


____________________________=
___________________


homenet mailing list


homenet@ietf.org<=
/span>


https://www.ietf.org/mailman=
/listinfo/homenet






--_000_01FE63842C181246BBE4CF183BD159B4490350ADnkgeml504mbxchi_--

--_004_01FE63842C181246BBE4CF183BD159B4490350ADnkgeml504mbxchi_
Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=9036;
	creation-date="Wed, 22 Oct 2014 09:48:24 GMT";
	modification-date="Wed, 22 Oct 2014 09:48:24 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf
IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7
Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCADWAawDASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0uiii
uc4gooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKbHLHMgeJ1dCSAynI
4OD+tADqrXNxdxSBbfT2uVIyWEyJg+mGqzRQBUmub2NwItMeZSoJYXCLg9xgntSy3N4k+yPTWlj4
/eCdF+vBOeKtUUAVXubxbny101ni3Aed56AY9duc0fabz7V5f9mt5O7HneemMeu3Ofwq1RQBVjub
xrny301o4skecZ0Ix67Qc1aoooAKKRmVELsQqqMknoBQrBlDKQQRkEdCKAFooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKaZYxMs
JdRIylgmeSBjJ/UfnTqACiiigAooooAKKbHLHMpaJ1cBipKnOCDgj8DTqACiio7idLa2luJM7IkL
tgZOAMmgCrq9xJFaCC3OLm6YQw/7JPVv+AjJ/CrVtbxWltFbQLtiiUIo9hTl2SqkoUHIypI5AI/S
nUAFFFFABRRRQAUUUUAFFFFABgEYIBB6g96zdIP2V59JdiTaENDnq0Lfd/LlfwFaVJsXfv2jfjG7
HOPTNAxaKbHLHMC0bq4VipKnOCDgj8DTqBBRRUVxdRWvleaSBLIIlbHAY9M+men1IoAlooooAKKK
KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAMubRjLrcV/
9su1RYnUotww5LKQAP7vByPpVoWCi6+0fa7zO7d5ZuG8v6bemPale7K6pDZbARJC8u/PTaVGMf8A
Av0qzQN3Ksdgsdx5/wBrvWOSdj3DFP8AvnpiiHT1hmMgu7185+WS4Zl59qtUUAVIdPWBmYXl9JuU
riW5ZgM9xnofeiLTliVx9svn3rty9yzFfceh96t0UAZuj6S2mJKHuZ5mklkcB5mdQGYkcHv6mtKq
1hdm9hkkKBNk0kWAc52sVz+OKsM6ou52VR6scChg9xaq6qjSaPexopZ2t5AqgZJJU4FLaaha3tlH
dxSqI5FDDcwBGfXng064vre1tJbp5UMcSMxKsDnAyQOetDBaMfbgrawgjBEagg9uKkpkM0c8SyxO
GVgDkEGn03uIKKKKQBRVNr24GrLYi0BjaMyed53YHH3cep9ap3Wt3kFzLEmjvKqGTa3nhWkCAEkL
t/2uOecUDszYorHGuXDahLaR6crmKbyyBcjeRhSWCbegDAnn1rYoCwUUUUCCmyx+bE0Zd03DG5G2
sPoe1OooAytN0U2UFxG97dsZpZGBFyx2hmyCPRvU1aTTlSF4vtl8wfHztcsWXHoe1Osbs3kUrlAn
lzyRYBznaxGfxxVmgbvcqDTlW3aH7ZfEMwO83LFx7Buw9qSTTIpdOmsZJp5VmBG+aUuynsQT6HBq
5RQFytp089xYxtdRmO4XKSgjGWBwSPY9R9as1Wvbz7Ebd3TMMkojkfP+r3cKfpnA/GrNAgooooAK
KytV1w6XqFjamykmF5JsDq6AA4Pqw74HPHPrxRf64bHWrLTTZSSfa9wEgdAAQM9Cc+vX04zTsOzN
WisqfXDB4ht9INnI3nxs6yh0xxjtuz0z78cA0f24R4kGjGzkBMPmCbemOuOmc9OfX2xzSsFjVorK
g1wzeIp9HNlIhiiEnml0IIJOeA2fT355ArVoBqwUUUUCCiiigAooooAKKKbLIsMTSPu2qMnapY/g
ByaAHUVl6drsN9bTTNFOnkyOpAt5OQrlRjK8n2HSrKapbPA8wW42RkA5tZA3PopXJ/Cgdi3RVQap
bG3acLcbFbaQbWTdn/d25x74o/tO2FsLjbcbC23H2WTdn/d25x74xQBborL1LXYbHSJL9IpnwpKK
1vIMkHuNuQPc1oQTx3MQljDhScfvI2Q/kwBoCxJRRRQIKKKKAKklrI2swXY2+VHbyRtzzlmUjj/g
Jq3VOS4lXW7e2DfuntpHZcdWDIBz+Jq5R0GwooooEFFQXzyRWFxLCwSSOJmRmXcAQCenesrRdUur
uBru4uhLAsfzoLRo5A+FPyryWXDelCHbS5o6ZayWlvKku3L3Esgwc8M5I/Q1YlhiuIzHPFHKh6rI
oYH8DWdp2uw31vPK0U6eTJIpAt5OVVioIyvJ9hzVldUtngeYLc7EIBzayhufQbcn8KGDvcZZaNp9
lp8dktpA8aKAd0K/OR0JGME0650iwubCWyNpAkUisMLCuFJGNwGMZ96Zouqpq+nRXIjeN2QM6tG6
gE+hYDP4Vfpu99Qu0yK2tYLOBYbeKOJFA4RAoJx1wO9S1S1S5lsoortDmCKQfaFxn92eCw/3SQfp
mrtIQUUUUAZl7YahPetPb3dtEhgaEK8DMwB5JyHHP4U5dPu47mwdbqIx2kPlMHiYvJkAE53cdPQ1
o0UDuYb6DdnULm7iu7WKS4k3eatu3mouFBUNv54UdR3Nbp5JOMUlFAN3CiiigQUUVStLia71C7ZX
H2SAiFAAPnkHLtn24X8DQA7TbaS1hmSXbl7mWQYOeGYkfoat0UUAFFFFAEV1bR3lrLbTDMcqFWx7
96bYi6WyiW9Km4VdrspyGI43fj1/Gp6KACisnxBdataW8L6VEkrGVfMUxM52A5bofTPue1M1u71i
2NkdPjilDSL9o/cu2F6MeD05HHX9aaQ7Gu0UbnLxox6ZZQe+f580NFG7b2jRm4+YqCeOnNOGcc4z
3x0opCGmKMvvMaF8g7iozkdOfxP50eVHv3+Wm/Od20ZzjHX6cU6igBoijD7xGgfJO4KM89efwH5U
6isfT7rWJNevILuOMWSgGCRYWXcRwwBJ9cdevagZsUVkaRdavPqV9FqEca26MDbusLLvGMHBJ9Qe
vPIPStegHoFFFFAgooooAKKKB1oAZFBHboUiQIpYuQPUnJP4k0+s/RGZrKUsxJ+1zjk5/wCWjVoU
De4UUUUCGTwR3ULwTIJI5BhlPcU/rWf4gZl8P3zKxUiLgg4I5FaJ60DEooooEFFFFAEDWgfUYr3e
QY4ni244O4qc5/4DU9Z8rN/wkdqu47TaSkjPGdyVoUdBsKKKKBEdxAtzbSQOXVJUKMUbBweDg9qq
Wej29lPHMk11K0UZjj86beEU4zj/AL5H5VfooGMigjt1KRIEDMXIHdmOSfxJp+az9FZmtJyzE4vJ
xyc8eY1aFAPcZBDFbQJBCgSKMbUUdAKfRRQIbIiSxtHIoZHUqynoQeoqKytms7KK2aZpvKXaHYYJ
A6Z/DAqeigAooqtcz3sTgW1gLlSOWNwseD6YINAFmiqk1xfo4EOmrMpAJY3Kpg9xgj9aWW4vkn2R
acssfH7z7Sq/XjFAFqiqr3F8tz5aacrw7sed9pUceu3Gfwo8+++1eX/Z6+Tux532lenrtxn8KALV
FVY7i+a52PpypDkjzftKnj124zVqgBHDFGCNsYggNjOD61DZWkdjZRWsWSsa4yerHqSfcnJ/Gp6K
ACiiigAooooAKKKy/EOn32o6d5Gn3T2828HeJNo4OeeDnpjt1oGjUopkKskEauzM4Ubi7BjnvkgD
P5U+gQUUUUAFFFFABRRRQAUUEZBGSM9x1FZGhadqFjNetfXUk6zy+ZEHlD7AeoPyjnjr056cUDNe
iiigQUUUUAFFFKOtAFWBrK1tneKWJIRK5d2k+UOWO7JP+1mpVubdy4W4ibyxl8SA7B6n0/Guduhv
8H6igQuzXUwULEZDnzz/AAjrUTwSvfX7TRtdxrcW0k/l2jRiWJVOQFOd+CQSM9ulNIu2504uIGg8
9Z4jCBnzQ4Kfn0prXtmkayteW6xscK5mUKfoc81gXKQSC6njt7mCzmnhMZjtiw8xckyGLGdn3QeO
cfjTZLW2fQry4msU3q0wgaK1dfOLqAX8rBIJxj8M96LCsdA62upWbxb47iCUbWMb5B9sip6w9SsJ
JvD9wujEQm5BkaPyDmRjgcAldvStF4NRMSKuowiQZ3P9kyG9ON/H50CLdFVJYNQZIxFfxRsFw7G1
3bz6gbhj6c0TQag2zyb+KPCgNutd24+v3hj6UgLdFVJodQeQGG/iiXAyrWu8k9zncKWWG/afdFfR
Rxcfuzbbj7/NuH8qBExt4muUuSv71EKK2eikgkfoKkrIns9UfxDDcR3aLbLBIvNvnbllIUndyTg8
47VsDrR0GyL7RB5xh8+LzR1j3jcPw601L2zlLCO8t3KDLBZVO0dycHgVj6fHaRiztbrTXl1CCYu0
gtz8r5OZfM6EHPqTzjFVdLthPJPI0ccUNrdTzgC1dZXDFwASRgqQc4Ge1Mdjooby0uHKQXdvMwGS
scqscfQGpq5XwsRF9jhlgMk3k7UcWjw/ZlCDcrZGCSR611VDVmJqxBaJbJE4tSpQyuW2tn5yx3fr
mp6ztD/485/+vy4/9GNWjSB7sKKKKBBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUANll
jgiaWV1jjUZZmOABTqoa1o9vrmnPY3OBG55bYCwHfbnoferNpbraWcVuu3ESBcqgUH3wOBmgZNUU
13a2zBbi6ghJGQJJVUkfialrG8QSWyyaeJoGlZLpJGK2zSbUG7JJCmhbglc2RyARyDyCKaJEMpiD
AyKoYr3AOQD9OD+Vc1rCE3upTxNfB4rON4FiEoTzcnBAAwTjaMfmKmuYLKPxC19cW124ntozE0Ql
O5wzZGFOBwV4OB+tOw7HRYOM44owfSuWlXUF1mVpJCk5ucxMEnbMWRgAL+7xjIOe+asxJbzeJ7tX
mvlXdGYUHmrH5gzuOcY9BjOKLCsdBg+lGD6da5WyDQXNvNE98ZJL+eMiUSlViw20EEYC52kE+vWn
aJHerfwJcyMJiGF2u2clzjnJb5Bz0K/hRYbVjpY5Emj8yJw6ZI3KcjIOD+op1YHh23tbHNqttdJd
K8ocuJSirvJHLHbyCMYredFkRkdQysCCGGQR7ikxPcSOWOZS0Tq4DFSVOcEHBH4GnVmaJoVvoUc6
QMrefJ5jHywpBPUcds5IHbNadABRRRQIKKKB1oAhtLmK5iaSFSqrI6HIx8ysQf1BqbNUdHikhs5V
lRkY3MzAMMZBkYg/iKvUDe4uT60ZNJRQIhvLqOytJbqbcY4l3NtGTipqoa5FJPod5FCjSSPHhVUZ
JORWgetA+glFFFAgooooAha6jW9jtDu8ySNpBxxhSAf/AEIVNVGWKQ6/bTBGMa2sql8cAlkwP0P5
VeoGGaXJ9aSigQuT60lFFAEFpcxXUTvCpVVleM5GPmViD+oqeqOjxSQ2syyoyE3UzAMMZBkJB/EV
eoG9wooooEFFFFABRRVa5sI7pw7zXSEDGIbh4x+SkUAWaKqTadFO4dp7tSABiO6kQcewPX3pZdOi
mn85p7tW4+VLl1Xj/ZBxQBaoqq+nxPc/aDNdhsg7VuXCf98g4x7Uf2fF9q+0eddbt27b9pfZ/wB8
5xj2oAtUVVj0+KO588T3ZbJO1rl2T/vknGKtUAFFFFABRRRQAUUUUAFU9U1az0e2FxeyMiFgowhb
qQO31q5UF7Y22o25t7uPzYiclCxAP1x1/wAaBq3UljkSaNZIzlHGVOCMj6Gn5I701V2qFBJCgDJO
T+feloELk+tGaSigAzS5PrSUUALk+tJmiigALbVJJ4Ayao6drNjqrzpZys7W7lHDIy4Ix6j3q9Va
00+2sXle3jKNO26Qlyd7f3jk9ff6elA+hZooooEFFFFABSM6opd3VFHVmOAPxpaRlV1Kuqup6qwy
D+FAFSz1WyvYZJY7iILG7I2ZF42sVz16Ejipxd2rI0i3UBRfvMJVIH1OeKhtNKsrKGSKK3iKyOzt
mNedzFsdOgJ4qYWlqqNGtrAEb7yiJQD9RjmgegC7tTGZBdQGMHBfzV2g+mc0fa7Xy/M+1QeXnG/z
V259M5oFpaiMxi1gCE5KeUu0n1xij7Ja+X5f2WDy852eUu3PrjFAEF7qtlY2D3klxE0SAkbZF+bH
Yc8mrUckcqb4pEkU/wASMGH5iq17pVnfWL2ckEaxOCBtjUbc9xxxVmOOOJdkUaRqP4UUKPyFADqK
KKBBRRRQBWe7ZdVhstgKyQPKWzyCpUY/8eqzVSS1kbWILsFfLjt5IyM85ZlI/wDQTVugYUUUUCI7
iR4raWVEDsiFgpbaDgZxnBxVCy1eSUW5vbaO0W5h82JxPvXAAJDEgYOCD6dav3Eby20sSOEZ0Khi
u4DIxnGRmqFlpMkIgF7cx3S20PlRIINi4IAJYEnJwB+tCHpYntNVsr2KSSO4iCxO6NmReNrbc9eh
xwamF5aMjSC7gKL95hKuB9TmorTSrKyikjit4isru7ZjXnc27HTpzwKmFpahCgtYAjfeURLg/UYo
DQj0/ULfU7OO6tpFZZFDbQwJXPY4PFWarafp9vplnHa20aqsahdwUAtjucDmrNNgMmmjt4JJ5W2x
xKXY+gAyajsZpriyhmuIhDJIu4xg5256A++MZ96j1G0e+WCDIFv5oecHq6ryF+hOM+wq2eTmkAUU
UUCCiiigAooooAKKKKAEffsbywC+DtDdM9s1Bp94t/Yx3IUozZDoeqODhlP0INWKp29rLbajdSIV
+zXAEm3PKy9GwPQgA/Ue9Ay5RRRQIKKKKACiiigDK17Wm0SCGYWhnWSVUYiRV2gnk8nsMnPQY5pu
s65JpBsv9BMoupVjb98g2Z+p7HHPTnrWsyK33lVu3IzQyI33kVuMcgHimPQUZxyMHuPSiiikIKKK
KACsmw1uS81y80xrIxfZQpEnmo27PXgH1446Z5xWtSBEByEUHnkDnnrQMytK1x9S1K+s2sjB9kcD
cZUbcCB6H13DjjjHWtakCIpyqKD0yABS0AwooooEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF
AFKSeVdct7YP+6e2kdlx1YMgB/U1dqBrRW1CK83kNHE0QXHBDEHP/jtT0DCiiigQUUUUAUtKuJbm
2meZ9zLczIDjoquQB+QqzcTrbxGVklcDtFGXb8hzTLO0WzieNXLh5XlJI6FmLEfrU9DG9zL03W1v
dIivpLa6VmVSypbSHk/3RjJHvTr3WEttJnvUtromNHKo1tIDkLnkYyB71fhhjt4UhhQRxoMKq9AK
WSNJonikUOjqVZT0IPBFNhpchsbtb21SYRyx7gMiSNkOcdgece9WKRVCqFUYAGAPQUtJiCiiigAo
pcH0pMUAFFLg+lJQAUUUUAFFFFAFLS55biCdpX3FbqZAcdFVyAPyq7UFnaLZxyIrlhJM8pJHQsxO
P1qegb3CiiigRBe3aWNlLdSDKxLnb3Y9h9ScD8aLFLmOyiW8k8y425lYDA3Hkgew6fhRdWaXcluZ
GOyCUS7OzsB8ufoefqBU9AwooooEZGrz6zFqNiNPVGtmf/SMwF9qnjJIYZ5IOBzwT0o1GbWY9cso
7NUaxbIuCYC23PQk7hnkHp0zk5rXop3HcyLifWV8SW8UKodNZCJW8gnaxwR8272YZxgZGc5o8/WB
4nEW1Dphi+95B4frjdu9O+MdsZrXoouFzIt5tZPiWeGZU/s3yx5biAj5hnIzu9CvOMHBxiteiikD
CiiigQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGRPeaoviGG3jtI2tmgkbm5xuwyjc
Rt4IyeM96uia/wDtWw2MQg3Y837T82PXbt/TNWqKBlWOa/a42SWMSQ5P7wXO447Hbt/rRDNqDTFZ
rGGOPn51udx9uNo/nVqigCpDNqLswnsIYgFJUrdb8nsPuDH1oin1Flcy6fChC5QC63bj6H5Bj681
booAytCutRuYpjfW6oFnlVXE288OQFxtHAHetWiigHuFU9YJGiX5BwRbScj/AHTVymTRRzwyQyru
jkUoy+oIwRQCdmJbf8ekP/XNf5CpKj3xQtFAWVS42xqT97A6D8KkpsQUUUUgOfv1szrN+0948DRW
aSJtumXY+W5C5xngcY5qrdXDSMZ7u5Z3jSDzI7e7MU1sxAJAj6Puzn1xkV0j2drJL5z2sDygg+Y0
SlvbnGac1tbvMJmt4WlU5EhjBYfjjNNOxVzHe6sNN1bU7uScnyoo2Mf2gtgnOcIWxnp2rcqBrCye
QyNZWzSE5LmFSxPrnFT0hMKKKKBBTZTIsTGJBI4HyqW2gn64OKdTPOi+0fZ/MXzdm/Z325xn6ZoA
y9JvNVntrlrizjLJPKsebnrhyAv3OAB3q4k2omF2ewhWUY2ILrIb1ydnH5GrdFA7lQTaibdmawhE
wYBY/tWQR67tnH0xTJ7+ez02W6urZI5U4jiSXzN7HhRnA5JIFXqjlgimaMyoGMTh0z2YdD+tAEWn
WjWNjHDI5kl5aVz/ABOTlj+ZqzRRQIKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAp6raPd2R8ji5hYTQH0deQPx5B9
jU1ndx31nFdRZCSruAPVT3B9wcj8KmoAA6AD6UDCiiigQUUUUAFFFFABRRRQAjMqIzuwVVBLE9gO
prP0dGmjl1KVCst6wdVPVIhwi/lz9WNaJGRgjIooGFFFFAgooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAqtc6fb3cgeUzggY/d3EkY/JSBVmigCpNpltcOHkNxlVCjZcyKMD2DD86WXTbaefznNxv4
+7cyKOPYNirVFAFV9Nt5Ln7Qxn8zIbi5kC5/3Q2PwxR/Ztv9q+05n8zdu/4+ZNuf93djHtirVFAF
WPTbeO5+0KZ9+SfmuZCvP+yWx+lWqKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAopHBMbBW2kg4YDOPeu
f8PXup6lGk73crGONTLHcWyxrIWTIKlQDgH8xQOx0NFY9pfyW+jtI0W+c3bwKplZlLmQqPmPIXP5
Dio21nUYZruKe0tR9llgRikrHeJDjI44xnoadgszcorJutWu7az1Wb7NC8mnyfKoZsSJtDenDYOP
Sm3usXtgkC3NtbxzXMhEfzO6ooGTu2rnd24496LBZmxRVTTL039mJmjMbBihGGAOO67gDg/Smarh
YUke+ntYlJBW3A8yVj91VPPOewHP0pAXqKzXm1e20u0P2WK6vC6JcK8ojCqfvNnoSPQde1aR60CC
iuc1rVr6yudTSGW4xDaxyQ+XarIsbEtkscdPl7+pq3e6vdWUt1b+TBJOgiNorMQbjedvPHGD6U7D
szYorAi1PUbT+0ZZY0ntLS7KO7ynzApCkhBjGFLd+TV1b7UX1e5so7S3MVuYy0xlIyrZ4Ax94Yz6
UWCxpUVmwTSJrV+k4AVII5FKSMRty/8ACeA3HOOv4VVS+1GfUtKldEhtLsOQscpJI2blDgjr0OR0
5FFgsblFMmZUgkdpPKVUJL4B2gDrzXNaJ4kd7K7kvbuO9eK3W6TytgYISRsO3jIIH/fVILHUUVly
3+p2UM017ZW5jWNShgmJzIWACHcOOv3ulR3mqalpkLve2lt8zpHC8Tuys7E5DDbuAGM8A5p2CxsU
VkQ6xdT6fcSw2YmnhdVARXVJAe43AMcDOQOeKI9Vv5NMedLFHuUn8poUL5Uf3ipAbOOdo7EUWCxr
0VU0y8kvrITTIkcm9lZEJO0g4wcgEH1HaotVlvYzB9l84Rkt5zwRCWRePlwp6jPU49KQWNCisi31
G8nitbe1e2vLh4DNJO4aOMgNt4UAkHPbtg1BceILu3m+zyWkUVxFCsk8bGR/mbOFQopHQdT607BZ
m9RWJd65ewyztFZRNbQWqXTNI7K+1s5Xbj73B9qk1HXBYXyxAwSpuRZEG/zFLHA5AKjqDgkcUWYW
Neisya+1IazLYW9pbyIkSS+a8pX5SSCpGPvccdvWnxyTf8JI8MgG1rXdGVkbGN+OVPGcnqO1ILGh
RWVDq1xJ9nuWt4hZXM3lRMHPmAkkKSMYwSOnUVq0AFFFFAgooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAR1DoyHOGGDg4P51WtdNtrOyNnAZlhxgAzuSo9AScj8KKKAIY9FtI
LWe3hjkdZskpNcSMpYnOckkg55yOahsdBEKXovVUm9ZGdUld8bRwd7fMTnnPGMDFFFMd3Yk/sDTv
IuINs+y6YNP/AKTJmQgYyTuz0/kKsNptu9ssDGZgjbkczuZFPqHzuH50UUguyW3t47WLy495GSxL
uXYk9ySSTUV5pttfSwzTeaJIM+W8czxlc9fukelFFAiOfRtPurKCzuIDLDbyLLGHkYkOpyDnOT+N
Xjyc0UUAUbjRrK6e5eZJSbpBHNiZwGUdBgHjv09TUUul3U+tWV5LHbG1sVfyiXZpSzADJyMevfvm
iimhj10LTluXuBC5eSXzZMzOVdx0LLnBx2z0wKlj0u2ivnvUM/nSHL5uHKtjplc44z6UUUguNi0m
1ivmvVNx57cMWuJCCOcDaTjHJ4x3piaHp8d1FcpE4kgYmL98+I89QozgA+nSiigLlq7tIb60ktbg
M0Uq7XVXKkj0yOagbSLJ5Y5ZI3kaKEwKHlYgoeoIJw2ff0oooC4R6PYxxyRmN5Ukj8tlmleQbPQb
icD6UJpFmsUkZWWQSABmlnd2GORgk5GDzxRRQFxH0aylgMMqzSgyLJue4dnDL90hicjFD6NYvAkL
RyEJL5yv5z79+Mbt+ck4OOtFFAXLNtbQ2kIhhUqoJJySxJPUknkn3NRXem217NFNMJBLCCEkilaN
lB6jKkegoooENfSLJ44UEbx+QpWNopWRlB6jcCCQepz3ofSbNljVVli8tPLBindCV9CQcn8aKKB3
GzaLYz+d5kcmJ4lhkAmcAoOgwDx+HqabcaFp9yWMscp3FWYCd1DMuMMQDywwOevFFFFwuSf2Xbf2
gb/M/ntgE/aH2kDoNucY5PGO9H9k2v8AaH2/Nx5/TP2mTGM5xtzjGe2KKKAFTS7OO6+0rGwcMXCm
RiiserBM4B68gdzVuiigQUUUUAFFFFABRRRQB//Z

--_004_01FE63842C181246BBE4CF183BD159B4490350ADnkgeml504mbxchi_--


From nobody Wed Oct 22 03:54:39 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A251A8FD6 for ; Wed, 22 Oct 2014 03:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level: 
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlQi9vPT402N for ; Wed, 22 Oct 2014 03:54:32 -0700 (PDT)
Received: from mx1.nominet.org.uk (mail.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0025A1A9040 for ; Wed, 22 Oct 2014 03:54:31 -0700 (PDT)
DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns;  h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=qAJrhHESQ21RyWMhTD+7D8OP7GPHC+fTChVcSyUWyxQlvvot+q8trdXZ RP/v3sgRNOUY0KrIUOzexKco4D1WX/rcCLxqieuZePAqKwr6o6B86fXb/ Us3yX6PP0LrRFvLzXl1YFgDTJk+Budr0w+CeBztDI7dW0WFUVOXMCcq30 1vKS7sNBxFsC9V5Zyfi9k7Sk4gY6DWeEvtw5u1YcoVLK8llD/R8+SUBCV F4ci6BDG/bJY4h7n49LrEI41HGPsY;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1413975272; x=1445511272; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CfqK+4zf2pPgOcyYVI0n+H3cbN2NghummNhEVX+rYTM=; b=MBU9gElAq4pnKU1lB7Q7u2yrDNCxauxDNlw3ewoOBE5Va9aczkY7yU6Z WQGg3JDjWN/KaGM3/BZCEH4IqlhzfyrzPIZoLX05LPrL3O/QLcZREA569 HiNfyyQt9AaSNAY+JbSQhau0AK0ZyxeQve7V+I+dthXdmenCX2EqcyMUN nSt5v902vKwft0JQP5s/RiZyq6s64b+mrkzw04uMcMiVvACcEbBoWi33F lNyE45L0bCB8kI5uaZBfPEhJ3cUeg;
X-IronPort-AV: E=Sophos;i="5.04,768,1406588400"; d="scan'208";a="14082323"
X-IPAS-Result: AhEFAKqMR1TV+MWR/2dsb2JhbABcgmsjgSwE1DECgQsWAQF8hAMBAQMBOhkmBQsCAQg2ECERJQIEDgWILAMJCQO/EA2GOAEBAQEGAQEBAQEBAQEBAQEXjiKCAjMHgy2BHgWbTJFdhl2DeGwBgUeBAwEBAQ
Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 22 Oct 2014 11:54:03 +0100
Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%16]) with mapi id 14.03.0181.006; Wed, 22 Oct 2014 11:54:02 +0100
From: Ray Bellis 
To: Brian E Carpenter 
Thread-Topic: [homenet] I-D Action: draft-barth-homenet-hncp-security-trust-01.txt
Thread-Index: AQHP7ZPt0ifQmmuEV0+vQGNJBpOJn5w74Q6A
Date: Wed, 22 Oct 2014 10:54:01 +0000
Message-ID: <7486C1B6-4CB2-4A06-884B-84C772A9B7A9@nominet.org.uk>
References: <20141014071141.5753.35124.idtracker@ietfa.amsl.com> <5447023B.4030104@gmail.com>
In-Reply-To: <5447023B.4030104@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.2.1]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <393F823B5725DD42BF61CF47F62FF7DF@okna.nominet.org.uk>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/WQlDSvSl4shTw9fSgVGHg92_9xM
Cc: "homenet@ietf.org" 
Subject: Re: [homenet] I-D Action: draft-barth-homenet-hncp-security-trust-01.txt
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 10:54:38 -0000

On 22 Oct 2014, at 02:02, Brian E Carpenter  w=
rote:

> Up one more level: the charter looks pretty out of date in general.

Hi Brian,

The charter itself still reflects our primary focus.  I believe it still ac=
curately reflects the constraints on our scope.

The milestones are admittedly completely out of date!  I hope that Mark and=
 I will be able to get some time with our AD in Honolulu to get those updat=
ed.

Ray


From nobody Wed Oct 22 09:29:04 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE77E1ACD42; Wed, 22 Oct 2014 09:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.1
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xk2Tkobiww9v; Wed, 22 Oct 2014 09:29:00 -0700 (PDT)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEB541AC417; Wed, 22 Oct 2014 09:28:59 -0700 (PDT)
Received: by mail-la0-f42.google.com with SMTP id gf13so3618655lab.29 for ; Wed, 22 Oct 2014 09:28:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=V9HQLAdS8ya5z3ymKsxztFUc2VdSOBbAv3VyKzmb114=; b=Iu3R1tHX5P5tR4fVfSrM5MATPT4DvQnrJ4FjnvGeur8+erOB7WBLvbun2dlPMZi3X8 9to0Q/tnbmgW937A6UuJGNKYD387VUvFMwtd7RiNj5taQyjE4vZyb1zkFH+qB25uNiFq dRMbcGHZyNzIHQm6wLOidKb0gbfiYAvliwBpLtj56ezWQJt7qaue1QH3Y3HrMxZA7ItC fGsIcaRF1Jwz5b3AUncmAGqviMD2ImpO4+lYaFyfKJCVKx/tEuSjYw8qDrldFvPDZHzT wUe6dRE41HObmZwMQo9dDrmiCUqchpbmluRQhn84Td5SJT22+9hO78z+l8hsoQyCiIWI YMcw==
X-Received: by 10.152.45.2 with SMTP id i2mr11928858lam.7.1413995338221; Wed, 22 Oct 2014 09:28:58 -0700 (PDT)
Received: from [192.168.101.244] (212-123-27-210.iFiber.telenet-ops.be. [212.123.27.210]) by mx.google.com with ESMTPSA id bn6sm4600139lbc.5.2014.10.22.09.28.42 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Oct 2014 09:28:57 -0700 (PDT)
Message-ID: <5447DB20.9080505@gmail.com>
Date: Wed, 22 Oct 2014 18:28:16 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Xueli , Ted Lemon ,  "STARK, BARBARA H" 
References: <20141021160652.24101.60334.idtracker@ietfa.amsl.com> <4BBD7952-84F7-40F9-9034-8DD7A1F2A05C@nominum.com> <2D09D61DDFA73D4C884805CC7865E61130EA59FC@GAALPA1MSGUSRBF.ITServices.sbc.com>  <01FE63842C181246BBE4CF183BD159B4490350AD@nkgeml504-mbx.china.huawei.com>
In-Reply-To: <01FE63842C181246BBE4CF183BD159B4490350AD@nkgeml504-mbx.china.huawei.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/UmJWNSf-HLNlg-WVsFCaOVKdKpw
Cc: HOMENET Working Group , "mif@ietf.org" 
Subject: Re: [homenet] =?windows-1252?q?=93Hybrid_Access_for_Broadband_Network?= =?windows-1252?q?s=94_=28WT-348=29?=
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 16:29:02 -0000

Hello Xueli,

Several people look at this problem as an IP problem.  Instead of 
considering a cellular+dsl combination in a homebox, they considered 
cellular+wifi on a smartphone.   But the goal was the same: augment the 
bandwidth perceived by the end user.

In implementation it is however quite challenging.  The more tempting 
the expectations of augmenting bandwidth by simply adding network 
interfaces (as in adding RAM to a busy computer), the higher the 
desillusion when facing the challenges of implementation.

Some consider it simply as a local computer policy problem (and hence no 
new communicaiton standards needed), but others consider that there is a 
need of a server in the infrastructure to which these interfaces would 
first connect (a sort of an 'anchor').

If such a technology is developped, it will surely be useful for more 
than homenets - it will be useful for multi-interfaced smartphones, 
useful for mobile routers installed in vehicles, and more that I can not 
think of.

Alex
PS: there are a few IETF Internet Drafts about how would smartphones 
would use this, with Mobile IPv4 and Mobile IPv6 extensions, but there 
are no widespread implementations.

Le 22/10/2014 11:48, Xueli a écrit :
> Hello
>
> Thanks Barbara to send this liaison out.
>
> Hybrid Access network is that Residential gateway (RG, or CPE) is
> extended with more than two access lines
>
> (e.g. DSL + LTE) in order to provide higher bandwidth for the
> customers. The scenario and architecture are shown as follows
>
> cid:image002.jpg@01CF9A07.BF8CD480
>
> Right now, we have two individual drafts, one for architecture and
> requirements, and the other one is for an optional solution.
>
> The draft
> (http://tools.ietf.org/html/draft-lhwxz-hybrid-access-network-architecture-00
>  ; ) proposes the architecture and gap analysis.
>
> The solution draft proposes one option for the solutions,
> http://tools.ietf.org/html/draft-heileyli-gre-notifications-00
>
> We did not combine them as one draft, because we believe there may be
>  other candidates, and we would like to have further discussions in
> the related groups and IETF.
>
> We used to present it in Homenet in Toronto.
>
> Now the authors have invited Orange to join this architecture work.
> We will send out the new version of these drafts soon.
>
> We are glad to invite the experts for comments.
>
> Best Regards
>
> Li Xue on the co-authors behalf
>
> -----Original Message-----
>
> From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of Ted
> Lemon
>
> Sent: Wednesday, October 22, 2014 3:05 AM
>
> To: STARK, BARBARA H
>
> Cc: HOMENET Working Group
>
> Subject: Re: [homenet] Fwd: New Liaison Statement, "Broadband Forum
> Work on “Hybrid Access for Broadband Networks”(WT-348)"
>
> On Oct 21, 2014, at 2:55 PM, STARK, BARBARA H 
> wrote:
>
>> FYI. I made sure they were aware of IETF mif and homenet activities
>> in this area. I intend to try to prevent having to track efforts
>> that try to do the same thing in two different ways. But some of
>> the BBF effort  may be focused on what can be done around "bonding"
>> of multiple
> interfaces that are under the control of a single service provider. I
>  don't see this in mif or homenet.
>
> Thanks.   I couldn't really tell what was being proposed from the
> Liaison statement, so this information is helpful.
>
> _______________________________________________
>
> homenet mailing list
>
> homenet@ietf.org
>
> https://www.ietf.org/mailman/listinfo/homenet
>
>
>
> _______________________________________________ homenet mailing list
> homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
>


From nobody Wed Oct 22 10:51:37 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1151ACEB6 for ; Wed, 22 Oct 2014 10:51:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.984
X-Spam-Level: 
X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izlq-BQl8BHi for ; Wed, 22 Oct 2014 10:51:34 -0700 (PDT)
Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE301ACE86 for ; Wed, 22 Oct 2014 10:51:06 -0700 (PDT)
Received: by mail-vc0-f174.google.com with SMTP id hq12so2261051vcb.5 for ; Wed, 22 Oct 2014 10:51:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5ySdrYVvyn/sSJXB1RNsyaMFPrB8qIhWesh3poJmMzA=; b=FHTZmIHAOex4OlJodAYMt2BnbbuREDSxLVnthLg4sUqyZVDqfdwc+p7y+Sion3N4GG pPiV/Amkebdomi2SItO2t5W+PV8Y/KvUPtjnbNiVhbzrOdUqFFtPYvHO3WQ4tYw07sAn zdOkGbkvAnOC9jf9EgsKnjsW/3Z7CL7027gNeIXcBkOykpqJyd0HhrJD1OzMG6+RVhZd KaS5PbFTXVFEoYfyDAAno4qgfgPmhQW3gKNwy/NEO6j8gLNpLWYHIvuOJ+LdDeg8UXDp M6D2ODF9BUn3tXXi9Nos2XV3c3tgK2QoNU+Gp9q4zhohlJ36tw5HCWeE2uj2qM45DVRg zNEA==
X-Gm-Message-State: ALoCoQnf/J+bt9UTIO4gHzuyKDTdE2K2euzaF203a3F+2Xo3zkjWf7AklJimD7VNdEYx/odu8/W6
MIME-Version: 1.0
X-Received: by 10.220.188.131 with SMTP id da3mr37555011vcb.10.1414000265574;  Wed, 22 Oct 2014 10:51:05 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Wed, 22 Oct 2014 10:51:05 -0700 (PDT)
In-Reply-To: <648DEA84-6A8F-4075-85B1-AD135719CFC0@iki.fi>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>  <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com>   <1D269223-52B5-4B58-A46F-3B787EAFE4F3@fugue.com> <802A6061-3B41-4296-B739-E740DCF4873F@darou.fr> <648DEA84-6A8F-4075-85B1-AD135719CFC0@iki.fi>
Date: Wed, 22 Oct 2014 10:51:05 -0700
Message-ID: 
From: James Woodyatt 
To: Markus Stenberg 
Content-Type: multipart/alternative; boundary=089e015379928acd00050606978c
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ZzuIHbbxMy_jE9PiR8eSixvRggo
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 17:51:35 -0000

--089e015379928acd00050606978c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 22, 2014 at 12:19 AM, Markus Stenberg 
wrote:

>
> My assertion:
>
> Given HNCP generated one spans whole administrative domain, _and_ should
> not have routing anywhere outside it, it=E2=80=99s uniqueness does not _m=
atter_.
>

Wait. Where did this "and should not be routable anywhere outside"
recommendation come from? And if it's only a recommendation and not a
requirement, then it still matters, right? I don't see that we can
meaningfully make it a requirement, and I would advise against attempting
to make it a recommendation. I don't believe such a recommendation will be
followed.


--=20
james woodyatt 
Nest Labs, Communications Engineering

--089e015379928acd00050606978c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On W=
ed, Oct 22, 2014 at 12:19 AM, Markus Stenberg <markus.stenberg@iki.fi=
> wrote:


My assertion:



Given HNCP generated one spans whole administrative domain, _and_ should no=
t have routing anywhere outside it, it=E2=80=99s uniqueness does not _matte=
r_.

Wait. Where did this "and shou=
ld not be routable anywhere outside" recommendation come from? And if =
it's only a recommendation and not a requirement, then it still matters=
, right? I don't see that we can meaningfully make it a requirement, an=
d I would advise against attempting to make it a recommendation. I don'=
t believe such a recommendation will be followed.


-- 
james woodyatt <jhw@nestlabs.com>
Nest Lab=
s, Communications Engineering




--089e015379928acd00050606978c--


From nobody Wed Oct 22 11:05:07 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263051ACEF4 for ; Wed, 22 Oct 2014 11:05:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level: 
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCJyHZ8t9qnZ for ; Wed, 22 Oct 2014 11:05:01 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DAD11ACDEE for ; Wed, 22 Oct 2014 11:05:01 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1057C200A7; Wed, 22 Oct 2014 14:05:50 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 467DF63A84; Wed, 22 Oct 2014 14:04:55 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3088E63A21; Wed, 22 Oct 2014 14:04:55 -0400 (EDT)
From: Michael Richardson 
To: James Woodyatt 
In-Reply-To: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>  <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com>   <1D269223-52B5-4B58-A46F-3B787EAFE4F3@fugue.com> <802A6061-3B41-4296-B739-E740DCF4873F@darou.fr> <648DEA84-6A8F-4075-85B1-AD135719CFC0@iki.fi> 
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/E6WQARv8yozb1QCjg_HnW6yCw2Q
Cc: HOMENET Working Group , Markus Stenberg 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 18:05:04 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


James Woodyatt  wrote:
    >> My assertion:
    >>
    >> Given HNCP generated one spans whole administrative domain, _and_
    >> should not have routing anywhere outside it, it=E2=80=99s uniqueness=
 does not
    >> _matter_.
    >>

    > Wait. Where did this "and should not be routable anywhere outside"
    > recommendation come from? And if it's only a recommendation and not a
    > requirement, then it still matters, right? I don't see that we can
    > meaningfully make it a requirement, and I would advise against
    > attempting to make it a recommendation. I don't believe such a
    > recommendation will be followed.

I won't mince words, "recommendation"/"requirement"/"potato"/etc..  I think
it's a very strong SHOULD, the only reason for someone to do otherwise would
by explicit geek-administator action.  Manually configuring a VPN for examp=
le.

It's not saying that ULA can never be routed by consenting adults, it's
saying that the Homenet ULA SHOULD never be routed outside that homenet.

Where it comes from; from the architecture document, I hope.
I'm pretty sure we said that somewhere, but I'll have to go search for the
specific statement.

I'm comfortable with a Homenet ULA existing in two places when equipment ge=
ts
seperated for a period of non-trivial time.   For instance, I fully
anticipate having 1-2 routers in my VM camper van, and I fully expect them =
to
travel.  {I might even bring up an explicit VPN to link stuff back together=
.}
I imagine that most people will expect their various conveyances, including
their (smart) backpacks to do this kind of thing.
Or taking stuff to the cottage for the summer, and bringing it back later o=
n.
If we split up the 64K available /64s sensibly, it shouldn't be a big deal.

I think that it's entirely reasonable that giving up the ULA when you move
equipment requires an explicit administrator action, like holding down the
FACTORY RESET button.  Sure, people might not do that; sure there might be
some people confusion when 5 friends get together for a "LAN" party ("hey,
why are there three servers called 'quake'? Which one is "quake-1"?"), but I
don't think that will be any systems confused by such activity.

=2D-
Michael Richardson , Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBVEfxxoCLcPvd0N1lAQLs9Af7BTnBO8UFpoaxYsiUOz/oJkmSGCoAulgf
Qq+2WUzkXhYMvgPsTs3sqoNNk5eVejTQ4cLPxlfPC5o0HGSYdlEh64Ph9jDeiH6E
/Fti5XWDJ/7IIXbAJelmAzqC5FnLGqeKoutqJ45GKrao6fAgm+o1NsnLOxRnW4HC
Rfnw1db3l1OXq8xXu3fR/XLIlDoUfDwP6rfYOeDcudrbG3LLd4EiVjS5Tj0UCr1e
VXwk4bReDNtHK49CvZjEkZHOUW3d/V1d+GempEW1QDkOTXIj0NdJ5QZmRYVxTjx1
ZPPUhtYyg4cvFONZGBi5bey2Jdy0YQlIN7bXA1e5cZx7osHuSVrrSg==
=ld3q
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Wed Oct 22 11:35:27 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6281ACF8C for ; Wed, 22 Oct 2014 11:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.483
X-Spam-Level: 
X-Spam-Status: No, score=0.483 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cdxnnx2SUeXf for ; Wed, 22 Oct 2014 11:35:24 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id BC7B31A8721 for ; Wed, 22 Oct 2014 11:35:23 -0700 (PDT)
Received: from [10.0.20.107] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id 3D2C3238013F; Wed, 22 Oct 2014 14:35:21 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <32190.1414001095@sandelman.ca>
Date: Wed, 22 Oct 2014 14:35:17 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <110B9A70-D611-44D3-A0AD-7D491D004BCC@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>  <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com>   <1D269223-52B5-4B58-A46F-3B787EAFE4F3@fugue.com> <802A6061-3B41-4296-B739-E740DCF4873F@darou.fr> <648DEA84-6A8F-4075-85B1-AD135719CFC0@iki.fi>  <32190.1414001095@sandelman.ca>
To: Michael Richardson 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/In7kPkZUUQhyiDjylfsqDQCaz4M
Cc: HOMENET Working Group , Markus Stenberg , James Woodyatt 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 18:35:25 -0000

On Oct 22, 2014, at 2:04 PM, Michael Richardson  =
wrote:
> Sure, people might not do that; sure there might be
> some people confusion when 5 friends get together for a "LAN" party =
("hey,
> why are there three servers called 'quake'? Which one is "quake-1"?"), =
but I
> don't think that will be any systems confused by such activity.

Gack.   No.   The existence of multiple ULAs on the wire should not mean =
that one machine with three addresses gets three names.


From nobody Wed Oct 22 11:46:57 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB361ACFCD for ; Wed, 22 Oct 2014 11:46:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.984
X-Spam-Level: 
X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Z0GMRfPtB4l for ; Wed, 22 Oct 2014 11:46:38 -0700 (PDT)
Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457DD1ACFCE for ; Wed, 22 Oct 2014 11:46:37 -0700 (PDT)
Received: by mail-vc0-f182.google.com with SMTP id la4so2420869vcb.13 for ; Wed, 22 Oct 2014 11:46:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KZk+yGOb2J7ci5NOqCjHGeuPk1zNmCjUFwy5P4+Gyzc=; b=LWUx/SedylRhT9m9ZKVjGXdrBCDYxAz70baQd8JaDiGFU9KScXMWhBepLp6yqf6JBa fR3k38U5t9tojOZ+BL5FhL3iP1PiMk5CLMEalj7Jv9PrhkmD8JBFyKo9r8w2c1VjY9ol pZNt/HtuI/RE7iWkSQL9QvM73HboRWD/gnuWNEwumKg0J/Onv9KB01mefVakS4P+9uVW MJy8+9IRIBp93yJLImqylHZXtITNtvneSHwrFPeS+EzMmoJa8wRQ3HgYUKgfZnS9ueGs 60uMiO8EoLNGprPGxT8kqDBrNiKX4WDDs1ZjP9NnsZXJ//Wx1FFKHOJ58DLf+NBpODnc DFrQ==
X-Gm-Message-State: ALoCoQkH3dllBDErnPdE9Y7Y8Vau0wkxa7UXvf/3DNtOAEIuZZfui3RZYyQpfqzfLfdGlC2Sri56
MIME-Version: 1.0
X-Received: by 10.221.4.73 with SMTP id ob9mr37834368vcb.13.1414003596297; Wed, 22 Oct 2014 11:46:36 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Wed, 22 Oct 2014 11:46:36 -0700 (PDT)
In-Reply-To: <32190.1414001095@sandelman.ca>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>  <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com>  <1D269223-52B5-4B58-A46F-3B787EAFE4F3@fugue.com> <802A6061-3B41-4296-B739-E740DCF4873F@darou.fr> <648DEA84-6A8F-4075-85B1-AD135719CFC0@iki.fi>  <32190.1414001095@sandelman.ca>
Date: Wed, 22 Oct 2014 11:46:36 -0700
Message-ID: 
From: James Woodyatt 
To: Michael Richardson 
Content-Type: multipart/alternative; boundary=089e0116052411a0210506075e2b
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/_33VvANuG4NbfeMmpA_U2q1Gj8A
Cc: HOMENET Working Group , Markus Stenberg 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 18:46:40 -0000

--089e0116052411a0210506075e2b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 22, 2014 at 11:04 AM, Michael Richardson 
wrote:

>
> James Woodyatt  wrote:
>     >> My assertion:
>     >>
>     >> Given HNCP generated one spans whole administrative domain, _and_
>     >> should not have routing anywhere outside it, it=E2=80=99s uniquene=
ss does
> not
>     >> _matter_.
>     >>
>
>     > Wait. Where did this "and should not be routable anywhere outside"
>     > recommendation come from? And if it's only a recommendation and not=
 a
>     > requirement, then it still matters, right? I don't see that we can
>     > meaningfully make it a requirement, and I would advise against
>     > attempting to make it a recommendation. I don't believe such a
>     > recommendation will be followed.
>
> I won't mince words, "recommendation"/"requirement"/"potato"/etc..  I thi=
nk
> it's a very strong SHOULD, the only reason for someone to do otherwise
> would
> by explicit geek-administator action.  Manually configuring a VPN for
> example.
>
> It's not saying that ULA can never be routed by consenting adults, it's
> saying that the Homenet ULA SHOULD never be routed outside that homenet.
>
> Where it comes from; from the architecture document, I hope.
> I'm pretty sure we said that somewhere, but I'll have to go search for th=
e
> specific statement. [...]


You won't find it.  It isn't actually there.  There is some text that maybe
you were thinking says it, but it doesn't, and the people who will be
implementing this stuff will never look in the architecture document
anyway, so it's moot.

p1. I won't mince words either: the HOMENET architecture document is full
of wrong on this topic. In particular, section 3.6.6
.
ULAs as a hint of connection origin makes the unwarranted assumption that
subscriber home gateways are the only routers bordering the home network.
They may often be the only *default* routers, but there can be=E2=80=94 and
absolutely definitely will be in the vast majority of cases=E2=80=94 overla=
y
networks that route ULA prefixes to, from and most likely *between* home
networks over tunnels. We can't tell people not to do that. If there is a
routing protocol in a HOMENET, then it will be done, and it ought to work
right.

p2. These overlay networks will not be "for geeks only" and they will not
require advanced manual network configuration skills. If this issue isn't
handled right in HOMENET, then we can expect each of those overlay networks
(there will almost certainly be more than one in many homes) to use
delegated ULA prefixes instead of the HNCP locally-generated prefixes if
necessary, but that just goes to show that the locally-generated prefixes
are likely to be crippled compared to the ones from overlay networks, which
will actually be generated and delegated properly to keep them from
colliding on network joins and splits.

What's the point of having a HNCP locally-generated ULA prefix if it
doesn't actually have the statistical properties of collision avoidance
that ULA prefixes were designed in the first place to have?


--=20
james woodyatt 
Nest Labs, Communications Engineering

--089e0116052411a0210506075e2b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On W=
ed, Oct 22, 2014 at 11:04 AM, Michael Richardson <mcr+ietf@sandelman.c=
a> wrote:


James Woodyatt <jhw@nestlabs.com=
> wrote:

=C2=A0 =C2=A0 >> My assertion:

=C2=A0 =C2=A0 >>

=C2=A0 =C2=A0 >> Given HNCP generated one spans whole administrative =
domain, _and_

=C2=A0 =C2=A0 >> should not have routing anywhere outside it, it=E2=
=80=99s uniqueness does not

=C2=A0 =C2=A0 >> _matter_.

=C2=A0 =C2=A0 >>



=C2=A0 =C2=A0 > Wait. Where did this "and should not be routable an=
ywhere outside"

=C2=A0 =C2=A0 > recommendation come from? And if it's only a recomme=
ndation and not a

=C2=A0 =C2=A0 > requirement, then it still matters, right? I don't s=
ee that we can

=C2=A0 =C2=A0 > meaningfully make it a requirement, and I would advise a=
gainst

=C2=A0 =C2=A0 > attempting to make it a recommendation. I don't beli=
eve such a

=C2=A0 =C2=A0 > recommendation will be followed.



I won't mince words, "recommendation"/"requiremen=
t"/"potato"/etc..=C2=A0 I think

it's a very strong SHOULD, the only reason for someone to do otherwise =
would

by explicit geek-administator action.=C2=A0 Manually configuring a VPN for =
example.



It's not saying that ULA can never be routed by consenting adults, it&#=
39;s

saying that the Homenet ULA SHOULD never be routed outside that homenet.


Where it comes from; from the architecture document, I hope.

I'm pretty sure we said that somewhere, but I'll have to go search =
for the

specific statement. [...]=C2=A0

You won't find it.=C2=A0 It isn&=
#39;t actually there.=C2=A0 There is some text that maybe you were thinking=
 says it, but it doesn't, and the people who will be implementing this =
stuff will never look in the architecture document anyway, so it's moot=
.

p1. I won't mince words eit=
her: the HOMENET architecture document is full of wrong on this topic. In p=
articular, section=C2=A03.6.6.  ULAs as a hint of connection origin=C2=A0make=
s the unwarranted assumption that subscriber home gateways are the only rou=
ters bordering the home network.=C2=A0 They may often be the only *default*=
 routers, but there can be=E2=80=94 and absolutely definitely will be in th=
e vast majority of cases=E2=80=94 overlay networks that route ULA prefixes =
to, from and most likely *between* home networks over tunnels. We can't=
 tell people not to do that. If there is a routing protocol in a HOMENET, t=
hen it will be done, and it ought to work right.

p2. These overlay networks will =
not be "for geeks only" and they will not require advanced manual=
 network configuration skills. If this issue isn't handled right in HOM=
ENET, then we can expect each of those overlay networks (there will almost =
certainly be more than one in many homes) to use delegated ULA prefixes ins=
tead of the HNCP locally-generated prefixes if necessary, but that just goe=
s to show that the locally-generated prefixes are likely to be crippled com=
pared to the ones from overlay networks, which will actually be generated a=
nd delegated properly to keep them from colliding on network joins and spli=
ts.

Wh=
at's the point of having a HNCP locally-generated ULA prefix if it does=
n't actually have the statistical properties of collision avoidance tha=
t ULA prefixes were designed in the first place to have?


-- 
james woodyatt <=
;jhw@nestlabs.com=
>
Nest Labs, Communications Engineering




--089e0116052411a0210506075e2b--


From nobody Wed Oct 22 12:07:50 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52E71AD2AF; Wed, 22 Oct 2014 12:07:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_6UU3qIjhxy; Wed, 22 Oct 2014 12:07:35 -0700 (PDT)
Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 926B91AD333; Wed, 22 Oct 2014 12:07:11 -0700 (PDT)
Received: from [2001:8d8:870:10ef:1::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1Xh1FT-0007ua-Cj; Wed, 22 Oct 2014 21:07:07 +0200
Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.82) (envelope-from ) id 1Xh1FF-001Iey-Ls; Wed, 22 Oct 2014 21:06:56 +0200
Date: Wed, 22 Oct 2014 21:06:53 +0200
From: David Lamparter 
To: rtgwg@ietf.org, homenet@ietf.org
Message-ID: <20141022190653.GB868521@jupiter.n2.diac24.net>
References: <20141020204033.GD236844@jupiter.n2.diac24.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20141020204033.GD236844@jupiter.n2.diac24.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/7r9CYlCQZq0fymxE7o41dxfRTVs
Cc: "Fred Baker \(fred\)" , Mikael Abrahamsson 
Subject: Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 19:07:41 -0000

On Mon, Oct 20, 2014 at 10:40:33PM +0200, David Lamparter wrote:
> https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-routing-extra-qualifiers/?include_text=1
> https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-dst-src-routing/?include_text=1

rtgwg & homenet:

So, these drafts describe the general router behaviour for D/S, without
heading into homenet specifics.  There are a few points that might be
worth going into detail:

- the first draft describes adding random kinds of attributes into route
  lookup.  That's very generic, and it didn't add significant
  complexity, but I don't think we're expecting to insert things in the
  middle?

- we haven't discussed some of the boundaries to other functions.
  Recursive route handling is unlikely to be relevant for homenet, but
  might warrant feedback from rtgwg.  And the situation is rather
  complex, the draft has an open "multiple-choices TBD" there.

  Interesting for both rtgwg & homenet are behaviour with uRPF filtering
  and multicast RP lookups.  The draft says:
   for uRPF, flip dst & src and match both, if the system supports it.
     If it doesn't, match packet source against all possible route dst.
     (This probably needs better wording in the draft)
   for mcast reverse-path lookup, ignore all D/S routes.  Multicast has
     only (group, source) available, no destination to match against the
     route source prefix.

So, to be explicit on this, D/S routing is conceptually incompatible
with multicast reverse path lookups.  But that can be dealt with (cue to
homenet multicast discussion here.)


Hoping for feedback (including, possibly, "I don't care" or "I have no
opinion"),


-David


P.S.: there is an unfortunate scheduling collision between homenet and
rtgwg for IETF 91... please convert to mail as much as possible!


From nobody Wed Oct 22 12:25:46 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE361AD381 for ; Wed, 22 Oct 2014 12:25:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.573
X-Spam-Level: **
X-Spam-Status: No, score=2.573 tagged_above=-999 required=5 tests=[BAYES_50=0.8, PLING_QUERY=0.994, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i25pub61qAvj for ; Wed, 22 Oct 2014 12:25:33 -0700 (PDT)
Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.194]) by ietfa.amsl.com (Postfix) with ESMTP id A8B401AD372 for ; Wed, 22 Oct 2014 12:25:32 -0700 (PDT)
Received: from poro.lan (80.220.64.126) by jenni2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 543C16C900BF8BA5; Wed, 22 Oct 2014 22:25:22 +0300
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Markus Stenberg 
In-Reply-To: 
Date: Wed, 22 Oct 2014 22:25:22 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <242EDEFE-06B8-4B6A-8B42-D67D68B330A4@iki.fi>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>  <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com>   <1D269223-52B5-4B58-A46F-3B787EAFE4F3@fugue.com> <802A6061-3B41-4296-B739-E740DCF4873F@darou.fr> <648DEA84-6A8F-4075-85B1-AD135719CFC0@iki.fi> 
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/CDq5Mwuh9F3eQSqCKyYSgFCtZ7g
Cc: HOMENET Working Group , Markus Stenberg 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 19:25:35 -0000

On 22.10.2014, at 20.51, James Woodyatt  wrote:
> On Wed, Oct 22, 2014 at 12:19 AM, Markus Stenberg =
 wrote:
> Wait. Where did this "and should not be routable anywhere outside" =
recommendation come from? And if it's only a recommendation and not a =
requirement, then it still matters, right? I don't see that we can =
meaningfully make it a requirement, and I would advise against =
attempting to make it a recommendation. I don=92t believe such a =
recommendation will be followed.

I was not writing anything based on recommendations ; I just wrote =
taxonomy of different ULA cases that I currently see as realistic, and =
in the [3], there does not seem to be any (automated) reason for routing =
outside the administrative domain that is the HNCP router network-

RFC4193 abstract.

   This document defines an IPv6 unicast address format that is globally
   unique and is intended for local communications, usually inside of a
   site.  These addresses are not expected to be routable on the global
   Internet.

If you are doing =91private routing=92 or whatever, note the categories =
[1] and [2] I defined that _are_ routable and should work for that fine.

I am just interested in the case [3]. For it, specifying just some fixed =
/48 or something for HNCP administrative scope use would be fine too. If =
multiple HNCP-using networks want to communicate, they may share the =
prefix (or at least make sure the /64s allocated are unique so the =
communication works between all routed links).=20

The idea that they share (partially?) routes but not HNCP state sounds =
strange to me, but even for that, the [1]/[2] sub-delegation options =
should work fine.

Cheers,

-Markus=


From nobody Wed Oct 22 12:46:41 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394971AD3F7 for ; Wed, 22 Oct 2014 12:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLxKhY0u4AYv for ; Wed, 22 Oct 2014 12:46:30 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F1C51AD3F0 for ; Wed, 22 Oct 2014 12:46:27 -0700 (PDT)
Received: by mail-pa0-f51.google.com with SMTP id lj1so4336938pab.38 for ; Wed, 22 Oct 2014 12:46:26 -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=M4WTjh/VgIAgMnQVPwclL7Z7EhEp71qgkOUgStBLJGQ=; b=fjGBMH1LbZ2pOHUwAVnIB7cztOXeeWmiqAQeV4naBM1D6qrfGpqI/Q/ti6Sn/HOjQT 4nXiG4tMUaBIajXFO9qQY9ngEDa5/IRAMAdAErWwBnTqkCqgZQAcvw77AQNbybx80n6/ PuxIO1PgdcqeZTCKvvoWZqvjAc72XxV6qLVj7QOgLn0NASpw5v+c5VHsJVrP0ZVPZsbM 8SbyIqqoL1jY01uk7Npx6l2PLEHwsUrCneaSPquHp2VpA7yYN0KGLHtdKxPsyRPylj09 0BqzAPKdydsjj9vTWvRmb2vlGEBGUuiQhXqf+ZY8QFeFPSDdeeb/b/EHKS+xqtl/IT4j y9mg==
X-Received: by 10.66.66.229 with SMTP id i5mr5847201pat.137.1414007186734; Wed, 22 Oct 2014 12:46:26 -0700 (PDT)
Received: from [192.168.178.23] (74.200.69.111.dynamic.snap.net.nz. [111.69.200.74]) by mx.google.com with ESMTPSA id bf2sm14879418pbb.13.2014.10.22.12.46.23 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 12:46:25 -0700 (PDT)
Message-ID: <54480996.9050104@gmail.com>
Date: Thu, 23 Oct 2014 08:46:30 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ray Bellis 
References: <20141014071141.5753.35124.idtracker@ietfa.amsl.com> <5447023B.4030104@gmail.com> <7486C1B6-4CB2-4A06-884B-84C772A9B7A9@nominet.org.uk>
In-Reply-To: <7486C1B6-4CB2-4A06-884B-84C772A9B7A9@nominet.org.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/u60AWLKaZPsfp4x23jHmJtbWc2I
Cc: "homenet@ietf.org" 
Subject: Re: [homenet] I-D Action: draft-barth-homenet-hncp-security-trust-01.txt
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 19:46:34 -0000

On 22/10/2014 23:54, Ray Bellis wrote:
> On 22 Oct 2014, at 02:02, Brian E Carpenter  wrote:
> 
>> Up one more level: the charter looks pretty out of date in general.
> 
> Hi Brian,
> 
> The charter itself still reflects our primary focus.  I believe it still accurately reflects the constraints on our scope.
> 
> The milestones are admittedly completely out of date!  I hope that Mark and I will be able to get some time with our AD in Honolulu to get those updated.

Been there, done that, you have my sympathy and understanding ;-).

However, I suggest that a security threat analysis would be worth
considering as a new charter goal.

   Brian


From nobody Wed Oct 22 12:51:09 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB391AD3F1 for ; Wed, 22 Oct 2014 12:51:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.982
X-Spam-Level: 
X-Spam-Status: No, score=0.982 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8VZBWy2EK1c for ; Wed, 22 Oct 2014 12:51:04 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 57DE91AD3ED for ; Wed, 22 Oct 2014 12:51:04 -0700 (PDT)
Received: from [10.0.20.107] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id 09748238013F; Wed, 22 Oct 2014 15:51:02 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Wed, 22 Oct 2014 15:51:01 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>  <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com>  <1D 269223-52B5-4B58-A46F-3B787EAFE4F3@fugue.com> <802A6061-3B41-4296-B739-E740DCF4873F@darou.fr> <648DEA84-6A8F-4075-85B1-AD135719CFC0@iki.fi>  <32190.1414001095@sandelman.ca> 
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/V3GzZB4lGpZbEpV5qqTgZBUR_pU
Cc: Michael Richardson , HOMENET Working Group , Markus Stenberg 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 19:51:05 -0000

On Oct 22, 2014, at 2:46 PM, James Woodyatt  wrote:
> They may often be the only *default* routers, but there can be=97 and =
absolutely definitely will be in the vast majority of cases=97 overlay =
networks that route ULA prefixes to, from and most likely *between* home =
networks over tunnels. We can't tell people not to do that. If there is =
a routing protocol in a HOMENET, then it will be done, and it ought to =
work right.

In the case where ULAs are being routed like this, wouldn't that ULA be =
the responsibility of whatever homenet federation protocol is being =
used?   I don't disagree that this is a valid use case, but I don't =
think it would rely on the homenet ULA.


From nobody Wed Oct 22 13:16:34 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D391A1AA5; Wed, 22 Oct 2014 13:16:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.511
X-Spam-Level: 
X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6tPvnXMwHRy; Wed, 22 Oct 2014 13:16:30 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D6C1A1A29; Wed, 22 Oct 2014 13:16:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1837; q=dns/txt; s=iport; t=1414008991; x=1415218591; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oaa7DHsMvz0K+jXrxo6QJ+3w4xp7MZrT12KJmCtmiQU=; b=Gldb//oMUIIhObHznDVRESoUZKt/DLYAH+OGe2mkYYRkq/2/jcBJOAwd Byz0uvwGRklOvVdQMYzB9dIN0/yt5RT71/ElgX4kbn4JnRp6Wspe9EsMC 3VHAMHVX2IfwGXhqKUxkYKfif8ozdNAeGqfLWY2pcv7KvVjASi+NG68lu o=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhwFANAPSFStJV2P/2dsb2JhbABcgw5UWATMX4dLAoEOFgF9hAIBAQEDAXkFCwIBCA4KLjIlAgQOBQ4NiB0IDcVuAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSQVweDLYEeBZIEgg6BUGiHE5Yqg3hsgUiBAwEBAQ
X-IronPort-AV: E=Sophos;i="5.04,770,1406592000";  d="asc'?scan'208";a="89462280"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP; 22 Oct 2014 20:16:30 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9MKGTB4006838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 20:16:30 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.248]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 15:16:29 -0500
From: "Fred Baker (fred)" 
To: David Lamparter 
Thread-Topic: dst/src routing drafts (for IETF-91 rtgwg)
Thread-Index: AQHP7KYr8Fy7zf5Z70yFtC9ToRE4KA==
Date: Wed, 22 Oct 2014 20:16:29 +0000
Message-ID: 
References: <20141020204033.GD236844@jupiter.n2.diac24.net> <20141022190653.GB868521@jupiter.n2.diac24.net>
In-Reply-To: <20141022190653.GB868521@jupiter.n2.diac24.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.19.64.118]
Content-Type: multipart/signed; boundary="Apple-Mail=_A342AF8E-5ABC-4A62-AE96-CFC74460E806"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/6lttOX_pMtGXiy14AHMjeXXWIR4
Cc: "homenet@ietf.org" , Mikael Abrahamsson , "rtgwg@ietf.org" 
Subject: Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 20:16:32 -0000

--Apple-Mail=_A342AF8E-5ABC-4A62-AE96-CFC74460E806
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Oct 22, 2014, at 12:06 PM, David Lamparter  =
wrote:

> On Mon, Oct 20, 2014 at 10:40:33PM +0200, David Lamparter wrote:
>> =
https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-routing-extra-quali=
fiers/?include_text=3D1
>> =
https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-dst-src-routing/?in=
clude_text=3D1

Speaking strictly for myself, I=92m not sure why homenet is relevant. =
The technology is related to networks that have different routing depend =
on on one=92s use case. A class of solutions for it has been called the =
=93fish=94 problem, and built using multi-topology routing. In homenet, =
it=92s called SADR, and is primarily about egress routing (routing to an =
egress to an upstream ISP that gave you a PA prefix). While one doesn=92t =
really want to confuse theory with practice, in theory it could be used =
between points of a network, to prevent folks using one set of prefixes =
to talk with another set, or to force routing of some sessions in some =
ways.

Personally, those are a class of problems I associate with campus =
networks more than residential networks.

--Apple-Mail=_A342AF8E-5ABC-4A62-AE96-CFC74460E806
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iD8DBQFUSBCbbjEdbHIsm0MRAt9VAJwO7TWL/GoPRxUSxtF2umu95xwdXQCg2yGw
YhppcpRpkls65fus2i41JQw=
=mb3/
-----END PGP SIGNATURE-----

--Apple-Mail=_A342AF8E-5ABC-4A62-AE96-CFC74460E806--


From nobody Wed Oct 22 14:00:41 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7AA1A1B0C for ; Wed, 22 Oct 2014 14:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.416
X-Spam-Level: 
X-Spam-Status: No, score=0.416 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Yb4k2MCerKj for ; Wed, 22 Oct 2014 14:00:36 -0700 (PDT)
Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE091A1A72 for ; Wed, 22 Oct 2014 14:00:36 -0700 (PDT)
Received: by mail-vc0-f182.google.com with SMTP id la4so2647059vcb.27 for ; Wed, 22 Oct 2014 14:00:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=qBA+sjoT7P22lIuzb9LCTPuGij56pJFQv93vtmLATUU=; b=guQJZp/TVcsFXg9mCmMLx6oFUFuZO3iyUDDA0xUNjMSveFUIy0hlty82q2qx7dqu7W YFx6Sa56ji5Nf7S8c8FYQ3Mq48lBvhmtLWFwe0xSrkVqkVENcPVbcZBw28RI13S7veyG Ty/oZ21mjnVDAwgVlycCuArOHZ1m2Pu9E6mI8cav2h6tnT7Q+YsC7EHQkuVD4g24eLzC jg/wkqcSOm4B04KlDa/84pYXSzng8oyCj19xxXsgU/HCEfPeRxEFMHYlBTDc7nGwsvY7 F0M7sOjbxKkHcePe9i15gmtCsU5BOyPL3Sid/sn0vZM+3ZtPrU2VvRplj+dUFk1S25Hb xYJw==
X-Gm-Message-State: ALoCoQmcfOjPsKhcw+gPQVbiEna4gPlxlQw25/tRwZBdMuR7J/H22gOcfabpzvYXgOQlC/Dme99r
MIME-Version: 1.0
X-Received: by 10.52.242.198 with SMTP id ws6mr294714vdc.21.1414011635486; Wed, 22 Oct 2014 14:00:35 -0700 (PDT)
Received: by 10.31.10.65 with HTTP; Wed, 22 Oct 2014 14:00:35 -0700 (PDT)
In-Reply-To: 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>  <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com>  <802A6061-3B41-4296-B739-E740DCF4873F@darou.fr> <648DEA84-6A8F-4075-85B1-AD135719CFC0@iki.fi>  <32190.1414001095@sandelman.ca>  
Date: Wed, 22 Oct 2014 14:00:35 -0700
Message-ID: 
From: James Woodyatt 
To: HOMENET Working Group 
Content-Type: multipart/alternative; boundary=001a1135e3823de6f10506093da9
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/uKr5f08vIapHliFvkvCuN-pCk8k
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 21:00:37 -0000

--001a1135e3823de6f10506093da9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 22, 2014 at 12:51 PM, Ted Lemon  wrote:

> On Oct 22, 2014, at 2:46 PM, James Woodyatt  wrote:
> > They may often be the only *default* routers, but there can be=E2=80=94=
 and
> absolutely definitely will be in the vast majority of cases=E2=80=94 over=
lay
> networks that route ULA prefixes to, from and most likely *between* home
> networks over tunnels. We can't tell people not to do that. If there is a
> routing protocol in a HOMENET, then it will be done, and it ought to work
> right.
>
> In the case where ULAs are being routed like this, wouldn't that ULA be
> the responsibility of whatever homenet federation protocol is being used?
>  I don't disagree that this is a valid use case, but I don't think it wou=
ld
> rely on the homenet ULA.
>

My point is that it doesn't need to be done that way unless HOMENET forces
that design choice.

I see a way to work around the potential problem here=E2=80=94 by eating th=
e
expense of requiring the overlay routers between HOMENET site boundaries to
exchange the full raft of valid /64 routes in all the currently valid
locally-generated ULA prefixes instead of exchanging just the aggregated
/48 ULA prefixes. I suppose that can be made to mostly work in the majority
of cases at the cost of memory and efficiency for interior routers. Don't
grow your home networks too big, however, or the interior routers in your
house=E2=80=94 or in your friend's house=E2=80=94 might fall over when the =
overlay connects.


--=20
james woodyatt 
Nest Labs, Communications Engineering

--001a1135e3823de6f10506093da9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On W=
ed, Oct 22, 2014 at 12:51 PM, Ted Lemon <mellon@fugue.com> wr=
ote:
On Oct 22, 2014, at=
 2:46 PM, James Woodyatt <jhw@nestla=
bs.com> wrote:

> They may often be the only *default* routers, but there can be=E2=80=
=94 and absolutely definitely will be in the vast majority of cases=E2=80=
=94 overlay networks that route ULA prefixes to, from and most likely *betw=
een* home networks over tunnels. We can't tell people not to do that. I=
f there is a routing protocol in a HOMENET, then it will be done, and it ou=
ght to work right.



In the case where ULAs are being routed like this, wouldn't that=
 ULA be the responsibility of whatever homenet federation protocol is being=
 used?=C2=A0 =C2=A0I don't disagree that this is a valid use case, but =
I don't think it would rely on the homenet ULA.



My point is that it=
 doesn't need to be done that way unless HOMENET forces that design cho=
ice.

I=
 see a way to work around the potential problem here=E2=80=94 by eating the=
 expense of requiring the overlay routers between HOMENET site boundaries t=
o exchange the full raft of valid /64 routes in all the currently valid loc=
ally-generated ULA prefixes instead of exchanging just the aggregated /48 U=
LA prefixes. I suppose that can be made to mostly work in the majority of c=
ases at the cost of memory and efficiency for interior routers. Don't g=
row your home networks too big, however, or the interior routers in your ho=
use=E2=80=94 or in your friend's house=E2=80=94 might fall over when th=
e overlay connects.


-- 
james woodyatt <jhw@nestlabs.com>=

Nest Labs, Communications Engineering




--001a1135e3823de6f10506093da9--


From nobody Wed Oct 22 14:09:04 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC8A1A01F9 for ; Wed, 22 Oct 2014 14:09:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.982
X-Spam-Level: 
X-Spam-Status: No, score=0.982 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, PLING_QUERY=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbxB-S_rTFu8 for ; Wed, 22 Oct 2014 14:09:00 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 38D821A1B0C for ; Wed, 22 Oct 2014 14:09:00 -0700 (PDT)
Received: from [10.0.20.107] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id 14B4F23802BC; Wed, 22 Oct 2014 17:08:58 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: 
Date: Wed, 22 Oct 2014 17:08:56 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <41C89287-810A-4119-84C3-C9B7CF302B14@fugue.com>
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr>     <70C2B2B2-A19A-4730-AB51-1EF26448445B@fugue.com>  <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>  <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com>  <80 2A6061-3B41-4296-B739-E740DCF4873F@darou.fr> <648DEA84-6A8F-4075-85B1-AD135719CFC0@iki.fi>  <32190.1414001095@sandelman.ca>   
To: James Woodyatt 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Y0DuSmHUVn8U3449s0gcU2-LZQo
Cc: HOMENET Working Group 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 21:09:02 -0000

On Oct 22, 2014, at 5:00 PM, James Woodyatt  wrote:
> My point is that it doesn't need to be done that way unless HOMENET =
forces that design choice.

The scenario you are describing sounds like it's secondary.   Yes, it's =
a valid use case, but homenets working right is a use case that will see =
wider deployment.   Federating home networks is certainly an interesting =
idea, but it seems even more bleeding edge than homenets.   I can think =
of a lot of nice ways to approach the problem.   I agree that if =
homenets use ULAs the way we're discussing, that constrains your =
choices, but I am confident that the remaining choices are not only =
adequate, but good.=


From nobody Wed Oct 22 14:43:12 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5DA1A6F28 for ; Wed, 22 Oct 2014 14:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.006
X-Spam-Level: 
X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PLING_QUERY=0.994, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4Rm_-31h5LW for ; Wed, 22 Oct 2014 14:43:10 -0700 (PDT)
Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 146D81A6FED for ; Wed, 22 Oct 2014 14:42:31 -0700 (PDT)
Received: by mail-pd0-f171.google.com with SMTP id ft15so4301379pdb.16 for ; Wed, 22 Oct 2014 14:42:30 -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=USthBZrSa0I/XrDuMUj9UgZhZltJUziw3eRPmQpLSWs=; b=E4hnHvSoEwId+CtjYVGC6xuUuWMmu/DZ28LM9vMRjFh0UE16L7YWhehLZThzpy6K3J jtVsIe+spcd6scBROk4wZ/1niFzhVjKLoV5L6j6Kk00LdRYZq1eFkbYV8bhivavfmJb0 yxuE7h3ke2RFH++LNrcshNplpSSZ4Lum1HY08ySMoavrBr5HU1PB7brYgOdq8XdNxJ6y jvYFmI//1cPJrxXGojpfFmgg79u2fvfUI7lbuaSVxQ0auSBKnKw5iKgv4LeEyDc83QXT sigzODOs5sD0cuM8tn/+1vgnI6fKvu2RbWO3DMPGgRhWzvsvtNX5Z4wR0hNcLztvOj5J Rj+A==
X-Received: by 10.70.48.36 with SMTP id i4mr871489pdn.20.1414014150761; Wed, 22 Oct 2014 14:42:30 -0700 (PDT)
Received: from [192.168.178.23] (74.200.69.111.dynamic.snap.net.nz. [111.69.200.74]) by mx.google.com with ESMTPSA id y1sm14951433pbw.89.2014.10.22.14.42.26 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 14:42:29 -0700 (PDT)
Message-ID: <544824CB.4020306@gmail.com>
Date: Thu, 23 Oct 2014 10:42:35 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Michael Richardson 
References: <72CC13D1-7E7A-4421-B23E-16D8FFAEEB58@darou.fr> <94990F79-439A-4820-B03B-BFEAB01AA515@fugue.com>  <0DACB967-C77F-4C8A-82DD-759FF5C39E91@fugue.com>  <4321EF22-4AD9-4BC8-8253-12034C562C00@fugue.com>  <69F7C62F-273B-4808-B7A8-5D2487CAF4BF@fugue.com>  <9C02AF4F-CEFC-426A-B8CC-0A5DA146FB1B@fugue.com>   <1D269223-52B5-4B58-A46F-3B787EAFE4F3@fugue.com> <802A6061-3B41-4296-B739-E740DCF4873F@darou.fr> <648DEA84-6A8F-4075-85B1-AD135719CFC0@iki.fi>  <32190.1414001095@sandelman.ca>
In-Reply-To: <32190.1414001095@sandelman.ca>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/QZkhk1jMDTQnBI4WgT-TFYOe3oU
Cc: HOMENET Working Group , Markus Stenberg , James Woodyatt 
Subject: Re: [homenet] Let's make in-home ULA presence a MUST !?
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 21:43:11 -0000

Michael,

On 23/10/2014 07:04, Michael Richardson wrote:
> James Woodyatt  wrote:
>     >> My assertion:
>     >>
>     >> Given HNCP generated one spans whole administrative domain, _and=
_
>     >> should not have routing anywhere outside it, it=E2=80=99s unique=
ness does not
>     >> _matter_.
>     >>
>=20
>     > Wait. Where did this "and should not be routable anywhere outside=
"
>     > recommendation come from? And if it's only a recommendation and n=
ot a
>     > requirement, then it still matters, right? I don't see that we ca=
n
>     > meaningfully make it a requirement, and I would advise against
>     > attempting to make it a recommendation. I don't believe such a
>     > recommendation will be followed.
>=20
> I won't mince words, "recommendation"/"requirement"/"potato"/etc..  I t=
hink
> it's a very strong SHOULD, the only reason for someone to do otherwise =
would
> by explicit geek-administator action.  Manually configuring a VPN for e=
xample.
>=20
> It's not saying that ULA can never be routed by consenting adults, it's=

> saying that the Homenet ULA SHOULD never be routed outside that homenet=
=2E
>=20
> Where it comes from; from the architecture document, I hope.
> I'm pretty sure we said that somewhere, but I'll have to go search for =
the
> specific statement.

You may be thinking of http://tools.ietf.org/html/rfc4193#section-4,
if we equate "site" to "homenet". I just re-read it and it all still
seems right to me. It doesn't discuss network splits, however, and
that is not a theoretical issue in homenets.

   Brian

>=20
> I'm comfortable with a Homenet ULA existing in two places when equipmen=
t gets
> seperated for a period of non-trivial time.   For instance, I fully
> anticipate having 1-2 routers in my VM camper van, and I fully expect t=
hem to
> travel.  {I might even bring up an explicit VPN to link stuff back toge=
ther.}
> I imagine that most people will expect their various conveyances, inclu=
ding
> their (smart) backpacks to do this kind of thing.
> Or taking stuff to the cottage for the summer, and bringing it back lat=
er on.
> If we split up the 64K available /64s sensibly, it shouldn't be a big d=
eal.
>=20
> I think that it's entirely reasonable that giving up the ULA when you m=
ove
> equipment requires an explicit administrator action, like holding down =
the
> FACTORY RESET button.  Sure, people might not do that; sure there might=
 be
> some people confusion when 5 friends get together for a "LAN" party ("h=
ey,
> why are there three servers called 'quake'? Which one is "quake-1"?"), =
but I
> don't think that will be any systems confused by such activity.
>=20
> --
> Michael Richardson , Sandelman Software Works
>  -=3D IPv6 IoT consulting =3D-
>=20
>=20
>=20
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From nobody Wed Oct 22 15:26:44 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DD61A8765 for ; Wed, 22 Oct 2014 15:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.112
X-Spam-Level: 
X-Spam-Status: No, score=-1.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MG59yIwFi20i for ; Wed, 22 Oct 2014 15:26:42 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6B41A1AFD for ; Wed, 22 Oct 2014 15:26:41 -0700 (PDT)
Received: from [10.1.10.18] (c-50-148-182-215.hsd1.ca.comcast.net [50.148.182.215]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id s9MMQUuq006374 for ; Wed, 22 Oct 2014 15:26:33 -0700
Message-ID: <54482F0D.3060602@mtcc.com>
Date: Wed, 22 Oct 2014 15:26:21 -0700
From: Michael Thomas 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: homenet@ietf.org
References: <20141014071141.5753.35124.idtracker@ietfa.amsl.com> <5447023B.4030104@gmail.com> <7486C1B6-4CB2-4A06-884B-84C772A9B7A9@nominet.org.uk> <54480996.9050104@gmail.com>
In-Reply-To: <54480996.9050104@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/MNwKtKCwBUUEfIWZ9NXh6jDwlfA
Subject: Re: [homenet] I-D Action: draft-barth-homenet-hncp-security-trust-01.txt
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 22:26:43 -0000

On 10/22/14, 12:46 PM, Brian E Carpenter wrote:
> On 22/10/2014 23:54, Ray Bellis wrote:
>> On 22 Oct 2014, at 02:02, Brian E Carpenter  wrote:
>>
>>> Up one more level: the charter looks pretty out of date in general.
>> Hi Brian,
>>
>> The charter itself still reflects our primary focus.  I believe it still accurately reflects the constraints on our scope.
>>
>> The milestones are admittedly completely out of date!  I hope that Mark and I will be able to get some time with our AD in Honolulu to get those updated.
> Been there, done that, you have my sympathy and understanding ;-).
>
> However, I suggest that a security threat analysis would be worth
> considering as a new charter goal.
>

+1

Mike


From nobody Fri Oct 24 05:16:39 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292AB1A8AF0; Fri, 24 Oct 2014 05:16:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26JNfCc-Atul; Fri, 24 Oct 2014 05:16:33 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFBFB1A8AA3; Fri, 24 Oct 2014 05:16:33 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.4.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141024121633.26839.23922.idtracker@ietfa.amsl.com>
Date: Fri, 24 Oct 2014 05:16:33 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/h5tYSEBuVsXfzpPirrcV1twEM1I
Cc: homenet@ietf.org
Subject: [homenet] I-D Action: draft-ietf-homenet-prefix-assignment-01.txt
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 12:16:35 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Home Networking Working Group of the IETF.

        Title           : Prefix and Address Assignment in a Home Network
        Authors         : Pierre Pfister
                          Benjamin Paterson
                          Jari Arkko
	Filename        : draft-ietf-homenet-prefix-assignment-01.txt
	Pages           : 32
	Date            : 2014-10-24

Abstract:
   This memo describes a home network prefix and address assignment
   algorithm running on top of any 'flooding protocol' that fulfills the
   specified requirements.  It is expected that home border routers are
   allocated one or multiple IPv6 prefixes through DHCPv6 Prefix
   Delegation (PD) or that prefixes are made available through other
   means.  An IPv4 address can also be assigned and private addresses be
   used with NAT to provide IPv4 connectivity.  In both cases, provided
   prefixes need to be efficiently divided among the multiple links, and
   routers need to obtain addresses.  This document describes a
   distributed algorithm for IPv4 and IPv6 prefixes division, assignment
   and router's address assignment, and specifies how hosts can be given
   addresses and configuration options using DHCP or SLAAC.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-prefix-assignment/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-homenet-prefix-assignment-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-prefix-assignment-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From SRS0=5ONS=7P=darou.fr=pierre.pfister@bounces.m4x.org  Fri Oct 24 05:28:22 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F771A8AF1 for ; Fri, 24 Oct 2014 05:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6kMFMNM6Loy for ; Fri, 24 Oct 2014 05:28:19 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BCAD1A8AB5 for ; Fri, 24 Oct 2014 05:28:19 -0700 (PDT)
Received: from [10.61.195.172] (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 8C4121408EEEB for ; Fri, 24 Oct 2014 14:28:16 +0200 (CEST)
From: Pierre Pfister 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Date: Fri, 24 Oct 2014 14:28:31 +0200
References: <20141024121634.26839.9974.idtracker@ietfa.amsl.com>
To: HOMENET Working Group 
Message-Id: <16E43441-54DA-48AA-8F4F-0E2318727699@darou.fr>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Fri Oct 24 14:28:16 2014 +0200 (CEST))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/n83_bLmnVyivcFPUlY52zRuNFNo
Subject: [homenet] Fwd: New Version Notification for draft-ietf-homenet-prefix-assignment-01.txt
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 12:28:50 -0000

Hello group,

I updated version -01 of the Homenet prefix assignment draft.

Changes since -00 are:
- Add a paragraph specifying that Route Information Options must be =
included in router advertisements, providing in-home prefixes =
information.
- Lost Delegated Prefixes are advertised up to 2 hours (In agreement =
with SLAAC and RFC7084).
- Deprecated Delegated Prefixes (preferred lifetime =3D 0) are not used =
for new assignments (Unless configuration states otherwise or no other =
prefix is available).
- New **proposal** for autonomously generated ULAs. If no IPv6 prefix is =
available, ULA generation is a =91SHOULD=92. The proposition also deals =
with network splits.

Please notice that the change concerning the ULA generation is a hot =
topic.=20
This is a proposal, trying to provide a solution to the different =
concerns expressed on the dedicated thread:

Comments are welcome.

Regards,

- Pierre


>=20
> A new version of I-D, draft-ietf-homenet-prefix-assignment-01.txt
> has been successfully submitted by Pierre Pfister and posted to the
> IETF repository.
>=20
> Name:		draft-ietf-homenet-prefix-assignment
> Revision:	01
> Title:		Prefix and Address Assignment in a Home Network
> Document date:	2014-10-24
> Group:		homenet
> Pages:		32
> URL:            =
http://www.ietf.org/internet-drafts/draft-ietf-homenet-prefix-assignment-0=
1.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-ietf-homenet-prefix-assignment/
> Htmlized:       =
http://tools.ietf.org/html/draft-ietf-homenet-prefix-assignment-01
> Diff:           =
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-prefix-assignment-01=

>=20
> Abstract:
>   This memo describes a home network prefix and address assignment
>   algorithm running on top of any 'flooding protocol' that fulfills =
the
>   specified requirements.  It is expected that home border routers are
>   allocated one or multiple IPv6 prefixes through DHCPv6 Prefix
>   Delegation (PD) or that prefixes are made available through other
>   means.  An IPv4 address can also be assigned and private addresses =
be
>   used with NAT to provide IPv4 connectivity.  In both cases, provided
>   prefixes need to be efficiently divided among the multiple links, =
and
>   routers need to obtain addresses.  This document describes a
>   distributed algorithm for IPv4 and IPv6 prefixes division, =
assignment
>   and router's address assignment, and specifies how hosts can be =
given
>   addresses and configuration options using DHCP or SLAAC.
>=20
>=20
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> The IETF Secretariat
>=20


From nobody Fri Oct 24 16:18:20 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2BF1A1AE1; Fri, 24 Oct 2014 16:18:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.912
X-Spam-Level: 
X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqaGQoTAlzjP; Fri, 24 Oct 2014 16:18:14 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 1B60D1A1C06; Fri, 24 Oct 2014 16:18:14 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 69A48181C99; Fri, 24 Oct 2014 16:17:43 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 6000:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20141024231743.69A48181C99@rfc-editor.org>
Date: Fri, 24 Oct 2014 16:17:43 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/eA15Yuj0M9vY5twWE9fz4XG9M1U
Cc: drafts-update-ref@iana.org, homenet@ietf.org, rfc-editor@rfc-editor.org
Subject: [homenet] RFC 7368 on IPv6 Home Networking Architecture Principles
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 23:18:17 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7368

        Title:      IPv6 Home Networking Architecture Principles 
        Author:     T. Chown, Ed.,
                    J. Arkko, A. Brandt,
                    O. Troan, J. Weil
        Status:     Informational
        Stream:     IETF
        Date:       October 2014
        Mailbox:    tjc@ecs.soton.ac.uk, 
                    jari.arkko@piuha.net, 
                    Anders_Brandt@sigmadesigns.com, 
                    ot@cisco.com, 
                    jason.weil@twcable.com
        Pages:      49
        Characters: 125402
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-homenet-arch-17.txt

        URL:        https://www.rfc-editor.org/rfc/rfc7368.txt

This text describes evolving networking technology within residential
home networks with increasing numbers of devices and a trend towards
increased internal routing.  The goal of this document is to define a
general architecture for IPv6-based home networking, describing the
associated principles, considerations, and requirements.  The text
briefly highlights specific implications of the introduction of IPv6
for home networking, discusses the elements of the architecture, and
suggests how standard IPv6 mechanisms and addressing can be employed
in home networking.  The architecture describes the need for specific
protocol extensions for certain additional functionality.  It is
assumed that the IPv6 home network is not actively managed and runs
as an IPv6-only or dual-stack network.  There are no recommendations
in this text for the IPv4 part of the network.

This document is a product of the Home Networking Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From nobody Sat Oct 25 09:29:17 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E721A047A for ; Sat, 25 Oct 2014 09:28:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level: 
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTzi1SytJL4B for ; Sat, 25 Oct 2014 09:28:55 -0700 (PDT)
Received: from mx1.nominet.org.uk (mail.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id F18921A0032 for ; Sat, 25 Oct 2014 09:28:54 -0700 (PDT)
DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns;  h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ftmHlqZXq6lOCNCi9NeNnxwuKyyTnc43u6m0cTxEkE+zp6moOOPiX1XV DQ5LLOeN8tsRXyNS2k/q6Htark7TMCRj+xqdFPncnCWr7ZHHkfkjX/adz pC8tpZHX6QCJyD0JrVi89yrG79ChsI54UEfL4Kl9shIrfBhgHXpjQLT2O rIuyHfrethrnmZKeJ4jh4qpYp3+9K/ukH3mOE8pbPSX1KSIDIozRg7fyf vA3GvwDGgspXvd4/4pSiekCiDWINg;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1414254535; x=1445790535; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ty3YE6oorLx8PaSpFKAV+yWLXbmVZzgnKu6XdQda/j0=; b=fcbV/W8KD+D19ISK93n+dDVfZ+Lg5JK+Bdh86TIznKsfd36VCcvcp8Mx N6cA6qtKqLjOs+lAk3esttZXfSGrwSlEB+EyGDgoJkGWmEVYcG+/kZ3wf trO6VqvQ1uSlIM3BOuqZ3GoRF8F295X4rDN2LPchltizwpLgCA/UuMzbi YkCqa1trrxmaFfleJl1B7jF6/pytwF8s5GQbuaDL4LBN3U0iQmT1COOOG +0J1ZMj+Tgo+aT7EZzdXlcK0y8FTp;
X-IronPort-AV: E=Sophos;i="5.04,787,1406588400"; d="scan'208";a="14167418"
X-IPAS-Result: Al4FAKrOS1TV+MWR/2dsb2JhbABcgmsjVFjNHR8KhnlUAoEFFgEBcQuEAgEBAQECAQEBATcUBRsQCwIBCBICBAwSECcKARcOAgQTFAcCBIgXCgMJyFgBAQEBBgEBAQEBAQEBAQEBEwSNOoJ7IDqCNlMkgR4Flk+dQIIOgWpsAYEOgTwBAQE
Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 25 Oct 2014 17:28:52 +0100
Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%16]) with mapi id 14.03.0181.006; Sat, 25 Oct 2014 17:28:52 +0100
From: Ray Bellis 
To: "homenet@ietf.org" 
Thread-Topic: [homenet] RFC 7368 on IPv6 Home Networking Architecture Principles
Thread-Index: AQHP7+EgmXyHT13omk26Tf6YJAcS2pxBAcPj
Date: Sat, 25 Oct 2014 16:28:51 +0000
Message-ID: 
References: <20141024231743.69A48181C99@rfc-editor.org>
In-Reply-To: <20141024231743.69A48181C99@rfc-editor.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/60HZj996uUaNhNr--iPxMe_A4qM
Subject: Re: [homenet] RFC 7368 on IPv6 Home Networking Architecture Principles
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Oct 2014 16:28:58 -0000

Congratulations and thanks to the team for their work on this document, esp=
ecially to Tim Chown!

Ray

> On 25 Oct 2014, at 00:20, "rfc-editor@rfc-editor.org"  wrote:
>=20
> A new Request for Comments is now available in online RFC libraries.
>=20
>=20
>        RFC 7368
>=20
>        Title:      IPv6 Home Networking Architecture Principles=20
>        Author:     T. Chown, Ed.,
>                    J. Arkko, A. Brandt,
>                    O. Troan, J. Weil
>        Status:     Informational
>        Stream:     IETF
>        Date:       October 2014
>        Mailbox:    tjc@ecs.soton.ac.uk,=20
>                    jari.arkko@piuha.net,=20
>                    Anders_Brandt@sigmadesigns.com,
>                    ot@cisco.com,=20
>                    jason.weil@twcable.com
>        Pages:      49
>        Characters: 125402
>        Updates/Obsoletes/SeeAlso:   None
>=20
>        I-D Tag:    draft-ietf-homenet-arch-17.txt
>=20
>        URL:        https://www.rfc-editor.org/rfc/rfc7368.txt
>=20
> This text describes evolving networking technology within residential
> home networks with increasing numbers of devices and a trend towards
> increased internal routing.  The goal of this document is to define a
> general architecture for IPv6-based home networking, describing the
> associated principles, considerations, and requirements.  The text
> briefly highlights specific implications of the introduction of IPv6
> for home networking, discusses the elements of the architecture, and
> suggests how standard IPv6 mechanisms and addressing can be employed
> in home networking.  The architecture describes the need for specific
> protocol extensions for certain additional functionality.  It is
> assumed that the IPv6 home network is not actively managed and runs
> as an IPv6-only or dual-stack network.  There are no recommendations
> in this text for the IPv4 part of the network.
>=20
> This document is a product of the Home Networking Working Group of the IE=
TF.
>=20
>=20
> INFORMATIONAL: This memo provides information for the Internet community.
> It does not specify an Internet standard of any kind. Distribution of
> this memo is unlimited.
>=20
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>  https://www.ietf.org/mailman/listinfo/ietf-announce
>  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>=20
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/rfc.html
>=20
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>=20
>=20
> The RFC Editor Team
> Association Management Solutions, LLC
>=20
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From nobody Mon Oct 27 06:04:07 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DB21A8ADF for ; Mon, 27 Oct 2014 06:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.227
X-Spam-Level: 
X-Spam-Status: No, score=0.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfQwqvfzXaAd for ; Mon, 27 Oct 2014 06:03:50 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id B59BB1A0366 for ; Mon, 27 Oct 2014 06:03:49 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s9RD3nXN017786 for ; Mon, 27 Oct 2014 07:03:49 -0600
Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 27 Oct 2014 07:03:49 -0600 (MDT)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 07:03:48 -0600
From: Michael Kloberdans 
To: "homenet@ietf.org" 
Thread-Topic: Comments requested for draft CER-ID
Thread-Index: AQHP8eZyBnMT2tvAoEOB5hY9+dInug==
Date: Mon, 27 Oct 2014 13:03:48 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.4.2.9]
Content-Type: multipart/alternative; boundary="_000_D0739ED2D31Dmkloberdanscablelabscom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/PziPzCVTiqGadEt2EGa_XLjrwDA
Subject: [homenet] Comments requested for draft CER-ID
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 13:03:54 -0000

--_000_D0739ED2D31Dmkloberdanscablelabscom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

As co-chair of the Homenet working group, Mark Townsley suggested that the =
Homenet group provide comments on the CER-ID (Customer Edge Router Identifi=
cation), draft before adding it to the Homenet agenda for IETF-91.

This draft proposes a DHCP option that explicitly identifies a specific hom=
e router as the edge between the boundary of the public and private network=
s at the home.  The CER has a public-facing interface and one or more inter=
nal-facing interface(s).  Conversely, it also identifies internal routers t=
hat are not at the boundary edge.  Knowing the edge is important for applyi=
ng services such as a firewall, NAPT and requesting IPv6 PDs.

This draft also provides a mechanism to change the default automatically or=
 manually assigned edge router.  This draft peacefully co-exists with other=
 border detection and other assignment methods.  The CER-ID draft features =
have already been incorporated into Cable Industry specifications for eRout=
er (Cable Modem integrated into a routing, switching unit), but could also =
be helpful to TELCO and other industries.

Flexibility was built-in by allowing multiple numbering schemes to identify=
 the CER, including up to 128-bits for an IPv6 address.  A simple number ca=
n also be used to act as a flag if desired.  Again, the ability to manually=
 or automatically move the designation of the edge router is available by u=
sing a double colon =91::=92 in the CER-ID field and indicates that router =
is NOT the Edge router.

Behaviors resulting from the knowledge of the CER are left to other impleme=
ntations.  One implementation detects the CER and disables firewall, NAPT a=
nd allocates PD requests for all Internal Routers (non-CER), but this is ju=
st one example of applying behaviors based on knowing where the CER lies.

Please read this short draft below and provide comments.

Regards,





Network Working Group                                          C. Donley
Internet-Draft                                             M. Kloberdans
Intended status: Informational                                 CableLabs
Expires: February 13, 2015                                 J. Brzozowski
                                                                 Comcast
                                                           C. Grundemann
                                                                    ISOC
                                                         August 12, 2014


               Customer Edge Router Identification Option
                   draft-donley-dhc-cer-id-option-04

Abstract

   Addressing mechanisms supporting DHCPv6 Prefix Delegation in home
   networks such as those described in CableLabs' eRouter specification
   and the HIPnet Internet-Draft require identification of the customer
   edge router (CER) as the demarcation between the customer network and
   the service provider network.  This document reserves a DHCPv6 option
   to identify the CER.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 13, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Donley, et al.          Expires February 13, 2015               [Page 1]
Internet-Draft                cer-id-option                  August 2014


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  CER Identification Option . . . . . . . . . . . . . . . . . .   2
   3.  CER-ID Compatibility  . . . . . . . . . . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   Some addressing mechanisms supporting DHCPv6 Prefix Delegation in
   home networks such as those described in
   [I-D.grundemann-homenet-hipnet] and [EROUTER] require identification
   of the customer edge router as the demarcation between the customer
   network and the service provider network.  For prefix delegation
   purposes, it is desirable for other routers within the home to know
   which device is the CER so that the customer home network only
   requests a single prefix from the ISP DHCPv6 server, and efficiently
   distributes this prefix within the home.  CER-ID is a 128-bit string
   that optionally represents an IPV6 address, or another arbitrary
   number.  The CER-ID maybe treated as a hint to be used with border
   detection methods.  This document reserves a DHCPv6 option to be used
   to identify the CER.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  CER Identification Option

   A Customer Edge Router (CER) sets the CER_ID to the IPv6 address of
   its LAN interface.  If it has more than one LAN IPv6 address, it
   selects one of its LAN or loopback IPv6 addresses to be used in the
   CER_ID.  An ISP server does not respond with the CER_ID or sets the



Donley, et al.          Expires February 13, 2015               [Page 2]
Internet-Draft                cer-id-option                  August 2014


   CER_ID to ::.  Such a response or lack of response indicates to the
   DHCPv6 client that it is the CER.

   The format of the CER Identification option is:

    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-code              |      option-len               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           CER_ID                              |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       option-code          OPTION_CER_ID (TBD).
       option-len           36
       CER_ID value         IPv6 address of CER or ::

   Figure 1.

   A DHCPv6 client SHOULD include the CER Identification option code in
   an Option Request option [RFC3315] in its DHCP Solicit messages.

   The DHCPv6 server MAY include the CER Identification option in any
   response it sends to a client that has included the CER
   Identification option code in an Option Request option.  The CER
   Identification option is sent in the main body of the message to
   client, not as a sub-option in, e.g., an IA_NA, IA_TA
   [RFC3315]option.

   When sending the CER Identification option, the DHCPv6 server MUST
   set the CER_ID value to either one of its IPv6 addresses, another
   identifier, or ::. If a device does not receive the CER
   Identification Option or receives a CER ID of :: from the DHCPv6
   server, it MUST include one of its Globally Unique IPv6 addresses
   (unless another identifier is used), in the CER_ID value in response
   to DHCPv6 messages received by its DHCPv6 server that contains the
   CER Identification option code in an Option Request option.  If the
   device has only one LAN interface, it SHOULD use its LAN IPv6 address
   as the CER_ID value.  If the device has more than one LAN interface,
   it SHOULD use the lowest Globally Unique address not assigned to its
   WAN interface.








Donley, et al.          Expires February 13, 2015               [Page 3]
Internet-Draft                cer-id-option                  August 2014


3.  CER-ID Compatibility

   CER-ID explicitly indicates that a gateway is, or is not, the
   demarcation point between public and private networks by containing a
   reachable IPv6 address, other identifier or a double colon '::'
   (double colon indicates that the CER-ID sender is NOT the edge
   router), and as a compliment, can be applied to various border
   definitions and detection methods such as:

   o  I.D.  Draft-IETF-Homenet-Arch-16 [I-D.ietf-homenet-arch]

   o  I.D.  Draft-Grundemann-homenet-HIPnet-01
      [I-D.grundemann-homenet-hipnet]

   o  I.D.  Draft-IETF-Kline-Homenet-Default-Perimeter-01
      [I-D.kline-default-perimeter]

   o  Others, including manual configuration

4.  IANA Considerations

   IANA is requested to assign an option code from the "DHCP Option
   Codes" Registry for OPTION_CER_ID.  IANA is also requested to
   maintain a list of authentication options.

5.  Security Considerations

   The security of a home network is an important consideration.  Both
   the HIPNet [I-D.grundemann-homenet-hipnet] and Homenet
   [I-D.ietf-homenet-arch] approaches change the operational model of
   the home network vs. today's IPv4-only paradigm.  Specifically, these
   networks eliminate NAT inside the home network (and only enable it
   for IPv4 at the edge router, if required), support global
   addressability of devices, and thus need to consider firewall and/or
   filter support in various home routers.  As the security profile of
   these home routers can shift based on their position in the network
   (e.g., edge vs. internal), security can be severely compromised if
   routers misidentify their border and mistakenly reduce or eliminate
   firewall rules.  If the CER-ID option is used as part of the border
   detection algorithm, it becomes a natural, but not the only place to
   enact firewall, NAT, Prefix Delegation and other functions in the
   home network.

6.  Acknowledgements







Donley, et al.          Expires February 13, 2015               [Page 4]
Internet-Draft                cer-id-option                  August 2014


7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

7.2.  Informative References

   [EROUTER]  CableLabs, "CableLabs IPv4 and IPv6 eRouter Specification
              (CM-SP-eRouter-I12-131120)", April 2014.

   [I-D.grundemann-homenet-hipnet]
              Grundemann, C., Donley, C., Brzozowski, J., Howard, L.,
              and V. Kuarsingh, "A Near Term Solution for Home IP
              Networking (HIPnet)", draft-grundemann-homenet-hipnet-01
              (work in progress), February 2013.

   [I-D.ietf-homenet-arch]
              Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
              "IPv6 Home Networking Architecture Principles", draft-
              ietf-homenet-arch-16 (work in progress), June 2014.

   [I-D.kline-default-perimeter]
              Kline, E., "Default Border Definition", draft-kline-
              default-perimeter-01 (work in progress), November 2012.

Authors' Addresses

   Chris Donley
   CableLabs
   858 Coal Creek Cir.
   Louisville, CO  80027
   US

   Email: c.donley@cablelabs.com











Donley, et al.          Expires February 13, 2015               [Page 5]
Internet-Draft                cer-id-option                  August 2014


   Michael Kloberdans
   CableLabs
   858 Coal Creek Cir
   Louisville, CO  80027
   US

   Email: m.kloberdans@cablelabs.com


   John Brzozowski
   Comcast
   1306 Goshen Parkway
   West Chester, PA  19380
   US

   Email: john_brzozowski@cable.comcast.com


   Chris Grundemann
   ISOC
   Denver  CO

   Email: cgrundemann@gmail.com




























Donley, et al.          Expires February 13, 2015               [Page 6]

Michael Kloberdans
Lead Architect / Home Networking     CableLabs=AE

858 Coal Creek Circle.  Louisville, CO. 80027
303-661-3813 (v)

--_000_D0739ED2D31Dmkloberdanscablelabscom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <8C40FF0176F46A44A159F25DF77436D0@cablelabs.com>
Content-Transfer-Encoding: quoted-printable













As co-chair of the Homenet working group, Mark Townsley suggested that=
 the Homenet group provide comments on the CER-ID (Customer Edge Router Ide=
ntification), draft before adding it to the Homenet agenda for IETF-91. &nb=
sp;







This draft proposes a DHCP option that explicitly identifies a specifi=
c home router as the edge between the boundary of the public and private ne=
tworks at the home.  The CER has a public-facing interface and one or =
more internal-facing interface(s).  Conversely,
 it also identifies internal routers that are not at the boundary edge. &nb=
sp;Knowing the edge is important for applying services such as a firewall, =
NAPT and requesting IPv6 PDs.  







This draft also provides a mechanism to change the default automatical=
ly or manually assigned edge router.  This draft peacefully co-exists =
with other border detection and other assignment methods.  The CER-ID =
draft features have already been incorporated
 into Cable Industry specifications for eRouter (Cable Modem integrated int=
o a routing, switching unit), but could also be helpful to TELCO and other =
industries.







Flexibility was built-in by allowing multiple numbering schemes to ide=
ntify the CER, including up to 128-bits for an IPv6 address.  A simple=
 number can also be used to act as a flag if desired.  Again, the abil=
ity to manually or automatically move the
 designation of the edge router is available by using a double colon =91::=
=92 in the CER-ID field and indicates that router is NOT the Edge router. &=
nbsp;







Behaviors resulting from the knowledge of the CER are left to other im=
plementations.  One implementation detects the CER and disables firewa=
ll, NAPT and allocates PD requests for all Internal Routers (non-CER), but =
this is just one example of applying
 behaviors based on knowing where the CER lies.







Please read this short draft below and provide comments.







Regards,





























Network Working Grou=
p                     &nb=
sp;                    C.=
 Donley


Internet-Draft  =
;                     &nb=
sp;                     M=
. Kloberdans


Intended status: Inf=
ormational                   &=
nbsp;             CableLabs


Expires: February 13=
, 2015                    =
;             J. Brzozowski


     =
                     &nbs=
p;                     &n=
bsp;                Comcast<=
/div>

     =
                     &nbs=
p;                     &n=
bsp;          C. Grundemann


     =
                     &nbs=
p;                     &n=
bsp;                   ISOC


     =
                     &nbs=
p;                     &n=
bsp;        August 12, 2014












     =
          Customer Edge Router Identification Opti=
on


     =
              draft-donley-dhc-cer-id-op=
tion-04







Abstract






   Address=
ing mechanisms supporting DHCPv6 Prefix Delegation in home


   network=
s such as those described in CableLabs' eRouter specification


   and the=
 HIPnet Internet-Draft require identification of the customer


   edge ro=
uter (CER) as the demarcation between the customer network and


   the ser=
vice provider network.  This document reserves a DHCPv6 option<=
/div>

   to iden=
tify the CER.







Status of This Memo<=
/font>







   This In=
ternet-Draft is submitted in full conformance with the


   provisi=
ons of BCP 78 and BCP 79.







   Interne=
t-Drafts are working documents of the Internet Engineering


   Task Fo=
rce (IETF).  Note that other groups may also distribute


   working=
 documents as Internet-Drafts.  The list of current Internet-







   Interne=
t-Drafts are draft documents valid for a maximum of six months


   and may=
 be updated, replaced, or obsoleted by other documents at any


   time. &=
nbsp;It is inappropriate to use Internet-Drafts as reference


   materia=
l or to cite them other than as "work in progress."







   This In=
ternet-Draft will expire on February 13, 2015.







Copyright Notice







   Copyrig=
ht (c) 2014 IETF Trust and the persons identified as the


   documen=
t authors.  All rights reserved.







   This do=
cument is subject to BCP 78 and the IETF Trust's Legal


   Provisi=
ons Relating to IETF Documents


   (http://trustee.ietf.org/license-=
info) in effect on the date of


   publica=
tion of this document.  Please review these documents

















Donley, et al.  =
;        Expires February 13, 2015      =
         [Page 1]




Internet-Draft  =
;              cer-id-option   &nbs=
p;              August 2014












   careful=
ly, as they describe your rights and restrictions with respect


   to this=
 document.  Code Components extracted from this document must

   include=
 Simplified BSD License text as described in Section 4.e of


   the Tru=
st Legal Provisions and are provided without warranty as


   describ=
ed in the Simplified BSD License.







Table of Contents







   1. &nbs=
p;Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  =
 2


     =
1.1.  Requirements Language . . . . . . . . . . . . . . . . . .  =
 2


   2. &nbs=
p;CER Identification Option . . . . . . . . . . . . . . . . . .   2


   3. &nbs=
p;CER-ID Compatibility  . . . . . . . . . . . . . . . . . . . .  =
 4


   4. &nbs=
p;IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4


   5. &nbs=
p;Security Considerations . . . . . . . . . . . . . . . . . . .   4


   6. &nbs=
p;Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  =
 4


   7. &nbs=
p;References  . . . . . . . . . . . . . . . . . . . . . . . . .  =
 5


     =
7.1.  Normative References  . . . . . . . . . . . . . . . . . . &=
nbsp; 5


     =
7.2.  Informative References  . . . . . . . . . . . . . . . . . &=
nbsp; 5


   Authors=
' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5







1.  Introductio=
n







   Some ad=
dressing mechanisms supporting DHCPv6 Prefix Delegation in


   home ne=
tworks such as those described in


   [I-D.gr=
undemann-homenet-hipnet] and [EROUTER] require identification


   of the =
customer edge router as the demarcation between the customer


   network=
 and the service provider network.  For prefix delegation


   purpose=
s, it is desirable for other routers within the home to know


   which d=
evice is the CER so that the customer home network only


   request=
s a single prefix from the ISP DHCPv6 server, and efficiently


   distrib=
utes this prefix within the home.  CER-ID is a 128-bit string

   that op=
tionally represents an IPV6 address, or another arbitrary


   number.=
  The CER-ID maybe treated as a hint to be used with border

   detecti=
on methods.  This document reserves a DHCPv6 option to be used<=
/div>

   to iden=
tify the CER.







1.1.  Requireme=
nts Language







   The key=
 words "MUST", "MUST NOT", "REQUIRED", "=
SHALL", "SHALL NOT",


   "S=
HOULD", "SHOULD NOT", "RECOMMENDED", "MAY&quo=
t;, and "OPTIONAL" in this


   documen=
t are to be interpreted as described in RFC 2119 [RFC2119].







2.  CER Identif=
ication Option







   A Custo=
mer Edge Router (CER) sets the CER_ID to the IPv6 address of


   its LAN=
 interface.  If it has more than one LAN IPv6 address, it


   selects=
 one of its LAN or loopback IPv6 addresses to be used in the


   CER_ID.=
  An ISP server does not respond with the CER_ID or sets the
















Donley, et al.  =
;        Expires February 13, 2015      =
         [Page 2]




Internet-Draft  =
;              cer-id-option   &nbs=
p;              August 2014












   CER_ID =
to ::.  Such a response or lack of response indicates to the

   DHCPv6 =
client that it is the CER.







   The for=
mat of the CER Identification option is:







    0 &nbs=
p;                 1     =
              2       &nb=
sp;           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


   +-&=
#43;-+-+-+-+-+-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+-+-+-&=
#43;-+-+-+-+-+-+


   |  =
;    option-code              =
|      option-len             =
  |


   +-&=
#43;-+-+-+-+-+-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+-+-+-&=
#43;-+-+-+-+-+-+


   |  =
;                     &nb=
sp;                     &=
nbsp;                 |

   |  =
;                     &nb=
sp;   CER_ID                 &=
nbsp;            |


   |  =
;                     &nb=
sp;                     &=
nbsp;                 |

   |  =
;                     &nb=
sp;                     &=
nbsp;                 |

   +-&=
#43;-+-+-+-+-+-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+-+-+-&=
#43;-+-+-+-+-+-+


     =
  option-code          OPTION_CER_ID (TBD).


     =
  option-len           36


     =
  CER_ID value         IPv6 address of CER or ::







   Figure =
1.







   A DHCPv=
6 client SHOULD include the CER Identification option code in


   an Opti=
on Request option [RFC3315] in its DHCP Solicit messages.







   The DHC=
Pv6 server MAY include the CER Identification option in any


   respons=
e it sends to a client that has included the CER


   Identif=
ication option code in an Option Request option.  The CER


   Identif=
ication option is sent in the main body of the message to


   client,=
 not as a sub-option in, e.g., an IA_NA, IA_TA


   [RFC331=
5]option.







   When se=
nding the CER Identification option, the DHCPv6 server MUST


   set the=
 CER_ID value to either one of its IPv6 addresses, another


   identif=
ier, or ::. If a device does not receive the CER


   Identif=
ication Option or receives a CER ID of :: from the DHCPv6


   server,=
 it MUST include one of its Globally Unique IPv6 addresses


   (unless=
 another identifier is used), in the CER_ID value in response


   to DHCP=
v6 messages received by its DHCPv6 server that contains the


   CER Ide=
ntification option code in an Option Request option.  If the

   device =
has only one LAN interface, it SHOULD use its LAN IPv6 address


   as the =
CER_ID value.  If the device has more than one LAN interface,

   it SHOU=
LD use the lowest Globally Unique address not assigned to its


   WAN int=
erface.










































Donley, et al.  =
;        Expires February 13, 2015      =
         [Page 3]




Internet-Draft  =
;              cer-id-option   &nbs=
p;              August 2014












3.  CER-ID Comp=
atibility







   CER-ID =
explicitly indicates that a gateway is, or is not, the


   demarca=
tion point between public and private networks by containing a


   reachab=
le IPv6 address, other identifier or a double colon '::'


   (double=
 colon indicates that the CER-ID sender is NOT the edge


   router)=
, and as a compliment, can be applied to various border


   definit=
ions and detection methods such as:







   o  =
;I.D.  Draft-IETF-Homenet-Arch-16 [I-D.ietf-homenet-arch]







   o  =
;I.D.  Draft-Grundemann-homenet-HIPnet-01


     =
 [I-D.grundemann-homenet-hipnet]







   o  =
;I.D.  Draft-IETF-Kline-Homenet-Default-Perimeter-01


     =
 [I-D.kline-default-perimeter]







   o  =
;Others, including manual configuration







4.  IANA Consid=
erations







   IANA is=
 requested to assign an option code from the "DHCP Option


   Codes&q=
uot; Registry for OPTION_CER_ID.  IANA is also requested to

   maintai=
n a list of authentication options.







5.  Security Co=
nsiderations







   The sec=
urity of a home network is an important consideration.  Both

   the HIP=
Net [I-D.grundemann-homenet-hipnet] and Homenet


   [I-D.ie=
tf-homenet-arch] approaches change the operational model of


   the hom=
e network vs. today's IPv4-only paradigm.  Specifically, these<=
/div>

   network=
s eliminate NAT inside the home network (and only enable it


   for IPv=
4 at the edge router, if required), support global


   address=
ability of devices, and thus need to consider firewall and/or


   filter =
support in various home routers.  As the security profile of

   these h=
ome routers can shift based on their position in the network


   (e.g., =
edge vs. internal), security can be severely compromised if


   routers=
 misidentify their border and mistakenly reduce or eliminate


   firewal=
l rules.  If the CER-ID option is used as part of the border

   detecti=
on algorithm, it becomes a natural, but not the only place to


   enact f=
irewall, NAT, Prefix Delegation and other functions in the


   home ne=
twork.







6.  Acknowledge=
ments





































Donley, et al.  =
;        Expires February 13, 2015      =
         [Page 4]




Internet-Draft  =
;              cer-id-option   &nbs=
p;              August 2014












7.  References<=
/font>







7.1.  Normative=
 References







   [RFC211=
9]  Bradner, S., "Key words for use in RFCs to Indicate

     =
         Requirement Levels", BCP 14, RFC 2119, Ma=
rch 1997.







   [RFC331=
5]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,

     =
         and M. Carney, "Dynamic Host Configuratio=
n Protocol for


     =
         IPv6 (DHCPv6)", RFC 3315, July 2003.







7.2.  Informati=
ve References







   [EROUTE=
R]  CableLabs, "CableLabs IPv4 and IPv6 eRouter Specification


     =
         (CM-SP-eRouter-I12-131120)", April 2014.<=
/font>







   [I-D.gr=
undemann-homenet-hipnet]


     =
         Grundemann, C., Donley, C., Brzozowski, J., Ho=
ward, L.,


     =
         and V. Kuarsingh, "A Near Term Solution f=
or Home IP


     =
         Networking (HIPnet)", draft-grundemann-ho=
menet-hipnet-01


     =
         (work in progress), February 2013.






   [I-D.ie=
tf-homenet-arch]


     =
         Chown, T., Arkko, J., Brandt, A., Troan, O., a=
nd J. Weil,


     =
         "IPv6 Home Networking Architecture Princi=
ples", draft-


     =
         ietf-homenet-arch-16 (work in progress), June =
2014.







   [I-D.kl=
ine-default-perimeter]


     =
         Kline, E., "Default Border Definition&quo=
t;, draft-kline-


     =
         default-perimeter-01 (work in progress), Novem=
ber 2012.







Authors' Addresses







   Chris D=
onley


   CableLa=
bs


   858 Coa=
l Creek Cir.


   Louisvi=
lle, CO  80027


   US







   Email:&=
nbsp;c.donley@cablelabs.com

























































Donley, et al.  =
;        Expires February 13, 2015      =
         [Page 5]




Internet-Draft  =
;              cer-id-option   &nbs=
p;              August 2014












   Michael=
 Kloberdans


   CableLa=
bs


   858 Coa=
l Creek Cir


   Louisvi=
lle, CO  80027


   US







   Email:&=
nbsp;m.kloberdans@cablelabs.c=
om












   John Br=
zozowski


   Comcast=



   1306 Go=
shen Parkway


   West Ch=
ester, PA  19380


   US


















   Chris G=
rundemann


   ISOC


   Denver =
 CO







   Email:&=
nbsp;cgrundemann@gmail.com














































































































































Donley, et al.  =
;        Expires February 13, 2015      =
         [Page 6]













Michael Kloberdans


Lead Architect / Home Networking    
CableLabs=AE







858 Coal Creek Circle.  Louisville, CO. 80027


303-661-3813 (v)










--_000_D0739ED2D31Dmkloberdanscablelabscom_--


From nobody Mon Oct 27 06:21:18 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F181A923E for ; Mon, 27 Oct 2014 06:21:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.279
X-Spam-Level: 
X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fQoC6htDXXh for ; Mon, 27 Oct 2014 06:21:00 -0700 (PDT)
Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.194]) by ietfa.amsl.com (Postfix) with ESMTP id B82091AC428 for ; Mon, 27 Oct 2014 06:20:52 -0700 (PDT)
Received: from poro.lan (80.220.64.126) by jenni1.inet.fi (8.5.142.08) (authenticated as stenma-47) id 541949910365C1D5; Mon, 27 Oct 2014 15:20:48 +0200
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Markus Stenberg 
In-Reply-To: 
Date: Mon, 27 Oct 2014 15:20:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Michael Kloberdans 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/5j10Rc7vvB6tW7esEml7z9Yud50
Cc: "homenet@ietf.org" , Markus Stenberg 
Subject: Re: [homenet] Comments requested for draft CER-ID
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 13:21:01 -0000

On 27.10.2014, at 15.03, Michael Kloberdans  =
wrote:
> Behaviors resulting from the knowledge of the CER are left to other =
implementations.  One implementation detects the CER and disables =
firewall, NAPT and allocates PD requests for all Internal Routers =
(non-CER), but this is just one example of applying behaviors based on =
knowing where the CER lies.

First, draft comments..

Section 2 - why clients SHOULD send the ORO for this at all? Perhaps it =
is MAY, just server responding with one.  Why use WAN _or_ unique LAN =
interface address? Inconsistency is not a plus. Also, it is not obvious =
to me what to do if  it has one LAN interface but multiple addresses..

Then, non-draft comments ..

I am not sure evil bit (that ISP must obviously be nice enough to set, =
i.e. cer_id ::) is really what I would trust my firewalling decisions =
on. In Cablelabs context this is especially puzzling, as you have =
ISP-facing holes (with weird antenna-style bits in them), and home =
facing holes (RJ45 or wireless). Why is this autodetection needed at all =
there? Or is it just so ISP _can_ turn off the firewall if they want to, =
or government wants to force them to do so?

Cheers,

-Markus


From nobody Mon Oct 27 07:18:30 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5B01ACDA5 for ; Mon, 27 Oct 2014 07:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.226
X-Spam-Level: 
X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEQxAYfbqlvo for ; Mon, 27 Oct 2014 07:17:48 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA521ACDA7 for ; Mon, 27 Oct 2014 07:17:48 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s9REHlnB025496; Mon, 27 Oct 2014 08:17:47 -0600
Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 27 Oct 2014 08:17:47 -0600 (MDT)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 08:17:46 -0600
From: Michael Kloberdans 
To: Markus Stenberg 
Thread-Topic: [homenet] Comments requested for draft CER-ID
Thread-Index: AQHP8eZyBnMT2tvAoEOB5hY9+dInupxEUmmA//+rVgA=
Date: Mon, 27 Oct 2014 14:17:46 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.4.2.9]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <69FE9A69D662B54DB49547966B77E433@cablelabs.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/L1rjVQANHreykBc41e9jnh9Gdgg
Cc: "homenet@ietf.org" 
Subject: Re: [homenet] Comments requested for draft CER-ID
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 14:17:51 -0000

Markus,
All home routers should know their role; CER or IR.  The status of CER
places the burden of providing the firewall and NAPT as it was determined
to be the edge router.  The interior routers need to understand their role
and disable their firewall and NAPT abilities.  This is why the CER-ID is
a numeric value (indicating CER status) or a double colon (indicating IR
status).=20
=20
In the case of the eRouter (combined cable modem and
router/switch/wireless), it performs a /48 check between the IA_NA and the
IA_PD ranges.  If the ISP sends a double colon or null in the CER-ID ORO,
AND if the IA_NA is in a different /48 than the given IA_PD, the eRouter
becomes the CER.  It must now declare to the IRs that it is the CER.  A
directly connected IR will see the CER value in the ORO and, in the
absence of another controlling protocol, disable its firewall and NAPT
functions.

Having all IRs understand their role is allows consistent behaviors.


CER-ID can be any numeric value.  A simple number can act as a flag.  An
IPv6 address is urged because it allows communications between the CER and
the IRs, and may be used in the cable industry.

The nice advantage of the double colon is for network literate people like
yourself to manually determine where the boundary between public and
private network will be.  If you didn=B9t want the Cable or DSL modem to be
the CER, manually give them a =8C::=B2 and assign a CER-ID to a downstream
router.  Thus, CER-ID allows for automatic detection of the CER and
uniform behavior of IRs within the home and also a way to design your
network the way you desire.

Comments?


Michael Kloberdans
Lead Architect / Home Networking     CableLabs=AE

858 Coal Creek Circle.  Louisville, CO. 80027
303-661-3813 (v)




On 10/27/14, 7:20 AM, "Markus Stenberg"  wrote:

>On 27.10.2014, at 15.03, Michael Kloberdans 
>wrote:
>> Behaviors resulting from the knowledge of the CER are left to other
>>implementations.  One implementation detects the CER and disables
>>firewall, NAPT and allocates PD requests for all Internal Routers
>>(non-CER), but this is just one example of applying behaviors based on
>>knowing where the CER lies.
>
>First, draft comments..
>
>Section 2 - why clients SHOULD send the ORO for this at all? Perhaps it
>is MAY, just server responding with one.  Why use WAN _or_ unique LAN
>interface address? Inconsistency is not a plus. Also, it is not obvious
>to me what to do if  it has one LAN interface but multiple addresses..
>
>Then, non-draft comments ..
>
>I am not sure evil bit (that ISP must obviously be nice enough to set,
>i.e. cer_id ::) is really what I would trust my firewalling decisions on.
>In Cablelabs context this is especially puzzling, as you have ISP-facing
>holes (with weird antenna-style bits in them), and home facing holes
>(RJ45 or wireless). Why is this autodetection needed at all there? Or is
>it just so ISP _can_ turn off the firewall if they want to, or government
>wants to force them to do so?
>
>Cheers,
>
>-Markus
>


From nobody Mon Oct 27 07:39:04 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583E31A875B; Mon, 27 Oct 2014 07:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GZMU_qJNBLz; Mon, 27 Oct 2014 07:38:19 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 818671A8721; Mon, 27 Oct 2014 07:38:04 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141027143804.20449.48327.idtracker@ietfa.amsl.com>
Date: Mon, 27 Oct 2014 07:38:04 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/yO5zIvfGxbm6x_1FnLkhk4AvW2A
Cc: homenet@ietf.org
Subject: [homenet] I-D Action: draft-ietf-homenet-hncp-02.txt
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 14:38:21 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Home Networking Working Group of the IETF.

        Title           : Home Networking Control Protocol
        Authors         : Markus Stenberg
                          Steven Barth
	Filename        : draft-ietf-homenet-hncp-02.txt
	Pages           : 26
	Date            : 2014-10-27

Abstract:
   This document describes the Home Networking Control Protocol (HNCP),
   a minimalist state synchronization protocol for homenet routers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-homenet-hncp-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-hncp-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Mon Oct 27 07:42:34 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130F61A87DE for ; Mon, 27 Oct 2014 07:41:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eFlldcDk7YE for ; Mon, 27 Oct 2014 07:41:54 -0700 (PDT)
Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.194]) by ietfa.amsl.com (Postfix) with ESMTP id EA0101ACDBE for ; Mon, 27 Oct 2014 07:41:53 -0700 (PDT)
Received: from poro.lan (80.220.64.126) by kirsi1.inet.fi (8.5.142.08) (authenticated as stenma-47) id 5425273602AA763E; Mon, 27 Oct 2014 16:41:53 +0200
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Markus Stenberg 
In-Reply-To: <20141027143804.20449.48327.idtracker@ietfa.amsl.com>
Date: Mon, 27 Oct 2014 16:41:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20141027143804.20449.48327.idtracker@ietfa.amsl.com>
To: HOMENET Working Group 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Q4IfTk2jsXwZ1C8f-tI77KCKA8Q
Cc: Markus Stenberg 
Subject: Re: [homenet] I-D Action: draft-ietf-homenet-hncp-02.txt
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 14:41:56 -0000

On 27.10.2014, at 16.38, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Home Networking Working Group of the =
IETF.
>=20
>        Title           : Home Networking Control Protocol
>        Authors         : Markus Stenberg
>                          Steven Barth
> 	Filename        : draft-ietf-homenet-hncp-02.txt
> 	Pages           : 26
> 	Date            : 2014-10-27

Very much incremential update.

=46rom the changelog in the draft:

draft-ietf-homenet-hncp-02: Removed any built-in security. Relying
      on IPsec. Reorganized interface categories, added requirements =
languages,
      made manual border configuration a MUST-support. Redesigned =
routing
      protocol election to consider non-router devices.

(There is also informational pointer to Steven=92s security draft, which =
hopefully makes life bit better than just IPsec manual key as currently =
specified.)

For -03, there is a number of things I would like to change, but perhaps =
it is bit too early for that discussion yet.

Cheers,

-Markus=


From nobody Mon Oct 27 07:47:46 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7F61ACDD8 for ; Mon, 27 Oct 2014 07:47:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkMHtsRrOKb5 for ; Mon, 27 Oct 2014 07:47:15 -0700 (PDT)
Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.194]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7071A87E2 for ; Mon, 27 Oct 2014 07:47:15 -0700 (PDT)
Received: from poro.lan (80.220.64.126) by jenni2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 543C16C90120979F; Mon, 27 Oct 2014 16:47:11 +0200
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Markus Stenberg 
In-Reply-To: 
Date: Mon, 27 Oct 2014 16:47:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9C9AAA6C-61E0-4BAB-9BB4-DA02B74835FD@iki.fi>
References:   
To: Michael Kloberdans 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/EncMt1Tr-1H8mAMA42HQ_98Dk-s
Cc: "homenet@ietf.org" , Markus Stenberg 
Subject: Re: [homenet] Comments requested for draft CER-ID
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 14:47:16 -0000

On 27.10.2014, at 16.17, Michael Kloberdans  =
wrote:
> All home routers should know their role; CER or IR.  The status of CER
> places the burden of providing the firewall and NAPT as it was =
determined
> to be the edge router.  The interior routers need to understand their =
role
> and disable their firewall and NAPT abilities.  This is why the CER-ID =
is
> a numeric value (indicating CER status) or a double colon (indicating =
IR
> status).=20

I agree with that. However, I disagree with how you are doing it.

> In the case of the eRouter (combined cable modem and
> router/switch/wireless), it performs a /48 check between the IA_NA and =
the
> IA_PD ranges.  If the ISP sends a double colon or null in the CER-ID =
ORO,
> AND if the IA_NA is in a different /48 than the given IA_PD, the =
eRouter
> becomes the CER.  It must now declare to the IRs that it is the CER.  =
A
> directly connected IR will see the CER value in the ORO and, in the
> absence of another controlling protocol, disable its firewall and NAPT
> functions.

Why cannot it determine it is CER by bits coming from particular type of =
plug? Cable modem plug looks different from ethernet/wireless? It would =
be much more secure that way.

> The nice advantage of the double colon is for network literate people =
like
> yourself to manually determine where the boundary between public and
> private network will be.  If you didn=B9t want the Cable or DSL modem =
to be
> the CER, manually give them a =8C::=B2 and assign a CER-ID to a =
downstream
> router.  Thus, CER-ID allows for automatic detection of the CER and
> uniform behavior of IRs within the home and also a way to design your
> network the way you desire.

Again, bits coming from cable port <> not sounds much simpler to me. And =
more secure.=20

Cheers,

-Markus=


From nobody Mon Oct 27 08:01:25 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52AA91ACCE3 for ; Mon, 27 Oct 2014 08:00:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level: 
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsRe2INfy5ew for ; Mon, 27 Oct 2014 08:00:50 -0700 (PDT)
Received: from zimbra.powertech.no (zimbra-out.powertech.no [195.159.42.152]) by ietfa.amsl.com (Postfix) with ESMTP id B3EE11A885E for ; Mon, 27 Oct 2014 08:00:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by zimbra.powertech.no (Postfix) with ESMTP id AD307480076 for ; Mon, 27 Oct 2014 16:00:46 +0100 (CET)
Received: from zimbra.powertech.no ([127.0.0.1]) by localhost (zimbra.powertech.no [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id lvk57hzBMPQR for ; Mon, 27 Oct 2014 16:00:42 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by zimbra.powertech.no (Postfix) with ESMTP id CF09F480647 for ; Mon, 27 Oct 2014 16:00:42 +0100 (CET)
X-Virus-Scanned: amavisd-new at zimbra.powertech.no
Received: from zimbra.powertech.no ([127.0.0.1]) by localhost (zimbra.powertech.no [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id U_2JZrd-NtLO for ; Mon, 27 Oct 2014 16:00:42 +0100 (CET)
Received: from zimbra.powertech.no (zimbra.powertech.no [195.159.198.162]) by zimbra.powertech.no (Postfix) with ESMTP id B6A2C480076 for ; Mon, 27 Oct 2014 16:00:42 +0100 (CET)
Date: Mon, 27 Oct 2014 16:00:42 +0100 (CET)
From: Ola Thoresen 
To: homenet@ietf.org
Message-ID: <819511805.3231790.1414422042375.JavaMail.zimbra@zimbra.powertech.no>
In-Reply-To: <9C9AAA6C-61E0-4BAB-9BB4-DA02B74835FD@iki.fi>
References:    <9C9AAA6C-61E0-4BAB-9BB4-DA02B74835FD@iki.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [195.159.6.21]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - GC38 (Linux)/8.0.6_GA_5922)
Thread-Topic: Comments requested for draft CER-ID
Thread-Index: 3RlYsiMWAoHOVk4Opjf/lHX/rOyXHA==
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/GGQbsO7w7admgZnaT80DknETIFQ
Subject: Re: [homenet] Comments requested for draft CER-ID
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 15:00:53 -0000

> On 27.10.2014, at 16.17, Michael Kloberdans 
> wrote:
> > All home routers should know their role; CER or IR.  The status of CER
> > places the burden of providing the firewall and NAPT as it was determined
> > to be the edge router.  The interior routers need to understand their role
> > and disable their firewall and NAPT abilities.  This is why the CER-ID is
> > a numeric value (indicating CER status) or a double colon (indicating IR
> > status).
> 
> I agree with that. However, I disagree with how you are doing it.
> 
> > In the case of the eRouter (combined cable modem and
> > router/switch/wireless), it performs a /48 check between the IA_NA and the
> > IA_PD ranges.  If the ISP sends a double colon or null in the CER-ID ORO,
> > AND if the IA_NA is in a different /48 than the given IA_PD, the eRouter
> > becomes the CER.  It must now declare to the IRs that it is the CER.  A
> > directly connected IR will see the CER value in the ORO and, in the
> > absence of another controlling protocol, disable its firewall and NAPT
> > functions.
> 
> Why cannot it determine it is CER by bits coming from particular type of
> plug? Cable modem plug looks different from ethernet/wireless? It would be
> much more secure that way.
> 


But that would not work if the router only has ethernet-ports - which is probably the case if the customer has various kinds of FTTH (many of these will use Fast/Gig-ethernet over copper for the last meters in to the CPE).

However I do agree that the suggested solution seems sub optimal.  It is way to easy for a misconfigured router to disable all local security (IE. turning off firewalling) without the network owners knowledge.

/Ola (T)


From nobody Mon Oct 27 08:53:04 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FBE1A888E for ; Mon, 27 Oct 2014 08:53:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.226
X-Spam-Level: 
X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZJdS6cd-TUJ for ; Mon, 27 Oct 2014 08:53:01 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id E11DB1A87D1 for ; Mon, 27 Oct 2014 08:53:00 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s9RFqxgc005200; Mon, 27 Oct 2014 09:53:00 -0600
Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 27 Oct 2014 09:52:59 -0600 (MDT)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 09:52:59 -0600
From: Michael Kloberdans 
To: Markus Stenberg 
Thread-Topic: [homenet] Comments requested for draft CER-ID
Thread-Index: AQHP8eZyBnMT2tvAoEOB5hY9+dInupxEUmmA//+rVgCAAGzQgP//rcuA
Date: Mon, 27 Oct 2014 15:52:58 +0000
Message-ID: 
References:    <9C9AAA6C-61E0-4BAB-9BB4-DA02B74835FD@iki.fi>
In-Reply-To: <9C9AAA6C-61E0-4BAB-9BB4-DA02B74835FD@iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.4.2.9]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/p_DExq0uHNv25a_jXQSSOaIqaDk
Cc: "homenet@ietf.org" 
Subject: Re: [homenet] Comments requested for draft CER-ID
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 15:53:02 -0000

TWFya3VzLA0KQ0VSLUlEIGNhbiBhcHBseSB0byBtb3JlIHRoYW4ganVzdCB0aGUgY2FibGUgaW5k
dXN0cnkuICBEU0wgbW9kZW1zIGFuZA0Kc2F0ZWxsaXRlIHNlcnZpY2VzIGNhbiBhbHNvIHRha2Ug
YWR2YW50YWdlIG9mIHRoZSBiZW5lZml0cyBpZiB3ZSBkb27igJl0DQpsb2NrIGRvd24gdGhlIGlu
dGVyZmFjZS4gIEFsc28sIHNvbWUgaG9tZSBvd25lcnMgbWF5IG5vdCB3YW50IHRoZSBuYXR1cmFs
DQpib3VuZGFyeSBiZWluZyB0aGUgQ2FibGUgbW9kZW0gb3IgRFNMIG1vZGVtIGFuZCB0aGlzIHBy
b3ZpZGVzIGEgd2F5IHRvDQptYWtlIHRoYXQgaGFwcGVuLg0KDQpEbyB5b3Ugc3RpbGwgd2FudCB0
byBkaXNjdXNzIGhvdyBvciB3aHkgQ0VSLUlEIGlzIGltcGxlbWVudGVkIHRoaXMgd2F5Pw0KDQpU
aGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMgc28gZmFyLg0KDQoNCk1pY2hhZWwgS2xvYmVyZGFu
cw0KTGVhZCBBcmNoaXRlY3QgLyBIb21lIE5ldHdvcmtpbmcgICAgIENhYmxlTGFic8KuDQoNCjg1
OCBDb2FsIENyZWVrIENpcmNsZS4gIExvdWlzdmlsbGUsIENPLiA4MDAyNw0KMzAzLTY2MS0zODEz
ICh2KQ0KDQoNCg0KDQpPbiAxMC8yNy8xNCwgODo0NyBBTSwgIk1hcmt1cyBTdGVuYmVyZyIgPG1h
cmt1cy5zdGVuYmVyZ0Bpa2kuZmk+IHdyb3RlOg0KDQo+T24gMjcuMTAuMjAxNCwgYXQgMTYuMTcs
IE1pY2hhZWwgS2xvYmVyZGFucyA8bS5rbG9iZXJkYW5zQGNhYmxlbGFicy5jb20+DQo+d3JvdGU6
DQo+PiBBbGwgaG9tZSByb3V0ZXJzIHNob3VsZCBrbm93IHRoZWlyIHJvbGU7IENFUiBvciBJUi4g
IFRoZSBzdGF0dXMgb2YgQ0VSDQo+PiBwbGFjZXMgdGhlIGJ1cmRlbiBvZiBwcm92aWRpbmcgdGhl
IGZpcmV3YWxsIGFuZCBOQVBUIGFzIGl0IHdhcw0KPj5kZXRlcm1pbmVkDQo+PiB0byBiZSB0aGUg
ZWRnZSByb3V0ZXIuICBUaGUgaW50ZXJpb3Igcm91dGVycyBuZWVkIHRvIHVuZGVyc3RhbmQgdGhl
aXINCj4+cm9sZQ0KPj4gYW5kIGRpc2FibGUgdGhlaXIgZmlyZXdhbGwgYW5kIE5BUFQgYWJpbGl0
aWVzLiAgVGhpcyBpcyB3aHkgdGhlIENFUi1JRA0KPj5pcw0KPj4gYSBudW1lcmljIHZhbHVlIChp
bmRpY2F0aW5nIENFUiBzdGF0dXMpIG9yIGEgZG91YmxlIGNvbG9uIChpbmRpY2F0aW5nIElSDQo+
PiBzdGF0dXMpLiANCj4NCj5JIGFncmVlIHdpdGggdGhhdC4gSG93ZXZlciwgSSBkaXNhZ3JlZSB3
aXRoIGhvdyB5b3UgYXJlIGRvaW5nIGl0Lg0KPg0KPj4gSW4gdGhlIGNhc2Ugb2YgdGhlIGVSb3V0
ZXIgKGNvbWJpbmVkIGNhYmxlIG1vZGVtIGFuZA0KPj4gcm91dGVyL3N3aXRjaC93aXJlbGVzcyks
IGl0IHBlcmZvcm1zIGEgLzQ4IGNoZWNrIGJldHdlZW4gdGhlIElBX05BIGFuZA0KPj50aGUNCj4+
IElBX1BEIHJhbmdlcy4gIElmIHRoZSBJU1Agc2VuZHMgYSBkb3VibGUgY29sb24gb3IgbnVsbCBp
biB0aGUgQ0VSLUlEDQo+Pk9STywNCj4+IEFORCBpZiB0aGUgSUFfTkEgaXMgaW4gYSBkaWZmZXJl
bnQgLzQ4IHRoYW4gdGhlIGdpdmVuIElBX1BELCB0aGUgZVJvdXRlcg0KPj4gYmVjb21lcyB0aGUg
Q0VSLiAgSXQgbXVzdCBub3cgZGVjbGFyZSB0byB0aGUgSVJzIHRoYXQgaXQgaXMgdGhlIENFUi4g
IEENCj4+IGRpcmVjdGx5IGNvbm5lY3RlZCBJUiB3aWxsIHNlZSB0aGUgQ0VSIHZhbHVlIGluIHRo
ZSBPUk8gYW5kLCBpbiB0aGUNCj4+IGFic2VuY2Ugb2YgYW5vdGhlciBjb250cm9sbGluZyBwcm90
b2NvbCwgZGlzYWJsZSBpdHMgZmlyZXdhbGwgYW5kIE5BUFQNCj4+IGZ1bmN0aW9ucy4NCj4NCj5X
aHkgY2Fubm90IGl0IGRldGVybWluZSBpdCBpcyBDRVIgYnkgYml0cyBjb21pbmcgZnJvbSBwYXJ0
aWN1bGFyIHR5cGUgb2YNCj5wbHVnPyBDYWJsZSBtb2RlbSBwbHVnIGxvb2tzIGRpZmZlcmVudCBm
cm9tIGV0aGVybmV0L3dpcmVsZXNzPyBJdCB3b3VsZA0KPmJlIG11Y2ggbW9yZSBzZWN1cmUgdGhh
dCB3YXkuDQo+DQo+PiBUaGUgbmljZSBhZHZhbnRhZ2Ugb2YgdGhlIGRvdWJsZSBjb2xvbiBpcyBm
b3IgbmV0d29yayBsaXRlcmF0ZSBwZW9wbGUNCj4+bGlrZQ0KPj4geW91cnNlbGYgdG8gbWFudWFs
bHkgZGV0ZXJtaW5lIHdoZXJlIHRoZSBib3VuZGFyeSBiZXR3ZWVuIHB1YmxpYyBhbmQNCj4+IHBy
aXZhdGUgbmV0d29yayB3aWxsIGJlLiAgSWYgeW91IGRpZG7CuXQgd2FudCB0aGUgQ2FibGUgb3Ig
RFNMIG1vZGVtIHRvDQo+PmJlDQo+PiB0aGUgQ0VSLCBtYW51YWxseSBnaXZlIHRoZW0gYSDFkjo6
wrIgYW5kIGFzc2lnbiBhIENFUi1JRCB0byBhIGRvd25zdHJlYW0NCj4+IHJvdXRlci4gIFRodXMs
IENFUi1JRCBhbGxvd3MgZm9yIGF1dG9tYXRpYyBkZXRlY3Rpb24gb2YgdGhlIENFUiBhbmQNCj4+
IHVuaWZvcm0gYmVoYXZpb3Igb2YgSVJzIHdpdGhpbiB0aGUgaG9tZSBhbmQgYWxzbyBhIHdheSB0
byBkZXNpZ24geW91cg0KPj4gbmV0d29yayB0aGUgd2F5IHlvdSBkZXNpcmUuDQo+DQo+QWdhaW4s
IGJpdHMgY29taW5nIGZyb20gY2FibGUgcG9ydCA8PiBub3Qgc291bmRzIG11Y2ggc2ltcGxlciB0
byBtZS4gQW5kDQo+bW9yZSBzZWN1cmUuIA0KPg0KPkNoZWVycywNCj4NCj4tTWFya3VzDQoNCg==


From nobody Mon Oct 27 08:59:41 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D77B1A88DD for ; Mon, 27 Oct 2014 08:59:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.226
X-Spam-Level: 
X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyAMA9GoUqPA for ; Mon, 27 Oct 2014 08:59:38 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 52FF31A00F6 for ; Mon, 27 Oct 2014 08:59:38 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s9RFxZDY005931; Mon, 27 Oct 2014 09:59:35 -0600
Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 27 Oct 2014 09:59:34 -0600 (MDT)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 09:59:35 -0600
From: Michael Kloberdans 
To: Ola Thoresen , "homenet@ietf.org" 
Thread-Topic: [homenet] Comments requested for draft CER-ID
Thread-Index: AQHP8f8ABnMT2tvAoEOB5hY9+dInug==
Date: Mon, 27 Oct 2014 15:59:34 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.4.2.9]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/wG2GxvvL_c8SW3x_O96Ze1dw8ho
Subject: Re: [homenet] Comments requested for draft CER-ID
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 15:59:39 -0000

Ola,
I=B9d like to better understand your comment about a misconfigured router
being a security issue.

In the eRouter implementation, the CER is automatically determined.  The
only way a router would be misconfigured is if the home owner or someone
else with local access manually changes the CER.  Perhaps I=B9m missing
something. Please expound - I=B9m grateful for all comments.

Regards,


Michael Kloberdans
Lead Architect / Home Networking     CableLabs=AE

858 Coal Creek Circle.  Louisville, CO. 80027
303-661-3813 (v)




On 10/27/14, 9:00 AM, "Ola Thoresen"  wrote:

>> On 27.10.2014, at 16.17, Michael Kloberdans 
>> wrote:
>> > All home routers should know their role; CER or IR.  The status of CER
>> > places the burden of providing the firewall and NAPT as it was
>>determined
>> > to be the edge router.  The interior routers need to understand their
>>role
>> > and disable their firewall and NAPT abilities.  This is why the
>>CER-ID is
>> > a numeric value (indicating CER status) or a double colon (indicating
>>IR
>> > status).
>>=20
>> I agree with that. However, I disagree with how you are doing it.
>>=20
>> > In the case of the eRouter (combined cable modem and
>> > router/switch/wireless), it performs a /48 check between the IA_NA
>>and the
>> > IA_PD ranges.  If the ISP sends a double colon or null in the CER-ID
>>ORO,
>> > AND if the IA_NA is in a different /48 than the given IA_PD, the
>>eRouter
>> > becomes the CER.  It must now declare to the IRs that it is the CER.
>>A
>> > directly connected IR will see the CER value in the ORO and, in the
>> > absence of another controlling protocol, disable its firewall and NAPT
>> > functions.
>>=20
>> Why cannot it determine it is CER by bits coming from particular type of
>> plug? Cable modem plug looks different from ethernet/wireless? It would
>>be
>> much more secure that way.
>>=20
>
>
>But that would not work if the router only has ethernet-ports - which is
>probably the case if the customer has various kinds of FTTH (many of
>these will use Fast/Gig-ethernet over copper for the last meters in to
>the CPE).
>
>However I do agree that the suggested solution seems sub optimal.  It is
>way to easy for a misconfigured router to disable all local security (IE.
>turning off firewalling) without the network owners knowledge.
>
>/Ola (T)
>
>_______________________________________________
>homenet mailing list
>homenet@ietf.org
>https://www.ietf.org/mailman/listinfo/homenet


From nobody Mon Oct 27 11:27:35 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473521A8A88 for ; Mon, 27 Oct 2014 11:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOFCzLMQGn98 for ; Mon, 27 Oct 2014 11:27:05 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6051A0194 for ; Mon, 27 Oct 2014 11:23:40 -0700 (PDT)
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id cad8e445.2b7aff86b940.4643206.00-2449.12993774.nbfkord-smmo06.seg.att.com (envelope-from );  Mon, 27 Oct 2014 18:23:40 +0000 (UTC)
X-MXL-Hash: 544e8dac024d4336-b845199204a8e1432fd7a4a7e092138d83f984ca
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id b8d8e445.0.4642860.00-2208.12992803.nbfkord-smmo06.seg.att.com (envelope-from );  Mon, 27 Oct 2014 18:23:10 +0000 (UTC)
X-MXL-Hash: 544e8d8e7b832bc1-cdaf4d3d43a6c1cc9778ccef3eee67fe0a93fa1b
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9RIN6YD015345; Mon, 27 Oct 2014 14:23:06 -0400
Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9RIMqbK015215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Oct 2014 14:22:55 -0400
Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi131.aldc.att.com (RSA Interceptor); Mon, 27 Oct 2014 18:22:40 GMT
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.152]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 14:22:40 -0400
From: "STARK, BARBARA H" 
To: Michael Kloberdans , Markus Stenberg 
Thread-Topic: [homenet] Comments requested for draft CER-ID
Thread-Index: AQHP8eZyBnMT2tvAoEOB5hY9+dInupxEMOKAgAAP7gCAAAg4gIAAEmEA//++LDA=
Date: Mon, 27 Oct 2014 18:22:40 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E61130EA81CA@GAALPA1MSGUSRBF.ITServices.sbc.com>
References:    <9C9AAA6C-61E0-4BAB-9BB4-DA02B74835FD@iki.fi> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.6.241]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=X9rl3hve c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=riIHBUA8hK4A:10 a=BLceEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP]
X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=jU2thFBwAAAA:8 a=48vgC7mUAA]
X-AnalysisOut: [AA:8 a=uFSKDfX_B7JSQYYPPGYA:9 a=QEXdDO2ut3YA:10 a=ShkLpKDU]
X-AnalysisOut: [LFQA:10 a=z5GxMmkQ6zqjZ1Os:21 a=F8LcOWKmZZWWYAhQ:21]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.23]
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/kdaXa4zPYN6SpYuDxvyfX7eT4EU
Cc: "homenet@ietf.org" 
Subject: Re: [homenet] Comments requested for draft CER-ID
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 18:27:09 -0000

TXkgY29tbWVudHMgY29udGludWUgdG8gYmU6DQpJIHRoaW5rIGFuIGluZGljYXRpb24gb2YgInRo
aXMgaW50ZXJmYWNlIGlzIGV4dGVybmFsIiAoaS5lLiwgZG9uJ3QgdHJ1c3QgbWUsIHRoaXMgaXMg
YSAicHVibGljIiBuZXR3b3JrKSBjYW4gYmUgdmFsdWFibGUgaW4gYXBwbHlpbmcgImV4dGVybmFs
IiBjbGFzc2lmaWNhdGlvbiB0byBhbiBpbnRlcmZhY2UuIEknbSBoYXBweSBub3QgdG8gdHJ1c3Qg
dGhvc2Ugd2hvIGNsYWltIHRvIGJlIHVudHJ1c3R3b3J0aHkuIEJ1dCB0aGF0IGRvZXNuJ3Qgc2Vl
bSB0byBiZSB0aGUgcHJpbWFyeSBmb2N1cyBvZiB0aGlzIENFUiBJRCBwcm9wb3NhbC4gSSB0aGlu
ayB0aGF0IHRyeWluZyB0byB1c2UgY2VydGFpbiBDRVIgSUQgdmFsdWVzIGFzIGFuIGluZGljYXRp
b24gb2YgInRoaXMgaW50ZXJmYWNlIGlzIGludGVybmFsIiAoaS5lLiwgdHJ1c3QgbWUgLS0gcmVh
bGx5ISkgaXMgcHJvYmxlbWF0aWMuDQoNClRoZSBpZGVhIHRoYXQgdGhlIENFUiBJRCB3aWxsIHNv
bWVob3cgY2F1c2UgY29uc2lzdGVudCBiZWhhdmlvciBieSBJUnMgaGFzIG5vIGJhc2lzLCBiZWNh
dXNlIHRoZSBleHBlY3RhdGlvbiBmb3IgSVJzIHRvIHRyZWF0IHRoZSBDRVIgSUQgYXMgYSAidHJ1
c3QgbWUgLS0gcmVhbGx5ISIgaW5kaWNhdGlvbiBpcyBwcm9ibGVtYXRpYy4gSSB3b3VsZCBiZSBv
cHBvc2VkIHRvIGFueSBzdWdnZXN0aW9uIHRoYXQgSVJzIHRydXN0IGEgInRydXN0IG1lIC0tIHJl
YWxseSEiIENFUiBJRCB2YWx1ZSBhbmQgYmVoYXZlIGluIGEgdHJ1c3RpbmcgbWFubmVyIGFzIGEg
cmVzdWx0IG9mIGl0LiBBcyBNYXJrdXMgc3VnZ2VzdHMsIG90aGVyIGluZGljYXRvcnMgc2hvdWxk
IGJlIHVzZWQgZm9yIHBvc2l0aXZlIGlkZW50aWZpY2F0aW9uIG9mIGludGVybmFsIGludGVyZmFj
ZXMuDQoNCkkgY29uc2lkZXIgdGhlIGZvcm1hdHRpbmcgb2YgdGhlIG9wdGlvbiBhcyBhbiBJUCBh
ZGRyZXNzIHRvIGJlIGZsYXdlZC4gSWYgaXQgaXMgdGhlIGNhc2UgdGhhdCBDYWJsZUxhYnMgd291
bGQgbm90IGFjY2VwdCBJRVRGIGlucHV0IHRvIGNoYW5nZSB0aGlzIG9wdGlvbiB0byBhIGZvcm1h
dCB0aGF0IElFVEYgcGFydGljaXBhbnRzIHdvdWxkIGZpbmQgdXNlZnVsIChiZWNhdXNlIGl0J3Mg
YWxyZWFkeSB0aGlzIHdheSBpbiB0aGUgZVJvdXRlciBzcGVjcyBhbmQgZVJvdXRlciB2ZW5kb3Jz
IGFyZSBpbXBsZW1lbnRpbmcgaXQpLCB0aGVuIEkgdGhpbmsgaXQgc2hvdWxkIG5vdCBiZSBzdGFu
ZGFyZGl6ZWQgYnkgSUVURiBhbmQgc2hvdWxkIHJlbWFpbiBhIHZlbmRvciBvcHRpb24gc3BlY2lm
aWVkIHB1cmVseSBpbiB0aGUgZVJvdXRlcnMgc3BlY3MuIA0KDQpJZiBvdGhlcnMgdGhpbmsgdGhh
dCBhbiBpbmRpY2F0aW9uIG9mICJ0aGlzIGludGVyZmFjZSBpcyBleHRlcm5hbCIgd291bGQgYmUg
dXNlZnVsLCB0aGVuIEkgd291bGQgYmUgaGFwcHkgdG8gcHJvcG9zZSBzdWNoIGEgdGhpbmcsIG9y
IHdvcmsgd2l0aCBvdGhlcnMgdG8gcHJvcG9zZSBzdWNoIGEgdGhpbmcuIEkgd291bGQgbWFrZSBp
dCBhIGZsYWcuIEl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBjb25zaWRlciBpbmNsdWRpbmcgb3RoZXIg
ZmxhZ3MgKGUuZy4sIG11bHRpcGxlIElBX1BEIHJlcXVlc3RzIGFyZSBvayAvIG5vdCBvaykgaW4g
dGhlIG9wdGlvbiBhcyB3ZWxsLiBJdCB3b3VsZCBiZSBhbiBvcHRpb24gdGhhdCBjb21lcyBmcm9t
IElTUHMgdG8gaW5kaWNhdGUgcHJlZmVycmVkIGV4cGVjdGVkIGJlaGF2aW9yIG9uIHRoZSBleHRl
cm5hbCBpbnRlcmZhY2UuDQoNCkknbSBvcHBvc2VkIHRvIElTUHMgdHJ5aW5nIHRvIGNvbnRyb2wg
d2hhdCBoYXBwZW5zIG9uIG15IGhvbWUgbmV0d29yaydzIGludGVybmFsIGludGVyZmFjZXMgdGhy
b3VnaCBzdGFuZGFyZGl6ZWQgREhDUCBvcHRpb25zLiBUaGF0J3Mgb25lIG9mIHRoZSByZWFzb25z
IEkgb25seSBoYXZlIG5vbi1JU1AgcHJvdmlkZWQvYWZmaWxpYXRlZCByb3V0ZXJzIGluIG15IGhv
bWUuIEluIGZhY3QsIEkgd291bGQgd2FudCBteSByb3V0ZXJzIHRvIGlkZW50aWZ5IGFueSBJU1At
cHJvdmlkZWQgZGV2aWNlIGFzIGJlaW5nIG9uIGFuIGV4dGVybmFsIGludGVyZmFjZS4gIEknbSBh
YnNvbHV0ZWx5IHVud2lsbGluZyB0byBhY2NlcHQgYW55dGhpbmcgdGhhdCB3b3VsZCBhbGxvdyBh
biBJU1AgdG8gZGlzYWJsZSBteSBpbnRlcm5hbCByb3V0ZXIncyBmaXJld2FsbC4gSSB3b3VsZCBw
cmVmZXIgdG8gaGF2ZSB0aGUgZmlyZXdhbGwgb24gdGhlIElTUCByb3V0ZXIgYmUgZGlzYWJsZWQs
IGlmIHRoZXJlIGlzIGEgZmlyZXdhbGwgb24gYW4gaW50ZXJuYWwgcm91dGVyLiANCkJhcmJhcmEg
DQoNCj4gTWFya3VzLA0KPiBDRVItSUQgY2FuIGFwcGx5IHRvIG1vcmUgdGhhbiBqdXN0IHRoZSBj
YWJsZSBpbmR1c3RyeS4gIERTTCBtb2RlbXMgYW5kDQo+IHNhdGVsbGl0ZSBzZXJ2aWNlcyBjYW4g
YWxzbyB0YWtlIGFkdmFudGFnZSBvZiB0aGUgYmVuZWZpdHMgaWYgd2UgZG9u4oCZdCBsb2NrDQo+
IGRvd24gdGhlIGludGVyZmFjZS4gIEFsc28sIHNvbWUgaG9tZSBvd25lcnMgbWF5IG5vdCB3YW50
IHRoZSBuYXR1cmFsDQo+IGJvdW5kYXJ5IGJlaW5nIHRoZSBDYWJsZSBtb2RlbSBvciBEU0wgbW9k
ZW0gYW5kIHRoaXMgcHJvdmlkZXMgYSB3YXkgdG8NCj4gbWFrZSB0aGF0IGhhcHBlbi4NCj4gDQo+
IERvIHlvdSBzdGlsbCB3YW50IHRvIGRpc2N1c3MgaG93IG9yIHdoeSBDRVItSUQgaXMgaW1wbGVt
ZW50ZWQgdGhpcyB3YXk/DQo+IA0KPiBUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMgc28gZmFy
Lg0KPiANCj4gDQo+IE1pY2hhZWwgS2xvYmVyZGFucw0KPiBMZWFkIEFyY2hpdGVjdCAvIEhvbWUg
TmV0d29ya2luZyAgICAgQ2FibGVMYWJzwq4NCj4gDQo+IDg1OCBDb2FsIENyZWVrIENpcmNsZS4g
IExvdWlzdmlsbGUsIENPLiA4MDAyNw0KPiAzMDMtNjYxLTM4MTMgKHYpDQo+IA0KPiANCj4gDQo+
IA0KPiBPbiAxMC8yNy8xNCwgODo0NyBBTSwgIk1hcmt1cyBTdGVuYmVyZyIgPG1hcmt1cy5zdGVu
YmVyZ0Bpa2kuZmk+IHdyb3RlOg0KPiANCj4gPk9uIDI3LjEwLjIwMTQsIGF0IDE2LjE3LCBNaWNo
YWVsIEtsb2JlcmRhbnMNCj4gPjxtLmtsb2JlcmRhbnNAY2FibGVsYWJzLmNvbT4NCj4gPndyb3Rl
Og0KPiA+PiBBbGwgaG9tZSByb3V0ZXJzIHNob3VsZCBrbm93IHRoZWlyIHJvbGU7IENFUiBvciBJ
Ui4gIFRoZSBzdGF0dXMgb2YNCj4gPj5DRVIgIHBsYWNlcyB0aGUgYnVyZGVuIG9mIHByb3ZpZGlu
ZyB0aGUgZmlyZXdhbGwgYW5kIE5BUFQgYXMgaXQgd2FzDQo+ID4+ZGV0ZXJtaW5lZCAgdG8gYmUg
dGhlIGVkZ2Ugcm91dGVyLiAgVGhlIGludGVyaW9yIHJvdXRlcnMgbmVlZCB0bw0KPiA+PnVuZGVy
c3RhbmQgdGhlaXIgcm9sZSAgYW5kIGRpc2FibGUgdGhlaXIgZmlyZXdhbGwgYW5kIE5BUFQgYWJp
bGl0aWVzLg0KPiA+PlRoaXMgaXMgd2h5IHRoZSBDRVItSUQgaXMgIGEgbnVtZXJpYyB2YWx1ZSAo
aW5kaWNhdGluZyBDRVIgc3RhdHVzKSBvcg0KPiA+PmEgZG91YmxlIGNvbG9uIChpbmRpY2F0aW5n
IElSICBzdGF0dXMpLg0KPiA+DQo+ID5JIGFncmVlIHdpdGggdGhhdC4gSG93ZXZlciwgSSBkaXNh
Z3JlZSB3aXRoIGhvdyB5b3UgYXJlIGRvaW5nIGl0Lg0KPiA+DQo+ID4+IEluIHRoZSBjYXNlIG9m
IHRoZSBlUm91dGVyIChjb21iaW5lZCBjYWJsZSBtb2RlbSBhbmQNCj4gPj5yb3V0ZXIvc3dpdGNo
L3dpcmVsZXNzKSwgaXQgcGVyZm9ybXMgYSAvNDggY2hlY2sgYmV0d2VlbiB0aGUgSUFfTkEgYW5k
DQo+ID4+dGhlICBJQV9QRCByYW5nZXMuICBJZiB0aGUgSVNQIHNlbmRzIGEgZG91YmxlIGNvbG9u
IG9yIG51bGwgaW4gdGhlDQo+ID4+Q0VSLUlEIE9STywgIEFORCBpZiB0aGUgSUFfTkEgaXMgaW4g
YSBkaWZmZXJlbnQgLzQ4IHRoYW4gdGhlIGdpdmVuDQo+ID4+SUFfUEQsIHRoZSBlUm91dGVyICBi
ZWNvbWVzIHRoZSBDRVIuICBJdCBtdXN0IG5vdyBkZWNsYXJlIHRvIHRoZSBJUnMNCj4gPj50aGF0
IGl0IGlzIHRoZSBDRVIuICBBICBkaXJlY3RseSBjb25uZWN0ZWQgSVIgd2lsbCBzZWUgdGhlIENF
UiB2YWx1ZQ0KPiA+PmluIHRoZSBPUk8gYW5kLCBpbiB0aGUgIGFic2VuY2Ugb2YgYW5vdGhlciBj
b250cm9sbGluZyBwcm90b2NvbCwNCj4gPj5kaXNhYmxlIGl0cyBmaXJld2FsbCBhbmQgTkFQVCAg
ZnVuY3Rpb25zLg0KPiA+DQo+ID5XaHkgY2Fubm90IGl0IGRldGVybWluZSBpdCBpcyBDRVIgYnkg
Yml0cyBjb21pbmcgZnJvbSBwYXJ0aWN1bGFyIHR5cGUNCj4gPm9mIHBsdWc/IENhYmxlIG1vZGVt
IHBsdWcgbG9va3MgZGlmZmVyZW50IGZyb20gZXRoZXJuZXQvd2lyZWxlc3M/IEl0DQo+ID53b3Vs
ZCBiZSBtdWNoIG1vcmUgc2VjdXJlIHRoYXQgd2F5Lg0KPiA+DQo+ID4+IFRoZSBuaWNlIGFkdmFu
dGFnZSBvZiB0aGUgZG91YmxlIGNvbG9uIGlzIGZvciBuZXR3b3JrIGxpdGVyYXRlIHBlb3BsZQ0K
PiA+Pmxpa2UgIHlvdXJzZWxmIHRvIG1hbnVhbGx5IGRldGVybWluZSB3aGVyZSB0aGUgYm91bmRh
cnkgYmV0d2VlbiBwdWJsaWMNCj4gPj5hbmQgIHByaXZhdGUgbmV0d29yayB3aWxsIGJlLiAgSWYg
eW91IGRpZG7CuXQgd2FudCB0aGUgQ2FibGUgb3IgRFNMDQo+ID4+bW9kZW0gdG8gYmUgIHRoZSBD
RVIsIG1hbnVhbGx5IGdpdmUgdGhlbSBhIMWSOjrCsiBhbmQgYXNzaWduIGEgQ0VSLUlEIHRvDQo+
ID4+YSBkb3duc3RyZWFtICByb3V0ZXIuICBUaHVzLCBDRVItSUQgYWxsb3dzIGZvciBhdXRvbWF0
aWMgZGV0ZWN0aW9uIG9mDQo+ID4+dGhlIENFUiBhbmQgIHVuaWZvcm0gYmVoYXZpb3Igb2YgSVJz
IHdpdGhpbiB0aGUgaG9tZSBhbmQgYWxzbyBhIHdheSB0bw0KPiA+PmRlc2lnbiB5b3VyICBuZXR3
b3JrIHRoZSB3YXkgeW91IGRlc2lyZS4NCj4gPg0KPiA+QWdhaW4sIGJpdHMgY29taW5nIGZyb20g
Y2FibGUgcG9ydCA8PiBub3Qgc291bmRzIG11Y2ggc2ltcGxlciB0byBtZS4NCj4gPkFuZCBtb3Jl
IHNlY3VyZS4NCj4gPg0KPiA+Q2hlZXJzLA0KPiA+DQo+ID4tTWFya3VzDQo+IA0KPiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBob21lbmV0IG1haWxp
bmcgbGlzdA0KPiBob21lbmV0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vaG9tZW5ldA0K


From nobody Mon Oct 27 11:31:08 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C880A1A9098 for ; Mon, 27 Oct 2014 11:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAe6MxrCgWxX for ; Mon, 27 Oct 2014 11:30:42 -0700 (PDT)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7170E1A1B55 for ; Mon, 27 Oct 2014 11:28:15 -0700 (PDT)
Received: from [10.86.114.90] (198-135-0-233.cisco.com [198.135.0.233]) (authenticated bits=0) by spark.crystalorb.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id s9RISOVg022166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Oct 2014 11:28:29 -0700
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: David R Oran 
In-Reply-To: 
Date: Mon, 27 Oct 2014 11:27:58 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Michael Kloberdans 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ZTHXpMOjpaMEA_ypzr6jZEArPTQ
Cc: "homenet@ietf.org" , Ola Thoresen 
Subject: Re: [homenet] Comments requested for draft CER-ID
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 18:30:44 -0000

Silly question:

Isn=92t the border defined by a link and not a router? What if you have =
uplinks to two different ISPs on the same router?
This seems to assume there=92s only one border link on a router, and =
that router connects to only one external entity.

On Oct 27, 2014, at 8:59 AM, Michael Kloberdans =
 wrote:

> Ola,
> I=B9d like to better understand your comment about a misconfigured =
router
> being a security issue.
>=20
> In the eRouter implementation, the CER is automatically determined.  =
The
> only way a router would be misconfigured is if the home owner or =
someone
> else with local access manually changes the CER.  Perhaps I=B9m =
missing
> something. Please expound - I=B9m grateful for all comments.
>=20
> Regards,
>=20
>=20
> Michael Kloberdans
> Lead Architect / Home Networking     CableLabs=AE
>=20
> 858 Coal Creek Circle.  Louisville, CO. 80027
> 303-661-3813 (v)
>=20
>=20
>=20
>=20
> On 10/27/14, 9:00 AM, "Ola Thoresen"  wrote:
>=20
>>> On 27.10.2014, at 16.17, Michael Kloberdans =

>>> wrote:
>>>> All home routers should know their role; CER or IR.  The status of =
CER
>>>> places the burden of providing the firewall and NAPT as it was
>>> determined
>>>> to be the edge router.  The interior routers need to understand =
their
>>> role
>>>> and disable their firewall and NAPT abilities.  This is why the
>>> CER-ID is
>>>> a numeric value (indicating CER status) or a double colon =
(indicating
>>> IR
>>>> status).
>>>=20
>>> I agree with that. However, I disagree with how you are doing it.
>>>=20
>>>> In the case of the eRouter (combined cable modem and
>>>> router/switch/wireless), it performs a /48 check between the IA_NA
>>> and the
>>>> IA_PD ranges.  If the ISP sends a double colon or null in the =
CER-ID
>>> ORO,
>>>> AND if the IA_NA is in a different /48 than the given IA_PD, the
>>> eRouter
>>>> becomes the CER.  It must now declare to the IRs that it is the =
CER.
>>> A
>>>> directly connected IR will see the CER value in the ORO and, in the
>>>> absence of another controlling protocol, disable its firewall and =
NAPT
>>>> functions.
>>>=20
>>> Why cannot it determine it is CER by bits coming from particular =
type of
>>> plug? Cable modem plug looks different from ethernet/wireless? It =
would
>>> be
>>> much more secure that way.
>>>=20
>>=20
>>=20
>> But that would not work if the router only has ethernet-ports - which =
is
>> probably the case if the customer has various kinds of FTTH (many of
>> these will use Fast/Gig-ethernet over copper for the last meters in =
to
>> the CPE).
>>=20
>> However I do agree that the suggested solution seems sub optimal.  It =
is
>> way to easy for a misconfigured router to disable all local security =
(IE.
>> turning off firewalling) without the network owners knowledge.
>>=20
>> /Ola (T)
>>=20
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From nobody Mon Oct 27 15:57:35 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850511A1B54; Mon, 27 Oct 2014 15:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKngpOZFnKWi; Mon, 27 Oct 2014 15:57:23 -0700 (PDT)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9314D1A1B3F; Mon, 27 Oct 2014 15:57:02 -0700 (PDT)
Received: by mail-pa0-f53.google.com with SMTP id kx10so6305118pab.26 for ; Mon, 27 Oct 2014 15:57:02 -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=i8UzVkyUYiHHo6B0zggCsbIgxSsDaCDnVsnP9nJr/Nw=; b=VFAzd9/d6TkXLrjIiwIY7fts9vg0pX0xRONo0feM9RN7OHMgu3Rm2S/+Ome0EaprBu m49AqyHAzrIoR+LOeY1+WHw4Te/ylxKoOh5ZwakzN9/gPPBwly8HEDADSMy5M95iNy0N +RCMLtf5OfdoEUpjCPE7WjH1Alu3Q73pypGRku0BvMXIfoV79R8PIEYTn3ywTNzD0Tqe oLUdTjMPLIQzFEd4RVYzM7xentwAW8D+Tx4FOUoT/0wuWQJz5SvauDTVCqzYtEo0MymK IDV2CAAM/ZxBwHeGGThXVPG5yWbWqpYJ60liJ7zB1n4ewDetu1PaHwzrrFcfnovPtr/Y ICKw==
X-Received: by 10.66.144.106 with SMTP id sl10mr26592157pab.96.1414450622313;  Mon, 27 Oct 2014 15:57:02 -0700 (PDT)
Received: from [192.168.178.23] (142.193.69.111.dynamic.snap.net.nz. [111.69.193.142]) by mx.google.com with ESMTPSA id ub7sm9935803pbc.30.2014.10.27.15.56.56 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 15:57:01 -0700 (PDT)
Message-ID: <544ECDB8.1010204@gmail.com>
Date: Tue, 28 Oct 2014 11:56:56 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Pierre PFISTER 
References: <9A89531E-AEE1-4FCD-B725-0ECDC76F5125@cisco.com>
In-Reply-To: <9A89531E-AEE1-4FCD-B725-0ECDC76F5125@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/5TNtdntE0YdePA0hT7o9Jl2Mjbs
Cc: Toerless Eckert , Laurent Ciavaglia , Markus Stenberg , "Townsley.net" , "Michael Behringer \(mbehring\)" , Benoit Claise , HOMENET Working Group , Steven Barth , anima@ietf.org, Sheng Jiang 
Subject: Re: [homenet] Slots request for presenting Homenet work at Anima session
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 22:57:28 -0000

FYI the status of the anima meeting in HNL will only be decided
at this weeks's IESG meeting and the chairs are not yet known,
so the agenda process is running late.

Regards
   Brian Carpenter (with no hat on)

On 28/10/2014 00:08, Pierre PFISTER wrote:
> Hello Anima future chairs/participants,
> 
> It has been stated and discussed multiple times already that Homenet and Anima have quite significant similarities, although they are focusing on different scenarios.
> HNCP authors and myself think it may be useful to take some time to present our work so that Anima may have a view of the Homenet approach to solving similar problems (Negociation, Configuration and Security). The Anima charter provides starting points for protocol specifications which are very different from what Homenet is moving to. Other approaches exist though, and should be considered before it is too late.
> 
> Therefore, we are requesting slots for the three following presentations.
> 
> - draft-ietf-homenet-hncp-02 (10 min)
> Speaker: TBD
> 
> - draft-ietf-homenet-prefix-assignment-01 (10 min)
> Speaker: Pierre Pfister
> 
> - draft-barth-homenet-hncp-security-trust-00 (10 min)
> Speaker: Pierre Pfister (on behalf of Steven Barth)
> 
> 
> Regards,
> 
> - Pierre
> 
> 


From nobody Mon Oct 27 20:59:37 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F871A044F; Mon, 27 Oct 2014 20:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level: 
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rxvv5tGbmDIu; Mon, 27 Oct 2014 20:59:26 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAC3C1A001E; Mon, 27 Oct 2014 20:59:24 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKZ80023; Tue, 28 Oct 2014 03:59:23 +0000 (GMT)
Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Oct 2014 03:59:21 +0000
Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.168]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 28 Oct 2014 11:59:14 +0800
From: Xueli 
To: "pierrick.seite@orange.com" , Ted Lemon , "STARK, BARBARA H" 
Thread-Topic: =?Windows-1252?Q?[homenet]_Fwd:_New_Liaison_Statement, _"Broadband_Forum_W?= =?Windows-1252?Q?ork_on_=93Hybrid_Access_for_Broadband_Networks=94_(WT-34?= =?Windows-1252?Q?8)"?=
Thread-Index: AQHP7WIcOm96HPXJ7U2H19EDbAXxJpw7zesggAASlkCACQpR4A==
Date: Tue, 28 Oct 2014 03:59:14 +0000
Message-ID: <01FE63842C181246BBE4CF183BD159B449036DFF@nkgeml504-mbx.china.huawei.com>
References: <20141021160652.24101.60334.idtracker@ietfa.amsl.com> <4BBD7952-84F7-40F9-9034-8DD7A1F2A05C@nominum.com> <2D09D61DDFA73D4C884805CC7865E61130EA59FC@GAALPA1MSGUSRBF.ITServices.sbc.com>  <01FE63842C181246BBE4CF183BD159B4490350AD@nkgeml504-mbx.china.huawei.com> <31246_1413972312_54478158_31246_662_1_81C77F07008CA24F9783A98CFD706F71142BD145@PEXCVZYM12.corporate.adroot.infra.ftgroup>
In-Reply-To: <31246_1413972312_54478158_31246_662_1_81C77F07008CA24F9783A98CFD706F71142BD145@PEXCVZYM12.corporate.adroot.infra.ftgroup>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.97.86]
Content-Type: multipart/related; boundary="_004_01FE63842C181246BBE4CF183BD159B449036DFFnkgeml504mbxchi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/8r1iFw8ZMXZ9GlRLKOUZePBEqyM
Cc: HOMENET Working Group , "mif@ietf.org" , "dmm@ietf.org" 
Subject: [homenet] =?windows-1252?q?=3D=3FWindows-1252=3FQ=3FRE=3A=5F=5FFw?= =?windows-1252?q?d=3A=5FNew=5FLiaison=5FStatement=2C_=5F=22Broadband=5FFo?= =?windows-1252?q?r=3F=3D_um_Work_on_=93Hybrid_Access_for_Broadband_Networ?= =?windows-1252?q?ks=94_=28WT-348=29=22?=
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 03:59:30 -0000

--_004_01FE63842C181246BBE4CF183BD159B449036DFFnkgeml504mbxchi_
Content-Type: multipart/alternative;
	boundary="_000_01FE63842C181246BBE4CF183BD159B449036DFFnkgeml504mbxchi_"

--_000_01FE63842C181246BBE4CF183BD159B449036DFFnkgeml504mbxchi_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hello Pierrick

First of all, thanks a lot for agree with the big picture depicture and arc=
hitecture..
I am fine to split the architecture considerations and solution design in t=
wo different documents.
And I updated the architecture draft (No specific solution there) in the ne=
w version, I hope it makes sense for you.
http://www.ietf.org/internet-drafts/draft-lhwxz-hybrid-access-network-archi=
tecture-01.txt
Do you mind to share more about the solution about DMM proposal.
Which exact issues it is really solving?

Best Regards
Li

From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com]
Sent: Wednesday, October 22, 2014 6:05 PM
To: Xueli; Ted Lemon; STARK, BARBARA H
Cc: HOMENET Working Group; mif@ietf.org; dmm@ietf.org
Subject: RE: [homenet] Fwd: New Liaison Statement, "Broadband Forum Work on=
 =93Hybrid Access for Broadband Networks=94 (WT-348)"

Hi Li,

Architecture considerations and solution design are two different things, w=
hich should not be addressed in the same I-D. People may agree with the big=
 picture depicture and architecture but not agree with going on extensions =
to the GRE protocol to address the issue. BTW, I think that going for exten=
sions to GRE header to address the hybrid access use-case is not the right =
way. Actually, IETF solutions already exist (RFC  4908 ) and, moreover, the=
re is ongoing effort in DMM to update RFC 4908 to meet hybrid access requir=
ements.

BR,
Pierrick

De : Xueli [mailto:xueli@huawei.com]
Envoy=E9 : mercredi 22 octobre 2014 11:48
=C0 : Ted Lemon; STARK, BARBARA H
Cc : HOMENET Working Group; mif@ietf.org
Objet : RE: [homenet] Fwd: New Liaison Statement, "Broadband Forum Work on =
=93Hybrid Access for Broadband Networks=94 (WT-348)"


Hello



Thanks Barbara to send this liaison out.

Hybrid Access network is that Residential gateway (RG, or CPE) is extended =
with more than two access lines

(e.g. DSL + LTE) in order to provide higher bandwidth for the customers. Th=
e scenario and architecture are shown as follows

[cid:image002.jpg@01CF9A07.BF8CD480]



Right now, we have two individual drafts, one for architecture and requirem=
ents, and the other one is for an optional solution.

The draft (http://tools.ietf.org/html/draft-lhwxz-hybrid-access-network-arc=
hitecture-00 ; ) proposes the architecture and gap analysis.

The solution draft proposes one option for the solutions, http://tools.ietf=
.org/html/draft-heileyli-gre-notifications-00

We did not combine them as one draft, because we believe there may be other=
 candidates, and we would like to have further discussions in the related g=
roups and IETF.

We used to present it in Homenet in Toronto.



Now the authors have invited Orange to join this architecture work. We will=
 send out the new version of these drafts soon.

We are glad to invite the experts for comments.



Best Regards

Li Xue on the co-authors behalf





-----Original Message-----

From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of Ted Lemon

Sent: Wednesday, October 22, 2014 3:05 AM

To: STARK, BARBARA H

Cc: HOMENET Working Group

Subject: Re: [homenet] Fwd: New Liaison Statement, "Broadband Forum Work on=
 =93Hybrid Access for Broadband Networks=94 (WT-348)"



On Oct 21, 2014, at 2:55 PM, STARK, BARBARA H > wrote:

> FYI. I made sure they were aware of IETF mif and homenet activities in th=
is area. I intend to try to prevent having to track efforts that try to do =
the same thing in two different ways. But some of the BBF effort may be foc=
used on what can be done around "bonding" of multiple interfaces that are u=
nder the control of a single service provider. I don't see this in mif or h=
omenet.



Thanks.   I couldn't really tell what was being proposed from the Liaison s=
tatement, so this information is helpful.



_______________________________________________

homenet mailing list

homenet@ietf.org

https://www.ietf.org/mailman/listinfo/homenet

___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.



This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.

Thank you.

--_000_01FE63842C181246BBE4CF183BD159B449036DFFnkgeml504mbxchi_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable











Hello Pierrick


 


First of all, thanks a lot for agree with the big picture depictu=
re and architecture..


I am fine to split the architecture considerations and solution d=
esign in two different documents.


And I updated the architecture draft (No specific solution there)=
 in the new version, I hope it makes sense for you.



http=
://www.ietf.org/internet-drafts/draft-lhwxz-hybrid-access-network-architect=
ure-01.txt


Do you mind to share more about the solution about DMM proposal.<=
o:p>


Which exact issues it is really solving?



 


Best Regards


Li


&n=
bsp;






From: pierrick.sei=
te@orange.com
 [mailto:pierrick.seite@orange.com] 

Sent: Wednesday, October 22, 2014 6:05 PM

To: Xueli; Ted Lemon; STARK, BARBARA H

Cc: HOMENET Working Group; mif@ietf.org; dmm@ietf.org

Subject: RE: [homenet] Fwd: New Liaison Statement, "Broadband F=
orum Work on =93Hybrid Access for Broadband Networks=94 (WT-348)"=







 


Hi Li,


 


Architecture considerations and solution design are two different=
 things, which should not be addressed in the same I-D. People may agree wi=
th the big picture depicture and architecture
 but not agree with going on extensions to the GRE protocol to address the =
issue. BTW, I think that going for extensions to GRE header to address the =
hybrid access use-case is not the right way. Actually, IETF solutions alrea=
dy exist (RFC  4908 ) and, moreover,
 there is ongoing effort in DMM to update RFC 4908 to meet hybrid access re=
quirements.  


 


BR,


Pierrick  


 








De : Xueli [mailto:=
xueli@huawei.com]


Envoy=E9 : mercredi 22 octobre 2014 11:48

=C0 : Ted Lemon; STARK, BARBARA H

Cc : HOMENET Working Group; mif@ietf.org

Objet : RE: [homenet] Fwd: New Liaison Statement, "Broadba=
nd Forum Work on =93Hybrid Access for Broadband Networks=94 (WT-348)"<=
/span>






 


Hello 


 


Thanks Barbara to send this =
liaison out.


Hybrid Access network is tha=
t Residential gateway (RG, or CPE) is extended with more than two access li=
nes



(e.g. DSL + LTE) in orde=
r to provide higher bandwidth for the customers. The scenario and architect=
ure are shown as follows



3D"cid:image002.jpg@01CF9A07.BF8CD480"


 


Right now, we have two indiv=
idual drafts, one for architecture and requirements, and the other one is f=
or an optional solution.


The draft (htt=
p://tools.ietf.org/html/draft-lhwxz-hybrid-access-network-architecture-00 ; ) proposes the architecture and gap
 analysis.


The solution draft proposes =
one option for the solutions,
=
http://tools.ietf.org/html/draft-heileyli-gre-notifications-00  


We did not combine them as o=
ne draft, because we believe there may be other candidates, and we would li=
ke to have further discussions in the related groups and IETF.


We used to present it in Hom=
enet in Toronto.



 


Now the authors have invited=
 Orange to join this architecture work. We will send out the new version of=
 these drafts soon.


We are glad to invite the ex=
perts for comments.


 


Best Regards


Li Xue on the co-authors beh=
alf


 


 


-----Original Message-----


From: homenet [mailto:homene=
t-bounces@ietf.org] On Behalf Of Ted Lemon


Sent: Wednesday, October 22,=
 2014 3:05 AM


To: STARK, BARBARA H<=
span lang=3D"FR">


Cc: HOMENET Working Group


Subject: Re: [homenet] Fwd: =
New Liaison Statement, "Broadband Forum Work on
=
=93Hybrid Access for Broadband Networks<=
span lang=3D"EN-US" style=3D"font-family:"Courier New"">=94 (WT-348)"


 


On Oct 21, 2014, at 2:55 PM,=
 STARK, BARBARA H <bs7652@att.com&=
gt; wrote:


> FYI. I made sure they w=
ere aware of IETF mif and homenet activities in this area. I intend to try =
to prevent having to track efforts that try to do the same thing in two dif=
ferent ways. But some of the BBF effort
 may be focused on what can be done around "bonding" of multiple =
interfaces that are under the control of a single service provider. I don't=
 see this in mif or homenet.


 


Thanks.   I couldn=
't really tell what was being proposed from the Liaison statement, so this =
information is helpful.


 


____________________________=
___________________


homenet mailing list<=
span lang=3D"FR">


homenet@ietf.org


https://www.ietf.org/mailma=
n/listinfo/homenet



____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.






--_000_01FE63842C181246BBE4CF183BD159B449036DFFnkgeml504mbxchi_--

--_004_01FE63842C181246BBE4CF183BD159B449036DFFnkgeml504mbxchi_
Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=9036;
	creation-date="Tue, 28 Oct 2014 03:59:13 GMT";
	modification-date="Tue, 28 Oct 2014 03:59:13 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf
IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7
Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCADWAawDASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0uiii
uc4gooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKbHLHMgeJ1dCSAynI
4OD+tADqrXNxdxSBbfT2uVIyWEyJg+mGqzRQBUmub2NwItMeZSoJYXCLg9xgntSy3N4k+yPTWlj4
/eCdF+vBOeKtUUAVXubxbny101ni3Aed56AY9duc0fabz7V5f9mt5O7HneemMeu3Ofwq1RQBVjub
xrny301o4skecZ0Ix67Qc1aoooAKKRmVELsQqqMknoBQrBlDKQQRkEdCKAFooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKaZYxMs
JdRIylgmeSBjJ/UfnTqACiiigAooooAKKbHLHMpaJ1cBipKnOCDgj8DTqACiio7idLa2luJM7IkL
tgZOAMmgCrq9xJFaCC3OLm6YQw/7JPVv+AjJ/CrVtbxWltFbQLtiiUIo9hTl2SqkoUHIypI5AI/S
nUAFFFFABRRRQAUUUUAFFFFABgEYIBB6g96zdIP2V59JdiTaENDnq0Lfd/LlfwFaVJsXfv2jfjG7
HOPTNAxaKbHLHMC0bq4VipKnOCDgj8DTqBBRRUVxdRWvleaSBLIIlbHAY9M+men1IoAlooooAKKK
KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAMubRjLrcV/
9su1RYnUotww5LKQAP7vByPpVoWCi6+0fa7zO7d5ZuG8v6bemPale7K6pDZbARJC8u/PTaVGMf8A
Av0qzQN3Ksdgsdx5/wBrvWOSdj3DFP8AvnpiiHT1hmMgu7185+WS4Zl59qtUUAVIdPWBmYXl9JuU
riW5ZgM9xnofeiLTliVx9svn3rty9yzFfceh96t0UAZuj6S2mJKHuZ5mklkcB5mdQGYkcHv6mtKq
1hdm9hkkKBNk0kWAc52sVz+OKsM6ou52VR6scChg9xaq6qjSaPexopZ2t5AqgZJJU4FLaaha3tlH
dxSqI5FDDcwBGfXng064vre1tJbp5UMcSMxKsDnAyQOetDBaMfbgrawgjBEagg9uKkpkM0c8SyxO
GVgDkEGn03uIKKKKQBRVNr24GrLYi0BjaMyed53YHH3cep9ap3Wt3kFzLEmjvKqGTa3nhWkCAEkL
t/2uOecUDszYorHGuXDahLaR6crmKbyyBcjeRhSWCbegDAnn1rYoCwUUUUCCmyx+bE0Zd03DG5G2
sPoe1OooAytN0U2UFxG97dsZpZGBFyx2hmyCPRvU1aTTlSF4vtl8wfHztcsWXHoe1Osbs3kUrlAn
lzyRYBznaxGfxxVmgbvcqDTlW3aH7ZfEMwO83LFx7Buw9qSTTIpdOmsZJp5VmBG+aUuynsQT6HBq
5RQFytp089xYxtdRmO4XKSgjGWBwSPY9R9as1Wvbz7Ebd3TMMkojkfP+r3cKfpnA/GrNAgooooAK
KytV1w6XqFjamykmF5JsDq6AA4Pqw74HPHPrxRf64bHWrLTTZSSfa9wEgdAAQM9Cc+vX04zTsOzN
WisqfXDB4ht9INnI3nxs6yh0xxjtuz0z78cA0f24R4kGjGzkBMPmCbemOuOmc9OfX2xzSsFjVorK
g1wzeIp9HNlIhiiEnml0IIJOeA2fT355ArVoBqwUUUUCCiiigAooooAKKKbLIsMTSPu2qMnapY/g
ByaAHUVl6drsN9bTTNFOnkyOpAt5OQrlRjK8n2HSrKapbPA8wW42RkA5tZA3PopXJ/Cgdi3RVQap
bG3acLcbFbaQbWTdn/d25x74o/tO2FsLjbcbC23H2WTdn/d25x74xQBborL1LXYbHSJL9IpnwpKK
1vIMkHuNuQPc1oQTx3MQljDhScfvI2Q/kwBoCxJRRRQIKKKKAKklrI2swXY2+VHbyRtzzlmUjj/g
Jq3VOS4lXW7e2DfuntpHZcdWDIBz+Jq5R0GwooooEFFQXzyRWFxLCwSSOJmRmXcAQCenesrRdUur
uBru4uhLAsfzoLRo5A+FPyryWXDelCHbS5o6ZayWlvKku3L3Esgwc8M5I/Q1YlhiuIzHPFHKh6rI
oYH8DWdp2uw31vPK0U6eTJIpAt5OVVioIyvJ9hzVldUtngeYLc7EIBzayhufQbcn8KGDvcZZaNp9
lp8dktpA8aKAd0K/OR0JGME0650iwubCWyNpAkUisMLCuFJGNwGMZ96Zouqpq+nRXIjeN2QM6tG6
gE+hYDP4Vfpu99Qu0yK2tYLOBYbeKOJFA4RAoJx1wO9S1S1S5lsoortDmCKQfaFxn92eCw/3SQfp
mrtIQUUUUAZl7YahPetPb3dtEhgaEK8DMwB5JyHHP4U5dPu47mwdbqIx2kPlMHiYvJkAE53cdPQ1
o0UDuYb6DdnULm7iu7WKS4k3eatu3mouFBUNv54UdR3Nbp5JOMUlFAN3CiiigQUUVStLia71C7ZX
H2SAiFAAPnkHLtn24X8DQA7TbaS1hmSXbl7mWQYOeGYkfoat0UUAFFFFAEV1bR3lrLbTDMcqFWx7
96bYi6WyiW9Km4VdrspyGI43fj1/Gp6KACisnxBdataW8L6VEkrGVfMUxM52A5bofTPue1M1u71i
2NkdPjilDSL9o/cu2F6MeD05HHX9aaQ7Gu0UbnLxox6ZZQe+f580NFG7b2jRm4+YqCeOnNOGcc4z
3x0opCGmKMvvMaF8g7iozkdOfxP50eVHv3+Wm/Od20ZzjHX6cU6igBoijD7xGgfJO4KM89efwH5U
6isfT7rWJNevILuOMWSgGCRYWXcRwwBJ9cdevagZsUVkaRdavPqV9FqEca26MDbusLLvGMHBJ9Qe
vPIPStegHoFFFFAgooooAKKKB1oAZFBHboUiQIpYuQPUnJP4k0+s/RGZrKUsxJ+1zjk5/wCWjVoU
De4UUUUCGTwR3ULwTIJI5BhlPcU/rWf4gZl8P3zKxUiLgg4I5FaJ60DEooooEFFFFAEDWgfUYr3e
QY4ni244O4qc5/4DU9Z8rN/wkdqu47TaSkjPGdyVoUdBsKKKKBEdxAtzbSQOXVJUKMUbBweDg9qq
Wej29lPHMk11K0UZjj86beEU4zj/AL5H5VfooGMigjt1KRIEDMXIHdmOSfxJp+az9FZmtJyzE4vJ
xyc8eY1aFAPcZBDFbQJBCgSKMbUUdAKfRRQIbIiSxtHIoZHUqynoQeoqKytms7KK2aZpvKXaHYYJ
A6Z/DAqeigAooqtcz3sTgW1gLlSOWNwseD6YINAFmiqk1xfo4EOmrMpAJY3Kpg9xgj9aWW4vkn2R
acssfH7z7Sq/XjFAFqiqr3F8tz5aacrw7sed9pUceu3Gfwo8+++1eX/Z6+Tux532lenrtxn8KALV
FVY7i+a52PpypDkjzftKnj124zVqgBHDFGCNsYggNjOD61DZWkdjZRWsWSsa4yerHqSfcnJ/Gp6K
ACiiigAooooAKKKy/EOn32o6d5Gn3T2828HeJNo4OeeDnpjt1oGjUopkKskEauzM4Ubi7BjnvkgD
P5U+gQUUUUAFFFFABRRRQAUUEZBGSM9x1FZGhadqFjNetfXUk6zy+ZEHlD7AeoPyjnjr056cUDNe
iiigQUUUUAFFFKOtAFWBrK1tneKWJIRK5d2k+UOWO7JP+1mpVubdy4W4ibyxl8SA7B6n0/Guduhv
8H6igQuzXUwULEZDnzz/AAjrUTwSvfX7TRtdxrcW0k/l2jRiWJVOQFOd+CQSM9ulNIu2504uIGg8
9Z4jCBnzQ4Kfn0prXtmkayteW6xscK5mUKfoc81gXKQSC6njt7mCzmnhMZjtiw8xckyGLGdn3QeO
cfjTZLW2fQry4msU3q0wgaK1dfOLqAX8rBIJxj8M96LCsdA62upWbxb47iCUbWMb5B9sip6w9SsJ
JvD9wujEQm5BkaPyDmRjgcAldvStF4NRMSKuowiQZ3P9kyG9ON/H50CLdFVJYNQZIxFfxRsFw7G1
3bz6gbhj6c0TQag2zyb+KPCgNutd24+v3hj6UgLdFVJodQeQGG/iiXAyrWu8k9zncKWWG/afdFfR
Rxcfuzbbj7/NuH8qBExt4muUuSv71EKK2eikgkfoKkrIns9UfxDDcR3aLbLBIvNvnbllIUndyTg8
47VsDrR0GyL7RB5xh8+LzR1j3jcPw601L2zlLCO8t3KDLBZVO0dycHgVj6fHaRiztbrTXl1CCYu0
gtz8r5OZfM6EHPqTzjFVdLthPJPI0ccUNrdTzgC1dZXDFwASRgqQc4Ge1Mdjooby0uHKQXdvMwGS
scqscfQGpq5XwsRF9jhlgMk3k7UcWjw/ZlCDcrZGCSR611VDVmJqxBaJbJE4tSpQyuW2tn5yx3fr
mp6ztD/485/+vy4/9GNWjSB7sKKKKBBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUANll
jgiaWV1jjUZZmOABTqoa1o9vrmnPY3OBG55bYCwHfbnoferNpbraWcVuu3ESBcqgUH3wOBmgZNUU
13a2zBbi6ghJGQJJVUkfialrG8QSWyyaeJoGlZLpJGK2zSbUG7JJCmhbglc2RyARyDyCKaJEMpiD
AyKoYr3AOQD9OD+Vc1rCE3upTxNfB4rON4FiEoTzcnBAAwTjaMfmKmuYLKPxC19cW124ntozE0Ql
O5wzZGFOBwV4OB+tOw7HRYOM44owfSuWlXUF1mVpJCk5ucxMEnbMWRgAL+7xjIOe+asxJbzeJ7tX
mvlXdGYUHmrH5gzuOcY9BjOKLCsdBg+lGD6da5WyDQXNvNE98ZJL+eMiUSlViw20EEYC52kE+vWn
aJHerfwJcyMJiGF2u2clzjnJb5Bz0K/hRYbVjpY5Emj8yJw6ZI3KcjIOD+op1YHh23tbHNqttdJd
K8ocuJSirvJHLHbyCMYredFkRkdQysCCGGQR7ikxPcSOWOZS0Tq4DFSVOcEHBH4GnVmaJoVvoUc6
QMrefJ5jHywpBPUcds5IHbNadABRRRQIKKKB1oAhtLmK5iaSFSqrI6HIx8ysQf1BqbNUdHikhs5V
lRkY3MzAMMZBkYg/iKvUDe4uT60ZNJRQIhvLqOytJbqbcY4l3NtGTipqoa5FJPod5FCjSSPHhVUZ
JORWgetA+glFFFAgooooAha6jW9jtDu8ySNpBxxhSAf/AEIVNVGWKQ6/bTBGMa2sql8cAlkwP0P5
VeoGGaXJ9aSigQuT60lFFAEFpcxXUTvCpVVleM5GPmViD+oqeqOjxSQ2syyoyE3UzAMMZBkJB/EV
eoG9wooooEFFFFABRRVa5sI7pw7zXSEDGIbh4x+SkUAWaKqTadFO4dp7tSABiO6kQcewPX3pZdOi
mn85p7tW4+VLl1Xj/ZBxQBaoqq+nxPc/aDNdhsg7VuXCf98g4x7Uf2fF9q+0eddbt27b9pfZ/wB8
5xj2oAtUVVj0+KO588T3ZbJO1rl2T/vknGKtUAFFFFABRRRQAUUUUAFU9U1az0e2FxeyMiFgowhb
qQO31q5UF7Y22o25t7uPzYiclCxAP1x1/wAaBq3UljkSaNZIzlHGVOCMj6Gn5I701V2qFBJCgDJO
T+feloELk+tGaSigAzS5PrSUUALk+tJmiigALbVJJ4Ayao6drNjqrzpZys7W7lHDIy4Ix6j3q9Va
00+2sXle3jKNO26Qlyd7f3jk9ff6elA+hZooooEFFFFABSM6opd3VFHVmOAPxpaRlV1Kuqup6qwy
D+FAFSz1WyvYZJY7iILG7I2ZF42sVz16Ejipxd2rI0i3UBRfvMJVIH1OeKhtNKsrKGSKK3iKyOzt
mNedzFsdOgJ4qYWlqqNGtrAEb7yiJQD9RjmgegC7tTGZBdQGMHBfzV2g+mc0fa7Xy/M+1QeXnG/z
V259M5oFpaiMxi1gCE5KeUu0n1xij7Ja+X5f2WDy852eUu3PrjFAEF7qtlY2D3klxE0SAkbZF+bH
Yc8mrUckcqb4pEkU/wASMGH5iq17pVnfWL2ckEaxOCBtjUbc9xxxVmOOOJdkUaRqP4UUKPyFADqK
KKBBRRRQBWe7ZdVhstgKyQPKWzyCpUY/8eqzVSS1kbWILsFfLjt5IyM85ZlI/wDQTVugYUUUUCI7
iR4raWVEDsiFgpbaDgZxnBxVCy1eSUW5vbaO0W5h82JxPvXAAJDEgYOCD6dav3Eby20sSOEZ0Khi
u4DIxnGRmqFlpMkIgF7cx3S20PlRIINi4IAJYEnJwB+tCHpYntNVsr2KSSO4iCxO6NmReNrbc9eh
xwamF5aMjSC7gKL95hKuB9TmorTSrKyikjit4isru7ZjXnc27HTpzwKmFpahCgtYAjfeURLg/UYo
DQj0/ULfU7OO6tpFZZFDbQwJXPY4PFWarafp9vplnHa20aqsahdwUAtjucDmrNNgMmmjt4JJ5W2x
xKXY+gAyajsZpriyhmuIhDJIu4xg5256A++MZ96j1G0e+WCDIFv5oecHq6ryF+hOM+wq2eTmkAUU
UUCCiiigAooooAKKKKAEffsbywC+DtDdM9s1Bp94t/Yx3IUozZDoeqODhlP0INWKp29rLbajdSIV
+zXAEm3PKy9GwPQgA/Ue9Ay5RRRQIKKKKACiiigDK17Wm0SCGYWhnWSVUYiRV2gnk8nsMnPQY5pu
s65JpBsv9BMoupVjb98g2Z+p7HHPTnrWsyK33lVu3IzQyI33kVuMcgHimPQUZxyMHuPSiiikIKKK
KACsmw1uS81y80xrIxfZQpEnmo27PXgH1446Z5xWtSBEByEUHnkDnnrQMytK1x9S1K+s2sjB9kcD
cZUbcCB6H13DjjjHWtakCIpyqKD0yABS0AwooooEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF
AFKSeVdct7YP+6e2kdlx1YMgB/U1dqBrRW1CK83kNHE0QXHBDEHP/jtT0DCiiigQUUUUAUtKuJbm
2meZ9zLczIDjoquQB+QqzcTrbxGVklcDtFGXb8hzTLO0WzieNXLh5XlJI6FmLEfrU9DG9zL03W1v
dIivpLa6VmVSypbSHk/3RjJHvTr3WEttJnvUtromNHKo1tIDkLnkYyB71fhhjt4UhhQRxoMKq9AK
WSNJonikUOjqVZT0IPBFNhpchsbtb21SYRyx7gMiSNkOcdgece9WKRVCqFUYAGAPQUtJiCiiigAo
pcH0pMUAFFLg+lJQAUUUUAFFFFAFLS55biCdpX3FbqZAcdFVyAPyq7UFnaLZxyIrlhJM8pJHQsxO
P1qegb3CiiigRBe3aWNlLdSDKxLnb3Y9h9ScD8aLFLmOyiW8k8y425lYDA3Hkgew6fhRdWaXcluZ
GOyCUS7OzsB8ufoefqBU9AwooooEZGrz6zFqNiNPVGtmf/SMwF9qnjJIYZ5IOBzwT0o1GbWY9cso
7NUaxbIuCYC23PQk7hnkHp0zk5rXop3HcyLifWV8SW8UKodNZCJW8gnaxwR8272YZxgZGc5o8/WB
4nEW1Dphi+95B4frjdu9O+MdsZrXoouFzIt5tZPiWeGZU/s3yx5biAj5hnIzu9CvOMHBxiteiikD
CiiigQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGRPeaoviGG3jtI2tmgkbm5xuwyjc
Rt4IyeM96uia/wDtWw2MQg3Y837T82PXbt/TNWqKBlWOa/a42SWMSQ5P7wXO447Hbt/rRDNqDTFZ
rGGOPn51udx9uNo/nVqigCpDNqLswnsIYgFJUrdb8nsPuDH1oin1Flcy6fChC5QC63bj6H5Bj681
booAytCutRuYpjfW6oFnlVXE288OQFxtHAHetWiigHuFU9YJGiX5BwRbScj/AHTVymTRRzwyQyru
jkUoy+oIwRQCdmJbf8ekP/XNf5CpKj3xQtFAWVS42xqT97A6D8KkpsQUUUUgOfv1szrN+0948DRW
aSJtumXY+W5C5xngcY5qrdXDSMZ7u5Z3jSDzI7e7MU1sxAJAj6Puzn1xkV0j2drJL5z2sDygg+Y0
SlvbnGac1tbvMJmt4WlU5EhjBYfjjNNOxVzHe6sNN1bU7uScnyoo2Mf2gtgnOcIWxnp2rcqBrCye
QyNZWzSE5LmFSxPrnFT0hMKKKKBBTZTIsTGJBI4HyqW2gn64OKdTPOi+0fZ/MXzdm/Z325xn6ZoA
y9JvNVntrlrizjLJPKsebnrhyAv3OAB3q4k2omF2ewhWUY2ILrIb1ydnH5GrdFA7lQTaibdmawhE
wYBY/tWQR67tnH0xTJ7+ez02W6urZI5U4jiSXzN7HhRnA5JIFXqjlgimaMyoGMTh0z2YdD+tAEWn
WjWNjHDI5kl5aVz/ABOTlj+ZqzRRQIKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAp6raPd2R8ji5hYTQH0deQPx5B9
jU1ndx31nFdRZCSruAPVT3B9wcj8KmoAA6AD6UDCiiigQUUUUAFFFFABRRRQAjMqIzuwVVBLE9gO
prP0dGmjl1KVCst6wdVPVIhwi/lz9WNaJGRgjIooGFFFFAgooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAqtc6fb3cgeUzggY/d3EkY/JSBVmigCpNpltcOHkNxlVCjZcyKMD2DD86WXTbaefznNxv4
+7cyKOPYNirVFAFV9Nt5Ln7Qxn8zIbi5kC5/3Q2PwxR/Ztv9q+05n8zdu/4+ZNuf93djHtirVFAF
WPTbeO5+0KZ9+SfmuZCvP+yWx+lWqKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAopHBMbBW2kg4YDOPeu
f8PXup6lGk73crGONTLHcWyxrIWTIKlQDgH8xQOx0NFY9pfyW+jtI0W+c3bwKplZlLmQqPmPIXP5
Dio21nUYZruKe0tR9llgRikrHeJDjI44xnoadgszcorJutWu7az1Wb7NC8mnyfKoZsSJtDenDYOP
Sm3usXtgkC3NtbxzXMhEfzO6ooGTu2rnd24496LBZmxRVTTL039mJmjMbBihGGAOO67gDg/Smarh
YUke+ntYlJBW3A8yVj91VPPOewHP0pAXqKzXm1e20u0P2WK6vC6JcK8ojCqfvNnoSPQde1aR60CC
iuc1rVr6yudTSGW4xDaxyQ+XarIsbEtkscdPl7+pq3e6vdWUt1b+TBJOgiNorMQbjedvPHGD6U7D
szYorAi1PUbT+0ZZY0ntLS7KO7ynzApCkhBjGFLd+TV1b7UX1e5so7S3MVuYy0xlIyrZ4Ax94Yz6
UWCxpUVmwTSJrV+k4AVII5FKSMRty/8ACeA3HOOv4VVS+1GfUtKldEhtLsOQscpJI2blDgjr0OR0
5FFgsblFMmZUgkdpPKVUJL4B2gDrzXNaJ4kd7K7kvbuO9eK3W6TytgYISRsO3jIIH/fVILHUUVly
3+p2UM017ZW5jWNShgmJzIWACHcOOv3ulR3mqalpkLve2lt8zpHC8Tuys7E5DDbuAGM8A5p2CxsU
VkQ6xdT6fcSw2YmnhdVARXVJAe43AMcDOQOeKI9Vv5NMedLFHuUn8poUL5Uf3ipAbOOdo7EUWCxr
0VU0y8kvrITTIkcm9lZEJO0g4wcgEH1HaotVlvYzB9l84Rkt5zwRCWRePlwp6jPU49KQWNCisi31
G8nitbe1e2vLh4DNJO4aOMgNt4UAkHPbtg1BceILu3m+zyWkUVxFCsk8bGR/mbOFQopHQdT607BZ
m9RWJd65ewyztFZRNbQWqXTNI7K+1s5Xbj73B9qk1HXBYXyxAwSpuRZEG/zFLHA5AKjqDgkcUWYW
Neisya+1IazLYW9pbyIkSS+a8pX5SSCpGPvccdvWnxyTf8JI8MgG1rXdGVkbGN+OVPGcnqO1ILGh
RWVDq1xJ9nuWt4hZXM3lRMHPmAkkKSMYwSOnUVq0AFFFFAgooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAR1DoyHOGGDg4P51WtdNtrOyNnAZlhxgAzuSo9AScj8KKKAIY9FtI
LWe3hjkdZskpNcSMpYnOckkg55yOahsdBEKXovVUm9ZGdUld8bRwd7fMTnnPGMDFFFMd3Yk/sDTv
IuINs+y6YNP/AKTJmQgYyTuz0/kKsNptu9ssDGZgjbkczuZFPqHzuH50UUguyW3t47WLy495GSxL
uXYk9ySSTUV5pttfSwzTeaJIM+W8czxlc9fukelFFAiOfRtPurKCzuIDLDbyLLGHkYkOpyDnOT+N
Xjyc0UUAUbjRrK6e5eZJSbpBHNiZwGUdBgHjv09TUUul3U+tWV5LHbG1sVfyiXZpSzADJyMevfvm
iimhj10LTluXuBC5eSXzZMzOVdx0LLnBx2z0wKlj0u2ivnvUM/nSHL5uHKtjplc44z6UUUguNi0m
1ivmvVNx57cMWuJCCOcDaTjHJ4x3piaHp8d1FcpE4kgYmL98+I89QozgA+nSiigLlq7tIb60ktbg
M0Uq7XVXKkj0yOagbSLJ5Y5ZI3kaKEwKHlYgoeoIJw2ff0oooC4R6PYxxyRmN5Ukj8tlmleQbPQb
icD6UJpFmsUkZWWQSABmlnd2GORgk5GDzxRRQFxH0aylgMMqzSgyLJue4dnDL90hicjFD6NYvAkL
RyEJL5yv5z79+Mbt+ck4OOtFFAXLNtbQ2kIhhUqoJJySxJPUknkn3NRXem217NFNMJBLCCEkilaN
lB6jKkegoooENfSLJ44UEbx+QpWNopWRlB6jcCCQepz3ofSbNljVVli8tPLBindCV9CQcn8aKKB3
GzaLYz+d5kcmJ4lhkAmcAoOgwDx+HqabcaFp9yWMscp3FWYCd1DMuMMQDywwOevFFFFwuSf2Xbf2
gb/M/ntgE/aH2kDoNucY5PGO9H9k2v8AaH2/Nx5/TP2mTGM5xtzjGe2KKKAFTS7OO6+0rGwcMXCm
RiiserBM4B68gdzVuiigQUUUUAFFFFABRRRQB//Z

--_004_01FE63842C181246BBE4CF183BD159B449036DFFnkgeml504mbxchi_--


From nobody Mon Oct 27 21:05:54 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E029C1A036D; Mon, 27 Oct 2014 21:05:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level: 
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsbviIlBziRm; Mon, 27 Oct 2014 21:04:57 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040A91A0364; Mon, 27 Oct 2014 21:04:55 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKZ80353; Tue, 28 Oct 2014 04:04:54 +0000 (GMT)
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Oct 2014 04:04:53 +0000
Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.168]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 28 Oct 2014 12:04:48 +0800
From: Xueli 
To: "Sri Gundavelli (sgundave)" , "pierrick.seite@orange.com" , Ted Lemon , "STARK, BARBARA H" 
Thread-Topic: =?iso-8859-1?Q?[DMM]_RE:_[homenet]_Fwd:_New_Liaison_Statement, __"Broadban?= =?iso-8859-1?Q?d_For_um_Work_on_=B3Hybrid_Access_for_Broadband_Networks?= =?iso-8859-1?Q?=B2_(WT-348)"?=
Thread-Index: AQHP7ebM3TmRiAKOr0eUpP4sbHAVFJxE62qQ
Date: Tue, 28 Oct 2014 04:04:47 +0000
Message-ID: <01FE63842C181246BBE4CF183BD159B449036E17@nkgeml504-mbx.china.huawei.com>
References: <31246_1413972312_54478158_31246_662_1_81C77F07008CA24F9783A98CFD706F71142BD145@PEXCVZYM12.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.97.86]
Content-Type: multipart/related; boundary="_004_01FE63842C181246BBE4CF183BD159B449036E17nkgeml504mbxchi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/CXv98rCuio4MbwtzeSVwjLV3c-w
Cc: HOMENET Working Group , "mif@ietf.org" , "dmm@ietf.org" 
Subject: [homenet] =?iso-8859-1?q?=3D=3Fiso-8859-1=3FQ=3FRE=3A=5F=5BDMM=5D?= =?iso-8859-1?q?=5FRE=3A=5F=5FFwd=3A=5FNew=5FLiaison=5FStatement=2C_=5F=5F?= =?iso-8859-1?q?=22Broa=3F=3D_dband_For_um_Work_on_=B3Hybrid_Access_for_Br?= =?iso-8859-1?q?oadband_Networks=B2_=28WT-348=29=22?=
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 04:05:21 -0000

--_004_01FE63842C181246BBE4CF183BD159B449036E17nkgeml504mbxchi_
Content-Type: multipart/alternative;
	boundary="_000_01FE63842C181246BBE4CF183BD159B449036E17nkgeml504mbxchi_"

--_000_01FE63842C181246BBE4CF183BD159B449036E17nkgeml504mbxchi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello Sri

Thanks for the comments.  Just some clarification for the cross email.
A new version about the architecture is uploaded..
http://www.ietf.org/internet-drafts/draft-lhwxz-hybrid-access-network-archi=
tecture-01.txt
There are some new  requirements about the hybrid access topic, such as bon=
ding, traffic policy distribution etc.
Do you mind to share more additional technologies about the existing protoc=
ols solution for hybrid access.
Which exact issues it is really solving, in order to evaluate if the existi=
ng solutions properly solve this use case?
Best Regards
Li


From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 22, 2014 6:56 PM
To: pierrick.seite@orange.com; Xueli; Ted Lemon; STARK, BARBARA H
Cc: HOMENET Working Group; mif@ietf.org; dmm@ietf.org
Subject: Re: [DMM] RE: [homenet] Fwd: New Liaison Statement, "Broadband For=
 um Work on =B3Hybrid Access for Broadband Networks=B2 (WT-348)"



Hi Li,

While the term "hybrid-access" sounds fresh and new, but its important to u=
nderstand that this is largely a use-case around mobile networks. Per my co=
mments in the last HOMENET meeting, mobility working groups have defined so=
lutions for this multi-access use-case. There are clearly mechanisms that a=
llow network entities to negotiate flow policies and switch traffic on appl=
ication basis. The access can be LTE, WLAN, SatRAN, Fixed line ..etc, but t=
he negotiated policies allow the peers to agree on binding a flow to a give=
n access.  Wearing cisco vendor hat, we have deployed solutions for this us=
e-case for the last decade. So, I agree with the BBF use-case and I think w=
e should probably draft a BCP-type solution document, explaining BBF on the=
 tools that are available for addressing this issue. If there are minor gap=
s, we should certainly propose extensions to the protocols.

As pierrick, I'm also not in favor of defining a control protocol for GRE a=
s its not needed. GRE is a use-plane protocol and the semantics that are pr=
esent in the header are only designed to be used for adding meta-data relat=
ed to the IP flows in that tunnel header. There are no semantics for defini=
ng a new signaling layer in a user-plane protocol. GRE was always used in c=
onjunction with a signaling protocol and that signaling protocol is IPsec, =
MIP, PMIP ..and so on. However, you design that control protocol, it will e=
xactly smell and feel like existing protocols. The aspect around subscriber=
 identity, authorization, access policy, Traffic flow template definition .=
..all of this has to be modeled and in the process we will end up reinventi=
ng every thing that we defined over the last many years, but it will have a=
 new title, "GRE-CP".



Regards
Sri







From: "pierrick.seite@orange.com" >
Date: Wednesday, October 22, 2014 3:05 AM
To: Xueli >, Ted Lemon >, "STARK, BARBARA H" >
Cc: HOMENET Working Group >, "mif=
@ietf.org" >, "dmm@i=
etf.org" >
Subject: [DMM] =3D?Windows-1252?Q?RE:_[homenet]_Fwd:_New_Liaison_Statement,=
 _"Broadband_For?=3D um Work on "Hybrid Access for Broadband Networks" (WT-=
348)"

Hi Li,

Architecture considerations and solution design are two different things, w=
hich should not be addressed in the same I-D. People may agree with the big=
 picture depicture and architecture but not agree with going on extensions =
to the GRE protocol to address the issue. BTW, I think that going for exten=
sions to GRE header to address the hybrid access use-case is not the right =
way. Actually, IETF solutions already exist (RFC  4908 ) and, moreover, the=
re is ongoing effort in DMM to update RFC 4908 to meet hybrid access requir=
ements.

BR,
Pierrick

De : Xueli [mailto:xueli@huawei.com]
Envoy=E9 : mercredi 22 octobre 2014 11:48
=C0 : Ted Lemon; STARK, BARBARA H
Cc : HOMENET Working Group; mif@ietf.org
Objet : RE: [homenet] Fwd: New Liaison Statement, "Broadband Forum Work on =
"Hybrid Access for Broadband Networks" (WT-348)"


Hello



Thanks Barbara to send this liaison out.

Hybrid Access network is that Residential gateway (RG, or CPE) is extended =
with more than two access lines

(e.g. DSL + LTE) in order to provide higher bandwidth for the customers. Th=
e scenario and architecture are shown as follows

[cid:image002.jpg@01CF9A07.BF8CD480]



Right now, we have two individual drafts, one for architecture and requirem=
ents, and the other one is for an optional solution.

The draft (http://tools.ietf.org/html/draft-lhwxz-hybrid-access-network-arc=
hitecture-00 ; ) proposes the architecture and gap analysis.

The solution draft proposes one option for the solutions, http://tools.ietf=
.org/html/draft-heileyli-gre-notifications-00

We did not combine them as one draft, because we believe there may be other=
 candidates, and we would like to have further discussions in the related g=
roups and IETF.

We used to present it in Homenet in Toronto.



Now the authors have invited Orange to join this architecture work. We will=
 send out the new version of these drafts soon.

We are glad to invite the experts for comments.



Best Regards

Li Xue on the co-authors behalf





-----Original Message-----

From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of Ted Lemon

Sent: Wednesday, October 22, 2014 3:05 AM

To: STARK, BARBARA H

Cc: HOMENET Working Group

Subject: Re: [homenet] Fwd: New Liaison Statement, "Broadband Forum Work on=
 "Hybrid Access for Broadband Networks" (WT-348)"



On Oct 21, 2014, at 2:55 PM, STARK, BARBARA H > wrote:

> FYI. I made sure they were aware of IETF mif and homenet activities in th=
is area. I intend to try to prevent having to track efforts that try to do =
the same thing in two different ways. But some of the BBF effort may be foc=
used on what can be done around "bonding" of multiple interfaces that are u=
nder the control of a single service provider. I don't see this in mif or h=
omenet.



Thanks.   I couldn't really tell what was being proposed from the Liaison s=
tatement, so this information is helpful.



_______________________________________________

homenet mailing list

homenet@ietf.org

https://www.ietf.org/mailman/listinfo/homenet

___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.



This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.

Thank you.

--_000_01FE63842C181246BBE4CF183BD159B449036E17nkgeml504mbxchi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello Sri


 


Thanks for the comments.  =
Just some clarification for the cross email.


A new version about the archite=
cture is uploaded..



http=
://www.ietf.org/internet-drafts/draft-lhwxz-hybrid-access-network-architect=
ure-01.txt


There are some new  requir=
ements about the hybrid access topic, such as bonding, traffic policy distr=
ibution etc.


Do you mind to share more addit=
ional technologies about the existing protocols solution for hybrid access.=



Which exact issues it is really=
 solving, in order to evaluate if the existing =
solutions properly solve this use case?<=
span lang=3D"EN-US">


Best Regards<=
/p>

Li






&n=
bsp;






From: Sri Gundavel=
li (sgundave)
 [mailto:sgundave@cisco.com] 

Sent: Wednesday, October 22, 2014 6:56 PM

To: pierrick.seite@orange.com; Xueli; Ted Lemon; STARK, BARBARA H
Cc: HOMENET Working Group; mif@ietf.org; dmm@ietf.org

Subject: Re: [DMM] RE: [homenet] Fwd: New Liaison Statement, "B=
roadband For um Work on =B3Hybrid Access for Broadband Networks=B2 (WT-348)=
"






 




<We pr=
obably should not be cross posting the mail to three WG mailers, but I will=
 respond to this one last email>






&nbs=
p;






Hi Li,






&nbs=
p;






While the=
 term "hybrid-access" sounds fresh and new, but its important to =
understand that this is largely a use-case around mobile networks. Per my c=
omments in the last HOMENET meeting, mobility working
 groups have defined solutions for this multi-access use-case. There are cl=
early mechanisms that allow network entities to negotiate flow policies and=
 switch traffic on application basis. The access can be LTE, WLAN, SatRAN, =
Fixed line ..etc, but the negotiated
 policies allow the peers to agree on binding a flow to a given access. &nb=
sp;Wearing cisco vendor hat, we have deployed solutions for this use-case f=
or the last decade. So, I agree with the BBF use-case and I think we should=
 probably draft a BCP-type solution document,
 explaining BBF on the tools that are available for addressing this issue. =
If there are minor gaps, we should certainly propose extensions to the prot=
ocols.






&nbs=
p;






As pierri=
ck, I'm also not in favor of defining a control protocol for GRE as its not=
 needed. GRE is a use-plane protocol and the semantics that are present in =
the header are only designed to be used
 for adding meta-data related to the IP flows in that tunnel header. There =
are no semantics for defining a new signaling layer in a user-plane protoco=
l. GRE was always used in conjunction with a signaling protocol and that si=
gnaling protocol is IPsec, MIP,
 PMIP ..and so on. However, you design that control protocol, it will exact=
ly smell and feel like existing protocols. The aspect around subscriber ide=
ntity, authorization, access policy, Traffic flow template definition ̷=
0;all of this has to be modeled and in
 the process we will end up reinventing every thing that we defined over th=
e last many years, but it will have a new title, "GRE-CP".






&nbs=
p;






&nbs=
p;






&nbs=
p;






Regards






Sri<=
/o:p>






&nbs=
p;






&nbs=
p;






&nbs=
p;






&nbs=
p;






&nbs=
p;






&nbs=
p;






&nbs=
p;






From:
&quo=
t;pierrick.seite@orange.com" <pierrick.seite@ora=
nge.com>

Date: Wednesday, October 22, 2014 3:05 AM

To: Xueli <xueli@huawei.com>, Ted Lemon <Ted.Lemon@no=
minum.com>, "STARK, BARBARA H" <bs7652@att.com>

Cc: HOMENET Working Group <ho=
menet@ietf.org>, "mif@ietf.org<=
/a>" <mif@ietf.org>, "<=
a href=3D"mailto:dmm@ietf.org">dmm@ietf.org" <dmm@ietf.org>

Subject: [DMM] =3D?Windows-1252?Q?RE:_[homenet]_Fwd:_New_Liaison_Sta=
tement, _"Broadband_For?=3D um Work on “Hybrid Access for Broadb=
and Networks” (WT-348)"






&nbs=
p;








Hi Li,


 


Architecture considerations and solution design are two different=
 things, which should not be addressed in the same I-D. People may agree wi=
th the big picture depicture and architecture
 but not agree with going on extensions to the GRE protocol to address the =
issue. BTW, I think that going for extensions to GRE header to address the =
hybrid access use-case is not the right way. Actually, IETF solutions alrea=
dy exist (RFC  4908 ) and, moreover,
 there is ongoing effort in DMM to update RFC 4908 to meet hybrid access re=
quirements.  


 <=
/span>


BR,


Pierrick  


 <=
/span>








De : Xueli
 [mailto:xueli@huawei.com] 

Envoy=E9 : mercredi 22 octobre 2014 11:48

=C0 : Ted Lemon; STARK, BARBARA H

Cc : HOMENET Working Group; mif=
@ietf.org

Objet : RE: [homenet] Fwd: New Liaison Statement, "Broadba=
nd Forum Work on “Hybrid Access for Broadband Networks” (WT-348=
)"





 


Hello =



 =



Thanks=
 Barbara to send this liaison out.


Hybrid=
 Access network is that Residential gateway (RG, or CPE) is extended with m=
ore than two access lines



(e.g. =
DSL + LTE) in order to provide higher bandwidth for the customers. The =
scenario and architecture are shown as follows



3D"cid:image002.jpg@01CF9A07.BF=

 =



Right =
now, we have two individual drafts, one for architecture and requirements, =
and the other one is for an optional solution.


The dr=
aft (http://tools.ietf.org/html/draft-lhwxz-hybrid-access-net=
work-architecture-00 ; ) proposes the
 architecture and gap analysis.


The so=
lution draft proposes one option for the solutions,
=
http://tools.ietf.org/html/draft-heileyli-gre-notifications-00  


We did=
 not combine them as one draft, because we believe there may be other candi=
dates, and we would like to have further discussions in the related groups =
and IETF.<=
/p>

We use=
d to present it in Homenet in Toronto.



 =



Now th=
e authors have invited Orange to join this architecture work. We will send =
out the new version of these drafts soon.


We are=
 glad to invite the experts for comments.


 =



Best R=
egards


Li Xue=
 on the co-authors behalf


 =



 =



-----O=
riginal Message-----


From: =
homenet [mailto:homenet-bounces=
@ietf.org] On Behalf Of Ted Lemon


Sent: =
Wednesday, October 22, 2014 3:05 AM


To: ST=
ARK, BARBARA H


Cc: HO=
MENET Working Group


Subjec=
t: Re: [homenet] Fwd: New Liaison Statement, "Broadband Forum Work on
“Hybrid =
Access for Broadband Networks”
 (WT-348)"


 =



On Oct=
 21, 2014, at 2:55 PM, STARK, BARBARA H <bs7652@att.com> wrote:


> F=
YI. I made sure they were aware of IETF mif and homenet activities in this =
area. I intend to try to prevent having to track efforts that try to do the=
 same thing in two different ways. But some
 of the BBF effort may be focused on what can be done around "bonding&=
quot; of multiple interfaces that are under the control of a single service=
 provider. I don't see this in mif or homenet.


 =



Thanks=
.   I couldn't really tell what was being proposed from the Liais=
on statement, so this information is helpful.


 =



______=
_________________________________________


homene=
t mailing list


homenet@ietf.org


https=
://www.ietf.org/mailman/listinfo/homenet




______________________________=
___________________________________________________________________________=
________________


 


Ce message et ses pieces joint=
es peuvent contenir des informations confidentielles ou privilegiees et ne =
doivent donc


pas etre diffuses, exploites o=
u copies sans autorisation. Si vous avez recu ce message par erreur, veuill=
ez le signaler


a l'expediteur et le detruire =
ainsi que les pieces jointes. Les messages electroniques etant susceptibles=
 d'alteration,


Orange decline toute responsab=
ilite si ce message a ete altere, deforme ou falsifie. Merci.


 


This message and its attachmen=
ts may contain confidential or privileged information that may be protected=
 by law;


they should not be distributed=
, used or copied without authorisation.


If you have received this emai=
l in error, please notify the sender and delete this message and its attach=
ments.


As emails may be altered, Oran=
ge is not liable for messages that have been modified, changed or falsified=
.


Thank you.









--_000_01FE63842C181246BBE4CF183BD159B449036E17nkgeml504mbxchi_--

--_004_01FE63842C181246BBE4CF183BD159B449036E17nkgeml504mbxchi_
Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=9036;
	creation-date="Tue, 28 Oct 2014 04:04:47 GMT";
	modification-date="Tue, 28 Oct 2014 04:04:47 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf
IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7
Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCADWAawDASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0uiii
uc4gooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKbHLHMgeJ1dCSAynI
4OD+tADqrXNxdxSBbfT2uVIyWEyJg+mGqzRQBUmub2NwItMeZSoJYXCLg9xgntSy3N4k+yPTWlj4
/eCdF+vBOeKtUUAVXubxbny101ni3Aed56AY9duc0fabz7V5f9mt5O7HneemMeu3Ofwq1RQBVjub
xrny301o4skecZ0Ix67Qc1aoooAKKRmVELsQqqMknoBQrBlDKQQRkEdCKAFooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKaZYxMs
JdRIylgmeSBjJ/UfnTqACiiigAooooAKKbHLHMpaJ1cBipKnOCDgj8DTqACiio7idLa2luJM7IkL
tgZOAMmgCrq9xJFaCC3OLm6YQw/7JPVv+AjJ/CrVtbxWltFbQLtiiUIo9hTl2SqkoUHIypI5AI/S
nUAFFFFABRRRQAUUUUAFFFFABgEYIBB6g96zdIP2V59JdiTaENDnq0Lfd/LlfwFaVJsXfv2jfjG7
HOPTNAxaKbHLHMC0bq4VipKnOCDgj8DTqBBRRUVxdRWvleaSBLIIlbHAY9M+men1IoAlooooAKKK
KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAMubRjLrcV/
9su1RYnUotww5LKQAP7vByPpVoWCi6+0fa7zO7d5ZuG8v6bemPale7K6pDZbARJC8u/PTaVGMf8A
Av0qzQN3Ksdgsdx5/wBrvWOSdj3DFP8AvnpiiHT1hmMgu7185+WS4Zl59qtUUAVIdPWBmYXl9JuU
riW5ZgM9xnofeiLTliVx9svn3rty9yzFfceh96t0UAZuj6S2mJKHuZ5mklkcB5mdQGYkcHv6mtKq
1hdm9hkkKBNk0kWAc52sVz+OKsM6ou52VR6scChg9xaq6qjSaPexopZ2t5AqgZJJU4FLaaha3tlH
dxSqI5FDDcwBGfXng064vre1tJbp5UMcSMxKsDnAyQOetDBaMfbgrawgjBEagg9uKkpkM0c8SyxO
GVgDkEGn03uIKKKKQBRVNr24GrLYi0BjaMyed53YHH3cep9ap3Wt3kFzLEmjvKqGTa3nhWkCAEkL
t/2uOecUDszYorHGuXDahLaR6crmKbyyBcjeRhSWCbegDAnn1rYoCwUUUUCCmyx+bE0Zd03DG5G2
sPoe1OooAytN0U2UFxG97dsZpZGBFyx2hmyCPRvU1aTTlSF4vtl8wfHztcsWXHoe1Osbs3kUrlAn
lzyRYBznaxGfxxVmgbvcqDTlW3aH7ZfEMwO83LFx7Buw9qSTTIpdOmsZJp5VmBG+aUuynsQT6HBq
5RQFytp089xYxtdRmO4XKSgjGWBwSPY9R9as1Wvbz7Ebd3TMMkojkfP+r3cKfpnA/GrNAgooooAK
KytV1w6XqFjamykmF5JsDq6AA4Pqw74HPHPrxRf64bHWrLTTZSSfa9wEgdAAQM9Cc+vX04zTsOzN
WisqfXDB4ht9INnI3nxs6yh0xxjtuz0z78cA0f24R4kGjGzkBMPmCbemOuOmc9OfX2xzSsFjVorK
g1wzeIp9HNlIhiiEnml0IIJOeA2fT355ArVoBqwUUUUCCiiigAooooAKKKbLIsMTSPu2qMnapY/g
ByaAHUVl6drsN9bTTNFOnkyOpAt5OQrlRjK8n2HSrKapbPA8wW42RkA5tZA3PopXJ/Cgdi3RVQap
bG3acLcbFbaQbWTdn/d25x74o/tO2FsLjbcbC23H2WTdn/d25x74xQBborL1LXYbHSJL9IpnwpKK
1vIMkHuNuQPc1oQTx3MQljDhScfvI2Q/kwBoCxJRRRQIKKKKAKklrI2swXY2+VHbyRtzzlmUjj/g
Jq3VOS4lXW7e2DfuntpHZcdWDIBz+Jq5R0GwooooEFFQXzyRWFxLCwSSOJmRmXcAQCenesrRdUur
uBru4uhLAsfzoLRo5A+FPyryWXDelCHbS5o6ZayWlvKku3L3Esgwc8M5I/Q1YlhiuIzHPFHKh6rI
oYH8DWdp2uw31vPK0U6eTJIpAt5OVVioIyvJ9hzVldUtngeYLc7EIBzayhufQbcn8KGDvcZZaNp9
lp8dktpA8aKAd0K/OR0JGME0650iwubCWyNpAkUisMLCuFJGNwGMZ96Zouqpq+nRXIjeN2QM6tG6
gE+hYDP4Vfpu99Qu0yK2tYLOBYbeKOJFA4RAoJx1wO9S1S1S5lsoortDmCKQfaFxn92eCw/3SQfp
mrtIQUUUUAZl7YahPetPb3dtEhgaEK8DMwB5JyHHP4U5dPu47mwdbqIx2kPlMHiYvJkAE53cdPQ1
o0UDuYb6DdnULm7iu7WKS4k3eatu3mouFBUNv54UdR3Nbp5JOMUlFAN3CiiigQUUVStLia71C7ZX
H2SAiFAAPnkHLtn24X8DQA7TbaS1hmSXbl7mWQYOeGYkfoat0UUAFFFFAEV1bR3lrLbTDMcqFWx7
96bYi6WyiW9Km4VdrspyGI43fj1/Gp6KACisnxBdataW8L6VEkrGVfMUxM52A5bofTPue1M1u71i
2NkdPjilDSL9o/cu2F6MeD05HHX9aaQ7Gu0UbnLxox6ZZQe+f580NFG7b2jRm4+YqCeOnNOGcc4z
3x0opCGmKMvvMaF8g7iozkdOfxP50eVHv3+Wm/Od20ZzjHX6cU6igBoijD7xGgfJO4KM89efwH5U
6isfT7rWJNevILuOMWSgGCRYWXcRwwBJ9cdevagZsUVkaRdavPqV9FqEca26MDbusLLvGMHBJ9Qe
vPIPStegHoFFFFAgooooAKKKB1oAZFBHboUiQIpYuQPUnJP4k0+s/RGZrKUsxJ+1zjk5/wCWjVoU
De4UUUUCGTwR3ULwTIJI5BhlPcU/rWf4gZl8P3zKxUiLgg4I5FaJ60DEooooEFFFFAEDWgfUYr3e
QY4ni244O4qc5/4DU9Z8rN/wkdqu47TaSkjPGdyVoUdBsKKKKBEdxAtzbSQOXVJUKMUbBweDg9qq
Wej29lPHMk11K0UZjj86beEU4zj/AL5H5VfooGMigjt1KRIEDMXIHdmOSfxJp+az9FZmtJyzE4vJ
xyc8eY1aFAPcZBDFbQJBCgSKMbUUdAKfRRQIbIiSxtHIoZHUqynoQeoqKytms7KK2aZpvKXaHYYJ
A6Z/DAqeigAooqtcz3sTgW1gLlSOWNwseD6YINAFmiqk1xfo4EOmrMpAJY3Kpg9xgj9aWW4vkn2R
acssfH7z7Sq/XjFAFqiqr3F8tz5aacrw7sed9pUceu3Gfwo8+++1eX/Z6+Tux532lenrtxn8KALV
FVY7i+a52PpypDkjzftKnj124zVqgBHDFGCNsYggNjOD61DZWkdjZRWsWSsa4yerHqSfcnJ/Gp6K
ACiiigAooooAKKKy/EOn32o6d5Gn3T2828HeJNo4OeeDnpjt1oGjUopkKskEauzM4Ubi7BjnvkgD
P5U+gQUUUUAFFFFABRRRQAUUEZBGSM9x1FZGhadqFjNetfXUk6zy+ZEHlD7AeoPyjnjr056cUDNe
iiigQUUUUAFFFKOtAFWBrK1tneKWJIRK5d2k+UOWO7JP+1mpVubdy4W4ibyxl8SA7B6n0/Guduhv
8H6igQuzXUwULEZDnzz/AAjrUTwSvfX7TRtdxrcW0k/l2jRiWJVOQFOd+CQSM9ulNIu2504uIGg8
9Z4jCBnzQ4Kfn0prXtmkayteW6xscK5mUKfoc81gXKQSC6njt7mCzmnhMZjtiw8xckyGLGdn3QeO
cfjTZLW2fQry4msU3q0wgaK1dfOLqAX8rBIJxj8M96LCsdA62upWbxb47iCUbWMb5B9sip6w9SsJ
JvD9wujEQm5BkaPyDmRjgcAldvStF4NRMSKuowiQZ3P9kyG9ON/H50CLdFVJYNQZIxFfxRsFw7G1
3bz6gbhj6c0TQag2zyb+KPCgNutd24+v3hj6UgLdFVJodQeQGG/iiXAyrWu8k9zncKWWG/afdFfR
Rxcfuzbbj7/NuH8qBExt4muUuSv71EKK2eikgkfoKkrIns9UfxDDcR3aLbLBIvNvnbllIUndyTg8
47VsDrR0GyL7RB5xh8+LzR1j3jcPw601L2zlLCO8t3KDLBZVO0dycHgVj6fHaRiztbrTXl1CCYu0
gtz8r5OZfM6EHPqTzjFVdLthPJPI0ccUNrdTzgC1dZXDFwASRgqQc4Ge1Mdjooby0uHKQXdvMwGS
scqscfQGpq5XwsRF9jhlgMk3k7UcWjw/ZlCDcrZGCSR611VDVmJqxBaJbJE4tSpQyuW2tn5yx3fr
mp6ztD/485/+vy4/9GNWjSB7sKKKKBBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUANll
jgiaWV1jjUZZmOABTqoa1o9vrmnPY3OBG55bYCwHfbnoferNpbraWcVuu3ESBcqgUH3wOBmgZNUU
13a2zBbi6ghJGQJJVUkfialrG8QSWyyaeJoGlZLpJGK2zSbUG7JJCmhbglc2RyARyDyCKaJEMpiD
AyKoYr3AOQD9OD+Vc1rCE3upTxNfB4rON4FiEoTzcnBAAwTjaMfmKmuYLKPxC19cW124ntozE0Ql
O5wzZGFOBwV4OB+tOw7HRYOM44owfSuWlXUF1mVpJCk5ucxMEnbMWRgAL+7xjIOe+asxJbzeJ7tX
mvlXdGYUHmrH5gzuOcY9BjOKLCsdBg+lGD6da5WyDQXNvNE98ZJL+eMiUSlViw20EEYC52kE+vWn
aJHerfwJcyMJiGF2u2clzjnJb5Bz0K/hRYbVjpY5Emj8yJw6ZI3KcjIOD+op1YHh23tbHNqttdJd
K8ocuJSirvJHLHbyCMYredFkRkdQysCCGGQR7ikxPcSOWOZS0Tq4DFSVOcEHBH4GnVmaJoVvoUc6
QMrefJ5jHywpBPUcds5IHbNadABRRRQIKKKB1oAhtLmK5iaSFSqrI6HIx8ysQf1BqbNUdHikhs5V
lRkY3MzAMMZBkYg/iKvUDe4uT60ZNJRQIhvLqOytJbqbcY4l3NtGTipqoa5FJPod5FCjSSPHhVUZ
JORWgetA+glFFFAgooooAha6jW9jtDu8ySNpBxxhSAf/AEIVNVGWKQ6/bTBGMa2sql8cAlkwP0P5
VeoGGaXJ9aSigQuT60lFFAEFpcxXUTvCpVVleM5GPmViD+oqeqOjxSQ2syyoyE3UzAMMZBkJB/EV
eoG9wooooEFFFFABRRVa5sI7pw7zXSEDGIbh4x+SkUAWaKqTadFO4dp7tSABiO6kQcewPX3pZdOi
mn85p7tW4+VLl1Xj/ZBxQBaoqq+nxPc/aDNdhsg7VuXCf98g4x7Uf2fF9q+0eddbt27b9pfZ/wB8
5xj2oAtUVVj0+KO588T3ZbJO1rl2T/vknGKtUAFFFFABRRRQAUUUUAFU9U1az0e2FxeyMiFgowhb
qQO31q5UF7Y22o25t7uPzYiclCxAP1x1/wAaBq3UljkSaNZIzlHGVOCMj6Gn5I701V2qFBJCgDJO
T+feloELk+tGaSigAzS5PrSUUALk+tJmiigALbVJJ4Ayao6drNjqrzpZys7W7lHDIy4Ix6j3q9Va
00+2sXle3jKNO26Qlyd7f3jk9ff6elA+hZooooEFFFFABSM6opd3VFHVmOAPxpaRlV1Kuqup6qwy
D+FAFSz1WyvYZJY7iILG7I2ZF42sVz16Ejipxd2rI0i3UBRfvMJVIH1OeKhtNKsrKGSKK3iKyOzt
mNedzFsdOgJ4qYWlqqNGtrAEb7yiJQD9RjmgegC7tTGZBdQGMHBfzV2g+mc0fa7Xy/M+1QeXnG/z
V259M5oFpaiMxi1gCE5KeUu0n1xij7Ja+X5f2WDy852eUu3PrjFAEF7qtlY2D3klxE0SAkbZF+bH
Yc8mrUckcqb4pEkU/wASMGH5iq17pVnfWL2ckEaxOCBtjUbc9xxxVmOOOJdkUaRqP4UUKPyFADqK
KKBBRRRQBWe7ZdVhstgKyQPKWzyCpUY/8eqzVSS1kbWILsFfLjt5IyM85ZlI/wDQTVugYUUUUCI7
iR4raWVEDsiFgpbaDgZxnBxVCy1eSUW5vbaO0W5h82JxPvXAAJDEgYOCD6dav3Eby20sSOEZ0Khi
u4DIxnGRmqFlpMkIgF7cx3S20PlRIINi4IAJYEnJwB+tCHpYntNVsr2KSSO4iCxO6NmReNrbc9eh
xwamF5aMjSC7gKL95hKuB9TmorTSrKyikjit4isru7ZjXnc27HTpzwKmFpahCgtYAjfeURLg/UYo
DQj0/ULfU7OO6tpFZZFDbQwJXPY4PFWarafp9vplnHa20aqsahdwUAtjucDmrNNgMmmjt4JJ5W2x
xKXY+gAyajsZpriyhmuIhDJIu4xg5256A++MZ96j1G0e+WCDIFv5oecHq6ryF+hOM+wq2eTmkAUU
UUCCiiigAooooAKKKKAEffsbywC+DtDdM9s1Bp94t/Yx3IUozZDoeqODhlP0INWKp29rLbajdSIV
+zXAEm3PKy9GwPQgA/Ue9Ay5RRRQIKKKKACiiigDK17Wm0SCGYWhnWSVUYiRV2gnk8nsMnPQY5pu
s65JpBsv9BMoupVjb98g2Z+p7HHPTnrWsyK33lVu3IzQyI33kVuMcgHimPQUZxyMHuPSiiikIKKK
KACsmw1uS81y80xrIxfZQpEnmo27PXgH1446Z5xWtSBEByEUHnkDnnrQMytK1x9S1K+s2sjB9kcD
cZUbcCB6H13DjjjHWtakCIpyqKD0yABS0AwooooEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF
AFKSeVdct7YP+6e2kdlx1YMgB/U1dqBrRW1CK83kNHE0QXHBDEHP/jtT0DCiiigQUUUUAUtKuJbm
2meZ9zLczIDjoquQB+QqzcTrbxGVklcDtFGXb8hzTLO0WzieNXLh5XlJI6FmLEfrU9DG9zL03W1v
dIivpLa6VmVSypbSHk/3RjJHvTr3WEttJnvUtromNHKo1tIDkLnkYyB71fhhjt4UhhQRxoMKq9AK
WSNJonikUOjqVZT0IPBFNhpchsbtb21SYRyx7gMiSNkOcdgece9WKRVCqFUYAGAPQUtJiCiiigAo
pcH0pMUAFFLg+lJQAUUUUAFFFFAFLS55biCdpX3FbqZAcdFVyAPyq7UFnaLZxyIrlhJM8pJHQsxO
P1qegb3CiiigRBe3aWNlLdSDKxLnb3Y9h9ScD8aLFLmOyiW8k8y425lYDA3Hkgew6fhRdWaXcluZ
GOyCUS7OzsB8ufoefqBU9AwooooEZGrz6zFqNiNPVGtmf/SMwF9qnjJIYZ5IOBzwT0o1GbWY9cso
7NUaxbIuCYC23PQk7hnkHp0zk5rXop3HcyLifWV8SW8UKodNZCJW8gnaxwR8272YZxgZGc5o8/WB
4nEW1Dphi+95B4frjdu9O+MdsZrXoouFzIt5tZPiWeGZU/s3yx5biAj5hnIzu9CvOMHBxiteiikD
CiiigQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGRPeaoviGG3jtI2tmgkbm5xuwyjc
Rt4IyeM96uia/wDtWw2MQg3Y837T82PXbt/TNWqKBlWOa/a42SWMSQ5P7wXO447Hbt/rRDNqDTFZ
rGGOPn51udx9uNo/nVqigCpDNqLswnsIYgFJUrdb8nsPuDH1oin1Flcy6fChC5QC63bj6H5Bj681
booAytCutRuYpjfW6oFnlVXE288OQFxtHAHetWiigHuFU9YJGiX5BwRbScj/AHTVymTRRzwyQyru
jkUoy+oIwRQCdmJbf8ekP/XNf5CpKj3xQtFAWVS42xqT97A6D8KkpsQUUUUgOfv1szrN+0948DRW
aSJtumXY+W5C5xngcY5qrdXDSMZ7u5Z3jSDzI7e7MU1sxAJAj6Puzn1xkV0j2drJL5z2sDygg+Y0
SlvbnGac1tbvMJmt4WlU5EhjBYfjjNNOxVzHe6sNN1bU7uScnyoo2Mf2gtgnOcIWxnp2rcqBrCye
QyNZWzSE5LmFSxPrnFT0hMKKKKBBTZTIsTGJBI4HyqW2gn64OKdTPOi+0fZ/MXzdm/Z325xn6ZoA
y9JvNVntrlrizjLJPKsebnrhyAv3OAB3q4k2omF2ewhWUY2ILrIb1ydnH5GrdFA7lQTaibdmawhE
wYBY/tWQR67tnH0xTJ7+ez02W6urZI5U4jiSXzN7HhRnA5JIFXqjlgimaMyoGMTh0z2YdD+tAEWn
WjWNjHDI5kl5aVz/ABOTlj+ZqzRRQIKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAp6raPd2R8ji5hYTQH0deQPx5B9
jU1ndx31nFdRZCSruAPVT3B9wcj8KmoAA6AD6UDCiiigQUUUUAFFFFABRRRQAjMqIzuwVVBLE9gO
prP0dGmjl1KVCst6wdVPVIhwi/lz9WNaJGRgjIooGFFFFAgooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAqtc6fb3cgeUzggY/d3EkY/JSBVmigCpNpltcOHkNxlVCjZcyKMD2DD86WXTbaefznNxv4
+7cyKOPYNirVFAFV9Nt5Ln7Qxn8zIbi5kC5/3Q2PwxR/Ztv9q+05n8zdu/4+ZNuf93djHtirVFAF
WPTbeO5+0KZ9+SfmuZCvP+yWx+lWqKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAopHBMbBW2kg4YDOPeu
f8PXup6lGk73crGONTLHcWyxrIWTIKlQDgH8xQOx0NFY9pfyW+jtI0W+c3bwKplZlLmQqPmPIXP5
Dio21nUYZruKe0tR9llgRikrHeJDjI44xnoadgszcorJutWu7az1Wb7NC8mnyfKoZsSJtDenDYOP
Sm3usXtgkC3NtbxzXMhEfzO6ooGTu2rnd24496LBZmxRVTTL039mJmjMbBihGGAOO67gDg/Smarh
YUke+ntYlJBW3A8yVj91VPPOewHP0pAXqKzXm1e20u0P2WK6vC6JcK8ojCqfvNnoSPQde1aR60CC
iuc1rVr6yudTSGW4xDaxyQ+XarIsbEtkscdPl7+pq3e6vdWUt1b+TBJOgiNorMQbjedvPHGD6U7D
szYorAi1PUbT+0ZZY0ntLS7KO7ynzApCkhBjGFLd+TV1b7UX1e5so7S3MVuYy0xlIyrZ4Ax94Yz6
UWCxpUVmwTSJrV+k4AVII5FKSMRty/8ACeA3HOOv4VVS+1GfUtKldEhtLsOQscpJI2blDgjr0OR0
5FFgsblFMmZUgkdpPKVUJL4B2gDrzXNaJ4kd7K7kvbuO9eK3W6TytgYISRsO3jIIH/fVILHUUVly
3+p2UM017ZW5jWNShgmJzIWACHcOOv3ulR3mqalpkLve2lt8zpHC8Tuys7E5DDbuAGM8A5p2CxsU
VkQ6xdT6fcSw2YmnhdVARXVJAe43AMcDOQOeKI9Vv5NMedLFHuUn8poUL5Uf3ipAbOOdo7EUWCxr
0VU0y8kvrITTIkcm9lZEJO0g4wcgEH1HaotVlvYzB9l84Rkt5zwRCWRePlwp6jPU49KQWNCisi31
G8nitbe1e2vLh4DNJO4aOMgNt4UAkHPbtg1BceILu3m+zyWkUVxFCsk8bGR/mbOFQopHQdT607BZ
m9RWJd65ewyztFZRNbQWqXTNI7K+1s5Xbj73B9qk1HXBYXyxAwSpuRZEG/zFLHA5AKjqDgkcUWYW
Neisya+1IazLYW9pbyIkSS+a8pX5SSCpGPvccdvWnxyTf8JI8MgG1rXdGVkbGN+OVPGcnqO1ILGh
RWVDq1xJ9nuWt4hZXM3lRMHPmAkkKSMYwSOnUVq0AFFFFAgooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAR1DoyHOGGDg4P51WtdNtrOyNnAZlhxgAzuSo9AScj8KKKAIY9FtI
LWe3hjkdZskpNcSMpYnOckkg55yOahsdBEKXovVUm9ZGdUld8bRwd7fMTnnPGMDFFFMd3Yk/sDTv
IuINs+y6YNP/AKTJmQgYyTuz0/kKsNptu9ssDGZgjbkczuZFPqHzuH50UUguyW3t47WLy495GSxL
uXYk9ySSTUV5pttfSwzTeaJIM+W8czxlc9fukelFFAiOfRtPurKCzuIDLDbyLLGHkYkOpyDnOT+N
Xjyc0UUAUbjRrK6e5eZJSbpBHNiZwGUdBgHjv09TUUul3U+tWV5LHbG1sVfyiXZpSzADJyMevfvm
iimhj10LTluXuBC5eSXzZMzOVdx0LLnBx2z0wKlj0u2ivnvUM/nSHL5uHKtjplc44z6UUUguNi0m
1ivmvVNx57cMWuJCCOcDaTjHJ4x3piaHp8d1FcpE4kgYmL98+I89QozgA+nSiigLlq7tIb60ktbg
M0Uq7XVXKkj0yOagbSLJ5Y5ZI3kaKEwKHlYgoeoIJw2ff0oooC4R6PYxxyRmN5Ukj8tlmleQbPQb
icD6UJpFmsUkZWWQSABmlnd2GORgk5GDzxRRQFxH0aylgMMqzSgyLJue4dnDL90hicjFD6NYvAkL
RyEJL5yv5z79+Mbt+ck4OOtFFAXLNtbQ2kIhhUqoJJySxJPUknkn3NRXem217NFNMJBLCCEkilaN
lB6jKkegoooENfSLJ44UEbx+QpWNopWRlB6jcCCQepz3ofSbNljVVli8tPLBindCV9CQcn8aKKB3
GzaLYz+d5kcmJ4lhkAmcAoOgwDx+HqabcaFp9yWMscp3FWYCd1DMuMMQDywwOevFFFFwuSf2Xbf2
gb/M/ntgE/aH2kDoNucY5PGO9H9k2v8AaH2/Nx5/TP2mTGM5xtzjGe2KKKAFTS7OO6+0rGwcMXCm
RiiserBM4B68gdzVuiigQUUUUAFFFFABRRRQB//Z

--_004_01FE63842C181246BBE4CF183BD159B449036E17nkgeml504mbxchi_--


From nobody Mon Oct 27 21:11:17 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA911A0364; Mon, 27 Oct 2014 21:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.339
X-Spam-Level: **
X-Spam-Status: No, score=2.339 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-X4bl8MHuFn; Mon, 27 Oct 2014 21:11:08 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6BB71A020A; Mon, 27 Oct 2014 21:11:06 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOC68862; Tue, 28 Oct 2014 04:11:05 +0000 (GMT)
Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Oct 2014 04:11:04 +0000
Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.168]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Tue, 28 Oct 2014 12:10:57 +0800
From: Xueli 
To: Alexandru Petrescu , Ted Lemon , "STARK, BARBARA H" 
Thread-Topic: =?gb2312?B?obBIeWJyaWQgQWNjZXNzIGZvciBCcm9hZGJhbmQgTmV0d29ya3OhsSAoV1Qt?= =?gb2312?Q?348)?=
Thread-Index: AQHP7hVMKwQDYikd/UqCpyrRYAba8JxE7LCQ
Date: Tue, 28 Oct 2014 04:10:57 +0000
Message-ID: <01FE63842C181246BBE4CF183BD159B449036E28@nkgeml504-mbx.china.huawei.com>
References: <20141021160652.24101.60334.idtracker@ietfa.amsl.com> <4BBD7952-84F7-40F9-9034-8DD7A1F2A05C@nominum.com> <2D09D61DDFA73D4C884805CC7865E61130EA59FC@GAALPA1MSGUSRBF.ITServices.sbc.com>  <01FE63842C181246BBE4CF183BD159B4490350AD@nkgeml504-mbx.china.huawei.com> <5447DB20.9080505@gmail.com>
In-Reply-To: <5447DB20.9080505@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.97.86]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/2uURzU7LK9O1WKb8HDb0didK9nI
Cc: HOMENET Working Group , "mif@ietf.org" 
Subject: Re: [homenet] =?gb2312?b?obBIeWJyaWQgQWNjZXNzIGZvciBCcm9hZGJhbmQgTmV0?= =?gb2312?b?d29ya3OhsSAoV1QtMzQ4KQ==?=
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 04:11:10 -0000

SGVsbG8gQWxleA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgbmljZSBjb21tZW50Lg0KVGhlIHNjZW5h
cmlvIGhlcmUgaXMgZm9yIHRoZSBmaXhlZCBvcGVyYXRvcnMgcmF0aGVyIHRoYW4gdGhlIG1vYmls
ZSBwaG9uZSBmb3IgaGlnaGVyIGJhbmR3aWR0aC4NCkkgbWFrZSB0aGlzIGNsYXJpZmljYXRpb24g
aW4gdGhlIG5ldyB2ZXJzaW9uIGFyY2hpdGVjdHVyZSBkcmFmdCBhc6O6DQqhsSBIb3N0cyBpbiB0
aGUgY3VzdG9tZXIgc2l0ZSBtYXkgY29ubmVjdCB0byB0aGUgSW50ZXJuZXQgdGhyb3VnaCB0aGUN
CiAgIENQRSwgdGhlIDNHLzRHIG5ldHdvcmssIG9yIGJvdGguICBJbiBtb3N0IGNhc2VzIHRoZSBt
YWpvcml0eSBvZiB0aGUNCiAgIGhvc3RzIGNvbm5lY3RzIHRvIHRoZSBJbnRlcm5ldCB0aHJvdWdo
IHRoZSBDUEUgb25seSBhbmQgd2lsbA0KICAgZXhwZXJpZW5jZSBzbG93IEludGVybmV0IGFjY2Vz
cyB3aGVuIHRoZSBiYW5kd2lkdGggcHJvdmlkZWQgYnkgdGhlDQogICBmaXhlZCBhY2Nlc3MgbmV0
d29yayBpcyBmdWxseSB1dGlsaXplZCAoZS5nLiwgdGhlIHRyYWZmaWMgb3ZlciB0aGUNCiAgIGZp
eGVkIGFjY2VzcyBuZXR3b3JrIHJlYWNoZWQgaXRzIG1heGltdW0gY2FwYWNpdHkgb3IgYSBwcmUt
c3BlY2lmaWVkDQogICB0aHJlc2hvbGQgc2V0IGJ5IHRoZSBvcGVyYXRvcikuICANClNvIHdlIGFy
ZSBjb25zaWRlcmluZyB0aGUgc2NlbmFyaW8gd2l0aCBDUEUgZXh0ZW5zaW9uIHdpdGggbXVsdGlw
bGUgYWNjZXNzIG5ldHdvcmtzLg0KDQpJIHdvdWxkIGxpa2UgdG8ga25vdyBhZGRpdGlvbmFsIGlu
Zm9ybWF0aW9uIG9uIHRoZSBpbnRlcm5ldCBkcmFmdHMgeW91IG1lbnRpb25lZCwgZG8geW91IG1p
bmQgdG8gcHJvdmlkZSBtb3JlIGluZm9ybWF0aW9uIG9uIHRoaXM/DQoNCkJlc3QgUmVnYXJkcw0K
TGkNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWxleGFuZHJ1IFBldHJl
c2N1IFttYWlsdG86YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbV0gDQpTZW50OiBUaHVyc2Rh
eSwgT2N0b2JlciAyMywgMjAxNCAxMjoyOCBBTQ0KVG86IFh1ZWxpOyBUZWQgTGVtb247IFNUQVJL
LCBCQVJCQVJBIEgNCkNjOiBIT01FTkVUIFdvcmtpbmcgR3JvdXA7IG1pZkBpZXRmLm9yZw0KU3Vi
amVjdDogUmU6IKGwSHlicmlkIEFjY2VzcyBmb3IgQnJvYWRiYW5kIE5ldHdvcmtzobEgKFdULTM0
OCkNCg0KSGVsbG8gWHVlbGksDQoNClNldmVyYWwgcGVvcGxlIGxvb2sgYXQgdGhpcyBwcm9ibGVt
IGFzIGFuIElQIHByb2JsZW0uICBJbnN0ZWFkIG9mIGNvbnNpZGVyaW5nIGEgY2VsbHVsYXIrZHNs
IGNvbWJpbmF0aW9uIGluIGEgaG9tZWJveCwgdGhleSBjb25zaWRlcmVkIA0KY2VsbHVsYXIrd2lm
aSBvbiBhIHNtYXJ0cGhvbmUuICAgQnV0IHRoZSBnb2FsIHdhcyB0aGUgc2FtZTogYXVnbWVudCB0
aGUgDQpiYW5kd2lkdGggcGVyY2VpdmVkIGJ5IHRoZSBlbmQgdXNlci4NCg0KSW4gaW1wbGVtZW50
YXRpb24gaXQgaXMgaG93ZXZlciBxdWl0ZSBjaGFsbGVuZ2luZy4gIFRoZSBtb3JlIHRlbXB0aW5n
IHRoZSBleHBlY3RhdGlvbnMgb2YgYXVnbWVudGluZyBiYW5kd2lkdGggYnkgc2ltcGx5IGFkZGlu
ZyBuZXR3b3JrIGludGVyZmFjZXMgKGFzIGluIGFkZGluZyBSQU0gdG8gYSBidXN5IGNvbXB1dGVy
KSwgdGhlIGhpZ2hlciB0aGUgZGVzaWxsdXNpb24gd2hlbiBmYWNpbmcgdGhlIGNoYWxsZW5nZXMg
b2YgaW1wbGVtZW50YXRpb24uDQoNClNvbWUgY29uc2lkZXIgaXQgc2ltcGx5IGFzIGEgbG9jYWwg
Y29tcHV0ZXIgcG9saWN5IHByb2JsZW0gKGFuZCBoZW5jZSBubyBuZXcgY29tbXVuaWNhaXRvbiBz
dGFuZGFyZHMgbmVlZGVkKSwgYnV0IG90aGVycyBjb25zaWRlciB0aGF0IHRoZXJlIGlzIGEgbmVl
ZCBvZiBhIHNlcnZlciBpbiB0aGUgaW5mcmFzdHJ1Y3R1cmUgdG8gd2hpY2ggdGhlc2UgaW50ZXJm
YWNlcyB3b3VsZCBmaXJzdCBjb25uZWN0IChhIHNvcnQgb2YgYW4gJ2FuY2hvcicpLg0KDQpJZiBz
dWNoIGEgdGVjaG5vbG9neSBpcyBkZXZlbG9wcGVkLCBpdCB3aWxsIHN1cmVseSBiZSB1c2VmdWwg
Zm9yIG1vcmUgdGhhbiBob21lbmV0cyAtIGl0IHdpbGwgYmUgdXNlZnVsIGZvciBtdWx0aS1pbnRl
cmZhY2VkIHNtYXJ0cGhvbmVzLCB1c2VmdWwgZm9yIG1vYmlsZSByb3V0ZXJzIGluc3RhbGxlZCBp
biB2ZWhpY2xlcywgYW5kIG1vcmUgdGhhdCBJIGNhbiBub3QgdGhpbmsgb2YuDQoNCkFsZXgNClBT
OiB0aGVyZSBhcmUgYSBmZXcgSUVURiBJbnRlcm5ldCBEcmFmdHMgYWJvdXQgaG93IHdvdWxkIHNt
YXJ0cGhvbmVzIHdvdWxkIHVzZSB0aGlzLCB3aXRoIE1vYmlsZSBJUHY0IGFuZCBNb2JpbGUgSVB2
NiBleHRlbnNpb25zLCBidXQgdGhlcmUgYXJlIG5vIHdpZGVzcHJlYWQgaW1wbGVtZW50YXRpb25z
Lg0KDQpMZSAyMi8xMC8yMDE0IDExOjQ4LCBYdWVsaSBhIKimY3JpdCA6DQo+IEhlbGxvDQo+DQo+
IFRoYW5rcyBCYXJiYXJhIHRvIHNlbmQgdGhpcyBsaWFpc29uIG91dC4NCj4NCj4gSHlicmlkIEFj
Y2VzcyBuZXR3b3JrIGlzIHRoYXQgUmVzaWRlbnRpYWwgZ2F0ZXdheSAoUkcsIG9yIENQRSkgaXMg
DQo+IGV4dGVuZGVkIHdpdGggbW9yZSB0aGFuIHR3byBhY2Nlc3MgbGluZXMNCj4NCj4gKGUuZy4g
RFNMICsgTFRFKSBpbiBvcmRlciB0byBwcm92aWRlIGhpZ2hlciBiYW5kd2lkdGggZm9yIHRoZSAN
Cj4gY3VzdG9tZXJzLiBUaGUgc2NlbmFyaW8gYW5kIGFyY2hpdGVjdHVyZSBhcmUgc2hvd24gYXMg
Zm9sbG93cw0KPg0KPiBjaWQ6aW1hZ2UwMDIuanBnQDAxQ0Y5QTA3LkJGOENENDgwDQo+DQo+IFJp
Z2h0IG5vdywgd2UgaGF2ZSB0d28gaW5kaXZpZHVhbCBkcmFmdHMsIG9uZSBmb3IgYXJjaGl0ZWN0
dXJlIGFuZCANCj4gcmVxdWlyZW1lbnRzLCBhbmQgdGhlIG90aGVyIG9uZSBpcyBmb3IgYW4gb3B0
aW9uYWwgc29sdXRpb24uDQo+DQo+IFRoZSBkcmFmdA0KPiAoaHR0cDovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvZHJhZnQtbGh3eHotaHlicmlkLWFjY2Vzcy1uZXR3b3JrLWFyY2hpdGVjDQo+IHR1cmUt
MDAgIDsgKSBwcm9wb3NlcyB0aGUgYXJjaGl0ZWN0dXJlIGFuZCBnYXAgYW5hbHlzaXMuDQo+DQo+
IFRoZSBzb2x1dGlvbiBkcmFmdCBwcm9wb3NlcyBvbmUgb3B0aW9uIGZvciB0aGUgc29sdXRpb25z
LCANCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGVpbGV5bGktZ3JlLW5vdGlm
aWNhdGlvbnMtMDANCj4NCj4gV2UgZGlkIG5vdCBjb21iaW5lIHRoZW0gYXMgb25lIGRyYWZ0LCBi
ZWNhdXNlIHdlIGJlbGlldmUgdGhlcmUgbWF5IGJlICANCj4gb3RoZXIgY2FuZGlkYXRlcywgYW5k
IHdlIHdvdWxkIGxpa2UgdG8gaGF2ZSBmdXJ0aGVyIGRpc2N1c3Npb25zIGluIHRoZSANCj4gcmVs
YXRlZCBncm91cHMgYW5kIElFVEYuDQo+DQo+IFdlIHVzZWQgdG8gcHJlc2VudCBpdCBpbiBIb21l
bmV0IGluIFRvcm9udG8uDQo+DQo+IE5vdyB0aGUgYXV0aG9ycyBoYXZlIGludml0ZWQgT3Jhbmdl
IHRvIGpvaW4gdGhpcyBhcmNoaXRlY3R1cmUgd29yay4NCj4gV2Ugd2lsbCBzZW5kIG91dCB0aGUg
bmV3IHZlcnNpb24gb2YgdGhlc2UgZHJhZnRzIHNvb24uDQo+DQo+IFdlIGFyZSBnbGFkIHRvIGlu
dml0ZSB0aGUgZXhwZXJ0cyBmb3IgY29tbWVudHMuDQo+DQo+IEJlc3QgUmVnYXJkcw0KPg0KPiBM
aSBYdWUgb24gdGhlIGNvLWF1dGhvcnMgYmVoYWxmDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQo+DQo+IEZyb206IGhvbWVuZXQgW21haWx0bzpob21lbmV0LWJvdW5jZXNAaWV0Zi5v
cmddIE9uIEJlaGFsZiBPZiBUZWQgTGVtb24NCj4NCj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVy
IDIyLCAyMDE0IDM6MDUgQU0NCj4NCj4gVG86IFNUQVJLLCBCQVJCQVJBIEgNCj4NCj4gQ2M6IEhP
TUVORVQgV29ya2luZyBHcm91cA0KPg0KPiBTdWJqZWN0OiBSZTogW2hvbWVuZXRdIEZ3ZDogTmV3
IExpYWlzb24gU3RhdGVtZW50LCAiQnJvYWRiYW5kIEZvcnVtIA0KPiBXb3JrIG9uIKGwSHlicmlk
IEFjY2VzcyBmb3IgQnJvYWRiYW5kIE5ldHdvcmtzobEoV1QtMzQ4KSINCj4NCj4gT24gT2N0IDIx
LCAyMDE0LCBhdCAyOjU1IFBNLCBTVEFSSywgQkFSQkFSQSBIIDxiczc2NTJAYXR0LmNvbT4NCj4g
d3JvdGU6DQo+DQo+PiBGWUkuIEkgbWFkZSBzdXJlIHRoZXkgd2VyZSBhd2FyZSBvZiBJRVRGIG1p
ZiBhbmQgaG9tZW5ldCBhY3Rpdml0aWVzIA0KPj4gaW4gdGhpcyBhcmVhLiBJIGludGVuZCB0byB0
cnkgdG8gcHJldmVudCBoYXZpbmcgdG8gdHJhY2sgZWZmb3J0cyB0aGF0IA0KPj4gdHJ5IHRvIGRv
IHRoZSBzYW1lIHRoaW5nIGluIHR3byBkaWZmZXJlbnQgd2F5cy4gQnV0IHNvbWUgb2YgdGhlIEJC
RiANCj4+IGVmZm9ydCAgbWF5IGJlIGZvY3VzZWQgb24gd2hhdCBjYW4gYmUgZG9uZSBhcm91bmQg
ImJvbmRpbmciDQo+PiBvZiBtdWx0aXBsZQ0KPiBpbnRlcmZhY2VzIHRoYXQgYXJlIHVuZGVyIHRo
ZSBjb250cm9sIG9mIGEgc2luZ2xlIHNlcnZpY2UgcHJvdmlkZXIuIEkgIA0KPiBkb24ndCBzZWUg
dGhpcyBpbiBtaWYgb3IgaG9tZW5ldC4NCj4NCj4gVGhhbmtzLiAgIEkgY291bGRuJ3QgcmVhbGx5
IHRlbGwgd2hhdCB3YXMgYmVpbmcgcHJvcG9zZWQgZnJvbSB0aGUNCj4gTGlhaXNvbiBzdGF0ZW1l
bnQsIHNvIHRoaXMgaW5mb3JtYXRpb24gaXMgaGVscGZ1bC4NCj4NCj4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4NCj4gaG9tZW5ldCBtYWlsaW5nIGxp
c3QNCj4NCj4gaG9tZW5ldEBpZXRmLm9yZw0KPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2hvbWVuZXQNCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18gaG9tZW5ldCBtYWlsaW5nIGxpc3QgDQo+IGhvbWVuZXRA
aWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ob21lbmV0DQo+
DQoNCg==


From nobody Tue Oct 28 01:35:01 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27301A1A17 for ; Tue, 28 Oct 2014 01:34:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4m7QwvmCjZlH for ; Tue, 28 Oct 2014 01:34:20 -0700 (PDT)
Received: from zimbra.powertech.no (zimbra-out.powertech.no [195.159.42.152]) by ietfa.amsl.com (Postfix) with ESMTP id 569601A00AE for ; Tue, 28 Oct 2014 01:34:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by zimbra.powertech.no (Postfix) with ESMTP id 398AF4800F8; Tue, 28 Oct 2014 09:34:18 +0100 (CET)
Received: from zimbra.powertech.no ([127.0.0.1]) by localhost (zimbra.powertech.no [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id qb3SP62PKXO7; Tue, 28 Oct 2014 09:34:14 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by zimbra.powertech.no (Postfix) with ESMTP id B413C480651; Tue, 28 Oct 2014 09:34:14 +0100 (CET)
X-Virus-Scanned: amavisd-new at zimbra.powertech.no
Received: from zimbra.powertech.no ([127.0.0.1]) by localhost (zimbra.powertech.no [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uOniTFNCpJWx; Tue, 28 Oct 2014 09:34:14 +0100 (CET)
Received: from zimbra.powertech.no (zimbra.powertech.no [195.159.198.162]) by zimbra.powertech.no (Postfix) with ESMTP id 8691F4800F8; Tue, 28 Oct 2014 09:34:14 +0100 (CET)
Date: Tue, 28 Oct 2014 09:34:14 +0100 (CET)
From: Ola Thoresen 
To: Michael Kloberdans 
Message-ID: <1182988227.3238794.1414485254200.JavaMail.zimbra@zimbra.powertech.no>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [195.159.6.21]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - GC38 (Linux)/8.0.6_GA_5922)
Thread-Topic: [homenet] Comments requested for draft CER-ID
Thread-Index: AQHP8f8ABnMT2tvAoEOB5hY9+dInumzdql7H
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/LdEjAPwVKB5IZ7FUS621BKIJZpk
Cc: homenet@ietf.org
Subject: Re: [homenet] Comments requested for draft CER-ID
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 08:34:23 -0000

If all other local routers will disable their firewalls just because they r=
eceive a single packet with a flag set (and we're not only talking UPnP whi=
ch should only open a subset of ports to a subset of addresses), I would be=
 concerned.  If re-used router that had been previously set up as a CER, an=
d plugged it in - maybe as a kind of WIFI-extender or whatever - and it sta=
rted to disable the firewalls on pother routers in my network (IE. between =
my Guest WIFI and my Home Automation network) it would obviously be a secur=
ity issue. =20

Also, it would be a trivial task to create a virus/trojan that could spoof =
these packets, and start exploring internal networks that the box at hand s=
hould not have access to.
With more and more embedded devices showing up - with a questionable track =
record for firmware/software updates - I think we should be really careful =
with this kind of automatic downgrade of local security.

There are plenty of reasons to run firewalls and filters on other routers t=
han the edge-router(s).


/Ola Thoresen



----- Opprinnelig melding -----
> Fra: "Michael Kloberdans" 
> Til: "Ola Thoresen" , homenet@ietf.org
> Sendt: 27. oktober 2014 16:59:34
> Emne: Re: [homenet] Comments requested for draft CER-ID
>=20
> Ola,
> I=C2=B9d like to better understand your comment about a misconfigured rou=
ter
> being a security issue.
>=20
> In the eRouter implementation, the CER is automatically determined.  The
> only way a router would be misconfigured is if the home owner or someone
> else with local access manually changes the CER.  Perhaps I=C2=B9m missin=
g
> something. Please expound - I=C2=B9m grateful for all comments.
>=20
> Regards,
>=20
>=20
> Michael Kloberdans
> Lead Architect / Home Networking     CableLabs=C2=AE
>=20
> 858 Coal Creek Circle.  Louisville, CO. 80027
> 303-661-3813 (v)
>=20
>=20
>=20
>=20
> On 10/27/14, 9:00 AM, "Ola Thoresen"  wrote:
>=20
> >> On 27.10.2014, at 16.17, Michael Kloberdans 
> >> wrote:
> >> > All home routers should know their role; CER or IR.  The status of C=
ER
> >> > places the burden of providing the firewall and NAPT as it was
> >>determined
> >> > to be the edge router.  The interior routers need to understand thei=
r
> >>role
> >> > and disable their firewall and NAPT abilities.  This is why the
> >>CER-ID is
> >> > a numeric value (indicating CER status) or a double colon (indicatin=
g
> >>IR
> >> > status).
> >>=20
> >> I agree with that. However, I disagree with how you are doing it.
> >>=20
> >> > In the case of the eRouter (combined cable modem and
> >> > router/switch/wireless), it performs a /48 check between the IA_NA
> >>and the
> >> > IA_PD ranges.  If the ISP sends a double colon or null in the CER-ID
> >>ORO,
> >> > AND if the IA_NA is in a different /48 than the given IA_PD, the
> >>eRouter
> >> > becomes the CER.  It must now declare to the IRs that it is the CER.
> >>A
> >> > directly connected IR will see the CER value in the ORO and, in the
> >> > absence of another controlling protocol, disable its firewall and NA=
PT
> >> > functions.
> >>=20
> >> Why cannot it determine it is CER by bits coming from particular type =
of
> >> plug? Cable modem plug looks different from ethernet/wireless? It woul=
d
> >>be
> >> much more secure that way.
> >>=20
> >
> >
> >But that would not work if the router only has ethernet-ports - which is
> >probably the case if the customer has various kinds of FTTH (many of
> >these will use Fast/Gig-ethernet over copper for the last meters in to
> >the CPE).
> >
> >However I do agree that the suggested solution seems sub optimal.  It is
> >way to easy for a misconfigured router to disable all local security (IE=
.
> >turning off firewalling) without the network owners knowledge.
> >
> >/Ola (T)
> >
> >_______________________________________________
> >homenet mailing list
> >homenet@ietf.org
> >https://www.ietf.org/mailman/listinfo/homenet
>=20
>=20

--=20
Ola Thoresen                                        Tlf.: 23 01 00 00
PowerTech Drift                                     Dir.: 23 01 00 47
                                                    Mob.: 92 09 04 30=20


From nobody Tue Oct 28 01:40:58 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F411A1A2F for ; Tue, 28 Oct 2014 01:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JC-GBoGb4mYF for ; Tue, 28 Oct 2014 01:40:20 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id E985C1A1A65 for ; Tue, 28 Oct 2014 01:40:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id F14BD871612; Tue, 28 Oct 2014 09:40:18 +0100 (CET)
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0eJI0L9buvq; Tue, 28 Oct 2014 09:40:18 +0100 (CET)
Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 5F6EF871611; Tue, 28 Oct 2014 09:40:18 +0100 (CET)
Message-ID: <544F5647.4080100@globis.net>
Date: Tue, 28 Oct 2014 09:39:35 +0100
From: Ray Hunter 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: David R Oran 
References:  
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/J875t12WCF9R2M_ALAWFBe8_gmQ
Cc: "homenet@ietf.org" , Ola Thoresen , Michael Kloberdans 
Subject: Re: [homenet] Comments requested for draft CER-ID
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 08:40:22 -0000

David R Oran wrote:
> Silly question:
>
> Isn’t the border defined by a link and not a router? What if you have uplinks to two different ISPs on the same router?
> This seems to assume there’s only one border link on a router, and that router connects to only one external entity.

Indeed.

The draft states

 >If the device has more than one LAN interface,
 >it SHOULD use the lowest Globally Unique address not assigned to 
itsWAN interface.

That would seem to me to suggest that this draft is targeted at an RFC 
7084 router.

RFC7368 (The Homenet Architecture) is explicit in section 3.2.2.3 that 
dual ISP links on one single CER are supported.

So what happens if one ISP states in a CER-ID reply that this DHCPv6 
client router is the CER, and another ISP states via the same CER-ID 
mechanism, responding from a different DHCPv6 server, that this router 
is not the CER?

I therefore think all DHCPv6 based management mechanisms are pretty much 
doomed to failure, unless they can explicitly resolve conflicting 
configuration information.

> On Oct 27, 2014, at 8:59 AM, Michael Kloberdans  wrote:
>
>> Ola,
>> Iąd like to better understand your comment about a misconfigured router
>> being a security issue.
>>
>> In the eRouter implementation, the CER is automatically determined.  The
>> only way a router would be misconfigured is if the home owner or someone
>> else with local access manually changes the CER.  Perhaps Iąm missing
>> something. Please expound - Iąm grateful for all comments.
>>
>> Regards,
>>
>>
>> Michael Kloberdans
>> Lead Architect / Home Networking     CableLabs®
>>
>> 858 Coal Creek Circle.  Louisville, CO. 80027
>> 303-661-3813 (v)
>>
>>
>>
>>
>> On 10/27/14, 9:00 AM, "Ola Thoresen"  wrote:
>>
>>>> On 27.10.2014, at 16.17, Michael Kloberdans
>>>> wrote:
>>>>> All home routers should know their role; CER or IR.  The status of CER
>>>>> places the burden of providing the firewall and NAPT as it was
>>>> determined
>>>>> to be the edge router.  The interior routers need to understand their
>>>> role
>>>>> and disable their firewall and NAPT abilities.  This is why the
>>>> CER-ID is
>>>>> a numeric value (indicating CER status) or a double colon (indicating
>>>> IR
>>>>> status).
>>>> I agree with that. However, I disagree with how you are doing it.
>>>>
>>>>> In the case of the eRouter (combined cable modem and
>>>>> router/switch/wireless), it performs a /48 check between the IA_NA
>>>> and the
>>>>> IA_PD ranges.  If the ISP sends a double colon or null in the CER-ID
>>>> ORO,
>>>>> AND if the IA_NA is in a different /48 than the given IA_PD, the
>>>> eRouter
>>>>> becomes the CER.  It must now declare to the IRs that it is the CER.
>>>> A
>>>>> directly connected IR will see the CER value in the ORO and, in the
>>>>> absence of another controlling protocol, disable its firewall and NAPT
>>>>> functions.
>>>> Why cannot it determine it is CER by bits coming from particular type of
>>>> plug? Cable modem plug looks different from ethernet/wireless? It would
>>>> be
>>>> much more secure that way.
>>>>
>>> But that would not work if the router only has ethernet-ports - which is
>>> probably the case if the customer has various kinds of FTTH (many of
>>> these will use Fast/Gig-ethernet over copper for the last meters in to
>>> the CPE).
>>>
>>> However I do agree that the suggested solution seems sub optimal.  It is
>>> way to easy for a misconfigured router to disable all local security (IE.
>>> turning off firewalling) without the network owners knowledge.
>>>
>>> /Ola (T)
>>>
>>> _______________________________________________
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>
>

-- 
Regards,
RayH


From nobody Tue Oct 28 06:07:23 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5625A1A6FAA; Tue, 28 Oct 2014 06:06:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sl9nvQMLG3Ze; Tue, 28 Oct 2014 06:06:35 -0700 (PDT)
Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D78C1A6FE7; Tue, 28 Oct 2014 06:06:35 -0700 (PDT)
Received: from [192.168.10.30] (cm-84.215.22.20.getinternet.no [84.215.22.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 6087B628B; Tue, 28 Oct 2014 06:06:33 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Ole Troan 
In-Reply-To: 
Date: Tue, 28 Oct 2014 14:06:26 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20141020204033.GD236844@jupiter.n2.diac24.net> <20141022190653.GB868521@jupiter.n2.diac24.net> 
To: "Fred Baker (fred)" 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/fsL_TAzcY9aUk-cHnhOB8TZBO-w
Cc: "homenet@ietf.org" , Mikael Abrahamsson , "rtgwg@ietf.org" , David Lamparter 
Subject: Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 13:06:39 -0000

Fred,

>>> =
https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-routing-extra-quali=
fiers/?include_text=3D1
>>> =
https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-dst-src-routing/?in=
clude_text=3D1
>=20
> Speaking strictly for myself, I=92m not sure why homenet is relevant. =
The technology is related to networks that have different routing depend =
on on one=92s use case. A class of solutions for it has been called the =
=93fish=94 problem, and built using multi-topology routing. In homenet, =
it=92s called SADR, and is primarily about egress routing (routing to an =
egress to an upstream ISP that gave you a PA prefix). While one doesn=92t =
really want to confuse theory with practice, in theory it could be used =
between points of a network, to prevent folks using one set of prefixes =
to talk with another set, or to force routing of some sessions in some =
ways.
>=20
> Personally, those are a class of problems I associate with campus =
networks more than residential networks.

why homenet is relevant?
isn't multi-prefix multi-homing one of the most obvious use cases for =
source address dependent routing? that's not restricted with homenets, =
but also any small network. I'm assuming large networks will continue =
with PI addresses and BGP based multihoming.

cheers,
Ole=


From nobody Tue Oct 28 06:19:05 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1001B1A6EEC for ; Tue, 28 Oct 2014 06:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level: 
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJerxXHk2M48 for ; Tue, 28 Oct 2014 06:18:53 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70EA11A877F for ; Tue, 28 Oct 2014 06:18:05 -0700 (PDT)
X-Original-To: homenet@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 77C51602FF for ; Tue, 28 Oct 2014 14:18:03 +0100 (CET)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 3912560141 for ; Tue, 28 Oct 2014 14:18:03 +0100 (CET)
Received: (qmail 23745 invoked by uid 1007); 28 Oct 2014 14:18:03 +0100
Date: Tue, 28 Oct 2014 14:18:03 +0100
From: Gert Doering 
To: Ole Troan 
Message-ID: <20141028131803.GN31092@Space.Net>
References: <20141020204033.GD236844@jupiter.n2.diac24.net> <20141022190653.GB868521@jupiter.n2.diac24.net>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/nsjffeMrGFsKh5VUkb5jRleBF4I
Cc: David Lamparter , "homenet@ietf.org" , "rtgwg@ietf.org" , "Fred Baker \(fred\)" , Mikael Abrahamsson 
Subject: Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 13:19:00 -0000

Hi,

On Tue, Oct 28, 2014 at 02:06:26PM +0100, Ole Troan wrote:
> isn't multi-prefix multi-homing one of the most obvious use cases
> for source address dependent routing? that's not restricted with
> homenets, but also any small network. I'm assuming large networks
> will continue with PI addresses and BGP based multihoming.

I see the distinction somewhere in the "what defines policy in a network",
as in:

 - in a "big" company network, there usually is some sort of network access
   policy, which is defined and enforced by the network people - so you'll
   see BGP policies and PI, or in a "dual /48" style shop, I expect to see
   dual-NPT66-with-ULA devices where you can configure your policy ("surfing
   goes out via ISP A, mail goes out via ISP B") in the network device

 - in a homenet, small company ("barber shop") network, there is no "admin",
   and to try to enforce network policy ("surfing via cable, bittorrent via
   DSL") in the network device is futile, because "no admin".  So here you
   need SADR to empower the end device - and by that means, the user - to
   define policy.  Have the bittorrent client use the source address from
   the DSL ISP's /48, the web browser use the source address from the 
   Cable ISP, and things work the way the user wants it.

   ... and this is why I really really like dual-/48 multihoming for the
   "not really managed" SOHO case, as it puts policy decisions where they
   can be made (= user's device) - and of course, why dual-/48 is not going
   to fly for enterprise networks (= can't have the user decide that).


(In case this wasn't obvious, I'm agreeing with Ole here, I just try to
shed light from a slightly different angle on that.)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279


From nobody Tue Oct 28 12:37:18 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AAA1A6F99 for ; Tue, 28 Oct 2014 12:37:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adjc509jWu46 for ; Tue, 28 Oct 2014 12:37:13 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA541AC43A for ; Tue, 28 Oct 2014 12:37:13 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CC9A9203AA; Tue, 28 Oct 2014 15:38:27 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 1A3C363A84; Tue, 28 Oct 2014 15:37:12 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 02E4A63A21; Tue, 28 Oct 2014 15:37:12 -0400 (EDT)
From: Michael Richardson 
To: Michael Kloberdans 
In-Reply-To: 
References:   
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/987eKlSwbChqTwfyBTbsjInfqt4
Cc: "homenet@ietf.org" , Markus Stenberg 
Subject: Re: [homenet] Comments requested for draft CER-ID
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 19:37:17 -0000

--=-=-=


Michael Kloberdans  wrote:
    > All home routers should know their role; CER or IR.  The status of CER

80% of the innovation of the Homenet working group is really to find a way to
avoid having to *tell* the routers this role.  Yes, they wind up deriving it,
and I agree that it's useful for the routers to emit their conclusion in
the form of CER-ID.

> The status of CER places the burden of providing the firewall and NAPT as
> it was determined to be the edge router.  The interior routers need to
> understand their role and disable their firewall and NAPT abilities.  This
> is why the CER-ID is a numeric value (indicating CER status) or a double
> colon (indicating IR status).

I think that your document needs a 2-3 page explanation of reasons why
an router should believe the CER-ID it says.  It's a very clear attack vector
on a home router if you can get it to turn off it's firewall.

I don't think your security considerations is adequate; you likely did not
understand Markus' reference to the "evil bit", which a Steve Bellovin April
1 "RFC": rfc3514.txt.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBVE/wZ4CLcPvd0N1lAQJT6gf9GoyM8fn+4Y5mK64AMfej8yuCxW/Y+4io
gfVtEGrQi8T9jsegmf+gUajPkK5024g5leS2ifYcjBdtbIZrcXL4xcqCwklga6WH
JeulB/vtu1MBpuduF+NGNzqkzlBnXZWC1fiKK+YkNLVv7h7jNm7fcXOwwKwobc40
5Vt1XMwG89vFd3e+uzeLI8PZVWFMim4j3qN/GyZ4kIvz5IFySQysoeLfqvj6YmOy
lkm2O0bvLXoJieZiD3eU9ojC5NA2DkePAjRNpmYR3RnxfVm5fWcdsJl8cEaRIQCh
AeedxA0c6GCYeSMblnHdSEaMaL4nKLzIkuu9ueLQ6ZhyGh8RvzZsEg==
=HNGT
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Tue Oct 28 12:46:22 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B181C1ACD15; Tue, 28 Oct 2014 12:46:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.231
X-Spam-Level: 
X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAi2iNnTv83o; Tue, 28 Oct 2014 12:46:18 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102D81ACD04; Tue, 28 Oct 2014 12:46:14 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s9SJjuj4031557; Tue, 28 Oct 2014 19:45:56 GMT
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s9SJjuj4031557
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1414525556; bh=E4WStCiA8bKeYuGZOU8JfD2/qjI=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=bxZteXgXnwDLVnGhyXqsCoLd4Ixqt5IIlxx14DYKB5ZxSUP8Xe3fC2C52x9qJphIZ +tnO4ADM9rLePEGTD9LbtXa0irk1N/a9/wHbX/UQD7gFuyWM+PC3jnMkfGhnL+AnjA pPQBdvhCp1Ov+ZtjUvUKzsTBHzivF4nzcN++vAts=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from  with ESMTP (valid=N/A) id q9RJju07631119375H ret-id none; Tue, 28 Oct 2014 19:45:56 +0000
Received: from [192.168.1.108] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s9SJik0r023263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Oct 2014 19:44:47 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_A299BC16-851D-4B16-8D3E-E5873F004D4E"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Tim Chown 
In-Reply-To: 
Date: Tue, 28 Oct 2014 19:44:45 +0000
Message-ID: 
References: <20141020204033.GD236844@jupiter.n2.diac24.net> <20141022190653.GB868521@jupiter.n2.diac24.net>  <5C2EFB4E-925B-4252-BE58-894F9C061EA7@ecs.soton.ac.uk>
To: "Fred Baker (fred)" 
X-Mailer: Apple Mail (2.1878.6)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=q9RJju076311193700; tid=q9RJju07631119375H; client=relay,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: s9SJjuj4031557
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/zA49roa70Qj_HtYEdorkl3m5IjY
Cc: "homenet@ietf.org" , Mikael Abrahamsson , "rtgwg@ietf.org" , David Lamparter 
Subject: Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 19:46:20 -0000

--Apple-Mail=_A299BC16-851D-4B16-8D3E-E5873F004D4E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

On 22 Oct 2014, at 21:16, Fred Baker (fred)  wrote:

> On Oct 22, 2014, at 12:06 PM, David Lamparter  =
wrote:
>=20
>> On Mon, Oct 20, 2014 at 10:40:33PM +0200, David Lamparter wrote:
>>> =
https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-routing-extra-quali=
fiers/?include_text=3D1
>>> =
https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-dst-src-routing/?in=
clude_text=3D1
>=20
> Speaking strictly for myself, I=92m not sure why homenet is relevant. =
The technology is related to networks that have different routing depend =
on on one=92s use case. A class of solutions for it has been called the =
=93fish=94 problem, and built using multi-topology routing. In homenet, =
it=92s called SADR, and is primarily about egress routing (routing to an =
egress to an upstream ISP that gave you a PA prefix). While one doesn=92t =
really want to confuse theory with practice, in theory it could be used =
between points of a network, to prevent folks using one set of prefixes =
to talk with another set, or to force routing of some sessions in some =
ways.
>=20
> Personally, those are a class of problems I associate with campus =
networks more than residential networks.

I suspect most campus networks will have a single /48 from their NREN, =
or a /48 PI. I=92m not aware of any campuses in the UK which are =
multi-homed with dual /48, though I understand some Internet2 campuses =
may be.=20

(As an aside we=92ve just run out of our v4 /16=85)

Homenet has =91designed in=92 future multihoming, which is rare today. =
In the homenet case the multihoming may presumably be more commonly for =
different services to the home?

Tim


--Apple-Mail=_A299BC16-851D-4B16-8D3E-E5873F004D4E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJUT/ItAAoJEFoq8u2GfpfeP+8H/RaTDY7Oa7ws9pFVc7XpHMJw
R1mHrNIZ8+hZRhLxEbz5O/Ovm9dKhcE4QwBERZ7RHzPYwZPGdv3gqi5cDU7+m6XJ
F0MYyZddVT+KvZ2Lkt2b9FTPw2lVr0jcdqgkZS/9gHtyVJR78n2lSKcmel0h0qIT
DrZ8hY1DQr8xMdsxORC9FyqG1lfT9QoAWEOTDuV6fNCP+Mm1AigEnyJpaapu6eDm
paJp0HmRceDzB6inerQ91XQuyMGPeVEZA3PhWC9BMYKjt2+8LzYTnCrsg9XqkpAx
0QtW+dz+n+TrNwaIm7sPz+IybV7bOKuOSg/81lxZiMcpsQNAAXFj7rqokDMmJNY=
=QDRq
-----END PGP SIGNATURE-----

--Apple-Mail=_A299BC16-851D-4B16-8D3E-E5873F004D4E--


From nobody Tue Oct 28 12:52:53 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8DA1ACCEC; Tue, 28 Oct 2014 12:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wn_M4E96z6y6; Tue, 28 Oct 2014 12:52:49 -0700 (PDT)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A349A1ACD82; Tue, 28 Oct 2014 12:52:19 -0700 (PDT)
Received: by mail-pa0-f47.google.com with SMTP id kx10so1478772pab.6 for ; Tue, 28 Oct 2014 12:52:19 -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=WG3YzXprql5Q4a8hW0BCIOtV3PiDF958hmSZoT+1af8=; b=sa+upQXhXbWzHDWBEeLNqy25sT/MIOYLa3egRNBkDCdsdgKH4lbsqKqKUtjQcXFunA jl3LSZ6Vpq9t0aD0brvPkq5Wy91GQtK/EuF9jvHd9SdLyYTItQ7ggJOvjUQ2URVAUn7X nU7/2ooqN9B6h2pF0rwCDDfVj/FxqgfZ1yUjrfYzreo1AxKM1HY6EjaaLQ15wFVCF+lk 8IupcRWYspkVg6vi3I9DIUKKHokR7MYcYupI8rz1GENge4EEnn+BPeDlF3gaCHfjwAGZ JQYqKoXjc0VbwpAN+FXw1DQPxuLdXj57MtL/1Nxiy7f7tikdh0VgoFdN59n4GMZmr1KY TR1Q==
X-Received: by 10.68.185.98 with SMTP id fb2mr3885558pbc.142.1414525939381; Tue, 28 Oct 2014 12:52:19 -0700 (PDT)
Received: from [192.168.178.23] (162.194.69.111.dynamic.snap.net.nz. [111.69.194.162]) by mx.google.com with ESMTPSA id zn11sm2396554pab.24.2014.10.28.12.52.15 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Oct 2014 12:52:18 -0700 (PDT)
Message-ID: <544FF3F2.3050206@gmail.com>
Date: Wed, 29 Oct 2014 08:52:18 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ole Troan 
References: <20141020204033.GD236844@jupiter.n2.diac24.net> <20141022190653.GB868521@jupiter.n2.diac24.net>  
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Q6QR7FxPpfOYVTf4B49rJ8Nj5ds
Cc: David Lamparter , "homenet@ietf.org" , "rtgwg@ietf.org" , "Fred Baker \(fred\)" , Mikael Abrahamsson 
Subject: Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 19:52:52 -0000

On 29/10/2014 02:06, Ole Troan wrote:
> Fred,
>=20
>>>> https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-routing-extra=
-qualifiers/?include_text=3D1
>>>> https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-dst-src-routi=
ng/?include_text=3D1
>> Speaking strictly for myself, I=E2=80=99m not sure why homenet is rele=
vant. The technology is related to networks that have different routing d=
epend on on one=E2=80=99s use case. A class of solutions for it has been =
called the =E2=80=9Cfish=E2=80=9D problem, and built using multi-topology=
 routing. In homenet, it=E2=80=99s called SADR, and is primarily about eg=
ress routing (routing to an egress to an upstream ISP that gave you a PA =
prefix). While one doesn=E2=80=99t really want to confuse theory with pra=
ctice, in theory it could be used between points of a network, to prevent=
 folks using one set of prefixes to talk with another set, or to force ro=
uting of some sessions in some ways.
>>
>> Personally, those are a class of problems I associate with campus netw=
orks more than residential networks.
>=20
> why homenet is relevant?
> isn't multi-prefix multi-homing one of the most obvious use cases for s=
ource address dependent routing? that's not restricted with homenets, but=
 also any small network. I'm assuming large networks will continue with P=
I addresses and BGP based multihoming.

If you mean by "large" the few ten thousand largest networks in the
world, that will not cause significant BGP4 bloat by having PI, then
yes, I fully agree. Any medium to small network should expect to have
multiple prefixes in the long run (we are not talking about today, but
a time when all we old folks who remember the IPv4 world have retired
and gone fishing).

   Brian


From nobody Tue Oct 28 13:18:39 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58081ACF60; Tue, 28 Oct 2014 13:18:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.111
X-Spam-Level: 
X-Spam-Status: No, score=-13.111 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05cwI5sXN2Iv; Tue, 28 Oct 2014 13:18:34 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71771ACE37; Tue, 28 Oct 2014 13:13:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2259; q=dns/txt; s=iport; t=1414527232; x=1415736832; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=SpR/8DK9aLeDpIWegRtPZL7TsZqwszH7945gUWTvjqA=; b=QrAaaqQ7JYQEonAun0VKIi2vfx0TUhsvnkDE3BxXlZR46Sqew7BYgXV1 m1DLZS31cenBnI8Hs/e71nfwuqWvJTXLlAvqeEe2c3jOE96yphNKPpaYP iGhGJSWmFyo/QTo6rwJPe5QR9a5f4jNmwKE/6v+yLA8q0A+0KzZLG1gJb E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArAEAF74T1StJssW/2dsb2JhbABcg2JYzkKJCQEBAQEBfYRBLwcKPRYYAwIBAgFLAQwIAQEQB4gmDccuAQEBAQEBBAEBAQEBARgElVsBBJZVhxOBMYNJgnSOSIN5PC8BAQEBgkcBAQE
X-IronPort-AV: E=Sophos;i="5.04,804,1406592000"; d="scan'208";a="224010610"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 28 Oct 2014 20:13:49 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9SKDmaJ019820; Tue, 28 Oct 2014 20:13:48 GMT
Message-ID: <544FF8FC.5090103@cisco.com>
Date: Tue, 28 Oct 2014 21:13:48 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: "anima@ietf.org" , homenet@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/3HWUpywmbpivXAPsV1ZYSoN5yYQ
Subject: [homenet] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 20:18:37 -0000

Dear all,

[sorry for double-posting, but we need the specific feedback from the 
HOMENET community]

1. scope
I finished reading the ANIMA mailing list and, based on the feedback, 
Joel, Ted, and I would like to clarify the ANIMA scope for "the set of 
specific reusable infrastructure components that support autonomic 
interactions between devices" (quoting the charter)

The charter currently mentions:
     The ANIMA working group will initially focus on enterprise, ISP 
networks and IoT.

Multiple tracks were discussed on the mailing list.
     * keep enterprise, ISP networks and IoT
     * focus on enterprise and ISP networks
     * everything, but the initial focus is enterprise and carrier?
     * professionally-managed networks

It seems to us that "professionally-managed networks" is what ANIMA is 
after. And it's potentially a distraction to try to segment the scope 
based on enterprise, ISP, homenet, or IoT. What is IoT after all?

OLD:     The ANIMA working group will initially focus on enterprise, ISP 
networks and IoT.
NEW:    The ANIMA working group focuses on professionally-managed networks.

Does it sound about right?

2. Overlap with HOMENET
This distinction in point 1 might help regarding the potential overlap 
of the solution for distributed IPv6 prefix management.
Btw, the new charter has been adapted:
OLD:  A solution for distributed IPv6 prefix management within a network.
NEW: the solution for distributed IPv6 prefix management within a 
large-scale network

Also, The HOMENET collaboration has been stressed in the charter.

3. Others
I believe I took care of the others changes proposed on the mailing. If 
this is not the case, let me know.
At this point in time, please provide concrete change to the charter 
text if some issues persist.
Charter v15 has just been posted, and you can review the detailed 
changes at 
https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-15.txt


4. Security Advisor.
I have requested one for ANIMA to the security ADs.

Regards, Benoit


From nobody Tue Oct 28 14:25:36 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6531ACF5E; Tue, 28 Oct 2014 14:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9YXbkoVZBQO; Tue, 28 Oct 2014 14:25:28 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12CF71ACF99; Tue, 28 Oct 2014 14:25:28 -0700 (PDT)
Received: by mail-pa0-f51.google.com with SMTP id kq14so1627324pab.24 for ; Tue, 28 Oct 2014 14:25:27 -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=NI5UrGwP5rH8W88a5apfU59E1GeP92gp7LgkvYS5C/Q=; b=OnpOG1GP7zoyUn8QHzlldok3l3ZX7hZIeOKDLk1yCAVwzscqglyNzAS9Z1TboEN44b LWps9nZuaYJ074lPs07Xt/HS4BodVWDgKO1FQ1BmFePbssK04TdVOHC/YA/OLFFZMFJy 4Dm+oJln52Zhi7UuJkzFvMNFJ0Mw61M8ViCLK29WndoPeMS5hJR/8Mmt8yY/T6jL2rLg APOi7fvdhFF9ODoBfRHIfakQ2lV2r8HH6T99ok0sgcpalNFMX0u+48pNJw/YB+u35eK/ XJsxWBGUiAMpmu1d1SEbMjLbXRICTy7+q8yOVxcVZGENHTFsxGKPDh3ezm1Cdhy6suxU 2Smg==
X-Received: by 10.68.235.103 with SMTP id ul7mr6093046pbc.63.1414531527781; Tue, 28 Oct 2014 14:25:27 -0700 (PDT)
Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id gz1sm2494820pbb.8.2014.10.28.14.25.24 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Oct 2014 14:25:26 -0700 (PDT)
Message-ID: <545009C7.3010103@gmail.com>
Date: Wed, 29 Oct 2014 10:25:27 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Benoit Claise 
References: <544FF8FC.5090103@cisco.com>
In-Reply-To: <544FF8FC.5090103@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/clR4lvuU0c2332fbFd5PMoMpCn0
Cc: homenet@ietf.org, "anima@ietf.org" 
Subject: Re: [homenet] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 21:25:31 -0000

On 29/10/2014 09:13, Benoit Claise wrote:
> Dear all,
> 
> [sorry for double-posting, but we need the specific feedback from the
> HOMENET community]
> 
> 1. scope
> I finished reading the ANIMA mailing list and, based on the feedback,
> Joel, Ted, and I would like to clarify the ANIMA scope for "the set of
> specific reusable infrastructure components that support autonomic
> interactions between devices" (quoting the charter)
> 
> The charter currently mentions:
>     The ANIMA working group will initially focus on enterprise, ISP
> networks and IoT.
> 
> Multiple tracks were discussed on the mailing list.
>     * keep enterprise, ISP networks and IoT
>     * focus on enterprise and ISP networks
>     * everything, but the initial focus is enterprise and carrier?
>     * professionally-managed networks
> 
> It seems to us that "professionally-managed networks" is what ANIMA is
> after. And it's potentially a distraction to try to segment the scope
> based on enterprise, ISP, homenet, or IoT. What is IoT after all?
> 
> OLD:     The ANIMA working group will initially focus on enterprise, ISP
> networks and IoT.
> NEW:    The ANIMA working group focuses on professionally-managed networks.
> 
> Does it sound about right?

Personal opinion: Yes. We should of course seek to make everything we
do as general as possible, so that there are no artificial limits
to its use if successful.

    Brian

> 
> 2. Overlap with HOMENET
> This distinction in point 1 might help regarding the potential overlap
> of the solution for distributed IPv6 prefix management.
> Btw, the new charter has been adapted:
> OLD:  A solution for distributed IPv6 prefix management within a network.
> NEW: the solution for distributed IPv6 prefix management within a
> large-scale network
> 
> Also, The HOMENET collaboration has been stressed in the charter.
> 
> 3. Others
> I believe I took care of the others changes proposed on the mailing. If
> this is not the case, let me know.
> At this point in time, please provide concrete change to the charter
> text if some issues persist.
> Charter v15 has just been posted, and you can review the detailed
> changes at
> https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-15.txt
> 
> 
> 
> 4. Security Advisor.
> I have requested one for ANIMA to the security ADs.
> 
> Regards, Benoit
> 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


From nobody Tue Oct 28 14:37:34 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BEE1AD065; Tue, 28 Oct 2014 14:37:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-TFFlfFARHO; Tue, 28 Oct 2014 14:37:26 -0700 (PDT)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857C71AD064; Tue, 28 Oct 2014 14:37:26 -0700 (PDT)
Received: by mail-ig0-f179.google.com with SMTP id r10so1950099igi.12 for ; Tue, 28 Oct 2014 14:37:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=KxD74K2l6uyn9MWjz9jfdqVzojZMuXNYNlltEFrZ3Uc=; b=dMJTtaCWc6sUs9YywkYJBzotQbjhf9g8nUj0k3uAe059+IzeW9prYarxt/yIhTfQ4B dj77NdahHtDQWga9VyAFTxjzWRoRZWVzYz4cGFxEQUmQIQ+EthsS86+0XlcT/Gnv5K0b iVxRa64ZvuwrImzWu5tfUfNMWnFp8ch86j6Wzdj3LSWyBUawbQaMiDeKwEq8/ROYgBFP zUPJT0IG0m0vNUPwLHvgyCY1lF86YGuYZsDMmckB1oG3zTfz1Iw3qTn5Y04qBVSW+mgU yqr1Mi/CD7ZlCpv4H2bXWc91ooqIeyCBWAwrP347g9qxPnu8vVYhlEfjDIBt2Ec//Yfq Ld0A==
X-Received: by 10.42.167.1 with SMTP id q1mr6563198icy.48.1414532244776; Tue, 28 Oct 2014 14:37:24 -0700 (PDT)
Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id x9sm6931656igl.10.2014.10.28.14.37.23 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Oct 2014 14:37:24 -0700 (PDT)
Message-ID: <54500C8F.5030104@gmail.com>
Date: Tue, 28 Oct 2014 17:37:19 -0400
From: Rene Struik 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Benoit Claise , "anima@ietf.org" ,  homenet 
References: <544FF8FC.5090103@cisco.com>
In-Reply-To: <544FF8FC.5090103@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/tJ2DBOe_7En8I9HBTkHLEAULvRI
Subject: Re: [homenet] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 21:37:29 -0000

Hi Benoit:

-1 on you suggestion #1.

I do not think suggesting "constrained networks and devices" to be 
suddenly out of scope helps: it is one of the main areas where 
semi-automatic management is imperative. If one has a bootstrapping 
solution and configuration negotiation/synchronization protocol that is 
not useful in constrained settings, what is the point? In my mind, it 
seems much more prudent to design schemes with constrained networks and 
devices and failure recovery models that apply there (configuration 
mismatch due to sleepy devices, malfunctioning data store, etc.), where 
these would then obviously also fit the less constrained, 
"professionally managed" networks. Design for the"nimble", so that both 
"nimble" and "fatter" networks can use this.

This also has the advantage that one is forced to think in terms of many 
potential actors, rather than a few ones, which helps in viewing 
solutions in terms of heterogeneous rather than homogeneous deployment 
models.

I have done all my reviews of nmrg drafts 
(http://www.ietf.org/mail-archive/web/anima/current/msg00327.html) with 
constrained networks and devices in mind. It would be a shame if one 
would now narrow down the focus and rule this (future almost ubiquitous) 
deployment category out of scope.

Or, is this a political ploy, so as to avoid a turf war with homenet people?

If that is the case, it would be much more prudent to have another BoF 
to iron out some of these issues. {This may be prudent for reasons I 
already indicated in the same #00327 message as well - I will  not 
repeat those arguments here.}

Best regards, Rene

On 10/28/2014 4:13 PM, Benoit Claise wrote:
> Dear all,
>
> [sorry for double-posting, but we need the specific feedback from the 
> HOMENET community]
>
> 1. scope
> I finished reading the ANIMA mailing list and, based on the feedback, 
> Joel, Ted, and I would like to clarify the ANIMA scope for "the set of 
> specific reusable infrastructure components that support autonomic 
> interactions between devices" (quoting the charter)
>
> The charter currently mentions:
>     The ANIMA working group will initially focus on enterprise, ISP 
> networks and IoT.
>
> Multiple tracks were discussed on the mailing list.
>     * keep enterprise, ISP networks and IoT
>     * focus on enterprise and ISP networks
>     * everything, but the initial focus is enterprise and carrier?
>     * professionally-managed networks
>
> It seems to us that "professionally-managed networks" is what ANIMA is 
> after. And it's potentially a distraction to try to segment the scope 
> based on enterprise, ISP, homenet, or IoT. What is IoT after all?
>
> OLD:     The ANIMA working group will initially focus on enterprise, 
> ISP networks and IoT.
> NEW:    The ANIMA working group focuses on professionally-managed 
> networks.
>
> Does it sound about right?
>
> 2. Overlap with HOMENET
> This distinction in point 1 might help regarding the potential overlap 
> of the solution for distributed IPv6 prefix management.
> Btw, the new charter has been adapted:
> OLD:  A solution for distributed IPv6 prefix management within a network.
> NEW: the solution for distributed IPv6 prefix management within a 
> large-scale network
>
> Also, The HOMENET collaboration has been stressed in the charter.
>
> 3. Others
> I believe I took care of the others changes proposed on the mailing. 
> If this is not the case, let me know.
> At this point in time, please provide concrete change to the charter 
> text if some issues persist.
> Charter v15 has just been posted, and you can review the detailed 
> changes at 
> https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-15.txt
>
>
> 4. Security Advisor.
> I have requested one for ANIMA to the security ADs.
>
> Regards, Benoit
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


From nobody Tue Oct 28 15:48:22 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3440F1A0023; Tue, 28 Oct 2014 15:48:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHmUemA9-8Xl; Tue, 28 Oct 2014 15:48:13 -0700 (PDT)
Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961E21A00D7; Tue, 28 Oct 2014 15:48:11 -0700 (PDT)
Received: by mail-pd0-f179.google.com with SMTP id g10so1647538pdj.24 for ; Tue, 28 Oct 2014 15:48:11 -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=AtGLhOjV3hRdC0B0xTXLkKttsAxem/yaLjVYJcNBpjM=; b=KV/hkY3DAWQPfKw6cmElHF0XCkJHjYsecw6G33c1lR6z03Q0FvDqbACrP3Yyu+ctEY jODtrmFUVqVVhQ1bUkX3lzfd4R4JSG0smX+fa5jhdL0Lp2g+dovAn1/tGgBLMLr0axdz BryPqdP8uRq86Cr4rM6zrbSO39+qjU1MVqhLT8R3dXkbp+8q5ATFiz5jZjeV3sBVLi29 kD1GUwjirws4ZX2a95iREH67+JfO9WOC/O+U4AljVb0avEo+0jYsQNhMy2O/YKPb/Eb4 ShHLtfyo6yZWt5pFTxhjbIvY6keyd3Alu3lX/Rs2Ef70LNNBL1zLCssnJjLIfVeDJnT7 CX6A==
X-Received: by 10.68.219.35 with SMTP id pl3mr6350205pbc.143.1414536491295; Tue, 28 Oct 2014 15:48:11 -0700 (PDT)
Received: from [130.216.38.108] ([130.216.38.108]) by mx.google.com with ESMTPSA id hm1sm2541012pdb.84.2014.10.28.15.48.07 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Oct 2014 15:48:09 -0700 (PDT)
Message-ID: <54501D28.4090908@gmail.com>
Date: Wed, 29 Oct 2014 11:48:08 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Rene Struik 
References: <544FF8FC.5090103@cisco.com> <54500C8F.5030104@gmail.com>
In-Reply-To: <54500C8F.5030104@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/KVkt16ncZDKNQCblr2rw5gO1loA
Cc: Benoit Claise , homenet , "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 22:48:18 -0000

On 29/10/2014 10:37, Rene Struik wrote:
> Hi Benoit:
> 
> -1 on you suggestion #1.
> 
> I do not think suggesting "constrained networks and devices" to be
> suddenly out of scope helps: it is one of the main areas where
> semi-automatic management is imperative. 

Rene has a point. My +1 was with the idea of limiting the initially
worked-out use cases, and avoiding any direct interference with
progress in homenet. But understanding the requirements for
constrained networks is desirable. What I don't know is whether
those requirements can in fact be met by the same infrastructure
components that we need for "professionally managed" networks.
There may simply not be enough overlap between "nimble and
heterogeneous" and "managed and homogeneous."

   Brian

If one has a bootstrapping
> solution and configuration negotiation/synchronization protocol that is
> not useful in constrained settings, what is the point? In my mind, it
> seems much more prudent to design schemes with constrained networks and
> devices and failure recovery models that apply there (configuration
> mismatch due to sleepy devices, malfunctioning data store, etc.), where
> these would then obviously also fit the less constrained,
> "professionally managed" networks. Design for the"nimble", so that both
> "nimble" and "fatter" networks can use this.
> 
> This also has the advantage that one is forced to think in terms of many
> potential actors, rather than a few ones, which helps in viewing
> solutions in terms of heterogeneous rather than homogeneous deployment
> models.
> 
> I have done all my reviews of nmrg drafts
> (http://www.ietf.org/mail-archive/web/anima/current/msg00327.html) with
> constrained networks and devices in mind. It would be a shame if one
> would now narrow down the focus and rule this (future almost ubiquitous)
> deployment category out of scope.
> 
> Or, is this a political ploy, so as to avoid a turf war with homenet
> people?
> 
> If that is the case, it would be much more prudent to have another BoF
> to iron out some of these issues. {This may be prudent for reasons I
> already indicated in the same #00327 message as well - I will  not
> repeat those arguments here.}
> 
> Best regards, Rene
> 
> On 10/28/2014 4:13 PM, Benoit Claise wrote:
>> Dear all,
>>
>> [sorry for double-posting, but we need the specific feedback from the
>> HOMENET community]
>>
>> 1. scope
>> I finished reading the ANIMA mailing list and, based on the feedback,
>> Joel, Ted, and I would like to clarify the ANIMA scope for "the set of
>> specific reusable infrastructure components that support autonomic
>> interactions between devices" (quoting the charter)
>>
>> The charter currently mentions:
>>     The ANIMA working group will initially focus on enterprise, ISP
>> networks and IoT.
>>
>> Multiple tracks were discussed on the mailing list.
>>     * keep enterprise, ISP networks and IoT
>>     * focus on enterprise and ISP networks
>>     * everything, but the initial focus is enterprise and carrier?
>>     * professionally-managed networks
>>
>> It seems to us that "professionally-managed networks" is what ANIMA is
>> after. And it's potentially a distraction to try to segment the scope
>> based on enterprise, ISP, homenet, or IoT. What is IoT after all?
>>
>> OLD:     The ANIMA working group will initially focus on enterprise,
>> ISP networks and IoT.
>> NEW:    The ANIMA working group focuses on professionally-managed
>> networks.
>>
>> Does it sound about right?
>>
>> 2. Overlap with HOMENET
>> This distinction in point 1 might help regarding the potential overlap
>> of the solution for distributed IPv6 prefix management.
>> Btw, the new charter has been adapted:
>> OLD:  A solution for distributed IPv6 prefix management within a network.
>> NEW: the solution for distributed IPv6 prefix management within a
>> large-scale network
>>
>> Also, The HOMENET collaboration has been stressed in the charter.
>>
>> 3. Others
>> I believe I took care of the others changes proposed on the mailing.
>> If this is not the case, let me know.
>> At this point in time, please provide concrete change to the charter
>> text if some issues persist.
>> Charter v15 has just been posted, and you can review the detailed
>> changes at
>> https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-15.txt
>>
>>
>>
>> 4. Security Advisor.
>> I have requested one for ANIMA to the security ADs.
>>
>> Regards, Benoit
>>
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
> 
> 


From nobody Tue Oct 28 19:57:31 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814751A3BA7; Tue, 28 Oct 2014 19:57:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFWLkXRD_h_P; Tue, 28 Oct 2014 19:57:27 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19851A1B00; Tue, 28 Oct 2014 19:57:26 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOD76882; Wed, 29 Oct 2014 02:57:25 +0000 (GMT)
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Oct 2014 02:57:24 +0000
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.22]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Wed, 29 Oct 2014 10:57:17 +0800
From: Sheng Jiang 
To: Benoit Claise , "anima@ietf.org" , "homenet@ietf.org" 
Thread-Topic: [homenet] ANIMA scope + homenet interaction + charter v15
Thread-Index: AQHP8uxfe2M7WLYKck6TBi2tNBM/BJxGX/mw
Date: Wed, 29 Oct 2014 02:57:17 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF6B09D@nkgeml512-mbx.china.huawei.com>
References: <544FF8FC.5090103@cisco.com>
In-Reply-To: <544FF8FC.5090103@cisco.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.145]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/8XdURZAv75Sr29wC-C8AQ9cTAE0
Subject: Re: [homenet] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 02:57:29 -0000

SGksIEJlbm9pdCBhbmQgYWxsLA0KDQpSZXBseSBpbiBsaW5lcy4NCg0KT24gMjkvMTAvMjAxNCAw
OToxMywgQmVub2l0IENsYWlzZSB3cm90ZToNCj5EZWFyIGFsbCwNCj4NCj5bc29ycnkgZm9yIGRv
dWJsZS1wb3N0aW5nLCBidXQgd2UgbmVlZCB0aGUgc3BlY2lmaWMgZmVlZGJhY2sgZnJvbSB0aGUN
Cj5IT01FTkVUIGNvbW11bml0eV0NCj4NCj4xLiBzY29wZQ0KPkkgZmluaXNoZWQgcmVhZGluZyB0
aGUgQU5JTUEgbWFpbGluZyBsaXN0IGFuZCwgYmFzZWQgb24gdGhlIGZlZWRiYWNrLA0KPkpvZWws
IFRlZCwgYW5kIEkgd291bGQgbGlrZSB0byBjbGFyaWZ5IHRoZSBBTklNQSBzY29wZSBmb3IgInRo
ZSBzZXQgb2YNCj5zcGVjaWZpYyByZXVzYWJsZSBpbmZyYXN0cnVjdHVyZSBjb21wb25lbnRzIHRo
YXQgc3VwcG9ydCBhdXRvbm9taWMNCj5pbnRlcmFjdGlvbnMgYmV0d2VlbiBkZXZpY2VzIiAocXVv
dGluZyB0aGUgY2hhcnRlcikNCj4NCj5UaGUgY2hhcnRlciBjdXJyZW50bHkgbWVudGlvbnM6DQo+
ICAgICBUaGUgQU5JTUEgd29ya2luZyBncm91cCB3aWxsIGluaXRpYWxseSBmb2N1cyBvbiBlbnRl
cnByaXNlLCBJU1ANCj5uZXR3b3JrcyBhbmQgSW9ULg0KPg0KPk11bHRpcGxlIHRyYWNrcyB3ZXJl
IGRpc2N1c3NlZCBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KPiAgICAgKiBrZWVwIGVudGVycHJpc2Us
IElTUCBuZXR3b3JrcyBhbmQgSW9UDQo+ICAgICAqIGZvY3VzIG9uIGVudGVycHJpc2UgYW5kIElT
UCBuZXR3b3Jrcw0KPiAgICAgKiBldmVyeXRoaW5nLCBidXQgdGhlIGluaXRpYWwgZm9jdXMgaXMg
ZW50ZXJwcmlzZSBhbmQgY2Fycmllcj8NCj4gICAgICogcHJvZmVzc2lvbmFsbHktbWFuYWdlZCBu
ZXR3b3Jrcw0KPg0KPkl0IHNlZW1zIHRvIHVzIHRoYXQgInByb2Zlc3Npb25hbGx5LW1hbmFnZWQg
bmV0d29ya3MiIGlzIHdoYXQgQU5JTUEgaXMNCj5hZnRlci4gQW5kIGl0J3MgcG90ZW50aWFsbHkg
YSBkaXN0cmFjdGlvbiB0byB0cnkgdG8gc2VnbWVudCB0aGUgc2NvcGUNCj5iYXNlZCBvbiBlbnRl
cnByaXNlLCBJU1AsIGhvbWVuZXQsIG9yIElvVC4gV2hhdCBpcyBJb1QgYWZ0ZXIgYWxsPw0KPg0K
Pk9MRDogICAgIFRoZSBBTklNQSB3b3JraW5nIGdyb3VwIHdpbGwgaW5pdGlhbGx5IGZvY3VzIG9u
IGVudGVycHJpc2UsIElTUA0KPm5ldHdvcmtzIGFuZCBJb1QuDQo+TkVXOiAgICBUaGUgQU5JTUEg
d29ya2luZyBncm91cCBmb2N1c2VzIG9uIHByb2Zlc3Npb25hbGx5LW1hbmFnZWQNCj5uZXR3b3Jr
cy4NCj4NCj5Eb2VzIGl0IHNvdW5kIGFib3V0IHJpZ2h0Pw0KDQpZZXMsIGl0IGlzIHJpZ2h0LiBB
ZnRlciB3ZSBkZXZlbG9wIGEgZ2VuZXJpYyBwcm90b2NvbC9tZWNoYW5pc20sIGl0IGlzIHBvc3Np
YmxlIHRoYXQgb3RoZXIgcGVvcGxlIG1heSByZXVzZSB0aGVtIGluIG90aGVyIHNjZW5hcmlvcy4g
SXQgaXMgb3V0IG9mIG91ciBjdXJyZW50IGZvY3VzLCBmb3Igc3VyZS4NCg0KPjIuIE92ZXJsYXAg
d2l0aCBIT01FTkVUDQo+VGhpcyBkaXN0aW5jdGlvbiBpbiBwb2ludCAxIG1pZ2h0IGhlbHAgcmVn
YXJkaW5nIHRoZSBwb3RlbnRpYWwgb3ZlcmxhcA0KPm9mIHRoZSBzb2x1dGlvbiBmb3IgZGlzdHJp
YnV0ZWQgSVB2NiBwcmVmaXggbWFuYWdlbWVudC4NCj5CdHcsIHRoZSBuZXcgY2hhcnRlciBoYXMg
YmVlbiBhZGFwdGVkOg0KPk9MRDogIEEgc29sdXRpb24gZm9yIGRpc3RyaWJ1dGVkIElQdjYgcHJl
Zml4IG1hbmFnZW1lbnQgd2l0aGluIGEgbmV0d29yay4NCj5ORVc6IHRoZSBzb2x1dGlvbiBmb3Ig
ZGlzdHJpYnV0ZWQgSVB2NiBwcmVmaXggbWFuYWdlbWVudCB3aXRoaW4gYQ0KPmxhcmdlLXNjYWxl
IG5ldHdvcmsNCg0KVGhhdCdzIGV4YWN0bHkgc3RhdGVkIGluIHRoZSBpbmRpdmlkdWFsIGRyYWZ0
IHRoYXQgc3VibWl0dGVkIHRvIGFuaW1hLg0KDQo+QWxzbywgVGhlIEhPTUVORVQgY29sbGFib3Jh
dGlvbiBoYXMgYmVlbiBzdHJlc3NlZCBpbiB0aGUgY2hhcnRlci4NCg0KSXQgd291bGQgYmUgaGVs
cGZ1bC4NCg0KPjMuIE90aGVycw0KPkkgYmVsaWV2ZSBJIHRvb2sgY2FyZSBvZiB0aGUgb3RoZXJz
IGNoYW5nZXMgcHJvcG9zZWQgb24gdGhlIG1haWxpbmcuIElmDQo+dGhpcyBpcyBub3QgdGhlIGNh
c2UsIGxldCBtZSBrbm93Lg0KPkF0IHRoaXMgcG9pbnQgaW4gdGltZSwgcGxlYXNlIHByb3ZpZGUg
Y29uY3JldGUgY2hhbmdlIHRvIHRoZSBjaGFydGVyDQo+dGV4dCBpZiBzb21lIGlzc3VlcyBwZXJz
aXN0Lg0KPkNoYXJ0ZXIgdjE1IGhhcyBqdXN0IGJlZW4gcG9zdGVkLCBhbmQgeW91IGNhbiByZXZp
ZXcgdGhlIGRldGFpbGVkDQo+Y2hhbmdlcyBhdA0KPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp
ZmY/dXJsMT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZA0KPm9jJTJGY2hh
cnRlci1pZXRmLWFuaW1hJTJGd2l0aG1pbGVzdG9uZXMtMDAtMTQudHh0JmRpZmZ0eXBlPS0taHRt
bCZzdWINCj5taXQ9R28hJnVybDI9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUy
RmRvYyUyRmNoYXJ0ZXItaWV0Zi1hDQo+bmltYSUyRndpdGhtaWxlc3RvbmVzLTAwLTE1LnR4dA0K
Pg0KPg0KPjQuIFNlY3VyaXR5IEFkdmlzb3IuDQo+SSBoYXZlIHJlcXVlc3RlZCBvbmUgZm9yIEFO
SU1BIHRvIHRoZSBzZWN1cml0eSBBRHMuDQoNCkl0IHdvdWxkIGJlIGdyZWF0LiBNYW55IHRoYW5r
cy4NCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZw0KDQo+UmVnYXJkcywgQmVub2l0DQo+DQo+X19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5ob21lbmV0IG1h
aWxpbmcgbGlzdA0KPmhvbWVuZXRAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2hvbWVuZXQNCg==


From nobody Tue Oct 28 23:28:46 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272A61A0673; Tue, 28 Oct 2014 23:28:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuXQPWoPtQUw; Tue, 28 Oct 2014 23:28:41 -0700 (PDT)
Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a02:238:f02a:8e2f:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71BD81A0451; Tue, 28 Oct 2014 23:28:41 -0700 (PDT)
Received: from equinox by eidolon.nox.tf with local (Exim 4.84) (envelope-from ) id 1XjMkH-0002aQ-1k; Wed, 29 Oct 2014 07:28:38 +0100
Date: Wed, 29 Oct 2014 07:28:37 +0100
From: David Lamparter 
To: Brian E Carpenter 
Message-ID: <20141029062837.GH5186@eidolon>
References: <20141020204033.GD236844@jupiter.n2.diac24.net> <20141022190653.GB868521@jupiter.n2.diac24.net>   <544FF3F2.3050206@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <544FF3F2.3050206@gmail.com>
User-Agent: Mutt/1.5.22 (2013-10-16)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/UOKX8-9--yw8CZ0n-aPf089DCIQ
Cc: Ole Troan , Mikael Abrahamsson , "Fred Baker \(fred\)" , "homenet@ietf.org" , "rtgwg@ietf.org" , David Lamparter 
Subject: Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 06:28:43 -0000

On Wed, Oct 29, 2014 at 08:52:18AM +1300, Brian E Carpenter wrote:
> On 29/10/2014 02:06, Ole Troan wrote:
> > Fred,
> > 
> >>>> https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-routing-extra-qualifiers/?include_text=1
> >>>> https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-dst-src-routing/?include_text=1
> >> Speaking strictly for myself, I’m not sure why homenet is relevant. The technology is related to networks that have different routing depend on on one’s use case. A class of solutions for it has been called the “fish” problem, and built using multi-topology routing. In homenet, it’s called SADR, and is primarily about egress routing (routing to an egress to an upstream ISP that gave you a PA prefix). While one doesn’t really want to confuse theory with practice, in theory it could be used between points of a network, to prevent folks using one set of prefixes to talk with another set, or to force routing of some sessions in some ways.
> >>
> >> Personally, those are a class of problems I associate with campus networks more than residential networks.
> > 
> > why homenet is relevant?
> > isn't multi-prefix multi-homing one of the most obvious use cases for source address dependent routing? that's not restricted with homenets, but also any small network. I'm assuming large networks will continue with PI addresses and BGP based multihoming.
> 
> If you mean by "large" the few ten thousand largest networks in the
> world, that will not cause significant BGP4 bloat by having PI, then
> yes, I fully agree. Any medium to small network should expect to have
> multiple prefixes in the long run (we are not talking about today, but
> a time when all we old folks who remember the IPv4 world have retired
> and gone fishing).

What I'm personally wondering most in this regard is: to what extent
will larger networks deploy multiple prefixes to the hosts?

I can certainly see it in small to medium businesses that maybe just got
their second uplink at their headquarters and opened 3 shops or
whatever.  But at some point I'd guess policy/enforcement replaces
multiprefix deployments, as Gert wrote in his mail.  Then again, some
shiny new things like MPTCP would benefit from multiprefix deployments,
which might be an argument for some medium-sized users to deploy this?


FWIW, I understand Fred's question for the relevance of homenet as
asking whether these drafts should explicitly target homenet or not, and
I agree that they shouldn't.  Even if 90% of SADR use-cases end up to be
"bread and butter" homenets, the remaining 10% are valid too.


-David


From nobody Tue Oct 28 23:50:33 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4164D1A1B17; Tue, 28 Oct 2014 23:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.511
X-Spam-Level: 
X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-gINgaMGAv9; Tue, 28 Oct 2014 23:50:19 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13FE01A1A1C; Tue, 28 Oct 2014 23:50:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1337; q=dns/txt; s=iport; t=1414565419; x=1415775019; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xwvEhg6DBrxvy6NV8EfiKONfdPSNwn6H7VcSbsbu/ZI=; b=OvRpdmfwqkWwOO2zRYjxXetz2xWMenIhPhf7JZv7sbUZAb/BARS6ohTL VTt1hA2fXVcdiPn2+74bTohNSu2Hn78eCQ0bPu+EKgqLSx4IUrAFhA3Mm FmEeGV6cXjhmB3xGkGGcBOtonFehdPLw+jJP6srltQleP/SdrW51YjCd5 c=;
X-Files: signature.asc : 195
X-IronPort-AV: E=Sophos;i="5.04,808,1406592000";  d="asc'?scan'208";a="91287274"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP; 29 Oct 2014 06:50:17 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9T6oHHN031698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 06:50:17 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.248]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 01:50:17 -0500
From: "Fred Baker (fred)" 
To: David Lamparter 
Thread-Topic: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
Thread-Index: AQHP7KYr8Fy7zf5Z70yFtC9ToRE4KA==
Date: Wed, 29 Oct 2014 06:50:17 +0000
Message-ID: 
References: <20141020204033.GD236844@jupiter.n2.diac24.net> <20141022190653.GB868521@jupiter.n2.diac24.net>   <544FF3F2.3050206@gmail.com> <20141029062837.GH5186@eidolon>
In-Reply-To: <20141029062837.GH5186@eidolon>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.19.64.120]
Content-Type: multipart/signed; boundary="Apple-Mail=_71B80352-0042-4026-A97C-A58CF7EF403E"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/8rSdI33fO8t8lIJsctbT6K9lGxE
Cc: Ole Troan , "homenet@ietf.org" , "rtgwg@ietf.org" , Mikael Abrahamsson 
Subject: Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 06:50:24 -0000

--Apple-Mail=_71B80352-0042-4026-A97C-A58CF7EF403E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Oct 28, 2014, at 11:28 PM, David Lamparter  =
wrote:

> What I'm personally wondering most in this regard is: to what extent
> will larger networks deploy multiple prefixes to the hosts?

Well, define =93larger=94. Any network that gets a PI prefix is unlikely =
to deploy multiple prefixes. The question is at what size network is =
makes sense to obtain an AS number and a PI prefix, and use BGP to talk =
with one=92s upstream. Wherever that boundary is, below that networks =
will use PA prefixes. The question then becomes: will they multi home?

And I think the answer today is that we don=92t know the answer.

--Apple-Mail=_71B80352-0042-4026-A97C-A58CF7EF403E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iD8DBQFUUI4ibjEdbHIsm0MRAiXHAKDNLmSA5OJdR0hascpe6gM2EgNufQCgkfWX
Zk3WB/wxsiNP1qmSRE9xIOg=
=7ndN
-----END PGP SIGNATURE-----

--Apple-Mail=_71B80352-0042-4026-A97C-A58CF7EF403E--


From nobody Wed Oct 29 03:32:49 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C981A8035; Wed, 29 Oct 2014 03:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level: 
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8l_jFpLfrFj; Wed, 29 Oct 2014 03:32:43 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6219D1A802D; Wed, 29 Oct 2014 03:32:43 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 6AFD21058EA4D; Wed, 29 Oct 2014 10:32:40 +0000 (GMT)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s9TAWfT5008426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 06:32:41 -0400
Received: from [135.244.2.6] (135.5.27.16) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 29 Oct 2014 06:32:41 -0400
Message-ID: <5450B98F.9060908@alcatel-lucent.com>
Date: Wed, 29 Oct 2014 10:55:27 +0100
From: Laurent Ciavaglia 
Organization: Alcatel-Lucent Bell Labs France
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Brian E Carpenter , Rene Struik 
References: <544FF8FC.5090103@cisco.com> <54500C8F.5030104@gmail.com> <54501D28.4090908@gmail.com>
In-Reply-To: <54501D28.4090908@gmail.com>
Content-Type: multipart/alternative; boundary="------------080403050600040608030605"
X-Originating-IP: [135.5.27.16]
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/JVhxt1mIMH2fetjwJS4eISiRsa4
Cc: Benoit Claise , homenet , "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 10:32:46 -0000

--------------080403050600040608030605
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

I agree with Rene and Brian on the need to consider constrained networks.
However, I don't think that "professionally-managed networks" 
automatically exclude such environments.

As Barbara S. mentioned in 
http://www.ietf.org/mail-archive/web/homenet/current/msg04008.html, 
there can be multiple scenarios with different roles, and different 
devices being managed.

My opinion is that covering the scenario of professionally-managed 
consrained (and less constrained) networks is a challenging one, from 
which we could derive "good" common, re-usable protocols/components.

Best regards, Laurent.


On 28/10/2014 23:48, Brian E Carpenter wrote:
> On 29/10/2014 10:37, Rene Struik wrote:
>> Hi Benoit:
>>
>> -1 on you suggestion #1.
>>
>> I do not think suggesting "constrained networks and devices" to be
>> suddenly out of scope helps: it is one of the main areas where
>> semi-automatic management is imperative.
> Rene has a point. My +1 was with the idea of limiting the initially
> worked-out use cases, and avoiding any direct interference with
> progress in homenet. But understanding the requirements for
> constrained networks is desirable. What I don't know is whether
> those requirements can in fact be met by the same infrastructure
> components that we need for "professionally managed" networks.
> There may simply not be enough overlap between "nimble and
> heterogeneous" and "managed and homogeneous."
>
>     Brian
>
> If one has a bootstrapping
>> solution and configuration negotiation/synchronization protocol that is
>> not useful in constrained settings, what is the point? In my mind, it
>> seems much more prudent to design schemes with constrained networks and
>> devices and failure recovery models that apply there (configuration
>> mismatch due to sleepy devices, malfunctioning data store, etc.), where
>> these would then obviously also fit the less constrained,
>> "professionally managed" networks. Design for the"nimble", so that both
>> "nimble" and "fatter" networks can use this.
>>
>> This also has the advantage that one is forced to think in terms of many
>> potential actors, rather than a few ones, which helps in viewing
>> solutions in terms of heterogeneous rather than homogeneous deployment
>> models.
>>
>> I have done all my reviews of nmrg drafts
>> (http://www.ietf.org/mail-archive/web/anima/current/msg00327.html) with
>> constrained networks and devices in mind. It would be a shame if one
>> would now narrow down the focus and rule this (future almost ubiquitous)
>> deployment category out of scope.
>>
>> Or, is this a political ploy, so as to avoid a turf war with homenet
>> people?
>>
>> If that is the case, it would be much more prudent to have another BoF
>> to iron out some of these issues. {This may be prudent for reasons I
>> already indicated in the same #00327 message as well - I will  not
>> repeat those arguments here.}
>>
>> Best regards, Rene
>>
>> On 10/28/2014 4:13 PM, Benoit Claise wrote:
>>> Dear all,
>>>
>>> [sorry for double-posting, but we need the specific feedback from the
>>> HOMENET community]
>>>
>>> 1. scope
>>> I finished reading the ANIMA mailing list and, based on the feedback,
>>> Joel, Ted, and I would like to clarify the ANIMA scope for "the set of
>>> specific reusable infrastructure components that support autonomic
>>> interactions between devices" (quoting the charter)
>>>
>>> The charter currently mentions:
>>>      The ANIMA working group will initially focus on enterprise, ISP
>>> networks and IoT.
>>>
>>> Multiple tracks were discussed on the mailing list.
>>>      * keep enterprise, ISP networks and IoT
>>>      * focus on enterprise and ISP networks
>>>      * everything, but the initial focus is enterprise and carrier?
>>>      * professionally-managed networks
>>>
>>> It seems to us that "professionally-managed networks" is what ANIMA is
>>> after. And it's potentially a distraction to try to segment the scope
>>> based on enterprise, ISP, homenet, or IoT. What is IoT after all?
>>>
>>> OLD:     The ANIMA working group will initially focus on enterprise,
>>> ISP networks and IoT.
>>> NEW:    The ANIMA working group focuses on professionally-managed
>>> networks.
>>>
>>> Does it sound about right?
>>>
>>> 2. Overlap with HOMENET
>>> This distinction in point 1 might help regarding the potential overlap
>>> of the solution for distributed IPv6 prefix management.
>>> Btw, the new charter has been adapted:
>>> OLD:  A solution for distributed IPv6 prefix management within a network.
>>> NEW: the solution for distributed IPv6 prefix management within a
>>> large-scale network
>>>
>>> Also, The HOMENET collaboration has been stressed in the charter.
>>>
>>> 3. Others
>>> I believe I took care of the others changes proposed on the mailing.
>>> If this is not the case, let me know.
>>> At this point in time, please provide concrete change to the charter
>>> text if some issues persist.
>>> Charter v15 has just been posted, and you can review the detailed
>>> changes at
>>> https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-15.txt
>>>
>>>
>>>
>>> 4. Security Advisor.
>>> I have requested one for ANIMA to the security ADs.
>>>
>>> Regards, Benoit
>>>
>>> _______________________________________________
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Advanced Internet Research

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com 


linkedin: laurentciavaglia 

address: Route de Villejust | 91620 Nozay | France


--------------080403050600040608030605
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit


  
    
  
  
    Dear all,

      

      I agree with Rene and Brian on the need to consider constrained
      networks.

      However, I don't think that "professionally-managed networks"
      automatically exclude such environments.

      

      As Barbara S. mentioned in
      http://www.ietf.org/mail-archive/web/homenet/current/msg04008.html,
      there can be multiple scenarios with different roles, and
      different devices being managed.

      

      My opinion is that covering the scenario of professionally-managed
      consrained (and less constrained) networks is a challenging one,
      from which we could derive "good" common, re-usable
      protocols/components.

      

      Best regards, Laurent.

      

      

    
    
On 28/10/2014 23:48, Brian E Carpenter
      wrote:

    

    

      
On 29/10/2014 10:37, Rene Struik wrote:


      

        
Hi Benoit:

-1 on you suggestion #1.

I do not think suggesting "constrained networks and devices" to be
suddenly out of scope helps: it is one of the main areas where
semi-automatic management is imperative. 


      

      
Rene has a point. My +1 was with the idea of limiting the initially
worked-out use cases, and avoiding any direct interference with
progress in homenet. But understanding the requirements for
constrained networks is desirable. What I don't know is whether
those requirements can in fact be met by the same infrastructure
components that we need for "professionally managed" networks.
There may simply not be enough overlap between "nimble and
heterogeneous" and "managed and homogeneous."

   Brian

If one has a bootstrapping


      

        
solution and configuration negotiation/synchronization protocol that is
not useful in constrained settings, what is the point? In my mind, it
seems much more prudent to design schemes with constrained networks and
devices and failure recovery models that apply there (configuration
mismatch due to sleepy devices, malfunctioning data store, etc.), where
these would then obviously also fit the less constrained,
"professionally managed" networks. Design for the"nimble", so that both
"nimble" and "fatter" networks can use this.

This also has the advantage that one is forced to think in terms of many
potential actors, rather than a few ones, which helps in viewing
solutions in terms of heterogeneous rather than homogeneous deployment
models.

I have done all my reviews of nmrg drafts
(http://www.ietf.org/mail-archive/web/anima/current/msg00327.html) with
constrained networks and devices in mind. It would be a shame if one
would now narrow down the focus and rule this (future almost ubiquitous)
deployment category out of scope.

Or, is this a political ploy, so as to avoid a turf war with homenet
people?

If that is the case, it would be much more prudent to have another BoF
to iron out some of these issues. {This may be prudent for reasons I
already indicated in the same #00327 message as well - I will  not
repeat those arguments here.}

Best regards, Rene

On 10/28/2014 4:13 PM, Benoit Claise wrote:


        

          
Dear all,

[sorry for double-posting, but we need the specific feedback from the
HOMENET community]

1. scope
I finished reading the ANIMA mailing list and, based on the feedback,
Joel, Ted, and I would like to clarify the ANIMA scope for "the set of
specific reusable infrastructure components that support autonomic
interactions between devices" (quoting the charter)

The charter currently mentions:
    The ANIMA working group will initially focus on enterprise, ISP
networks and IoT.

Multiple tracks were discussed on the mailing list.
    * keep enterprise, ISP networks and IoT
    * focus on enterprise and ISP networks
    * everything, but the initial focus is enterprise and carrier?
    * professionally-managed networks

It seems to us that "professionally-managed networks" is what ANIMA is
after. And it's potentially a distraction to try to segment the scope
based on enterprise, ISP, homenet, or IoT. What is IoT after all?

OLD:     The ANIMA working group will initially focus on enterprise,
ISP networks and IoT.
NEW:    The ANIMA working group focuses on professionally-managed
networks.

Does it sound about right?

2. Overlap with HOMENET
This distinction in point 1 might help regarding the potential overlap
of the solution for distributed IPv6 prefix management.
Btw, the new charter has been adapted:
OLD:  A solution for distributed IPv6 prefix management within a network.
NEW: the solution for distributed IPv6 prefix management within a
large-scale network

Also, The HOMENET collaboration has been stressed in the charter.

3. Others
I believe I took care of the others changes proposed on the mailing.
If this is not the case, let me know.
At this point in time, please provide concrete change to the charter
text if some issues persist.
Charter v15 has just been posted, and you can review the detailed
changes at
https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-15.txt



4. Security Advisor.
I have requested one for ANIMA to the security ADs.

Regards, Benoit

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


        

        



      

      
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima



    

    

    
-- 

      
      
      
      

        
Bien
            cordialement, Best regards,

        
 

        
Laurent
              Ciavaglia

        
Advanced
            Internet Research

        
Bell
            Labs | Alcatel Lucent

        
 

        
phone:
            +33 160 402 636 

        
email:
          laurent.ciavaglia@alcatel-lucent.com

        
linkedin:
          laurentciavaglia

        
address:
            Route de Villejust | 91620 Nozay | France

      

    

  


--------------080403050600040608030605--


From nobody Wed Oct 29 05:05:52 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EF31A0078; Wed, 29 Oct 2014 05:05:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.012
X-Spam-Level: 
X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaBZD6tjAfig; Wed, 29 Oct 2014 05:05:47 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id D16471A0076; Wed, 29 Oct 2014 05:05:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 6B1E7871612; Wed, 29 Oct 2014 13:05:45 +0100 (CET)
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYhcOzxypzPf; Wed, 29 Oct 2014 13:05:45 +0100 (CET)
Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 3F00D871611; Wed, 29 Oct 2014 13:05:45 +0100 (CET)
Message-ID: <5450D7ED.9010806@globis.net>
Date: Wed, 29 Oct 2014 13:05:01 +0100
From: Ray Hunter 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: "Fred Baker (fred)" 
References: <20141020204033.GD236844@jupiter.n2.diac24.net> <20141022190653.GB868521@jupiter.n2.diac24.net>   <544FF3F2.3050206@gmail.com> <20141029062837.GH5186@eidolon> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/dqCMBs1yzW05lIdJ6Kl9tdx8Oyc
Cc: Ole Troan , "homenet@ietf.org" , "rtgwg@ietf.org" , Mikael Abrahamsson , David Lamparter 
Subject: Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 12:05:48 -0000

Fred Baker (fred) wrote:
> On Oct 28, 2014, at 11:28 PM, David Lamparter  wrote:
>
>> What I'm personally wondering most in this regard is: to what extent
>> will larger networks deploy multiple prefixes to the hosts?
>
> Well, define “larger”. Any network that gets a PI prefix is unlikely to deploy multiple prefixes. The question is at what size network is makes sense to obtain an AS number and a PI prefix, and use BGP to talk with one’s upstream.
I don't agree with this statement for the following reasons.

Availability: There are many enterprises that have very numerous 
far-flung sales-office type locations which do not host any critical 
data or applications, but which could benefit from higher availability 
than that provided by a single ISP provider (some of which are currently 
served by a specialised box offering a Very Small Office Service running 
dual IPSec tunnels to a central site, which then performs the break out 
to the corporate intranet/Internet)

Latency: There are many sites which could benefit from local Internet 
breakout to regional cloud services, where you don't want to suffer the 
latency associated with a back haul from an office in Australia to a 
regional hub in Hong Kong, or even East coast US to West coast US and 
back. You'd still also want some back up via the central breakout if the 
local breakout failed.

Cost: There are cost savings to be made in many countries where private 
network services are still many orders of magnitude more expensive than 
plain old Internet. So Internet offload for non-mission-critical traffic 
can be very attractive. If you could achieve this via direct host-server 
connections using address selection rules or multipath TCP; rather than 
via PBR, GRE tunnels + NAT, that would be a lot simpler.

>   Wherever that boundary is, below that networks will use PA prefixes. The question then becomes: will they multi home?
>
> And I think the answer today is that we don’t know the answer.
This I agree with.


-- 
Regards,
RayH


From nobody Wed Oct 29 07:24:05 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA061A00F9; Wed, 29 Oct 2014 07:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.567
X-Spam-Level: *
X-Spam-Status: No, score=1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBoV0A7BDUUO; Wed, 29 Oct 2014 07:24:00 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB70E1A00EF; Wed, 29 Oct 2014 07:23:59 -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 s9TENnnc025931; Wed, 29 Oct 2014 15:23:49 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 52A10204FB9; Wed, 29 Oct 2014 15:25:25 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3E537204F6B; Wed, 29 Oct 2014 15:25:25 +0100 (CET)
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 s9TENMf4002872; Wed, 29 Oct 2014 15:23:48 +0100
Message-ID: <5450F85A.7000205@gmail.com>
Date: Wed, 29 Oct 2014 15:23:22 +0100
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Xueli , Ted Lemon , "STARK, BARBARA H" 
References: <20141021160652.24101.60334.idtracker@ietfa.amsl.com> <4BBD7952-84F7-40F9-9034-8DD7A1F2A05C@nominum.com> <2D09D61DDFA73D4C884805CC7865E61130EA59FC@GAALPA1MSGUSRBF.ITServices.sbc.com>  <01FE63842C181246BBE4CF183BD159B4490350AD@nkgeml504-mbx.china.huawei.com> <5447DB20.9080505@gmail.com> <01FE63842C181246BBE4CF183BD159B449036E28@nkgeml504-mbx.china.huawei.com>
In-Reply-To: <01FE63842C181246BBE4CF183BD159B449036E28@nkgeml504-mbx.china.huawei.com>
Content-Type: text/plain; charset=gbk; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/bapCHw5oVsRvc3-L0U_y73rVePQ
Cc: HOMENET Working Group , "mif@ietf.org" 
Subject: Re: [homenet] =?gbk?q?=A1=B0Hybrid_Access_for_Broadband_Networks?= =?gbk?b?obEgKFdULTM0OCk=?=
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 14:24:03 -0000

Le 28/10/2014 05:10, Xueli a ¨¦crit :
> Hello Alex
>
> Thank you for your nice comment. The scenario here is for the fixed
> operators rather than the mobile phone for higher bandwidth. I make
> this clarification in the new version architecture draft asŁş ˇ± Hosts
> in the customer site may connect to the Internet through the CPE, the
> 3G/4G network, or both.  In most cases the majority of the hosts
> connects to the Internet through the CPE only and will experience
> slow Internet access when the bandwidth provided by the fixed access
> network is fully utilized (e.g., the traffic over the fixed access
> network reached its maximum capacity or a pre-specified threshold set
> by the operator). So we are considering the scenario with CPE
> extension with multiple access networks.
>
> I would like to know additional information on the internet drafts
> you mentioned, do you mind to provide more information on this?

Sure, it is about these documents;

Flow Binding Support for Mobile IP
draft-ietf-mip4-multiple-tunnel-support-08.txt

Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support
RFC 6089

and this post:
https://www.ietf.org/mail-archive/web/mip4/current/msg03728.html

>
> Best Regards Li
>
>
> -----Original Message----- From: Alexandru Petrescu
> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, October 23,
> 2014 12:28 AM To: Xueli; Ted Lemon; STARK, BARBARA H Cc: HOMENET
> Working Group; mif@ietf.org Subject: Re: ˇ°Hybrid Access for Broadband
> Networksˇ± (WT-348)
>
> Hello Xueli,
>
> Several people look at this problem as an IP problem.  Instead of
> considering a cellular+dsl combination in a homebox, they considered
> cellular+wifi on a smartphone.   But the goal was the same: augment
> the bandwidth perceived by the end user.
>
> In implementation it is however quite challenging.  The more tempting
> the expectations of augmenting bandwidth by simply adding network
> interfaces (as in adding RAM to a busy computer), the higher the
> desillusion when facing the challenges of implementation.
>
> Some consider it simply as a local computer policy problem (and hence
> no new communicaiton standards needed), but others consider that
> there is a need of a server in the infrastructure to which these
> interfaces would first connect (a sort of an 'anchor').
>
> If such a technology is developped, it will surely be useful for more
> than homenets - it will be useful for multi-interfaced smartphones,
> useful for mobile routers installed in vehicles, and more that I can
> not think of.
>
> Alex PS: there are a few IETF Internet Drafts about how would
> smartphones would use this, with Mobile IPv4 and Mobile IPv6
> extensions, but there are no widespread implementations.
>
> Le 22/10/2014 11:48, Xueli a ¨¦crit :
>> Hello
>>
>> Thanks Barbara to send this liaison out.
>>
>> Hybrid Access network is that Residential gateway (RG, or CPE) is
>> extended with more than two access lines
>>
>> (e.g. DSL + LTE) in order to provide higher bandwidth for the
>> customers. The scenario and architecture are shown as follows
>>
>> cid:image002.jpg@01CF9A07.BF8CD480
>>
>> Right now, we have two individual drafts, one for architecture and
>> requirements, and the other one is for an optional solution.
>>
>> The draft
>> (http://tools.ietf.org/html/draft-lhwxz-hybrid-access-network-architec
>>
>>
ture-00  ; ) proposes the architecture and gap analysis.
>>
>> The solution draft proposes one option for the solutions,
>> http://tools.ietf.org/html/draft-heileyli-gre-notifications-00
>>
>> We did not combine them as one draft, because we believe there may
>> be other candidates, and we would like to have further discussions
>> in the related groups and IETF.
>>
>> We used to present it in Homenet in Toronto.
>>
>> Now the authors have invited Orange to join this architecture
>> work. We will send out the new version of these drafts soon.
>>
>> We are glad to invite the experts for comments.
>>
>> Best Regards
>>
>> Li Xue on the co-authors behalf
>>
>> -----Original Message-----
>>
>> From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of Ted
>> Lemon
>>
>> Sent: Wednesday, October 22, 2014 3:05 AM
>>
>> To: STARK, BARBARA H
>>
>> Cc: HOMENET Working Group
>>
>> Subject: Re: [homenet] Fwd: New Liaison Statement, "Broadband
>> Forum Work on ˇ°Hybrid Access for Broadband Networksˇ±(WT-348)"
>>
>> On Oct 21, 2014, at 2:55 PM, STARK, BARBARA H 
>> wrote:
>>
>>> FYI. I made sure they were aware of IETF mif and homenet
>>> activities in this area. I intend to try to prevent having to
>>> track efforts that try to do the same thing in two different
>>> ways. But some of the BBF effort  may be focused on what can be
>>> done around "bonding" of multiple
>> interfaces that are under the control of a single service provider.
>> I don't see this in mif or homenet.
>>
>> Thanks.   I couldn't really tell what was being proposed from the
>> Liaison statement, so this information is helpful.
>>
>> _______________________________________________
>>
>> homenet mailing list
>>
>> homenet@ietf.org
>>
>> https://www.ietf.org/mailman/listinfo/homenet
>>
>>
>>
>> _______________________________________________ homenet mailing
>> list homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>>
>



From nobody Wed Oct 29 08:14:02 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0711A01C6; Wed, 29 Oct 2014 08:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KSESS9uG37m; Wed, 29 Oct 2014 08:13:39 -0700 (PDT)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18FD01A0171; Wed, 29 Oct 2014 08:13:39 -0700 (PDT)
Received: by mail-oi0-f49.google.com with SMTP id u20so2418589oif.22 for ; Wed, 29 Oct 2014 08:13:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=f/WZlpDJU9UsoaWtJV2vPS4PGrqcO+8iTk3w5WyTYjI=; b=e2vZUKzP31vYR3BBuo8o3V9G1DlGq7P7ClXZyYs3WAkhbM/qlYyA9XBRaEMsDWBhDX D86JZbW5s9Adu+L77YU2k0WiGfl/XGbqpXuHWZor92nh8Ve8HsBwS2CJeto+yyHudgGQ OjypYvNKz48NISc+ox5qBKfLh1PVRSQguKo0/E2O0NiSlUAavW6NkMOng/BYcavDFZKd SBwtEKF8TkII3C2FLc9bFcbk/MiJgCnqT18DWRl8nSHSX5xhCeUNNQyuQLpD5nspopLu 94uAyrR8ew8r70wtavnKY67MzOL5MVswqeoFPCC5IgUc6XOXoeBPfhjSTlqxc4fiOqYg DmVg==
MIME-Version: 1.0
X-Received: by 10.60.157.100 with SMTP id wl4mr9228686oeb.37.1414595617464; Wed, 29 Oct 2014 08:13:37 -0700 (PDT)
Sender: gettysjim@gmail.com
Received: by 10.76.4.203 with HTTP; Wed, 29 Oct 2014 08:13:37 -0700 (PDT)
In-Reply-To: <5450D7ED.9010806@globis.net>
References: <20141020204033.GD236844@jupiter.n2.diac24.net> <20141022190653.GB868521@jupiter.n2.diac24.net>   <544FF3F2.3050206@gmail.com> <20141029062837.GH5186@eidolon>  <5450D7ED.9010806@globis.net>
Date: Wed, 29 Oct 2014 11:13:37 -0400
X-Google-Sender-Auth: -paScE3WgopxfKj55TksJCFvEao
Message-ID: 
From: Jim Gettys 
To: Ray Hunter 
Content-Type: multipart/alternative; boundary=089e01182fd047a90f05069135ba
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/gLOGay4m7N6hMXBnzPM7gV74HhU
Cc: Ole Troan , "rtgwg@ietf.org" , "Fred Baker \(fred\)" , "homenet@ietf.org" , Mikael Abrahamsson , David Lamparter 
Subject: Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 15:13:44 -0000

--089e01182fd047a90f05069135ba
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 29, 2014 at 8:05 AM, Ray Hunter  wrote:

>
>
> Fred Baker (fred) wrote:
>
>> On Oct 28, 2014, at 11:28 PM, David Lamparter  wrote=
:
>>
>>  What I'm personally wondering most in this regard is: to what extent
>>> will larger networks deploy multiple prefixes to the hosts?
>>>
>>
>> Well, define =E2=80=9Clarger=E2=80=9D. Any network that gets a PI prefix=
 is unlikely to
>> deploy multiple prefixes. The question is at what size network is makes
>> sense to obtain an AS number and a PI prefix, and use BGP to talk with
>> one=E2=80=99s upstream.
>>
> I don't agree with this statement for the following reasons.
>
> Availability: There are many enterprises that have very numerous far-flun=
g
> sales-office type locations which do not host any critical data or
> applications, but which could benefit from higher availability than that
> provided by a single ISP provider (some of which are currently served by =
a
> specialised box offering a Very Small Office Service running dual IPSec
> tunnels to a central site, which then performs the break out to the
> corporate intranet/Internet)
>

=E2=80=8B
=E2=80=8B
=E2=80=8BAnd we are now deploying home networks that are being used for hom=
e health
medical monitoring; having full fail-over to another ISP is in the process
of becoming a "life" issue=E2=80=8B.
=E2=80=8B
=E2=80=8B


>
> Latency: There are many sites which could benefit from local Internet
> breakout to regional cloud services, where you don't want to suffer the
> latency associated with a back haul from an office in Australia to a
> regional hub in Hong Kong, or even East coast US to West coast US and bac=
k.
> You'd still also want some back up via the central breakout if the local
> breakout failed.
>
> Cost: There are cost savings to be made in many countries where private
> network services are still many orders of magnitude more expensive than
> plain old Internet. So Internet offload for non-mission-critical traffic
> can be very attractive. If you could achieve this via direct host-server
> connections using address selection rules or multipath TCP; rather than v=
ia
> PBR, GRE tunnels + NAT, that would be a lot simpler.

=E2=80=8B

>
>
>    Wherever that boundary is, below that networks will use PA prefixes.
>> The question then becomes: will they multi home?
>>
>> And I think the answer today is that we don=E2=80=99t know the answer.
>>
> This I agree with.


=E2=80=8BDitto.  Though I have a personal opinion that they will... How els=
e can
you be able to test that things are actually going to "work" in the face of
loss of one ISP? Anything not being tested on an ongoing basis is unlikely
to work in the case of failure.  If availability really matters, you care..=
.

Jim

=E2=80=8B


>
>
>
> --
> Regards,
> RayH
>
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>

--089e01182fd047a90f05069135ba
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Wed, Oc=
t 29, 2014 at 8:05 AM, Ray Hunter <v6ops@globis.net> wrote:




Fred Baker (fred) wrote:



On Oct 28, 2014, at 11:28 PM, David Lamparter<equinox@diac24.net>=C2=A0 wrote:





What I'm personally wondering most in this regard is: to what extent
will larger networks deploy multiple prefixes to the hosts?





Well, define =E2=80=9Clarger=E2=80=9D. Any network that gets a PI prefix is=
 unlikely to deploy multiple prefixes. The question is at what size network=
 is makes sense to obtain an AS number and a PI prefix, and use BGP to talk=
 with one=E2=80=99s upstream.



I don't agree with this statement for the following reasons.



Availability: There are many enterprises that have very numerous far-flung =
sales-office type locations which do not host any critical data or applicat=
ions, but which could benefit from higher availability than that provided b=
y a single ISP provider (some of which are currently served by a specialise=
d box offering a Very Small Office Service running dual IPSec tunnels to a =
central site, which then performs the break out to the corporate intranet/I=
nternet)

=E2=80=8B
=E2=80=8B
=

=E2=80=8BAnd we are now de=
ploying home networks that are being used for home health medical monitorin=
g; having full fail-over to another ISP is in the process of becoming a &qu=
ot;life" issue=E2=80=8B.=C2=A0
=E2=80=8B
=E2=80=8B
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex">


Latency: There are many sites which could benefit from local Internet break=
out to regional cloud services, where you don't want to suffer the late=
ncy associated with a back haul from an office in Australia to a regional h=
ub in Hong Kong, or even East coast US to West coast US and back. You'd=
 still also want some back up via the central breakout if the local breakou=
t failed.



Cost: There are cost savings to be made in many countries where private net=
work services are still many orders of magnitude more expensive than plain =
old Internet. So Internet offload for non-mission-critical traffic can be v=
ery attractive. If you could achieve this via direct host-server connection=
s using address selection rules or multipath TCP; rather than via PBR, GRE =
tunnels + NAT, that would be a lot simpler.
=E2=80=8B






=C2=A0 Wherever that boundary is, below that networks will use PA prefixes.=
 The question then becomes: will they multi home?



And I think the answer today is that we don=E2=80=99t know the answer.



This I agree with.

=E2=80=8BDitto.=C2=A0 Though =
I have a personal opinion that they will... How else can you be able to tes=
t that things are actually going to "work" in the face of loss of=
 one ISP? Anything not being tested on an ongoing basis is unlikely to work=
 in the case of failure.=C2=A0 If availability really matters, you care...<=
/div>

Jim

=E2=80=8B
=
=C2=A0






-- 

Regards,

RayH




_______________________________________________

homenet mailing list

homenet@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/homenet





--089e01182fd047a90f05069135ba--


From nobody Wed Oct 29 08:16:20 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E297E1A01D5; Wed, 29 Oct 2014 08:16:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeBcZ7uHV32O; Wed, 29 Oct 2014 08:16:01 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B711A039B; Wed, 29 Oct 2014 08:15:51 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 37323203AA; Wed, 29 Oct 2014 11:17:08 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 8D7EE63A84; Wed, 29 Oct 2014 11:15:49 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 77B3A63A21; Wed, 29 Oct 2014 11:15:49 -0400 (EDT)
From: Michael Richardson 
To: Laurent Ciavaglia 
In-Reply-To: <5450B98F.9060908@alcatel-lucent.com>
References: <544FF8FC.5090103@cisco.com> <54500C8F.5030104@gmail.com> <54501D28.4090908@gmail.com> <5450B98F.9060908@alcatel-lucent.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/u-l0BZiPMCU-jQJ19QgbOAdJCtw
Cc: Benoit Claise , homenet , "anima@ietf.org" , Rene Struik 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 15:16:05 -0000

--=-=-=


Laurent Ciavaglia  wrote:
    > I agree with Rene and Brian on the need to consider constrained networks.
    > However, I don't think that "professionally-managed networks" automatically
    > exclude such environments.

I would further say that the security work in 6tisch, which is aimed at
industrial networks is made possible because we are assuming a
professionally-managed LLN.

The mechanisms being discussed won't scale down to the home.

The important constraint of the constrained devices is not ram, cpu or stable
storage for ANIMA, but the lack of a VGA and USB connectors for the
monitor/mouse.  Routers usually share the same constraint.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBVFEEo4CLcPvd0N1lAQKDuggAgJGWDBG051HWhtKy21iyd7nvyFQJNTAP
QWllRV9ilmPfBu7hwM44YPH8pnCYaQfMwiA/DVAPCCvZYCwndaMbCJkKmyJ9p3XT
6F6W1AuADBDwE3sqO1ZoLql1gR7kKL0x5Hyw2Wv6X/894hKJ9ICGeqTK1aCNjsMK
ES3Yamr0v6wpvbtxQe+C2Q5HMh1rawVXjDk07sgZr+57G4Tc7974wQVnsPB25kWO
iii3G3GplTxrPGVaVLgi9QwEJKHYDoTXUqWbrA9DBS8kbkQYffZyARsHC4td8K7i
xj6HIV8jSaqNAY77IOVNJjJg4n9mMcBImKD+aoKMIUTZFOkpX61PPw==
=CgBk
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Wed Oct 29 08:47:05 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3843B1A044F; Wed, 29 Oct 2014 08:47:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWFI9uVv7RNE; Wed, 29 Oct 2014 08:46:52 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EB0B1A1A54; Wed, 29 Oct 2014 08:46:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3001; q=dns/txt; s=iport; t=1414597612; x=1415807212; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=zLnLnGQ6pQKjZYy9ckOFX87rpL4cT4gnygSVSNoXO+U=; b=SGZWmz2pRZfQ22LRK+eBN61xQJHedPMvU45U3j2QlCT4CkGcZYUncXL3 sCkcz1Tnsn78uR0zjCl+65uoGLCMG38+VOAn8s/RmD27zHUVqtlAhYkxA 1IPLfBiOGUaB24IQ569pEkcYoU2eVGOWvFOSBWff8rcIMIJ3SKyDxghBr s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArQEANkKUVStJssW/2dsb2JhbABcg2JYzhMHh1ACgTEBAQEBAX2EAgEBAQQBAQE1LwcKDQQLEQQBAQoWCAcJAwIBAgEVHwkIBgEMBgIBARAHiCYNx0oBAQEBAQEBAQEBAQEBAQEBAQEBAQETBJEQBoRFAQSWVYcTgTGDSYJ0jkqDeTwvAQEBAYJHAQEB
X-IronPort-AV: E=Sophos;i="5.04,810,1406592000"; d="scan'208";a="229784855"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 29 Oct 2014 15:46:49 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9TFknkP024452; Wed, 29 Oct 2014 15:46:49 GMT
Message-ID: <54510BE9.3090101@cisco.com>
Date: Wed, 29 Oct 2014 16:46:49 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Linda Dunbar , "anima@ietf.org" ,  "homenet@ietf.org" 
References: <544FF8FC.5090103@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645E25359@dfweml701-chm>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645E25359@dfweml701-chm>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/qV15bbQYUKyT9vQphHig5WIJxgM
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 15:47:02 -0000

Hi Linda,
> Beniot,
>
> Is "professionally-managed networks" same as "network service provider network"?
It was intended to say: as opposed to just plug-and-play.
This could be a managed service offered by a ISP, gas meters service in 
a city, etc.

Regards, B.
>
> Linda
>
> -----Original Message-----
> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Benoit Claise
> Sent: Tuesday, October 28, 2014 3:14 PM
> To: anima@ietf.org; homenet@ietf.org
> Subject: [Anima] ANIMA scope + homenet interaction + charter v15
>
> Dear all,
>
> [sorry for double-posting, but we need the specific feedback from the HOMENET community]
>
> 1. scope
> I finished reading the ANIMA mailing list and, based on the feedback, Joel, Ted, and I would like to clarify the ANIMA scope for "the set of specific reusable infrastructure components that support autonomic interactions between devices" (quoting the charter)
>
> The charter currently mentions:
>       The ANIMA working group will initially focus on enterprise, ISP networks and IoT.
>
> Multiple tracks were discussed on the mailing list.
>       * keep enterprise, ISP networks and IoT
>       * focus on enterprise and ISP networks
>       * everything, but the initial focus is enterprise and carrier?
>       * professionally-managed networks
>
> It seems to us that "professionally-managed networks" is what ANIMA is after. And it's potentially a distraction to try to segment the scope based on enterprise, ISP, homenet, or IoT. What is IoT after all?
>
> OLD:     The ANIMA working group will initially focus on enterprise, ISP
> networks and IoT.
> NEW:    The ANIMA working group focuses on professionally-managed networks.
>
> Does it sound about right?
>
> 2. Overlap with HOMENET
> This distinction in point 1 might help regarding the potential overlap of the solution for distributed IPv6 prefix management.
> Btw, the new charter has been adapted:
> OLD:  A solution for distributed IPv6 prefix management within a network.
> NEW: the solution for distributed IPv6 prefix management within a large-scale network
>
> Also, The HOMENET collaboration has been stressed in the charter.
>
> 3. Others
> I believe I took care of the others changes proposed on the mailing. If this is not the case, let me know.
> At this point in time, please provide concrete change to the charter text if some issues persist.
> Charter v15 has just been posted, and you can review the detailed changes at https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-15.txt
>
>
> 4. Security Advisor.
> I have requested one for ANIMA to the security ADs.
>
> Regards, Benoit
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> .
>


From nobody Wed Oct 29 09:09:23 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1EF21A1AEB; Wed, 29 Oct 2014 09:09:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.511
X-Spam-Level: 
X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fV0VKRLMommJ; Wed, 29 Oct 2014 09:09:17 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEAF51A1A4E; Wed, 29 Oct 2014 09:09:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5723; q=dns/txt; s=iport; t=1414598957; x=1415808557; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2QWzecaPC0eydHgZPn18j4Gr7oDQQYS737TOKLAGrK0=; b=kz3HBi9szpE+yv8QcBxK3qV+dh4PfmLF+cPgE4ruRv77mcWm+wBthS9m Rp6pU7hoi/sgeE7uwGnZSfc4xp3d7rComa8JBhluxNZSTQAJESUw5EuFZ i2EThMeH8fiU847tP9gKtkmR+OBClVKJanb19gpbUzv/g7GW4J3mgR5SW Q=;
X-Files: signature.asc : 195
X-IronPort-AV: E=Sophos;i="5.04,810,1406592000";  d="asc'?scan'208";a="367613256"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 29 Oct 2014 16:09:15 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9TG9F93026139 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 16:09:15 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.248]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 11:09:15 -0500
From: "Fred Baker (fred)" 
To: Ray Hunter 
Thread-Topic: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
Thread-Index: AQHP7KYr8Fy7zf5Z70yFtC9ToRE4KA==
Date: Wed, 29 Oct 2014 16:09:15 +0000
Message-ID: 
References: <20141020204033.GD236844@jupiter.n2.diac24.net> <20141022190653.GB868521@jupiter.n2.diac24.net>   <544FF3F2.3050206@gmail.com> <20141029062837.GH5186@eidolon>  <5450D7ED.9010806@globis.net>
In-Reply-To: <5450D7ED.9010806@globis.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.19.64.120]
Content-Type: multipart/signed; boundary="Apple-Mail=_6D616973-B317-4DAA-9C1D-B9051EFAA046"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/KjNj8u07fmZtqRF_AtdkKLsRHeg
Cc: Ole Troan , "homenet@ietf.org" , "rtgwg@ietf.org" , Mikael Abrahamsson , David Lamparter 
Subject: Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 16:09:20 -0000

--Apple-Mail=_6D616973-B317-4DAA-9C1D-B9051EFAA046
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Oct 29, 2014, at 5:05 AM, Ray Hunter  wrote:

>=20
>=20
> Fred Baker (fred) wrote:
>> On Oct 28, 2014, at 11:28 PM, David Lamparter  =
wrote:
>>=20
>>> What I'm personally wondering most in this regard is: to what extent
>>> will larger networks deploy multiple prefixes to the hosts?
>>=20
>> Well, define =93larger=94. Any network that gets a PI prefix is =
unlikely to deploy multiple prefixes. The question is at what size =
network is makes sense to obtain an AS number and a PI prefix, and use =
BGP to talk with one=92s upstream.
>=20
> I don't agree with this statement for the following reasons.
>=20
> Availability: There are many enterprises that have very numerous =
far-flung sales-office type locations which do not host any critical =
data or applications, but which could benefit from higher availability =
than that provided by a single ISP provider (some of which are currently =
served by a specialised box offering a Very Small Office Service running =
dual IPSec tunnels to a central site, which then performs the break out =
to the corporate intranet/Internet)
>=20
> Latency: There are many sites which could benefit from local Internet =
breakout to regional cloud services, where you don't want to suffer the =
latency associated with a back haul from an office in Australia to a =
regional hub in Hong Kong, or even East coast US to West coast US and =
back. You'd still also want some back up via the central breakout if the =
local breakout failed.
>=20
> Cost: There are cost savings to be made in many countries where =
private network services are still many orders of magnitude more =
expensive than plain old Internet. So Internet offload for =
non-mission-critical traffic can be very attractive. If you could =
achieve this via direct host-server connections using address selection =
rules or multipath TCP; rather than via PBR, GRE tunnels + NAT, that =
would be a lot simpler.

I have a hunch we=92re talking past each other. We would agree, but =
we=92re discussing different cases. I was discussing a case in which a =
company operates a single addressing plan. I think you=92re discussing a =
company that operates multiple addressing plans, one for each of several =
locations.

Cisco might be an example of a =93larger=94 company. We have an IPv6 =
/32, more locations than you can shake a stick at, and maybe 20 DMZs, =
places where our network interconnects with the Internet. I don=92t know =
exactly what we advertise or where, but I could imagine that a few of =
our DMZs advertise the /32 and each of our DMZs advertises a /40, or =
something along that line. For us, PI is =93duh, obvious=94, and the =
only case in which we might - *might* - have a second prefix would be a =
ULA in a lab.

I suspect the company you are discussing might have a number of small =
offices in as many cities, and as many PA prefixes as it takes. The =
company might also have a PI prefix, but I would be surprised if it used =
the PI prefix in all of its little offices; if it did, it would =
essentially use it for internal traffic, and have some sort of VPN =
connecting the offices on which it was used. It would, however, use the =
PA prefixes from the offices when they need to talk outside the house. =
If it is using the PI prefix plus a PA prefix in any given office, it =
would depend on RFC 6724=92s Rule 8 (longest match) to prefer a PI =
address when talking to another address within the prefix, and a =
temporary address from PA space otherwise.

In any event, in the context of my comment above, I am thinking of the =
many small offices as separate networks. They don=92t justify their own =
PI spaces; the PI in context acts more like PA from the central =
corporation than PI in the traditional sense of the term. They might =
well get PA from one or more ISPs, and they might have something akin to =
PA from their central office or whatever.

Coming back to the question - =93would they put multiple subnet prefixes =
on any given LAN=94 - the question really comes back to their =
requirements and stomach for complexity. If they require multihoming, =
such as Jim suggests, I would hope they would do that. Among my =93NAT =
=3D=3D Security=94 customers and SEs, getting them there requires their =
network to work well (egress routing being one of many important parts =
of that), and a good security solution that doesn=92t involve NAT. Until =
they have one AND they are convinced, they tell us that the lack of a =
NAT solution is a reason to delay deployment. I don=92t think that last =
is about the number of prefixes around; it=92s about security policy and =
mindset.

>>  Wherever that boundary is, below that networks will use PA prefixes. =
The question then becomes: will they multi home?
>>=20
>> And I think the answer today is that we don=92t know the answer.
>=20
> This I agree with.
>=20
>=20
> --=20
> Regards,
> RayH
>=20


--Apple-Mail=_6D616973-B317-4DAA-9C1D-B9051EFAA046
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iD8DBQFUUREhbjEdbHIsm0MRAjvPAKDV09l2avuGVLDfwVF56b1rxWovfwCfZGGH
PXoegO/XxUeMdkj69FwYTDc=
=Tn9I
-----END PGP SIGNATURE-----

--Apple-Mail=_6D616973-B317-4DAA-9C1D-B9051EFAA046--


From nobody Wed Oct 29 09:16:53 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9A11A01FA; Wed, 29 Oct 2014 09:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-862JQ2QXvL; Wed, 29 Oct 2014 09:16:40 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA171A1B44; Wed, 29 Oct 2014 09:16:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19229; q=dns/txt; s=iport; t=1414599399; x=1415808999; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=BA3J05Eoo09UE4L8zaPUuq2HYCyPOJKp49fROpGI4mY=; b=AVmV6/C/BZbv1xpgKl9noTE9MZb09mp0NUBMffhJVedAWBdPm8DfWQuI e0IS+yagW8tig9XLGKnWZ1SGkCizPikK3HsdH1qNxjysKSs6E8KUalWSs sQEAhbCzq3Clzw9t9XJbLrGcBcRZXX/xsFjj4Kgxtz9Nf1APOnoOo00kw 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aq4EAOgRUVStJssW/2dsb2JhbABcgkiBGljOGwEGhnxUAoExAQEBAQF9hAIBAQEDAQEBAWQHCgEFCQILGAkWCAcJAwIBAgEJDB8RBgEMAQUCAQEFCweIHQkNx18BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBJAqEAIBIywGAYRLBY4pgUWGaYcTgTGDSoJ0jlGDeTwvAQEBAYJHAQEB
X-IronPort-AV: E=Sophos;i="5.04,810,1406592000";  d="scan'208,217";a="225049581"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 29 Oct 2014 16:16:36 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9TGGaEe017075; Wed, 29 Oct 2014 16:16:36 GMT
Message-ID: <545112E4.1010700@cisco.com>
Date: Wed, 29 Oct 2014 17:16:36 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Laurent Ciavaglia , Brian E Carpenter , Rene Struik 
References: <544FF8FC.5090103@cisco.com> <54500C8F.5030104@gmail.com> <54501D28.4090908@gmail.com> <5450B98F.9060908@alcatel-lucent.com>
In-Reply-To: <5450B98F.9060908@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="------------030205040509040700080208"
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/8j1MY6px7REF4cxmm2mxm_CZE0U
Cc: homenet , "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 16:16:43 -0000

This is a multi-part message in MIME format.
--------------030205040509040700080208
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit


> Dear all,
>
> I agree with Rene and Brian on the need to consider constrained networks.
> However, I don't think that "professionally-managed networks" 
> automatically exclude such environments.
>
> As Barbara S. mentioned in 
> http://www.ietf.org/mail-archive/web/homenet/current/msg04008.html, 
> there can be multiple scenarios with different roles, and different 
> devices being managed.
Exactly.

Regards, Benoit
>
> My opinion is that covering the scenario of professionally-managed 
> consrained (and less constrained) networks is a challenging one, from 
> which we could derive "good" common, re-usable protocols/components.
>
> Best regards, Laurent.
>
>
> On 28/10/2014 23:48, Brian E Carpenter wrote:
>> On 29/10/2014 10:37, Rene Struik wrote:
>>> Hi Benoit:
>>>
>>> -1 on you suggestion #1.
>>>
>>> I do not think suggesting "constrained networks and devices" to be
>>> suddenly out of scope helps: it is one of the main areas where
>>> semi-automatic management is imperative.
>> Rene has a point. My +1 was with the idea of limiting the initially
>> worked-out use cases, and avoiding any direct interference with
>> progress in homenet. But understanding the requirements for
>> constrained networks is desirable. What I don't know is whether
>> those requirements can in fact be met by the same infrastructure
>> components that we need for "professionally managed" networks.
>> There may simply not be enough overlap between "nimble and
>> heterogeneous" and "managed and homogeneous."
>>
>>     Brian
>>
>> If one has a bootstrapping
>>> solution and configuration negotiation/synchronization protocol that is
>>> not useful in constrained settings, what is the point? In my mind, it
>>> seems much more prudent to design schemes with constrained networks and
>>> devices and failure recovery models that apply there (configuration
>>> mismatch due to sleepy devices, malfunctioning data store, etc.), where
>>> these would then obviously also fit the less constrained,
>>> "professionally managed" networks. Design for the"nimble", so that both
>>> "nimble" and "fatter" networks can use this.
>>>
>>> This also has the advantage that one is forced to think in terms of many
>>> potential actors, rather than a few ones, which helps in viewing
>>> solutions in terms of heterogeneous rather than homogeneous deployment
>>> models.
>>>
>>> I have done all my reviews of nmrg drafts
>>> (http://www.ietf.org/mail-archive/web/anima/current/msg00327.html) with
>>> constrained networks and devices in mind. It would be a shame if one
>>> would now narrow down the focus and rule this (future almost ubiquitous)
>>> deployment category out of scope.
>>>
>>> Or, is this a political ploy, so as to avoid a turf war with homenet
>>> people?
>>>
>>> If that is the case, it would be much more prudent to have another BoF
>>> to iron out some of these issues. {This may be prudent for reasons I
>>> already indicated in the same #00327 message as well - I will  not
>>> repeat those arguments here.}
>>>
>>> Best regards, Rene
>>>
>>> On 10/28/2014 4:13 PM, Benoit Claise wrote:
>>>> Dear all,
>>>>
>>>> [sorry for double-posting, but we need the specific feedback from the
>>>> HOMENET community]
>>>>
>>>> 1. scope
>>>> I finished reading the ANIMA mailing list and, based on the feedback,
>>>> Joel, Ted, and I would like to clarify the ANIMA scope for "the set of
>>>> specific reusable infrastructure components that support autonomic
>>>> interactions between devices" (quoting the charter)
>>>>
>>>> The charter currently mentions:
>>>>      The ANIMA working group will initially focus on enterprise, ISP
>>>> networks and IoT.
>>>>
>>>> Multiple tracks were discussed on the mailing list.
>>>>      * keep enterprise, ISP networks and IoT
>>>>      * focus on enterprise and ISP networks
>>>>      * everything, but the initial focus is enterprise and carrier?
>>>>      * professionally-managed networks
>>>>
>>>> It seems to us that "professionally-managed networks" is what ANIMA is
>>>> after. And it's potentially a distraction to try to segment the scope
>>>> based on enterprise, ISP, homenet, or IoT. What is IoT after all?
>>>>
>>>> OLD:     The ANIMA working group will initially focus on enterprise,
>>>> ISP networks and IoT.
>>>> NEW:    The ANIMA working group focuses on professionally-managed
>>>> networks.
>>>>
>>>> Does it sound about right?
>>>>
>>>> 2. Overlap with HOMENET
>>>> This distinction in point 1 might help regarding the potential overlap
>>>> of the solution for distributed IPv6 prefix management.
>>>> Btw, the new charter has been adapted:
>>>> OLD:  A solution for distributed IPv6 prefix management within a network.
>>>> NEW: the solution for distributed IPv6 prefix management within a
>>>> large-scale network
>>>>
>>>> Also, The HOMENET collaboration has been stressed in the charter.
>>>>
>>>> 3. Others
>>>> I believe I took care of the others changes proposed on the mailing.
>>>> If this is not the case, let me know.
>>>> At this point in time, please provide concrete change to the charter
>>>> text if some issues persist.
>>>> Charter v15 has just been posted, and you can review the detailed
>>>> changes at
>>>> https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-15.txt
>>>>
>>>>
>>>>
>>>> 4. Security Advisor.
>>>> I have requested one for ANIMA to the security ADs.
>>>>
>>>> Regards, Benoit
>>>>
>>>> _______________________________________________
>>>> homenet mailing list
>>>> homenet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/homenet
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
>>
>
> -- 
>
> Bien cordialement, Best regards,
>
> *Laurent Ciavaglia*
>
> Advanced Internet Research
>
> Bell Labs | Alcatel Lucent
>
> phone: +33 160 402 636
>
> email: laurent.ciavaglia@alcatel-lucent.com 
> 
>
> linkedin: laurentciavaglia 
>
> address: Route de Villejust | 91620 Nozay | France
>


--------------030205040509040700080208
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

      
      Dear all,

        

        I agree with Rene and Brian on the need to consider constrained
        networks.

        However, I don't think that "professionally-managed networks"
        automatically exclude such environments.

        

        As Barbara S. mentioned in http://www.ietf.org/mail-archive/web/homenet/current/msg04008.html,
        there can be multiple scenarios with different roles, and
        different devices being managed.

      

    Exactly.

    

    Regards, Benoit
    
 

        My opinion is that covering the scenario of
        professionally-managed consrained (and less constrained)
        networks is a challenging one, from which we could derive "good"
        common, re-usable protocols/components.

        

        Best regards, Laurent.

        

        

      
      
On 28/10/2014 23:48, Brian E
        Carpenter wrote:

      

      

        
On 29/10/2014 10:37, Rene Struik wrote:


        

          
Hi Benoit:

-1 on you suggestion #1.

I do not think suggesting "constrained networks and devices" to be
suddenly out of scope helps: it is one of the main areas where
semi-automatic management is imperative. 


        

        
Rene has a point. My +1 was with the idea of limiting the initially
worked-out use cases, and avoiding any direct interference with
progress in homenet. But understanding the requirements for
constrained networks is desirable. What I don't know is whether
those requirements can in fact be met by the same infrastructure
components that we need for "professionally managed" networks.
There may simply not be enough overlap between "nimble and
heterogeneous" and "managed and homogeneous."

   Brian

If one has a bootstrapping


        

          
solution and configuration negotiation/synchronization protocol that is
not useful in constrained settings, what is the point? In my mind, it
seems much more prudent to design schemes with constrained networks and
devices and failure recovery models that apply there (configuration
mismatch due to sleepy devices, malfunctioning data store, etc.), where
these would then obviously also fit the less constrained,
"professionally managed" networks. Design for the"nimble", so that both
"nimble" and "fatter" networks can use this.

This also has the advantage that one is forced to think in terms of many
potential actors, rather than a few ones, which helps in viewing
solutions in terms of heterogeneous rather than homogeneous deployment
models.

I have done all my reviews of nmrg drafts
(http://www.ietf.org/mail-archive/web/anima/current/msg00327.html) with
constrained networks and devices in mind. It would be a shame if one
would now narrow down the focus and rule this (future almost ubiquitous)
deployment category out of scope.

Or, is this a political ploy, so as to avoid a turf war with homenet
people?

If that is the case, it would be much more prudent to have another BoF
to iron out some of these issues. {This may be prudent for reasons I
already indicated in the same #00327 message as well - I will  not
repeat those arguments here.}

Best regards, Rene

On 10/28/2014 4:13 PM, Benoit Claise wrote:


          

            
Dear all,

[sorry for double-posting, but we need the specific feedback from the
HOMENET community]

1. scope
I finished reading the ANIMA mailing list and, based on the feedback,
Joel, Ted, and I would like to clarify the ANIMA scope for "the set of
specific reusable infrastructure components that support autonomic
interactions between devices" (quoting the charter)

The charter currently mentions:
    The ANIMA working group will initially focus on enterprise, ISP
networks and IoT.

Multiple tracks were discussed on the mailing list.
    * keep enterprise, ISP networks and IoT
    * focus on enterprise and ISP networks
    * everything, but the initial focus is enterprise and carrier?
    * professionally-managed networks

It seems to us that "professionally-managed networks" is what ANIMA is
after. And it's potentially a distraction to try to segment the scope
based on enterprise, ISP, homenet, or IoT. What is IoT after all?

OLD:     The ANIMA working group will initially focus on enterprise,
ISP networks and IoT.
NEW:    The ANIMA working group focuses on professionally-managed
networks.

Does it sound about right?

2. Overlap with HOMENET
This distinction in point 1 might help regarding the potential overlap
of the solution for distributed IPv6 prefix management.
Btw, the new charter has been adapted:
OLD:  A solution for distributed IPv6 prefix management within a network.
NEW: the solution for distributed IPv6 prefix management within a
large-scale network

Also, The HOMENET collaboration has been stressed in the charter.

3. Others
I believe I took care of the others changes proposed on the mailing.
If this is not the case, let me know.
At this point in time, please provide concrete change to the charter
text if some issues persist.
Charter v15 has just been posted, and you can review the detailed
changes at
https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-15.txt



4. Security Advisor.
I have requested one for ANIMA to the security ADs.

Regards, Benoit

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


          

          

        

        
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima



      

      

      
-- 

        
        
        

          
Bien cordialement, Best
              regards,

          
 

          
Laurent Ciavaglia

          
Advanced
              Internet Research

          
Bell Labs |
              Alcatel Lucent

          
 

          
phone: +33 160 402 636 

          
email: laurent.ciavaglia@alcatel-lucent.com

          
linkedin: laurentciavaglia

          
address: Route de
              Villejust | 91620 Nozay | France

        

      

    

    

  


--------------030205040509040700080208--


From nobody Wed Oct 29 11:04:44 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912FF1A874B; Wed, 29 Oct 2014 11:04:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUtq3msCzs82; Wed, 29 Oct 2014 11:04:38 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5C7A1A871F; Wed, 29 Oct 2014 11:04:37 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9128A2002D; Wed, 29 Oct 2014 14:05:55 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 8966063A84; Wed, 29 Oct 2014 14:04:36 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7260063A80; Wed, 29 Oct 2014 14:04:36 -0400 (EDT)
From: Michael Richardson 
To: Benoit Claise 
In-Reply-To: <544FF8FC.5090103@cisco.com>
References: <544FF8FC.5090103@cisco.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Mal6exymCewSBjgtRPKPZosapSc
Cc: homenet@ietf.org, "anima@ietf.org" 
Subject: Re: [homenet] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 18:04:41 -0000

--=-=-=


Benoit Claise  wrote:
    > [sorry for double-posting, but we need the specific feedback from the HOMENET
    > community]

    > 1. scope
    > I finished reading the ANIMA mailing list and, based on the feedback, Joel,
    > Ted, and I would like to clarify the ANIMA scope for "the set of specific
    > reusable infrastructure components that support autonomic interactions
    > between devices" (quoting the charter)

    > The charter currently mentions:
    > The ANIMA working group will initially focus on enterprise, ISP networks
    > and IoT.

    > Multiple tracks were discussed on the mailing list.
    > * keep enterprise, ISP networks and IoT
    > * focus on enterprise and ISP networks
    > * everything, but the initial focus is enterprise and carrier?
    > * professionally-managed networks

    > It seems to us that "professionally-managed networks" is what ANIMA is
    > after. And it's potentially a distraction to try to segment the scope based
    > on enterprise, ISP, homenet, or IoT. What is IoT after all?

(I came to this thread backwards, sorry)
I agree with this change. +1000.
This gets EXACTLY gets to the point.

    > 4. Security Advisor.
    > I have requested one for ANIMA to the security ADs.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBVFEsMYCLcPvd0N1lAQIwmQf+KlEhlRcJhy/Ok9o4BSHiYIO2vIdbNrfJ
gYXYm8JMo0Zr7ZgqIFCX3KfV6wCkOo6TEurHNIU1zOzmfOOop+ITSSXKDyFNzg82
YgLWFqgZcsOiIaqgU0wAZwCdBR49k60r/eU2Z7HQwj1CcTrXC6W2N+FM66vXc3sS
A7y4MXAnIsMeOpY7DfRNPIQmJegD+/ABBE2nthwm4dCZ+Z3xXJzmPjLM0YJDMzqz
eURTi3BO+7eiGqzD8dNu7TE6ysQ9kVY2cCwap4hlVkKUBjcJqrdxfZ9b76pXJYmo
/XlNjkEpxxempMV3X/1xUmuoD5HL/RHV6Zxnnov2zkddgYqUSz4MLg==
=oArr
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Wed Oct 29 11:24:19 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566821A87AC; Wed, 29 Oct 2014 11:24:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcUACjvWqkD4; Wed, 29 Oct 2014 11:24:12 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C721A879D; Wed, 29 Oct 2014 11:24:05 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 19429203AA; Wed, 29 Oct 2014 14:25:23 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 1077263A84; Wed, 29 Oct 2014 14:24:03 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EE45763A80; Wed, 29 Oct 2014 14:24:03 -0400 (EDT)
From: Michael Richardson 
To: Tim Chown 
In-Reply-To: 
References: <20141020204033.GD236844@jupiter.n2.diac24.net> <20141022190653.GB868521@jupiter.n2.diac24.net>  <5C2EFB4E-925B-4252-BE58-894F9C061EA7@ecs.soton.ac.uk> 
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/jLdnCG-3K3ggXCs7wwhFIPfdtVk
Cc: David Lamparter , "homenet@ietf.org" , "rtgwg@ietf.org" , "Fred Baker \(fred\)" , Mikael Abrahamsson 
Subject: Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 18:24:13 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Tim Chown  wrote:
    > Homenet has =E2=80=98designed in=E2=80=99 future multihoming, which i=
s rare today. In
    > the homenet case the multihoming may presumably be more commonly for
    > different services to the home?

It's true that real multihoming (in the home...) is rare.

There are a multitude of off-the-shelf SOHO routers which support multiple
uplinks via NAPT.  I have setup this kind of thing up for a few dozen
friends' companies over the years... usually via a cablemodel + DSL (from
different suppliers) because we are protecting from a combination of
backhaul events and "customer service".

All of the downtime I've seen in the past ten years in my home office has
been due to "initiatives" from "customer service".

So I am very happy with the features that we have built-in, and I think with
the growth of 3G we will see additional mechanisms.

=2D-
Michael Richardson , Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBVFEwwYCLcPvd0N1lAQIIKwf+LnZM+0xNjgNjM0D81a6fQOgFa6n9ngC0
dULmlZsGioBJCCgRaedBuk2U3icRSY7YSBr4+dGOqZLLr1QRoIDf5kb2VIs11Mww
UBHjJw33l7Zlpw53zJodzDnUvR9zeoXgwgtmeV4imIwVXJ2TqBSPLUsSlqfQYiTh
4eo1Vxjr1lPstYhr5ZsvAZqDeQtNlyoA4B+H2Y1rkOH60i6NIY8A/zxeFg3BrLU6
Aj2rn+ycBY6c26nya77unoFBHY2hUySbP091eZp7TjgYkBjxNS/ndHPECwyCN/b+
IiKtjf88wlBaxbTvZ4CKNwNnOxH631N/meTs3YY5ZD7AqSkzQFU4OA==
=Vl4a
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Wed Oct 29 11:26:40 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AC01A873E for ; Wed, 29 Oct 2014 11:26:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.383
X-Spam-Level: 
X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_24=0.6, J_CHICKENPOX_61=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1gqi6NMGiFH for ; Wed, 29 Oct 2014 11:26:37 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853F31A0117 for ; Wed, 29 Oct 2014 11:26:36 -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 s9TIQWtX023015; Wed, 29 Oct 2014 19:26:32 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6B51520A426; Wed, 29 Oct 2014 19:28:09 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5D84220A41F; Wed, 29 Oct 2014 19:28:09 +0100 (CET)
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 s9TIQBQU011404; Wed, 29 Oct 2014 19:26:32 +0100
Message-ID: <54513143.2070004@gmail.com>
Date: Wed, 29 Oct 2014 19:26:11 +0100
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Pierre Pfister 
References:  <54350D62.5050706@gmail.com> <048F40EB-A1D5-4D70-986B-9DDE55FF7C22@darou.fr> <543526D9.2020107@gmail.com> <54352A62.2040605@gmail.com> <4BCB9E4C-31F2-4769-A994-32F58490BD2B@darou.fr>
In-Reply-To: <4BCB9E4C-31F2-4769-A994-32F58490BD2B@darou.fr>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/b1tP4QwG2uV4zc-gPhvrkOXEHDQ
Cc: homenet@ietf.org
Subject: Re: [homenet] on prefix comparison
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 18:26:39 -0000

Hi Pierre,

I took some time to understand the code.

But here is what I would like to say.

Your algorithm decides whether or not one prefix collides with another, 
by comparing prefix/plen pairs according to an exact match rule.

On another hand, the forwarding towards these prefixes is realized by 
longest-prefix match rule applied to an address against successive 
entries in a routing table.  By this rule an address/128 matches the 
first one entry whose prefix length is longest, if several; and default 
otherwise.

If one hears two prefix/plen pairs in RAs and decides they 'collide' by 
the exact match rule implemented by the code below then one may decide 
this is a bad configuration situation.  At the same time the forwarding 
may be set up ok, because it uses the longest-prefix match rule, not 
exact match, and has a default to escape to as well.

This is why I am saying that any method to compare prefixes may not be 
agreed on, may not lead to effective results, unless designed according 
to the rules used for forwarding.

Yours,

Alex



Le 08/10/2014 14:25, Pierre Pfister a écrit :
> A prefix can only contain another prefix if its prefix length is smaller.
>
> Here is some C-code that provides what you are looking for.
>
> Cheers,
>
> - Pierre
>
>
> /* Tell whether a prefix contains an address */
> uint8_t prefix_contains(const struct in6_addr *p, uint8_t plen, const struct in6_addr *addr)
> {
> 	int blen = plen >> 3;
> 	if(blen && memcmp(p, addr, blen))
> 		return 0;
>
> 	int rem = plen & 0x07;
> 	if(rem && ((p->s6_addr[blen] ^ addr->s6_addr[blen]) >> (8 - rem)))
> 		return 0;
>
> 	return 1;
> }
>
> /* Tell whether a prefix contains another prefix */
> uint8_t prefix_include(const struct in6_addr *p1, uint8_t plen1, const struct in6_addr *p2, uint8_t plen2)
> {
> 	if(plen1 > plen2)
> 		return 0;
> 	
> 	return prefix_contains(p1, plen1, p2);
> }
>
> /* Tell whether two prefixes are colliding */
> uint8_t prefix_collision(const struct in6_addr *p1, uint8_t plen1, const struct in6_addr *p2, uint8_t plen2)
> {
> 	return prefix_include(p1, plen1, p2, plen2) || prefix_include(p2, plen2, p1, plen1);
> }
>
>
> Le 8 oct. 2014 ŕ 14:13, Alexandru Petrescu  a écrit :
>
>> Pierre, just a small doubt, but I agree with you in general.
>>
>> Le 08/10/2014 13:58, Alexandru Petrescu a écrit :
>> [...]
>>>> Equality is never considered alone. Actually, most of the time, you
>>>> will find considerations such as: The prefix is not included or does
>>>> not include any other Assigned Prefix with a higher precedence.
>>
>> It is hard to say whether a prefix is included into another or not.  We do not have a published algorithm to say what it means for a prefix to include another.
>>
>> In general, we have a common understanding (and not published algorithm) about what it means 'longest prefix match'.  But that compares an address to a prefix, not a prefix to a prefix.
>>
>> Sure, one could assume that an address is just a /128 prefix and execute longest prefix match with it as if it were an address.
>>
>> But then again which prefix has the role of the address and which is the role of the prefix?  In other words, when hearing two prefixes on a link and want to compare them, which of them should be compared against the other by using the longest-prefix match?  There are two possibilities and two different outputs for a particular tuple of prefixes, depending on the order of this longest prefix match.
>>
>> Of course, I do not mention the easy case which compares two prefixes of precisely same length.
>>
>> Just because the length is different may make think that the prefixes are different.  Or otherwise one could be aggregated into another.  But there are several types of aggregation: matching up to the shortest length, matching up to middle, up to longest length, beyond the longest length.
>>
>> These cases are not documented and people may implement them in many different ways with different outputs when trying to tell whether this or that prefix are equal or included into one another.
>>
>> Alex
>>
>>
>
>
>



From nobody Wed Oct 29 17:39:43 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF891ACE84; Wed, 29 Oct 2014 17:39:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7mUoPCyNoKy; Wed, 29 Oct 2014 17:39:40 -0700 (PDT)
Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a02:238:f02a:8e2f:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1784A1ACE81; Wed, 29 Oct 2014 17:39:39 -0700 (PDT)
Received: from equinox by eidolon.nox.tf with local (Exim 4.84) (envelope-from ) id 1Xjdm1-000DwA-SK; Thu, 30 Oct 2014 01:39:34 +0100
Date: Thu, 30 Oct 2014 01:39:33 +0100
From: David Lamparter 
To: "Fred Baker (fred)" 
Message-ID: <20141030003933.GS5186@eidolon>
References: <20141020204033.GD236844@jupiter.n2.diac24.net> <20141022190653.GB868521@jupiter.n2.diac24.net>   <544FF3F2.3050206@gmail.com> <20141029062837.GH5186@eidolon>  <5450D7ED.9010806@globis.net> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.5.22 (2013-10-16)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/8gTXAeMgl0H27hrS_cbPsRwqN2s
Cc: Ole Troan , Ray Hunter , David Lamparter , "homenet@ietf.org" , "rtgwg@ietf.org" , Mikael Abrahamsson 
Subject: Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 00:39:42 -0000

[plucking a paragraph from the middle]
On Wed, Oct 29, 2014 at 04:09:15PM +0000, Fred Baker (fred) wrote:
> I suspect the company you are discussing might have a number of small
> offices in as many cities, and as many PA prefixes as it takes. The
> company might also have a PI prefix, but I would be surprised if it
> used the PI prefix in all of its little offices; if it did, it would
> essentially use it for internal traffic, and have some sort of VPN
> connecting the offices on which it was used. It would, however, use
> the PA prefixes from the offices when they need to talk outside the
> house. If it is using the PI prefix plus a PA prefix in any given
> office, it would depend on RFC 6724’s Rule 8 (longest match) to prefer
> a PI address when talking to another address within the prefix, and a
> temporary address from PA space otherwise.

If there is an overlap of a company-wide numbering plan with local
connectivity, that might actually be use-case for a SADR route whose
destination isn't ::/0.  Though you could always do that with a simple
destination route for the company-wide prefix, what you can now do is
signal the correlations between routes.  (Except we don't have a
protocol to communicate this to the host yet.)

I'm imagining a route table like this:
(:cccc: being the company-wide PI)

::/0 from 2001:db8:1::/48 via PA-provider-1
::/0 from 2001:db8:2::/48 via PA-provider-2
::/0 from 2001:db8:cccc::/48 unreachable
2001:db8:cccc::/48 from 2001:db8:cccc::/48 via IPsec-gateway
2001:db8:cccc::/48 from ::/0 unreachable

Where the last route would prevent accidental leaking of packets onto
the internet in case the IPsec gateway malfunctions.  (The 3rd route is
redundant if there's no "::/0 from ::/0")

But - apart from ease of use for multiple prefixes, this can be done
without SADR just fine, the only advantage is that there's full
information regarding which source addresses work with which
destinations.  If we get that to hosts, and into their source address
selection, then we won something.

(And this is really the same as homenet walled-garden scenarios, where
an ISP uses a separate prefix for some [IPTV, whatever] service and
expects clients to use a distinct source prefix to get to that service.
Then again, "secret gardens are better than walled gardens.")


-David


From nobody Wed Oct 29 20:50:57 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED071ACFFB; Wed, 29 Oct 2014 20:50:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIsQ5bnqdu-D; Wed, 29 Oct 2014 20:50:51 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7D0F1ACFFA; Wed, 29 Oct 2014 20:50:51 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id rd18so4263350iec.7 for ; Wed, 29 Oct 2014 20:50:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=H7iOSqW9Ri32Sl+HXHj8W1QC4ZHZrv/o12X0UQkGMXg=; b=oVY2lvsk7arkcFHl4/rKzPsFQYdGaqpDtFcFQh8guqQ83/eZHbrWlFfCeQasrsdpt1 +UYxZ+3fITdZZBz8aXkajenRDig+NmSDmqyZaWiSV7W7rjH4Nqi2Rc/qrO4XNnTC2qRI FuNnZb+sfzVUmq8pqEeZoKhdot2NaoOu2HNqTc64WpVXFjIm0vXuZHfmV1n3iJnfdIvl SY67yHZdkA+lPTtgFBlr0fVOW4lBVf5SsXQu25QyKdCYTxjxqSuayDGklNigBBIUYDMh T7+mGbDjk+zzwgrFJpByQpavIQEL4vHza5/K7VdbzEcHrqwYArX5O3lJ8J7a1fcWoPcT iC/w==
X-Received: by 10.107.148.200 with SMTP id w191mr16413847iod.28.1414641051100;  Wed, 29 Oct 2014 20:50:51 -0700 (PDT)
Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id qp8sm1250497igb.15.2014.10.29.20.50.50 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 20:50:50 -0700 (PDT)
Message-ID: <5451B594.8090305@gmail.com>
Date: Wed, 29 Oct 2014 23:50:44 -0400
From: Rene Struik 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Brian E Carpenter 
References: <544FF8FC.5090103@cisco.com> <54500C8F.5030104@gmail.com> <54501D28.4090908@gmail.com>
In-Reply-To: <54501D28.4090908@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/UkyRs7L1ITgxc9BOIVR78_ib4LE
Cc: Benoit Claise , homenet , "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 03:50:54 -0000

Hi Brian:

It is very puzzling to me to see essential deployments that would be a 
test case on viability of the concept of semi-automatic management (in 
casu: constrained networks and devices) being removed from the charter. 
I have not seen any technical justification for ruling this out of order 
(nor do I know who decides on this - consensus?).

If one emphasizes so much the "professionally managed" aspect, this 
seems to suggest that whatever "solution" Anima (or, perhaps, simply the 
co-authors of the three anima drafts mentioned in the draft charter?) 
have in mind may not meet or closely approximate the whole idea of 
"autonous" operation (at least, as I understand this after reading all 
drafts referred to in the draft charter and producing 15 pages of 
comments on this).

I, for one, think we can minimize these differences and define an 
architecture and a set of protocols that mostly only differ in policy 
and configuration settings for "professionally managed" and "highly 
constrained devices and networks". I think I have made this point in my 
extensive comments.

I am happy to make this concrete once the group meets during IETF-91, 
but certainly already declaring things out of order without accompanying 
technical discussion and analysis, effectively stymies this.

During IETF-91, I think we need to spend much more time on discussing 
draft-irtf-nmrg-an-gap-analysis and 
draft-irtf-nmrg-autonomic-network-definitions-04, since improving those 
seem to attack the festering chartering problems at the heart. I would 
happily volunteer elaborating on this during the two Anima meeting slots.

Best regards, Rene

On 10/28/2014 6:48 PM, Brian E Carpenter wrote:
> On 29/10/2014 10:37, Rene Struik wrote:
>> Hi Benoit:
>>
>> -1 on you suggestion #1.
>>
>> I do not think suggesting "constrained networks and devices" to be
>> suddenly out of scope helps: it is one of the main areas where
>> semi-automatic management is imperative.
> Rene has a point. My +1 was with the idea of limiting the initially
> worked-out use cases, and avoiding any direct interference with
> progress in homenet. But understanding the requirements for
> constrained networks is desirable. What I don't know is whether
> those requirements can in fact be met by the same infrastructure
> components that we need for "professionally managed" networks.
> There may simply not be enough overlap between "nimble and
> heterogeneous" and "managed and homogeneous."
>
>     Brian
>
> If one has a bootstrapping
>> solution and configuration negotiation/synchronization protocol that is
>> not useful in constrained settings, what is the point? In my mind, it
>> seems much more prudent to design schemes with constrained networks and
>> devices and failure recovery models that apply there (configuration
>> mismatch due to sleepy devices, malfunctioning data store, etc.), where
>> these would then obviously also fit the less constrained,
>> "professionally managed" networks. Design for the"nimble", so that both
>> "nimble" and "fatter" networks can use this.
>>
>> This also has the advantage that one is forced to think in terms of many
>> potential actors, rather than a few ones, which helps in viewing
>> solutions in terms of heterogeneous rather than homogeneous deployment
>> models.
>>
>> I have done all my reviews of nmrg drafts
>> (http://www.ietf.org/mail-archive/web/anima/current/msg00327.html) with
>> constrained networks and devices in mind. It would be a shame if one
>> would now narrow down the focus and rule this (future almost ubiquitous)
>> deployment category out of scope.
>>
>> Or, is this a political ploy, so as to avoid a turf war with homenet
>> people?
>>
>> If that is the case, it would be much more prudent to have another BoF
>> to iron out some of these issues. {This may be prudent for reasons I
>> already indicated in the same #00327 message as well - I will  not
>> repeat those arguments here.}
>>
>> Best regards, Rene
>>
>> On 10/28/2014 4:13 PM, Benoit Claise wrote:
>>> Dear all,
>>>
>>> [sorry for double-posting, but we need the specific feedback from the
>>> HOMENET community]
>>>
>>> 1. scope
>>> I finished reading the ANIMA mailing list and, based on the feedback,
>>> Joel, Ted, and I would like to clarify the ANIMA scope for "the set of
>>> specific reusable infrastructure components that support autonomic
>>> interactions between devices" (quoting the charter)
>>>
>>> The charter currently mentions:
>>>      The ANIMA working group will initially focus on enterprise, ISP
>>> networks and IoT.
>>>
>>> Multiple tracks were discussed on the mailing list.
>>>      * keep enterprise, ISP networks and IoT
>>>      * focus on enterprise and ISP networks
>>>      * everything, but the initial focus is enterprise and carrier?
>>>      * professionally-managed networks
>>>
>>> It seems to us that "professionally-managed networks" is what ANIMA is
>>> after. And it's potentially a distraction to try to segment the scope
>>> based on enterprise, ISP, homenet, or IoT. What is IoT after all?
>>>
>>> OLD:     The ANIMA working group will initially focus on enterprise,
>>> ISP networks and IoT.
>>> NEW:    The ANIMA working group focuses on professionally-managed
>>> networks.
>>>
>>> Does it sound about right?
>>>
>>> 2. Overlap with HOMENET
>>> This distinction in point 1 might help regarding the potential overlap
>>> of the solution for distributed IPv6 prefix management.
>>> Btw, the new charter has been adapted:
>>> OLD:  A solution for distributed IPv6 prefix management within a network.
>>> NEW: the solution for distributed IPv6 prefix management within a
>>> large-scale network
>>>
>>> Also, The HOMENET collaboration has been stressed in the charter.
>>>
>>> 3. Others
>>> I believe I took care of the others changes proposed on the mailing.
>>> If this is not the case, let me know.
>>> At this point in time, please provide concrete change to the charter
>>> text if some issues persist.
>>> Charter v15 has just been posted, and you can review the detailed
>>> changes at
>>> https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-15.txt
>>>
>>>
>>>
>>> 4. Security Advisor.
>>> I have requested one for ANIMA to the security ADs.
>>>
>>> Regards, Benoit
>>>
>>> _______________________________________________
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>>


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


From nobody Thu Oct 30 00:29:36 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100131AD029; Thu, 30 Oct 2014 00:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbRK3OBWm19U; Thu, 30 Oct 2014 00:29:33 -0700 (PDT)
Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7551AD036; Thu, 30 Oct 2014 00:29:33 -0700 (PDT)
Received: from [192.168.10.30] (cm-84.215.22.20.getinternet.no [84.215.22.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 37F4F62C4; Thu, 30 Oct 2014 00:29:32 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Ole Troan 
In-Reply-To: <20141030003933.GS5186@eidolon>
Date: Thu, 30 Oct 2014 08:29:37 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20141020204033.GD236844@jupiter.n2.diac24.net> <20141022190653.GB868521@jupiter.n2.diac24.net>   <544FF3F2.3050206@gmail.com> <20141029062837.GH5186@eidolon>  <5450D7ED.9010806@globis.net>  <20141030003933.GS5186@eidolon>
To: David Lamparter 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/JsC7cXyeK2k7QiCcI2ZCEcE0ymw
Cc: Ray Hunter , "homenet@ietf.org" , Mikael Abrahamsson , "Fred Baker \(fred\)" , "rtgwg@ietf.org" 
Subject: Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 07:29:35 -0000

David,

> ::/0 from 2001:db8:1::/48 via PA-provider-1
> ::/0 from 2001:db8:2::/48 via PA-provider-2
> ::/0 from 2001:db8:cccc::/48 unreachable
> 2001:db8:cccc::/48 from 2001:db8:cccc::/48 via IPsec-gateway
> 2001:db8:cccc::/48 from ::/0 unreachable
>=20
> Where the last route would prevent accidental leaking of packets onto
> the internet in case the IPsec gateway malfunctions.  (The 3rd route =
is
> redundant if there's no "::/0 from ::/0")
>=20
> But - apart from ease of use for multiple prefixes, this can be done
> without SADR just fine, the only advantage is that there's full
> information regarding which source addresses work with which
> destinations.  If we get that to hosts, and into their source address
> selection, then we won something.

in a simple triangle topology:

   |            |
CE1      CE2
  \             /
   \           /
       IR1
         |
-----------------
   |
 Host

with PA1 and PA2 doing BCP38 filtering and a non SADR capable network, I =
would assert that you cannot do this without SADR.
IR1 load balances, and you could end up in a situation where IR1 load =
balancing would pick CE1 exit for PA2 source address, and CE2 exit for =
PA1 source address. with the result that whatever the host tried to do, =
all traffic would be black-holed by the ISP ingress filters.

with regards to getting SAS policies into hosts, that isn't necessary =
for the multi-homed to congruent networks case. it is needed in the =
walled garden cases (but there are some many other issues with walled =
gardens that I'm not sure the IETF should try to fix a broken business =
model). we do have a DHCP option already to configure a host's SAS table =
for this purpose. RFC7078.

cheers,
Ole


From nobody Thu Oct 30 02:08:10 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12881ACFE1; Thu, 30 Oct 2014 02:08:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7J7O311s9KE; Thu, 30 Oct 2014 02:08:08 -0700 (PDT)
Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.194]) by ietfa.amsl.com (Postfix) with ESMTP id C22871A6FC6; Thu, 30 Oct 2014 02:08:07 -0700 (PDT)
Received: from poro.lan (80.220.64.126) by jenni2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 543C16C90161454A; Thu, 30 Oct 2014 11:08:02 +0200
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Markus Stenberg 
In-Reply-To: <544FF8FC.5090103@cisco.com>
Date: Thu, 30 Oct 2014 11:08:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi>
References: <544FF8FC.5090103@cisco.com>
To: Benoit Claise 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/oBI5ehPwcnDE_HBhNxtozO9gNYY
Cc: homenet@ietf.org, Markus Stenberg , "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 09:08:09 -0000

On 28.10.2014, at 22.13, Benoit Claise  wrote:
> 1. scope
> OLD:     The ANIMA working group will initially focus on enterprise, =
ISP networks and IoT.
> NEW:    The ANIMA working group focuses on professionally-managed =
networks.

+1. This is what I was trying to get earlier (but apparently just =
dropping IoT did not describe it fully due to potentially managed IoT =
networks too; I am too stuck in my home IoT rut I guess).

> Does it sound about right?
> 2. Overlap with HOMENET
> This distinction in point 1 might help regarding the potential overlap =
of the solution for distributed IPv6 prefix management.
> Btw, the new charter has been adapted:
> OLD:  A solution for distributed IPv6 prefix management within a =
network.
> NEW: the solution for distributed IPv6 prefix management within a =
large-scale network

I would personally rather drop prefix management. At least, the current =
proposed solution is DHCPv6 PD plus lot of marketing plus one extra =
thing (role) minus tons of existing functionality. I would rather stick =
the role into PD, than reinvent the protocol.

If there is not something more novel there (that is, not hierarchical PD =
in disguise), I do not see the point.

> Also, The HOMENET collaboration has been stressed in the charter.
>=20
> 3. Others
> I believe I took care of the others changes proposed on the mailing. =
If this is not the case, let me know.
> At this point in time, please provide concrete change to the charter =
text if some issues persist.
> Charter v15 has just been posted, and you can review the detailed =
changes at =
https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fd=
oc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.txt&difftype=3D--html&submi=
t=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-ani=
ma%2Fwithmilestones-00-15.txt

I think it is mostly fine, although the use of term =91autonomous=92 for =
essentially (on high level) managed devices that perform some low-level =
autonomic functions sounds still strange to me. I guess I could live =
with it though.

Cheers,

-Markus



From nobody Thu Oct 30 05:00:09 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0261AD0A9; Thu, 30 Oct 2014 05:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdBRSbpHvlkd; Thu, 30 Oct 2014 05:00:05 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFAE1A0007; Thu, 30 Oct 2014 05:00:05 -0700 (PDT)
Received: from [10.0.20.107] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id 47300238004A; Thu, 30 Oct 2014 08:00:03 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi>
Date: Thu, 30 Oct 2014 08:00:01 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <62A56FF8-EA71-4559-8929-0A03FA7785F9@fugue.com>
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi>
To: Markus Stenberg 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/XG5coWqH7M7ppczYNo7dg0FTlYM
Cc: Benoit Claise , homenet@ietf.org, "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 12:00:07 -0000

On Oct 30, 2014, at 5:08 AM, Markus Stenberg  =
wrote:
> I would personally rather drop prefix management. At least, the =
current proposed solution is DHCPv6 PD plus lot of marketing plus one =
extra thing (role) minus tons of existing functionality. I would rather =
stick the role into PD, than reinvent the protocol.

Hierarchical PD doesn't work or even make sense.   Flow-through PD does, =
but hasn't been described in an RFC: there is no mechanism for =
autonomously configuring the relay structure or installing routes.   So =
I think it's appropriate to do this work in ANIMA (I know there is no =
enthusiasm for it in homenet).   Or, if that turns out to be an =
inadequate solution, to do something else.


From nobody Thu Oct 30 05:08:44 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC081A000B; Thu, 30 Oct 2014 05:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.778
X-Spam-Level: 
X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGaSTj8Sz2pL; Thu, 30 Oct 2014 05:08:34 -0700 (PDT)
Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.194]) by ietfa.amsl.com (Postfix) with ESMTP id 54C361A0008; Thu, 30 Oct 2014 05:08:27 -0700 (PDT)
Received: from poro.lan (80.220.64.126) by kirsi1.inet.fi (8.5.142.08) (authenticated as stenma-47) id 5425273602F01B41; Thu, 30 Oct 2014 14:08:17 +0200
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Markus Stenberg 
In-Reply-To: <62A56FF8-EA71-4559-8929-0A03FA7785F9@fugue.com>
Date: Thu, 30 Oct 2014 14:08:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3743B3C2-D8F2-45C5-85F5-C53B18739FB3@iki.fi>
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <62A56FF8-EA71-4559-8929-0A03FA7785F9@fugue.com>
To: Ted Lemon 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ruPRYmK0kokTjEMQeqTH8WE_Kos
Cc: Benoit Claise , homenet@ietf.org, Markus Stenberg , "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 12:08:36 -0000

On 30.10.2014, at 14.00, Ted Lemon  wrote:
> On Oct 30, 2014, at 5:08 AM, Markus Stenberg  =
wrote:
>> I would personally rather drop prefix management. At least, the =
current proposed solution is DHCPv6 PD plus lot of marketing plus one =
extra thing (role) minus tons of existing functionality. I would rather =
stick the role into PD, than reinvent the protocol.
> Hierarchical PD doesn't work or even make sense.   Flow-through PD =
does, but hasn't been described in an RFC: there is no mechanism for =
autonomously configuring the relay structure or installing routes.   So =
I think it's appropriate to do this work in ANIMA (I know there is no =
enthusiasm for it in homenet).   Or, if that turns out to be an =
inadequate solution, to do something else.

I hope someone tells that to Cablelabs, I thought eRouter spec had =
hierarchical PD (=3Dhipnet).

ANIMA=92s current solution[1] does not seem to deal with autonomously =
configuring the delegation hierarchy, or routes in general at all =
currently.

What does flow-through PD mean? Do you have any reference on that?

Cheers,

-Markus

[1] http://tools.ietf.org/html/draft-jiang-anima-prefix-management-00=


From nobody Thu Oct 30 06:05:00 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC3B1AD0D6; Thu, 30 Oct 2014 06:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAMCTVjXcnSe; Thu, 30 Oct 2014 06:04:58 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0281F1AD0BC; Thu, 30 Oct 2014 06:04:58 -0700 (PDT)
Received: from [10.0.20.107] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id 51A67238004A; Thu, 30 Oct 2014 09:04:56 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <3743B3C2-D8F2-45C5-85F5-C53B18739FB3@iki.fi>
Date: Thu, 30 Oct 2014 09:04:53 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <10925F8D-D2FB-4E96-B4CC-5C6F9158FE3C@fugue.com>
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <62A56FF8-EA71-4559-8929-0A03FA7785F9@fugue.com> <3743B3C2-D8F2-45C5-85F5-C53B18739FB3@iki.fi>
To: Markus Stenberg 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/IwTZShbfHHhuDlvPimO-nnNv2_U
Cc: Benoit Claise , homenet@ietf.org, "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 13:04:59 -0000

On Oct 30, 2014, at 8:08 AM, Markus Stenberg  =
wrote:
> What does flow-through PD mean? Do you have any reference on that?

It means that the edge router has the delegation, and then sub-delegates =
individual /64s from the pool of /64s it was delegated by the ISP, =
rather than splitting its delegation and delegating chunks of that =
delegation to downstream routers which will then delegate in turn.   In =
order for this to work, downstream routers have to relay PD requests to =
the edge router, and install routes to the delegated prefixes.   =
Something analogous could work on an autonomous network; I don't know =
that it's the right way to solve the problem, but it's certainly one way =
to solve the problem.   Homenet went with HNCP because it's more =
sensitive to arbitrary topology changes.

The hierarchical model doesn't work because it doesn't anticipate new =
routers being added to the network, and doesn't account for unbalanced =
topologies.   I thought the hipnet proposal wound up going with the =
flow-through model, not the hierarchical model, but I may be mistaken.


From nobody Thu Oct 30 06:15:28 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3421A0053; Thu, 30 Oct 2014 06:15:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUQXXLiE7Lsx; Thu, 30 Oct 2014 06:15:24 -0700 (PDT)
Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1F7C1A0024; Thu, 30 Oct 2014 06:15:23 -0700 (PDT)
Received: from [192.168.10.30] (cm-84.215.22.20.getinternet.no [84.215.22.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 2A0D762A6; Thu, 30 Oct 2014 06:15:21 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Ole Troan 
In-Reply-To: <10925F8D-D2FB-4E96-B4CC-5C6F9158FE3C@fugue.com>
Date: Thu, 30 Oct 2014 14:15:17 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A07B58F-9CDE-434D-9770-494D030312B6@cisco.com>
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <62A56FF8-EA71-4559-8929-0A03FA7785F9@fugue.com> <3743B3C2-D8F2-45C5-85F5-C53B18739FB3@iki.fi> <10925F8D-D2FB-4E96-B4CC-5C6F9158FE3C@fugue.com>
To: Ted Lemon 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/6OfZk-cgOTolOuLvmCqCLQS-SYw
Cc: Benoit Claise , homenet@ietf.org, Markus Stenberg , "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 13:15:27 -0000

>> What does flow-through PD mean? Do you have any reference on that?
>=20
> It means that the edge router has the delegation, and then =
sub-delegates individual /64s from the pool of /64s it was delegated by =
the ISP, rather than splitting its delegation and delegating chunks of =
that delegation to downstream routers which will then delegate in turn.  =
 In order for this to work, downstream routers have to relay PD requests =
to the edge router, and install routes to the delegated prefixes.   =
Something analogous could work on an autonomous network; I don't know =
that it's the right way to solve the problem, but it's certainly one way =
to solve the problem.   Homenet went with HNCP because it's more =
sensitive to arbitrary topology changes.
>=20
> The hierarchical model doesn't work because it doesn't anticipate new =
routers being added to the network, and doesn't account for unbalanced =
topologies.   I thought the hipnet proposal wound up going with the =
flow-through model, not the hierarchical model, but I may be mistaken.

I think the homenet wg did a good of analysing the 3 variants proposed.
the "flow-through" model as far as I can recall suffers from DHCP's =
general problem of dealing with multiple sources of information (think =
multihoming with separate CE routers), in addition you either need to =
build what's essentially a spanning tree of DHCP relays or you need some =
mechanism to discover the set of DHCP server(s). certainly do-able, but =
not quite out of the box.

cheers,
Ole=


From nobody Thu Oct 30 06:26:44 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5B81A0053; Thu, 30 Oct 2014 06:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VX5jIjBCK3M; Thu, 30 Oct 2014 06:26:37 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id C564B1AD0B3; Thu, 30 Oct 2014 06:26:37 -0700 (PDT)
Received: from [10.0.20.107] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id 48F11238004A; Thu, 30 Oct 2014 09:26:36 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <0A07B58F-9CDE-434D-9770-494D030312B6@cisco.com>
Date: Thu, 30 Oct 2014 09:26:33 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D83DBA5-D5D5-411E-A9BE-6231BEB129F8@fugue.com>
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <62A56FF8-EA71-4559-8929-0A03FA7785F9@fugue.com> <3743B3C2-D8F2-45C5-85F5-C53B18739FB3@iki.fi> <10925F8D-D2FB-4E96-B4CC-5C6F9158FE3C@fugue.com> <0A07B58F-9CDE-434D-9770-494D030312B6@cisco.com>
To: Ole Troan 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/dy7LP55SL3UREq1eysVwF1Fi1Js
Cc: Benoit Claise , homenet@ietf.org, Markus Stenberg , "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 13:26:39 -0000

On Oct 30, 2014, at 9:15 AM, Ole Troan  wrote:
> the "flow-through" model as far as I can recall suffers from DHCP's =
general problem of dealing with multiple sources of information (think =
multihoming with separate CE routers), in addition you either need to =
build what's essentially a spanning tree of DHCP relays or you need some =
mechanism to discover the set of DHCP server(s). certainly do-able, but =
not quite out of the box.

Actually it doesn't suffer from this problem.   You just wind up getting =
a prefix delegation per edge router, and when you get a delegation, you =
add that edge router to the list of routers to which you will relay =
downstream prefix delegation requests.   You do not need spanning tree =
because if you reach the same router through two different paths, you =
will just get the same delegation twice per DUID/IAID.

The reason homenet didn't go with this solution is essentially that HNCP =
has a better feature set and is easier to make work in a homenet =
environment.

(To be clear, I am just explaining the prefix delegation model.   If =
Anima doesn't want to do it that way, that's fine with me, just as it's =
fine with me that homenet went with HNCP.)


From nobody Thu Oct 30 06:28:57 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315E11AD1FE for ; Thu, 30 Oct 2014 06:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjT_HOPky8Ga for ; Thu, 30 Oct 2014 06:28:50 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181E71AD0BC for ; Thu, 30 Oct 2014 06:28:50 -0700 (PDT)
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 11d32545.0.6447097.00-2372.18107209.nbfkord-smmo06.seg.att.com (envelope-from );  Thu, 30 Oct 2014 13:28:50 +0000 (UTC)
X-MXL-Hash: 54523d1229cea8c6-e6d5e45881a4fbaaec83806186efb5bf74fba59c
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9UDSm86014312 for ; Thu, 30 Oct 2014 09:28:49 -0400
Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9UDSgjJ014174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 30 Oct 2014 09:28:42 -0400
Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi133.aldc.att.com (RSA Interceptor) for ; Thu, 30 Oct 2014 13:28:29 GMT
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.152]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0195.001; Thu, 30 Oct 2014 09:28:28 -0400
From: "STARK, BARBARA H" 
To: "homenet@ietf.org" 
Thread-Topic: [homenet] Comments requested for draft CER-ID: firewall behavior
Thread-Index: Ac/0RUCyor7Th21bQhK1aU4hrtViBQ==
Date: Thu, 30 Oct 2014 13:28:28 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E61130EA9855@GAALPA1MSGUSRBF.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.10.239.48]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=X9rl3hve c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=8RP7HBNDfBoA:10 a=BLceEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP]
X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=5abA1UBDzhpfjdjEDQUA:9 a=QE]
X-AnalysisOut: [XdDO2ut3YA:10]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.23]
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/YKXE0ANX4tH2VIo_GNZB-Z9SyK8
Subject: Re: [homenet] Comments requested for draft CER-ID: firewall behavior
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 13:28:53 -0000

T25lIG90aGVyIHRoaW5nIEkgZm9yZ290IHRvIG1lbnRpb24gYWJvdXQgZmlyZXdhbGxzIHZpcy3D
oC12aXMgdGhlIENFIHJvdXRlciwgaXMgdGhhdCBub3QgYWxsIENFIHJvdXRlcnMgaGF2ZSBmaXJl
d2FsbHMuDQoNClNvbWUgSVNQcyBwcm92aWRlIHRoZWlyIGN1c3RvbWVycyB3aXRoIGFuIG9wdGlv
biBvZiByZWNlaXZpbmcgYSAiYmFzaWMiIChzaW5nbGUgTEFOIEV0aGVybmV0IHBvcnQsIG5vIFdp
LUZpKSBDRSByb3V0ZXIgdGhhdCBoYXMgbm8gZmlyZXdhbGwuIFRoZSBleHBlY3RhdGlvbiBpcyB0
aGF0IG1vc3QgdXNlcnMgd2hvIGFyZSBhc2tpbmcgZm9yIHRoZXNlIHJvdXRlcnMgd2lsbCBwdXQg
dGhlaXIgb3duIHJvdXRlciBiZWhpbmQgdGhlIENFIHJvdXRlciwgYW5kIHRoaXMgdXNlci1zdXBw
bGllZCBpbnRlcmlvciByb3V0ZXIgKElSKSB3aWxsIGhhdmUgd2hhdGV2ZXIgZmlyZXdhbGwgdGhl
IHVzZXIgd2FudHMuDQogDQpUaGlzIHNjZW5hcmlvIGlzIHJlYWwgdG9kYXkuIEkgZG9uJ3QgdGhp
bmsgdGhlIENFUiBJRCBwcm9wb3NhbCB3b3VsZCBiZW5lZml0IGl0IGF0IGFsbC4gSWYgQ0VSIElE
IGJlaGF2aW9ycyB3ZXJlIGltcGxlbWVudGVkIGFzIHN1Z2dlc3RlZCBpbiB0aGUgZHJhZnQsIHRo
ZSByZXN1bHRzIHdvdWxkIGJlIHVuZGVzaXJhYmxlLiBMb29raW5nIGZyb20gaW5zaWRlIHRoZSBo
b21lIG5ldHdvcmssIHRoZSBJUiBpcyB0aGUgInJlYWwiIG91dGVyIGVkZ2Ugb2YgdGhlIGhvbWUg
bmV0d29yay4gTG9va2luZyBmcm9tIHRoZSBJU1AgbmV0d29yaywgdGhlIENFIHJvdXRlciBpcyB0
aGUgZWRnZS4gVGhlIEV0aGVybmV0IGxpbmsgaW4gYmV0d2VlbiBpcyBpbiBsaW1ibyBhbmQgb25s
eSBiZWNvbWVzIGltcG9ydGFudCB3aGVuIHRoZXJlIGFyZSBwcm9ibGVtcy4NCkJhcmJhcmENCg0K
W0FkZGl0aW9uYWwgaW5mbyBmb3IgdGhlIGN1cmlvdXM6IFRoZSBJU1AtcHJvdmlkZWQgQ0Ugcm91
dGVyIGlzIHJlc3BvbnNpYmxlIGZvciBhbGwgaW50ZXJhY3Rpb25zIHdpdGggdGhlIElTUCBuZXR3
b3JrIChhbGwgREhDUCwgUFBQb0UpLiBGb3IgSVB2NCwgdGhlIElTUC1wcm92aWRlZCByb3V0ZXIg
aGFzIGFuIElQIHBhc3N0aHJvdWdoIGZ1bmN0aW9uIHRoYXQgcHJvdmlkZXMgdGhlIGFjcXVpcmVk
IHB1YmxpYyBJUHY0IGFkZHJlc3MgdG8gdGhlIElSLCB3aGVuIHRoZSBJUiBkb2VzIGEgREhDUHY0
IHJlcXVlc3QgdG8gdGhlIENFIHJvdXRlci4gRm9yIElQdjYsIHRoZSBDRSByb3V0ZXIgc3ViLWRl
bGVnYXRlcyAoSUFfUEQpIGZyb20gdGhlIHByZWZpeCBpdCBnb3QgZnJvbSB0aGUgSVNQLiBZb3Ug
bWF5IHdvbmRlciB3aHkgYm90aGVyIHdpdGggYSByb3V0ZXI7IHdoeSBub3QganVzdCBwcm92aWRl
IGEgYnJpZGdlZCBtb2RlbT8gQnkgaGF2aW5nIGl0IGFzIGEgcm91dGVyLCB0aGUgZGV2aWNlIGlz
IG1hbmFnZWFibGUgKGl0IGNhbiBoYXZlIGl0cyBmaXJtd2FyZSB1cGRhdGVkLCBydW4gZGlhZ25v
c3RpY3MsIG1hbmFnZSBQUFBvRSBjcmVkZW50aWFscyB0aGF0IHVzZXJzIHN0cnVnZ2xlIHRvIHJl
bWVtYmVyLCBldGMuKSwgYW5kIHRyb3VibGVzaG9vdGluZyBpcyBzaW1wbGlmaWVkIGJlY2F1c2Ug
bW9zdCB1c2VycyBjYW4gZGlyZWN0bHkgY29ubmVjdCBhIFBDIHRvIHRoZSBJU1Atc3VwcGxpZWQg
cm91dGVyIHdoZW4gb24gYSBoZWxwIGRlc2sgY2FsbCAod2hpY2ggcmVzdWx0cyBpbiBzaG9ydGVy
IGhlbHAgZGVzayBjYWxscykuIEluIG90aGVyIHdvcmRzLCB0aGUgYmFzaWMgQ0Ugcm91dGVyIGhh
cyBzaWduaWZpY2FudGx5IGxvd2VyIG9wZXJhdGlvbmFsIGNvc3RzIHRoYW4gYSBicmlkZ2VkIG1v
ZGVtLl0NCg0K


From nobody Thu Oct 30 06:44:00 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB391AD371; Thu, 30 Oct 2014 06:43:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3MwdA89xpiS; Thu, 30 Oct 2014 06:43:50 -0700 (PDT)
Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2211A0126; Thu, 30 Oct 2014 06:43:50 -0700 (PDT)
Received: by mail-qg0-f43.google.com with SMTP id f51so3926906qge.2 for ; Thu, 30 Oct 2014 06:43:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rRHkjMkACu7UHdhqxuB4/Eg9h6lEl9CveV1zZ9NQYFY=; b=y+1uXZEN1SP+3OwXni1ZHbxQN+V21a1ehuple3W+L4KwUVgZYuYNsMqq3JcSvT4JH5 1egvWc66Mw1KmKWZ5pAsqZM2/Dgnr9YvvKlwBy7EWrsEoaj8t524nA4F7+21ILmcnrIC Kiho6pkO+MuT3ah0xRMkPJjbWzGp00ys9VgKfsV7/lzEGt4b9L7WqRAnIjYjYIkvpLpq jigRCxP6IAA7J7tyyuKUByEWcdh4dMvzS+CwFdDW3odCXO/IuV5aRm/J/7LZCFlsVIJO Z0J3FSIr2rgtSGpaUBY+FRA8qX9hFPgh/4GeDk/yu8kUqM9c/418lHdiEMidW5GPkDZx CTOw==
X-Received: by 10.224.124.67 with SMTP id t3mr26537169qar.20.1414676629484; Thu, 30 Oct 2014 06:43:49 -0700 (PDT)
Received: from [10.86.247.187] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id 9sm6745943qau.37.2014.10.30.06.43.47 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 06:43:48 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ralph Droms 
In-Reply-To: <4D83DBA5-D5D5-411E-A9BE-6231BEB129F8@fugue.com>
Date: Thu, 30 Oct 2014 09:43:50 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6D979919-07D7-49B4-B0CE-E21A64DEC78D@gmail.com>
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <62A56FF8-EA71-4559-8929-0A03FA7785F9@fugue.com> <3743B3C2-D8F2-45C5-85F5-C53B18739FB3@iki.fi> <10925F8D-D2FB-4E96-B4CC-5C6F9158FE3C@fugue.com> <0A07B58F-9CDE-434D-9770-494D030312B6@cisco.com> <4D83DBA5-D5D5-411E-A9BE-6231BEB129F8@fugue.com>
To: Ted Lemon , Ole Troan 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/dXCPPuGYwX3tLMiw_cKSkiSsYA4
Cc: Benoit Claise , HOMENET Working Group , Markus Stenberg , "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 13:43:52 -0000

On Oct 30, 2014, at 9:26 AM 10/30/14, Ted Lemon  =
wrote:

> On Oct 30, 2014, at 9:15 AM, Ole Troan  wrote:
>> the "flow-through" model as far as I can recall suffers from DHCP's =
general problem of dealing with multiple sources of information (think =
multihoming with separate CE routers), in addition you either need to =
build what's essentially a spanning tree of DHCP relays or you need some =
mechanism to discover the set of DHCP server(s). certainly do-able, but =
not quite out of the box.
>=20
> Actually it doesn't suffer from this problem.   You just wind up =
getting a prefix delegation per edge router, and when you get a =
delegation, you add that edge router to the list of routers to which you =
will relay downstream prefix delegation requests.   You do not need =
spanning tree because if you reach the same router through two different =
paths, you will just get the same delegation twice per DUID/IAID.

There may be a couple of areas where some small amount of protocol =
specification work would be required for the flow-through model:

* the requesting router would have to know to accept delegated prefixes =
from multiple delegating routers rather than just choosing one =
delegating router
* either each server would have to have its own set of relay agents, or =
a single set of relay agents would have to be provisioned dynamically =
with the list of delegating routers

- Ralph

>=20
> The reason homenet didn't go with this solution is essentially that =
HNCP has a better feature set and is easier to make work in a homenet =
environment.
>=20
> (To be clear, I am just explaining the prefix delegation model.   If =
Anima doesn't want to do it that way, that's fine with me, just as it's =
fine with me that homenet went with HNCP.)
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


From nobody Thu Oct 30 06:47:38 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEA51AD0BC; Thu, 30 Oct 2014 06:47:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5rayNhCcw6v; Thu, 30 Oct 2014 06:47:35 -0700 (PDT)
Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB651AD35C; Thu, 30 Oct 2014 06:47:30 -0700 (PDT)
Received: from [192.168.10.30] (cm-84.215.22.20.getinternet.no [84.215.22.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id C63C6612B; Thu, 30 Oct 2014 06:46:42 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Ole Troan 
In-Reply-To: <4D83DBA5-D5D5-411E-A9BE-6231BEB129F8@fugue.com>
Date: Thu, 30 Oct 2014 14:46:35 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <15219CEA-8A3B-48EC-B3DC-E70BB45C6859@cisco.com>
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <62A56FF8-EA71-4559-8929-0A03FA7785F9@fugue.com> <3743B3C2-D8F2-45C5-85F5-C53B18739FB3@iki.fi> <10925F8D-D2FB-4E96-B4CC-5C6F9158FE3C@fugue.com> <0A07B58F-9CDE-434D-9770-494D030312B6@cisco.com> <4D83DBA5-D5D5-411E-A9BE-6231BEB129F8@fugue.com>
To: Ted Lemon 
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/7ceUPSqWos6tPQfdBWcMBdGQcCQ
Cc: Benoit Claise , homenet@ietf.org, Markus Stenberg , "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 13:47:37 -0000

Ted,

>> the "flow-through" model as far as I can recall suffers from DHCP's =
general problem of dealing with multiple sources of information (think =
multihoming with separate CE routers), in addition you either need to =
build what's essentially a spanning tree of DHCP relays or you need some =
mechanism to discover the set of DHCP server(s). certainly do-able, but =
not quite out of the box.
>=20
> Actually it doesn't suffer from this problem.   You just wind up =
getting a prefix delegation per edge router, and when you get a =
delegation, you add that edge router to the list of routers to which you =
will relay downstream prefix delegation requests.   You do not need =
spanning tree because if you reach the same router through two different =
paths, you will just get the same delegation twice per DUID/IAID.
>=20
> The reason homenet didn't go with this solution is essentially that =
HNCP has a better feature set and is easier to make work in a homenet =
environment.
>=20
> (To be clear, I am just explaining the prefix delegation model.   If =
Anima doesn't want to do it that way, that's fine with me, just as it's =
fine with me that homenet went with HNCP.)
>=20

it isn't as obvious as you make it out to be. there is no point in us =
arguing over that here (we have had this exact argument previously), =
write a draft if you think the flow-through model is viable in a network =
with multiple edges and arbitrary topology.

cheers,
Ole=


From nobody Thu Oct 30 06:55:50 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1B31A0171 for ; Thu, 30 Oct 2014 06:55:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsDWf_KbanNk for ; Thu, 30 Oct 2014 06:55:44 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69EBA1A00E4 for ; Thu, 30 Oct 2014 06:55:44 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 69532203AF; Thu, 30 Oct 2014 09:57:05 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 9CFA263A84; Thu, 30 Oct 2014 09:55:43 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8938B63A21; Thu, 30 Oct 2014 09:55:43 -0400 (EDT)
From: Michael Richardson 
To: "STARK\, BARBARA H" 
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130EA9855@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <2D09D61DDFA73D4C884805CC7865E61130EA9855@GAALPA1MSGUSRBF.ITServices.sbc.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/uK-gZA9z75lAt-IJBvchEO_SAa4
Cc: "homenet@ietf.org" 
Subject: Re: [homenet] Comments requested for draft CER-ID: firewall behavior
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 13:55:46 -0000

--=-=-=


STARK, BARBARA H  wrote:
    > Some ISPs provide their customers with an option of receiving a "basic"
    > (single LAN Ethernet port, no Wi-Fi) CE router that has no
    > firewall. The expectation is that most users who are asking for these
    > routers will put their own router behind the CE router, and this
    > user-supplied interior router (IR) will have whatever firewall the user
    > wants.

    > [Additional info for the curious: The ISP-provided CE router is
    > responsible for all interactions with the ISP network (all DHCP,
    > PPPoE). For IPv4, the ISP-provided router has an IP passthrough
    > function that provides the acquired public IPv4 address to the IR, when
    > the IR does a DHCPv4 request to the CE router. For IPv6, the CE router
    > sub-delegates (IA_PD) from the prefix it got from the ISP. You may
    > wonder why bother with a router; why not just provide a bridged modem?

    > By having it as a router, the device is manageable (it can have its
    > firmware updated, run diagnostics, manage PPPoE credentials that users
    > struggle to remember, etc.), and troubleshooting is simplified because
    > most users can directly connect a PC to the ISP-supplied router when on
    > a help desk call (which results in shorter help desk calls). In other
    > words, the basic CE router has significantly lower operational costs
    > than a bridged modem.]

so this a real layer-3 device, and not just a layer-3 device with layer-3
turned off?  I've never seen such a thing.

And most of the devices I've seen have all of the management functions
(TR-079, etc.), which runs on a seperate "VLAN" (cable) or ?VC (DSL), and
leave the PPPoE to the "IR"

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBVFJDXICLcPvd0N1lAQK/DQf/Y6bIk9uxlYKsiYA1TnvCCROn2vYa2ESF
NlbzsiseBjyJAgvLB8nvoy9hFzo/p4KeklT6WiohDgXtSt0p+jZlHOoihrIV/QRq
ol/tx/+LZOaN0yOw4hkBQg7O1YIrMgM4Czddt/HI5kOFq3kf3qP+EmReV8T82W9u
TlvNZLFJoptsTzjahXr26rAdW6BjG22G6jJywLWoiPAN/b6LHubmyne9vqDj6W37
/0yVFQkBeCRo+lhWzV2lebS0RcXS5AojT7i5Px0JchC41GbASAoKjIB2mJ/2KVJn
9i7oGSO0xTwDsIrMO80Z6zS5X/XLjvEq0KjKoJUzjMTJPCOSUpE5QQ==
=mKa9
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Thu Oct 30 07:02:39 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF301AD0BC for ; Thu, 30 Oct 2014 07:02:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BZ90UOpNWYM for ; Thu, 30 Oct 2014 07:02:36 -0700 (PDT)
Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109991AD26E for ; Thu, 30 Oct 2014 07:01:26 -0700 (PDT)
Received: by mail-qa0-f48.google.com with SMTP id x12so3645453qac.7 for ; Thu, 30 Oct 2014 07:01:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=lxusHz27R4RT9PHw5yDbAjO7fLmNlH20PH8lyQ9o19c=; b=jpJCh9U5LZ8qT5pL/UFYGx/Rk55MOQIrWVtgf6Y569m0c0PzGcAIMR33PqyBOxF4/I xLCULTdC62saJuuoImTQByfrsfsJaBhTT37NwF09uFgAGsJdbTW+A2YqCSbFAbWrBi/V Udtgze0J7EA1JMgk4A1gGCitn6kgxuPdnucrY5KQLAeEB8vN1Hd3WOZztQSkSXM/NEcZ mlYJ4DcmktpT1dJcOKdmn+eSoG8xpWGSS2OXdbKn2okDMoemZ3PzpSgBz0rB1ltl/PwL 1AOgARmPdqdQXCv3oNgYIPFk9SgKTb8Oad/5y0dNcclEfKEtVynaa2ZGXpo/PIqTJKBy UHIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:content-type; bh=lxusHz27R4RT9PHw5yDbAjO7fLmNlH20PH8lyQ9o19c=; b=UgxvUw3BTvUHzxX46VxDXjY8Ip7jL+OjsAg4SA6SL17dTxCg8kWJsCCwqNi8Expc3b 8NlJdlIjf5Wijw6UI8HSpvaVjskRJc1aLhJ6BCGLG+ximaavI7viErBYnHRDVVeoVZfQ 1TaOTEuK2oMfyxMWUwVsbnrdVKx1DkT7jBB0Y6SloExbIM/71Ra3cT5zA4vRHGUa/AVC WePLrbfM/2y2WUciZk/ZpcsDdK7+k/YNjNQXgSFCTYyUAD0C1YEOUQA3kw7fOtKJ5o34 ApmX8ysV8+XU94d72Z/DjCxn7A9/y1ZF2igDyH/rb4hgX05EL4zrQGfpq6UC1WL9wDy2 eWLQ==
X-Gm-Message-State: ALoCoQnbgVpnrE5Tdpu3gDlhKmNoMAoZAcHu7LqHM+eyd7wigYlXAn9YSKtT0eOow3eMNnRZBuBw
X-Received: by 10.224.94.9 with SMTP id x9mr1355533qam.90.1414677684042; Thu, 30 Oct 2014 07:01:24 -0700 (PDT)
MIME-Version: 1.0
References: <2D09D61DDFA73D4C884805CC7865E61130EA9855@GAALPA1MSGUSRBF.ITServices.sbc.com>
From: Erik Kline 
Date: Thu, 30 Oct 2014 14:01:23 +0000
Message-ID: 
To: "STARK, BARBARA H" , "homenet@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7b673a84d45b9c0506a45022
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/UNy9wSIiJkEsPSWigCf1Qkrsj0k
Subject: Re: [homenet] Comments requested for draft CER-ID: firewall behavior
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 14:02:37 -0000

--047d7b673a84d45b9c0506a45022
Content-Type: text/plain; charset=UTF-8

>
> This scenario is real today. I don't think the CER ID proposal would
> benefit it at all. If CER ID behaviors were implemented as suggested in the
> draft, the results would be undesirable.
>

I think basically the issue is that the CER ID is fundamentally equivalent
to the not-evil bit, and therefore not remotely useful for security
purposes at all.

--047d7b673a84d45b9c0506a45022
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


This scenario is =
real today. I don't think the CER ID proposal would benefit it at all. =
If CER ID behaviors were implemented as suggested in the draft, the results=
 would be undesirable.

I think basicall=
y the issue is that the CER ID is fundamentally equivalent to the not-evil =
bit, and therefore not remotely useful for security purposes at all.=C2=A0<=
/div>


--047d7b673a84d45b9c0506a45022--


From nobody Thu Oct 30 12:31:34 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A381A1BEA; Thu, 30 Oct 2014 12:31:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzjsnehG-k6i; Thu, 30 Oct 2014 12:31:28 -0700 (PDT)
Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656FD1A1BCF; Thu, 30 Oct 2014 12:31:28 -0700 (PDT)
Received: by mail-pa0-f41.google.com with SMTP id rd3so6141409pab.0 for ; Thu, 30 Oct 2014 12:31:28 -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=Ucprvl5SuRkADzP77Mnnbklt2Gd6TEUi0kAIygvDEMM=; b=nk4U+llGRLItpCs68niBZlDZzlc8mKgUOe0VSWEF+6D8SYzlfL7h/IV390CL493vjC wF+g+2OVwojE2RzkoP5Q0F3nLd9bXNOwtUGW7+bH4i/R/Xo0srC3f61yVU0i4QXYFu3I X+iX8QOGDOT9wXI1r1SePZEb8SuS63HIvU709n/jalxUBMU5Zm6eOVgKiG3AgAdLyCVC 6zWg1Rio9nr5t6mfNSH0S5CH3NEvnxk+DP6M75QKDdsC1HIDk/1KiHb9XiC3HLzBSzrp A5n9FN6bhEGcHw6o0aDhXkYQy7ve4BlItqsO7kikIotj4dd4X+IOGa+4AMi/57mV9VUV Y3Dw==
X-Received: by 10.70.61.106 with SMTP id o10mr19353809pdr.96.1414697488035; Thu, 30 Oct 2014 12:31:28 -0700 (PDT)
Received: from [192.168.178.23] (18.200.69.111.dynamic.snap.net.nz. [111.69.200.18]) by mx.google.com with ESMTPSA id is15sm7824892pbd.87.2014.10.30.12.31.24 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 12:31:27 -0700 (PDT)
Message-ID: <54529215.9000701@gmail.com>
Date: Fri, 31 Oct 2014 08:31:33 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Markus Stenberg 
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi>
In-Reply-To: <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/oav2XMhAr4WuyST0fscP9kMfJHo
Cc: Benoit Claise , homenet@ietf.org, "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 19:31:30 -0000

On 30/10/2014 22:08, Markus Stenberg wrote:
> On 28.10.2014, at 22.13, Benoit Claise  wrote:
>> 1. scope
>> OLD:     The ANIMA working group will initially focus on enterprise, I=
SP networks and IoT.
>> NEW:    The ANIMA working group focuses on professionally-managed netw=
orks.
>=20
> +1. This is what I was trying to get earlier (but apparently just dropp=
ing IoT did not describe it fully due to potentially managed IoT networks=
 too; I am too stuck in my home IoT rut I guess).
>=20
>> Does it sound about right?
>> 2. Overlap with HOMENET
>> This distinction in point 1 might help regarding the potential overlap=
 of the solution for distributed IPv6 prefix management.
>> Btw, the new charter has been adapted:
>> OLD:  A solution for distributed IPv6 prefix management within a netwo=
rk.
>> NEW: the solution for distributed IPv6 prefix management within a larg=
e-scale network
>=20
> I would personally rather drop prefix management. At least, the current=
 proposed solution is DHCPv6 PD plus lot of marketing plus one extra thin=
g (role) minus tons of existing functionality. I would rather stick the r=
ole into PD, than reinvent the protocol.
>=20
> If there is not something more novel there (that is, not hierarchical P=
D in disguise), I do not see the point.

It is specifically not bound to be hierarchical. The idea is that peer de=
vices
can provide resource (IPv6 prefixes) to each other when one of them runs =
low,
and that is a specific use case for carriers. Perhaps it's badly explaine=
d.
It was chosen explicitly as a very simple but real use case. (There is a
more complex case which is sharing IPv4 resources between AFTRs but we
took that out to keep things simple.)

I don't understand what you mean about marketing.

    Brian

>> Also, The HOMENET collaboration has been stressed in the charter.
>>
>> 3. Others
>> I believe I took care of the others changes proposed on the mailing. I=
f this is not the case, let me know.
>> At this point in time, please provide concrete change to the charter t=
ext if some issues persist.
>> Charter v15 has just been posted, and you can review the detailed chan=
ges at https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf=
=2Eorg%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.txt&difftype=3D-=
-html&submit=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fchar=
ter-ietf-anima%2Fwithmilestones-00-15.txt
>=20
> I think it is mostly fine, although the use of term =E2=80=98autonomous=
=E2=80=99 for essentially (on high level) managed devices that perform so=
me low-level autonomic functions sounds still strange to me. I guess I co=
uld live with it though.
>=20
> Cheers,
>=20
> -Markus
>=20
>=20
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>=20


From nobody Thu Oct 30 12:43:19 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC32F1A1BC8; Thu, 30 Oct 2014 12:43:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkqcOVi0f7SN; Thu, 30 Oct 2014 12:43:14 -0700 (PDT)
Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5B01A1A3E; Thu, 30 Oct 2014 12:43:13 -0700 (PDT)
Received: by mail-pd0-f169.google.com with SMTP id y10so5816890pdj.0 for ; Thu, 30 Oct 2014 12:43:13 -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=wa5zItBXUfPckpuBXQNMHaBAuwPLrBuBqjbw9KHt+88=; b=T+fuyLg8kjrmqeJiRSShOI8loFISc5gZNeqZ/OqOCAJ2pMY5IIAbzePhmQskep4WRa 38z5591YzSczM9o1tBELqbefAJ+l9V6GQ702ofbQvflQDbF3euqkE2V8nfVojnYOayiX tQ/9ll4DKUMexIKkuDnLkfKLMK3NaeD+jITzzglPaW6TqDo0EVJAm09G7Qh6V/eeBgLw NnQ7qghmnxF+euwHqiTGwey5mnqOccTDW1FsvI/7Kdj4ZpV3ov/AFfqR45ALkUkYvdgZ fMEh4eLjfm4jn4jDj+84PKrh34MZUxKIQmdmBUMZLeab5JoRwJMsK5+KYMHdp/i89GVp myUQ==
X-Received: by 10.66.216.232 with SMTP id ot8mr19517901pac.19.1414698193612; Thu, 30 Oct 2014 12:43:13 -0700 (PDT)
Received: from [192.168.178.23] (18.200.69.111.dynamic.snap.net.nz. [111.69.200.18]) by mx.google.com with ESMTPSA id iu10sm7860384pbd.57.2014.10.30.12.43.10 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 12:43:12 -0700 (PDT)
Message-ID: <545294D6.9000002@gmail.com>
Date: Fri, 31 Oct 2014 08:43:18 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Rene Struik 
References: <544FF8FC.5090103@cisco.com> <54500C8F.5030104@gmail.com> <54501D28.4090908@gmail.com> <5451B594.8090305@gmail.com>
In-Reply-To: <5451B594.8090305@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/h6Dx0fj5X0sFSqMMH7_noW9Bxzw
Cc: Benoit Claise , homenet , "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 19:43:16 -0000

Rene,


On 30/10/2014 16:50, Rene Struik wrote:
> Hi Brian:
> 
> It is very puzzling to me to see essential deployments that would be a
> test case on viability of the concept of semi-automatic management (in
> casu: constrained networks and devices) being removed from the charter.
> I have not seen any technical justification for ruling this out of order
> (nor do I know who decides on this - consensus?).

Well, it's technically the IESG that charters WGs but they do always
look for rough consensus. However, I don't believe the new wording excludes
IOT, it simply doesn't mention it.

> If one emphasizes so much the "professionally managed" aspect, this
> seems to suggest that whatever "solution" Anima (or, perhaps, simply the
> co-authors of the three anima drafts mentioned in the draft charter?)
> have in mind may not meet or closely approximate the whole idea of
> "autonous" operation (at least, as I understand this after reading all
> drafts referred to in the draft charter and producing 15 pages of
> comments on this).
> 
> I, for one, think we can minimize these differences and define an
> architecture and a set of protocols that mostly only differ in policy
> and configuration settings for "professionally managed" and "highly
> constrained devices and networks". I think I have made this point in my
> extensive comments.

I would be happy with that result. I am interpreting "professionally
managed" very liberally, but it does seem to me that things like
building services networks are both highly constrained and professionally
managed.

> I am happy to make this concrete once the group meets during IETF-91,
> but certainly already declaring things out of order without accompanying
> technical discussion and analysis, effectively stymies this.
> 
> During IETF-91, I think we need to spend much more time on discussing
> draft-irtf-nmrg-an-gap-analysis and
> draft-irtf-nmrg-autonomic-network-definitions-04, 

Unfortunately the NMRG, which "owns" those documents, has chosen
not to meet at the IETF site. Your comments were closely studied
during the most recent revision of both drafts. The result is of course
a compromise between the authors' views and yours.

   Brian


From nobody Thu Oct 30 13:45:56 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0591A86E8 for ; Thu, 30 Oct 2014 13:45:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.961
X-Spam-Level: 
X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVurIRImwU7E for ; Thu, 30 Oct 2014 13:45:51 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF4B1A876C for ; Thu, 30 Oct 2014 13:45:51 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 83936A1; Thu, 30 Oct 2014 21:45:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1414701949; bh=bzB7fghvfzeBy/+Y1ycdWokI+DnZHJYwuptjMnLkNRc=; h=Date:From:To:Subject:In-Reply-To:References:From; b=SgLOvT7JUOoH03qpVxYaTHBplRriD7eH/gqDH1XAYyxp2IkLcb19Z5eC5cUlCzIdy M9h9ySeph5dqyN6nOb0fdQ7XSjQpougaAjHkiFVyyN8mDRELrrjIBY3gK2xlH5JLcv fAcDg5/kaQPxjbcou/GEIO5j/IQ943Rm3MYOZDMA=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7F6AF9F for ; Thu, 30 Oct 2014 21:45:49 +0100 (CET)
Date: Thu, 30 Oct 2014 21:45:49 +0100 (CET)
From: Mikael Abrahamsson 
To: "homenet@ietf.org" 
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/zpndEW9c8Xmr13WEfrl9_bKUZ3o
Subject: Re: [homenet] Comments requested for draft CER-ID
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 20:45:54 -0000

On Mon, 27 Oct 2014, Michael Kloberdans wrote:

> 2.  CER Identification Option
>
>   A Customer Edge Router (CER) sets the CER_ID to the IPv6 address of
>   its LAN interface.  If it has more than one LAN IPv6 address, it
>   selects one of its LAN or loopback IPv6 addresses to be used in the
>   CER_ID.  An ISP server does not respond with the CER_ID or sets the
>   CER_ID to ::.  Such a response or lack of response indicates to the
>   DHCPv6 client that it is the CER.
>
>   The format of the CER Identification option is:
>
>    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-code              |      option-len               |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                                                               |
>   |                           CER_ID                              |
>   |                                                               |
>   |                                                               |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       option-code          OPTION_CER_ID (TBD).
>       option-len           36
>       CER_ID value         IPv6 address of CER or ::

I am not an expert when it comes to DHCP. Is there something implicit in 
the way that DHCP options are designed that makes it obvious that the 
"CER_ID value" is using ASCII or 128 bits binary to represent the IPv6 
address? Because it's not obvious to me from reading the above text.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Thu Oct 30 14:57:14 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767811A8840 for ; Thu, 30 Oct 2014 14:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level: 
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1v6RrOAQ25Mg for ; Thu, 30 Oct 2014 14:57:02 -0700 (PDT)
Received: from mx2.nominet.org.uk (mail.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id 16D331A8843 for ; Thu, 30 Oct 2014 14:57:01 -0700 (PDT)
DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns;  h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-Transfer-Encoding:MIME-Version; b=X8xSv1+biqsAALRjb7fu/fIY7aQct7hfnSwVE55+l4v+TL9rUru5qr8H CYFn0456TAnJOEuNz2QEp6cqDG1lpkNdKwZ+mfrrsrZm+G66DPHyDjReE NgUAI6Ll98iLP/bWSpnxh8KVKHVDKyZaiwN+3KKusT7Pe/F3nt1mwsexZ HTGW3W25h9y5z/v6W3ryLVwmZMAKatEGbfFLnTm/Cvy0kTHck9KVagrtW 6GALPefJ70ut6pFaL9qDIf1ZUk2ls;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1414706222; x=1446242222; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WWvy0X+lTEeU7GyhhDDHhcg3cXvS9KoDR3uH7aJujrU=; b=JX6t5cyOX4vRddrmR+xLugqUo7m9J4YTFLvZcYea+J5F1kzlA2GcsHL2 UDRVmFtgf0eoBzp7N08bL27dkk7vqfpN0aoDz6HKooKEwwuVhpB29SeGf k85KN3vPBQNAmrZUP4HRQK2pa+u+QGv9MVZNM64S9/FCle8fTYrkdoBh6 BG1tE+D8TmwQRQz1nTgUe81krk0qEXgW6Z2ZISrYB/T6IFrGQSyyZAGJl PCIUIPGcFuoAM+Ux5p8DcoeiUDyXB;
X-IronPort-AV: E=Sophos;i="5.07,289,1413241200"; d="scan'208";a="13520555"
X-IPAS-Result: AqYDAH+zUlTV+MWRdGdsb2JhbABcgmuBT9RrAoElFgEBAQEBARABDF+EAgEBAQECAToZFREFCwIBCBgeECERJQIEDgWILAMJCgPEQA2GOgEBAQEBBQEBAQEBAQEBAQEBF45VggczB4MtgR4Fm1+RaopjbAGCSgEBAQ
Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 30 Oct 2014 21:57:00 +0000
Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%16]) with mapi id 14.03.0181.006; Thu, 30 Oct 2014 21:57:00 +0000
From: Ray Bellis 
To: Brian E Carpenter 
Thread-Topic: [homenet] Slots request for presenting Homenet work at Anima session
Thread-Index: AQHP8jlrSjmWir9oXUCMndNtJM3/55xJNGkG
Date: Thu, 30 Oct 2014 21:56:59 +0000
Message-ID: 
References: <9A89531E-AEE1-4FCD-B725-0ECDC76F5125@cisco.com>, <544ECDB8.1010204@gmail.com>
In-Reply-To: <544ECDB8.1010204@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/EatQNDZRjO252_MG0VgzCicRDT0
Cc: HOMENET Working Group 
Subject: Re: [homenet] Slots request for presenting Homenet work at Anima session
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 21:57:09 -0000

> On 27 Oct 2014, at 22:57, "Brian E Carpenter"  wrote:
>=20
> FYI the status of the anima meeting in HNL will only be decided
> at this weeks's IESG meeting and the chairs are not yet known,
> so the agenda process is running late.

As is ours, as I'm on vacation and Mark is away at a conference.  We expect=
 normal service to be resumed Monday.

Ray=


From nobody Thu Oct 30 15:12:26 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BD21A8854; Thu, 30 Oct 2014 15:12:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXq_9gTEilLK; Thu, 30 Oct 2014 15:11:32 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id E94EB1A884C; Thu, 30 Oct 2014 15:11:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 57B85871612; Thu, 30 Oct 2014 23:11:30 +0100 (CET)
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gi7UhoIstpiK; Thu, 30 Oct 2014 23:11:30 +0100 (CET)
Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id E5AA6870048; Thu, 30 Oct 2014 23:11:29 +0100 (CET)
Message-ID: <5452B76B.8080908@globis.net>
Date: Thu, 30 Oct 2014 23:10:51 +0100
From: Ray Hunter 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: "Fred Baker (fred)" 
References: <20141020204033.GD236844@jupiter.n2.diac24.net> <20141022190653.GB868521@jupiter.n2.diac24.net>   <544FF3F2.3050206@gmail.com> <20141029062837.GH5186@eidolon>  <5450D7ED.9010806@globis.net> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/87sEK4SI1Zy6PUD0f0Bx0eoAhLc
Cc: Ole Troan , "homenet@ietf.org" , "rtgwg@ietf.org" , Mikael Abrahamsson , David Lamparter 
Subject: Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 22:12:03 -0000

> Fred Baker (fred) 
> 29 October 2014 17:09
> On Oct 29, 2014, at 5:05 AM, Ray Hunter  wrote:
>
>> Fred Baker (fred) wrote:
>>> On Oct 28, 2014, at 11:28 PM, David Lamparter   wrote:
>>>
>>>> What I'm personally wondering most in this regard is: to what extent
>>>> will larger networks deploy multiple prefixes to the hosts?
>>> Well, define “larger”. Any network that gets a PI prefix is unlikely to deploy multiple prefixes. The question is at what size network is makes sense to obtain an AS number and a PI prefix, and use BGP to talk with one’s upstream.
>> I don't agree with this statement for the following reasons.
>>
>> Availability: There are many enterprises that have very numerous far-flung sales-office type locations which do not host any critical data or applications, but which could benefit from higher availability than that provided by a single ISP provider (some of which are currently served by a specialised box offering a Very Small Office Service running dual IPSec tunnels to a central site, which then performs the break out to the corporate intranet/Internet)
>>
>> Latency: There are many sites which could benefit from local Internet breakout to regional cloud services, where you don't want to suffer the latency associated with a back haul from an office in Australia to a regional hub in Hong Kong, or even East coast US to West coast US and back. You'd still also want some back up via the central breakout if the local breakout failed.
>>
>> Cost: There are cost savings to be made in many countries where private network services are still many orders of magnitude more expensive than plain old Internet. So Internet offload for non-mission-critical traffic can be very attractive. If you could achieve this via direct host-server connections using address selection rules or multipath TCP; rather than via PBR, GRE tunnels + NAT, that would be a lot simpler.
>
> I have a hunch we’re talking past each other. We would agree, but we’re discussing different cases. I was discussing a case in which a company operates a single addressing plan. I think you’re discussing a company that operates multiple addressing plans, one for each of several locations.
Quite possibly.
> Cisco might be an example of a “larger” company. We have an IPv6 /32, more locations than you can shake a stick at, and maybe 20 DMZs, places where our network interconnects with the Internet. I don’t know exactly what we advertise or where, but I could imagine that a few of our DMZs advertise the /32 and each of our DMZs advertises a /40, or something along that line. For us, PI is “duh, obvious”, and the only case in which we might - *might* - have a second prefix would be a ULA in a lab.
Well I think it's instructive to look at the current IPv4 unicast 
routing table and ask whether replicating this 1:1 into IPv6 is what 
enterprises really want.

Multihoming is far more than Internet.

External "3rd Party" networks are often as big as, or even bigger than, 
an enterprises own Intranet.

If I look at some customer's current IPv4 routing tables, they contain: 
3rd party management companies for IT, speciality partners, per-project 
collaboration partners, private cloud, public cloud, merger demerger and 
assimilation targets, payment companies, 3rd party management companies 
for specialist equipment .... hundreds of prefixes that aren't even 
managed by the enterprise in question, and with high churn rates too.

If I ask myself: do all product divisions of the business really want 
all of these differing communication requirements to get funneled 
through exactly the same handful of 3rd party touchpoints/DMZs to the 
outside world on a per region basis, I think the answer would 
emphatically be "no".

IMHO Destination based routing (and ensuring balanced/ symmetric return 
routes for your own prefixes) imposes unnatural constraints on these 
touchpoints/DMZs, compared to what the business expects.

Why do you want to share a route to your crown-jewels /32 prefix, also 
used for your sales/finance platform, with someone who just manages some 
print servers for one product division on a number of sites via a 
dual-redundant 1Mbps link, whilst you have 10Gbps to the Internet? What 
happens if this 3rd party print server management company leaks your /32 
elsewhere via BGP into another AS? e.g. to another customer where they 
also manage their print servers, and who in turn are an important 
customer of your own products and want to connect to your front end 
sales site (via another higher-speed link).

It remains to be seen whether multiple-prefixes and SADR would help 
reduce this complexity, or just shift it around.

e.g. having a different prefix M assigned to a logical management 
interface on all print servers managed by party M, in addition to a 
prefix C used by the internal customers to connect to the business 
interface of the same servers.

You could have a default route for traffic sourced from prefix M 
pointing to the server management company via one DMZ to company M, and 
a different default route for customers prefix C out of another e.g. 
Internet. The management company M would only need a return route to the 
specific M prefixes from their network located in your network, and 
would not need to learn your /32 C prefix at all. They in turn also 
wouldn't have to advertise their crown jewels /32 into your network. And 
firewall rules and route filter rules become "allow M to M on one DMZ 
gateway", rather than a spaghetti of 10000 individual rules from 
prefixes A-Z to prefix C that no-one understands any more.

I do know that trying to encode all of the regions/countries/business 
units requirements in the 32 bits available today in IPv6, whilst 
attempting to filter using BGP, just doesn't get anywhere near to 
expressing the current natural level of business complexity and 
availability requirements (assuming /32 RIR allocation and /64 LANs). 
And maintaining the related firewall rules and route filters is 
currently a nightmare.
> I suspect the company you are discussing might have a number of small offices in as many cities, and as many PA prefixes as it takes. The company might also have a PI prefix, but I would be surprised if it used the PI prefix in all of its little offices; if it did, it would essentially use it for internal traffic, and have some sort of VPN connecting the offices on which it was used. It would, however, use the PA prefixes from the offices when they need to talk outside the house. If it is using the PI prefix plus a PA prefix in any given office, it would depend on RFC 6724’s Rule 8 (longest match) to prefer a PI address when talking to another address within the prefix, and a temporary address from PA space otherwise.
>
> In any event, in the context of my comment above, I am thinking of the many small offices as separate networks. They don’t justify their own PI spaces; the PI in context acts more like PA from the central corporation than PI in the traditional sense of the term. They might well get PA from one or more ISPs, and they might have something akin to PA from their central office or whatever.
>
> Coming back to the question - “would they put multiple subnet prefixes on any given LAN” - the question really comes back to their requirements and stomach for complexity. If they require multihoming, such as Jim suggests, I would hope they would do that. Among my “NAT == Security” customers and SEs, getting them there requires their network to work well (egress routing being one of many important parts of that), and a good security solution that doesn’t involve NAT. Until they have one AND they are convinced, they tell us that the lack of a NAT solution is a reason to delay deployment. I don’t think that last is about the number of prefixes around; it’s about security policy and mindset.
>
>>>   Wherever that boundary is, below that networks will use PA prefixes. The question then becomes: will they multi home?
>>>
>>> And I think the answer today is that we don’t know the answer.
>> This I agree with.
>>
>>
>> -- 
>> Regards,
>> RayH
>>
>
>

-- 
Regards,
RayH


From nobody Thu Oct 30 22:53:31 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EE91A8ABC; Thu, 30 Oct 2014 22:53:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nPqv5yh2C0W; Thu, 30 Oct 2014 22:53:24 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031521A8AC0; Thu, 30 Oct 2014 22:53:23 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOG18809; Fri, 31 Oct 2014 05:53:22 +0000 (GMT)
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 31 Oct 2014 05:53:21 +0000
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.22]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 31 Oct 2014 13:53:17 +0800
From: Sheng Jiang 
To: Markus Stenberg , Benoit Claise 
Thread-Topic: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
Thread-Index: AQHP9CELHPsbSkuB0kOBZR+m5fg3ypxJsn3Q
Date: Fri, 31 Oct 2014 05:53:16 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF6C46E@nkgeml512-mbx.china.huawei.com>
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi>
In-Reply-To: <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.145]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/n__exGpxP5_aAtffO1dQkfgF_ic
Cc: "homenet@ietf.org" , "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 05:53:27 -0000

Pkkgd291bGQgcGVyc29uYWxseSByYXRoZXIgZHJvcCBwcmVmaXggbWFuYWdlbWVudC4gQXQgbGVh
c3QsIHRoZSBjdXJyZW50DQo+cHJvcG9zZWQgc29sdXRpb24gaXMgREhDUHY2IFBEIHBsdXMgbG90
IG9mIG1hcmtldGluZyBwbHVzIG9uZSBleHRyYSB0aGluZw0KPihyb2xlKSBtaW51cyB0b25zIG9m
IGV4aXN0aW5nIGZ1bmN0aW9uYWxpdHkuIEkgd291bGQgcmF0aGVyIHN0aWNrIHRoZSByb2xlIGlu
dG8gUEQsDQo+dGhhbiByZWludmVudCB0aGUgcHJvdG9jb2wuDQoNCkRIQ1B2NiBQRCBoYXMgb25s
eSBzb2x2ZSB0aGUgcHJlZml4IHJlcXVlc3QgYW5kIGFzc2lnbiBwcm9jZXNzIGJhc2VkIG9uIHRo
ZSBwcmVjb25kaXRpb25zOg0KDQphKSB0aGUgcmVxdWVzdGluZyByb3V0ZXIga25vd3MgdGhlIHBy
ZWZpeCBsZW5ndGggaXQgc2hvdWxkIHJlcXVlc3Q7DQpiKSB0aGUgcmVxdWVzdGluZyByb3V0ZXIg
a25vd3Mgd2hhdCBkZXZpY2UgdG8gc2VuZCB0aGUgcmVxdWVzdDsNCmMpIFRoZSByZXF1ZXN0ZWQg
ZGV2aWNlIGhhdmUgZW5vdWdoIHJlc291cmNlIGZvciB0aGUgcmVxdWVzdC4NCg0KSG93ZXZlciwg
aHVtYW4gY29uZmlndXJhdGlvbiBvciBodW1hbiBpbnRlcnZlbnRpb24gYXJlIG5lZWRlZCB0byBt
ZWV0IHRoZXNlIHByZWNvbmRpdGlvbnMuIFRoZSBjdXJyZW50IHByb3Bvc2VkIHNvbHV0aW9uIGZv
Y3VzZXMgb24gdG8gYXV0b25vbWljIHByb2Nlc3NlcyB0byBzb2x2ZSB0aGVzZSBwcmVjb25kaXRp
b25zLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj5JZiB0aGVyZSBpcyBub3Qgc29tZXRo
aW5nIG1vcmUgbm92ZWwgdGhlcmUgKHRoYXQgaXMsIG5vdCBoaWVyYXJjaGljYWwgUEQgaW4NCj5k
aXNndWlzZSksIEkgZG8gbm90IHNlZSB0aGUgcG9pbnQuDQo+DQo+PiBBbHNvLCBUaGUgSE9NRU5F
VCBjb2xsYWJvcmF0aW9uIGhhcyBiZWVuIHN0cmVzc2VkIGluIHRoZSBjaGFydGVyLg0KPj4NCj4+
IDMuIE90aGVycw0KPj4gSSBiZWxpZXZlIEkgdG9vayBjYXJlIG9mIHRoZSBvdGhlcnMgY2hhbmdl
cyBwcm9wb3NlZCBvbiB0aGUgbWFpbGluZy4gSWYgdGhpcyBpcw0KPm5vdCB0aGUgY2FzZSwgbGV0
IG1lIGtub3cuDQo+PiBBdCB0aGlzIHBvaW50IGluIHRpbWUsIHBsZWFzZSBwcm92aWRlIGNvbmNy
ZXRlIGNoYW5nZSB0byB0aGUgY2hhcnRlciB0ZXh0IGlmDQo+c29tZSBpc3N1ZXMgcGVyc2lzdC4N
Cj4+IENoYXJ0ZXIgdjE1IGhhcyBqdXN0IGJlZW4gcG9zdGVkLCBhbmQgeW91IGNhbiByZXZpZXcg
dGhlIGRldGFpbGVkIGNoYW5nZXMNCj5hdA0KPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/
dXJsMT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZA0KPm9jJTJGY2hhcnRl
ci1pZXRmLWFuaW1hJTJGd2l0aG1pbGVzdG9uZXMtMDAtMTQudHh0JmRpZmZ0eXBlPS0taHRtbCZz
dWINCj5taXQ9R28hJnVybDI9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRv
YyUyRmNoYXJ0ZXItaWV0Zi1hDQo+bmltYSUyRndpdGhtaWxlc3RvbmVzLTAwLTE1LnR4dA0KPg0K
PkkgdGhpbmsgaXQgaXMgbW9zdGx5IGZpbmUsIGFsdGhvdWdoIHRoZSB1c2Ugb2YgdGVybSDigJhh
dXRvbm9tb3Vz4oCZIGZvcg0KPmVzc2VudGlhbGx5IChvbiBoaWdoIGxldmVsKSBtYW5hZ2VkIGRl
dmljZXMgdGhhdCBwZXJmb3JtIHNvbWUgbG93LWxldmVsDQo+YXV0b25vbWljIGZ1bmN0aW9ucyBz
b3VuZHMgc3RpbGwgc3RyYW5nZSB0byBtZS4gSSBndWVzcyBJIGNvdWxkIGxpdmUgd2l0aCBpdA0K
PnRob3VnaC4NCj4NCj5DaGVlcnMsDQo+DQo+LU1hcmt1cw0KPg0KPg0KPl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+aG9tZW5ldCBtYWlsaW5nIGxpc3QN
Cj5ob21lbmV0QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9ob21lbmV0DQo=


From nobody Fri Oct 31 03:32:08 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091761A0AF7; Fri, 31 Oct 2014 03:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmIipmGmkiYm; Fri, 31 Oct 2014 03:32:05 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id CC4FC1A012D; Fri, 31 Oct 2014 03:32:05 -0700 (PDT)
Received: from [10.0.20.107] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id 5C8E82380340; Fri, 31 Oct 2014 06:32:04 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AF6C46E@nkgeml512-mbx.china.huawei.com>
Date: Fri, 31 Oct 2014 06:31:48 -0400
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <5D36713D8A4E7348A7E10DF7437A4B923AF6C46E@nkgeml512-mbx.china.huawei.com>
To: Sheng Jiang 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/rB-8SZm8Sw185fAZzicxh3-nyQE
Cc: Benoit Claise , "homenet@ietf.org" , Markus Stenberg , "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 10:32:07 -0000

On Oct 31, 2014, at 1:53 AM, Sheng Jiang  wrote:
> a) the requesting router knows the prefix length it should request;

It should always request a single /64.


From nobody Fri Oct 31 05:54:29 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A7F1A003A; Fri, 31 Oct 2014 05:54:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqoyNwCjuRH8; Fri, 31 Oct 2014 05:54:23 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E599E1A8768; Fri, 31 Oct 2014 05:54:21 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLD51307; Fri, 31 Oct 2014 12:54:20 +0000 (GMT)
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 31 Oct 2014 12:54:19 +0000
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.22]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Fri, 31 Oct 2014 20:54:16 +0800
From: Sheng Jiang 
To: Ted Lemon 
Thread-Topic: [Anima] [homenet] ANIMA scope + homenet interaction + charter v15
Thread-Index: AQHP9PX0f2TRQAAlW0u8kzZowpEJRZxKKSPg
Date: Fri, 31 Oct 2014 12:54:15 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF6C7AE@nkgeml512-mbx.china.huawei.com>
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <5D36713D8A4E7348A7E10DF7437A4B923AF6C46E@nkgeml512-mbx.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.145]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/UANyMCO6HV4KZpX1CfJuR4pYh4A
Cc: Benoit Claise , "homenet@ietf.org" , Markus Stenberg , "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 12:54:26 -0000

Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogQW5pbWEgW21haWx0bzphbmltYS1i
b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVkIExlbW9uDQo+U2VudDogRnJpZGF5LCBP
Y3RvYmVyIDMxLCAyMDE0IDY6MzIgUE0NCj5UbzogU2hlbmcgSmlhbmcNCj5DYzogQmVub2l0IENs
YWlzZTsgaG9tZW5ldEBpZXRmLm9yZzsgTWFya3VzIFN0ZW5iZXJnOyBhbmltYUBpZXRmLm9yZw0K
PlN1YmplY3Q6IFJlOiBbQW5pbWFdIFtob21lbmV0XSBBTklNQSBzY29wZSArIGhvbWVuZXQgaW50
ZXJhY3Rpb24gKw0KPmNoYXJ0ZXIgdjE1DQo+DQo+T24gT2N0IDMxLCAyMDE0LCBhdCAxOjUzIEFN
LCBTaGVuZyBKaWFuZyA8amlhbmdzaGVuZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4+IGEpIHRoZSBy
ZXF1ZXN0aW5nIHJvdXRlciBrbm93cyB0aGUgcHJlZml4IGxlbmd0aCBpdCBzaG91bGQgcmVxdWVz
dDsNCj4NCj5JdCBzaG91bGQgYWx3YXlzIHJlcXVlc3QgYSBzaW5nbGUgLzY0Lg0KDQpBcmUgeW91
IHRhbGtpbmcgYWJvdXQgYXNzaWduaW5nIHByZWZpeCBmb3IgaG9tZW5ldD8gSSB0aG91Z2h0IHdl
IHdlcmUgdGFsa2luZyBhYm91dCBhdXRvIHByZWZpeCBtYW5hZ2VtZW50IGluIGEgbGFyZ2UgbmV0
d29yaywgd2hpY2ggaXMgQU5JTUEgdXNlIGNhc2UuDQoNClNoZW5nDQoNCj5fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkFuaW1hIG1haWxpbmcgbGlzdA0K
PkFuaW1hQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h
bmltYQ0K


From nobody Fri Oct 31 07:34:10 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5EF1A0079; Fri, 31 Oct 2014 07:34:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGtplosPwRMV; Fri, 31 Oct 2014 07:34:05 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2D79D1A000E; Fri, 31 Oct 2014 07:34:05 -0700 (PDT)
Received: from [10.0.20.107] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id 19B5723802BB; Fri, 31 Oct 2014 10:34:02 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AF6C7AE@nkgeml512-mbx.china.huawei.com>
Date: Fri, 31 Oct 2014 10:34:01 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <8490A544-45A9-45D2-9C98-D3CBEB28651D@fugue.com>
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <5D36713D8A4E7348A7E10DF7437A4B923AF6C46E@nkgeml512-mbx.china.huawei.com>  <5D36713D8A4E7348A7E10DF7437A4B923AF6C7AE@nkgeml512-mbx.china.huawei.com>
To: Sheng Jiang 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/n33QNfscQyjZBoxnrFr0gf8khHA
Cc: Benoit Claise , "homenet@ietf.org" , Markus Stenberg , "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 14:34:07 -0000

On Oct 31, 2014, at 8:54 AM, Sheng Jiang  wrote:
> Are you talking about assigning prefix for homenet? I thought we were =
talking about auto prefix management in a large network, which is ANIMA =
use case.

In either case, it's important to make the distinction between prefix =
assignment and prefix delegation.   In an autonomous network, I don't =
think it's practical to do hierarchical prefix delegation.   That has =
the unfortunate consequence that there can't be any routing aggregation. =
  The delegating router can of course _try_ to keep the topology clean, =
but routing has to work even if it fails.

That being the case, every delegation _request_ should be for a /64, =
because every delegation request should be a request for a /64 to =
configure on an interface of a router.   Whether or not aggregation =
occurs is up to whichever device is the delegating router.   Having a =
distributed delegation framework is probably a good idea, but a =
hierarchical distribution won't work, so the idea that a router could =
request prefixes to be delegated and then re-delegate some of those =
prefixes is, IMHO, not going to work.


From nobody Fri Oct 31 07:56:04 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A671A908D; Fri, 31 Oct 2014 07:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ByYtYdwlcMY; Fri, 31 Oct 2014 07:56:01 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E597E1A9076; Fri, 31 Oct 2014 07:55:29 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOG70899; Fri, 31 Oct 2014 14:55:28 +0000 (GMT)
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 31 Oct 2014 14:55:27 +0000
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.22]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 31 Oct 2014 22:55:21 +0800
From: Sheng Jiang 
To: Ted Lemon 
Thread-Topic: [Anima] [homenet] ANIMA scope + homenet interaction + charter v15
Thread-Index: AQHP9Re8b4wGgKR4VUqVVzrN4+BChZxKST3w
Date: Fri, 31 Oct 2014 14:55:20 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF6C8A9@nkgeml512-mbx.china.huawei.com>
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <5D36713D8A4E7348A7E10DF7437A4B923AF6C46E@nkgeml512-mbx.china.huawei.com>  <5D36713D8A4E7348A7E10DF7437A4B923AF6C7AE@nkgeml512-mbx.china.huawei.com>, <8490A544-45A9-45D2-9C98-D3CBEB28651D@fugue.com>
In-Reply-To: <8490A544-45A9-45D2-9C98-D3CBEB28651D@fugue.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.45.29.140]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/2EhzzkkN2SN_bGelSROTrPNXg_o
Cc: Benoit Claise , "homenet@ietf.org" , Markus Stenberg , "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 14:56:03 -0000

Hi, Ted,

I now understand your point. Your arguments do make sense. The current gene=
ral mechanism are too general to work for the use case of hierarchical pref=
ix delegation. But if we add hierarchical topology and no bypass requests a=
s constraint conditions, we may be able to make hierarchical prefix delegat=
ion work.

Best regards,

Sheng
________________________________________
From: Ted Lemon [mellon@fugue.com]
Sent: 31 October 2014 22:34
To: Sheng Jiang
Cc: Benoit Claise; homenet@ietf.org; Markus Stenberg; anima@ietf.org
Subject: Re: [Anima] [homenet] ANIMA scope + homenet interaction + charter =
v15

On Oct 31, 2014, at 8:54 AM, Sheng Jiang  wrote:
> Are you talking about assigning prefix for homenet? I thought we were tal=
king about auto prefix management in a large network, which is ANIMA use ca=
se.

In either case, it's important to make the distinction between prefix assig=
nment and prefix delegation.   In an autonomous network, I don't think it's=
 practical to do hierarchical prefix delegation.   That has the unfortunate=
 consequence that there can't be any routing aggregation.   The delegating =
router can of course _try_ to keep the topology clean, but routing has to w=
ork even if it fails.

That being the case, every delegation _request_ should be for a /64, becaus=
e every delegation request should be a request for a /64 to configure on an=
 interface of a router.   Whether or not aggregation occurs is up to whiche=
ver device is the delegating router.   Having a distributed delegation fram=
ework is probably a good idea, but a hierarchical distribution won't work, =
so the idea that a router could request prefixes to be delegated and then r=
e-delegate some of those prefixes is, IMHO, not going to work.=


From nobody Fri Oct 31 08:47:55 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691991ACD0C; Fri, 31 Oct 2014 08:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0pftzGWwxcB; Fri, 31 Oct 2014 08:47:51 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id B118E1ACD0B; Fri, 31 Oct 2014 08:47:51 -0700 (PDT)
Received: from [10.0.20.107] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id C37C923802BB; Fri, 31 Oct 2014 11:47:49 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AF6C8A9@nkgeml512-mbx.china.huawei.com>
Date: Fri, 31 Oct 2014 11:47:47 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <5D36713D8A4E7348A7E10DF7437A4B923AF6C46E@nkgeml512-mbx.china.huawei.com>  <5D36713D8A4E7348A7E10DF7437A4B923AF6C7AE@nkgeml512-mbx.china.huawei.com>, <8490A544-45A9-45D2-9C98-D3CBEB28651D@fugue.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6C8A9@nkgeml512-mbx.china.huawei.com>
To: Sheng Jiang 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/JQCpxLuYyLcg7pn_rDn6mv2bHR8
Cc: Benoit Claise , "homenet@ietf.org" , Markus Stenberg , "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 15:47:53 -0000

On Oct 31, 2014, at 10:55 AM, Sheng Jiang  wrote:
> The current general mechanism are too general to work for the use case =
of hierarchical prefix delegation. But if we add hierarchical topology =
and no bypass requests as constraint conditions, we may be able to make =
hierarchical prefix delegation work.

No, that is not the point I am making.   The point I am making is that =
hierarchical delegation simply won't work, no matter what mechanism you =
put in place to do it, because the network has to be able to grow =
incrementally.   With that as a base assumption, you cannot predict =
where the network will grow, so you don't know how to construct the =
hierarchy.   Once the hierarchy is constructed, you would have to =
renumber on a regular basis to make hierarchical delegation work.   I =
think it is preferable to simply allow for a complete routing table, and =
then try as best as possible to make routing hierarchical, without =
demanding perfection.


From nobody Fri Oct 31 10:13:42 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE291A006F; Fri, 31 Oct 2014 10:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOcGrkbKLJyo; Fri, 31 Oct 2014 10:13:39 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E651A001C; Fri, 31 Oct 2014 10:13:38 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s9VHCr1X025658; Fri, 31 Oct 2014 18:12:53 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 23C0820B1D7; Fri, 31 Oct 2014 18:12:54 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1023620B117; Fri, 31 Oct 2014 18:12:54 +0100 (CET)
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 s9VHCjCT008351; Fri, 31 Oct 2014 18:12:53 +0100
Message-ID: <5453C30D.6000701@gmail.com>
Date: Fri, 31 Oct 2014 18:12:45 +0100
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ted Lemon , Sheng Jiang 
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <5D36713D8A4E7348A7E10DF7437A4B923AF6C46E@nkgeml512-mbx.china.huawei.com>  <5D36713D8A4E7348A7E10DF7437A4B923AF6C7AE@nkgeml512-mbx.china.huawei.com>, <8490A544-45A9-45D2-9C98-D3CBEB28651D@fugue.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6C8A9@nkgeml512-mbx.china.huawei.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/7Euu4KCOsCwyneE5jVqYpwLRnf0
Cc: Benoit Claise , "homenet@ietf.org" , Markus Stenberg , "anima@ietf.org" 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 17:13:41 -0000

Le 31/10/2014 16:47, Ted Lemon a écrit :
> On Oct 31, 2014, at 10:55 AM, Sheng Jiang 
> wrote:
>> The current general mechanism are too general to work for the use
>> case of hierarchical prefix delegation. But if we add hierarchical
>> topology and no bypass requests as constraint conditions, we may be
>> able to make hierarchical prefix delegation work.
>
> No, that is not the point I am making.   The point I am making is
> that hierarchical delegation simply won't work, no matter what
> mechanism you put in place to do it, because the network has to be
> able to grow incrementally.   With that as a base assumption, you
> cannot predict where the network will grow, so you don't know how to
> construct the hierarchy.   Once the hierarchy is constructed, you
> would have to renumber on a regular basis to make hierarchical
> delegation work.

At which point one wonders whether Router Renumbering RFC2894 may need 
some updates.

Alex


    I think it is preferable to simply allow for a
> complete routing table, and then try as best as possible to make
> routing hierarchical, without demanding perfection.
>
> _______________________________________________ homenet mailing list
> homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
>
>



From nobody Fri Oct 31 12:10:58 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4881A1AAE; Fri, 31 Oct 2014 12:10:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Fxg-sSedCL8; Fri, 31 Oct 2014 12:10:49 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 12C9F1ACD18; Fri, 31 Oct 2014 12:10:35 -0700 (PDT)
Received: from [10.0.20.107] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id D2AA423802BB; Fri, 31 Oct 2014 15:10:32 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <5453C37B.50002@gmail.com>
Date: Fri, 31 Oct 2014 15:10:30 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <1EDC6FFB-3EE7-4FF9-BD82-B376A0677912@fugue.com>
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <5D36713D8A4E7348A7E10DF7437A4B923AF6C46E@nkgeml512-mbx.china.huawei.com>  <5D36713D8A4E7348A7E10DF7437A4B923AF6C7AE@nkgeml512-mbx.china.huawei.com>, <8490A544-45A9-45D2-9C98-D3CBEB28651D@fugue.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6C8A9@nkgeml512-mbx.china.huawei.com>  <5453C37B.50002@gmail.com>
To: Alexandre Petrescu 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/7f1-HSve1Ujml_Jr4saGc6MkSzg
Cc: Benoit Claise , "homenet@ietf.org" , Markus Stenberg , "anima@ietf.org" , Sheng Jiang 
Subject: Re: [homenet] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 19:10:51 -0000

On Oct 31, 2014, at 1:14 PM, Alexandre Petrescu =
 wrote:
> At which point one wonders whether Router Renumbering RFC2894 may need =
some updates.

I don't think that's the right approach.   Renumbering makes sense when =
it's needed, but renumbering whenever you need to balance the routing =
hierarchy?   That's a lot of pain for a very minimal return.


From nobody Fri Oct 31 12:25:55 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DB21A0120; Fri, 31 Oct 2014 12:25:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-24cqODRs_E; Fri, 31 Oct 2014 12:25:53 -0700 (PDT)
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C84D1A1A4B; Fri, 31 Oct 2014 12:25:53 -0700 (PDT)
Received: by mail-pa0-f54.google.com with SMTP id rd3so8351488pab.13 for ; Fri, 31 Oct 2014 12:25:52 -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=XXQZgEih75MfcdsOfv1ii4Qv6v4KKVgouFGH/it3M9M=; b=yVKxjvFIihJMEfojBe8/cRV7bRmIT7LtN8B7yGlP0TQKJ8WjOqmWHfOQNhBl5oASvK lO0jxIBzMunvOjLfEiMVXUaKwJYwBn5TNKXN6khzuvVuP+J7a1/J19ovqqJf/A6BDiJX XG0KQ7JX0kX9UabriLMLVaCWIaJDDCnvdEhNz5wj12gk0FKTSbn0gKN2z4/O/1swW33n D3+PzEcPaGyFe9VcrnAy7czc3OctX/6SZ7iaetd45WfzZPDTR+2hq0xGAXEpdN8PHh4f uuNM/ZgLnLLp6BB94xd0BPmg5CeeG7sHiFrE1e/8vRhk071lvqpI8GnyjGUbXQCT3/Jn 9uqw==
X-Received: by 10.70.89.101 with SMTP id bn5mr12767433pdb.134.1414783552775; Fri, 31 Oct 2014 12:25:52 -0700 (PDT)
Received: from [192.168.178.23] (247.200.69.111.dynamic.snap.net.nz. [111.69.200.247]) by mx.google.com with ESMTPSA id g2sm10622598pdk.46.2014.10.31.12.25.48 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 12:25:51 -0700 (PDT)
Message-ID: <5453E246.9000705@gmail.com>
Date: Sat, 01 Nov 2014 08:25:58 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ted Lemon 
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <5D36713D8A4E7348A7E10DF7437A4B923AF6C46E@nkgeml512-mbx.china.huawei.com>  <5D36713D8A4E7348A7E10DF7437A4B923AF6C7AE@nkgeml512-mbx.china.huawei.com>, <8490A544-45A9-45D2-9C98-D3CBEB28651D@fugue.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6C8A9@nkgeml512-mbx.china.huawei.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/7pl1JZDvubzr9LKbFENrCHO9vHM
Cc: Benoit Claise , "homenet@ietf.org" , Markus Stenberg , "anima@ietf.org" , Sheng Jiang 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 19:25:55 -0000

On 01/11/2014 04:47, Ted Lemon wrote:
> On Oct 31, 2014, at 10:55 AM, Sheng Jiang  wrote:
>> The current general mechanism are too general to work for the use case of hierarchical prefix delegation. But if we add hierarchical topology and no bypass requests as constraint conditions, we may be able to make hierarchical prefix delegation work.
> 
> No, that is not the point I am making.   The point I am making is that hierarchical delegation simply won't work, no matter what mechanism you put in place to do it, because the network has to be able to grow incrementally.   With that as a base assumption, you cannot predict where the network will grow, so you don't know how to construct the hierarchy.   Once the hierarchy is constructed, you would have to renumber on a regular basis to make hierarchical delegation work.   I think it is preferable to simply allow for a complete routing table, and then try as best as possible to make routing hierarchical, without demanding perfection.

Well yes. That's exactly why in autonomic management of prefixes,
we need peer to peer negotiation, as in "I need 3 /64s that I
don't have, do you have any spare ones for me?" Maybe it's
badly explained but that is the whole point of our use case.

   Brian


From nobody Fri Oct 31 13:04:59 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D516C1A0117; Fri, 31 Oct 2014 13:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LAcFWu-vELz; Fri, 31 Oct 2014 13:04:51 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDF51A07BC; Fri, 31 Oct 2014 13:04:49 -0700 (PDT)
Received: from [10.0.20.107] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id 56FF5238004A; Fri, 31 Oct 2014 16:04:45 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon 
In-Reply-To: <5453E246.9000705@gmail.com>
Date: Fri, 31 Oct 2014 16:04:42 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6AD5ADBE-649C-4E30-B2DE-2FE95EEB5112@fugue.com>
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <5D36713D8A4E7348A7E10DF7437A4B923AF6C46E@nkgeml512-mbx.china.huawei.com>  <5D36713D8A4E7348A7E10DF7437A4B923AF6C7AE@nkgeml512-mbx.china.huawei.com>, <8490A544-45A9-45D2-9C98-D3CBEB28651D@fugue.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6C8A9@nkgeml512-mbx.china.huawei.com>  <5453E246.9000705@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/oPd9uKWN-rMp3z-jBzDQytKIZEQ
Cc: Benoit Claise , "homenet@ietf.org" , Markus Stenberg , "anima@ietf.org" , Sheng Jiang 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 20:04:53 -0000

On Oct 31, 2014, at 3:25 PM, Brian E Carpenter =
 wrote:
> Well yes. That's exactly why in autonomic management of prefixes,
> we need peer to peer negotiation, as in "I need 3 /64s that I
> don't have, do you have any spare ones for me?" Maybe it's
> badly explained but that is the whole point of our use case.

Sure, you can approach it as a sort of flood fill algorithm that tries =
to optimize for route aggregation, but copes if that optimization =
doesn't pan out.


From nobody Fri Oct 31 16:28:55 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0211A873E; Fri, 31 Oct 2014 16:28:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSntgL-SJRuD; Fri, 31 Oct 2014 16:28:49 -0700 (PDT)
Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45BEF1A873D; Fri, 31 Oct 2014 16:28:49 -0700 (PDT)
Received: by mail-qa0-f46.google.com with SMTP id n8so2461249qaq.33 for ; Fri, 31 Oct 2014 16:28:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gYduyWmHY2XuICC81TSO3jSI08C3rIjK7AFyZcUBAX4=; b=cX33MNGCJhncOYUekhQcty4XFHObYjcl6XgOjKktRjux+fugoUkAz+6zUN1Dh6oziZ vX+WHtyk6ZUFPUbpKLZgqR1PNr+eEsJ/D/r6buO51uaHlKXVV/6uJwjb9XCzmKmG5yxJ aOBVUeuwHJL5WScA4qb5M0F9qI9ZmU2TKezkJRvkojzNnKazGH933F5Pob1xOv/1DHpT /8V5u31W1+n+L6yBlLDTQOgZGskpHNa2c+JNU+X9h1oAuAxNB5UujphYe1nJo4iltAeS tqMOP+rKAL0WwB17GCJy4g3gbxk9bXMx5nWTDzBcGcglFcm+UQ7a8gXluLvU/USsCLyb PNDw==
X-Received: by 10.140.101.145 with SMTP id u17mr13294790qge.84.1414798128456;  Fri, 31 Oct 2014 16:28:48 -0700 (PDT)
Received: from [192.168.1.126] (c-75-69-243-247.hsd1.ma.comcast.net. [75.69.243.247]) by mx.google.com with ESMTPSA id l2sm10608749qao.34.2014.10.31.16.28.47 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 16:28:47 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Ralph Droms 
X-Mailer: iPad Mail (12A405)
In-Reply-To: <6AD5ADBE-649C-4E30-B2DE-2FE95EEB5112@fugue.com>
Date: Fri, 31 Oct 2014 19:28:46 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <9D2D95EC-61CE-48A0-8196-4563E65F963C@gmail.com>
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <5D36713D8A4E7348A7E10DF7437A4B923AF6C46E@nkgeml512-mbx.china.huawei.com>  <5D36713D8A4E7348A7E10DF7437A4B923AF6C7AE@nkgeml512-mbx.china.huawei.com> <8490A544-45A9-45D2-9C98-D3CBEB28651D@fugue.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6C8A9@nkgeml512-mbx.china.huawei.com>  <5453E246.9000705@gmail.com> <6AD5ADBE-649C-4E30-B2DE-2FE95EEB5112@fugue.com>
To: Ted Lemon 
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Q3BTSIemWe2bUucoOGGX-4CKXF0
Cc: Markus Stenberg , Benoit Claise , "homenet@ietf.org" , "anima@ietf.org" , Sheng Jiang 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Oct 2014 23:28:51 -0000

> On Oct 31, 2014, at 4:04 PM, Ted Lemon  wrote:
>=20
>> On Oct 31, 2014, at 3:25 PM, Brian E Carpenter  wrote:
>> Well yes. That's exactly why in autonomic management of prefixes,
>> we need peer to peer negotiation, as in "I need 3 /64s that I
>> don't have, do you have any spare ones for me?" Maybe it's
>> badly explained but that is the whole point of our use case.
>=20
> Sure, you can approach it as a sort of flood fill algorithm that tries to o=
ptimize for route aggregation, but copes if that optimization doesn't pan ou=
t.
>=20
Do we have use cases in which the number of links is so large that unaggrega=
ted routing tables will be a problem?

- Ralph


From nobody Fri Oct 31 17:19:07 2014
Return-Path: 
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484AC1A874F; Fri, 31 Oct 2014 17:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Qzz_dzoHDyD; Fri, 31 Oct 2014 17:19:02 -0700 (PDT)
Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A331A874D; Fri, 31 Oct 2014 17:19:02 -0700 (PDT)
Received: by mail-pd0-f176.google.com with SMTP id ft15so8147731pdb.7 for ; Fri, 31 Oct 2014 17:19:02 -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=oKy5N3yBJa330cc9aQBy+Qrm8B+XVp74LZsBWngz9Cc=; b=Rt9fQq2ejNNDuG+zJebOC/KOtxDg5FGuZU4LIaGTUmc9Iln4lslZHTyXv/fppE0oIe wDr92pBh9msPJd0G7AadSCkc8NIeLtrQaBOsrjh9HglVkmoLjBxHb0QavcqXD78v/R3J Tp7FEP2Z6Ze6dG5Uy1yRtK0AxspOjmOuAPPICLBT3ri+RaXUC/1QvxHcQF3h5rrE2Ybv SuAAoO+/DcG8K7k/JtXCC0yLuCw1k2ZkQD9WMYOCAMwZmwSOOvuUJEIfIDF31Z9QznhU N5QP5BtAuB8g8AuiYc+ygv382FYcq+KFRErE6OdFte89f4NluxN7fVP5frfB7TvyKQUY hxBg==
X-Received: by 10.70.100.199 with SMTP id fa7mr10474700pdb.114.1414801142456;  Fri, 31 Oct 2014 17:19:02 -0700 (PDT)
Received: from [192.168.178.23] (247.200.69.111.dynamic.snap.net.nz. [111.69.200.247]) by mx.google.com with ESMTPSA id dk5sm10906104pbc.61.2014.10.31.17.18.57 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 17:19:01 -0700 (PDT)
Message-ID: <545426FC.7040504@gmail.com>
Date: Sat, 01 Nov 2014 13:19:08 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ralph Droms 
References: <544FF8FC.5090103@cisco.com> <95338658-B4F2-4634-AC7B-7B893C4DEF2E@iki.fi> <5D36713D8A4E7348A7E10DF7437A4B923AF6C46E@nkgeml512-mbx.china.huawei.com>  <5D36713D8A4E7348A7E10DF7437A4B923AF6C7AE@nkgeml512-mbx.china.huawei.com> <8490A544-45A9-45D2-9C98-D3CBEB28651D@fugue.com> <5D36713D8A4E7348A7E10DF7437A4B923AF6C8A9@nkgeml512-mbx.china.huawei.com>  <5453E246.9000705@gmail.com> <6AD5ADBE-649C-4E30-B2DE-2FE95EEB5112@fugue.com> <9D2D95EC-61CE-48A0-8196-4563E65F963C@gmail.com>
In-Reply-To: <9D2D95EC-61CE-48A0-8196-4563E65F963C@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/O0PGHVAevS7StZ5cDO-Fwh8IWiM
Cc: Markus Stenberg , Ted Lemon , Benoit Claise , "homenet@ietf.org" , "anima@ietf.org" , Sheng Jiang 
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Nov 2014 00:19:04 -0000

On 01/11/2014 12:28, Ralph Droms wrote:
> 
> 
> 
>> On Oct 31, 2014, at 4:04 PM, Ted Lemon  wrote:
>>
>>> On Oct 31, 2014, at 3:25 PM, Brian E Carpenter  wrote:
>>> Well yes. That's exactly why in autonomic management of prefixes,
>>> we need peer to peer negotiation, as in "I need 3 /64s that I
>>> don't have, do you have any spare ones for me?" Maybe it's
>>> badly explained but that is the whole point of our use case.
>> Sure, you can approach it as a sort of flood fill algorithm that tries to optimize for route aggregation, but copes if that optimization doesn't pan out.
>>
> Do we have use cases in which the number of links is so large that unaggregated routing tables will be a problem?

Not that I'm aware of. In the case of a carrier, the prefix will be aggregated
anyway when it is announced to peer carriers, and possibly aggregated
regionally anyway if it's a very large carrier. Of course, there will be
a scaling limit and that should be a consideration in the design.

    Brian