From nobody Wed Jul 2 07:39: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 EE2E91A0240 for ; Wed, 2 Jul 2014 07:39:40 -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 wTE7ezbUzRYu for ; Wed, 2 Jul 2014 07:39:39 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B988E1A0242 for ; Wed, 2 Jul 2014 07:39:38 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id b13so858125wgh.26 for ; Wed, 02 Jul 2014 07:39:35 -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=zmbjB0ndP0OApHLAHLrhOzNYKdP6y2N6UxkyDchLk2U=; b=0o+xEL+bJHVNM0m6yoZo/vhzQ7dNerB8ARL2XY+kJhPDIs4KeK4PR3AhlqJ0K11T4u pgyvr6zJCCqvnFSJYtZLMy4T4+vsb6dmQPqdmga79+Kxw+zcEVCEhXxUjvnCDnWHG58A U4ekKzeeQbUEjfx8KsJ5YEUWsr8RxrCOHUbnL0Dkznf+GyIuQTaOpQy0Cqj0YlNdfgcR 3LVnBOoiDfJdDHmXHamXwHQrwYxD50AP+VlB4VhigfwRX9vdSF9/yUb2OhGhdRFfqtYu x66S21N49Nvy8dr2bnmm0MWK1M5Ut4pDXjvWvkdkBrWm0ztJGba933jNAbf8rjRxhuVf 7QOA== MIME-Version: 1.0 X-Received: by 10.194.63.77 with SMTP id e13mr4138833wjs.104.1404311975353; Wed, 02 Jul 2014 07:39:35 -0700 (PDT) Received: by 10.194.51.131 with HTTP; Wed, 2 Jul 2014 07:39:35 -0700 (PDT) Date: Wed, 2 Jul 2014 16:39:35 +0200 Message-ID: From: Daniel Migault To: "homenet@ietf.org" Content-Type: multipart/alternative; boundary=047d7b86d96271e55404fd36dce6 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/l9nTfCsxv5IP7M9NBSHj42Taj10 Subject: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Wed, 02 Jul 2014 14:39:41 -0000 --047d7b86d96271e55404fd36dce6 Content-Type: text/plain; charset=UTF-8 Hi, Here is a new version of the DHCP Options for Homenet Naming Architecture . DHCP Options are designed so the CPE can automatically outsource its Authoritative DNS Service. [1] We carefully considered the remarks of the DHCP WG in London for the design of the options. We also considered the remarks we received in the Homenet WG more especially: - We removed TSIG for securing transaction between the CPE and the DNS servers. Intead we used SIG(0) - We considered AXFR and Master/Slave mechanisms to outsource the Zone from the CPE to the DNS Server. - We documented how outsourcing can be done on DNS owned/managed by the ISP and by third party DNS providers. The scope of the draft is designing DHCP Option to outsource a Zone from the CPE to the some other DNS. As such we did not discussed: - whether the zone shoudl be signed or not. - how the DS record should be updated. This should be performed by the DNS server hosting the zone, not (necessarily) the CPE. - the cases of internal / external zones This points have not been omitted and will be discussed in draft-mglt-homenet-front-end-naming-delegation. Feel free to make comments! Daniel [1] http://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc-options/ -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7b86d96271e55404fd36dce6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Here is a new v= ersion of the DHCP Options for Homenet Naming Architec= ture. DHCP Options are designed so the CPE can automatically outsource = its Authoritative DNS Service. [1]

We carefully considered the remarks of the DHCP WG in London for = the design of the options. We also considered the remarks we received in th= e Homenet WG more especially:
=C2=A0 =C2=A0 - We removed TSIG for = securing transaction between the CPE and the DNS servers. Intead we used SI= G(0)
=C2=A0 =C2=A0 -=C2=A0 We considered AXFR and Master/Slave mechanisms = to outsource the Zone from the CPE to the DNS Server.
=C2=A0= =C2=A0=C2=A0 - We documented how outsourcing can be done on DNS owned/manag= ed by the ISP and by third party DNS providers.

The scope of the draft is designing DHCP Option to outsource= a Zone from the CPE to the some other DNS. As such we did not discussed:=C2=A0=C2=A0=C2=A0 - whether the zone shoudl be signed or not.
=C2=A0= =C2=A0=C2=A0 - how the DS record should be updated. This should be performe= d by the DNS server hosting the zone, not (necessarily) the CPE.
=C2=A0=C2=A0=C2=A0 - the cases of internal / external zones
<= /div>

This points have not been omitted and will be disc= ussed in draft-mglt-homenet-front-end-naming-delegation.

= Feel free to make comments!

Daniel

<= div>
--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 = 58
--047d7b86d96271e55404fd36dce6-- From nobody Wed Jul 2 08:00: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 E88511A0359 for ; Wed, 2 Jul 2014 08:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] 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 8qX4qvrUVGP9 for ; Wed, 2 Jul 2014 08:00:31 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1: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 0E6AB1A0327 for ; Wed, 2 Jul 2014 08:00:30 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s62F0TIG024180 for ; Wed, 2 Jul 2014 17:00:29 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 4DB752C0947 for ; Wed, 2 Jul 2014 17:00:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id oBiVMt_3eV9P for ; Wed, 2 Jul 2014 17:00:27 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 89DA32C094A for ; Wed, 2 Jul 2014 17:00:27 +0200 (CEST) Date: Wed, 02 Jul 2014 17:00:33 +0200 Message-ID: <87simj7qlq.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: homenet@ietf.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 02 Jul 2014 17:00:29 +0200 (CEST) X-Miltered: at korolev with ID 53B41E8D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53B41E8D.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 53B41E8D.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/vAcZiBQ3tyLXdck5yLULxCfEt_w Subject: [homenet] Babel news X-BeenThere: homenet@ietf.org 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, 02 Jul 2014 15:00:33 -0000 Source-specific routing ======================= We've found a problem with interoperability between source-specific Babel and plain Babel. I don't think the current implementation has the problem, but the current packet format does in principle allow encodings that plain Babel will mis-parse. Rather than setting complex rules that work around the problem, we're planning an incompatible change to the format of source-specific updates. Dave is not pleased. http://mid.gmane.org/E54827C6-2083-49D2-AB79-FF75BE72177D@pps.univ-paris-diderot.fr http://mid.gmane.org/87lhsdysis.wl%25jch@pps.univ-paris-diderot.fr Extension mechanism =================== We're working on formalising the extensions mechanism: http://datatracker.ietf.org/doc/draft-chroboczek-babel-extension-mechanism/ http://tools.ietf.org/html/draft-chroboczek-babel-extension-mechanism The current -01 doesn't specify a policy for TLV and sub-TLV assignments, we're planning on "Specification Required" together with a range of 16 codepoints reserved for experimentation. If you have strong opinions on the subject, please let us know now rather than later. http://mid.gmane.org/8761jgvt3s.wl%25jch@pps.univ-paris-diderot.fr http://mid.gmane.org/CAGnRvuq_PJe1wrcZqaUqwsqpoUH3A4HTcSSsFhQ=H+SLjfaQzg@mail.gmail.com Other drafts ============ In other news, the authentication draft is in AUTH48 (yay!): http://datatracker.ietf.org/doc/draft-ovsienko-babel-hmac-authentication/ http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication there's a first cut at the RTT-based routing (overlay networks) extensions: http://datatracker.ietf.org/doc/draft-jonglez-babel-rtt-extension/ and a very early draft of the radio diversity extensions: http://www.pps.univ-paris-diderot.fr/~jch/software/babel/draft-chroboczek-babel-diversity-routing.html There's still no complete description of the source-specific routing extensions. -- Juliusz From nobody Wed Jul 2 13:38: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 C16AD1B2984 for ; Wed, 2 Jul 2014 13:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_FR=0.35] 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 pqmteB3hCafx for ; Wed, 2 Jul 2014 13:38:33 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1: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 28B501B2957 for ; Wed, 2 Jul 2014 13:38:32 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s62KcVe8002642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 2 Jul 2014 22:38:31 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id s62KcVS9007200; Wed, 2 Jul 2014 22:38:31 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id F2AB22C0993; Wed, 2 Jul 2014 22:38:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id HSesApg_4z7m; Wed, 2 Jul 2014 22:38:30 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C7F7A2C0986; Wed, 2 Jul 2014 22:38:29 +0200 (CEST) Date: Wed, 02 Jul 2014 22:38:35 +0200 Message-ID: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Daniel Migault In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 02 Jul 2014 22:38:31 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 02 Jul 2014 22:38:31 +0200 (CEST) X-Miltered: at korolev with ID 53B46DC7.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 53B46DC7.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53B46DC7.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 53B46DC7.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 53B46DC7.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 53B46DC7.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/CBoLV2St-kSW0vQNE4GtKqRQthA Cc: "homenet@ietf.org" Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Wed, 02 Jul 2014 20:38:34 -0000 Since I saw a previous version of that in London, I've been wondering about one thing, but didn't dare ask. Please be indulgent if it is a stupid question. Why does the CPE need to intervene in what is an application layer interaction between two consenting adults? If I'm setting up a web server on my home network, I'd expect that negotiating a DNS registration is a private matter between the web server and the authoritative DNS master; why would I want the CPE to act as intermediary? Thanks, -- Juliusz From nobody Wed Jul 2 13:50: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 35ECA1B28AD for ; Wed, 2 Jul 2014 13:50: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 zNMiKH6Zhsaf for ; Wed, 2 Jul 2014 13:49:59 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80841B28AC for ; Wed, 2 Jul 2014 13:49:58 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id k15so9401609qaq.16 for ; Wed, 02 Jul 2014 13:49:58 -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=E1cnBSQx1yEKbQfwGo8K+fH7rjx/2Ak4zJaRPEI1bwc=; b=jtex/oQSJ4c66pUqu+QRl7p5rDxAd/4rfmqaVSuKWGeagJ3GUJwdP2hGqaETPxCYok GsXRJtjJZ1r4oSLaZKkog7H6h0H+mQyCzv4Mpxe1O/AXY2vHxxwY6OVIqLwQCBKIFT7g hpT+3czlhSJYuF8BE7+7jh7wTd9l2Qqh9OrqMGoPRcp4FAzQIFeCZG6f5jKsRbFD/6Wl 4dbb5E4uf50NGW/AZEwr69jejaGdj1MCjzb4rJf//8HzRvBVH6Agbakh5SCDzpx36ycy gQHCEWk6ztDVJWBgJ68/n6XM7ao6/ZqneYW2urwJmaSN3oIllXOpScme+DAWFDZIOrV/ euIw== X-Received: by 10.224.29.201 with SMTP id r9mr465226qac.25.1404334197914; Wed, 02 Jul 2014 13:49:57 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id b51sm16942074qgd.49.2014.07.02.13.49.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 13:49:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> Date: Wed, 2 Jul 2014 13:49:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7F29FBCE-1308-425A-85ED-3B10DC554C66@gmail.com> References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/RTIrgIH84k_BIgDQhT5Lu51q5OI Cc: "homenet@ietf.org" , Daniel Migault Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Wed, 02 Jul 2014 20:50:00 -0000 On Jul 2, 2014, at 1:38 PM, Juliusz Chroboczek = wrote: > Since I saw a previous version of that in London, I've been wondering > about one thing, but didn't dare ask. Please be indulgent if it is > a stupid question. >=20 > Why does the CPE need to intervene in what is an application layer > interaction between two consenting adults? If I'm setting up a web = server > on my home network, I'd expect that negotiating a DNS registration is > a private matter between the web server and the authoritative DNS = master; > why would I want the CPE to act as intermediary? Dear Juliusz, That is a very good question. In essence, especially because ULA address use was ignored by the mDNS = proxy scheme, anything reported by mDNS that is routable is to be = published into DNS as a means to establish a routable unicast = alternative to that of mDNS. One major downside is this will end up = including devices never intended to have direct access from the = Internet, where things like an All-in-One printer or baby monitor may = find themselves. Use of a ULA addressing space offers a locally = routable alternative without exposing these devices to the Internet. = Unfortunately, many in the homenet wg consider this to be a problem to = be resolved by the device rather than the homenet protocol. Regards, Douglas Otis= From nobody Wed Jul 2 23:29: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 E5C281B278D for ; Wed, 2 Jul 2014 23:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 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.651, 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 r4ueD9ok8Adp for ; Wed, 2 Jul 2014 23:29:00 -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 CE05E1A0AE1 for ; Wed, 2 Jul 2014 23:28:59 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D16A0A1; Thu, 3 Jul 2014 08:28:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1404368936; bh=hDDSFVbU4e5nTFtc/ilCAwYrY4ZOBGmzOSWiOO3ba4Q=; h=Date:From:To:Subject:In-Reply-To:References:From; b=PfqncdYoDElCGt1IF/Ts4Pfqv5wNCNGlAMJDXNtzvf43AnFlRey7TQZn95ihBk1co 51hvmGBcTbwTqRFrAUwCkLGLGH2Mw5jIy12F0ogYzTibXt795oQhqNhihANf/9GKkc Hz2BhXf5BDoRF8bFOP/PKkWsHGxyReQTRZX4P1dc= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C90FB9F for ; Thu, 3 Jul 2014 08:28:56 +0200 (CEST) Date: Thu, 3 Jul 2014 08:28:56 +0200 (CEST) From: Mikael Abrahamsson To: "homenet@ietf.org" In-Reply-To: <7F29FBCE-1308-425A-85ED-3B10DC554C66@gmail.com> Message-ID: References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <7F29FBCE-1308-425A-85ED-3B10DC554C66@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/uIwgLNDlyx2AL3nRhus5kNfzIfY Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Thu, 03 Jul 2014 06:29:02 -0000 On Wed, 2 Jul 2014, Douglas Otis wrote: > In essence, especially because ULA address use was ignored by the mDNS > proxy scheme, anything reported by mDNS that is routable is to be > published into DNS as a means to establish a routable unicast > alternative to that of mDNS. One major downside is this will end up > including devices never intended to have direct access from the > Internet, where things like an All-in-One printer or baby monitor may > find themselves. Use of a ULA addressing space offers a locally > routable alternative without exposing these devices to the Internet. > Unfortunately, many in the homenet wg consider this to be a problem to > be resolved by the device rather than the homenet protocol. Personally my thinking has been that the service discovery mechanisms and how wide the service discovery information is propagated (and wherefrom and who has access to the services themselves), would be up to policy in the homenet CPEs. I have always envisioned a "control panel" for the home, where (new) devices pops up, and the user has to set up roles or equivalent for these devices, and the roles control how these devices and their services should be handled. I would like to see a lot of this complexity done at the CPE (or a "homenet controller") and not in the individual device. The "controller" would own the policy settings that the user interacts with using for instance a smartphone app and/or a web page. I have been meaning to write down use-cases and examples of my thoughts but I have not done this yet, but I should in the near future. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jul 3 03: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 4789C1B2814 for ; Thu, 3 Jul 2014 03:25:02 -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 ukZHMRKJBiui for ; Thu, 3 Jul 2014 03:24:59 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BD551A04AC for ; Thu, 3 Jul 2014 03:24:59 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so1966326wib.1 for ; Thu, 03 Jul 2014 03:24:57 -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=EwDWY7g362iaV+RofHLSY1tQatw87cm/Gj18txMdtLs=; b=ePKUWMZdBjHtyIH9IMqMirPc0BPm4a7Mv3rx6MJOVk9Q6++BHfxysvHtbOMslhr8Oe QbW7bUBM/XW5K607LIMiuo86UO+Fp92sHVoAE2zCg9KPWN0C7xVKe23g1pYyzocy5jzx /mOZGxGv8oGjdGz2JigiPLlZsjS0LuTudBvjpV+E71YrBH9LCuZZaI+n6A1NVWSTXc3a 3V7H3+epFCw4K58rwB67dRAWEzU1V8a1rUaheBoygzQ03KkFdn5S8HerjAHJyO89RqF4 vdw4m6CKwtPlLtbUNk8oVrNTB8oqehC+JkM2rzEcxz5wCKON4LwE3FmGEnmcXRXyRuDK WrWw== MIME-Version: 1.0 X-Received: by 10.180.90.132 with SMTP id bw4mr40286295wib.42.1404383095683; Thu, 03 Jul 2014 03:24:55 -0700 (PDT) Received: by 10.194.51.131 with HTTP; Thu, 3 Jul 2014 03:24:55 -0700 (PDT) In-Reply-To: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> Date: Thu, 3 Jul 2014 12:24:55 +0200 Message-ID: From: Daniel Migault To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=f46d043c81be8cecc104fd476be7 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/r_hp-g96pz4zcBVgjgx-hSJOP3E Cc: "homenet@ietf.org" Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Thu, 03 Jul 2014 10:25:02 -0000 --f46d043c81be8cecc104fd476be7 Content-Type: text/plain; charset=UTF-8 Hi, Thanks for the question. If I understand it properly, the use case you consider: 1) you set up a web server in your homenet, 2) you want it to be accessed from the outside so you register your domain name and register the IP address to the zone. Note that In this case, the Authoritative Naming service is outsourced to a third party which is what we want to achieve to. Your case is very specific. First your web server is a fixed node that is expected to last at least a few years in your home network. This makes manual configuration feasible. Then you only have one node you may install a specific software that updates the IP address to the DNS authoritative servers. This is to avoid multiple DNS configuration at every IP renumbering. At last you have an interface on your server you may not have with other nodes. On the other hand, if you have multiple devices, you are unlikely to handle / edit the zone manually or install the specific software on each device -- given that some device will not support it. For this reason we would like the CPE to handle this complexity. The advantages I see using the CPE are: - Ease the naming of device of various nature. - CPE remains in the homenet and may be easier to be authenticated than all different devices. - CPE presents a centralized point for end user interactions - CPE are "powerful enough" to handle complex policies... - CPE can integrate multiple protocols to publish a zone. Suppose mDNS is used by a node, than registration of its IP address and name cannot be perfomed on a public authoritative server cannot be performed using mDNS. - .... BR, Daniel On Wed, Jul 2, 2014 at 10:38 PM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > Since I saw a previous version of that in London, I've been wondering > about one thing, but didn't dare ask. Please be indulgent if it is > a stupid question. > > Why does the CPE need to intervene in what is an application layer > interaction between two consenting adults? If I'm setting up a web server > on my home network, I'd expect that negotiating a DNS registration is > a private matter between the web server and the authoritative DNS master; > why would I want the CPE to act as intermediary? > > Thanks, > > -- Juliusz > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --f46d043c81be8cecc104fd476be7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

= Thanks for the question. If I understand it properly, the use case you cons= ider: 1) you set up a web server in your homenet, 2) you want it to be acce= ssed from the outside so you register your domain name and register the IP = address to the zone. Note that In this case, the Authoritative Naming servi= ce is outsourced to a third party which is what we want to achieve to.

Your case is very specific. First your web server is a fixed= node that is expected to last at least a few years in your home network. T= his makes manual configuration feasible. Then you only have one node you ma= y install a specific software that updates the IP address to the DNS author= itative servers. This is to avoid multiple DNS configuration at every IP re= numbering.=C2=A0 At last you have an interface on your server you may not h= ave with other nodes. On the other hand, if you have multiple devices, you = are unlikely to handle / edit the zone manually or install the specific sof= tware on each device -- given that some device will not support it.

For this reason we would like the CPE to handle this complexity. = The advantages I see using the CPE are:
=C2=A0=C2=A0=C2=A0 - = Ease the naming of device of various nature.
=C2=A0=C2=A0=C2=A0 - = CPE remains in the homenet and may be easier to be authenticated than all d= ifferent devices.
=C2=A0=C2=A0=C2=A0 - CPE presents a centralized point for end user in= teractions
=C2=A0=C2=A0=C2=A0 - CPE are "powerful enough"= ; to handle complex policies...
=C2=A0=C2=A0=C2=A0 - CPE can integ= rate multiple protocols to publish a zone. Suppose mDNS is used by a node, = than registration of its IP address and name cannot be perfomed on a public= authoritative server cannot be performed using mDNS.
=C2=A0=C2=A0 - ....

BR,
Daniel




On Wed, Jul 2, 2014 at 10:38 PM, Juliusz Chroboczek <<= a href=3D"mailto:jch@pps.univ-paris-diderot.fr" target=3D"_blank">jch@pps.u= niv-paris-diderot.fr> wrote:

--
Daniel Migault
Orang= e Labs -- Security
+33 6 70 72 69 58
--f46d043c81be8cecc104fd476be7-- From nobody Thu Jul 3 05:14: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 86D2F1B2919 for ; Thu, 3 Jul 2014 05:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35] 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 nYxA_CfbBZFl for ; Thu, 3 Jul 2014 05:14:02 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1: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 BAB751B2916 for ; Thu, 3 Jul 2014 05:14:01 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s63CDxca002145; Thu, 3 Jul 2014 14:13:59 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 8F67C2C0CA1; Thu, 3 Jul 2014 14:13:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 2t5kgq-0E8RF; Thu, 3 Jul 2014 14:13:58 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6286E2C0C8B; Thu, 3 Jul 2014 14:13:58 +0200 (CEST) Date: Thu, 03 Jul 2014 14:14:04 +0200 Message-ID: <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Daniel Migault In-Reply-To: References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 03 Jul 2014 14:13:59 +0200 (CEST) X-Miltered: at korolev with ID 53B54907.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53B54907.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 53B54907.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/m3tmE8m1pt11YIB5yAtWUMFlv3c Cc: "homenet@ietf.org" Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Thu, 03 Jul 2014 12:14:03 -0000 Thanks for your answer, Daniel. > If I understand it properly, the use case you consider: 1) you set up > a web server in your homenet, 2) you want it to be accessed from the > outside so you register your domain name and register the IP address to > the zone. Note that In this case, the Authoritative Naming service is > outsourced to a third party which is what we want to achieve to. No, I think that I'm speaking of the same use case as your draft. (I'm not sure, since your draft takes the use case for granted -- I'm probably missing some background here, sorry for not being more attentive previously.) I've got a device that wants to be advertised in the global DNS (a web server is the obvious example, but it doesn't matter). Your draft suggests (I think) that the device should speak to the CPE which will take care of the interaction with the public DNS (arrow 6 in Figure 1 is missing, by the way). I'd like to understand why the device needs to go through the middleman rather than speaking directly to the authoritative DNS server. My family was poor but honest, Daniel, and NATed addresses were all we could afford. Notwithstanding our difficult conditions, my parents took a lot of care to bring me up to believe that end-to-end is always better than proxying. Since you're advocating proxying, I'd like to understand why you think it is necessary. What is more, I'd like to understand why you require that the proxy be co-located with the CPE. (It could certainly be implemented on the CPE, but I don't understand why the protocol requires that.) You give some good reasons below, and I think they should be included in the draft: >     - Ease the naming of device of various nature. Please explain. >     - CPE remains in the homenet and may be easier to be authenticated > than all different devices. Good point. >     - CPE presents a centralized point for end user interactions I'm not convinced about that, the authoritative DNS master seems like the natural place for end-user interactions. (Note that this does not prevent the CPE's web interface from implementing some sort of proxy to the DNS master's interface.) >     - CPE are "powerful enough" to handle complex policies... Everything is powerful enough nowadays. My abacus has a four-core chip. >     - CPE can integrate multiple protocols to publish a zone. Suppose mDNS is > used by a node, than registration of its IP address and name cannot be > perfomed on a public authoritative server cannot be performed using mDNS. I strongly disagree. I don't want mDNS->DNS proxying. Registering in the global DNS is something that should be under user control, while mDNS is something that happens automatically (for better or worse). -- Juliusz From nobody Thu Jul 3 05:22: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 E9C7B1B293C for ; Thu, 3 Jul 2014 05:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.951 X-Spam-Level: X-Spam-Status: No, score=-4.951 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.651] 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 06lUDfLVSPvt for ; Thu, 3 Jul 2014 05:22:22 -0700 (PDT) Received: from mx1.nominet.org.uk (mail.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 74B8B1B2939 for ; Thu, 3 Jul 2014 05:22:21 -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=mR58VXCf0wUdeujJzqfWcGaSRJkuJ4YvS8hJ8U/eFGlw18ZG4Bo3eoHD WEcH+YyZFQ0bJID2kECjAuBcjPpvv8P2SsF9QM6SRTupWZ/DWEI6Qx/wV KeRRd0NWn53pg0Pd9w2PiOIH06v5SkcRSAygh/cOKAjlCS/SKmOWaNOSN +WGVhPfOyTlfaJWds0oFKfCweVvfEHLBiRis8lin7CGGs1O7DfcQrtPqj 8F3x5eHVFrLA63YlNenKLRUbCTfy5; 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=1404390142; x=1435926142; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EMEzwLZ9GLiE7s/1N/uL10VllnEeKsmpKzssl0OwpuE=; b=mmX39qenpDlh81Gj4GAW4oH3xI0AabhgFhOGClGNL1mTp9fbc3/JlL4/ XWunWR/qu1uST/N41yxGTPkgf6Yl7iOAT6dm4VpW/UEdWHvVhdqmM1y92 RC6DyA30OrqAeITkPIJYi8PcRtHhlQSc37sjp7vAy3ojsGNCuNMnXI1es kYZqXcHS9huwIxOQW/DaYEWg/MrYWbaoGOJaxJnkNG/galC9/pTuJzkIE FHO4lWsHjLlpzSNbDNnlvOMAIymI0; X-IronPort-AV: E=Sophos;i="5.01,595,1400022000"; d="scan'208";a="11146916" X-IPAS-Result: ApcLAENKtVPV+MWR/2dsb2JhbABagmkkgSy+DYgRAYEIFnWEAwEBBAFTJgULAgEIDgQ0MhcOAgQOBYg6CQPIcheObzMHgy2BFgWKFKRjggGBQoIw Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 03 Jul 2014 13:22:20 +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; Thu, 3 Jul 2014 13:22:19 +0100 From: Ray Bellis To: Juliusz Chroboczek Thread-Topic: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt Thread-Index: AQHPljWfaft9JIFAykyOKHHrdAiXg5uOFOGAgAAefwCAAAJOgA== Date: Thu, 3 Jul 2014 12:22:19 +0000 Message-ID: <7989F344-2CC9-4EE4-8FB2-830B5F3CDF4B@nominet.org.uk> References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> In-Reply-To: <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> 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="iso-8859-1" Content-ID: <8721BC02DEDECD4EA1E1B2D364A7144F@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/mA-4m6whDp6_pD3Hv6aVfXUTn8w Cc: "homenet@ietf.org" Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Thu, 03 Jul 2014 12:22:25 -0000 On 3 Jul 2014, at 13:14, Juliusz Chroboczek = wrote: > I'd like to understand why the device needs to go > through the middleman rather than speaking directly to the authoritative > DNS server. [no hat] Juliusz, You may find some useful background in RFC 5625. The essence of it is that in the absence of external connectivity (and ther= efore external DNS servers) the CPE is the ideal place to run DNS services = for the LAN. Unfortunately most vendors made a right mess of their impleme= ntations, although the situation is improving. Ray From nobody Thu Jul 3 05:33: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 C2A091B27B7 for ; Thu, 3 Jul 2014 05:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 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.651, 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 V8mJEkW6p8ap for ; Thu, 3 Jul 2014 05:33:28 -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 BA29A1B2942 for ; Thu, 3 Jul 2014 05:33:25 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2D01CA1; Thu, 3 Jul 2014 14:33:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1404390804; bh=bdcItE0Hm18h4ufUCRDq1gKu0aVxqE4DWibmf8+aNro=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=qshOvHt+xiq8jWN7SoYhnrfjJNeskkGe+/KlFMNZ7KuXx8bOR7w69ECF9bySHR5ty TSA5Na7f3FGnnVD1CQgWq+XzRYErE7UXegi6+GZImOqtROtt9xcaom4cfhjoR6JDrg L80gs+LvqDcqK+41cYd2SNtlp23LQAh8EDvsFmpU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1E3B99F; Thu, 3 Jul 2014 14:33:24 +0200 (CEST) Date: Thu, 3 Jul 2014 14:33:24 +0200 (CEST) From: Mikael Abrahamsson To: Juliusz Chroboczek In-Reply-To: <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> Message-ID: References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.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/jz8W9H6gkevcN4PoQkyT47TXuRs Cc: "homenet@ietf.org" , Daniel Migault Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Thu, 03 Jul 2014 12:33:29 -0000 On Thu, 3 Jul 2014, Juliusz Chroboczek wrote: > missing, by the way). I'd like to understand why the device needs to go > through the middleman rather than speaking directly to the authoritative > DNS server. Isn't the thought that DNS-SD would be used, in that case the device wouldn't need to do anything else apart from announcing the service on the local subnet and the CPE would take care of making sure it would be discoverable globally? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jul 3 05:39: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 A71241B27B7 for ; Thu, 3 Jul 2014 05:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] 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 rYdMhlyTLWys for ; Thu, 3 Jul 2014 05:39:22 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1: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 4EBF41A0045 for ; Thu, 3 Jul 2014 05:39:22 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s63CdKNA018137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Jul 2014 14:39:20 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id s63CdKmC003740; Thu, 3 Jul 2014 14:39:20 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id B96632C0CA2; Thu, 3 Jul 2014 14:39:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 2_dFxREw0sxB; Thu, 3 Jul 2014 14:39:19 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 671F62C0C8B; Thu, 3 Jul 2014 14:39:19 +0200 (CEST) Date: Thu, 03 Jul 2014 14:39:26 +0200 Message-ID: <87egy2y5tt.wl.jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ray Bellis In-Reply-To: <7989F344-2CC9-4EE4-8FB2-830B5F3CDF4B@nominet.org.uk> References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <7989F344-2CC9-4EE4-8FB2-830B5F3CDF4B@nominet.org.uk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 03 Jul 2014 14:39:20 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 03 Jul 2014 14:39:20 +0200 (CEST) X-Miltered: at korolev with ID 53B54EF8.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 53B54EF8.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53B54EF8.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 53B54EF8.003 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 53B54EF8.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 53B54EF8.003 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/_1_9WNmu76UwVeyXb0_v6CnNMAs Cc: "homenet@ietf.org" Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Thu, 03 Jul 2014 12:39:23 -0000 >> I'd like to understand why the device needs to go through the middleman >> rather than speaking directly to the authoritative DNS server. > You may find some useful background in RFC 5625. I'm increasingly confused. RFC 5625 is about proxying DNS requests from the LAN. Daniel's draft is about proxying dynamic DNS updates, right? -- Juliusz From nobody Thu Jul 3 07: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 A1A621B2A00 for ; Thu, 3 Jul 2014 07:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, 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 AHqGHsW_CLke for ; Thu, 3 Jul 2014 07:00:08 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF34F1B29D5 for ; Thu, 3 Jul 2014 07:00:06 -0700 (PDT) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D42A38A031 for ; Thu, 3 Jul 2014 14:00:05 +0000 (UTC) Date: Thu, 3 Jul 2014 10:00:04 -0400 From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20140703140004.GC53048@mx1.yitter.info> References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <7989F344-2CC9-4EE4-8FB2-830B5F3CDF4B@nominet.org.uk> <87egy2y5tt.wl.jch@pps.univ-paris-diderot.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87egy2y5tt.wl.jch@pps.univ-paris-diderot.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/0nBD1UU21dmV0HrqYEmEk_2Z-EY Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Thu, 03 Jul 2014 14:00:11 -0000 On Thu, Jul 03, 2014 at 02:39:26PM +0200, Juliusz Chroboczek wrote: > I'm increasingly confused. RFC 5625 is about proxying DNS requests from > the LAN. Daniel's draft is about proxying dynamic DNS updates, right? Yes. My impression is that the idea in Daniel's draft is that the ISP will take the load of most DNS queries, and will effectively mark a boundary of split-horizon, so that some names resolve both outside and inside the local network, and some will resolve only inside. This is really a formalization of the way many CPE systems already work, where they update services like Dyn (full disclosure: my employer), no-ip, and so on. The differences seem to be (1) that the relationship is somehow stapled to the ISP rather than to an outside service and (2) that the commands all flow over Dynamic Update as opposed to any other protocol. Personally, I see the value in (2), but I'm worried about (1). Thinking as a vendor, I note that (2) basically means ditching a lot of running code, although for a protocol I think is poorly designed. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Jul 3 07:21: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 8D9311B2A0E for ; Thu, 3 Jul 2014 07:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.343 X-Spam-Level: X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, 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 Ds6c1io2bQFC for ; Thu, 3 Jul 2014 07:20:53 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [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 982521B2A46 for ; Thu, 3 Jul 2014 07:20:53 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6DAE420028; Thu, 3 Jul 2014 10:21:24 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2C45763B0E; Thu, 3 Jul 2014 10:20:50 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0FD4D63B0A; Thu, 3 Jul 2014 10:20:50 -0400 (EDT) From: Michael Richardson To: Juliusz Chroboczek In-Reply-To: <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.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/rv_aBBBogrw_GJV50jH9k8Tvoq8 Cc: "homenet@ietf.org" , Daniel Migault Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Thu, 03 Jul 2014 14:20:55 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Juliusz Chroboczek wrote: > I've got a device that wants to be advertised in the global DNS (a web Let's call this device "FredBaby" (with allusions to Breakfast at Tiffanys, which I was reading on the weekend) > server is the obvious example, but it doesn't matter). Your draft > suggests (I think) that the device should speak to the CPE which will > take care of the interaction with the public DNS (arrow 6 in Figure 1= is > missing, by the way). I'd like to understand why the device needs to= go > through the middleman rather than speaking directly to the authoritat= ive > DNS server. The reason why FredBaby device MAY speak to the CPE as the middleman is because: 1) in the homenet we can automate the discovery of CPE / FredBaby, and probably bootstrap a secure relationship between them. 2) the CPE may be managing multiple zones in multiple different ways. For instance, dyndns update to the ISP, dyndns to the DNS provider, stealth primary for the zone, public primary for the zone. 3) we may be able to bootstrap the secure relationship between the CPE device some of the forward zones with the ISP, and definitely will do that for the reverse zone with the ISP. FredBaby will have no relationship with the ISP(s). 4) the CPE will know about all the other devices that want their name managed, such as Rusty, Yunioshi, Sally. In particular the CPE will also know about brother-FredBaby, the device which you are replacing, but haven't yet turned off. You'll therefore be able to see all the various attempts to publish in one place and decide who gets priority, and which devices ("Sally" the Tomato), you weren't supposed to publish your relationship with. > My family was poor but honest, Daniel, and NATed addresses were all we > could afford. Notwithstanding our difficult conditions, my parents t= ook > a lot of care to bring me up to believe that end-to-end is always bet= ter LUXURY! >> =C2=A0=C2=A0=C2=A0 - CPE presents a centralized point for end user i= nteractions > I'm not convinced about that, the authoritative DNS master seems like= the > natural place for end-user interactions. (Note that this does not > prevent > the CPE's web interface from implementing some sort of proxy to the D= NS > master's interface.) I'm not sure I understand where the authoritative DNS master is. I don't think that Daniel is demanding the CPE be the only possible answer, and perhaps within HNCP we should be passing around the address of the homenet authoritative DNS master, as if there are multiple CPE they might need to argue about it too. >> =C2=A0=C2=A0=C2=A0 - CPE can integrate multiple protocols to publish= a zone. Suppose >> mDNS is >> used by a node, than registration of its IP address and name cannot = be >> perfomed on a public authoritative server cannot be performed using = mDNS. > I strongly disagree. I don't want mDNS->DNS proxying. Registering in > the > global DNS is something that should be under user control, while mDNS > is something that happens automatically (for better or worse). I think that this is the reason why we want it proxied; so that we have a filter. That's why FredBaby shouldn't talk to some out-of-home DNS master directly. I think that populating DNS from mDNS could well be turned off by default, and enabled in a UI on a per name basis. =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) iQEVAwUBU7Vmv4CLcPvd0N1lAQIW9gf+J/shhMEnCpXRoyBFjE2vLixzQwyn2VPy 4Az1DITejeolEnR90GmLWJNJJPAnlKYtuvfPl1c+uVITDSLShqAYbEiRg2s8ZVUb l0pE61pEIedFNTxLkUjDuzH6i0kUEWHEEly2ri84l21veme9MWaN9Mmzj+jy7mCv P5FYOpDZDTCIlIikfegpcjHdlTmMGWepv0x19S0TVst/h2M5SgOnw27WVV31o36F idEVx52y2KzsAmjj94NzF2uAXFUF0W79gHMleeY4+XXJF8Xzfp49a9ePXTRrDAsB ZzTXdJTjMhh1z+mQ8IQDUJ8h8hbcdm4pr+uaEmYSlC4c1sbarUzxHg== =pm/c -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 3 14: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 F0FD41B29F5 for ; Thu, 3 Jul 2014 14:44:04 -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 cVfKXmHkrQQw for ; Thu, 3 Jul 2014 14:44:02 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F51A1A03F4 for ; Thu, 3 Jul 2014 14:44:02 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id eu11so863514pac.19 for ; Thu, 03 Jul 2014 14:44:02 -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 :message-id:references:to; bh=NIvbVBkZjfjdr4pXHgqfUaiLgWxRF+z++sR3iqlI6T8=; b=FXa+xs7hgScx86PxzxiLv8JW6WtUxr3TWNDwmxJBGHisRTEq5K0K16tNXbTEPlrzCJ lCCGZ6ZOvjdDS335kVfQnqiWRCVdyyuBu9ww0NxY1JOkiOpbeVydDYzLpzW7V2TnzSDM N9l1eeDhpC5rQFmYwk4qaHHvx4cAgsJQFuJog6EdlpuAVH44z3kooySqP/opRseeWoQj Fl7HdFDk9H3tDumRtkqGyXMP/ty+ApUw1t+3SdIFFvw7KEvuKjClXaqDTqYLvaqExy94 d2Rp9v+MUNo3rIg/YLI2Nfh+IolvsJdcBM0dNnXJZAGP06EroCtZ28aV/cQPQ9fWpPFi A4eg== X-Received: by 10.70.36.135 with SMTP id q7mr6500023pdj.79.1404423842036; Thu, 03 Jul 2014 14:44:02 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id ia2sm42045520pbb.32.2014.07.03.14.44.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 14:44:01 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_03A912B7-9031-4E07-BBED-F7ADAFFC73F1" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: <20140703140004.GC53048@mx1.yitter.info> Date: Thu, 3 Jul 2014 14:43:59 -0700 Message-Id: <9E7F2E30-8F86-46A4-B2B4-7AFAF2F2C41A@gmail.com> References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <7989F344-2CC9-4EE4-8FB2-830B5F3CDF4B@nominet.org.uk> <87egy2y5tt.wl.jch@pps.univ-paris-diderot.fr> <20140703140004.GC53048@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/f9j1Hcqr190cGXyWCHY9hxnZuwE Cc: homenet@ietf.org Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Thu, 03 Jul 2014 21:44:05 -0000 --Apple-Mail=_03A912B7-9031-4E07-BBED-F7ADAFFC73F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 3, 2014, at 7:00 AM, Andrew Sullivan = wrote: > On Thu, Jul 03, 2014 at 02:39:26PM +0200, Juliusz Chroboczek wrote: >> I'm increasingly confused. RFC 5625 is about proxying DNS requests = from >> the LAN. Daniel's draft is about proxying dynamic DNS updates, = right? >=20 > Yes. My impression is that the idea in Daniel's draft is that the ISP > will take the load of most DNS queries, and will effectively mark a > boundary of split-horizon, so that some names resolve both outside and > inside the local network, and some will resolve only inside. This is > really a formalization of the way many CPE systems already work, where > they update services like Dyn (full disclosure: my employer), no-ip, > and so on. The differences seem to be (1) that the relationship is > somehow stapled to the ISP rather than to an outside service and (2) > that the commands all flow over Dynamic Update as opposed to any other > protocol. Personally, I see the value in (2), but I'm worried about > (1). Thinking as a vendor, I note that (2) basically means ditching a > lot of running code, although for a protocol I think is poorly > designed. Dear Andrew, Since mDNS is unable to make determinations regarding the ability of a = device to safely interact with the Internet, an overlay approach could = be taken. Although details are missing from the Hybrid = Unicast/Multicast DNS-Based Service Discovery draft, use of ULAs can = better establish a secure separation than can a split-horizon. DNS was = never intended to keep information private, especially within an = environment having uncertain network boundaries with informal input = schemes. Use of ULAs can replicate the securities permitted by use of = link-local by mDNS while also permitting continued operation when ISP = up-links are disrupted.=20 For some references see: https://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink Regards, Douglas Otis --Apple-Mail=_03A912B7-9031-4E07-BBED-F7ADAFFC73F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jul 3, 2014, at 7:00 AM, Andrew = Sullivan <ajs@anvilwalrusden.com> = wrote:

On Thu, Jul 03, 2014 at 02:39:26PM +0200, Juliusz = Chroboczek wrote:
I'm increasingly = confused.  RFC 5625 is about proxying DNS requests from
the LAN. =  Daniel's draft is about proxying dynamic DNS updates, = right?

Yes.  My impression is that the idea in = Daniel's draft is that the ISP
will take the load of most DNS = queries, and will effectively mark a
boundary of split-horizon, so = that some names resolve both outside and
inside the local network, = and some will resolve only inside.  This is
really a = formalization of the way many CPE systems already work, where
they = update services like Dyn (full disclosure: my employer), no-ip,
and = so on.  The differences seem to be (1) that the relationship = is
somehow stapled to the ISP rather than to an outside service and = (2)
that the commands all flow over Dynamic Update as opposed to any = other
protocol.  Personally, I see the value in (2), but I'm = worried about
(1).  Thinking as a vendor, I note that (2) = basically means ditching a
lot of running code, although for a = protocol I think is = poorly
designed.

Dear = Andrew,

Since mDNS is unable to make = determinations regarding the ability of a device to safely interact with = the Internet, an overlay approach could be taken.  Although details = are missing from the Hybrid Unicast/Multicast DNS-Based Service = Discovery draft, use of ULAs can better establish a secure separation = than can a split-horizon.  DNS was never intended to keep = information private, especially within an environment having uncertain = network boundaries with informal input schemes.  Use of ULAs can = replicate the securities permitted by use of link-local by mDNS while = also permitting continued operation when ISP up-links are = disrupted. 

For some references = see:

Regards,
Douglas = Otis






= --Apple-Mail=_03A912B7-9031-4E07-BBED-F7ADAFFC73F1-- From nobody Thu Jul 3 21:58: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 5AF8F1B2BDF for ; Thu, 3 Jul 2014 21:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 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.651, 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 pcppXOTvYhno for ; Thu, 3 Jul 2014 21:58:40 -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 082E81B2BDE for ; Thu, 3 Jul 2014 21:58:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 436A3A1; Fri, 4 Jul 2014 06:58:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1404449918; bh=Gr9n30VZyYnez3M9Cud/CRwKFeZOHa/SexjtwurUVrc=; h=Date:From:To:Subject:In-Reply-To:References:From; b=KVnaRIrH+JDs9sM0BpmBhKDAAr7FYiHBERvuNHDpteZ0iyeFMaEYjP1HJ/68dqvuL KUU37TspXcJI2ON1hJsf9LJ4hpluDYh9lejczQ+zXrL7csXGIEvQG43BoRzZCGLXnw G+AqLO5Mimnl86QFGzEcfKsNKVtTFSmLKNPvBEpE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 392569F for ; Fri, 4 Jul 2014 06:58:38 +0200 (CEST) Date: Fri, 4 Jul 2014 06:58:38 +0200 (CEST) From: Mikael Abrahamsson To: homenet@ietf.org In-Reply-To: <9E7F2E30-8F86-46A4-B2B4-7AFAF2F2C41A@gmail.com> Message-ID: References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <7989F344-2CC9-4EE4-8FB2-830B5F3CDF4B@nominet.org.uk> <87egy2y5tt.wl.jch@pps.univ-paris-diderot.fr> <20140703140004.GC53048@mx1.yitter.info> <9E7F2E30-8F86-46A4-B2B4-7AFAF2F2C41A@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/fDG3zkVvbGVDzaSI8aszYPsxlgo Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Fri, 04 Jul 2014 04:58:42 -0000 On Thu, 3 Jul 2014, Douglas Otis wrote: > Since mDNS is unable to make determinations regarding the ability of a > device to safely interact with the Internet, an overlay approach could > be taken. Although details are missing from the Hybrid > Unicast/Multicast DNS-Based Service Discovery draft, use of ULAs can > better establish a secure separation than can a split-horizon. DNS was I would very much prefer to see a solution where you can have policy to limit what is being published and to where, rather than the very binary "use ULAs for Internal resources". Apart from the fact that I do not like ULAs, I would also like to see more granularity and to enable the possibility to have zoning within the home network, for instance to have guest networks. So we need to enable possibility to control propagation of service discovery information, we need packet filtering, and we also need some kind of "identity" for the devices so they can interact with all of this. -- Mikael Abrahamsson email: swmike@swm.pp.se From xavier.bonnetain.2011@polytechnique.org Fri Jul 4 05:31: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 2AFF91B28A5 for ; Fri, 4 Jul 2014 05:31:55 -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 6-lr9d6o67dN for ; Fri, 4 Jul 2014 05:31:53 -0700 (PDT) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AC4E1B2864 for ; Fri, 4 Jul 2014 05:31:52 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h15so2299150igd.8 for ; Fri, 04 Jul 2014 05:31:52 -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:from:date:message-id:subject:to :content-type; bh=ZlHOBeyt+rQPcJUBAWxq0IB0OZ8wUZz1S9VCzRkIs7Q=; b=UGZcE7EIsxf4QmSyWWr7ZTjO2Q7GUivu0L/TqrV1uCel53o33HReRXHFVR6PUnvX5S vIqU/YY0T+RC5ZP1XKx+WfR6F1U1NTZJH0hzQqKaGXlZAV+BcUYWa/Ebp+5SSOMRRUtt FecXFFtTI16DJxALuw6fljxUG30bfytApJ7wLy6fM/7IcLULqcQGjF4IJgFXWKFqTZzQ RP46r1tb6T8r8nI6rqYOAcQYwYKTkKb8DrCPlZhS5Ydz+R3VyTg0VD/fSMNpD7Msl5d1 t5DBR4iCbpIU7Zm5FTo5+Q033EMT88EK7mhu8lpUhm3GuqqMnbj5VOKIRYnmcQFroAoV nVwA== X-Gm-Message-State: ALoCoQlUkh0Al96WgSJaVUZek2+h2EIqawsnXD4MRE4ywZChuNq5EWjDI6ZIuRoHsZ1u0fpo5Kwt X-Received: by 10.50.136.135 with SMTP id qa7mr34275613igb.21.1404477111955; Fri, 04 Jul 2014 05:31:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.63.82 with HTTP; Fri, 4 Jul 2014 05:31:31 -0700 (PDT) From: Bonnetain Date: Fri, 4 Jul 2014 14:31:31 +0200 Message-ID: To: homenet@ietf.org Content-Type: multipart/alternative; boundary=089e0149c10c5a871404fd5d4f0e Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/KuuIPOcu_Fd2s7UofstpDaP_gG4 Subject: [homenet] New draft : draft-bonnetain-hncp-security X-BeenThere: homenet@ietf.org 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, 04 Jul 2014 12:37:07 -0000 --089e0149c10c5a871404fd5d4f0e Content-Type: text/plain; charset=UTF-8 Hi guys, Working with Markus Stenberg, Pierre Pfister and Steven Barth, I've written a draft to add some security in HNCP. It's available at http://tools.ietf.org/html/draft-bonnetain-hncp-security-00 . What do you think of it ? Xavier Bonnetain --089e0149c10c5a871404fd5d4f0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi guys,

Working with Mar= kus Stenberg, Pierre Pfister and Steven Barth, I've written a draft to = add some security in HNCP.

It's available at http://tools.ietf.org/html/draft-bonnetain-hncp-security-00 .

What do you think of it ?

Xavier Bonnetain
--089e0149c10c5a871404fd5d4f0e-- From nobody Fri Jul 4 05:46: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 B10B81B28BA for ; Fri, 4 Jul 2014 05:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 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.651, 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 eFroUH9BdBJi for ; Fri, 4 Jul 2014 05:46:01 -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 45E301B28DF for ; Fri, 4 Jul 2014 05:46:01 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 518B1A1; Fri, 4 Jul 2014 14:45:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1404477959; bh=Ganyb86ZO3G+UOH0Yzg/C23/ejD9sJ61F3b8USa6NTM=; h=Date:From:To:Subject:In-Reply-To:References:From; b=2ZDAssSXu5QwkGJDq5ONVp91XU48pooZxzg+SBmXsrcIMA0YhMF0jhTnJIg1bS9od rLERbY75tiM+kc8G6tLK9poZ1+mH70cPi5LY+/ewescX9tDQ8VpxkNbz/Spn3Ek/lr pvkXCQdQxtAvU1z8ZuX9P6nzhG2Cb/jDlFFibzFs= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4874E9F for ; Fri, 4 Jul 2014 14:45:59 +0200 (CEST) Date: Fri, 4 Jul 2014 14:45:59 +0200 (CEST) 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/_dDy_lUcZYPD0fMOZ4mxMrjJXM4 Subject: Re: [homenet] New draft : draft-bonnetain-hncp-security X-BeenThere: homenet@ietf.org 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, 04 Jul 2014 12:46:03 -0000 On Fri, 4 Jul 2014, Bonnetain wrote: > What do you think of it ? I am not good enough in this area to validate that the draft actually does the right things from a security context, but it looks like we in the homenet WG are getting very close to what they're doing in the "Autonomic Networking Integrated Model and Approach" ANIMA http://www.ietf.org/mail-archive/web/homenet/current/msg03639.html I think we need to decide how to relate to their work, ignore it, try to steer both work efforts so we have some communality, or split up the work (or something else). -- Mikael Abrahamsson email: swmike@swm.pp.se From SRS0=mLgV=37=darou.fr=pierre.pfister@bounces.m4x.org Fri Jul 4 07:10: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 35F501B29B5 for ; Fri, 4 Jul 2014 07:10:25 -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 15sPH7zIqm0C for ; Fri, 4 Jul 2014 07:10: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 7B1D71B29B3 for ; Fri, 4 Jul 2014 07:10:18 -0700 (PDT) Received: from [10.148.10.22] (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 A287F1408EFA0; Fri, 4 Jul 2014 16:10:15 +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, 4 Jul 2014 16:10:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1878.6) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Fri Jul 4 16:10:16 2014 +0200 (CEST)) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/QLPQ4QM033zkH15g7wv_6QPGZeU Cc: HOMENET Subject: Re: [homenet] New draft : draft-bonnetain-hncp-security X-BeenThere: homenet@ietf.org 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, 04 Jul 2014 14:10:47 -0000 Hello Mikael, There is indeed a quite large common basis between Homenet and ANIMA = problem spaces. It appears that Homenet is one of the case that is = presented as a possible use-case for the UCAN BoF = (draft-carpenter-nmrg-homenet-an-use-case). IMHO, these similarities will have to be discussed in Toronto. = Particularly, one issue is that UCAN is at an earlier stage of = specification as well as it seems to target a more general problem. They = are proposing a different configuration protocol: CDNP, which can result = in the same features as HNCP, but with a very different design. If we = had to summarize, HNCP is a database synchronization protocol while CDNP = is a generic negotiation protocol, which is practically the same = theoretically as you can share data thought negotiation and negotiate = through data sharing (which is an approach widely used in the HNCP=92s = prefix assignment algorithm). Nevertheless, most of the considerations we need to discuss related to = Homenet and ANIMA are *not* specific to security considerations. So, back to security, CDNP proposes to establish authorization based on = a single CA for large networks and based on automatic processes for = small networks (These processes are said to be out of the scope of the = CDNP draft).=20 On the other hand, HNCP security as defined in the proposed draft relies = on generic trust relationships. These relationships could be established = through different means. Centralized, decentralized, managed from the = network or from a server outside the network, from one or multiple = authorities, etc=85 This is, IMHO, important in order to offer vendors = the largest flexibility in the way they want to manage their customer=92s = networks. =91Whether we use CNDP instead of HNCP' and =91how to secure HNCP=92 are = orthogonal problems. So I=92m not sure this is the right thread to = compare ANIMA and Homenet. But if anyone thinks we should enforce the = use of X.509 certificates, or have a different approach on how to secure = HNCP, we are open to suggestions. Pierre=20 Le 4 juil. 2014 =E0 14:45, Mikael Abrahamsson a =E9crit= : > On Fri, 4 Jul 2014, Bonnetain wrote: >=20 >> What do you think of it ? >=20 > I am not good enough in this area to validate that the draft actually = does the right things from a security context, but it looks like we in = the homenet WG are getting very close to what they're doing in the = "Autonomic Networking Integrated Model and Approach" ANIMA >=20 > http://www.ietf.org/mail-archive/web/homenet/current/msg03639.html >=20 > I think we need to decide how to relate to their work, ignore it, try = to steer both work efforts so we have some communality, or split up the = work (or something else). >=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 Fri Jul 4 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 582C61B2CE0 for ; Fri, 4 Jul 2014 07:41:58 -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 LKytRVk12klr for ; Fri, 4 Jul 2014 07:41:56 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c: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 4BC6B1B2D02 for ; Fri, 4 Jul 2014 07:41:56 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id t60so1794213wes.18 for ; Fri, 04 Jul 2014 07:41:54 -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=WOiA4UqvIoUovhSO42D8pdGvD8h1Mbd4uCrNIyG7m1M=; b=vmQaBYkKCZ8ztO2+20dLdE8QPmYOAK3wMkCWwtBeb54H656RdueWeTeCNjfI4GQ38k VC4L7QddGkYAdC/4oISN0XLA1qqD6OjypsdX+HPu1OklL5qpKDGKd8jIDvQeZL2dK5Xs NNCuO0cUB2FyCWCdvBch8TEIRCduzGhdg1OP9j5ElIDVuLAle7bZAnbJGaQkH8huURqS /cJsBa7M/2kKscohov2iNozlT5LTLl8DOjobydH1o6Fgg3QSPK9RFJ0LI1Mue8A1ZUSX KMbZen8NLGqA6oCpl85PNi9rdyoqbTttXm6cGAdbUA4YgSw2ZDGE5JUwgaFADnMI4TCs HMcA== MIME-Version: 1.0 X-Received: by 10.180.106.66 with SMTP id gs2mr18942599wib.5.1404484914791; Fri, 04 Jul 2014 07:41:54 -0700 (PDT) Received: by 10.194.51.131 with HTTP; Fri, 4 Jul 2014 07:41:54 -0700 (PDT) Date: Fri, 4 Jul 2014 16:41:54 +0200 Message-ID: From: Daniel Migault To: "homenet@ietf.org" Content-Type: multipart/alternative; boundary=f46d04451a0d704af104fd5f2022 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/zA4mYjy-OZgDo1WAZ4fX3fnw1Ms Subject: [homenet] Fwd: New Version Notification for draft-mglt-homenet-front-end-naming-delegation-04.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, 04 Jul 2014 14:41:58 -0000 --f46d04451a0d704af104fd5f2022 Content-Type: text/plain; charset=UTF-8 Hi, Please find the description of the architecture that enables a CPE to outsource the authoritative naming service on the Internet to a Public Authoritative Server. This version considers the comments we received on the mailing list for signing the zone. We clearly explain the pros and cons for signing the zone by the CPE and by the Public Authoritative Servers. We also clarify how multiple views should be handled by the CPE as this issue has been raised. Feel free top make comments. Just to clarify the position of draft-mglt-homenet-front-end-naming-delegation-04.txt and draft-mglt-homenet-naming-architecture-dhc-options-02.txt: - draft-mglt-homenet-front-end-naming-delegation-04.txt describes the architecture we recommend for the CPE to outsource the DNS Homenet Zone - draft-mglt-homenet-naming-architecture-dhc-options-02.txt: provides DHCP Options so the architecture can be (almost) automatically set. BR Daniel -------- Original Message -------- Subject: New Version Notification for draft-mglt-homenet-front-end-naming-delegation-04.txt Date: Fri, 4 Jul 2014 07:30:03 -0700 From: To: Ralf Weber , Chris Griffiths , Wouter Cloetens , Chris Griffiths , Ralf Weber , Daniel Migault , Wouter Cloetens , Daniel Migault A new version of I-D, draft-mglt-homenet-front-end-naming-delegation-04.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-homenet-front-end-naming-delegation Revision: 04 Title: Outsourcing Home Network Authoritative Naming Service Document date: 2014-07-04 Group: Individual Submission Pages: 21 URL: http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-04.txt Status: https://datatracker.ietf.org/doc/draft-mglt-homenet-front-end-naming-delegation/ Htmlized: http://tools.ietf.org/html/draft-mglt-homenet-front-end-naming-delegation-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-mglt-homenet-front-end-naming-delegation-04 Abstract: CPEs are designed to provide IP connectivity to home networks. Most CPEs assign IP addresses to the nodes of the home network which makes it a good candidate for hosting the naming service. With IPv6, the naming service makes nodes reachable from the home network as well as from the Internet. However, CPEs have not been designed to host such a naming service exposed on the Internet. This may expose the CPEs to resource exhaustion which would make the home network unreachable, and most probably would also affect the home network inner communications. In addition, DNSSEC management and configuration may not be well understood or mastered by regular end users. Misconfiguration may also results in naming service disruption, thus these end users may prefer to rely on third party naming providers. This document describes a homenet naming architecture where the CPEs manage the DNS zone associates to its home network, and outsources the naming service and eventually the DNSSEC management on the Internet to a third party designated as the Public Authoritative Servers. 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. The IETF Secretariat -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --f46d04451a0d704af104fd5f2022 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please find the= description=20 of the architecture that enables a CPE to outsource the authoritative=20 naming service on the Internet to a Public Authoritative Server.

This version considers the comments we received on the mailing list for=20 signing the zone. We clearly explain the pros and cons for signing the=20 zone by the CPE and by the Public Authoritative Servers. We also clarify how multiple views should be handled by the CPE as this issue has been=20 raised.

Feel free top make comments.

Just to= clarify the position of draft-mglt-homenet-front-end-naming-delegation-04.= txt and draft-mglt-homenet-naming-architecture-dhc-options-02.txt:

  • draft-mglt-homenet-front-end-naming-delegation-04.txt describes= the architecture we recommend for the CPE to outsource the DNS Homenet Zon= e
  • draft-mglt-homenet-naming-architecture-dhc-options-02.txt: provid= es DHCP Options so the architecture can be (almost) automatically set.

BR
Daniel


-------- Original Message --------
Subject: New Version Notification for draft-mglt-homenet-front-end-naming-delegation-04.txt
Date: Fri, 4 Jul 2014 07:30:03 -0700
From: <internet-drafts@ietf.org>
To: Ralf Weber <ralf.weber@nominum.com>, Chris Griffiths <cgriffiths@dyn.com>, Wouter Cloetens <wouter.cloetens@softathome.com>, Chris Griffiths <c= griffiths@dyn.com>, Ralf Weber &= lt;ralf.weber@nominum.com>, Daniel Migault <daniel.migault@orange.com>, Wouter Cloetens <wouter.cloetens@softathome.com>, Daniel Migault <daniel.migault@orange.com> 


A new version of I-D, draft-mglt-homenet-front-end-naming-delega=
tion-04.txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Name:		draft-mglt-homenet-front-end-naming-delegation
Revision:	04
Title:		Outsourcing Home Network Authoritative Naming Service
Document date:	2014-07-04
Group:		Individual Submission
Pages:		21
URL:            http://www.iet=
f.org/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-04.txt=

Status:         https://datatracker.iet=
f.org/doc/draft-mglt-homenet-front-end-naming-delegation/
Htmlized:       http://tools.ietf.org/html/=
draft-mglt-homenet-front-end-naming-delegation-04
Diff:           http://www.ietf.org=
/rfcdiff?url2=3Ddraft-mglt-homenet-front-end-naming-delegation-04

Abstract:
   CPEs are designed to provide IP connectivity to home networks.  Most
   CPEs assign IP addresses to the nodes of the home network which makes
   it a good candidate for hosting the naming service.  With IPv6, the
   naming service makes nodes reachable from the home network as well as
   from the Internet.

   However, CPEs have not been designed to host such a naming service
   exposed on the Internet.  This may expose the CPEs to resource
   exhaustion which would make the home network unreachable, and most
   probably would also affect the home network inner communications.

   In addition, DNSSEC management and configuration may not be well
   understood or mastered by regular end users.  Misconfiguration may
   also results in naming service disruption, thus these end users may
   prefer to rely on third party naming providers.

   This document describes a homenet naming architecture where the CPEs
   manage the DNS zone associates to its home network, and outsources
   the naming service and eventually the DNSSEC management on the
   Internet to a third party designated as the Public Authoritative
   Servers.

                                                                           =
      =20


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat





--
Daniel Migault
Orange Labs -- Sec= urity
+33 6 70 72 69 58
--f46d04451a0d704af104fd5f2022-- From nobody Fri Jul 4 08:27: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 6B9BA1B29EC for ; Fri, 4 Jul 2014 08:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 jQRMK0UxjMzJ for ; Fri, 4 Jul 2014 08:27:04 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7C51B2850 for ; Fri, 4 Jul 2014 08:27:04 -0700 (PDT) Received: from [192.168.43.232] (mobile-166-137-181-233.mycingular.net [166.137.181.233]) by toccata.fugue.com (Postfix) with ESMTPSA id C1B092380895; Fri, 4 Jul 2014 11:27:03 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Fri, 4 Jul 2014 08:27:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Bonnetain X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/wsOOLCWlsARNR1B9ds7nzwq_8LI Cc: homenet@ietf.org Subject: Re: [homenet] New draft : draft-bonnetain-hncp-security X-BeenThere: homenet@ietf.org 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, 04 Jul 2014 15:27:06 -0000 On Jul 4, 2014, at 5:31 AM, Bonnetain = wrote: > What do you think of it ? I think the text on establishing trust needs a lot of work. We had a = really good discussion about this about a year or two ago that captured = some of the ways you can establish trust fairly safely. I don't think = the "push a button, trust everything" model is a good idea, and I don't = agree that this can just be left up to the implementation, because it's = really the core of HNCP security: if we get it wrong, no amount of = cryptography is going to help. That said, thanks for writing the document--it definitely provides a = good starting point to work from! From nobody Fri Jul 4 12:25: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 B479B1B2B70; Fri, 4 Jul 2014 12:25:31 -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 fuYvm4O3nu08; Fri, 4 Jul 2014 12:25:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D545F1B2EFF; Fri, 4 Jul 2014 12:25:27 -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.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704192527.14472.75210.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 12:25:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/vzrd0r-YhEVfRxDMI6ms544Gtb8 Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-arch-17.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, 04 Jul 2014 19:25:31 -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 : IPv6 Home Networking Architecture Principles Authors : Tim Chown Jari Arkko Anders Brandt Ole Troan Jason Weil Filename : draft-ietf-homenet-arch-17.txt Pages : 54 Date : 2014-07-04 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-arch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-arch-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-17 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 Fri Jul 4 13:34: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 AC73A1B2F6D for ; Fri, 4 Jul 2014 13:34: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 AQotTf_RdfMv for ; Fri, 4 Jul 2014 13:34:32 -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 C704D1B2A12 for ; Fri, 4 Jul 2014 13:34:32 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id ey11so2348835pad.26 for ; Fri, 04 Jul 2014 13:34: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=NRiT7GuzcGgAnXCtw3J7bA7ESnv9ROYFhXl2Ny3vysA=; b=Wu0dPMPSHnB+PHbpI0d4U77yZa/uKjc6R1IrfDok7z4INrqUZMH1HjoGjZWBX1d/te 8/c2RZEo6X15EIGLH91JO1rKVVUXJEVkXobK6dDzyk5Yq3dAedZPrOoT7YDbby7LIS34 cidMWkfsedJDRUGWE3B3lu3QoA7tz3XTbaH1E+5e/5CWjLGzgm3DXDZgTL/3tym3Txps fFWxKiNWRAIWJlgmqZlvOhgS/I9dGWzhyMezl7vtjgzCjaxYBb4eJoxU5T0w9BXgmC9T IsPFTFLoeQsp+HqJ7xMTlXPrM2WMZTgDyDKoxOIgwNGSYYM7Mx1rz1jziyEa5h+NdZpC jyzg== X-Received: by 10.68.166.36 with SMTP id zd4mr12780016pbb.54.1404506072269; Fri, 04 Jul 2014 13:34:32 -0700 (PDT) Received: from [192.168.178.23] (24.198.69.111.dynamic.snap.net.nz. [111.69.198.24]) by mx.google.com with ESMTPSA id kn1sm45083475pbd.13.2014.07.04.13.34.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Jul 2014 13:34:31 -0700 (PDT) Message-ID: <53B70FE2.4020806@gmail.com> Date: Sat, 05 Jul 2014 08:34:42 +1200 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: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Fp33hgu1lk7qbMFN4D4RfRXRhgU Cc: HOMENET , Mikael Abrahamsson Subject: Re: [homenet] New draft : draft-bonnetain-hncp-security X-BeenThere: homenet@ietf.org 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, 04 Jul 2014 20:34:34 -0000 On 05/07/2014 02:10, Pierre Pfister wrote: > Hello Mikael, >=20 > There is indeed a quite large common basis between Homenet and ANIMA pr= oblem spaces. It appears that Homenet is one of the case that is presente= d as a possible use-case for the UCAN BoF (draft-carpenter-nmrg-homenet-a= n-use-case). Yes. But I'll repeat here what I've said in private mail: using homenet as a use case for autonomic networking is not intended to derail HNCP. It's also a little different from "mainstream" autonomic networking which is aimed at larger networks. > IMHO, these similarities will have to be discussed in Toronto. Particul= arly, one issue is that UCAN is at an earlier stage of specification as w= ell as it seems to target a more general problem. They are proposing a di= fferent configuration protocol: CDNP, which can result in the same featur= es as HNCP, but with a very different design. If we had to summarize, HNC= P is a database synchronization protocol while CDNP is a generic negotiat= ion protocol, which is practically the same theoretically as you can shar= e data thought negotiation and negotiate through data sharing (which is a= n approach widely used in the HNCP=E2=80=99s prefix assignment algorithm)= =2E To be clear, UCAN is not even a WG forming BOF, and CNP (now renamed CDNP) is probably only one proposal among several. But indeed, please attend the UCAN BOF as well as homenet. However, the homenet use case is only one among 7 use cases on the table in UCAN. Brian > Nevertheless, most of the considerations we need to discuss related to = Homenet and ANIMA are *not* specific to security considerations. >=20 > So, back to security, CDNP proposes to establish authorization based on= a single CA for large networks and based on automatic processes for smal= l networks (These processes are said to be out of the scope of the CDNP d= raft).=20 >=20 > On the other hand, HNCP security as defined in the proposed draft relie= s on generic trust relationships. These relationships could be establishe= d through different means. Centralized, decentralized, managed from the n= etwork or from a server outside the network, from one or multiple authori= ties, etc=E2=80=A6 This is, IMHO, important in order to offer vendors the= largest flexibility in the way they want to manage their customer=E2=80=99= s networks. >=20 > =E2=80=98Whether we use CNDP instead of HNCP' and =E2=80=98how to secur= e HNCP=E2=80=99 are orthogonal problems. So I=E2=80=99m not sure this is = the right thread to compare ANIMA and Homenet. But if anyone thinks we sh= ould enforce the use of X.509 certificates, or have a different approach = on how to secure HNCP, we are open to suggestions. >=20 >=20 > Pierre=20 >=20 >=20 >=20 >=20 > Le 4 juil. 2014 =C3=A0 14:45, Mikael Abrahamsson a =C3= =A9crit : >=20 >> On Fri, 4 Jul 2014, Bonnetain wrote: >> >>> What do you think of it ? >> I am not good enough in this area to validate that the draft actually = does the right things from a security context, but it looks like we in th= e homenet WG are getting very close to what they're doing in the "Autonom= ic Networking Integrated Model and Approach" ANIMA >> >> http://www.ietf.org/mail-archive/web/homenet/current/msg03639.html >> >> I think we need to decide how to relate to their work, ignore it, try = to steer both work efforts so we have some communality, or split up the w= ork (or something else). >> >> --=20 >> Mikael Abrahamsson email: swmike@swm.pp.se >> >> _______________________________________________ >> 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 Fri Jul 4 14: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 10B4D1B2A6F for ; Fri, 4 Jul 2014 14:15:35 -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 HiYPmFaNYHMo for ; Fri, 4 Jul 2014 14:15:30 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 527881B2A2C for ; Fri, 4 Jul 2014 14:15:29 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q58so2121704wes.2 for ; Fri, 04 Jul 2014 14:15:28 -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=5jHSfHs+pB1+uFgZQgh1DtT3AfXMsHuU+t+VPerga/M=; b=ZiCWwh7+8STHORUJ24To71eAygmaVs0HSOWIW6uye7JDXhghy59sc5ZNIVV0u+rJ+f KV1JKzowph0XsWg9SDjN9FjEO3IR5HQWPrFwPZX59und7m9z8j4Wzc90cTXb3ZuqAv8M u30PUXrK23MDCdRErAyol+xZD2SjSF3LkFdB4dLpqlNzeFv8qYFx0S6Ri3NZ+qh0hJFH DJl3vMdSgV+5MmltITVv1q/mC05WzYI7k478ypZpXalwk2wwJc+WNZgmOUwTC5yyjCAZ stIzjOFqkjFYvlmxhW0AWq45WUQONH0zzjXTd2nmZnZ80kSObB85+jNfBuWyG3bCsE/+ 9qvg== MIME-Version: 1.0 X-Received: by 10.180.206.73 with SMTP id lm9mr60467588wic.54.1404508528633; Fri, 04 Jul 2014 14:15:28 -0700 (PDT) Received: by 10.194.51.131 with HTTP; Fri, 4 Jul 2014 14:15:28 -0700 (PDT) In-Reply-To: <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> Date: Fri, 4 Jul 2014 23:15:28 +0200 Message-ID: From: Daniel Migault To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=001a11c383aceef27604fd649f51 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/qL5BmPs5LOi281AMTCD_lHt49Is Cc: "homenet@ietf.org" Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Fri, 04 Jul 2014 21:15:35 -0000 --001a11c383aceef27604fd649f51 Content-Type: text/plain; charset=UTF-8 Hi Juliusz, If I understand correctly your point your point is not about the DHCP Options, but about the architecture we defined for outsourcing the DNS Homenet Zone. I have just submitted an update of the description of the architecture in draft-mglt-homenet-front-end-naming-delegation-04.txt [1]. The main idea is that the CPE builds the zone for the whole home network. Then it outsources the zone on a server that handles the authoritative naming service on the Internet. The reason for outsourcing is that CPE have not been designed to host the authoritative service on the Internet and thus may be exposed to resource exhaustion. I am rephrasing your use case to make sure we have the same in mind. Please clarify if we do not agree on the use case. You consider is a web server in the home network, that you want to be reachable from the Internet. In order to do that you buy a specific domain name www.homenet.com. The domain is hosted on a Public Authoritative Server, you edit the zone, add the IP address of your server. Then, you can do that manually every time your IP changed or use a specific software that your registrar recommend you. To me, the drawbacks of this architecture are: 1) It is not scalable in term of configuration: if you have a single server, you can edit the zone. If you have 100 devices (which is not much) you will not be able to do it especially if you IP prefix changes every day. 2) It is not scalable in term of software installation: every registrar have its own API for configuring the zone. If you want to be able to do so, devices need to ba familiar with all APIs. Furthermore, if you suppose all registrar agree to have a unique way to do so, -- suppose nsupdate -- all devices will have to implement this protocol. For most devices this may be not a problem, however, for all devices like sensors having to perform nsupdate every day, may impact their battery life time for nothing. 3) It is not automatic and flexible: A new device that is in your network cannot have a name, as an admin needs to register its name in the zone myhomenet.com, or provide the credential for it to all new devices. 4) It is not scalable in term of zone management and bandwidth: Suppose you have n devices in the home network and a renumbering occurs. All these n devices will contact the Public Authoritative Server that may be miles away from your home network. The Authoritative Server will have to deal with n nsupdate transaction instead of one. 5) it exposes your homenet to IP disruption. Suppose your ISP has a connectivity issue, even a node in your home network will not be able to contact your web server as the DNS(SEC) resolution is not possible. In contrast, the architecture we describe in [1] : 1) is scalable in term of configuration: The only device that you may need to configure is your CPE. In the worst case it is done once for all. 2) is scalable in term of software installation: Only the CPE needs to be compliant with the registrar API, other devices do not need any kind of credentials, or other APIs. 3) It is automatic and flexible: as a new node is attached, it advertise its name in a DHCP query and the CPE takes in charge the binding. 4) it is scalable in term of zone management and bandwidth: registration is performed by the CPE, that is one of the first hops. Then the CPE updates once the zone to the Public Authoritative Server. This can be done with nsupdate, but we recommend master / slave synchronization. 5) It preserves the home network from IP disruption. If you d not have any connectivity on the Internet, as the authoritative naming service is provided by the CPE for the home network, nodes within the home network can still communicate. BR, Daniel [1] http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-04.txt On Thu, Jul 3, 2014 at 2:14 PM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > Thanks for your answer, Daniel. > > > If I understand it properly, the use case you consider: 1) you set up > > a web server in your homenet, 2) you want it to be accessed from the > > outside so you register your domain name and register the IP address to > > the zone. Note that In this case, the Authoritative Naming service is > > outsourced to a third party which is what we want to achieve to. > > No, I think that I'm speaking of the same use case as your draft. (I'm > not sure, since your draft takes the use case for granted -- I'm probably > missing some background here, sorry for not being more attentive > previously.) > > I've got a device that wants to be advertised in the global DNS (a web > server is the obvious example, but it doesn't matter). Your draft > suggests (I think) that the device should speak to the CPE which will take > care of the interaction with the public DNS (arrow 6 in Figure 1 is > missing, by the way). I'd like to understand why the device needs to go > through the middleman rather than speaking directly to the authoritative > DNS server. > > My family was poor but honest, Daniel, and NATed addresses were all we > could afford. Notwithstanding our difficult conditions, my parents took > a lot of care to bring me up to believe that end-to-end is always better > than proxying. Since you're advocating proxying, I'd like to understand > why you think it is necessary. What is more, I'd like to understand why > you require that the proxy be co-located with the CPE. (It could > certainly be implemented on the CPE, but I don't understand why the > protocol requires that.) > > You give some good reasons below, and I think they should be included in > the draft: > > > - Ease the naming of device of various nature. > > Please explain. > > > - CPE remains in the homenet and may be easier to be authenticated > > than all different devices. > > Good point. > > > - CPE presents a centralized point for end user interactions > > I'm not convinced about that, the authoritative DNS master seems like the > natural place for end-user interactions. (Note that this does not prevent > the CPE's web interface from implementing some sort of proxy to the DNS > master's interface.) > > > - CPE are "powerful enough" to handle complex policies... > > Everything is powerful enough nowadays. My abacus has a four-core chip. > > > - CPE can integrate multiple protocols to publish a zone. Suppose > mDNS is > > used by a node, than registration of its IP address and name cannot be > > perfomed on a public authoritative server cannot be performed using mDNS. > > I strongly disagree. I don't want mDNS->DNS proxying. Registering in the > global DNS is something that should be under user control, while mDNS > is something that happens automatically (for better or worse). > > -- Juliusz > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 On Thu, Jul 3, 2014 at 2:14 PM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > Thanks for your answer, Daniel. > > > If I understand it properly, the use case you consider: 1) you set up > > a web server in your homenet, 2) you want it to be accessed from the > > outside so you register your domain name and register the IP address to > > the zone. Note that In this case, the Authoritative Naming service is > > outsourced to a third party which is what we want to achieve to. > > No, I think that I'm speaking of the same use case as your draft. (I'm > not sure, since your draft takes the use case for granted -- I'm probably > missing some background here, sorry for not being more attentive > previously.) > > I've got a device that wants to be advertised in the global DNS (a web > server is the obvious example, but it doesn't matter). Your draft > suggests (I think) that the device should speak to the CPE which will take > care of the interaction with the public DNS (arrow 6 in Figure 1 is > missing, by the way). I'd like to understand why the device needs to go > through the middleman rather than speaking directly to the authoritative > DNS server. > > My family was poor but honest, Daniel, and NATed addresses were all we > could afford. Notwithstanding our difficult conditions, my parents took > a lot of care to bring me up to believe that end-to-end is always better > than proxying. Since you're advocating proxying, I'd like to understand > why you think it is necessary. What is more, I'd like to understand why > you require that the proxy be co-located with the CPE. (It could > certainly be implemented on the CPE, but I don't understand why the > protocol requires that.) > > You give some good reasons below, and I think they should be included in > the draft: > > > - Ease the naming of device of various nature. > > Please explain. > > > - CPE remains in the homenet and may be easier to be authenticated > > than all different devices. > > Good point. > > > - CPE presents a centralized point for end user interactions > > I'm not convinced about that, the authoritative DNS master seems like the > natural place for end-user interactions. (Note that this does not prevent > the CPE's web interface from implementing some sort of proxy to the DNS > master's interface.) > > > - CPE are "powerful enough" to handle complex policies... > > Everything is powerful enough nowadays. My abacus has a four-core chip. > > > - CPE can integrate multiple protocols to publish a zone. Suppose > mDNS is > > used by a node, than registration of its IP address and name cannot be > > perfomed on a public authoritative server cannot be performed using mDNS. > > I strongly disagree. I don't want mDNS->DNS proxying. Registering in the > global DNS is something that should be under user control, while mDNS > is something that happens automatically (for better or worse). > > -- Juliusz > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --001a11c383aceef27604fd649f51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Juliusz,

If I understand c= orrectly your point your point is not about the DHCP Options, but about the= architecture we defined for outsourcing the DNS Homenet Zone. I have just = submitted an update of the description of the architecture in=C2=A0 draft-m= glt-homenet-front-end-naming-delegation-04.txt [1].

The main idea is that the CPE builds the zone for the whole home = network. Then it outsources the zone on a server that handles the authorita= tive naming service on the Internet. The reason for outsourcing is that CPE= have not been designed to host the authoritative service on the Internet a= nd thus may be exposed to resource exhaustion.

I am rephrasing your use case to make sure we have the same = in mind. Please clarify if we do not agree on the use case. You consider is= a web server in the home network, that you want to be reachable from the I= nternet. In order to do that you buy a specific domain name www.homenet.com. The domain is ho= sted on a Public Authoritative Server, you edit the zone, add the IP addres= s of your server. Then, you can do that manually every time your IP changed= or use a specific software that your registrar recommend you.

To me, the drawbacks of this architecture are:
=C2=A0=C2= =A0=C2=A0 1) It is not scalable in term of configuration: if you have a sin= gle server, you can edit the zone. If you have 100 devices (which is not mu= ch) you will not be able to do it especially if you IP prefix changes every= day.
=C2=A0 =C2=A0 2) It is not scalable in term of software installa= tion: every registrar have its own API for configuring the zone. If you wan= t to be able to do so, devices need to ba familiar with all APIs. Furthermo= re, if you suppose all registrar agree to have a unique way to do so, -- su= ppose nsupdate -- all devices will have to implement this protocol. For mos= t devices this may be not a problem, however, for all devices like sensors = having to perform nsupdate every day, may impact their battery life time fo= r nothing. =C2=A0
=C2=A0=C2=A0=C2=A0 3) It is not automatic and flexible: A new de= vice that is in your network cannot have a name, as an admin needs to regis= ter its name in the zone myhomenet.com, or provide the credential for it to all new devices.
=C2=A0 =C2=A0 4) It is not scalable in term of zone management a= nd bandwidth: Suppose you have n devices in the home network and a renumber= ing occurs. All these n devices will contact the Public Authoritative Serve= r that may be miles away from your home network. The Authoritative Server w= ill have to deal with n nsupdate transaction instead of one.
=C2=A0=C2=A0=C2=A0 5) it exposes your homenet to IP disruption. = Suppose your ISP has a connectivity issue, even a node in your home network= will not be able to contact your web server as the DNS(SEC) resolution is = not possible.=C2=A0

In contrast, the architecture we describe in [1] = :
=C2=A0 =C2=A0 1) is scalable in term of configuration: The = only device that you may need to configure is your CPE. In the worst case i= t is done once for all.
=C2=A0 =C2=A0 2) is scalable in term of software installation: O= nly the CPE needs to be compliant with the registrar API, other devices do= =C2=A0 not need any kind of credentials, or other APIs.
=C2= =A0 =C2=A0 3) It is automatic and flexible: as a new node is attached, it a= dvertise its name in a DHCP query and the CPE takes in charge the binding.<= br>
=C2=A0 =C2=A0 4) it is scalable in term of zone management and b= andwidth: registration is performed by the CPE, that is one of the first ho= ps. Then the CPE updates once the zone to the Public Authoritative Server. = This can be done with nsupdate, but we recommend master / slave synchroniza= tion.
=C2=A0=C2=A0=C2=A0 5) It preserves the home network from IP disr= uption. If you d not have any connectivity on the Internet, as the authorit= ative naming service is provided by the CPE for the home network, nodes wit= hin the home network can still communicate.

BR,

Daniel

=C2=A0


[1] http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-en= d-naming-delegation-04.txt



On Thu, Jul 3, 2014 at 2:14 PM, Juliusz Chroboczek <= jch@pps.= univ-paris-diderot.fr> wrote:
Thanks for your answer, D= aniel.

> If I understand it properly, the use case you consider: 1) you set up<= br> > a web server in your homenet, 2) you want it to be accessed from the > outside so you register your domain name and register the IP address t= o
> the zone. Note that In this case, the Authoritative Naming service is<= br> > outsourced to a third party which is what we want to achieve to.

No, I think that I'm speaking of the same use case as your draft.= =C2=A0(I'm
not sure, since your draft takes the use case for granted -- I'm probab= ly
missing some background here, sorry for not being more attentive previously= .)

I've got a device that wants to be advertised in the global DNS (a web<= br> server is the obvious example, but it doesn't matter). =C2=A0Your draft=
suggests (I think) that the device should speak to the CPE which will take<= br> care of the interaction with the public DNS (arrow 6 in Figure 1 is
missing, by the way). =C2=A0I'd like to understand why the device needs= to go
through the middleman rather than speaking directly to the authoritative DNS server.

My family was poor but honest, Daniel, and NATed addresses were all we
could afford. =C2=A0Notwithstanding our difficult conditions, my parents to= ok
a lot of care to bring me up to believe that end-to-end is always better than proxying. =C2=A0Since you're advocating proxying, I'd like to = understand
why you think it is necessary. =C2=A0What is more, I'd like to understa= nd why
you require that the proxy be co-located with the CPE. =C2=A0(It could
certainly be implemented on the CPE, but I don't understand why the
protocol requires that.)

You give some good reasons below, and I think they should be included in the draft:

> =C2=A0=C2=A0=C2=A0 - Ease the naming of device of various nature.

Please explain.

> =C2=A0=C2=A0=C2=A0 - CPE remains in the homenet and may be easier to b= e authenticated
> than all different devices.

Good point.

> =C2=A0=C2=A0=C2=A0 - CPE presents a centralized point for end user int= eractions

I'm not convinced about that, the authoritative DNS master seems = like the
natural place for end-user interactions. =C2=A0(Note that this does not pre= vent
the CPE's web interface from implementing some sort of proxy to the DNS=
master's interface.)

> =C2=A0=C2=A0=C2=A0 - CPE are "powerful enough" to handle com= plex policies...

Everything is powerful enough nowadays. =C2=A0My abacus has a four-co= re chip.

> =C2=A0=C2=A0=C2=A0 - CPE can integrate multiple protocols to publish a= zone. Suppose mDNS is
> used by a node, than registration of its IP address and name cannot be=
> perfomed on a public authoritative server cannot be performed using mD= NS.

I strongly disagree. =C2=A0I don't want mDNS->DNS proxying. = =C2=A0Registering in the
global DNS is something that should be under user control, while mDNS
is something that happens automatically (for better or worse).

-- Juliusz



--
Daniel Mi= gault
Orange Labs -- Security
+33 6 70 72 69 58


On Thu, Jul 3, 2014 at 2:14 PM, Juliusz Chroboczek &= lt;jch@p= ps.univ-paris-diderot.fr> wrote:
Thanks for your answer, D= aniel.

> If I understand it properly, the use case you consider: 1) you set up<= br> > a web server in your homenet, 2) you want it to be accessed from the > outside so you register your domain name and register the IP address t= o
> the zone. Note that In this case, the Authoritative Naming service is<= br> > outsourced to a third party which is what we want to achieve to.

No, I think that I'm speaking of the same use case as your draft.= =C2=A0(I'm
not sure, since your draft takes the use case for granted -- I'm probab= ly
missing some background here, sorry for not being more attentive previously= .)

I've got a device that wants to be advertised in the global DNS (a web<= br> server is the obvious example, but it doesn't matter). =C2=A0Your draft=
suggests (I think) that the device should speak to the CPE which will take<= br> care of the interaction with the public DNS (arrow 6 in Figure 1 is
missing, by the way). =C2=A0I'd like to understand why the device needs= to go
through the middleman rather than speaking directly to the authoritative DNS server.

My family was poor but honest, Daniel, and NATed addresses were all we
could afford. =C2=A0Notwithstanding our difficult conditions, my parents to= ok
a lot of care to bring me up to believe that end-to-end is always better than proxying. =C2=A0Since you're advocating proxying, I'd like to = understand
why you think it is necessary. =C2=A0What is more, I'd like to understa= nd why
you require that the proxy be co-located with the CPE. =C2=A0(It could
certainly be implemented on the CPE, but I don't understand why the
protocol requires that.)

You give some good reasons below, and I think they should be included in the draft:

> =C2=A0=C2=A0=C2=A0 - Ease the naming of device of various nature.

Please explain.

> =C2=A0=C2=A0=C2=A0 - CPE remains in the homenet and may be easier to b= e authenticated
> than all different devices.

Good point.

> =C2=A0=C2=A0=C2=A0 - CPE presents a centralized point for end user int= eractions

I'm not convinced about that, the authoritative DNS master seems = like the
natural place for end-user interactions. =C2=A0(Note that this does not pre= vent
the CPE's web interface from implementing some sort of proxy to the DNS=
master's interface.)

> =C2=A0=C2=A0=C2=A0 - CPE are "powerful enough" to handle com= plex policies...

Everything is powerful enough nowadays. =C2=A0My abacus has a four-co= re chip.

> =C2=A0=C2=A0=C2=A0 - CPE can integrate multiple protocols to publish a= zone. Suppose mDNS is
> used by a node, than registration of its IP address and name cannot be=
> perfomed on a public authoritative server cannot be performed using mD= NS.

I strongly disagree. =C2=A0I don't want mDNS->DNS proxying. = =C2=A0Registering in the
global DNS is something that should be under user control, while mDNS
is something that happens automatically (for better or worse).

-- Juliusz



--
Daniel Mi= gault
Orange Labs -- Security
+33 6 70 72 69 58
--001a11c383aceef27604fd649f51-- From nobody Fri Jul 4 15:12: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 CBDA01A004A for ; Fri, 4 Jul 2014 15:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35] 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 C_WEs_shx4Ai for ; Fri, 4 Jul 2014 15:12:48 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1: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 B5FF71A003B for ; Fri, 4 Jul 2014 15:12:47 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s64MCkZB027696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 5 Jul 2014 00:12:46 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id s64MCjrZ020258; Sat, 5 Jul 2014 00:12:45 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id CE8FD2A654E; Sat, 5 Jul 2014 00:12:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id FfjAvIJRMlB6; Sat, 5 Jul 2014 00:12:43 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9F1DB115ED; Sat, 5 Jul 2014 00:12:42 +0200 (CEST) Date: Sat, 05 Jul 2014 00:12:42 +0200 Message-ID: <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Daniel Migault In-Reply-To: References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 05 Jul 2014 00:12:46 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 05 Jul 2014 00:12:45 +0200 (CEST) X-Miltered: at korolev with ID 53B726DE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 53B726DD.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53B726DE.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 53B726DD.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 53B726DE.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 53B726DD.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/7JmkTCBSSMs5nnH3VWPj6JAL0cA Cc: "homenet@ietf.org" Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Fri, 04 Jul 2014 22:12:50 -0000 > The main idea is that the CPE builds the zone for the whole home network. Thanks for the clarification. Daniel, perhaps I'm still misunderstanding something -- but I'm afraid that right now I'm strongly opposed to this protocol. I hold no opinion yet on whether proxying is necessary (although I hope it isn't), but I am strongly opposed to binding the DNS proxy role with the CPE at the protocol level. (This does not mean that the DNS proxy cannot be colocated with the CPE, only that I find a protocol that mandates this kind of colocation unacceptable.) > I am rephrasing your use case to make sure we have the same in mind. Please > clarify if we do not agree on the use case. You consider is a web server in > the home network, that you want to be reachable from the Internet. In order to > do that you buy a specific domain name www.homenet.com. The domain is hosted > on a Public Authoritative Server, you edit the zone, add the IP address of > your server. Oh, nothing that geeky. I copy my vacation photographs onto my NAS. I click the "share over the Internet" button on the NAS's web interface. The NAS performs DynDNS registration, I get a link that I can copy-paste into an e-mail to my mom: "Mom, the vacation photographs are on http://www.user-fe83-paris-13.dyndns.example.com:8080/photos, the password is 1234." I've avoided putting my private photographs on Google's servers -- and we're changing the world. I click on the "share over the internet" button on my stereo's web interface. The stereo performs DynDNS registration, I get a link that I can copy-paste. "Daniel, the song you found so funny at my place last night night is on http://www.user-fe83-paris-13.dyndns.example.com/funny-music, the password is 1234". I've avoided sending 20MB of Ukrainian R'n'B over SMTP -- and we're changing the world. I'm at the train station. There's a strike on. I'm playing Civilisation on my laptop in an internet cafe. I click the "Invite over the Internet" button. Civilisation performs DynDNS registration, I get a link which I can copy-paste. "Daniel, I'm bored, join me for a game of Civilisation, link is civ://www.user-fe83-paris-13.dyndns.example.com, password is 1234", and now I can wholeheartedly support the cheminot's strike -- we're changing the world again. >     1) It is not scalable in term of configuration: if you have a single > server, you can edit the zone. If you have 100 devices (which is not much) you > will not be able to do it especially if you IP prefix changes every day. Sure. Just like you, I'm expecting dynamic updates. But I don't expect dynamic updates to be dependent on my CPE, which is buggy (it was provided by the major competitor of your employer) and isn't available at the internet cafe. >     2) It is not scalable in term of software installation: every registrar > have its own API for configuring the zone. Then why not standardise a registration API? > Furthermore, if you suppose all registrar agree to have a unique way to > do so, -- suppose nsupdate -- all devices will have to implement this > protocol. For most devices this may be not a problem, however, for all > devices like sensors having to perform nsupdate every day, may impact > their battery life time for nothing. If you really believe that proxying is necessary (and I'd like actual figures to support this claim -- how many devices do you have in your home that cannot afford the cost of one registration every few hours?), then there's nothing preventing a DNS proxy from using the standardised registration protocol on behalf of its clients. Then clients can choose whether to go through the proxy, and users can choose whether use the ISP-provided proxy (co-located with the CPE) or a third-party proxy that happens to work. >     3) It is not automatic and flexible: A new device that is in your network > cannot have a name, as an admin needs to register its name in the zone > myhomenet.com, or provide the credential for it to all new devices. That's what we have HNCP for -- for distributing random data to all devices. >     4) It is not scalable in term of zone management and bandwidth: Suppose > you have n devices in the home network and a renumbering occurs. All these n > devices will contact the Public Authoritative Server that may be miles away > from your home network. I've got 100 devices. I renumber. Each device sends 500 bytes of registration data. My monthly Internet bill has just increased by 50 kB. >     5) it exposes your homenet to IP disruption. Suppose your ISP has a > connectivity issue, even a node in your home network will not be able to > contact your web server as the DNS(SEC) resolution is not possible.  But my nodes are still running mDNS/zeroconf, right? Or are you deprecating that? -- Juliusz From nobody Mon Jul 7 05:46: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 2BDF51B2845 for ; Mon, 7 Jul 2014 05:46:32 -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 2fo6IF9O3fQG for ; Mon, 7 Jul 2014 05:46:28 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c: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 96E721B281F for ; Mon, 7 Jul 2014 05:46:27 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id r20so6805166wiv.4 for ; Mon, 07 Jul 2014 05:46: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 :content-type; bh=VVzQ7+oypbMTORpDsJHYJxGb/oOLvmoxwV0pxTE4phU=; b=rukbcw7FeCA55tlBIEe2V503R5aH8Hf2BGdw+rwUs3ojaSqZtvKYWc7P8mm5g7EZpx vC51S+LgsgJG/oSqjiu5q6UvQ8WYzVD+F2m0o+E/UHfDyS2VnMnHiHcsUxCtcR+0qybg 1TwQrEFWuyvGFGemzlwbsgrrhqZ7Td8CMufLNibxtxaIpPp/KvboAvQ2CtK33jrTuNod UiEq8494KeDe1zt9RtM8yYxxZx8W7xfJvdDAMp3wLk2PGisvw+YF9W1IdBloTjBEqzPJ 831HfG5vNeyCzXbdn0S9WFOTd/g74oqsh2qsKaCm3wP3uiiofUT3VCKVGgAMofKqrGDi SsOQ== MIME-Version: 1.0 X-Received: by 10.194.60.240 with SMTP id k16mr33134763wjr.0.1404737186066; Mon, 07 Jul 2014 05:46:26 -0700 (PDT) Received: by 10.194.51.131 with HTTP; Mon, 7 Jul 2014 05:46:25 -0700 (PDT) In-Reply-To: References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> Date: Mon, 7 Jul 2014 14:46:25 +0200 Message-ID: From: Daniel Migault To: Juliusz Chroboczek , "homenet@ietf.org" Content-Type: multipart/alternative; boundary=047d7bacc1e4fa768604fd99dc7e Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/PqD2FNG49oxdqAQlKfof9g7252g Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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, 07 Jul 2014 12:46:32 -0000 --047d7bacc1e4fa768604fd99dc7e Content-Type: text/plain; charset=UTF-8 Hi Please see my comments inline. > > > On Sat, Jul 5, 2014 at 12:12 AM, Juliusz Chroboczek < > jch@pps.univ-paris-diderot.fr> wrote: > >> > The main idea is that the CPE builds the zone for the whole home >> network. >> >> Thanks for the clarification. >> >> Daniel, perhaps I'm still misunderstanding something -- but I'm afraid >> that >> right now I'm strongly opposed to this protocol. I hold no opinion yet on >> whether proxying is necessary (although I hope it isn't), but I am >> strongly >> opposed to binding the DNS proxy role with the CPE at the protocol level. >> (This does not mean that the DNS proxy cannot be colocated with the CPE, >> only that I find a protocol that mandates this kind of colocation >> unacceptable.) >> > I do not think our architecture is bound to the CPE. In the architecture document we mention that the CPE is the most likely to host the DNS zone for the home network. However, I agree it can be any other node. We do not either mandate any collocation of functions. If you could point specific sections, that would help to clarify the next versions. Similarly, I do not recall using the term proxy in one or the other draft, and I do not see what could be considered as a proxy. More specifically, suppose you have a authoritative DNS server in your homenet work. In the draft we said a CPE will most likely handle this function. This server MAY NOT want to respond for queries that are coming from outside the home network. In this case, This server outsources the authoritative server for queries coming from the Internet to a third party. DNS queries for the Domain name of the home network will be answered by the "CPE" when the query comes form the home network and by the "third party" when the query comes from outside the home network. > > >> > I am rephrasing your use case to make sure we have the same in mind. >> Please >> > clarify if we do not agree on the use case. You consider is a web >> server in >> > the home network, that you want to be reachable from the Internet. In >> order to >> > do that you buy a specific domain name www.homenet.com. The domain is >> hosted >> > on a Public Authoritative Server, you edit the zone, add the IP address >> of >> > your server. >> >> Oh, nothing that geeky. I copy my vacation photographs onto my NAS. >> I click the "share over the Internet" button on the NAS's web interface. >> The NAS performs DynDNS registration, I get a link that I can copy-paste >> into an e-mail to my mom: "Mom, the vacation photographs are on >> http://www.user-fe83-paris-13.dyndns.example.com:8080/photos, the >> password >> is 1234." I've avoided putting my private photographs on Google's >> servers -- and we're changing the world. >> >> I click on the "share over the internet" button on my stereo's web >> interface. The stereo performs DynDNS registration, I get a link that >> I can copy-paste. "Daniel, the song you found so funny at my place last >> night night is on >> http://www.user-fe83-paris-13.dyndns.example.com/funny-music, >> the password is 1234". I've avoided sending 20MB of Ukrainian R'n'B over >> SMTP -- and we're changing the world. >> >> I'm at the train station. There's a strike on. I'm playing Civilisation >> on my laptop in an internet cafe. I click the "Invite over the Internet" >> button. Civilisation performs DynDNS registration, I get a link which >> I can copy-paste. "Daniel, I'm bored, join me for a game of Civilisation, >> link is civ://www.user-fe83-paris-13.dyndns.example.com, password is >> 1234", and now I can wholeheartedly support the cheminot's strike -- we're >> changing the world again. >> > To me the last use case you provide is not in the scope of home network unless you are unsing a VPN. The two first examples seems to be related to WEBDAV. On a DNS point of view, it looks to me that they involve only a DNS registration. Suppose there is not NAT. Your NAS requests /discovers its IP address and then registers its IP address to the registrar. This means that at one time you have configured your NAS with the appropriated credentials to update your zone in the registrar. In the architecture we propose, things may be as follows: the NAS only needs a hostname: myserver for example. You plug the NAS in your home network, it announces its name via DHCP. The DHCP transmit the information to the entity that manages the DNS zone, which then outsource the zone to the registrar. You NAS does not need to be configured to update the zone at the registrar. > > > > 1) It is not scalable in term of configuration: if you have a single >> > server, you can edit the zone. If you have 100 devices (which is not >> much) you >> > will not be able to do it especially if you IP prefix changes every day. >> >> Sure. Just like you, I'm expecting dynamic updates. But I don't expect >> dynamic updates to be dependent on my CPE, which is buggy (it was provided >> by the major competitor of your employer) and isn't available at the >> internet cafe. > > To me the Internet cafe is not the home network. The issue of buggy CPE is an important one. The goal of the two drafts is to provide guidance to avoid such issues... and providing no guidances or leaving things as there are now won't solve these issues ;-) > > > >> > 2) It is not scalable in term of software installation: every >> registrar >> > have its own API for configuring the zone. >> >> Then why not standardise a registration API? >> > I am not sure there is a real interest in doing so, nor that it is feasible. The important thing is that you have the APIs of your registrar and that you do not have to set it in all devices. Some devices like sensor will never be able to embed these APIs anyway. > >> > > Furthermore, if you suppose all registrar agree to have a unique way to >> > do so, -- suppose nsupdate -- all devices will have to implement this >> > protocol. For most devices this may be not a problem, however, for all >> > devices like sensors having to perform nsupdate every day, may impact >> > their battery life time for nothing. >> > If you really believe that proxying is necessary (and I'd like actual >> figures to support this claim -- how many devices do you have in your home >> that cannot afford the cost of one registration every few hours?), then >> there's nothing preventing a DNS proxy from using the standardised >> registration protocol on behalf of its clients. Then clients can choose >> whether to go through the proxy, and users can choose whether use the >> ISP-provided proxy (co-located with the CPE) or a third-party proxy that >> happens to work. >> > It is not clear what you have in mind with proxy, so I might misunderstand your point here. It seems to me that you do not want the architecture to prevent a host to register on its own. YES this is the case. Suppose your Registered Domain Name for your home network is myhome.net. With our architecture, as mentioned above, your NAS may be automatically registered as myserver.myhome.net. If you want your server to be registered as myserver.org, nothing prevents you from doing so. You may have two names for the server, or a single one. In other words the proposed architecture is compliant with existing deployment. > > >> > 3) It is not automatic and flexible: A new device that is in your >> network >> > cannot have a name, as an admin needs to register its name in the zone >> > myhomenet.com, or provide the credential for it to all new devices. >> >> That's what we have HNCP for -- for distributing random data to all >> devices. >> > I am sure I misunderstood your point, but I understand you suggest using HNCP to distribute credentials (private keys, login password). Am I correct? >> > 4) It is not scalable in term of zone management and bandwidth: >> Suppose >> > you have n devices in the home network and a renumbering occurs. All >> these n >> > devices will contact the Public Authoritative Server that may be miles >> away >> > from your home network. >> >> I've got 100 devices. I renumber. Each device sends 500 bytes of >> registration data. My monthly Internet bill has just increased by 50 kB. >> > That is still more than 0 ;-) > > 5) it exposes your homenet to IP disruption. Suppose your ISP has a >> > connectivity issue, even a node in your home network will not be able to >> > contact your web server as the DNS(SEC) resolution is not possible. >> >> But my nodes are still running mDNS/zeroconf, right? Or are you >> deprecating >> that? >> > Interchanging mDNS and DNS for local / global scope is not an easy thing. These protocols are different protocols and I do not think it is a good idea to impose all devices to have both, then homenet may have different subnetworks, mDNS can use UTF-8... There are a lot of ongoing work in dnssd. By the way, I am not deprecating the use of mDNS at all it is simply orthogonal. > > > > -- Juliusz >> > > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7bacc1e4fa768604fd99dc7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Hi
=C2=A0
Please see my comments inline.


On Sat, Jul 5, 2014 at 12:12 AM, Juliusz Chro= boczek <jch@pps.univ-paris-diderot.fr> wrote:
> The main idea i= s that the CPE builds the zone for the whole home network.

Thanks for the clarification.

Daniel, perhaps I'm still misunderstanding something -- but I'm afr= aid that
right now I'm strongly opposed to this protocol. =C2=A0I hold no opinio= n yet on
whether proxying is necessary (although I hope it isn't), but I am stro= ngly
opposed to binding the DNS proxy role with the CPE at the protocol level. (This does not mean that the DNS proxy cannot be colocated with the CPE, only that I find a protocol that mandates this kind of colocation unaccepta= ble.)
=C2=A0
I do not think our architecture is bound to the CPE. In the ar= chitecture document we mention that the CPE is the most likely to host the = DNS zone for the home network. However, I agree it can be any other node. W= e do not either mandate any collocation of functions. If you could point sp= ecific sections, that would help to clarify the next versions.

Similarly, I do not recall using the term proxy in one or the other dra= ft, and I do not see what could be considered as a proxy. More specifically= , suppose you have a authoritative DNS server in your homenet work. In the = draft we said a CPE will most likely handle this function. This server MAY = NOT want to respond for queries that are coming from outside the home netwo= rk. In this case, This server outsources the authoritative server for queri= es coming from the Internet to a third party. DNS queries for the Domain na= me of the home network will be answered by the "CPE" when the que= ry comes form the home network and by the "third party" when the = query comes from outside the home network.
=C2=A0
> I am rephrasing your use case to make sure we have the same in mind. P= lease
> clarify if we do not agree on the use case. You consider is a web serv= er in
> the home network, that you want to be reachable from the Internet. In = order to
> do that you buy a specific domain name www.homenet.com. The domain is hosted
> on a Public Authoritative Server, you edit the zone, add the IP addres= s of
> your server.

Oh, nothing that geeky. =C2=A0I copy my vacation photographs onto my = NAS.
I click the "share over the Internet" button on the NAS's web= interface.
The NAS performs DynDNS registration, I get a link that I can copy-paste into an e-mail to my mom: "Mom, the vacation photographs are on
http://www.user-fe83-paris-13.dyndns.example.com:8080/photo= s, the password
is 1234." =C2=A0I've avoided putting my private photographs on Goo= gle's
servers -- and we're changing the world.

I click on the "share over the internet" button on my stereo'= s web
interface. =C2=A0The stereo performs DynDNS registration, I get a link that=
I can copy-paste. =C2=A0"Daniel, the song you found so funny at my pla= ce last
night night is on http://www.user-fe83-paris-13.dyndns.exam= ple.com/funny-music,
the password is 1234". =C2=A0I've avoided sending 20MB of Ukrainia= n R'n'B over
SMTP -- and we're changing the world.

I'm at the train station. =C2=A0There's a strike on. =C2=A0I'm = playing Civilisation
on my laptop in an internet cafe. =C2=A0I click the "Invite over the I= nternet"
button. =C2=A0Civilisation performs DynDNS registration, I get a link which=
I can copy-paste. =C2=A0"Daniel, I'm bored, join me for a game of = Civilisation,
link is civ://www.user-fe83-paris-13.dyndns.example.com, password i= s
1234", and now I can wholeheartedly support the cheminot's strike = -- we're
changing the world again.
=C2=A0
To me the last use case you= provide is not in the scope of home network unless you are unsing a VPN. T= he two first examples seems to be related to WEBDAV. On a DNS point of view= , it looks to me that they involve only a DNS registration. Suppose there i= s not NAT. Your NAS requests /discovers its IP address and then registers i= ts IP address to the registrar. This means that at one time you have config= ured your NAS with the appropriated credentials to update your zone in the = registrar. In the architecture we propose, things may be as follows: the NA= S only needs a hostname: myserver for example. You plug the NAS in your hom= e network, it announces its name via DHCP. The DHCP transmit the informatio= n to the entity that manages the DNS zone, which then outsource the zone to= the registrar. You NAS does not need to be configured to update the zone a= t the registrar. =C2=A0


> =C2=A0=C2=A0=C2=A0 1) It is not scalable in term of configuration: if = you have a single
> server, you can edit the zone. If you have 100 devices (which is not m= uch) you
> will not be able to do it especially if you IP prefix changes every da= y.

Sure. =C2=A0Just like you, I'm expecting dynamic updates. =C2=A0B= ut I don't expect
dynamic updates to be dependent on my CPE, which is buggy (it was provided<= br> by the major competitor of your employer) and isn't available at the internet cafe.
=C2=A0
To me the Internet cafe is not the home network. The issue = of buggy CPE is an important one. The goal of the two drafts is to provide = guidance to avoid such issues... and providing no guidances or leaving thin= gs as there are now won't solve these issues ;-)



> =C2=A0 =C2=A0 2) It is not scalable in term of software installation: = every registrar
> have its own API for configuring the zone.

Then why not standardise a registration API?
=C2=A0
I am not sure there is a real interest in doing so,= nor that it is feasible. The important thing is that you have the APIs of = your registrar and that you do not have to set it in all devices. Some devi= ces like sensor will never be able to embed these APIs anyway.
=C2=A0
<= div class=3D"gmail_extra">
=C2=A0
> Furthermore, if you suppose all registrar agree to have a unique way t= o
> do so, -- suppose nsupdate -- all devices will have to implement this<= br> > protocol. For most devices this may be not a problem, however, for all=
> devices like sensors having to perform nsupdate every day, may impact<= br> > their battery life time for nothing.
If you really = believe that proxying is necessary (and I'd like actual
figures to support this claim -- how many devices do you have in your home<= br> that cannot afford the cost of one registration every few hours?), then
there's nothing preventing a DNS proxy from using the standardised
registration protocol on behalf of its clients. =C2=A0Then clients can choo= se
whether to go through the proxy, and users can choose whether use the
ISP-provided proxy (co-located with the CPE) or a third-party proxy that happens to work.
=C2=A0
It is not clear what you have in mind with proxy, so I might m= isunderstand your point here. It seems to me that you do not want the archi= tecture to prevent a host to register on its own. YES this is the case. Sup= pose your Registered Domain Name for your home network is myhome.net. With our architecture, as me= ntioned above, your NAS may be automatically registered as myserver.myhome.net. If you wa= nt your server to be registered as myserver.org, nothing prevents you from doing so. You may h= ave two names for the server, or a single one. In other words the proposed = architecture is compliant with existing deployment.
=C2=A0
> =C2=A0=C2=A0=C2=A0 3) It is not automatic and flexible: A new device t= hat is in your network
> cannot have a name, as an admin needs to register its name in the zone=
> myhomenet.com, = or provide the credential for it to all new devices.

That's what we have HNCP for -- for distributing random data to a= ll devices.
=C2=A0
I am sure I misunderstood your point, but I un= derstand you suggest using HNCP to distribute credentials (private keys, lo= gin password). Am I correct?


> =C2=A0 =C2=A0 4) It is not scalable in term of zone management and ban= dwidth: Suppose
> you have n devices in the home network and a renumbering occurs. All t= hese n
> devices will contact the Public Authoritative Server that may be miles= away
> from your home network.

I've got 100 devices. =C2=A0I renumber. =C2=A0Each device sends 5= 00 bytes of
registration data. =C2=A0My monthly Internet bill has just increased by 50 = kB.
=C2=A0
That is still more than 0=C2=A0 ;-)
> =C2=A0=C2=A0=C2=A0 5) it exposes your homenet to IP disruption. Suppos= e your ISP has a
> connectivity issue, even a node in your home network will not be able = to
> contact your web server as the DNS(SEC) resolution is not possible.=C2= =A0

But my nodes are still running mDNS/zeroconf, right? =C2=A0Or are you= deprecating
that?
=C2=A0
Interchanging mDNS and DNS for local / global scope i= s not an easy thing. These protocols are different protocols and I do not t= hink it is a good idea to impose all devices to have both, then homenet may= have different subnetworks, mDNS can use UTF-8...=C2=A0 There are a lot of= ongoing work in dnssd.

By the way, I am not deprecating the use of mDNS at all it is simply or= thogonal.

<= br>

-- Juliusz



= --
Daniel Migault
Orange Labs -- Security
+33 6 70 72= 69 58



--
Daniel Migault
Orang= e Labs -- Security
+33 6 70 72 69 58 --047d7bacc1e4fa768604fd99dc7e-- From nobody Tue Jul 8 18:40: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 E3FE51A0203 for ; Tue, 8 Jul 2014 18:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 IJf9AdGr8hGK for ; Tue, 8 Jul 2014 18:39:58 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1: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 EBA531A0202 for ; Tue, 8 Jul 2014 18:39:57 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s691dtLL018526 for ; Wed, 9 Jul 2014 03:39:55 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C6A832C212E for ; Wed, 9 Jul 2014 03:39:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 4vdP0vb0_tS5 for ; Wed, 9 Jul 2014 03:39:54 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B7BC22C2136 for ; Wed, 9 Jul 2014 03:39:53 +0200 (CEST) Received: from jch (uid 1000) (envelope-from jch@pps.univ-paris-diderot.fr) id c00301 by ijon.pps.univ-paris-diderot.fr (DragonFly Mail Agent v0.9); Wed, 09 Jul 2014 03:39:59 +0200 Date: Wed, 09 Jul 2014 03:39:59 +0200 Message-ID: <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Daniel Migault In-Reply-To: References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 09 Jul 2014 03:39:55 +0200 (CEST) X-Miltered: at korolev with ID 53BC9D6B.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53BC9D6B.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 53BC9D6B.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/1peX9tp2CHMGo1H_tNOSuIb7zLs Cc: "homenet@ietf.org" Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Wed, 09 Jul 2014 01:40:00 -0000 Thanks for your patience, Daniel. I feel I'm understanding a little more now. My main misunderstanding was the following: - you're not populating DNS with mDNS data, you're populating it with the DHCP hostname data; I now understand that mDNS is mostly orthogonal. What I still don't understand is how your protocol can work when the hidden master is not the CPE. > In the architecture document we mention that the CPE is the most likely > to host the DNS zone for the home network. I'd really like to encourage you to revise the drafts so that it makes it clear that the hidden master is not necessarily the CPE. I'd be particularly keen to understand how the hidden master can sign the zone when it is not the CPE, given that you expect signing keys to be obtained over DHCP. > I do not think our architecture is bound to the CPE [...] If you could > point specific sections, that would help to clarify the next versions. This document describes a homenet naming architecture where the CPEs manage the DNS zone associates to its home network, [...] the DNS(SEC) Homenet Zone built by the CPE is outsourced to Public Authoritative Servers. [...] The zone signing and secure delegation can be performed either by the CPE or by the Public Authoritative Servers. [...] outsourcing the authoritative naming service from the CPE ...and so forth, and so on. I'm sure you can see where my confusion stems from ;-) > Similarly, I do not recall using the term proxy in one or the other > draft, and I do not see what could be considered as a proxy. I fear I wasn't very clear: 1. the homenet nodes populate the master zone at the hidden master (which is not at all the CPE, as we've established above) using DHCP; 2. the hidden master (which is not at all the CPE) performs a zone transfer to its secondaries (which are not at all the ones hardwired by the ISP into the CPE) using normal DNS(SEC) procedures. So in effect the hostname data is flowing (1) from the node to the hidden master which (2) forwards it to the authoritative secondaries. In effect, it's being proxied from the node to the secondaries by the hidden master. > In the architecture we propose, things may be as follows: the NAS only > needs a hostname: myserver for example. You plug the NAS in your home > network, it announces its name via DHCP. The DHCP transmit the > information to the entity that manages the DNS zone, which then > outsource the zone to the registrar. You NAS does not need to be > configured to update the zone at the registrar. Ah. I think that's the crucial point -- it's easier to provide credentials to a single node rather than to every node that needs to register in the global DNS. That makes sense. So how does the hidden master get the credentials? You say: The DHCP Server makes the Public Key available to the DNS servers, so the CPE can secure its DNS transactions. Note that the Public Key alone is not sufficient to perform the authentication [...] How the binding is performed is out of scope of the document. It can be a centralized database or various bindings may be sent to the different servers. That speaks about the ISP's DHCP server, right? But now that we've established that the hidden master is not the CPE -- it's not necessarily on the same link as the DHCP server. Are you assuming a DHCP proxy at the CPE? I also don't understand what you mean by "various bindings" in the last sentence quoted above. I'd appreciate a clarification. Perhaps you can tell us how the private keys are distributed in your implementation? >>> Suppose your ISP has a connectivity issue, even a node in your home >>> network will not be able to contact your web server as the DNS(SEC) >>> resolution is not possible. >> But my nodes are still running mDNS/zeroconf, right? > By the way, I am not deprecating the use of mDNS at all it is simply > orthogonal. What I meant by that is that you're still running mDNS, so losing connectivity to the master won't prevent you from resolving using mDNS. However, I now see that you're not deriving the DNS zone from mDNS, so the name you're interested in might very well not be advertised over mDNS. Thanks for your patience, -- Juliusz From nobody Wed Jul 9 06:53: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 4ACCB1A0A84 for ; Wed, 9 Jul 2014 06:53:22 -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 JS8wW_RYygJJ for ; Wed, 9 Jul 2014 06:53:18 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D0AC1A0944 for ; Wed, 9 Jul 2014 06:53:18 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u57so7524571wes.19 for ; Wed, 09 Jul 2014 06:53:17 -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=vGMRMnmPOllopyevBGdfIWgDVnFAAElTrTiUAuu9oRM=; b=g5sizmkjFdD8uY2E6+iIQgznanYINyjGJN9V/rECo2uMVt/L9ZbVh8tFCnAgVdypvg 7jKJ7OAFsV4wrGsXRSqOYSa52WtC1ZW837nwtS4318jA831NrgvAXLQX/Da+UaQPhUnx 5keLd93p6wLE6GnEGn5kRPafXy3oc0yr230ELnE9HUFkoWo5gBqcuxTaNRPtebuF8hJG 2PGob7BCqgI8bt8GbaYGMD9F3+Rt2DY8+x7qNr9PgrixRA6niUM3nSAsiadZOOsBhXzQ gkwAiAcMPmtlA4hxE1ziWcIfql58dhi29hfBOOX82sFO3cZ2QxCldKAKrdBIB8Jdlpdw 5/RA== MIME-Version: 1.0 X-Received: by 10.180.206.73 with SMTP id lm9mr12029664wic.54.1404913996946; Wed, 09 Jul 2014 06:53:16 -0700 (PDT) Received: by 10.194.51.131 with HTTP; Wed, 9 Jul 2014 06:53:16 -0700 (PDT) In-Reply-To: <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> Date: Wed, 9 Jul 2014 15:53:16 +0200 Message-ID: From: Daniel Migault To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=001a11c383acba632f04fdc30724 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/UtcvrbJzTXAi5p2v6_K79P7L6Fw Cc: "homenet@ietf.org" Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Wed, 09 Jul 2014 13:53:22 -0000 --001a11c383acba632f04fdc30724 Content-Type: text/plain; charset=UTF-8 Hi Thank you for your response and feed backs. See my response in the text body as well as in your text. I think we are making progress. [draft-mglt-homenet-front-end-naming-delegation] and [draft-mglt-homenet-naming-architecture-dhc-options] are distinct documents. The one describes the architecture to outsource the homenet authoritative naming service on the Internet. In that sense it should not be CPE specific. The second draft describes how DHCP Option could help to set this architecture. It does not mean they must always be used. A brief response to how these document are CPE specific: - The architecture document [draft-mglt-homenet-front-end-naming-delegation] in NOT CPE specific. See below for more details. - The DHCP Options document [draft-mglt-homenet-naming-architecture-dhc-options] is currently CPE specific. It can be made non CPE specific in two ways: 1) Keeping the document CPE specific and adding a section that describes how the option can be used when functions are not collocated. or 2) making the whole document non CPE specific. Reasons I would prefer 1) are: it makes things easier to read and understand, generalization is easy and I believe these options will mostly be used by CPE. That said both options are fine to me. See more details below. A more detailed response: In [draft-mglt-homenet-front-end-naming-delegation] we use the term CPE, as this is the device we are focused on, and we also believe that in most homenet this device will play this role. However, there are no such restriction. In this document, The CPE is the device that owns the Homenet Zone and that could publish the zone on the Internet. Instead, of publishing itself, it outsources the Zone to the Public Server. In order to clarify this misunderstanding, we can: - a) Explicitly mention that the CPE is an example, and any device can be - b) Introduce a new designation like the Internet Homenet Authoritative Server. Maybe b) is better. I would appreciate to have feed backs. Other designations are also welcome! In [draft-mglt-homenet-naming-architecture-dhc-options] we took advantage of the collocation DHCP client that exchange with the DHCP Server of the ISP, signing of the Zone and the Reverse Zone by the same device. If we want to split the different functions we may have to consider: - the CPE, - the Internet Homenet Authoritative Server - the Internet Reverse Homenet Authoritative Server To me only the Internet Reverse Homenet Authoritative Server needs to dialogue with the ISP, as the ISP manage the delegation of the Reverse Zone. If the Internet Reverse Homenet Authoritative Server is not colocated with the CPE, the DHCP Server of the home network will have to relay these options to the DHCP Server of the ISP. The Internet Homenet Authoritative Server can use the DHCP Options with any other DHCP Server that is configured to respond to these options. In the current draft, we used only one key the one the CPE uses to sign both the Homenet Zone and the Reverse Zone. If this may not be performed by the CPE, we need to have two keys: one for the Homenet Zone and one for the Reverse Zone. So that's something we missed, thanks for pointing it out. To me a network that have different entity for the CPE, the Internet Homenet Authoritative Server and the Internet Reverse Homenet Authoritative Server in different devices and a DHCP Relay may not be a home network anymore. I suggest the draft 1) remain restricted to the CPE and 2) add a section to describe how things could work if the functions are split into different devices. I also agree we need to have different options for the Key of the Reverse Homenet Zone and Homenet Zone. The reason to do so, is that Any opinions on that? I also added small comments inline. BR, Daniel On Wed, Jul 9, 2014 at 3:39 AM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > Thanks for your patience, Daniel. I feel I'm understanding a little more > now. My main misunderstanding was the following: > > - you're not populating DNS with mDNS data, you're populating it with the > DHCP hostname data; I now understand that mDNS is mostly orthogonal. > > What I still don't understand is how your protocol can work when the > hidden master is not the CPE. > > > In the architecture document we mention that the CPE is the most likely > > to host the DNS zone for the home network. > > I'd really like to encourage you to revise the drafts so that it makes it > clear that the hidden master is not necessarily the CPE. I'd be > particularly keen to understand how the hidden master can sign the zone > when it is not the CPE, given that you expect signing keys to be obtained > over DHCP. > > > I do not think our architecture is bound to the CPE [...] If you could > > point specific sections, that would help to clarify the next versions. > > This document describes a homenet naming architecture where the CPEs > manage the DNS zone associates to its home network, > > [...] > > the DNS(SEC) Homenet Zone built by the CPE is outsourced to Public > Authoritative Servers. > > [...] > > The zone signing and secure delegation can be performed either by the > CPE or by the Public Authoritative Servers. > > [...] > > outsourcing the authoritative naming service from the CPE > > ...and so forth, and so on. I'm sure you can see where my confusion stems > from ;-) > > > Similarly, I do not recall using the term proxy in one or the other > > draft, and I do not see what could be considered as a proxy. > > I fear I wasn't very clear: > > 1. the homenet nodes populate the master zone at the hidden master (which > is not at all the CPE, as we've established above) using DHCP; > This DHCP is the one of the home network and not the one of the ISP. > > 2. the hidden master (which is not at all the CPE) performs a zone > transfer to its secondaries (which are not at all the ones hardwired by > the ISP into the CPE) using normal DNS(SEC) procedures. > > So in effect the hostname data is flowing (1) from the node to the hidden > master which (2) forwards it to the authoritative secondaries. In effect, > it's being proxied from the node to the secondaries by the hidden master. > > OK, If I understand correctly you called that proxy as nodes do not register directly to the Public Authoritative Server. Instead, this is performed by the Internet Homenet Authoritative Server. Note also that nothing prevents the node to perform its registration to the Public Authoritative Server directly. This architecture do nothing against this. This is simply not part of the architecture. > > In the architecture we propose, things may be as follows: the NAS only > > needs a hostname: myserver for example. You plug the NAS in your home > > network, it announces its name via DHCP. The DHCP transmit the > > information to the entity that manages the DNS zone, which then > > outsource the zone to the registrar. You NAS does not need to be > > configured to update the zone at the registrar. > > Ah. I think that's the crucial point -- it's easier to provide > credentials to a single node rather than to every node that needs to > register in the global DNS. That makes sense. > > So how does the hidden master get the credentials? You say: > > The DHCP Server makes the Public Key available to the DNS servers, so > the CPE can secure its DNS transactions. Note that the Public Key > alone is not sufficient to perform the authentication [...] How the > binding is performed is out of scope of the document. It can be > a centralized database or various bindings may be sent to the > different servers. > > That speaks about the ISP's DHCP server, right? But now that we've > established that the hidden master is not the CPE -- it's not necessarily > on the same link as the DHCP server. Are you assuming a DHCP proxy at the > CPE? > As mentioned above the DHCP Options have currently been established for CPE. > > I also don't understand what you mean by "various bindings" in the last > sentence quoted above. I'd appreciate a clarification. Perhaps you can > tell us how the private keys are distributed in your implementation? > > A public key alone is not sufficient for authentication. You need an ID. This ID can be the domain name, the end user ID , the line number..... This is not specified in the document. As name servers needs the name and the key, the binding I would use would be the name and the key. > >>> Suppose your ISP has a connectivity issue, even a node in your home > >>> network will not be able to contact your web server as the DNS(SEC) > >>> resolution is not possible. > > >> But my nodes are still running mDNS/zeroconf, right? > > > By the way, I am not deprecating the use of mDNS at all it is simply > > orthogonal. > > What I meant by that is that you're still running mDNS, so losing > connectivity to the master won't prevent you from resolving using mDNS. > However, I now see that you're not deriving the DNS zone from mDNS, so the > name you're interested in might very well not be advertised over mDNS. > > Thanks for your patience, > > -- Juliusz > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --001a11c383acba632f04fdc30724 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

Thank you for your response and = feed backs. See my response in the text body as well as in your text. I thi= nk we are making progress.

[draft-mglt-homenet-front-end-naming= -delegation] and =20 [draft-mglt-homenet-naming-architecture-dhc-options] are distinct=20 documents. The one describes the architecture to outsource the homenet=20 authoritative naming service on the Internet. In that sense it should not b= e CPE specific. The second draft describes how DHCP Option could help to set this architecture. It does not mean=20 they must always be used.

A brief response to how these docume= nt are CPE specific:

=C2=A0=C2=A0=C2=A0 - The architectur= e document [draft-mglt-homenet-front-end-naming-delegation] in NOT CPE spec= ific. See below for more details.
=C2=A0=C2=A0=C2=A0 - The DHCP Options document [draft-mglt-homenet-naming-a= rchitecture-dhc-options] is currently CPE specific. It can be made non CPE = specific in two ways: 1) Keeping the document CPE specific and adding a sec= tion that describes how the option can be used when functions are not collo= cated. or 2) making the whole document non CPE specific. Reasons I would pr= efer 1) are: it makes things easier to read and understand, generalization = is easy and I believe these options will mostly be used by CPE. That said b= oth options are fine to me. See more details below.

A more detailed response:

=C2=A0=C2=A0=C2=A0 In [draft-mglt-homenet-front-end-naming-d= elegation] we use the term CPE, as this is the device we are focused on, an= d we also believe that in most homenet this device will play this role. How= ever, there are no such restriction. In this document, The CPE is the devic= e that owns the Homenet Zone and that could publish the zone on the Interne= t. Instead, of publishing itself, it outsources the Zone to the Public Serv= er. In order to clarify this misunderstanding, we can:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - a) Explicitl= y mention that the CPE is an example, and any device can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - b) Introduce a new desig= nation like the Internet Homenet Authoritative Server.

Maybe b) is better. I would appreciate= to have feed backs. Other designations are also welcome!

In [draft-mglt-homenet-naming-architecture-dhc-optio= ns] we took advantage of the collocation DHCP client that exchange with the= DHCP Server of the ISP, signing of the Zone and the Reverse Zone by the sa= me device. If we want to split the different functions we may have to consi= der:
=C2=A0=C2=A0=C2=A0 - the CPE,
=C2=A0=C2=A0=C2=A0 - the Internet Homenet= Authoritative Server
=C2=A0=C2=A0=C2=A0 - the Internet Reverse Homenet= Authoritative Server

To me only the Internet Reverse Homenet Autho= ritative Server needs to dialogue with the ISP, as the ISP manage the deleg= ation of the Reverse Zone. If the Internet Reverse Homenet Authoritative S= erver is not colocated with the CPE, the DHCP Server of the home network wi= ll have to relay these options to the DHCP Server of the ISP.

The Internet Homenet Authoritative Server can use the DHCP Options wit= h any other DHCP Server that is configured to respond to these options.
=
In the current draft, we used only one= key the one the CPE uses to sign both the Homenet Zone and the Reverse Zon= e. If this may not be performed by the CPE, we need to have two keys: one f= or the Homenet Zone and one for the Reverse Zone. So that's something w= e missed, thanks for pointing it out.

To me a network that have different en= tity for the CPE, the Internet Homenet Authoritative Server=C2=A0 and the I= nternet Reverse Homenet Authoritative Server in different devices and a DHC= P Relay may not be a home network anymore. I suggest the draft 1) remain re= stricted to the CPE and 2) add a section to describe how things could work = if the functions are split into different devices. I also agree we need to = have different options for the Key of the Reverse Homenet Zone and Homenet = Zone. The reason to do so, is that

Any opinions on that?


I also added s= mall comments inline.

BR,
Danie= l
On Wed, Jul 9, = 2014 at 3:39 AM, Juliusz Chroboczek <jch@pps.univ-paris-didero= t.fr> wrote:
Thanks for your patience,= Daniel. =C2=A0I feel I'm understanding a little more
now. =C2=A0My main misunderstanding was the following:

=C2=A0- you're not populating DNS with mDNS data, you're populating= it with the
=C2=A0 =C2=A0DHCP hostname data; I now understand that mDNS is mostly ortho= gonal.

What I still don't understand is how your protocol can work when the hidden master is not the CPE.

> In the architecture document we mention that the CPE is the most likel= y
> to host the DNS zone for the home network.

I'd really like to encourage you to revise the drafts so that it = makes it
clear that the hidden master is not necessarily the CPE. =C2=A0I'd be particularly keen to understand how the hidden master can sign the zone
when it is not the CPE, given that you expect signing keys to be obtained over DHCP.

> I do not think our architecture is bound to the CPE [...] If you could=
> point specific sections, that would help to clarify th= e next versions.

=C2=A0 =C2=A0 This document describes a homenet naming architecture w= here the CPEs
=C2=A0 =C2=A0 manage the DNS zone associates to its home network,

=C2=A0 =C2=A0 [...]

=C2=A0 =C2=A0 the DNS(SEC) Homenet Zone built by the CPE is outsourced to P= ublic
=C2=A0 =C2=A0 Authoritative Servers.

=C2=A0 =C2=A0 [...]

=C2=A0 =C2=A0 The zone signing and secure delegation can be performed eithe= r by the
=C2=A0 =C2=A0 CPE or by the Public Authoritative Servers.

=C2=A0 =C2=A0 [...]

=C2=A0 =C2=A0 outsourcing the authoritative naming service from the CPE

...and so forth, and so on. =C2=A0I'm sure you can see where my confusi= on stems
from ;-)

> Similarly, I do not recall using the term proxy in one or the other > draft, and I do not see what could be considered as a proxy.

I fear I wasn't very clear:

1. the homenet nodes populate the master zone at the hidden master (which =C2=A0 =C2=A0is not at all the CPE, as we've established above) using D= HCP;
This DHCP is the one of the home network and not = the one of the ISP.

2. the hidden master (which is not at all the CPE) performs a zone
=C2=A0 =C2=A0transfer to its secondaries (which are not at all the ones har= dwired by
=C2=A0 =C2=A0the ISP into the CPE) using normal DNS(SEC) procedures.

So in effect the hostname data is flowing (1) from the node to the hidden master which (2) forwards it to the authoritative secondaries. =C2=A0In eff= ect,
it's being proxied from the node to the secondaries by the hidden maste= r.

OK, If I understand correctly y= ou called that proxy as nodes do not register directly=C2=A0 to the Public = Authoritative Server. Instead, this is performed by the Internet Homenet Au= thoritative Server.

Note also that nothing prevents the node to perform its regi= stration to the Public Authoritative Server directly. This architecture do = nothing against this. This is simply not part of the architecture.

=C2=A0
> In the architecture we propose, things may be as follows: the NAS only=
> needs a hostname: myserver for example. You plug the NAS in your home<= br> > network, it announces its name via DHCP. The DHCP transmit the
> information to the entity that manages the DNS zone, which then
> outsource the zone to the registrar. You NAS does not need to be
> configured to update the zone at the registrar.

Ah. =C2=A0I think that's the crucial point -- it's easier to = provide
credentials to a single node rather than to every node that needs to
register in the global DNS. =C2=A0That makes sense.

So how does the hidden master get the credentials? =C2=A0You say:

=C2=A0 =C2=A0 The DHCP Server makes the Public Key available to the DNS ser= vers, so
=C2=A0 =C2=A0 the CPE can secure its DNS transactions. =C2=A0Note that the = Public Key
=C2=A0 =C2=A0 alone is not sufficient to perform the authentication [...] H= ow the
=C2=A0 =C2=A0 binding is performed is out of scope of the document. =C2=A0I= t can be
=C2=A0 =C2=A0 a centralized database or various bindings may be sent to the=
=C2=A0 =C2=A0 different servers.

That speaks about the ISP's DHCP server, right? =C2=A0But now that we&#= 39;ve
established that the hidden master is not the CPE -- it's not necessari= ly
on the same link as the DHCP server. =C2=A0Are you assuming a DHCP proxy at= the
CPE?

As mentioned above the DHCP Option= s have currently been established for CPE.
=C2=A0

I also don't understand what you mean by "various bindings" i= n the last
sentence quoted above. =C2=A0I'd appreciate a clarification. =C2=A0Perh= aps you can
tell us how the private keys are distributed in your implementation?

A public key alone is not suffi= cient for authentication. You need an ID. This ID can be the domain name, t= he end user ID , the line number..... This is not specified in the document= . As name servers needs the name and the key, the binding I would use would= be the name and the key.

=C2=A0
>>> Suppose your ISP has a connectivity issue, even a node in your= home
>>> network will not be able to contact your web server as the DNS= (SEC)
>>> resolution is not possible.

>> But my nodes are still running mDNS/zeroconf, right?

> By the way, I am not deprecating the use of mDNS= at all it is simply
> orthogonal.

What I meant by that is that you're still running mDNS, so losing=
connectivity to the master won't prevent you from resolving using mDNS.=
However, I now see that you're not deriving the DNS zone from mDNS, so = the
name you're interested in might very well not be advertised over mDNS.<= br>
Thanks for your patience,

-- Juliusz



--
Daniel Migault
Orang= e Labs -- Security
+33 6 70 72 69 58
--001a11c383acba632f04fdc30724-- From nobody Wed Jul 9 08:01: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 BD3AD1A0AE9 for ; Wed, 9 Jul 2014 08:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 853gwjtxVlMT for ; Wed, 9 Jul 2014 08:01:35 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1: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 DBD021A0645 for ; Wed, 9 Jul 2014 08:01:34 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s69F1XSX005917 for ; Wed, 9 Jul 2014 17:01:33 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 243792C21A7 for ; Wed, 9 Jul 2014 17:01:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id ZC_MXYcwiKI8 for ; Wed, 9 Jul 2014 17:01:32 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 232A62C21AD for ; Wed, 9 Jul 2014 17:01:31 +0200 (CEST) Received: from jch (uid 1000) (envelope-from jch@pps.univ-paris-diderot.fr) id c00177 by ijon.pps.univ-paris-diderot.fr (DragonFly Mail Agent v0.9); Wed, 09 Jul 2014 17:01:38 +0200 Date: Wed, 09 Jul 2014 17:01:38 +0200 Message-ID: <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Daniel Migault In-Reply-To: References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 09 Jul 2014 17:01:33 +0200 (CEST) X-Miltered: at korolev with ID 53BD594D.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53BD594D.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 53BD594D.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Cx_SaQ_5djyicVEgoBNqUXAoF5g Cc: "homenet@ietf.org" Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Wed, 09 Jul 2014 15:01:36 -0000 >     - The architecture document > [draft-mglt-homenet-front-end-naming-delegation] in NOT CPE specific. >     - The DHCP Options document > [draft-mglt-homenet-naming-architecture-dhc-options] is currently CPE > specific. Ah, I see. That definitely needs to be clarified. > - a) Explicitly mention that the CPE is an example [...] > - b) Introduce a new designation like the Internet Homenet Authoritative > Server. [...] > Maybe b) is better. Definitely so. Replacing CPE with IHAS in the text will allow you to see more clearly where you've assumed that the CPE and IHAS are co-located. There's still something I don't understand. If I'm understanding Steve's and Markus' work correctly, HNCP performs prefix delegation to internal routers over HNCP, and the internal routers don't proxy stateful DHCPv6 to the CPE. How does your protocol work in the presence of multiple links? Or are you assuming that only nodes directly connected to the IHAS/CPE can be advertised over your protocol? Finally, what happens when there are multiple CPEs, which HNCP explicitly supports? Are you assuming that only one acts as IHAS? -- Juliusz From nobody Wed Jul 9 08:34: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 E0EDA1A0AF8 for ; Wed, 9 Jul 2014 08:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.93 X-Spam-Level: X-Spam-Status: No, score=-3.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 KmZdQU9acLrA for ; Wed, 9 Jul 2014 08:34:11 -0700 (PDT) Received: from mx1.nominet.org.uk (mail.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 96F271A0AFB for ; Wed, 9 Jul 2014 08:34:11 -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: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=u2p1+pyPxrC4r4pzxmWP8R/J4sHe7otTnj1b6IdulIBlQ9fJZx1yLuAQ vKIVzFNjW5s+hWaLMEP9vB4aC0B/Eupfy5tIuL7qOrtPdQiesfx1BzkHX 9W7VkYWlL85sgp3nk27ywtpUqa8uWGHqDBQsZukOHJa+qf3067Dly6Be2 gn9OuQk3/WOX5Vg5I/Rfmhw1iMjY1WnojX6BliFeI7ETpdpzn6pKdpNc/ 7wOsQV4107MmcUXGNjyl4p4LwsuM/; 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=1404920051; x=1436456051; h=from:cc:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=3EK+MoDloxjObAtOjaPu+nu01pjnjcnt0Fnthapomw8=; b=J4RNeADrhpQpyKKk7W9Kc+VWTo0BSmPGdKIrkSdo8EvviF7yniMGunoH 9glcLpltSzxBdTyb5zrA/y6vwEhKbPMD/n3sG8XOn5udAEHzWcRqNKcNa 1tDUN1K2WXDoXcKcIs+Xqn4r8f3V7FgyuFpHElDO8zdfZhp/WxICoiZkn ZmmefpEEuXhWTOnodVzzkU/zGRriwocmxKdNUj4scj87BqYhUXaVc3tYe UVbfxNnSphdEzXde5RsahN9zwB1nj; X-IronPort-AV: E=Sophos;i="5.01,631,1400022000"; d="scan'208";a="11287714" X-IPAS-Result: Ak0NAM1fvVPV+MWRdGdsb2JhbABZgmp2Uwe/HYdBASVqFg8BDFmDewgBAQQBUyYFCwIBGjQyFw4CEgUJhW2CRAkDBAXJBheOYBEBUAeDBieBFgWyRYF3OQ Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 09 Jul 2014 16:34:09 +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, 9 Jul 2014 16:34:09 +0100 From: Ray Bellis CC: "homenet@ietf.org Group" Thread-Topic: WGLC (again) on draft-ietf-homenet-arch Thread-Index: AQHPm4s5+3DYJVuju0q+tiR98vBFvw== Date: Wed, 9 Jul 2014 15:34:08 +0000 Message-ID: <98FCD1E7-0211-4569-ABDA-039A18893FDA@nominet.org.uk> References: In-Reply-To: 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="Windows-1252" Content-ID: <1A8756526F228C4BA1775A0717CCCDC8@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/IgwHpF93hTC8mDjgwG49qk2a-_4 Subject: [homenet] WGLC (again) on draft-ietf-homenet-arch X-BeenThere: homenet@ietf.org 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, 09 Jul 2014 15:34:15 -0000 On 20 Jun 2014, at 06:07, Ted Lemon wrote: > As Tim mentioned a couple of days ago, there has been some productive dis= cussion about how to fix the routing section of the architecture document s= o that it satisfies the concerns that were raised during IESG review. Ray= Hunter posted a nice list of questions; I've asked him to produce a first = draft of a new version of this section. >=20 > Once that's done, Tim will hold the pen on the text, and I would obviousl= y appreciate any feedback people can give on it. The text from Ray will b= e a starting point, so if it's not what you think it should be, please expl= ain why and (if appropriate) send text. >=20 > As I mentioned earlier, this will not be open season on the document=97th= e IESG has already reviewed it, and making substantial changes at this poin= t that aren't addressing points raised in the IESG review is out of scope. >=20 > Thanks for whatever remaining patience you have to offer on this topic. draft-ietf-homenet-arch-17.txt, which contains the new text on routing that= Ted is referring to below, was published Friday. A diff from -16 is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-arch-17 This email commences a 2 week last call, ending Wednesday July 23 during th= e IETF meeting in Toronto. In parallel, we would like to ask Ted to review this new version with which= ever members of the IESG he deems necessary for additional review and pote= ntial change of ballot position. If the document passes this WG last call a= s well as any AD review by July 23, we will ask Ted to advance the document= before our meeting on Friday, July 25. As with the previous WGLC (albeit that was effectively immediately rendered= moot by the WG=92s unanimous rejection of the routing text that WGLC is th= e changes to section 3.5. thanks, Ray and Mark From nobody Wed Jul 9 08:46: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 336B81A0AFD for ; Wed, 9 Jul 2014 08:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.951 X-Spam-Level: X-Spam-Status: No, score=-4.951 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.651] 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 FgC6EhduWKdO for ; Wed, 9 Jul 2014 08:46:38 -0700 (PDT) Received: from mx2.nominet.org.uk (mail.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id 359C71A0AFF for ; Wed, 9 Jul 2014 08:46:38 -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:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=bcesRVjvTB8frMXUcj29rygsWbPz6bAhqAL8nOAWAOhMlXZVcOLFNnRT n388QHghnLqFeVgkdyoX6QFQ6WDIKMDhaVfZ9tjeFxnZh05S5vNrZoPBU TMl8iT5YvgmLmytPJXkRG8+janPUHCjCMhhdj/+FVEHRkvXK1+HJ0P382 mbvieC8nxwnVvlNGKWGCkYKQ7h/MCuMdM/xWb/38ZlxWaokU2fOxpAAMH JVO4EP3vfwEjP0ZB2jQ45EXWGG1z2; 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=1404920798; x=1436456798; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8IZUnhGvy4/f4wZApe1OhupT6guu0nrjTP/lAG3DOuM=; b=MYLwSYTbZdYJKhnCxdJhk4/+3nRDPXTQ2gw1gGDgTwkFkLJf8jAHiIQN BK7S/8g+ZalVP7saGP/qHoJ7DqY6hFFsLjXIAHlLqOU55QzPSF1o/ZS97 fS3qAmAc2ME6KJWTSPOHsvIBvMN3gInOWbAkT3ipgnrHn+b9J8FLXU+Bu YMZnK+D8Ze3JVZLHqWr0yqi/9iyw22sUILfh6BBvq2lKxDRMVNFa4KoLH +7mthFZchmhZW2g4Hl5ZNPxfdExSE; X-IronPort-AV: E=Sophos;i="5.01,631,1400022000"; d="scan'208";a="10603091" X-IPAS-Result: As8EAN9ivVPV+MWRdGdsb2JhbABZgmqBUMZeAYEQFg8BDFmEAwEBBAFTKwsCAQhGMiUCBBOIOgkDyRUXjw86gy2BFgWxA4FCgjA Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 09 Jul 2014 16:46:37 +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, 9 Jul 2014 16:46:36 +0100 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: {Sender Address Possibly Forged} [homenet] WGLC (again) on draft-ietf-homenet-arch Thread-Index: AQHPm4s5+3DYJVuju0q+tiR98vBFv5uX0hQA Date: Wed, 9 Jul 2014 15:46:36 +0000 Message-ID: <2099BE2A-33EA-4DCC-B8C1-2A16F13E0620@nominet.org.uk> References: <98FCD1E7-0211-4569-ABDA-039A18893FDA@nominet.org.uk> In-Reply-To: <98FCD1E7-0211-4569-ABDA-039A18893FDA@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="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/tuoXpvIzR7fL3yeW-8o_VZ54BHk Subject: Re: [homenet] {Sender Address Possibly Forged} WGLC (again) on draft-ietf-homenet-arch X-BeenThere: homenet@ietf.org 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, 09 Jul 2014 15:46:41 -0000 On 9 Jul 2014, at 16:34, Ray Bellis wrote: > As with the previous WGLC (albeit that was effectively immediately render= ed moot by the WG=92s unanimous rejection of the routing text that WGLC is = the changes to section 3.5. Sorry, that final paragraph should have read: As with the previous WGLC (albeit that was effectively immediately rendered= moot by the WG=92s unanimous rejection of the routing text that came from = the last IESG review) the only text that is in scope of this WGLC is the ch= anges to section 3.5. Ray From nobody Wed Jul 9 09:11: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 A735B1A0404 for ; Wed, 9 Jul 2014 09:11:31 -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 NkCDl6Bwwk0c for ; Wed, 9 Jul 2014 09:11:26 -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 46D6D1A009E for ; Wed, 9 Jul 2014 09:11:26 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b13so7669245wgh.35 for ; Wed, 09 Jul 2014 09:11:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=LQTXu2jBnv1LmrkYfnOT2eoC6gjF8vKyLEPkF3SEkPA=; b=Pe/KNJ9NEDOI5bVpgK1mowsvY2XS+4tKCqLwWl/MWivZe8Rfcjn34F91DSStsyNxCw jSMbpQ7l+msEMPalcxukVukOo1l79+YO+w0AqeFLsuUM+jUrtB7HW7rdKdWgqSYQLHrz JOQnEGdhV8vaE+O03HRu+jjuZWPWaNP7WgvA1OOOsAKBJJMht/TFc7c5/MxVFg1KpFsI chL5Gy4FMdxf2M/2q/UAsXWsDTtR3RwR3QRzklVLU0r2gDufo+rnGWfgG70fjF4EQGev ytFjF9nZG3k8npmc5ZlZpQPhTpQ0cbZLKwK8tQwU1Bk9i5a80Z92VQepGnAnWuSa+neM D+pg== X-Gm-Message-State: ALoCoQlIVW5q+lGjcTUFMUhss41/gZXowbA4wmo2d+IEZ8uwoRvoYPyeRu5+MHcln9zaTaFsWRJ9 X-Received: by 10.180.20.228 with SMTP id q4mr12518256wie.74.1404922284606; Wed, 09 Jul 2014 09:11:24 -0700 (PDT) Received: from ?IPv6:2001:420:c0c1:8:6876:dd2e:d5de:8e9? ([2001:420:c0c1:8:6876:dd2e:d5de:8e9]) by mx.google.com with ESMTPSA id ub11sm9118791wib.1.2014.07.09.09.11.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 09:11:23 -0700 (PDT) From: Mark Townsley Content-Type: multipart/alternative; boundary="Apple-Mail=_CDF638C6-0A34-4ECE-A6F8-5B06EDEF5601" Message-Id: <90E98893-6517-4B63-A724-E7B2F2A826CF@townsley.net> Date: Wed, 9 Jul 2014 18:11:22 +0200 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/l12LgPJzauudAkcb2HD2aDM3kOw Subject: [homenet] Draft Homenet Agenda X-BeenThere: homenet@ietf.org 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, 09 Jul 2014 16:11:31 -0000 --Apple-Mail=_CDF638C6-0A34-4ECE-A6F8-5B06EDEF5601 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ray and I are working on the Agenda for homenet, and are already a = couple of days tardy for which we apologize. We have already received = some requests for agenda time, and have also reserved space for a couple = of standing items. If you don=92t see your item below, please let us = know.=20 IETF 90 - Homenet Agenda Friday 25th July 2014, 09:00 - 11:30, Canadian room 0. Administrivia Blue Sheets Note taker - Thomas Clausen Jabber relay - TBC 1. Routing Homenet Architecture - Routing Area Review - Tim Chown and Ted Lemon = (TBC) - draft-ietf-homenet-arch-17 [will cancel if document has advanced by then] Routing Protocol Selection Discussion - Chairs Hybrid Access Network Architecture - Zhangdacheng (TBC) - draft-lhwxz-hybrid-access-network-architecture-00 - draft-heileyli-gre-notifications-00 2. Addressing / Configuration HNCP Updates - Steven Barth - draft-ietf-homenet-hncp-01 Prefix Assignment - Pierre Pfister - draft-pfister-homenet-prefix-assignment-02=20 3. Naming Front End Naming Delegation and Validator DHC Options - Daniel Migault - draft-mglt-homenet-front-end-naming-delegation-04 - draft-mglt-homenet-dnssec-validator-dhc-options-02 4. Service Discovery DNS SD Hybrid Proxy - Markus Stenberg - draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf-01 5. Security / Border Discovery HNCP Security - TBC - draft-bonnetain-hncp-security-00 Minimalist PCP Proxy - Markus Stenberg - draft-stenberg-homenet-minimalist-pcp-proxy --Apple-Mail=_CDF638C6-0A34-4ECE-A6F8-5B06EDEF5601 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Ray and I are working on the Agenda = for homenet, and are already a couple of days tardy for which we = apologize. We have already received some requests for agenda time, and = have also reserved space for a couple of standing items. If you don=92t = see your item below, please let us know.


IETF 90 - Homenet = Agenda
Friday = 25th July 2014, 09:00 - 11:30, Canadian room

0. Administrivia

Blue Sheets
Note taker - Thomas = Clausen
Jabber = relay - TBC

1. = Routing

Homenet = Architecture - Routing Area Review - Tim Chown and Ted Lemon = (TBC)
- draft-ietf-homenet-arch-17
[will = cancel if document has advanced by then]

Routing Protocol Selection Discussion = - Chairs

Hybrid = Access Network Architecture - Zhangdacheng (TBC)
- = draft-lhwxz-hybrid-access-network-architecture-00
- = draft-heileyli-gre-notifications-00

2. Addressing / = Configuration

HNCP Updates - Steven Barth
- = draft-ietf-homenet-hncp-01

Prefix Assignment - Pierre Pfister
- = draft-pfister-homenet-prefix-assignment-02

3. Naming

Front End Naming Delegation and = Validator DHC Options - Daniel Migault
- = draft-mglt-homenet-front-end-naming-delegation-04
- = draft-mglt-homenet-dnssec-validator-dhc-options-02

4. Service = Discovery

DNS SD = Hybrid Proxy - Markus Stenberg
- = draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf-01

5. Security / Border = Discovery

HNCP = Security - TBC
= - = draft-bonnetain-hncp-security-00

Minimalist PCP Proxy - Markus = Stenberg
= - = draft-stenberg-homenet-minimalist-pcp-proxy

<= /body>= --Apple-Mail=_CDF638C6-0A34-4ECE-A6F8-5B06EDEF5601-- From nobody Wed Jul 9 13:19: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 9824E1AD6B0 for ; Wed, 9 Jul 2014 13:19:16 -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 BlEvxrimJOe7 for ; Wed, 9 Jul 2014 13:19:12 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e: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 B5CFA1B278A for ; Wed, 9 Jul 2014 13:19:07 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id rd3so9830698pab.3 for ; Wed, 09 Jul 2014 13:19:07 -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=ZDbDuNMu/2Pxk58qaq+Xm7wxkfWntxRJfAlYcCg+brQ=; b=wD9SjJ2jSLAXoXgpUWLDeXGNlXDZ7Z4EsAIoy4falZ4pR+3QSW9qDR7lahHNgbMBJD 5nQAPGwqiRLd/nXFID6ULt25xz9xwnicb3MUHNaGPvS4wW77dQ2i0jTwbh6MRN8QVUqF XZdKgJBzQWtqNS7gaBRQRoo/Z45xcXIkWxc+BUJ3/K37KbYmCVTfdfyrgUt4KPu7qxeJ TnJ4NNF+pamYDABE0DINxDsEECRXOxx0DDsospqgnKwsAJkdwMytW4rzw5cykpt6BKyo l3Zc8GReU1vLqzQGz4JW9EthXxqo0BBoz7xPWCkGpAUURq1eBRnURLQyg4aFGYTsUFeb BfEA== X-Received: by 10.68.252.41 with SMTP id zp9mr33103376pbc.65.1404937147364; Wed, 09 Jul 2014 13:19:07 -0700 (PDT) Received: from [192.168.178.23] (158.197.69.111.dynamic.snap.net.nz. [111.69.197.158]) by mx.google.com with ESMTPSA id bx5sm59723350pbd.69.2014.07.09.13.19.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 13:19:06 -0700 (PDT) Message-ID: <53BDA3BF.2000207@gmail.com> Date: Thu, 10 Jul 2014 08:19:11 +1200 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: <98FCD1E7-0211-4569-ABDA-039A18893FDA@nominet.org.uk> In-Reply-To: <98FCD1E7-0211-4569-ABDA-039A18893FDA@nominet.org.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/HEHs3hArA9k_jUFyxZekx3gPSxI Cc: "homenet@ietf.org Group" Subject: Re: [homenet] WGLC (again) on draft-ietf-homenet-arch X-BeenThere: homenet@ietf.org 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, 09 Jul 2014 20:19:17 -0000 On 10/07/2014 03:34, Ray Bellis wrote: ... > draft-ietf-homenet-arch-17.txt, which contains the new text on routing that Ted is referring to below, was published Friday. It's fine. It's an informational document describing principles. It is not a technical specification. Ship it. Brian (suffering a severe case of WGLC fatigue). From nobody Mon Jul 14 23:47: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 995251B2822 for ; Mon, 14 Jul 2014 23:47:43 -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 O62xoYzsc2iW for ; Mon, 14 Jul 2014 23:47:42 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.199]) by ietfa.amsl.com (Postfix) with ESMTP id C5B491B2824 for ; Mon, 14 Jul 2014 23:47:41 -0700 (PDT) Received: from poro.lan (84.248.80.109) by kirsi1.inet.fi (8.5.142.08) (authenticated as stenma-47) id 53B153320128A3BA; Tue, 15 Jul 2014 09:47:36 +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: <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> Date: Tue, 15 Jul 2014 09:47:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/CnCCu3zaIfftIkacwmevKl3QnAE Cc: "homenet@ietf.org" , Markus Stenberg , Daniel Migault Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Tue, 15 Jul 2014 06:47:43 -0000 On 9.7.2014, at 18.01, Juliusz Chroboczek = wrote: > There's still something I don't understand. If I'm understanding = Steve's > and Markus' work correctly, HNCP performs prefix delegation to = internal > routers over HNCP, and the internal routers don't proxy stateful = DHCPv6 to > the CPE. How does your protocol work in the presence of multiple = links? > Or are you assuming that only nodes directly connected to the IHAS/CPE = can > be advertised over your protocol? Or even more weirdly, what if you don=92t want stateful DHCPv6? SLAAC + = temporary addresses? > Finally, what happens when there are multiple CPEs, which HNCP = explicitly > supports? Are you assuming that only one acts as IHAS? .. and how do the zones map to multiple uplinks .. Personally, I don=92t believe in auto-exported ~full DNS information = from home because current service discovery schemes (mdns, dns-sd, upnp) = or even host-name discovery schemes (dhcp*) do not really lend = themselves to the external visibility being _opt in_. I don=92t really = want to publish my home zone, and if I even did, anything that=92s = firewalled (=3D everything except few ports on few addresses) is not = useful outside the home in any case. Getting security right on =91all devices=92 so you can leave your = firewall open by default is a nice dream, but I think I stopped dreaming = sometime in the 90s on that front :p Default deny + clued allow is much, = much better than the default allow + ISP doing filtering for you after = your home is owned. Cheers, -Markus P.S. I am amused by recent WeMo/that other IoT light security woes. I=92m = sure publishing _their_ names on my home zone would help me, somehow, to = get remote controlled home disco if nothing else.. at least, if they = weren=92t on a separate, L3-firewalled link that has no outside = connectivity outside my home. From nobody Tue Jul 15 07:29: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 0B0DD1B2886 for ; Tue, 15 Jul 2014 07:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.353 X-Spam-Level: X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.651, 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 jy2WrhJ0lUAU for ; Tue, 15 Jul 2014 07:29:26 -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 2BE0C1B2883 for ; Tue, 15 Jul 2014 07:29:26 -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 s6FETOHa005486 for ; Tue, 15 Jul 2014 07:29:24 -0700 Message-ID: <53C53AC4.3080807@mtcc.com> Date: Tue, 15 Jul 2014 07:29:24 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: homenet@ietf.org References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> In-Reply-To: <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/kX6shD1K2BUkpDm08kbGNCUcl_c Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Tue, 15 Jul 2014 14:29:28 -0000 On 07/14/2014 11:47 PM, Markus Stenberg wrote: > On 9.7.2014, at 18.01, Juliusz Chroboczek wrote: >> There's still something I don't understand. If I'm understanding Steve's >> and Markus' work correctly, HNCP performs prefix delegation to internal >> routers over HNCP, and the internal routers don't proxy stateful DHCPv6 to >> the CPE. How does your protocol work in the presence of multiple links? >> Or are you assuming that only nodes directly connected to the IHAS/CPE can >> be advertised over your protocol? > Or even more weirdly, what if you don’t want stateful DHCPv6? SLAAC + temporary addresses? > >> Finally, what happens when there are multiple CPEs, which HNCP explicitly >> supports? Are you assuming that only one acts as IHAS? > .. and how do the zones map to multiple uplinks .. > > Personally, I don’t believe in auto-exported ~full DNS information from home because current service discovery schemes (mdns, dns-sd, upnp) or even host-name discovery schemes (dhcp*) do not really lend themselves to the external visibility being _opt in_. I don’t really want to publish my home zone, and if I even did, anything that’s firewalled (= everything except few ports on few addresses) is not useful outside the home in any case. > > Yet, I really, really, triple-super really want to be able to access my home network devices when i'm not at home. Any part of the naming architecture better take that as a very basic requirement. Mike From nobody Tue Jul 15 08:41: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 5F8951B28BA for ; Tue, 15 Jul 2014 08:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 HS4aIWfU2iY7 for ; Tue, 15 Jul 2014 08:41:16 -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 0068F1B2875 for ; Tue, 15 Jul 2014 08:41:15 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A282020028; Tue, 15 Jul 2014 11:42:29 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3C10363B0E; Tue, 15 Jul 2014 11:41:15 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 256E063AED; Tue, 15 Jul 2014 11:41:15 -0400 (EDT) From: Michael Richardson To: Markus Stenberg In-Reply-To: <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@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/L6SxQe3fqEb9P9LNGSNYisKRZNU Cc: "homenet@ietf.org" , Daniel Migault , Juliusz Chroboczek Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Tue, 15 Jul 2014 15:41:17 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Markus Stenberg wrote: > Personally, I don=E2=80=99t believe in auto-exported ~full DNS inform= ation from > home because current service discovery schemes (mdns, dns-sd, upnp) or > even host-name discovery schemes (dhcp*) do not really lend themselves > to the external visibility being _opt in_. I don=E2=80=99t really wan= t to > publish my home zone, and if I even did, anything that=E2=80=99s fire= walled (=3D > everything except few ports on few addresses) is not useful outside t= he > home in any case. Many people *do* want seemless access, and as their devices roam outside the home, they expect, that having entered the name of the device, they expect that whatever security they have (such as a VPN) will then get kicked off automatically. That requires that names->IPv6 mapping be available so that the VPN can know it is supposed to do something. I have way too much experience with IPsec VPNs where I have to turn the VPN on, flush my DNS cache, restart my browser, and then finally, I can access some internal name, all because some CIO thought that it would be insecure = if the world knew about intranet.example.com. That's not the same as having an open network, so please stop saying that names are useless because there is no connectivity. I think that whether you "auto-export", or whitelist, or blacklist, etc. is completely a local matter. We may recommend a default, but we should make sure that the mechanisms exist. =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) iQEVAwUBU8VLl4CLcPvd0N1lAQIMDggApsb/K3ZaV4ddADyUopG+aOUMklD9pMqS NO2xbnrZXB0w74xp7RdXUYwrHJWgrOvY8h5BGTtrG9ZyTtnTvgolAWz7zdEQOp9w n9TKRc5ImDxYcCGEuWLzZcvLm5xAtoJPImFEeLI1SumShmQwkUm1hAoARQVpTZmB Zyguof9Fhb5v7qX/WcoHBmr3HW9nY/Xsl29u8vCVN1dU1eq+DXSOLxBM3Xs4FYWy KQHJH627U6YNIVvRXMhZd3D4YlDoFcMPcWMoQLJh+uR3io6RFoVUhHtxrnuW5QcZ iYFmaOW7hGKBt1IqakAWhBVi0eVOcm6QRKWbqakhJFglpMjqxsbTdQ== =Eawe -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 15 08:57: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 E19B01B28C1 for ; Tue, 15 Jul 2014 08:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] 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 oY6NkJz5r3ll for ; Tue, 15 Jul 2014 08:57:09 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1: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 3CD141B287F for ; Tue, 15 Jul 2014 08:57:09 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s6FFv7s6015040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Jul 2014 17:57:07 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id s6FFv7lu030546; Tue, 15 Jul 2014 17:57:07 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id ECF232C4018; Tue, 15 Jul 2014 17:57:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id eP3gOpu4nOUn; Tue, 15 Jul 2014 17:57:06 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 037452C4015; Tue, 15 Jul 2014 17:57:04 +0200 (CEST) Received: from jch by lanthane.pps.univ-paris-diderot.fr with local (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X756G-000518-Qa; Tue, 15 Jul 2014 17:57:04 +0200 Date: Tue, 15 Jul 2014 17:57:04 +0200 Message-ID: <7ioawqpqcv.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Michael Richardson In-Reply-To: <21162.1405438875@sandelman.ca> References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> <21162.1405438875@sandelman.ca> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 15 Jul 2014 17:57:07 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 15 Jul 2014 17:57:07 +0200 (CEST) X-Miltered: at korolev with ID 53C54F53.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 53C54F53.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53C54F53.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 53C54F53.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 53C54F53.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 53C54F53.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/FFXjK0b2OcW3sgYSJ_akHznxq08 Cc: "homenet@ietf.org" , Markus Stenberg , Daniel Migault Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Tue, 15 Jul 2014 15:57:11 -0000 > Many people *do* want seemless access, and as their devices roam outside the > home, I think there are two issues here which are mostly orthogonal: (1) Do we want a standardised protocol for exporting data into the global DNS? (2) What is the right policy from exporting homenet names into the global DNS? I'm pretty sure that (1) can be answered without giving a full answer to (2). -- Juliusz From nobody Tue Jul 15 09:00: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 A2BF11B28D7 for ; Tue, 15 Jul 2014 09:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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_SBshOf46Zx for ; Tue, 15 Jul 2014 09:00: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 4F8DB1B28D1 for ; Tue, 15 Jul 2014 09:00: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 6818A602E5 for ; Tue, 15 Jul 2014 18:00:41 +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 4A4616025A for ; Tue, 15 Jul 2014 18:00:38 +0200 (CEST) Received: (qmail 4959 invoked by uid 1007); 15 Jul 2014 18:00:38 +0200 Date: Tue, 15 Jul 2014 18:00:38 +0200 From: Gert Doering To: Michael Richardson Message-ID: <20140715160038.GK51793@Space.Net> References: <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> <21162.1405438875@sandelman.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5NVDATmc8A1f9nDP" Content-Disposition: inline In-Reply-To: <21162.1405438875@sandelman.ca> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/BzD0c5LVthUfg4M8WwhDwksgwO8 Cc: "homenet@ietf.org" , Markus Stenberg , Daniel Migault , Juliusz Chroboczek Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Tue, 15 Jul 2014 16:00:49 -0000 --5NVDATmc8A1f9nDP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jul 15, 2014 at 11:41:15AM -0400, Michael Richardson wrote: > I think that whether you "auto-export", or whitelist, or blacklist, etc. = is > completely a local matter. We may recommend a default, but we should make > sure that the mechanisms exist. +1 for "have a policy that specifies whether names should be auto-exported or not", and I actually want all my machines be visible, and most of them be *reachable*, since they can protect themselves. They have to. 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 --5NVDATmc8A1f9nDP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBU8VQJt9WwGXkzn/FAQLbFA//S9tvNt2wuULQPHehrq85jEeh6FaWABTc AXNtardpT9nVIWgqXSZFJTR21C9htv8pj2TgaDtgRyJKaPPu60jLNZwPxGMTWHiN h8aHHHHfFYIh27rqlTrnSPT0eGLx0RhYxM0cGPUNK9W7gJ/O4CBr8EcnEGfBHVZY pwKy0d3elTDfFh2FfbUJ2gK49Q4TbLKZcmi07BJ0gTRtJWrsg3d2iYBW8DBwIxm/ 64GJl/YtHI583gNgoc+sAx5qCD/RcG5q5qUhVRHj7nxtNwREFQVmn7wF+pG421ll KMgcjMAwCzxOoUZb7wVzRw+pybavirFzuAIGYPfH+zbLQ6e1CB3GxF+beGFWS9se ywckvAL5QT9khhVXDuf7uLhiv8leK2EFTzy6exAEk2Bgl852iK2S/4nZ54OpzWrp Mf5gu4olMVL8twgLTfCNcRdIN69shz0uzk1i4YoZVt5+0X6/9r7vKsKc54xRePFS D8U/Ifz0OHBO+3Gxo0g3rJ5J4OQFKrq98NMD6YzHJBikV8obKXiCitZo8dh3Y7u+ pEqo74z6DDlitku1G5nv+xsO2SwAW4A/hK7keAHiGuZtpcS8Z+ktryN8jPXVV/ov IxHCGMR9iuKY7hPifwPLckYF+iKnVyIfjrSbjx2q6I6Hvp6A4HWG86Cc3bPeQtVD jr5q7X2NvJE= =fg7b -----END PGP SIGNATURE----- --5NVDATmc8A1f9nDP-- From nobody Tue Jul 15 10:00: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 BD2DE1A0AC0 for ; Tue, 15 Jul 2014 10:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 Cv-RWYHtn3qx for ; Tue, 15 Jul 2014 10:00:09 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB441A0ABB for ; Tue, 15 Jul 2014 10:00:09 -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 55EAE238088A; Tue, 15 Jul 2014 13:00: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: <7ioawqpqcv.wl%jch@pps.univ-paris-diderot.fr> Date: Tue, 15 Jul 2014 13:00:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7B5390DD-6969-4E26-A85E-0B436F48448F@fugue.com> References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> <21162.1405438875@sandelman.ca> <7ioawqpqcv.wl%jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/a6KPRGWzxyeUhe8Nfm9HR4FZxJo Cc: Michael Richardson , "homenet@ietf.org" , Markus Stenberg , Daniel Migault Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Tue, 15 Jul 2014 17:00:13 -0000 On Jul 15, 2014, at 11:57 AM, Juliusz Chroboczek = wrote: > (1) Do we want a standardised protocol for exporting data into the = global DNS? > (2) What is the right policy from exporting homenet names into the = global DNS? We already have two standardized protocols for exporting data into the = global DNS: Dynamic DNS updates and DNS zone transfers. What's needed = is just the connective tissue to set it up. There is no one right policy for exporting. I assume you mean that we = need to recommend a default policy and also document the range of other = policies that the end user might choose to use. It would also be nice = if the PCP server could somehow feed into this: if you open a PCP port, = then you get a DNS registration; if you don't, you don't. Something = like that. From nobody Tue Jul 15 11:35: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 71BB41A0B13 for ; Tue, 15 Jul 2014 11:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 nq7ClOfLDqaC for ; Tue, 15 Jul 2014 11:35:01 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1: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 5DEB11A0B04 for ; Tue, 15 Jul 2014 11:34:55 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s6FIYrH2004823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Jul 2014 20:34:53 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id s6FIYrNw006818 for ; Tue, 15 Jul 2014 20:34:53 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 94DAE2C4031 for ; Tue, 15 Jul 2014 20:34:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id hTjuEHENBVCM for ; Tue, 15 Jul 2014 20:34:52 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id ACE642C4029 for ; Tue, 15 Jul 2014 20:34:50 +0200 (CEST) Received: from jch (uid 1000) (envelope-from jch@pps.univ-paris-diderot.fr) id c002c9 by ijon.pps.univ-paris-diderot.fr (DragonFly Mail Agent v0.9); Tue, 15 Jul 2014 20:35:09 +0200 Date: Tue, 15 Jul 2014 20:35:09 +0200 Message-ID: <87a98acvxe.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ted Lemon In-Reply-To: <7B5390DD-6969-4E26-A85E-0B436F48448F@fugue.com> References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> <21162.1405438875@sandelman.ca> <7ioawqpqcv.wl%jch@pps.univ-paris-diderot.fr> <7B5390DD-6969-4E26-A85E-0B436F48448F@fugue.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 15 Jul 2014 20:34:53 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 15 Jul 2014 20:34:53 +0200 (CEST) X-Miltered: at korolev with ID 53C5744D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 53C5744D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53C5744D.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 53C5744D.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 53C5744D.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 53C5744D.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/tmR6-sBAitvw_wWANxpuS9rbhxw Cc: "homenet@ietf.org" , Daniel Migault Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Tue, 15 Jul 2014 18:35:01 -0000 > I assume you mean that we need to recommend a default policy and also > document the range of other policies that the end user might choose to > use. No, I just mean that Markus not wanting anything published in DNS is policy, and that's completely independent of whether we want to define a mechanism. I have no opinion on either point. All I know is that if we want to define a mechanism, then the mechanism should be compatible with the worldview of HNCP, which includes things such as multiple internal links and multiple CPEs. -- Juliusz From nobody Tue Jul 15 11:46: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 EB6401A000D for ; Tue, 15 Jul 2014 11:45:38 -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 q4LkADbuUesc for ; Tue, 15 Jul 2014 11:45:37 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.230]) by ietfa.amsl.com (Postfix) with ESMTP id D6E661A0009 for ; Tue, 15 Jul 2014 11:45:36 -0700 (PDT) Received: from poro.lan (84.248.80.109) by kirsi1.inet.fi (8.5.142.08) (authenticated as stenma-47) id 53B15332013A8533; Tue, 15 Jul 2014 21:45:26 +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: <87a98acvxe.wl-jch@pps.univ-paris-diderot.fr> Date: Tue, 15 Jul 2014 21:45:24 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> <21162.1405438875@sandelman.ca> <7ioawqpqcv.wl%jch@pps.univ-paris-diderot.fr> <7B5390DD-6969-4E26-A85E-0B436F48448F@fugue.com> <87a98acvxe.wl-jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/YqOFPeaOFWV3-a0HdLP96WZbGGo Cc: "homenet@ietf.org" , Markus Stenberg , Ted Lemon , Daniel Migault Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Tue, 15 Jul 2014 18:45:39 -0000 On 15.7.2014, at 21.35, Juliusz Chroboczek = wrote: >> I assume you mean that we need to recommend a default policy and also >> document the range of other policies that the end user might choose = to >> use. >=20 > No, I just mean that Markus not wanting anything published in DNS is > policy, and that's completely independent of whether we want to define > a mechanism. I have no opinion on either point. >=20 > All I know is that if we want to define a mechanism, then the = mechanism > should be compatible with the worldview of HNCP, which includes things > such as multiple internal links and multiple CPEs. The mechanism should not be tied to the particular ISPs either, except = perhaps optionally. In my case, I have 2 upstream ISPs, neither of which officially even = admits IPv6 exists, but I _would_ like to publish my home v6 zone = somewhere.. *sigh* So to summarize: - mechanism to publish either single DNS updates or zones would be nice = to have (possibly with tie-in to service discovery) - with policy bits thrown in=20 and some sort of possible zero-conf use, with help of co-operating ISP = perhaps, but _not_ requiring the first-hop ISP to be the only party you = interact with. The =91homenet=92 policy stuff may be actually relatively extensive in = the end, although with some sort of reasonable zeroconf defaults. In this case, policy stuff should apply to what=92s advertised (and in = which scope), and where it can be reached from (firewalling either with = accept rules, or PCP-derived holes). (Hmm. We don=92t seem to have any drafts on policy or management yet.) Cheers, -Markus= From nobody Tue Jul 15 11:59: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 DE4481B28FA for ; Tue, 15 Jul 2014 11:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 DV2ROJoOAH6a for ; Tue, 15 Jul 2014 11:59:03 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1: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 2F4B01B28F9 for ; Tue, 15 Jul 2014 11:59:02 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s6FIx14G011339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Jul 2014 20:59:01 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id s6FIx1uC012209 for ; Tue, 15 Jul 2014 20:59:01 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 504822C4035 for ; Tue, 15 Jul 2014 20:59:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id CuWadI6TxgHq for ; Tue, 15 Jul 2014 20:59:00 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 43CE42C4029 for ; Tue, 15 Jul 2014 20:59:00 +0200 (CEST) Received: from jch (uid 1000) (envelope-from jch@pps.univ-paris-diderot.fr) id c002c9 by ijon.pps.univ-paris-diderot.fr (DragonFly Mail Agent v0.9); Tue, 15 Jul 2014 20:59:19 +0200 Date: Tue, 15 Jul 2014 20:59:19 +0200 Message-ID: <877g3ecut4.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Markus Stenberg In-Reply-To: References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> <21162.1405438875@sandelman.ca> <7ioawqpqcv.wl%jch@pps.univ-paris-diderot.fr> <7B5390DD-6969-4E26-A85E-0B436F48448F@fugue.com> <87a98acvxe.wl-jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 15 Jul 2014 20:59:01 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 15 Jul 2014 20:59:01 +0200 (CEST) X-Miltered: at korolev with ID 53C579F5.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 53C579F5.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53C579F5.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 53C579F5.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 53C579F5.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 53C579F5.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/vQbn18cHMMXOz3XtnMUsXikt6Js Cc: "homenet@ietf.org" , Daniel Migault Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Tue, 15 Jul 2014 18:59:05 -0000 >> All I know is that if we want to define a mechanism, then the mechanism >> should be compatible with the worldview of HNCP, which includes things >> such as multiple internal links and multiple CPEs. > The mechanism should not be tied to the particular ISPs either, except > perhaps optionally. Uh-huh. Oh, and lest I forget: HNCP does not require stateful DHCPv6 for end nodes. It would be cool if the dynamic DNS mechanism didn't require it either. -- Juliusz From nobody Tue Jul 15 12:00: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 454961B2928 for ; Tue, 15 Jul 2014 12:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 4dIETH3S-U1i for ; Tue, 15 Jul 2014 12:00:48 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 195D41B2907 for ; Tue, 15 Jul 2014 12:00:46 -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 E99B9238088A; Tue, 15 Jul 2014 15:00:44 -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, 15 Jul 2014 15:00:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> <21162.1405438875@sandelman.ca> <7ioawqpqcv.wl%jch@pps.univ-paris-diderot.fr> <7B5390DD-6969-4E26-A85E-0B436F48448F@fugue.com> <87a98acvxe.wl-jch@pps.univ-paris-diderot.fr> To: Markus Stenberg X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Y2qrYfN_HNsucwHMYH1f38Nd1nE Cc: "homenet@ietf.org" , Daniel Migault , Juliusz Chroboczek Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Tue, 15 Jul 2014 19:00:50 -0000 On Jul 15, 2014, at 2:45 PM, Markus Stenberg = wrote: > The mechanism should not be tied to the particular ISPs either, except = perhaps optionally. I think the motivation with Daniel's draft was to provide support for = the optional case where the ISP wants to support it, because you get = some better results in that case, but clearly the full solution needs to = work "well enough" with partial or nonexistent ISP cooperation. Have you looked at = https://datatracker.ietf.org/doc/draft-lemon-dhc-dns-pd/ ? I don't = have time to work on this anymore, but the goal was to allow the ISP and = the end-user to negotiate how they want to set up the DNS for a = delegated prefix, and I'd like to see it move forward if there is = interest. From nobody Tue Jul 15 12:39: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 624411A0035 for ; Tue, 15 Jul 2014 12:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.651, 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 de2EYQ5D7wcy for ; Tue, 15 Jul 2014 12:39: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 8316E1A0027 for ; Tue, 15 Jul 2014 12:39:00 -0700 (PDT) Received: from [10.1.10.25] (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 s6FJcwxL023934 for ; Tue, 15 Jul 2014 12:38:59 -0700 Message-ID: <53C58350.3020006@mtcc.com> Date: Tue, 15 Jul 2014 12:38:56 -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: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> <21162.1405438875@sandelman.ca> <7ioawqpqcv.wl%jch@pps.univ-paris-diderot.fr> <7B5390DD-6969-4E26-A85E-0B436F48448F@fugue.com> <87a98acvxe.wl-jch@pps.univ-paris-diderot.fr> 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/kB4R9wFwosHVNcSZkBOhxERWZfY Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Tue, 15 Jul 2014 19:39:01 -0000 On 7/15/14, 12:00 PM, Ted Lemon wrote: > On Jul 15, 2014, at 2:45 PM, Markus Stenberg wrote: >> The mechanism should not be tied to the particular ISPs either, except perhaps optionally. > I think the motivation with Daniel's draft was to provide support for the optional case where the ISP wants to support it, because you get some better results in that case, but clearly the full solution needs to work "well enough" with partial or nonexistent ISP cooperation. That pretty much means that you need a solution that isn't bolted to DHCP, right? Or at least, that DHCP is only providing a default discovery mechanism which my CPE is completely free to ignore. Beyond the discovery, it ought to work identically regardless of whether it's my first hop ISP(s), or 20 hops away in Nairobi, right? Mike From nobody Tue Jul 15 12:43: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 AE4F81A005B for ; Tue, 15 Jul 2014 12:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 vwvqd7-gdznV for ; Tue, 15 Jul 2014 12:43:49 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4207C1A0054 for ; Tue, 15 Jul 2014 12:43:49 -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 6B193238088A; Tue, 15 Jul 2014 15:43:48 -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: <53C58350.3020006@mtcc.com> Date: Tue, 15 Jul 2014 15:43:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9F076247-1C4B-4006-98D7-BA1DAE2E9438@fugue.com> References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> <21162.1405438875@sandelman.ca> <7ioawqpqcv.wl%jch@pps.univ-paris-diderot.fr> <7B5390DD-6969-4E26-A85E-0B436F48448F@fugue.com> <87a98acvxe.wl-jch@pps.univ-paris-diderot.fr> <53C58350.3020006@mt cc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/tOhaJjVST173XqNJ0KSRJqQklhc Cc: homenet@ietf.org Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Tue, 15 Jul 2014 19:43:50 -0000 On Jul 15, 2014, at 3:38 PM, Michael Thomas wrote: > That pretty much means that you need a solution that isn't bolted to = DHCP, right? > Or at least, that DHCP is only providing a default discovery mechanism = which my CPE > is completely free to ignore. Beyond the discovery, it ought to work = identically regardless > of whether it's my first hop ISP(s), or 20 hops away in Nairobi, = right? The point is that what the ISP is offering may be ideal for some users, = and not others. And some ISPs may offer it, while others don't. So = if there's a standard mechanism in place for using it when it's offered, = if desired, then that's a win, even if not everyone wins. What happens with queries isn't important as long as they are satisfied; = there are lots of ways of satisfying queries for AAAA records, but only = two ways of satisfying queries for PTR records, and the ISP may support = one or both of those two ways, or neither. The point of the DNS-PD = document is to provide a way for the ISP and CPE to communicate about = which mechanisms are supported and desired. From nobody Tue Jul 15 12:55: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 E3DDB1A004E for ; Tue, 15 Jul 2014 12:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.651, 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 g6nWYFTMow_f for ; Tue, 15 Jul 2014 12:55:12 -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 161B01A0027 for ; Tue, 15 Jul 2014 12:55:12 -0700 (PDT) Received: from [10.1.10.25] (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 s6FJt809028509 for ; Tue, 15 Jul 2014 12:55:08 -0700 Message-ID: <53C58719.8020209@mtcc.com> Date: Tue, 15 Jul 2014 12:55:05 -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: <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> <21162.1405438875@sandelman.ca> <7ioawqpqcv.wl%jch@pps.univ-paris-diderot.fr> <7B5390DD-6969-4E26-A85E-0B436F48448F@fugue.com> <87a98acvxe.wl-jch@pps.univ-paris-diderot.fr> <53C58350.3020006@mt cc.com> <9F076247-1C4B-4006-98D7-BA1DAE2E9438@fugue.com> In-Reply-To: <9F076247-1C4B-4006-98D7-BA1DAE2E9438@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/5wHYW_GIr4IRUNT1rObaPrA6iEQ Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Tue, 15 Jul 2014 19:55:13 -0000 On 7/15/14, 12:43 PM, Ted Lemon wrote: > On Jul 15, 2014, at 3:38 PM, Michael Thomas wrote: >> That pretty much means that you need a solution that isn't bolted to DHCP, right? >> Or at least, that DHCP is only providing a default discovery mechanism which my CPE >> is completely free to ignore. Beyond the discovery, it ought to work identically regardless >> of whether it's my first hop ISP(s), or 20 hops away in Nairobi, right? > The point is that what the ISP is offering may be ideal for some users, and not others. And some ISPs may offer it, while others don't. So if there's a standard mechanism in place for using it when it's offered, if desired, then that's a win, even if not everyone wins. > > What happens with queries isn't important as long as they are satisfied; there are lots of ways of satisfying queries for AAAA records, but only two ways of satisfying queries for PTR records, and the ISP may support one or both of those two ways, or neither. The point of the DNS-PD document is to provide a way for the ISP and CPE to communicate about which mechanisms are supported and desired. > What I'm trying to say is that DHCP as a way of advertising a service that will host my zone, or in some way make my homenet names globally available is OK, but it should just be about DISCOVERY and nothing else. All of the rest of the mechanisms between my CPE and some service that causes my names to be globally available ought to use standard mechanisms which are not in any way tied to topology. It's OK if discovery for non-ISP's remains an unsolved problem, let's just have one mechanism once I know who I want to speak to. Mike From nobody Tue Jul 15 13:10: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 D21A61A007C for ; Tue, 15 Jul 2014 13:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 1TxcEHjmXdN4 for ; Tue, 15 Jul 2014 13:09:59 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id B635C1A0054 for ; Tue, 15 Jul 2014 13:09:59 -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 D6F70238088A; Tue, 15 Jul 2014 16:09: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: <53C58719.8020209@mtcc.com> Date: Tue, 15 Jul 2014 16:09:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5EEF0BDB-839A-4E97-876B-C5F66153834C@fugue.com> References: <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> <21162.1405438875@sandelman.ca> <7ioawqpqcv.wl%jch@pps.univ-paris-diderot.fr> <7B5390DD-6969-4E26-A85E-0B436F48448F@fugue.com> <87a98acvxe.wl-jch@pps.univ-paris-diderot.fr> <53C58350.3020006@mt cc.com> <9F076247-1C4B-4006-98D7-BA1DAE2E9438@fugue.com> <53C58719.8020209@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Hz51oTp-8DM82Byofe8q7FFtzbw Cc: homenet@ietf.org Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Tue, 15 Jul 2014 20:10:01 -0000 On Jul 15, 2014, at 3:55 PM, Michael Thomas wrote: > What I'm trying to say is that DHCP as a way of advertising a service = that will host my zone, or > in some way make my homenet names globally available is OK, but it = should just be about > DISCOVERY and nothing else. All of the rest of the mechanisms between = my CPE and some service > that causes my names to be globally available ought to use standard = mechanisms which are not > in any way tied to topology. Ah, yes. Agreed, at least in theory. From nobody Tue Jul 15 13: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 8B8B21A00BF for ; Tue, 15 Jul 2014 13:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.651, 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 XaoMVyLlslNB for ; Tue, 15 Jul 2014 13:27:54 -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 E13C21A008C for ; Tue, 15 Jul 2014 13:27:53 -0700 (PDT) Received: from [10.1.10.25] (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 s6FKRrmb005080 for ; Tue, 15 Jul 2014 13:27:53 -0700 Message-ID: <53C58EC7.7020905@mtcc.com> Date: Tue, 15 Jul 2014 13:27:51 -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: <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> <21162.1405438875@sandelman.ca> <7ioawqpqcv.wl%jch@pps.univ-paris-diderot.fr> <7B5390DD-6969-4E26-A85E-0B436F48448F@fugue.com> <87a98acvxe.wl-jch@pps.univ-paris-diderot.fr> <53C58350.3020006@mt cc.com> <9F076247-1C4B-4006-98D7-BA1DAE2E9438@fugue.com> <53C58719.8020209@mtcc.com> <5EEF0BDB-839A-4E97-876B-C5F66153834C@fugue.com> In-Reply-To: <5EEF0BDB-839A-4E97-876B-C5F66153834C@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/pckx3Y9A4SWon84TXkt77mcXjP8 Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Tue, 15 Jul 2014 20:27:54 -0000 On 7/15/14, 1:09 PM, Ted Lemon wrote: > On Jul 15, 2014, at 3:55 PM, Michael Thomas wrote: >> What I'm trying to say is that DHCP as a way of advertising a service that will host my zone, or >> in some way make my homenet names globally available is OK, but it should just be about >> DISCOVERY and nothing else. All of the rest of the mechanisms between my CPE and some service >> that causes my names to be globally available ought to use standard mechanisms which are not >> in any way tied to topology. > Ah, yes. Agreed, at least in theory. > > Good. If that can be done at all, is there a reason that it cannot have those properties? That is if, say, my Google Nest spams my local homenet advertising the Google Eggs-in-one-basket DNS service, it should use the same set of protocols as a local ISP advertising over DHCP to actually hook everything up between my CPE and their service. Can we make this a *requirement*? If not, why not? Mike From nobody Tue Jul 15 13:53: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 3BCBC1A00B5 for ; Tue, 15 Jul 2014 13:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 rSIzmpnsvAbC for ; Tue, 15 Jul 2014 13:53:42 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 73FBB1B2911 for ; Tue, 15 Jul 2014 13:53: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 7307A238088A; Tue, 15 Jul 2014 16:53: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: <53C58EC7.7020905@mtcc.com> Date: Tue, 15 Jul 2014 16:53:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> <21162.1405438875@sandelman.ca> <7ioawqpqcv.wl%jch@pps.univ-paris-diderot.fr> <7B5390DD-6969-4E26-A85E-0B436F48448F@fugue.com> <87a98acvxe.wl-jch@pps.univ-paris-diderot.fr> <53C58350.3020006@mt cc.com> <9F076247-1C4B-4006-98D7-BA1DAE2E9438@fugue.com> <53C58719.8020209@mtcc.com> <5EEF0BDB-839A-4E97-876B-C5F66153834C@fugue.com> <53C58EC7.7020905@mtcc.com > To: Michael Thomas X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/lJmhTRiTJ9dWFxELLY8vszDEweo Cc: homenet@ietf.org Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Tue, 15 Jul 2014 20:53:44 -0000 On Jul 15, 2014, at 4:27 PM, Michael Thomas wrote: > Good. If that can be done at all, is there a reason that it cannot = have those properties? > That is if, say, my Google Nest spams my local homenet advertising the = Google Eggs-in-one-basket > DNS service, it should use the same set of protocols as a local ISP = advertising over DHCP to > actually hook everything up between my CPE and their service. We can safely assume that any device that is monetized through the cloud = will do everything in its power to prevent us from accessing it, so = that's really not the interesting test case. The interesting test case = is whether a Nest-like device that isn't operated through the = manufacturer's captive portal will use this set of standard protocols. = (I don't know what the policies behind Nest are specifically, but the = phenomenon I'm talking about is more the rule than the exception in = citizen-grade IoT devices at the moment). > Can we make this a *requirement*? If not, why not? We can't force anybody to do anything, that's why not. But we can = document a mechanism for doing it, and if implementation becomes = widespread in home gateways, it's not unreasonable to think that devices = that _don't_ depend on a captive portal for monetization will use these = protocols rather than reinventing the wheel. But bear in mind that = this is a fairly big "if." From nobody Tue Jul 15 14:12: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 BD8611B2920 for ; Tue, 15 Jul 2014 14:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.651, 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 81_3wi0AshWG for ; Tue, 15 Jul 2014 14:12:09 -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 0D3741A007C for ; Tue, 15 Jul 2014 14:12:09 -0700 (PDT) Received: from [10.1.10.25] (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 s6FLC8p0017091 for ; Tue, 15 Jul 2014 14:12:08 -0700 Message-ID: <53C59926.9020704@mtcc.com> Date: Tue, 15 Jul 2014 14:12:06 -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: <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> <21162.1405438875@sandelman.ca> <7ioawqpqcv.wl%jch@pps.univ-paris-diderot.fr> <7B5390DD-6969-4E26-A85E-0B436F48448F@fugue.com> <87a98acvxe.wl-jch@pps.univ-paris-diderot.fr> <53C58350.3020006@mt cc.com> <9F076247-1C4B-4006-98D7-BA1DAE2E9438@fugue.com> <53C58719.8020209@mtcc.com> <5EEF0BDB-839A-4E97-876B-C5F66153834C@fugue.com> <53C58EC7.7020905@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/RrDcWFLf4nNbgoBzbhXRcHYI0cQ Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Tue, 15 Jul 2014 21:12:09 -0000 On 7/15/14, 1:53 PM, Ted Lemon wrote: > We can safely assume that any device that is monetized through the cloud will do everything in its power to prevent us from accessing it, so that's really not the interesting test case. The interesting test case is whether a Nest-like device that isn't operated through the manufacturer's captive portal will use this set of standard protocols. (I don't know what the policies behind Nest are specifically, but the phenomenon I'm talking about is more the rule than the exception in citizen-grade IoT devices at the moment). I believe we are at least in the fortunate situation that nobody's tried hard to do a naming provider land grab yet, so there may yet be time to do the right thing. >> Can we make this a *requirement*? If not, why not? > We can't force anybody to do anything, that's why not. But we can document a mechanism for doing it, and if implementation becomes widespread in home gateways, it's not unreasonable to think that devices that _don't_ depend on a captive portal for monetization will use these protocols rather than reinventing the wheel. But bear in mind that this is a fairly big "if." > I mean a requirement for the homenet working group, of course. I'm not entirely sure what the appetite is for wheel reinvention in this space is, but I'm guessing it's not that high if this working group comes up with something that is workable, and gives CPE vendors something to shoot for rather than a bunch of ad hoc point solutions requiring bilateral dev agreements. We should be really clear that "CPE" !== "Router" too. If the Nest wants to be my DNS name repository that gets mirrored out in Google's intrastructure somehow, that should OK too. I think its main requirement is that it: a) doesn't move around out of my homenet b) is always on Mike From nobody Tue Jul 15 14:32: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 7AF301B295D for ; Tue, 15 Jul 2014 14:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 RNR8X87rcsb5 for ; Tue, 15 Jul 2014 14:32:30 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92D101B2950 for ; Tue, 15 Jul 2014 14:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2059; q=dns/txt; s=iport; t=1405459950; x=1406669550; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0kwmYcPZd2AwlW9ustjOuFicueG9THZ3lqFmNQXICCc=; b=HSlKsMzcE1wJAH2/C5Nm/jOxkjBU7m+SXck861+EUvwxlwbaxSYFJUqP CbNSoP8V3Dq26DZFY2azj7UTg8ZNWVWsq4c28qcjElmDvXZU0s3cSvuqj Zw1kH+Plzzr3Yo2DiAfwFJK8PpVvO897LbsUeuokiLSxI6B9QhykpVPkD A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0HAL2cxVOtJA2J/2dsb2JhbABZgw5SVwTBG1EKhnBTAYERFnWEAwEBAQMBAQEBawsFCwIBCBIGLicLFw4CBA4FiDoIDco7EwSPGDMHgy2BFgWbGJQlggKBQmyBRQ X-IronPort-AV: E=Sophos;i="5.01,668,1400025600"; d="scan'208";a="61115285" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 15 Jul 2014 21:32:29 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6FLWT0O010348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jul 2014 21:32:29 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.235]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 15 Jul 2014 16:32:29 -0500 From: "Mark Baugher (mbaugher)" To: Markus Stenberg Thread-Topic: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt Thread-Index: AQHPljWkESJkO5Is/kCoLOF/09bhG5uOeXaAgAAegACAAimYAIAAD/4AgAPFGv+AAr4jgIAAzOEAgAATGgCACOP0gIAAlRqAgAAEbACAABGaAIAAGpGAgAAC3QCAAC6tAA== Date: Tue, 15 Jul 2014 21:32:29 +0000 Message-ID: <404C4648-278B-4369-9F44-692F9DD16FF2@cisco.com> References: <87fvij5wdw.wl.jch@pps.univ-paris-diderot.fr> <87k37uy703.wl.jch@pps.univ-paris-diderot.fr> <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> <21162.1405438875@sandelman.ca> <7ioawqpqcv.wl%jch@pps.univ-paris-diderot.fr> <7B5390DD-6969-4E26-A85E-0B436F48448F@fugue.com> <87a98acvxe.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.83.69] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Sw7Baza90i97oJb4gnwZbae2Rrs Cc: "homenet@ietf.org" , Ted Lemon , Daniel Migault , Juliusz Chroboczek Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Tue, 15 Jul 2014 21:32:32 -0000 On Jul 15, 2014, at 11:45 AM, Markus Stenberg wrot= e: > On 15.7.2014, at 21.35, Juliusz Chroboczek wrote: >>> I assume you mean that we need to recommend a default policy and also >>> document the range of other policies that the end user might choose to >>> use. >>=20 >> No, I just mean that Markus not wanting anything published in DNS is >> policy, and that's completely independent of whether we want to define >> a mechanism. I have no opinion on either point. >>=20 >> All I know is that if we want to define a mechanism, then the mechanism >> should be compatible with the worldview of HNCP, which includes things >> such as multiple internal links and multiple CPEs. >=20 > The mechanism should not be tied to the particular ISPs either, except pe= rhaps optionally. >=20 > In my case, I have 2 upstream ISPs, neither of which officially even admi= ts IPv6 exists, but I _would_ like to publish my home v6 zone somewhere.. *= sigh* >=20 > So to summarize: >=20 > - mechanism to publish either single DNS updates or zones would be nice t= o have (possibly with tie-in to service discovery) >=20 > - with policy bits thrown in=20 >=20 > and some sort of possible zero-conf use, with help of co-operating ISP pe= rhaps, but _not_ requiring the first-hop ISP to be the only party you inter= act with. >=20 > The =91homenet=92 policy stuff may be actually relatively extensive in th= e end, although with some sort of reasonable zeroconf defaults. > In this case, policy stuff should apply to what=92s advertised (and in wh= ich scope), and where it can be reached from (firewalling either with accep= t rules, or PCP-derived holes). >=20 > (Hmm. We don=92t seem to have any drafts on policy or management yet.) There is some dependency on security for these. Mark >=20 > Cheers, >=20 > -Markus > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Tue Jul 15 16:42: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 148981A0173 for ; Tue, 15 Jul 2014 16:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 Za3KUpB4nPi9 for ; Tue, 15 Jul 2014 16:42:17 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5391A016F for ; Tue, 15 Jul 2014 16:42:17 -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 5259023814E0; Tue, 15 Jul 2014 19:42: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: <53C59926.9020704@mtcc.com> Date: Tue, 15 Jul 2014 19:42:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7356EC5E-7947-4BC9-BBAB-8D9B78CE949D@fugue.com> References: <87vbrcydr9.wl.jch@pps.univ-paris-diderot.fr> <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> <21162.1405438875@sandelman.ca> <7ioawqpqcv.wl%jch@pps.univ-paris-diderot.fr> <7B5390DD-6969-4E26-A85E-0B436F48448F@fugue.com> <87a98acvxe.wl-jch@pps.univ-paris-diderot.fr> <53C58350.3020006@mt cc.com> <9F076247-1C4B-4006-98D7-BA1DAE2E9438@fugue.com> <53C58719.8020209@mtcc.com> <5EEF0BDB-839A-4E97-876B-C5F66153834C@fugue.com> <53C58EC7.7020905@mtcc.com > <53C59926.9020704 @mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/CbjBjcHOEWLjn2ONC1N1BO6vsYw Cc: homenet@ietf.org Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Tue, 15 Jul 2014 23:42:22 -0000 On Jul 15, 2014, at 5:12 PM, Michael Thomas wrote: > I believe we are at least in the fortunate situation that nobody's = tried hard to do a naming > provider land grab yet, so there may yet be time to do the right = thing. That's not the point. If you look at most of the consumer-grade IoT = devices that have been announced recently, they all keep the data on = their portal and do not allow you to use the device without sending them = your data, so chances are the device is going to just talk to their = portal using a proprietary scheme and ignore what we want. Which is = fine; my point is not that they are evil, but just that the use case for = this may not be quite as broad as we imagine. I still think it's worth = doing, and I hope that over time this stuff moves in the direction of = more flexibility. What we do in homenet can easily either make that = easy or make it hard, so we should try to make it easy. From nobody Tue Jul 15 17:48: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 C8F7E1B27B5 for ; Tue, 15 Jul 2014 17:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.651, 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 ppiFYEgzy3Ya for ; Tue, 15 Jul 2014 17:48:23 -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 7244E1B27AA for ; Tue, 15 Jul 2014 17:48:16 -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 s6G0kZgt000990; Tue, 15 Jul 2014 17:46:48 -0700 Message-ID: <53C5CB6B.60105@mtcc.com> Date: Tue, 15 Jul 2014 17:46:35 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ted Lemon References: <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> <21162.1405438875@sandelman.ca> <7ioawqpqcv.wl%jch@pps.univ-paris-diderot.fr> <7B5390DD-6969-4E26-A85E-0B436F48448F@fugue.com> <87a98acvxe.wl-jch@pps.univ-paris-diderot.fr> <53C58350.3020006@mt cc.com> <9F076247-1C4B-4006-98D7-BA1DAE2E9438@fugue.com> <53C58719.8020209@mtcc.com> <5EEF0BDB-839A-4E97-876B-C5F66153834C@fugue.com> <53C58EC7.7020905@mtcc.com > <53C59926.9020704 @mtcc.com> <7356EC5E-7947-4BC9-BBAB-8D9B78CE949D@fugue.com> In-Reply-To: <7356EC5E-7947-4BC9-BBAB-8D9B78CE949D@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/dWEFwcpoEefXDdtdvw4FaUqTQgg Cc: homenet@ietf.org Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Wed, 16 Jul 2014 00:48:28 -0000 On 07/15/2014 04:42 PM, Ted Lemon wrote: > On Jul 15, 2014, at 5:12 PM, Michael Thomas wrote: >> I believe we are at least in the fortunate situation that nobody's tried hard to do a naming >> provider land grab yet, so there may yet be time to do the right thing. > That's not the point. If you look at most of the consumer-grade IoT devices that have been announced recently, they all keep the data on their portal and do not allow you to use the device without sending them your data, so chances are the device is going to just talk to their portal using a proprietary scheme and ignore what we want. Which is fine; my point is not that they are evil, but just that the use case for this may not be quite as broad as we imagine. I still think it's worth doing, and I hope that over time this stuff moves in the direction of more flexibility. What we do in homenet can easily either make that easy or make it hard, so we should try to make it easy. Oh, ok. But this entire area is going to be pretty darn tricksey to get right, and we can have some hope that after enough proprietary we-need-to-get-something-done from vendors, they'll be somewhat relieved to have exactly One something that's standardized to support. I've seen this many times at $routervendor, even when they have their own business model in mind. So we shouldn't be too fatalistic... the game is still young on this account. Mike From nobody Tue Jul 15 18:56: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 525A61B29EF for ; Tue, 15 Jul 2014 18:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 9yEDDwCqynpu for ; Tue, 15 Jul 2014 18:56:00 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id E075E1B29E8 for ; Tue, 15 Jul 2014 18:56:00 -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 C89B823814E0; Tue, 15 Jul 2014 21:55:59 -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: <53C5CB6B.60105@mtcc.com> Date: Tue, 15 Jul 2014 21:55:57 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> <21162.1405438875@sandelman.ca> <7ioawqpqcv.wl%jch@pps.univ-paris-diderot.fr> <7B5390DD-6969-4E26-A85E-0B436F48448F@fugue.com> <87a98acvxe.wl-jch@pps.univ-paris-diderot.fr> <53C58350.3020006@mt cc.com> <9F076247-1C4B-4006-98D7-BA1DAE2E9438@fugue.com> <53C58719.8020209@mtcc.com> <5EEF0BDB-839A-4E97-876B-C5F66153834C@fugue.com> <53C58EC7.7020905@mtcc.com > <53C59926.9020704 @mtcc.com> <7356EC5E-7947-4BC9-BBAB-8D9B78CE949D@fugue.com> <53C5CB6B.60105@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/sUW2jKoMdDVMj7U9QxZEQWQLyFY Cc: homenet@ietf.org Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Wed, 16 Jul 2014 01:56:05 -0000 On Jul 15, 2014, at 8:46 PM, Michael Thomas wrote: > So we shouldn't be too fatalistic... the game is still > young on this account. I applaud and encourage your optimism. From nobody Tue Jul 15 19:06: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 7029B1B2A07 for ; Tue, 15 Jul 2014 19:06:49 -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 4Tlhkrmz-7UQ for ; Tue, 15 Jul 2014 19:06:47 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5D51B29EE for ; Tue, 15 Jul 2014 19:06:46 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id lf10so355580pab.30 for ; Tue, 15 Jul 2014 19:06:46 -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 :message-id:references:to; bh=eXbbl9QP2EYtdq+UtA/PMQP+QxcoA7vAsZ4DICzN/pY=; b=nBO2p/B6tU7AgRoy6FjFas9X+Fw/wmvjvnzLz1JCMWGJVOIul3us/Xv1iHyMrqv97h ZAawOlAnLZxC3xZEfglHVPZF2i9sF7rW8YssK4y7bStcHs05YAIpHWlkYUhwwmk7Hf4B oJ2ta4D+A42IzSKJg0kHIKN3oJgJAKGdHZSlPIIRkdqImLUHdLkKke0KeUq0JQYREFSx FDgOoz0vcfd8A0AvIsq+YvwetNM24Nd8ap+77feAOEGg2CCHriCLvKbCdJSWbra87Va4 lLhVHQCqCM4hQL4LclZ02ZHi++65BeCKbJTx9t4J96Xl6FchkFq3aH2iCu6Vu6kFv/BG P2/g== X-Received: by 10.66.159.34 with SMTP id wz2mr18718171pab.96.1405476406332; Tue, 15 Jul 2014 19:06:46 -0700 (PDT) Received: from [192.168.2.234] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id fu12sm64429683pad.42.2014.07.15.19.06.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 19:06:45 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CA9B274A-6B4C-414A-B6E1-E564F9521F37" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: <53C5CB6B.60105@mtcc.com> Date: Tue, 15 Jul 2014 19:06:43 -0700 Message-Id: References: <87d2dfb98w.wl-jch@pps.univ-paris-diderot.fr> <87vbr6mv8t.wl-jch@pps.univ-paris-diderot.fr> <7EEF5CD0-C3B8-4559-A75D-E55931F94F61@iki.fi> <21162.1405438875@sandelman.ca> <7ioawqpqcv.wl%jch@pps.univ-paris-diderot.fr> <7B5390DD-6969-4E26-A85E-0B436F48448F@fugue.com> <87a98acvxe.wl-jch@pps.univ-paris-diderot.fr> <53C58350.3020006@mt cc.com> <9F076247-1C4B-4006-98D7-BA1DAE2E9438@fugue.com> <53C58719.8020209@mtcc.com> <5EEF0BDB-839A-4E97-876B-C5F66153834C@fugue.com> <53C58EC7.7020905@mtcc.com > <53C59926.9020704 @mtcc.com> <7356EC5E-7947-4BC9-BBAB-8D9B78CE949D@fugue.com> <53C5CB6B.60105@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/MJrcsVosQTmQWNk3JmmwaT-LcBo Cc: homenet@ietf.org, Ted Lemon , Douglas Otis Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-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: Wed, 16 Jul 2014 02:06:49 -0000 --Apple-Mail=_CA9B274A-6B4C-414A-B6E1-E564F9521F37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 15, 2014, at 5:46 PM, Michael Thomas wrote: > On 07/15/2014 04:42 PM, Ted Lemon wrote: >> On Jul 15, 2014, at 5:12 PM, Michael Thomas wrote: >>> I believe we are at least in the fortunate situation that nobody's = tried hard to do a naming >>> provider land grab yet, so there may yet be time to do the right = thing. >> That's not the point. If you look at most of the consumer-grade IoT = devices that have been announced recently, they all keep the data on = their portal and do not allow you to use the device without sending them = your data, so chances are the device is going to just talk to their = portal using a proprietary scheme and ignore what we want. Which is = fine; my point is not that they are evil, but just that the use case for = this may not be quite as broad as we imagine. I still think it's worth = doing, and I hope that over time this stuff moves in the direction of = more flexibility. What we do in homenet can easily either make that = easy or make it hard, so we should try to make it easy. >=20 > Oh, ok. But this entire area is going to be pretty darn tricksey to = get right, and we can have some hope > that after enough proprietary we-need-to-get-something-done from = vendors, they'll be somewhat relieved > to have exactly One something that's standardized to support. I've = seen this many times at $routervendor, > even when they have their own business model in mind. So we shouldn't = be too fatalistic... the game is still > young on this account. Dear Mike,=20 http://tools.ietf.org/html/rfc6281 offers a fair amount of detail about = safely leveraging home networks. Further examination of this scheme = shows selective publications of devices in DNS and expects other = services to be indirectly shared by these devices. It makes extensive = use of ULAs that offer a stable basis for publishing addresses in DNS. http://tools.ietf.org/html/rfc6890 and homenet arch also references use = of ULAs. = http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.6.6 3.6.6. ULAs as a hint of connection origin The basic security related premise employed by mDNS can be confirmed by = use of ULAs. It is also conceivable anti-distribution protection = schemes can be satisfied when ULAs have a common prefix. There are also = many home routers already able to combine GUA and ULAs. Add L2TP and it = seems we are done. Regards, Douglas Otis --Apple-Mail=_CA9B274A-6B4C-414A-B6E1-E564F9521F37 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jul 15, 2014, at 5:46 PM, Michael = Thomas <mike@mtcc.com> = wrote:

On 07/15/2014 04:42 PM, Ted Lemon wrote:
On Jul 15, 2014, at 5:12 PM, Michael Thomas <mike@mtcc.com> = wrote:
I believe we are at least in the = fortunate situation that nobody's tried hard to do a naming
provider = land grab yet, so there may yet be time to do the right = thing.
That's not the point.   If you look at = most of the consumer-grade IoT devices that have been announced = recently, they all keep the data on their portal and do not allow you to = use the device without sending them your data, so chances are the device = is going to just talk to their portal using a proprietary scheme and = ignore what we want.   Which is fine; my point is not that = they are evil, but just that the use case for this may not be quite as = broad as we imagine.   I still think it's worth doing, and I = hope that over time this stuff moves in the direction of more = flexibility.   What we do in homenet can easily either make = that easy or make it hard, so we should try to make it = easy.

Oh, ok. But this entire area is going to be = pretty darn tricksey to get right, and we can have some hope
that = after enough proprietary we-need-to-get-something-done from vendors, = they'll be somewhat relieved
to have exactly One something that's = standardized to support. I've seen this many times at = $routervendor,
even when they have their own business model in mind. = So we shouldn't be too fatalistic... the game is still
young on this = account.

Dear = Mike, 

http://tools.ietf.org/html/rfc= 6281 offers a fair amount of detail about safely leveraging = home networks.  Further examination of this scheme shows selective = publications of devices in DNS and expects other services to be = indirectly shared by these devices.  It makes extensive use of ULAs = that offer a stable basis for publishing addresses in DNS.

http://tools.ietf.org/html/rfc= 6890 and homenet arch also references use of ULAs.  http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.6.6=

3.6.6.  ULAs as a hint of connection origin

The = basic security related premise employed by mDNS can be confirmed by use = of ULAs.  It is also conceivable anti-distribution protection = schemes can be satisfied when ULAs have a common prefix.  There are = also many home routers already able to combine GUA and ULAs.  Add = L2TP and it seems we are = done.

Regards,
Douglas = Otis



= --Apple-Mail=_CA9B274A-6B4C-414A-B6E1-E564F9521F37-- From nobody Tue Jul 22 11:42: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 45E381A0B00 for ; Tue, 22 Jul 2014 11:42:01 -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 wOSSf_lJ_ulS for ; Tue, 22 Jul 2014 11:41:59 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26AEB1A0322 for ; Tue, 22 Jul 2014 11:41:59 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k48so63003wev.13 for ; Tue, 22 Jul 2014 11:41: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:subject:references:from:content-type:message-id :date:to:content-transfer-encoding:mime-version; bh=YyU3i8a6dVjnFamfW3DjAKRf8zc+NAiS/PIF3SHH0pc=; b=nCP4uQQ3szKVH6lQj8lrZq7SSwPB/ETk+ujKpwCF+JMRGHkco4qbjkPtJI6R0OQMdy IT+4qHz2fDEqRasSTpKYjB9o2WOd+FLhsJwg4LGJEERqGlFLO9dqKtBaIcQ49OWmdvLN Npxt+rt6zpkidFkleUkKEjRKYuFJtwjJi7xg9aosu7DB8cDfhYV/7Pe6hGiHvaK7AFuQ wgcFXoSwVlR8uvHzEKFe/rPvx6z3C0Wl6FsKBpILsqWeQb8GSlw/AYMmgZ7JP8xzO1jt XUpL39uooxXQidO/Fb9DXLYBXoObZeX8+Uz8/4T2Wfkj425ENi6aeGqWfzx0cyAThoVD iwHA== X-Gm-Message-State: ALoCoQnRMPTeWO/l4CL6FUWdq7b0v6Qz0xoSRi60Do0qePJhtYE5EPGCzcEQYBG19OMg8TYEoCu4 X-Received: by 10.194.191.162 with SMTP id gz2mr37036479wjc.89.1406054515984; Tue, 22 Jul 2014 11:41:55 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:34a9:678f:6a2c:5f6? ([2001:67c:370:160:34a9:678f:6a2c:5f6]) by mx.google.com with ESMTPSA id eo4sm56639077wid.4.2014.07.22.11.41.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 11:41:55 -0700 (PDT) References: From: "Townsley.net" Content-Type: multipart/alternative; boundary=Apple-Mail-C0207B0A-DA4B-4C93-8DE9-30A83FC47B23 X-Mailer: iPhone Mail (11D201) Message-Id: Date: Tue, 22 Jul 2014 14:41:54 -0400 To: "homenet@ietf.org Group" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/y8shAqhKHrzjgnqvcOHPuuDM9PI Subject: [homenet] Fwd: FYI - Comcast IPv6 Deployment 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: Tue, 22 Jul 2014 18:42:01 -0000 --Apple-Mail-C0207B0A-DA4B-4C93-8DE9-30A83FC47B23 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Nice bit of news for the day... Comcast announces it has completed deployme= nt of v6 to 100% of homes, along with v6-only products on the way.=20 - Mark (Thumbtyped) Begin forwarded message: > From: "Brzozowski, John" > Date: July 22, 2014 at 1:42:32 PM EDT > Resent-To: mark@townsley.net, ray.bellis@nominet.org.uk, > To: Chairs > Subject: FYI - Comcast IPv6 Deployment update >=20 > Mark, Ray, >=20 > Thought you would find this interesting. If you feel it is relevant please= feel free to share with the Homenet WG: >=20 > http://corporate.comcast.com/comcast-voices/comcast-reaches-key-milestone-= in-launch-of-ipv6-broadband-network >=20 > Thank you, >=20 > John > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > John Jason Brzozowski > Comcast Cable > m) 609-377-6594 > o) 484-962-0060 > w) www.comcast6.net > e) john_brzozowski@cable.comcast.com > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 --Apple-Mail-C0207B0A-DA4B-4C93-8DE9-30A83FC47B23 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Nice bit of news for the day...  Comcast announces it has completed deployment of v6 to 100% of homes, along with v6-only products on the way. 

- Mark

(Thumbtyped)

Begin forwarded message:

From: "Brzozowski, John" <John_Brzozowski@Cable.Comcast.com>
Date: July 22, 2014 at 1:42:32 PM EDT
Resent-To: mark@townsley.net, ray.bellis@nominet.org.uk,
To: Chairs <homenet-chairs@tools.ietf.org>
Subject: FYI - Comcast IPv6 Deployment update

Mark, Ray,

Thought you would find this interesting. If you feel it is relevant please feel free to share with the Homenet WG:


Thank you,

John
=========================================
John Jason Brzozowski
Comcast Cable
m) 609-377-6594
o) 484-962-0060
=========================================


--Apple-Mail-C0207B0A-DA4B-4C93-8DE9-30A83FC47B23-- From nobody Wed Jul 23 04:54: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 06EAE1A066C for ; Wed, 23 Jul 2014 04:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.048 X-Spam-Level: * X-Spam-Status: No, score=1.048 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-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 ixZRAx8_qDqV for ; Wed, 23 Jul 2014 04:54:09 -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 456081A008C for ; Wed, 23 Jul 2014 04:54:09 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9DDBBA1; Wed, 23 Jul 2014 13:54:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1406116446; bh=P4V7Iir25QnFCxgTYM0xerr+L7XTbSJbXySvm4xJ5+w=; h=Date:From:To:Subject:From; b=cTfeeR189k8y+V1afri6EraV0wKBXmul2/VC6d9PCIqk41HW1nyls5nKRCDF7jWFx 9lLSFK8BeNaR7c75CBI4XCwhxyMk+vNDKT7ONwenYEBsplW8Vix4gA4Vg+7wo3HH6B SvS9sSIUQuXm/XJXkqdRJg8nxO92AE0Ll5wwSH5s= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 96D419F for ; Wed, 23 Jul 2014 13:54:06 +0200 (CEST) Date: Wed, 23 Jul 2014 13:54:06 +0200 (CEST) From: Mikael Abrahamsson To: homenet@ietf.org Message-ID: 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/ASaB3YXxPKV1yLWtcY7qXLh-cf4 Subject: [homenet] Bits'n'bites demonstration of ISIS for homenet X-BeenThere: homenet@ietf.org 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, 23 Jul 2014 11:54:11 -0000 Hi, just want to inform everybody that there will be a demonstration of ISIS running as the homenet routing protocol under the HNCP umbrella, basically replacing Babel in the same framework that was demonstrated at previous IETF. More details will follow but the code is intended to be released as open source in the coming month. Implementation is done by Netdef (http://www.opensourcerouting.org/) -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Jul 23 07:11: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 27F401B27CF for ; Wed, 23 Jul 2014 07:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 1btSIcHTGvpA for ; Wed, 23 Jul 2014 07:11:42 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1: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 2F2AA1B27E5 for ; Wed, 23 Jul 2014 07:11:42 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s6NEBeL4016802 for ; Wed, 23 Jul 2014 16:11:40 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 2FB202C5A9C for ; Wed, 23 Jul 2014 16:11:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 4ZwShL2LNIQj for ; Wed, 23 Jul 2014 16:11:38 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id BF9B62C5A9A for ; Wed, 23 Jul 2014 16:11:38 +0200 (CEST) Received: from jch (uid 1000) (envelope-from jch@pps.univ-paris-diderot.fr) id c002c9 by ijon.pps.univ-paris-diderot.fr (DragonFly Mail Agent v0.9); Wed, 23 Jul 2014 16:11:35 +0200 Date: Wed, 23 Jul 2014 16:11:35 +0200 Message-ID: <87zjg0cgh4.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Mikael Abrahamsson In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 23 Jul 2014 16:11:40 +0200 (CEST) X-Miltered: at korolev with ID 53CFC29C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53CFC29C.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 53CFC29C.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/YuG1XxfrWUW7PfBR2ytj-x4fuPk Cc: homenet@ietf.org, babel-users@lists.alioth.debian.org Subject: Re: [homenet] Bits'n'bites demonstration of ISIS for homenet X-BeenThere: homenet@ietf.org 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, 23 Jul 2014 14:11:49 -0000 [Added babel-users to the CC. Please choose followups wisely.] > there will be a demonstration of ISIS running as the homenet routing > protocol under the HNCP umbrella, basically replacing Babel in the same > framework that was demonstrated at previous IETF. That's excellent news. Have you written down your protocol extensions? Did you have any unexpected trouble with source-sensitive routing in link state? -- Juliusz From nobody Wed Jul 23 07:23: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 0C34A1B2834 for ; Wed, 23 Jul 2014 07:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 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.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 a8zAB9Uya0Af for ; Wed, 23 Jul 2014 07:23:19 -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 DF1A81B2812 for ; Wed, 23 Jul 2014 07:23:08 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 57DBEA1; Wed, 23 Jul 2014 16:23:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1406125387; bh=zL7hWatV4Wyk0CgVAkuWtj8xqkdKLcHBvkGNaBzD7Js=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=oPXPJ647sVk251Izfgkee4fNhfJaQl3TJY0AjMn/DrtlxMnNQuSrYqAe407rl8dVZ 1iVsRUnsEZCMU6l8lJePK0FrDvnx1m3k22SEgXc8vPRLb3Pvd/cdqSqGKQEhf+ytQP zdXk2G2VOMz/ohKXankhhu1XhBc49sI60qKuuGOM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4F80F9F; Wed, 23 Jul 2014 16:23:07 +0200 (CEST) Date: Wed, 23 Jul 2014 16:23:07 +0200 (CEST) From: Mikael Abrahamsson To: Juliusz Chroboczek In-Reply-To: <87zjg0cgh4.wl-jch@pps.univ-paris-diderot.fr> Message-ID: References: <87zjg0cgh4.wl-jch@pps.univ-paris-diderot.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/-AvIMIP-C3GL1nCiasbrz5THDkk Cc: homenet@ietf.org, babel-users@lists.alioth.debian.org Subject: Re: [homenet] Bits'n'bites demonstration of ISIS for homenet X-BeenThere: homenet@ietf.org 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, 23 Jul 2014 14:23:21 -0000 On Wed, 23 Jul 2014, Juliusz Chroboczek wrote: > [Added babel-users to the CC. Please choose followups wisely.] > >> there will be a demonstration of ISIS running as the homenet routing >> protocol under the HNCP umbrella, basically replacing Babel in the same >> framework that was demonstrated at previous IETF. > > That's excellent news. Have you written down your protocol extensions? > Did you have any unexpected trouble with source-sensitive routing in link > state? I wasn't directly involved in coding this, so I don't know. However, there is a goal to document experiences with the implementation, and to standardize the extensions needed. This work has been initiated during the IETF and I hope there will be things published in the next few months. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Jul 23 08:07: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 5B00F1B2891 for ; Wed, 23 Jul 2014 08:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 bpobNBBKSF_A for ; Wed, 23 Jul 2014 08:07:52 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E97021B290D for ; Wed, 23 Jul 2014 08:07:47 -0700 (PDT) Received: from ([24.40.56.122]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.107304482; Wed, 23 Jul 2014 11:07:44 -0400 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.11]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.03.0181.006; Wed, 23 Jul 2014 11:07:44 -0400 From: "Brzozowski, John" To: Mikael Abrahamsson , "homenet@ietf.org" Thread-Topic: [homenet] Bits'n'bites demonstration of ISIS for homenet Thread-Index: AQHPpmzh1qHcnUJZ+UGww+qjuqr6W5utwtiA Date: Wed, 23 Jul 2014 15:07:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [68.87.16.249] 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/6_fCkxNakarqKefChG35R3MQUqI Subject: Re: [homenet] Bits'n'bites demonstration of ISIS for homenet X-BeenThere: homenet@ietf.org 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, 23 Jul 2014 15:07:55 -0000 Rm9sa3MsDQoNCkkgc3Bva2Ugd2l0aCBBbGlzdGFpciBhbmQgZW1haWxlZCB3aXRoIE1pa2FlbCBz ZXBhcmF0ZWx5LCB0aG91Z2h0IGV2ZXJ5b25lDQp3b3VsZCBiZSBpbnRlcmVzdGVkIHRvIGtub3cg dGhhdCB3ZSAoQ29tY2FzdCBCbkIgdGFibGUpIG1hZGUgYW4gSVB2Ng0KZW5hYmxlZCBjYWJsZSBi cm9hZGJhbmQgY29ubmVjdGlvbiBhdmFpbGFibGUgdG8gTmV0REVGIGZvciB0aGVpcg0KZGVtb25z dHJhdGlvbi4gIFNpbWlsYXIgdG8gd2hhdCB3ZSBhcmUgZG9pbmcgd2l0aCB0aGUgSE5FVCBpbXBs ZW1lbnRhdGlvbiwNCk5ldERFRiBoYXMgYSBuYXRpdmUgSVB2NiBjYXBhYmxlIGJyb2FkYmFuZCBj b25uZWN0aW9uIGZvciBhdCBsZWFzdCBvbmUgb2YNCnRoZWlyIEludGVybmV0IGZhY2luZyBjb25u ZWN0aW9ucy4NCg0KRllJIC0gdGhpcyBjb25uZWN0aW9uIGlzIHJlcHJlc2VudGF0aXZlIG9mIGhv dyB0aGUgbWlsbGlvbnMgb2YgQ29tY2FzdOKAmXMNCmN1c3RvbWVycyBjb25uZWN0IHRvIHRoZSBJ bnRlcm5ldCB0b2RheSB1c2luZyBJUHY2Lg0KDQpKb2huDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KSm9obiBKYXNvbiBCcnpvem93c2tpDQpDb21jYXN0IENhYmxl DQptKSA2MDktMzc3LTY1OTQNCm8pIDQ4NC05NjItMDA2MA0Kdykgd3d3LmNvbWNhc3Q2Lm5ldA0K ZSkgam9obl9icnpvem93c2tpQGNhYmxlLmNvbWNhc3QuY29tDQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IE1pa2FlbCBBYnJhaGFtc3NvbiA8c3dtaWtlQHN3bS5wcC5zZT4NCk9yZ2Fu aXphdGlvbjogUGVvcGxlJ3MgRnJvbnQgQWdhaW5zdCBXV1cNCkRhdGU6IFdlZG5lc2RheSwgSnVs eSAyMywgMjAxNCBhdCA3OjU0DQpUbzogSE9NRU5FVCA8aG9tZW5ldEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFtob21lbmV0XSBCaXRzJ24nYml0ZXMgZGVtb25zdHJhdGlvbiBvZiBJU0lTIGZvciBob21l bmV0DQoNCj4NCj5IaSwNCj4NCj5qdXN0IHdhbnQgdG8gaW5mb3JtIGV2ZXJ5Ym9keSB0aGF0IHRo ZXJlIHdpbGwgYmUgYSBkZW1vbnN0cmF0aW9uIG9mIElTSVMNCj5ydW5uaW5nIGFzIHRoZSBob21l bmV0IHJvdXRpbmcgcHJvdG9jb2wgdW5kZXIgdGhlIEhOQ1AgdW1icmVsbGEsDQo+YmFzaWNhbGx5 IA0KPnJlcGxhY2luZyBCYWJlbCBpbiB0aGUgc2FtZSBmcmFtZXdvcmsgdGhhdCB3YXMgZGVtb25z dHJhdGVkIGF0IHByZXZpb3VzDQo+SUVURi4NCj4NCj5Nb3JlIGRldGFpbHMgd2lsbCBmb2xsb3cg YnV0IHRoZSBjb2RlIGlzIGludGVuZGVkIHRvIGJlIHJlbGVhc2VkIGFzIG9wZW4NCj5zb3VyY2Ug aW4gdGhlIGNvbWluZyBtb250aC4NCj4NCj5JbXBsZW1lbnRhdGlvbiBpcyBkb25lIGJ5IE5ldGRl ZiAoaHR0cDovL3d3dy5vcGVuc291cmNlcm91dGluZy5vcmcvKQ0KPg0KPi0tIA0KPk1pa2FlbCBB YnJhaGFtc3NvbiAgICBlbWFpbDogc3dtaWtlQHN3bS5wcC5zZQ0KPg0KPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+aG9tZW5ldCBtYWlsaW5nIGxpc3QN Cj5ob21lbmV0QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ob21lbmV0DQoNCg== From nobody Wed Jul 23 10:43: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 D6DC71A02D4 for ; Wed, 23 Jul 2014 10:43: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] 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 EAu5_vg4BLC9 for ; Wed, 23 Jul 2014 10:43:43 -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 1B7901B2B17 for ; Wed, 23 Jul 2014 10:43:43 -0700 (PDT) Received: from [2001:8d8:870:10ef:1::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1XA0Zl-0002Ju-FQ; Wed, 23 Jul 2014 19:43:37 +0200 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.82) (envelope-from ) id 1XA0ZT-003S4M-Ng; Wed, 23 Jul 2014 19:43:26 +0200 Date: Wed, 23 Jul 2014 19:43:19 +0200 From: David Lamparter To: Juliusz Chroboczek Message-ID: <20140723174319.GN801478@jupiter.n2.diac24.net> References: <87zjg0cgh4.wl-jch@pps.univ-paris-diderot.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/OzTtHifJg145n4dng7aiCQtJ2RE Cc: homenet@ietf.org, babel-users@lists.alioth.debian.org, Mikael Abrahamsson Subject: Re: [homenet] Bits'n'bites demonstration of ISIS for homenet X-BeenThere: homenet@ietf.org 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, 23 Jul 2014 17:43:47 -0000 On Wed, Jul 23, 2014 at 04:23:07PM +0200, Mikael Abrahamsson wrote: > On Wed, 23 Jul 2014, Juliusz Chroboczek wrote: > >> there will be a demonstration of ISIS running as the homenet routing > >> protocol under the HNCP umbrella, basically replacing Babel in the same > >> framework that was demonstrated at previous IETF. > > > > That's excellent news. Have you written down your protocol extensions? > > Did you have any unexpected trouble with source-sensitive routing in link > > state? > > I wasn't directly involved in coding this, so I don't know. However, there > is a goal to document experiences with the implementation, and to > standardize the extensions needed. This work has been initiated during the > IETF and I hope there will be things published in the next few months. Regarding protocol extensions, this is an implementation of http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing-01 If someone else creates another implementation of that, it should -basically- be compatible. We did not have unexpected trouble in IS-IS's link state/database management. There are known and expected issues regarding interop between srcdest and non-srcdest IS-IS implementations, i.e. a source restricted route should never point to a non-srcdest router. This will be addressed in a future revision of the draft. (Examining interop wasn't part/goal of our work so far, but having the implementation certainly creates the opportunity to do just that.) -David From nobody Thu Jul 24 09:25: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 65F1C1A029D for ; Thu, 24 Jul 2014 09:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 eGxOlis_JEDD for ; Thu, 24 Jul 2014 09:25:37 -0700 (PDT) Received: from mx1.nominet.org.uk (mail.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6534D1A03D4 for ; Thu, 24 Jul 2014 09:25:35 -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=eCrVuUDHktAkvqGjDINrhPwo6gASwwtJGjBbz7kwzA4IBakSv2S7CmZG o5jhB1UCrIiDK6EV5U89ez7y/dbgAOaCR4P++AHYwOOpnayZkbUOCsjZm U2k5Qmn24NPmnk/uhvFMonnG88NCRjFPl5NNwTX00VaHce90pmYfKPrxx Z8dLzigGjpWZ14CSeQHJ0vWsFJGhJPYGw/u9+bVR5+1Wj4PDjLPW1IuBN XLpD4uq+2WSWOv0JUBhhhcAXPcRBA; 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=1406219136; x=1437755136; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Las4D5XvQwx1pGvhC1+XHX+TdgOja9F9O0smQvzWZC8=; b=biSYiOARzFB5Iz2Ri4zUHvD3PNz8hk8qyPSgMjWSm41TW5hvV+zDVkcb e3n7Xr4SarswYbtg14j6U+UFzYb6lW+SaOLOVCYpekiY+hhPTHMc4EkHa m9lJXrzloRkeCj9UhjhaBe9IytdWV0YCrT5zd/bmu5AiUrgamaeYI/295 tHDVcD0mCWmL+VGNyEvpeGop3TpVA2dQD1chs7yosz8pSeBKS9iQ309KU 7ZKwY0CaaivdsSF3VO8+6rCu2n+7C; X-IronPort-AV: E=Sophos;i="5.01,725,1400022000"; d="scan'208";a="11662847" X-IPAS-Result: Aq8HAPAy0VPV+MWR/2dsb2JhbABYgmokgRMajSKmIAGVYohiFneEClM4AYEAJwSIVgOZGaZ3F5MAgRgFr3WDSIIx Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 24 Jul 2014 17:25:34 +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; Thu, 24 Jul 2014 17:25:34 +0100 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: Slides, please! Thread-Index: AQHPp1vkpIyTLqwwDUebHhv7Ptuf9A== Date: Thu, 24 Jul 2014 16:25:33 +0000 Message-ID: <0EB3AF00-C2F5-41A1-BE79-B8855DB0991E@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="Windows-1252" Content-ID: <22071D2F3EA8214495D673D6FBD2865A@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Rmd6_5y_Lzl1lN1rwj2CJ9AAOEE Subject: [homenet] Slides, please! X-BeenThere: homenet@ietf.org 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, 24 Jul 2014 16:25:42 -0000 If you are due to be presenting tomorrow morning please get your slides to = the chairs as soon as possible. Please don=92t forget to include slide numbers for the benefit of remote pa= rticipants! thanks, Ray From nobody Thu Jul 24 10:01: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 263E91A0648 for ; Thu, 24 Jul 2014 10:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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.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 B0CfANp89TRT for ; Thu, 24 Jul 2014 10:01:45 -0700 (PDT) Received: from mx1.nominet.org.uk (mx1.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id EECBE1A063F for ; Thu, 24 Jul 2014 10:01:32 -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: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=jWVXCBR49Z57NRl24Fzgpr1Hu4vT1SI8w3ftXWZAF2/rShU84CmKIdeq lTQvbq+be38puv9011VFhSGI0hRJ/pxsnPmb0zGLsWu7Zws8bTOVx7VU3 xu5YryJ2h0utEWu8IdMg1/jrDdA236V7/WDLxdAV6klKwvs4DdelUI0JU 5PYc1+X6CI1BkWRrwYjV5pF4eGXCZN2q40m4wlAQiHXC+XoSdjbCbtwg5 hmiACzWb8od8RHM/iiXHm1xCN3+wp; 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=1406221293; x=1437757293; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=lDUpGPwj86OuOpVCGh0vBO7VzA0VRwnYCGSHJpmCh18=; b=zwqcYpGwt+q9UOzx3+L0vPd8dutzkA+1uB9EPCMGTUBWpg3UfBihMIvJ DPuLE1ZM0Lpv0RzC8p5R9WnCPJta9lwtIApNP4N5g+kyjSI5R18ejoY0T 4x7Z1fAb05T7YEmfevIOgMtTLG/fCMJfPeUfjJNJr3lxjURZKw/nZMENT tr6f8sLkaGc3eOMqIJtcSjVtSlT18r5qjdzfZeFBQ5/+wze21cG1FSkIr WH90ZZsShHAJZOinLOjn6zgkLZkio; X-IronPort-AV: E=Sophos;i="5.01,725,1400022000"; d="scan'208";a="11663349" X-IPAS-Result: AgEFACU70VPV+MWR/2dsb2JhbABYgmokgS3SCRZ3hAQBAQMBOg0MKwsCAT4QMiUCBIhNCQOtcZIUF5MAgRgFr3uDSIIx Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 24 Jul 2014 18:01:31 +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; Thu, 24 Jul 2014 18:01:31 +0100 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: Request from tomorrow's minute taker Thread-Index: AQHPp18tW2lJpJqXfkiUPolv8ysv0w== Date: Thu, 24 Jul 2014 17:01:29 +0000 Message-ID: References: <4D953539-E7BC-44BC-A67D-6D566036A943@thomasclausen.org> 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/F44chWrE8A6R-dgBPXPO9PQrtRo Subject: [homenet] Request from tomorrow's minute taker X-BeenThere: homenet@ietf.org 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, 24 Jul 2014 17:01:48 -0000 Begin forwarded message: > Dear Chairs, >=20 > Would you be so good as to remind the participants tomorrow to, whenever = they go to the mike: >=20 > o State their names at the mike, slowly > o Enunciate when they do so >=20 > Failure to do either or both will cause the minutes recorded for the spea= ker in question to read that they're suggesting something utterly outrageou= s (and, if I recognize the speaker even though no name is stated, it'll be = attributed to him/her). >=20 > Thanks, >=20 > Thomas Please consider this your first reminder! ;) thanks, Ray From nobody Thu Jul 24 10:19: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 0F0161A0ADF; Thu, 24 Jul 2014 10:19:29 -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 ZGUZmWvu7ilE; Thu, 24 Jul 2014 10:19:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 871CA1A0AEB; Thu, 24 Jul 2014 10:19:00 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140724171900.23364.35659.idtracker@ietfa.amsl.com> Date: Thu, 24 Jul 2014 10:19:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/c4Hlp5v3FWlbWwnmLcKDFgclXHw Cc: homenet mailing list , homenet chair , RFC Editor Subject: [homenet] Document Action: 'IPv6 Home Networking Architecture Principles' to Informational RFC (draft-ietf-homenet-arch-17.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: Thu, 24 Jul 2014 17:19:29 -0000 The IESG has approved the following document: - 'IPv6 Home Networking Architecture Principles' (draft-ietf-homenet-arch-17.txt) as Informational RFC This document is the product of the Home Networking Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-homenet-arch/ Technical Summary 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. Working Group Summary The general architectural principles appear to be well supported and understood. Whilst there have been some controversial discussions within the WG, those have tended to be around potential future implementation decisions rather than with the architecture as a whole. Document Quality There have been two formal WG last calls, with a substantial number of reviewers. Personnel Ray Bellis is shepherd; Ted Lemon is responsible AD. From nobody Thu Jul 24 20:50: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 7A3D51A0AA6 for ; Thu, 24 Jul 2014 20:50:04 -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 cSNpBTqayPVq for ; Thu, 24 Jul 2014 20:50:02 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C821A0A92 for ; Thu, 24 Jul 2014 20:50:02 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id x19so3054483ier.6 for ; Thu, 24 Jul 2014 20:50: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:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=K+wVjX1niwatunpgIyWcL9mZL5f79dOpEOTZjF6YrYE=; b=gzWcBbphU25RQl6CYj4D5CcaCl0zyrfXRXs6WhBlWNcQkQHi0na0zNVmqutWrrEKXi tgJBCXKZ7zqIiX7ftN68/jpeNwqk7aH282qN9ZK8n5SNqXn8ZgIIrNrt6JnPjbVqaHTO AykcMCMrZyzjPJMOBduaFXEat/E9dLH54mPE1j/yL8D1GBOF25Y1pueioNZmSh7WoSA6 2Ntj1Lc95GsAhMiTWbM+HsqEhHvGtKxnRaOf8yFOJeohvdfgAgxlLKd+56qaS51yRwZs c/0jy7ivTmgrAC4U7FZ4a4zH5RDBpqupPqkjVuDL7RIqYGmuByThlvT1HysxmS7UnYbe 50IA== X-Gm-Message-State: ALoCoQkKbHyVsHQaxVsfFgVdoTCaJZQo3J3ab9M4JRWDYEuiUSiEZdEkV9jO1pUHm1d66VsDoKol X-Received: by 10.50.41.6 with SMTP id b6mr1746896igl.40.1406260201711; Thu, 24 Jul 2014 20:50:01 -0700 (PDT) Received: from [10.243.58.246] ([209.226.25.101]) by mx.google.com with ESMTPSA id z8sm443320igl.20.2014.07.24.20.49.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 20:50:00 -0700 (PDT) From: Mark Townsley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <937C30B7-2E3B-4905-B12C-1F0A27478400@townsley.net> Date: Thu, 24 Jul 2014 23:49:57 -0400 To: "homenet@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Nl2cPHaQACP2fRmiQfZfGEuQ0lg Subject: [homenet] Ending at 11:15 am tomorow X-BeenThere: homenet@ietf.org 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, 25 Jul 2014 03:50:04 -0000 IETF 90 Homenet WG attendees,=20 I've asked Ray and Ted if we can end at 11:15 am tomorrow, or at least = if chair duties can be wrapped up by then, and they agreed. The reason = being is simply that i need to catch a flight to the US without much = time to spare just after, and I believe that extra 15 minutes could help = quite a bit. I'm hoping that given it is at the end of a long week, = everyone is OK with this and perhaps will even appreciate having a = little extra time back. See you in the morning, - Mark= From nobody Fri Jul 25 07:05: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 ED4641B2949 for ; Fri, 25 Jul 2014 07:05: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 YRwSbPDZah7K for ; Fri, 25 Jul 2014 07:05:06 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003: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 521AD1B295B for ; Fri, 25 Jul 2014 07:04:09 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id g18so5586984oah.20 for ; Fri, 25 Jul 2014 07:04:08 -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 :content-transfer-encoding; bh=jmfgsp/asjuS4tVIpfrxJsyiqEf9y+Mz1zqoWOWQFi8=; b=mB17BzWbJXX6dCLlonUDikDEG4wtAl4w7xg2Aj3kqHzF+ERPhiKBpRDKbx2O0A6/Zp fCSLbruQTYOSognGcotTRQxz9yELiEpgvfxegnzB2pAi2CStlG/r64U/V4ZwtNlzsH5O aTkOyergX+2ubYF68VvHhVNpdkVPI7L+Zh+kfAr50rj8E3N/Zqvu28BsgMfj6ZmrMwbU u5OQiMuVPCt0FvtUzJeq4yK6ajhPuVkuTkzLHrs1cY2PKhiT1hi9q41VLLMHHgcrHAaX xGgDH2NGpMkR/6ZyoK8tSZgu3vXKftHSqmnpfNtJnxYkoh35bi8pbyBsHu/MdQtIMvvD 39ug== MIME-Version: 1.0 X-Received: by 10.182.246.39 with SMTP id xt7mr23070245obc.63.1406297048705; Fri, 25 Jul 2014 07:04:08 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Fri, 25 Jul 2014 07:04:08 -0700 (PDT) Date: Fri, 25 Jul 2014 07:04:08 -0700 Message-ID: From: Dave Taht To: HOMENET Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/Je3rHSMdYiTlENurO_tedSrOK4M Subject: [homenet] my mic comment on routing protocol interop... X-BeenThere: homenet@ietf.org 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, 25 Jul 2014 14:05:08 -0000 What I'd meant at the microphone concerning "interoperability", was not at the protocol level, but at the daemon level. We have separate forks of quagga (for ISIS with source sensitive routing), bird (for ospfv3), stand alone daemons like babels (which also has a quagga-babel version, but I think it's from another quagga branch than the ISIS work) and entirely separate daemons for the various other IoT devices. So far as I know the quagga-babel"s" work hasn't started yet. Is there work on source sensitive ospf for quagga? How big is all this stuff? (memory/flash?) It IS a headache to deal with all these different daemons and stuff flying in loose formation, and so I hope more folk pitch in to stabilize the code (pick a codebase, any codebase... ) to get it beyond "proof of concept" stage. ... and it would be nice to be able to evaluate each routing protocol's configurability (and/or lack thereof, which I'd weight in favor of) convergence time, reliability, wire usage, wireless usage, and the source specific features... Anyone for OLSRv2? /me ducks --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Fri Jul 25 08:41: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 88A8B1A0316 for ; Fri, 25 Jul 2014 08:41:36 -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 yOBIi7Aq_wzQ for ; Fri, 25 Jul 2014 08:41:35 -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 2E0671A0277 for ; Fri, 25 Jul 2014 08:41:35 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id f8so1223971wiw.12 for ; Fri, 25 Jul 2014 08:41:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=p0thi/9CTzbOL64i1D2w/E5bqXtmr3nBXISieg4K+gQ=; b=ByLta3X1sHUqe7Q7/3Zc01yc0b4oTAdshKkK5Zx9Iqb+7tbO+yxKMKLaB8TOXAYADu 2z1YZ7BbP6HYYSWv9UmYGn4YwsM9qAN7vMvRXPA42FPs2loE8IcmuxLE0S78I7lMty4K /qVA81cQYn+R7M4ByEvW+MmcxpCtaTnFA2Srb4lY36OvzTh811jae2ldilJy52JKT585 aFcrZsWV9Aue5ZvHp8MujBug45IPTLcI8gPcGd08DWlF7x4l3NNg8K5uqdjJNykZf3gc 96hzR0HzWAGEKbFoV3lEx5C9ZLJ5H+zTJNnD42UfxW5Iv5zV8rGXisTOG28Ty6Th9ini EHUw== X-Gm-Message-State: ALoCoQkkEwyuG5ByO+gqe8Yey+dT72kvLsb52NVsNfRn1zOqTPwSHEtcXqC7OvFzVD3FubrdTDFn X-Received: by 10.180.186.3 with SMTP id fg3mr6215646wic.78.1406302893779; Fri, 25 Jul 2014 08:41:33 -0700 (PDT) Received: from [100.70.185.167] (71.16.90.92.rev.sfr.net. [92.90.16.71]) by mx.google.com with ESMTPSA id pj6sm26207386wjb.21.2014.07.25.08.41.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 08:41:32 -0700 (PDT) From: "Townsley.net" Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (11D201) Message-Id: <1F125CF7-5337-4D4C-98E6-660AFBF8DA03@townsley.net> Date: Fri, 25 Jul 2014 11:41:29 -0400 To: "homenet@ietf.org Group" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/qN214U6fBNEd-fBLCiiTuu6Ejjw Subject: [homenet] Thanks and see you in Hawaii!! X-BeenThere: homenet@ietf.org 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, 25 Jul 2014 15:41:36 -0000 WG, Sorry for the abrupt exit.=20 Thank you for all the hard work before and comments during the meeting today= . Normally I really get a lot out of small discussions right after the meeti= ng, something that due to scheduling I had to miss this time. If you have a c= omment you wanted to make, positive or negative, and didn't catch Ray or I p= lease don't hesitate to email now while it is fresh in your mind. I'll be ch= ecking email as much as I can until I get in the plane :) After, I will be on vacation for a few weeks, so apologies if I don't follow= list discussion closely or if I am slow to followup on any private emails. I= will be checking in from time to time though.=20 Aloha, - Mark (Thumbtyped)= From nobody Fri Jul 25 08:49: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 303711B2931 for ; Fri, 25 Jul 2014 08:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 EFk6Ann133ug for ; Fri, 25 Jul 2014 08:49:25 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1: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 654A11B292F for ; Fri, 25 Jul 2014 08:49:25 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s6PFnNxm006566 for ; Fri, 25 Jul 2014 17:49:23 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 55EE82C60B9 for ; Fri, 25 Jul 2014 17:49:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id JZq4y2GrfZsM for ; Fri, 25 Jul 2014 17:49:17 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id EDD782C60C1 for ; Fri, 25 Jul 2014 17:49:15 +0200 (CEST) Received: from jch (uid 1000) (envelope-from jch@pps.univ-paris-diderot.fr) id c002f4 by ijon.pps.univ-paris-diderot.fr (DragonFly Mail Agent v0.9); Fri, 25 Jul 2014 17:49:21 +0200 Date: Fri, 25 Jul 2014 17:49:21 +0200 Message-ID: <87lhrhxwu6.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Dave Taht In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 25 Jul 2014 17:49:23 +0200 (CEST) X-Miltered: at korolev with ID 53D27C83.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53D27C83.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 53D27C83.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/j8wxSasr_2CGO7hvExPe7eNLu3w Cc: HOMENET Subject: Re: [homenet] my mic comment on routing protocol interop... X-BeenThere: homenet@ietf.org 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, 25 Jul 2014 15:49:27 -0000 > was not at the protocol level, but at the daemon level. We have > separate forks of quagga (for ISIS with source sensitive routing), > bird (for ospfv3), stand alone daemons like babels (which also has a > quagga-babel version, but I think it's from another quagga branch than > the ISIS work) Dave, According to David Lamparter, Quagga-babels work is using the same Zebra interfaces as IS-IS, so the two should be able to merge at some point. The outstanding issue is merging the releavant bits of Quagga-RE into Quagga, which is something that should happen soon, for some value of soon (at least Matthieu and David are discussing it). > So far as I know the quagga-babel"s" work hasn't started yet. Actually, it's running as we speak. It's not feature complete yet (there's no support for redistribution of source-sensitive routes), and I haven't reviewed the code yet (I'm busy reviewing Matthieu's code and merging babels into standalone babeld, check the branch called "ss-tables-merge"). We'll hopefully end up with just two implementations before the end of the summer: - Quagga (Babel, IS-IS, perhaps RIPng at some future point); - babeld (Babel). > It IS a headache to deal with all these different daemons and stuff > flying in loose formation, I know. Trouble is, my job is doing research, so any maintenance work I do happens during my copious free time, which causes my family to complain. Could you please speak to my nephews? (Getting GSOC funding and finding a competent student this summer was a big help, babels-Quagga wouldn't have happened otherwise.) -- Juliusz From nobody Fri Jul 25 09:11: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 B3C581B29B9 for ; Fri, 25 Jul 2014 09:11:05 -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 TdRs01I_tA_t for ; Fri, 25 Jul 2014 09:11:04 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E14F51A02D9 for ; Fri, 25 Jul 2014 09:11:03 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so4415497wgh.34 for ; Fri, 25 Jul 2014 09:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=9hKZA7/fIZq65cdTr0Nb5mSDa97AjWcRrNI4/cexak8=; b=gP9abJ2eu5ob2Mxsx5Z+b5YxLJJHtW9nWQ5E3CBe0FZ3OUUzES+gpqbfFlkzkKAv8L 1eMmHxcxj5YQMf0DiCZgdUHYLAI0dvKu2vP80gSPPw03bTtjAvpCfHq3WLs5x1Qi3FmW w1iNHi8fhZ8IagXJ3mL/fhzZ/hmHITLeBTJaYgfZFOtFB6xQ+1ytz/UrQ+94/SIFen+q bnRox6c06kPiQCxQ+WxX86Shv3nQ4uz59JZmYIDYIe1plKZM53IjYE5v51iRUAkFxR59 BuinxG9NIcr6oxm7tOxQBLu2PAJVk5gg9GM+jP/yrM7n18x8PSl1KiZqjMD/7TJwmxc3 50xg== X-Received: by 10.194.91.200 with SMTP id cg8mr23658454wjb.50.1406304660870; Fri, 25 Jul 2014 09:11:00 -0700 (PDT) Received: from dhcp-977b.meeting.ietf.org (dhcp-977b.meeting.ietf.org. [31.133.151.123]) by mx.google.com with ESMTPSA id a13sm26410721wjs.12.2014.07.25.09.10.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 09:11:00 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 25 Jul 2014 12:10:55 -0400 Message-Id: <72E20441-9EE0-4A61-B127-BA96468B6E5F@gmail.com> To: homenet@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/tAl27lrkGOCOy-OcIyHFDHzIUmQ Subject: [homenet] Clarification on Routing Thoughts X-BeenThere: homenet@ietf.org 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, 25 Jul 2014 16:11:05 -0000 I apologise that I did not organise my thoughts well earlier, so I will try to complete -- hopefully in a more clear way -- the thoughts I was trying to express earlier in the WG mtg. TERMINOLOGY; Anyplace I say "home" or "residence" below, I also mean to include "small business" or any other smallish organisation that might have a HomeNet type deployment. OBSERVATION: The HomeNet WG has at least 2 distinct communities in its membership, with at least 2 sets of objectives. There might well be more than 2, but hallway discussions this week make it clear to me that we have at least 2. So I think it unlikely that the WG can converge on any single solution for unicast routing. I doubt it is worth a lot of effort to try to force a single solution. I am not even sure it is necessary. USER COMMUNITIES: The WG has at least 2, possibly more, communities within its membership. These have at least some divergence in their goals/objectives, although there are some areas of commonality. A) Service Providers Several service providers want a Homet Net solution that lets them manage/provide/trouble-shoot the home networks inside their residential customers' homes and apartments. Service providers are comfortable with link-state routing and probably prefer IS-IS over OSPF for cultural reasons. Their goal is to reduce their operating expenses by reducing/eliminating telephone calls from users. So they will prefer a link-state approach to unicast routing within the home (or small business). This community is quite happy to adopt DHCP options and other IETF technology. In many cases, but not all cases, the equipment budgets are less critical than the potential for operating cost reductions (because operating costs recur, while capital costs are periodic). Something like HNCP has a good chance of also being included in their solutions. B) Consumer Electronics Vendors Many home users want to purchase their own in-home networking equipment and do NOT want to use provider- supplied equipment. The same is true for many small businesses. Consumer electronics vendors already are quite happy supplying this market. Consumer electronics vendors operate with thinner margins (e.g. eliminating one resistor makes a meaningful difference in their profit). Memory footprint and CPU cost matter a great deal to these manufacturers. They already have RIP, RIP is nearly zeroconf, and adding a link-state routing protocol would increase both their manufacturing cost and their support cost. Moreover, RIP scales just fine for residential and even small-business networks. It is nearly zeroconf, which is a bonus. So these folks are not likely to add any link-state routing protocol to their products. They are likely to add a few DHCP(v6) options that are useful and also are likely to add at least parts of HNCP (maybe the whole of HNCP if the footprint/complexity is small/low enough). PERSPECTIVE: It would optimise WG productivity to focus on matters other than trying to select a single unicast routing protocol. We can focus on making HNCP as good as it can be, identifying relevant DHCP(v6) options (possibly new options), identifying outputs from the IETF DNS-SD work that are applicable (and citing them as appropriate), and sorting out the other non-unicast-routing parts of the Home Net problem space. Yours, Ran PS: I agree with whomever spoke up earlier today about the importance of supporting IP multicasting throughout a HomeNet deployment. From nobody Fri Jul 25 09:52: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 3FC081A024E for ; Fri, 25 Jul 2014 09:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 MRiZ4QOLijwp for ; Fri, 25 Jul 2014 09:52:56 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A3BE01A01E2 for ; Fri, 25 Jul 2014 09:52:56 -0700 (PDT) Received: from nat64.meeting.ietf.org (unknown [IPv6:2001:67c:1231:998:e5e1:6c91:dd0c:fb1]) by toccata.fugue.com (Postfix) with ESMTPSA id DF09A2380935; Fri, 25 Jul 2014 12:52: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: <72E20441-9EE0-4A61-B127-BA96468B6E5F@gmail.com> Date: Fri, 25 Jul 2014 12:52:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <711FCA01-1990-4B49-8571-BBBD6BCC280B@fugue.com> References: <72E20441-9EE0-4A61-B127-BA96468B6E5F@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/qIHHe8vH9qr-sZhLq8fAFzEgotc Cc: homenet@ietf.org Subject: Re: [homenet] Clarification on Routing Thoughts X-BeenThere: homenet@ietf.org 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, 25 Jul 2014 16:52:58 -0000 It seems to me that you are grasping for a use case to justify a split = where none is needed. Protocols like OSPF, IS-IS and Babel would all = work in both environments. RIP won't. So this seems more like an = argument not to use RIP than an argument to have two different homenet = router profiles. From nobody Fri Jul 25 12:31: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 128A91A02D5 for ; Fri, 25 Jul 2014 12:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 3sTstSKAItQU for ; Fri, 25 Jul 2014 12:31:30 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1: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 3F7501A037A for ; Fri, 25 Jul 2014 12:31:30 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s6PJVSE1031423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 25 Jul 2014 21:31:28 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id s6PJVS3e011067 for ; Fri, 25 Jul 2014 21:31:28 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 882142C60D2 for ; Fri, 25 Jul 2014 21:31:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id AzzISiV2yaWW for ; Fri, 25 Jul 2014 21:31:27 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7532E2C60D5 for ; Fri, 25 Jul 2014 21:31:26 +0200 (CEST) Received: from jch (uid 1000) (envelope-from jch@pps.univ-paris-diderot.fr) id c002f4 by ijon.pps.univ-paris-diderot.fr (DragonFly Mail Agent v0.9); Fri, 25 Jul 2014 21:31:31 +0200 Date: Fri, 25 Jul 2014 21:31:30 +0200 Message-ID: <87egx98cbx.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: RJ Atkinson In-Reply-To: <72E20441-9EE0-4A61-B127-BA96468B6E5F@gmail.com> References: <72E20441-9EE0-4A61-B127-BA96468B6E5F@gmail.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 25 Jul 2014 21:31:28 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 25 Jul 2014 21:31:28 +0200 (CEST) X-Miltered: at korolev with ID 53D2B090.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 53D2B090.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53D2B090.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 53D2B090.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 53D2B090.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 53D2B090.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/s6YIxyh4mVhs439qC36qPYkCc6Q Cc: homenet@ietf.org Subject: Re: [homenet] Clarification on Routing Thoughts X-BeenThere: homenet@ietf.org 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, 25 Jul 2014 19:31:32 -0000 RJ, If I understand you right, you're pushing for an approach where we don't say anything about the routing protocol, and wait for the market to converge on RIPng, thus ensuring interoperability. Please correct me if I've misunderstood you. (My personal opinion right now (subject to change) is that we want a single Homenet protocol, but ensure that HNCP is designed so it is protocol-agnostic. We should make it clear that, while we encourage experimentation with other routing protocols, deploying HNCP with a non-Homenet routing protocol is not Homenet-compliant and doesn't give you the right to put the cool Homenet logo on your router.) > Consumer electronics vendors operate with thinner margins > (e.g. eliminating one resistor makes a meaningful difference in their > profit). Memory footprint and CPU cost matter a great deal to these > manufacturers. I think you're underestimating the amount of RAM and CPU in current cheap routers. The three cheapest routers I can find on Wallmart's website have between 16 and 32MB of RAM and a 300MHz MIPS CPU. That's plenty for running RIPng and Babel, and probably more than enough for a single-area variant of OSPF or IS-IS (Acee, can you confirm?). (The only reason I can see why these routers are unsuitable for Homenet is lack of flash -- some have as little as 4MB.) (Note that these are too slow to push anything close to 100Mb/s, even without firewalling, which, I suspect, is the reason why recent designs have switched to faster CPUs.) > They already have RIP, Do they? Are there any cheap routers that come with RIP enabled by default? > RIP is nearly zeroconf, and adding a link-state routing protocol would > increase both their manufacturing cost and their support cost. > Moreover, RIP scales just fine for residential and even small-business > networks. Just like you, I really like RIP, and could certainly live with RIPng being the One Homenet Routing Protocol. However, RIP(ng) has three major flaws: - the metric is a 4-bit integer, which seriously limits your ability to do fun stuff (like forcing traffic to follow the nice 1Gb/s cabling in preference to the unstable wifi); - the lack of explicit hello packets slows down link detection -- and there's no way you'll do a cool demo unless you can unplug the ethernet jack and have the traffic rerouted within seconds (with RIP, you'll need on the order of a minute, unless you have link-layer indications, which don't work well for other reasons); - RIP is unable to detect unidirectional failures. I don't see the lack of source-specific routing as a serious flaw, since desigining and implementing a source-specific extension to RIPng is probably a job for a day or two (I'm assuming you allow me to copy-paste from Babel and keep me furnished in coffee and food). > So these folks are not likely to add any link-state routing protocol to > their products. While I share your distaste for the "link-state everywhere" dogma, those folks who base their firmware on OpenWRT will add whatever doesn't require configuration and is well supported by OpenWRT. Those who don't are going to swear at us anyway. (Think of it as a consulting opportunity.) -- Juliusz From nobody Fri Jul 25 15:04: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 61ABB1A0392 for ; Fri, 25 Jul 2014 15:04:36 -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 aIploaO8abLw for ; Fri, 25 Jul 2014 15:04:35 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072E41A037C for ; Fri, 25 Jul 2014 15:04:34 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id j107so5766723qga.8 for ; Fri, 25 Jul 2014 15:04:34 -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 :content-transfer-encoding:message-id:references:to; bh=xESy4sb0ZUaRgmicYT1iciXfQCAkS0UvGAA/rDxCQIg=; b=Iz2yBd72VXFkiHVu9dcRsUq1lmDB5g3y0gI1ElJuE7U8t7fLodWR9cgcHhMrH7+rw9 5uk4flwFrhyPGUgXDycG9Jqz0q8flL+bl46CAl5PJ2lS0LuFPbo6lks9DPo+UUJvjHr3 7Y6cunfTp+aqurKTRC4uBGt0xN58JgVd9/SJULge79TeXxoKSyNQzd8C/jOJz28Kppm1 sCAzaV1nrtYACQGm5ehAZq83/kiQBa2hMXeOR/SKIyxse7BzA0WSANi4Y+1OU4IP90cq n7ViftQR6sbIfMFEmBC7uZBusd3th0/shf195RSHhzF5dGdxIMIbub7EtOmo9KBDdBzi YZUA== X-Received: by 10.224.156.145 with SMTP id x17mr31523183qaw.49.1406325874015; Fri, 25 Jul 2014 15:04:34 -0700 (PDT) Received: from [172.16.60.86] ([206.47.221.210]) by mx.google.com with ESMTPSA id g35sm12638406qgf.49.2014.07.25.15.04.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 15:04:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: <87egx98cbx.wl-jch@pps.univ-paris-diderot.fr> Date: Fri, 25 Jul 2014 18:04:22 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <72E20441-9EE0-4A61-B127-BA96468B6E5F@gmail.com> <87egx98cbx.wl-jch@pps.univ-paris-diderot.fr> To: homenet@ietf.org X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/-1qlmOBXDbtzfFcXOA739fHhxaE Subject: Re: [homenet] Clarification on Routing Thoughts X-BeenThere: homenet@ietf.org 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, 25 Jul 2014 22:04:36 -0000 On 25 Jul 2014, at 15:31 , Juliusz Chroboczek wrote: > If I understand you right, you're pushing for an approach where Not correct. I'm not "pushing" for anything. Yours, Ran From nobody Fri Jul 25 15: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 4601A1A03BE for ; Fri, 25 Jul 2014 15:09:44 -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 2HRqv3kBvE7V for ; Fri, 25 Jul 2014 15:09:37 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CBE01A037C for ; Fri, 25 Jul 2014 15:09:37 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id f51so5641833qge.25 for ; Fri, 25 Jul 2014 15:09:36 -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 :content-transfer-encoding:message-id:references:to; bh=i7txAB/+kY8nx7nOSi7pTSG9aSwuHV+lBggCIXgWCaA=; b=q5n5JCbgp15pmmFGO2XUScdgnPXo2B3bvGDxKVnIaUsT/szof6aZhAER07/V7Sut6D PSZRsYW8PQcGQbS06pAATGRsLn569exRv6T9rArY0RHhL78CWH6f5V61ANHpWRrclNIO x9gDcNAlVzAeyx69I761rAxHXnRyyNGgNNtClmPUkTUwT2XdzFawTQagisI7aFH4tbVo oE1yMHx/S8MtSHsjMXoYZ/GdCvQsP6vK1/Lmhg/2KQ3mt1zvduPEXyq1W26UCaaiJ4xx Diw2jW6mu9qaLzDYZhJIQ1Bd0CFjSNxnecQGF2t9QfPWCCxb9z1weeYrCUvZB0bRRiyy yufg== X-Received: by 10.140.80.2 with SMTP id b2mr22877580qgd.75.1406326176326; Fri, 25 Jul 2014 15:09:36 -0700 (PDT) Received: from [172.16.60.86] ([206.47.221.210]) by mx.google.com with ESMTPSA id h5sm12663710qgf.19.2014.07.25.15.09.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 15:09:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: <711FCA01-1990-4B49-8571-BBBD6BCC280B@fugue.com> Date: Fri, 25 Jul 2014 18:09:33 -0400 Content-Transfer-Encoding: 7bit Message-Id: <63A545CF-A521-4825-A473-9CD7D9D7AFF3@gmail.com> References: <72E20441-9EE0-4A61-B127-BA96468B6E5F@gmail.com> <711FCA01-1990-4B49-8571-BBBD6BCC280B@fugue.com> To: homenet@ietf.org X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/BhfnEdTqFj_BybdeSHxFywQsJrw Subject: Re: [homenet] Clarification on Routing Thoughts X-BeenThere: homenet@ietf.org 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, 25 Jul 2014 22:09:44 -0000 On 25 Jul 2014, at 12:52 , Ted Lemon wrote: > So this seems more like an argument ... Ted, To be clear, since you seem confused, my comments were not an argument for or against anything, just a set of observations. Cheers, Ran From nobody Fri Jul 25 22:27: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 9B8291A02F4 for ; Fri, 25 Jul 2014 22:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 lWsrrgZXdDG6 for ; Fri, 25 Jul 2014 22:27:11 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id B466E1A02F6 for ; Fri, 25 Jul 2014 22:27:11 -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 63EFF2380935; Sat, 26 Jul 2014 01:27: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: <63A545CF-A521-4825-A473-9CD7D9D7AFF3@gmail.com> Date: Sat, 26 Jul 2014 01:27:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9B4828C7-7C42-4C5E-A500-650B47DD7E7E@fugue.com> References: <72E20441-9EE0-4A61-B127-BA96468B6E5F@gmail.com> <711FCA01-1990-4B49-8571-BBBD6BCC280B@fugue.com> <63A545CF-A521-4825-A473-9CD7D9D7AFF3@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/RaoTEZ-JIg8by_QYD_I8wXLSGYg Cc: homenet@ietf.org Subject: Re: [homenet] Clarification on Routing Thoughts X-BeenThere: homenet@ietf.org 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, 26 Jul 2014 05:27:13 -0000 On Jul 25, 2014, at 6:09 PM, RJ Atkinson wrote: > To be clear, since you seem confused, my comments=20 > were not an argument for or against anything, > just a set of observations. I don't mean that you intended to argue that way. It's just the = conclusion I drew from the statements you made. From nobody Sat Jul 26 03:43: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 1C23E1A0ABE for ; Sat, 26 Jul 2014 03:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 n69d0jtac9zK for ; Sat, 26 Jul 2014 03:43:05 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 382EE1A0ABC for ; Sat, 26 Jul 2014 03:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3904; q=dns/txt; s=iport; t=1406371385; x=1407580985; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4LAgxhhiJHfd/aYw+nlNgK/GZOWryYMvwnD29NseaxU=; b=UBeyJJ0SAX/0UEwEPYPADUVDcb2GljkvnHsNwc4VkakrfTZnz/ANzxt8 so82zLNNPItNS6NbLSMvQe5q84xKJ0IU96M25DMdYa1K/mridYvAG5TJR LAfaLVUMl48bC6w4GvzxytZz3uT9kx5y8NLwNSVXWp7Ia0waJClw+JRi0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYFACeF01OtJV2S/2dsb2JhbABZgw5SVwTKe1IKhnJTAYEKFneEBAEBAgIBAQFrCxACAQgOOCcLJQIEAQ0FCYg5Db4SF48YMweESQWKN4xzhB+US4NJbAGBRA X-IronPort-AV: E=Sophos;i="5.01,735,1400025600"; d="scan'208";a="64227753" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP; 26 Jul 2014 10:43:04 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6QAh4vl032590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Jul 2014 10:43:04 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.69]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Sat, 26 Jul 2014 05:43:04 -0500 From: "Acee Lindem (acee)" To: Juliusz Chroboczek , RJ Atkinson Thread-Topic: [homenet] Clarification on Routing Thoughts Thread-Index: AQHPqCMNGbz28D9JvkCusZeQguIMBpuxgZ0AgAC7ogA= Date: Sat, 26 Jul 2014 10:43:03 +0000 Message-ID: References: <72E20441-9EE0-4A61-B127-BA96468B6E5F@gmail.com> <87egx98cbx.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <87egx98cbx.wl-jch@pps.univ-paris-diderot.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.11.178] 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/7lEqpVkwxFQFCZ-cYx3U3xk6eWA Cc: "homenet@ietf.org" Subject: Re: [homenet] Clarification on Routing Thoughts X-BeenThere: homenet@ietf.org 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, 26 Jul 2014 10:43:07 -0000 On 7/25/14, 3:31 PM, "Juliusz Chroboczek" wrote: >RJ, > >If I understand you right, you're pushing for an approach where we don't >say anything about the routing protocol, and wait for the market to >converge on RIPng, thus ensuring interoperability. Please correct me if >I've misunderstood you. > >(My personal opinion right now (subject to change) is that we want >a single Homenet protocol, but ensure that HNCP is designed so it is >protocol-agnostic. We should make it clear that, while we encourage >experimentation with other routing protocols, deploying HNCP with >a non-Homenet routing protocol is not Homenet-compliant and doesn't give >you the right to put the cool Homenet logo on your router.) > >> Consumer electronics vendors operate with thinner margins >> (e.g. eliminating one resistor makes a meaningful difference in their >> profit). Memory footprint and CPU cost matter a great deal to these >> manufacturers. > >I think you're underestimating the amount of RAM and CPU in current cheap >routers. The three cheapest routers I can find on Wallmart's website have >between 16 and 32MB of RAM and a 300MHz MIPS CPU. That's plenty for >running RIPng and Babel, and probably more than enough for a single-area >variant of OSPF or IS-IS (Acee, can you confirm?). Yes - it should be more than enough. Recall that Markus=B9 OSPFv3 Bird implementation report presented Berlin. http://www.ietf.org/proceedings/87/slides/slides-87-homenet-2.pdf I=B9d expect ISIS to be similar since commercial SP implementation sizes ar= e comparable.=20 Thanks, Acee=20 >(The only reason I can >see why these routers are unsuitable for Homenet is lack of flash -- some >have as little as 4MB.) > >(Note that these are too slow to push anything close to 100Mb/s, even >without firewalling, which, I suspect, is the reason why recent designs >have switched to faster CPUs.) > >> They already have RIP, > >Do they? Are there any cheap routers that come with RIP enabled by >default? > >> RIP is nearly zeroconf, and adding a link-state routing protocol would >> increase both their manufacturing cost and their support cost. >> Moreover, RIP scales just fine for residential and even small-business >> networks. > >Just like you, I really like RIP, and could certainly live with RIPng >being the One Homenet Routing Protocol. However, RIP(ng) has three major >flaws: > > - the metric is a 4-bit integer, which seriously limits your ability to > do fun stuff (like forcing traffic to follow the nice 1Gb/s cabling in > preference to the unstable wifi); > - the lack of explicit hello packets slows down link detection -- and > there's no way you'll do a cool demo unless you can unplug the ethernet > jack and have the traffic rerouted within seconds (with RIP, you'll > need on the order of a minute, unless you have link-layer indications, > which don't work well for other reasons); > - RIP is unable to detect unidirectional failures. > >I don't see the lack of source-specific routing as a serious flaw, since >desigining and implementing a source-specific extension to RIPng is >probably a job for a day or two (I'm assuming you allow me to copy-paste >from Babel and keep me furnished in coffee and food). > >> So these folks are not likely to add any link-state routing protocol to >> their products. > >While I share your distaste for the "link-state everywhere" dogma, those >folks who base their firmware on OpenWRT will add whatever doesn't require >configuration and is well supported by OpenWRT. Those who don't are going >to swear at us anyway. (Think of it as a consulting opportunity.) > >-- Juliusz > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From nobody Sat Jul 26 08:30: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 3B87F1B282E for ; Sat, 26 Jul 2014 08:30:18 -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 G9RThFUpnhDv for ; Sat, 26 Jul 2014 08:30:16 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E57E1A0326 for ; Sat, 26 Jul 2014 08:30:16 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 78F028813F for ; Sat, 26 Jul 2014 08:30:16 -0700 (PDT) Received: from clemson.local (c-76-21-129-88.hsd1.md.comcast.net [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 4166171B0001 for ; Sat, 26 Jul 2014 08:30:16 -0700 (PDT) Message-ID: <53D3C97F.20500@innovationslab.net> Date: Sat, 26 Jul 2014 11:30:07 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: homenet@ietf.org References: <72E20441-9EE0-4A61-B127-BA96468B6E5F@gmail.com> <87egx98cbx.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <87egx98cbx.wl-jch@pps.univ-paris-diderot.fr> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VFOr7cNbxixrIei9D3U5s1Wg2mTuXGl6H" Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/2Pw63HyfAj31VYCf4W_i2FXJZ1s Subject: Re: [homenet] Clarification on Routing Thoughts X-BeenThere: homenet@ietf.org 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, 26 Jul 2014 15:30:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VFOr7cNbxixrIei9D3U5s1Wg2mTuXGl6H Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7/25/14 3:31 PM, Juliusz Chroboczek wrote: >=20 > (My personal opinion right now (subject to change) is that we want > a single Homenet protocol, but ensure that HNCP is designed so it is > protocol-agnostic. We should make it clear that, while we encourage > experimentation with other routing protocols, deploying HNCP with > a non-Homenet routing protocol is not Homenet-compliant and doesn't giv= e > you the right to put the cool Homenet logo on your router.) To quote an IESG colleague: "The IETF does not do compliance." The goal should be increasing the probability of interoperability between devices from different vendors. Brian --VFOr7cNbxixrIei9D3U5s1Wg2mTuXGl6H Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT08mIAAoJEBOZRqCi7goq7GkH/38S/bJLAyCU3STD1lQRoQCg yBoIiWg+EtqkJmQY4HrIN9YWVOGJzPgXkDGp7thvDWJlK+tgLiA/6Rj3dLZCN7Dk CANCoBTSUEd9G3dEa8NMB5gu06a9vAu3YGzxOygwSb5cnuPPOwwlmWB+aLC6q8Pm k/uYW7lz5ew/TkDU1QSzhq3GF94ilFX+3ZWmzZHMaXPrmdLEwDqSVQs2oLgxOYEr DgtpE6DoRj/8VQSOHvt3+K/jyrPorjDB6f+UA9qxIed6eNs4yGvjsnCJ7OFMJwWu iv8aVXaXO4A4shq+0NPGyLfnbE++K/Wufwt3IB2z60wkeM6gqR6L7k+ZgK9YmKg= =zghj -----END PGP SIGNATURE----- --VFOr7cNbxixrIei9D3U5s1Wg2mTuXGl6H-- From nobody Sat Jul 26 12:42: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 C1D411A0396 for ; Sat, 26 Jul 2014 12:42:43 -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 oTtSe9LYd4hv for ; Sat, 26 Jul 2014 12:42:42 -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 6C1B61A0385 for ; Sat, 26 Jul 2014 12:42:42 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id tr6so5041435ieb.21 for ; Sat, 26 Jul 2014 12:42: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=zfpEMqDvbvetWVec7CLJR8IZTX5fxrd/5NwCOXAb8yY=; b=GFqYPGaLn+PZFYgwdnMUspnVd2ej10odehQTjXfNRixwhQIGw4uVBt76OeOJCA6J4B m4BAWoyEECBZXiVMtQHDFwD5dM/Zv29hNoKg6I1tDUUP9yYSxwDW6h98tkZHKcA6G7uz OulVdqIjR6+WX4ljdvYOqKmyezFpIt+R95z8SRkozbmrAfWlP2641Eujwdd9Xd4UGabL K6V/WAQb78Owi7/7WTKhaywG0aX4r6o8H04cnDF5x6czd71fHsk786LaDpBB/zJBhLn+ X2SrkfJojluiOV4SKZwG/+S2VVY7Met2Q4XexDtA6MvT1V0OOUhegVdRtvd35ZunUeYh BGxA== X-Received: by 10.50.43.137 with SMTP id w9mr2334802igl.36.1406403761898; Sat, 26 Jul 2014 12:42:41 -0700 (PDT) Received: from [10.205.128.216] ([209.226.201.243]) by mx.google.com with ESMTPSA id y14sm2174275igg.0.2014.07.26.12.42.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Jul 2014 12:42:41 -0700 (PDT) Message-ID: <53D404AB.5040605@gmail.com> Date: Sun, 27 Jul 2014 07:42:35 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Haberman References: <72E20441-9EE0-4A61-B127-BA96468B6E5F@gmail.com> <87egx98cbx.wl-jch@pps.univ-paris-diderot.fr> <53D3C97F.20500@innovationslab.net> In-Reply-To: <53D3C97F.20500@innovationslab.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/41RMp43Adn8zYbZcCzxTb1bsyPE Cc: homenet@ietf.org Subject: Re: [homenet] Clarification on Routing Thoughts X-BeenThere: homenet@ietf.org 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, 26 Jul 2014 19:42:43 -0000 On 27/07/2014 03:30, Brian Haberman wrote: ... > The goal should be increasing the probability of interoperability > between devices from different vendors. Exactly, which traditionally means a single mandatory-to-implement protocol, even if it's the Tossacoin protocol. Whether vendors take any notice is outside our control. Tossacoin, i.e. random routing, is of course a valid routing algorithm in itself. Isn't that the original reason why we had a TTL/hop count? It would probably work quite well in a small homenet. Brian C From nobody Sat Jul 26 16:42: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 957F01A0338 for ; Sat, 26 Jul 2014 16:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 4IvyAygPA_2H for ; Sat, 26 Jul 2014 16:42:18 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1: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 EFC081A0194 for ; Sat, 26 Jul 2014 16:42:17 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id s6QNgFti004016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 27 Jul 2014 01:42:16 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id s6QNgFBi005916 for ; Sun, 27 Jul 2014 01:42:15 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 99F212C4B0E for ; Sun, 27 Jul 2014 01:42:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Uah6lTUv1-ot for ; Sun, 27 Jul 2014 01:42:14 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id BDCD32C6635 for ; Sun, 27 Jul 2014 01:42:14 +0200 (CEST) Received: from jch (uid 1000) (envelope-from jch@pps.univ-paris-diderot.fr) id c0028b by ijon.pps.univ-paris-diderot.fr (DragonFly Mail Agent v0.9); Sun, 27 Jul 2014 01:42:22 +0200 Date: Sun, 27 Jul 2014 01:42:22 +0200 Message-ID: <87a97voffl.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Brian E Carpenter In-Reply-To: <53D404AB.5040605@gmail.com> References: <72E20441-9EE0-4A61-B127-BA96468B6E5F@gmail.com> <87egx98cbx.wl-jch@pps.univ-paris-diderot.fr> <53D3C97F.20500@innovationslab.net> <53D404AB.5040605@gmail.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sun, 27 Jul 2014 01:42:16 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 27 Jul 2014 01:42:15 +0200 (CEST) X-Miltered: at korolev with ID 53D43CD7.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 53D43CD7.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 53D43CD7.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 53D43CD7.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 53D43CD7.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 53D43CD7.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/K0dxZFHdX5oKzf0ru6zVRrVASos Cc: homenet@ietf.org Subject: Re: [homenet] Clarification on Routing Thoughts X-BeenThere: homenet@ietf.org 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, 26 Jul 2014 23:42:19 -0000 > Tossacoin, i.e. random routing, is of course a valid routing algorithm > in itself. Isn't that the original reason why we had a TTL/hop count? It > would probably work quite well in a small homenet. I call it hot potato routing, and I define it as choosing a random interface other than the one through which the packet was received. I once brought some actual potatoes to my lecture, and we implemented hot potato routing; it turned out being a good introduction to the subject of packet drops. (I don't think we ever laughed so much during one of my lectures.) Next time, I'll do mashed potato routing. -- Juliusz From nobody Sat Jul 26 17:51: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 BC9781A0422 for ; Sat, 26 Jul 2014 17:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.796 X-Spam-Level: X-Spam-Status: No, score=0.796 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001, 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 HVyBCw7pYXfd for ; Sat, 26 Jul 2014 17:51: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 B1F0E1A0444 for ; Sat, 26 Jul 2014 17:51:51 -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 s6R0ppt3004254 for ; Sat, 26 Jul 2014 17:51:51 -0700 Message-ID: <53D44D27.6060301@mtcc.com> Date: Sat, 26 Jul 2014 17:51:51 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: homenet@ietf.org References: <72E20441-9EE0-4A61-B127-BA96468B6E5F@gmail.com> <87egx98cbx.wl-jch@pps.univ-paris-diderot.fr> <53D3C97F.20500@innovationslab.net> <53D404AB.5040605@gmail.com> <87a97voffl.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <87a97voffl.wl-jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/0LJucqYIwfuk7FiVfcjKRlN3D6Y Subject: Re: [homenet] Clarification on Routing Thoughts X-BeenThere: homenet@ietf.org 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, 27 Jul 2014 00:51:54 -0000 On 07/26/2014 04:42 PM, Juliusz Chroboczek wrote: >> Tossacoin, i.e. random routing, is of course a valid routing algorithm >> in itself. Isn't that the original reason why we had a TTL/hop count? It >> would probably work quite well in a small homenet. > I call it hot potato routing, and I define it as choosing a random > interface other than the one through which the packet was received. > I once brought some actual potatoes to my lecture, and we implemented hot > potato routing; it turned out being a good introduction to the subject of > packet drops. (I don't think we ever laughed so much during one of my > lectures.) > I wonder if anybody has ever considered routing from a natural selection perspective. You throw random mutations (router chaos monkeys!) into the routing tables every once in a while and see if the packet progeny dies off or becomes more fit. Perhaps the mutation rate is the result of feedback from the packet mortality rate, and backhoes are the equivalent of asteroids, cf punctuated evolution. (maybe we can borrow some v6 address bits for the genetic material? :) Mike From nobody Thu Jul 31 21:03: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 A7BDF1A03C0 for ; Thu, 31 Jul 2014 21:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_NET=0.311, 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 dnpVwhdvETuN for ; Thu, 31 Jul 2014 21:03:37 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB021A03C8 for ; Thu, 31 Jul 2014 21:03:37 -0700 (PDT) Received: from sandelman.ca (modemcable202.173-70-69.static.videotron.ca [69.70.173.202]) by relay.sandelman.ca (Postfix) with ESMTPS id F2721220B1; Fri, 1 Aug 2014 00:03:35 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7BECECA0D9; Fri, 1 Aug 2014 00:03:34 -0400 (EDT) From: Michael Richardson To: Ted Lemon In-reply-to: <711FCA01-1990-4B49-8571-BBBD6BCC280B@fugue.com> References: <72E20441-9EE0-4A61-B127-BA96468B6E5F@gmail.com> <711FCA01-1990-4B49-8571-BBBD6BCC280B@fugue.com> Comments: In-reply-to Ted Lemon message dated "Fri, 25 Jul 2014 12:52:54 -0400." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 01 Aug 2014 00:03:34 -0400 Message-ID: <9402.1406865814@sandelman.ca> Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/wy62nl6SlK4RERgMVOn18CezFcs Cc: homenet@ietf.org, RJ Atkinson Subject: Re: [homenet] Clarification on Routing Thoughts X-BeenThere: homenet@ietf.org 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, 01 Aug 2014 04:03:38 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Ted Lemon wrote: > It seems to me that you are grasping for a use case to justify a split > where none is needed. Protocols like OSPF, IS-IS and Babel would all > work in both environments. RIP won't. So this seems more like an > argument not to use RIP than an argument to have two different homenet > router profiles. =20 For the record, can you expound on the technical reason why RIP(v2) won't work? (I'm not a fan of it, but last time I used it was on SunOS 3 or something) =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJT2xGUAAoJEKD0KQ7Gj3P2dfwH/j461iIP9utJpr3AJHpHGRHl 7haJmmPUqm4t+TqmqtwjdKGQ02+MsmAHsjcel38T7V3Hkqfoq/upXpOEqHI2FcAf 5iP6UxqEHkLqhVxGUcUXxPNKOgomfASN0NMWTPObAr7Hsjsu4Q03+hdZMw3O09hw h8i/eL7gIH6XkdG2AQ0HSJs+rNXHBeePvC4zYFOplczQLdXo3EttCu2bfDFLkEZ9 mq/ydpbkpxwhKD6wfhSRxfSjtjtTVa/GDE0FWFsKmlko7Y4tihMuDtJpQnHRcEOD i2D/CJJuDZAhUeUIN8CP72lgV9RO5413ZXWxRPQ/Z8s70BhfONQw/CIIChDJuRo= =C27q -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 31 23:11: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 2676C1A0415 for ; Thu, 31 Jul 2014 23:11:00 -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_40=-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 w7sj5VPOQxMP for ; Thu, 31 Jul 2014 23:10:58 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.199]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9721A0426 for ; Thu, 31 Jul 2014 23:10:40 -0700 (PDT) Received: from [192.168.38.220] (217.28.190.35) by jenni2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 53C62CBF0177D067; Fri, 1 Aug 2014 09:10:31 +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: <9402.1406865814@sandelman.ca> Date: Fri, 1 Aug 2014 06:10:26 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <72E20441-9EE0-4A61-B127-BA96468B6E5F@gmail.com> <711FCA01-1990-4B49-8571-BBBD6BCC280B@fugue.com> <9402.1406865814@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/f5CAmkmGdX2j82TQVKprruBI_u4 Cc: RJ Atkinson , homenet@ietf.org, Markus Stenberg , Ted Lemon Subject: Re: [homenet] Clarification on Routing Thoughts X-BeenThere: homenet@ietf.org 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, 01 Aug 2014 06:11:00 -0000 On 1.8.2014, at 4.03, Michael Richardson wrote: > Ted Lemon wrote: >> It seems to me that you are grasping for a use case to justify a = split >> where none is needed. Protocols like OSPF, IS-IS and Babel would all >> work in both environments. RIP won't. So this seems more like an >> argument not to use RIP than an argument to have two different = homenet >> router profiles. > For the record, can you expound on the technical reason why RIP(v2) = won't > work? (I'm not a fan of it, but last time I used it was on SunOS 3 or > something) RIPng (RFC2080) isn=92t source specific, I=92m not sure if there=92s = something more recent on RIP front that is (and is widely implemented = available). Obviously, extending RIPng to be source specific would not = be hard, but then it wouldn=92t be RIP anymore by strict definition (no = existing implementations). Cheers, -Markus From nobody Thu Jul 31 23: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 520291A0242 for ; Thu, 31 Jul 2014 23:18: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, RP_MATCHES_RCVD=-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 kxAHVi334Y71 for ; Thu, 31 Jul 2014 23:18:14 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8758E1A00B9 for ; Thu, 31 Jul 2014 23:18:14 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s716IA8S090526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 1 Aug 2014 06:18:11 GMT (envelope-from joelja@bogus.com) Message-ID: <53DB311D.4030902@bogus.com> Date: Thu, 31 Jul 2014 23:18:05 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Michael Richardson , Ted Lemon References: <72E20441-9EE0-4A61-B127-BA96468B6E5F@gmail.com> <711FCA01-1990-4B49-8571-BBBD6BCC280B@fugue.com> <9402.1406865814@sandelman.ca> In-Reply-To: <9402.1406865814@sandelman.ca> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eDA98HvcKt7MPMLwcOWvfUsLKRiJQ2MWd" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Fri, 01 Aug 2014 06:18:11 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/hUDT5GNulm0j-E1oqfTb27BhRnw Cc: homenet@ietf.org, RJ Atkinson Subject: Re: [homenet] Clarification on Routing Thoughts X-BeenThere: homenet@ietf.org 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, 01 Aug 2014 06:18:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eDA98HvcKt7MPMLwcOWvfUsLKRiJQ2MWd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/31/14 9:03 PM, Michael Richardson wrote: >=20 > Ted Lemon wrote: > > It seems to me that you are grasping for a use case to justify a = split > > where none is needed. Protocols like OSPF, IS-IS and Babel would= all > > work in both environments. RIP won't. So this seems more like an= > > argument not to use RIP than an argument to have two different ho= menet > > router profiles. > =20 > For the record, can you expound on the technical reason why RIP(v2) won= 't > work? (I'm not a fan of it, but last time I used it was on SunOS 3 or > something) hop count isn't a great tool for expressing that your gig-e port is a more desireable path if up then the wifi interface. >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet >=20 --eDA98HvcKt7MPMLwcOWvfUsLKRiJQ2MWd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPbMR0ACgkQ8AA1q7Z/VrKynQCghC3u3WH/CF6/dUgLd3AA79U3 M+wAn1dfUa0oeg+ef3pDa3vxzIyhUDJn =cNpc -----END PGP SIGNATURE----- --eDA98HvcKt7MPMLwcOWvfUsLKRiJQ2MWd--