From nobody Thu Apr 6 01:55:33 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB3B1292FD for ; Thu, 6 Apr 2017 01:55: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 rbyIkXpskWgH for ; Thu, 6 Apr 2017 01:55:29 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE181200DF for ; Thu, 6 Apr 2017 01:55:28 -0700 (PDT) Received: from [46.227.151.81] (port=49968 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1cw3CQ-0005PZ-1Y (Exim 4.72) for homenet@ietf.org (return-path ); Thu, 06 Apr 2017 09:55:26 +0100 To: HOMENET From: Ray Bellis Message-ID: <27930f4c-018d-92b9-18e4-9c0e20aa4471@bellis.me.uk> Date: Thu, 6 Apr 2017 09:55:25 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [homenet] Draft minutes online X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 08:55:32 -0000 The draft minutes of the WG session at IETF 98 are now online, with thanks to Barbara Stark and Stuart Cheshire: If you have any comments please send them to the chairs by April 21st. Ray From nobody Thu Apr 6 17:16:01 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E44FA126E01; Thu, 6 Apr 2017 17:15:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: homenet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149152415987.22060.14668852147365708738@ietfa.amsl.com> Date: Thu, 06 Apr 2017 17:15:59 -0700 Archived-At: Subject: [homenet] I-D Action: draft-ietf-homenet-dot-04.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 00:16:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking of the IETF. Title : Special Use Domain '.home.arpa' Authors : Pierre Pfister Ted Lemon Filename : draft-ietf-homenet-dot-04.txt Pages : 7 Date : 2017-04-06 Abstract: This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.', and designates this top-level domain as a special-use domain name. The '.home.arpa' top-level domain replaces '.home' as the default domain used by the Home Networking Control Protocol (HNCP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-homenet-dot-04 https://datatracker.ietf.org/doc/html/draft-ietf-homenet-dot-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dot-04 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 Thu Apr 13 17:38:55 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBF31314F1 for ; Thu, 13 Apr 2017 17:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10X_l4jrPbPX for ; Thu, 13 Apr 2017 17:38:51 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45: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 8A5B4128796 for ; Thu, 13 Apr 2017 17:38:51 -0700 (PDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1492130328; bh=YNmoQhSm2vGyGEreMd3Tdamb/Nqz47tAexRnFkt873E=; h=From:To:Subject:Date:From; b=LjPlPQl8MTT1kW2bMJwW18qz8fgCCoiLaBfVV+Lqs7jpfk95sr5uBhNL2KQtUmf0+ GvWsAzNQ1Ai26IF89lDYPLQ5eEiOFWUTRAla/14xwWcTdrfCEuxsefJmVsDiKEsoJf f2/4u5UeKQUo72khhCcaC92b6UUpI9p5LCWGaAFovnONZyScz+BapQcv0jkdfO09nN efWV+pA031vH9YNAuzNJKe80RggjNfU6Z7jmOgt6ZlBg9VNUwj7/LOumXGX/QMd0mj 7WzIKWIM9GlyiLQfwSeaRSK1meFzQh+mVSum4NJJfoy4pivfgTHeC5nl4Sd077Kdag esemAeGE0C+xw== To: homenet@ietf.org Date: Fri, 14 Apr 2017 02:38:46 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87r30vomax.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [homenet] A TOFU approach to naming things in the homenet (with code!) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 00:38:54 -0000 Hey everyone While following the naming discussions, I have been thinking about how to do one of the things that the current naming architecture draft excludes: Allowing devices on the homenet to register in (public) DNS so that one may find them. And since I also wanted to learn the Go programming language, I decided to prototype something. Enter the 'nsregd' daemon. This daemon will allow a client to claim a name on a Trust On First Use (TOFU) basis using the RFC2136 dynamic DNS update protocol. A client claims a name by sending a DNS update request with a SIG(0) (RFC2931) signature and including the public key corresponding to the signature. If the name in a claim is not already taken by another client, the client's claim will be successful and the daemon will cache the public key and use it to verify subsequent update requests. Once a name has been claimed by a client, that client can add and remove A and AAAA records by means of regular DNS update requests signed with the key used to claim the name. The daemon will forward these updates to one or more configured upstream authoritative nameservers. I'm posting this here in the hope that others will find it useful, either as input to the discussion, or as a tool to play around with. The code is available on Github: https://github.com/tohojo/nsregd The README file has a few more details on how it's supposed to work. Comments very welcome, patches even more so :) Cheers, -Toke From nobody Thu Apr 13 18:29:27 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E8B1243FE for ; Thu, 13 Apr 2017 18:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILu5kg9nhg_S for ; Thu, 13 Apr 2017 18:29:25 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73711242EA for ; Thu, 13 Apr 2017 18:29:24 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id n46so58197152qta.2 for ; Thu, 13 Apr 2017 18:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=eO/S54RTq/G2TLd0sgqPN5Aa6dY/3GwaKwKMCXoSxNc=; b=uhO8U+syPGvPjxld6VhsPq+iYLmpklphgUHvvTR1zQzvMJU/M5zOLH4xwu8ClMTosx VW5qslHy6MJ8FZbDz37oCgqikqDOLxWD+wc9Bs1c+gYDQj4UkANTDxJr4txPRZpYoyxh z7Ogmq6zaBtZdo/MAg+IgXlW5Nex66HrEbVEGv6hCIW4vzad20cR+Xq95Mz8UFDoa0hZ lzBBdoSryDzCIzH9sIhoQZHJ9SbBh9sgIYMKorOd9vkqJxbrJmc/nWAl0OeWG7hy28Li JFyU59dVmR0HGySR6ZadCOhxEdNPshDCrSVIyhE1Wqc5r/8WWlPoU+MAPBLhOPhTkU56 3eVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=eO/S54RTq/G2TLd0sgqPN5Aa6dY/3GwaKwKMCXoSxNc=; b=YvxgXgK7MGGWXt6fxTBudI8HdyMyChpqesk4uk8DiOzU9qd48bDXvzgL8AmEwiqEoT Z+lTqC1K+Sj+7+dj2yKavjSxlFUPG0B0QeGpKeo41Quz5vpiiijWaugcWlIAGq32iJgO GVxX63/O7gmxCrxCvHvFIr8yOPII2O1gROp49BekCNe4aIkGT53rED3CEhGBWcX/XN5g sdkcR4ezh9V49H9AW2egb2cyDMnTdHlRnT4xfMaOWxWKzOT1Cqn0erCw0NC8owgbZvvq H3qLCc0TZADak0fHtvFPJvZZ1nJ7EIgMi1PiXCnW1PhgYOEQ2DSPWEsPqhVypIr/tHNg dBTA== X-Gm-Message-State: AN3rC/7wL1V4Q5o8nj6DGj0NPr7JmgTUt+l3yln4IILFwVzbYeFvHFYc L0kvRgMoZeVj1w== X-Received: by 10.200.46.103 with SMTP id s36mr5079992qta.54.1492133363944; Thu, 13 Apr 2017 18:29:23 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id m57sm343794qtb.23.2017.04.13.18.29.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 18:29:23 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_01EAA927-4F9B-4CF8-AD1C-9582FE07A5B3" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 13 Apr 2017 21:29:21 -0400 In-Reply-To: <87r30vomax.fsf@alrua-x1> Cc: homenet@ietf.org To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <87r30vomax.fsf@alrua-x1> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] A TOFU approach to naming things in the homenet (with code!) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 01:29:27 -0000 --Apple-Mail=_01EAA927-4F9B-4CF8-AD1C-9582FE07A5B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for doing this! Did you come up with this on your own, or were = inspired by = https://tools.ietf.org/html/draft-lemon-homenet-naming-architecture-01 = = section 3.4.2 and = https://tools.ietf.org/html/draft-lemon-stateful-dnssd-00 = section 4.2? I ask both because I'm curious of you're proposing that the previous = naming architecture document is more in line with what you think should = be on a homenet, and also because I'm curious whether you are interested = in working on the documents. --Apple-Mail=_01EAA927-4F9B-4CF8-AD1C-9582FE07A5B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks for doing this!   Did you come up with this on = your own, or were inspired by https://tools.ietf.org/html/draft-lemon-homenet-naming-architec= ture-01 section 3.4.2 and https://tools.ietf.org/html/draft-lemon-stateful-dnssd-00&n= bsp;section 4.2?

I = ask both because I'm curious of you're proposing that the previous = naming architecture document is more in line with what you think should = be on a homenet, and also because I'm curious whether you are interested = in working on the documents.

= --Apple-Mail=_01EAA927-4F9B-4CF8-AD1C-9582FE07A5B3-- From nobody Fri Apr 14 06:34:08 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF71412ECA3 for ; Fri, 14 Apr 2017 06:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHzRDXUrIBcg for ; Fri, 14 Apr 2017 06:34:05 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45: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 015DD129435 for ; Fri, 14 Apr 2017 06:34:05 -0700 (PDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1492176841; bh=z0qipXgV1YCVIWWoSxYfz4J5Ps4ghiVYn6geDBVH6MI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=cThbNJvBhsIQZPQuehnBPSw8oUZKM/16iQi8X1GAQzshAr6jpTjybUrRyvDTOGi0w fjuljLva+iDKKB1zq4oksdVCxALSt4k+znYeZlMogotNGkhVaD+N3DSktSi0bqfrj6 hbUFJGwya44yO9e+5JyDEkXXI/ZfqciTxrjmN8jKfik/SrGQlGabhAE7LlbgIK4as8 c8oCgGGEfsds6n6euW8VSRaNnoS5xP/iCojdV8J8YxjfC9rkqPTwlC9mw1wtuw6KW9 OhIvlt/jJhzYA/SoQoMvTjg9beJqLsgt4KsbgtIGuPGvxPXnLVLS5SU8rqZKcYFiAb AFvuhd5CTGmkQ== To: Ted Lemon Cc: homenet@ietf.org References: <87r30vomax.fsf@alrua-x1> Date: Fri, 14 Apr 2017 15:34:01 +0200 In-Reply-To: (Ted Lemon's message of "Thu, 13 Apr 2017 21:29:21 -0400") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87lgr3nmeu.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [homenet] A TOFU approach to naming things in the homenet (with code!) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 13:34:07 -0000 Ted Lemon writes: > Thanks for doing this! Did you come up with this on your own, or were > inspired by > https://tools.ietf.org/html/draft-lemon-homenet-naming-architecture-01 > section 3.4.2 and > https://tools.ietf.org/html/draft-lemon-stateful-dnssd-00 section 4.2? Well, I would by no means claim to have come up with the idea in a vacuum. As I said, I have been following the naming discussions on this list. I think I read the -00 of the naming architecture, but I have not read the latest version, nor have I read the stateful-dnssd draft before. Looking at it now, what I have implemented looks like a hybrid of the two halves of section 3.4.2. I.e., clients generate a KEY and use it to sign updates, and they use that to remove records as well (i.e., there is no support for unauthenticated updates in nsregd). But the records are not permanent; the daemon will expire records that the client does not maintain (since if a client drops off the network it has no way of retiring its record). > I ask both because I'm curious of you're proposing that the previous > naming architecture document is more in line with what you think > should be on a homenet, and also because I'm curious whether you are > interested in working on the documents. Hmm, well, I have first and foremost been trying to scratch my own itch here. I was looking for something to replace dnsmasq's slaac address guessing (https://tools.ietf.org/id/draft-taht-kelley-hunt-dhcpv4-to-slaac-naming-00.html), and since no good solutions were forthcoming, I decided to roll my own. That being said, I do believe this mechanism could be useful as part of the homenet architecture, which is why I posted it here. And I wouldn't mind spending some time fleshing out the mechanism and putting it into a draft, if that is what you mean by "working on the documents"? -Toke From nobody Fri Apr 14 06:51:43 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE361120454 for ; Fri, 14 Apr 2017 06:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 AECkQHCVFXgY for ; Fri, 14 Apr 2017 06:51:40 -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 16ACC128CD5 for ; Fri, 14 Apr 2017 06:51:39 -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/56228) with ESMTP id v3EDpcx8010403; Fri, 14 Apr 2017 15:51:38 +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 6768CD79B2; Fri, 14 Apr 2017 15:51:38 +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 8-6rX9jCJs6O; Fri, 14 Apr 2017 15:51:37 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6DAA1D79D8; Fri, 14 Apr 2017 15:51:37 +0200 (CEST) Date: Fri, 14 Apr 2017 15:51:42 +0200 Message-ID: <87r30v3xn5.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: homenet@ietf.org In-Reply-To: <87r30vomax.fsf@alrua-x1> References: <87r30vomax.fsf@alrua-x1> 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, 14 Apr 2017 15:51:38 +0200 (CEST) X-Miltered: at korolev with ID 58F0D3EA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F0D3EA.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 : 58F0D3EA.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: Subject: Re: [homenet] A TOFU approach to naming things in the homenet (with code!) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 13:51:42 -0000 Simple and elegant, solves a real problem without too much ideology. > This daemon will allow a client to claim a name on a Trust On First Use > (TOFU) basis Cool. > If the name in a claim is not already taken by another nclient, the > client's claim will be successful and the daemon will cache the public > key and use it to verify subsequent update requests. Does this imply there's a single daemon in the Homenet? How does the network elect it in case there are multiple claimants? How does the client learn the address of the daemon? -- Juliusz From nobody Fri Apr 14 07:16:27 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADEA7128792 for ; Fri, 14 Apr 2017 07:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WosvzNBY6lwF for ; Fri, 14 Apr 2017 07:16:24 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 227FE129445 for ; Fri, 14 Apr 2017 07:16:24 -0700 (PDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1492179381; bh=FWHFH0K8UgMCyoGyp51h2/VYWSKe935FsyFwI7rNqRE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Q4HWyZc8TIluFtqEWH8+RUNWdgnULy5fXnt9x2xaK509wAf3MphlC9IkKI5crJ4ti zAllgo5BWb519RGZLYEuaZ0ZVhxenbQDWRr0FYR3diltRUxop/2ixiIJJSIqb9+rNP v9lSbxM/epfEd6m1hb2ff/Z8BJXkfZeYCHqu0y0iDVjqsffWKoX4metWH73loWI1mH FYqQAR7o7NIPCeh1S26BHDUmLzkoDc7TLqy7SfUj7w5SiTK+r6FQ4aKc2S1iqvEVPk Z4CPFw7cMsNjWLCzzZhqqlpAPD2hmH2nFiCxElC6/1e0YYPorORrPHDzs/GjAt3OQq 3ZP4zohq1iTmw== To: Juliusz Chroboczek Cc: homenet@ietf.org References: <87r30vomax.fsf@alrua-x1> <87r30v3xn5.wl-jch@irif.fr> Date: Fri, 14 Apr 2017 16:16:19 +0200 In-Reply-To: <87r30v3xn5.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Fri, 14 Apr 2017 15:51:42 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87h91rnkgc.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [homenet] A TOFU approach to naming things in the homenet (with code!) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 14:16:26 -0000 Juliusz Chroboczek writes: > Simple and elegant, solves a real problem without too much ideology. Thank you! That is high praise, coming from you :) >> If the name in a claim is not already taken by another nclient, the >> client's claim will be successful and the daemon will cache the public >> key and use it to verify subsequent update requests. > > Does this imply there's a single daemon in the Homenet? How does the > network elect it in case there are multiple claimants? How does the > client learn the address of the daemon? In the current implementation, a single daemon per registration zone. The client will query for a SRV at _nsreg._tcp. to find the daemon, which can be anywhere, in principle (the daemon will only speak TCP and limits initial registration to a list of configured subnets; I'm currently running mine on a separate server rather than on my router). For the multi-homed homenet case, I suppose each uplink could have a separate zone? I punted somewhat on how to discover the zone; the client will currently take it as a command line parameter. But figure that can be distributed via DHCP/RA? In principle, there's nothing preventing the daemon state from being replicated across the homenet routers, I suppose... -Toke From nobody Fri Apr 14 07:37:52 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2F513010D for ; Fri, 14 Apr 2017 07:37:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=BWSFkyI6; dkim=pass (1024-bit key) header.d=yitter.info header.b=DWGQo3eX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dua47TRmiOQ for ; Fri, 14 Apr 2017 07:37:45 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19DF31300CF for ; Fri, 14 Apr 2017 07:37:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id C1A19BD996 for ; Fri, 14 Apr 2017 14:37:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1492180633; bh=g1G4tt6wlpJA/8+GzPeOtLjvvDRf+TybNk5ulYDKkz8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=BWSFkyI6X1kMtXKysuCDHgrG6jHzr5UEoOyLkfTdL9wE97jzxDHVBy9jfq4LTObHD 0iyR/y+MSzEiq5a08Svza+Z2Bhl1Vi/Hke0emqMwtjoRr7HXOYw7bK06P2oPcGT39W dCDc3zGOzQX3QXQ/nKsrpB8o/0J2hGeaVB3Ji47I= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UiR1IYcII-Y for ; Fri, 14 Apr 2017 14:37:12 +0000 (UTC) Date: Fri, 14 Apr 2017 10:37:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1492180631; bh=g1G4tt6wlpJA/8+GzPeOtLjvvDRf+TybNk5ulYDKkz8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=DWGQo3eXzHNy98z0kCo2k2dq8SPoxVJ/V23yh1z3QUifh2qpnhAxdDeVqX8Hx4qPA fF3pg45uVJWJo+np86MzNM61FY6zzOJUHUpulkMCURROhddNQ7V+ETRY5ac1BtMJQ2 xWcnaSc+T6FxHEB6jZ5EMg1JIPvK1HbkwePRSzuU= From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20170414143708.GD860@mx4.yitter.info> References: <87r30vomax.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87r30vomax.fsf@alrua-x1> Archived-At: Subject: Re: [homenet] A TOFU approach to naming things in the homenet (with code!) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 14:37:51 -0000 I really like this idea. Obviously, it's the sort of thing whose scope had better be pretty limited (e.g. you better know what network those TOFU requests are coming from), but apart from that it seems quite useful. A On Fri, Apr 14, 2017 at 02:38:46AM +0200, Toke Høiland-Jørgensen wrote: > Hey everyone > > While following the naming discussions, I have been thinking about how > to do one of the things that the current naming architecture draft > excludes: Allowing devices on the homenet to register in (public) DNS so > that one may find them. And since I also wanted to learn the Go > programming language, I decided to prototype something. Enter the > 'nsregd' daemon. > > This daemon will allow a client to claim a name on a Trust On First Use > (TOFU) basis using the RFC2136 dynamic DNS update protocol. A client > claims a name by sending a DNS update request with a SIG(0) (RFC2931) > signature and including the public key corresponding to the signature. > If the name in a claim is not already taken by another client, the > client's claim will be successful and the daemon will cache the public > key and use it to verify subsequent update requests. > > Once a name has been claimed by a client, that client can add and remove > A and AAAA records by means of regular DNS update requests signed with > the key used to claim the name. The daemon will forward these updates to > one or more configured upstream authoritative nameservers. > > I'm posting this here in the hope that others will find it useful, > either as input to the discussion, or as a tool to play around with. > > The code is available on Github: > > https://github.com/tohojo/nsregd > > The README file has a few more details on how it's supposed to work. > Comments very welcome, patches even more so :) > > > Cheers, > > -Toke > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Apr 14 08:05:50 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65F713012A for ; Fri, 14 Apr 2017 08:05:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2nfWA8bUfh-4 for ; Fri, 14 Apr 2017 08:05: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 67F50131440 for ; Fri, 14 Apr 2017 08:05:48 -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/56228) with ESMTP id v3EF5k7X008924; Fri, 14 Apr 2017 17:05:46 +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 4B1B1D798C; Fri, 14 Apr 2017 17:05:46 +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 qEM2logng4xv; Fri, 14 Apr 2017 17:05:45 +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 63DC2D79B2; Fri, 14 Apr 2017 17:05:44 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.88) (envelope-from ) id 1cz2nA-0007mI-3B; Fri, 14 Apr 2017 17:05:44 +0200 Date: Fri, 14 Apr 2017 17:05:44 +0200 Message-ID: <7i8tn3xc53.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: homenet@ietf.org In-Reply-To: <87h91rnkgc.fsf@alrua-x1> References: <87r30vomax.fsf@alrua-x1> <87r30v3xn5.wl-jch@irif.fr> <87h91rnkgc.fsf@alrua-x1> 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, 14 Apr 2017 17:05:46 +0200 (CEST) X-Miltered: at korolev with ID 58F0E54A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F0E54A.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 : 58F0E54A.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: Subject: Re: [homenet] A TOFU approach to naming things in the homenet (with code!) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 15:05:49 -0000 > In the current implementation, a single daemon per registration zone. Right. Either it could be elected by HNCP, or the daemons could run an election among themselves. > The client will query for a SRV at _nsreg._tcp. to find the > daemon, which can be anywhere, in principle (the daemon will only speak > TCP and limits initial registration to a list of configured subnets; I'm > currently running mine on a separate server rather than on my router). Makes sense. The list of prefixes could be configured by HNCP. > For the multi-homed homenet case, I suppose each uplink could have a > separate zone? Don't know. I suppose so. > I punted somewhat on how to discover the zone; the client will currently > take it as a command line parameter. But figure that can be distributed > via DHCP/RA? Or put it in DNS under dot-home? Since the client already knows how to speak DNS, this avoids yet another coupling between protocols. > In principle, there's nothing preventing the daemon state from being > replicated across the homenet routers, I suppose... I think it's more complicated and more fragile than having an election. I'm not too keen on adding another flooding protocol to the Homenet stack. -- Juliusz From nobody Fri Apr 14 14:41:59 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7B0129514 for ; Fri, 14 Apr 2017 14:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGUBc-p44uFL for ; Fri, 14 Apr 2017 14:41:57 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 3E315129AAC for ; Fri, 14 Apr 2017 14:41:52 -0700 (PDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1492206109; bh=dTGAT/YQ49tTNNpGAYKykkI99Pq/FekIxlM63HasZbY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=xomfYvEzYMTNNj4ILHCTugx6J5pDhcXeOMIvr2moSUZjPmfiridALr/BGsXfEcQkc 5RUFM2L/6ZY25AYLHX7NAAEZSrbsB2ARQYrngDseNR4M/On5/XwZX8u5fedgltaLIT yFZ8AltEaF7CgVOvYBbBF2tchUq/6KWw4P5UXeEBXt2+CMOZ2EQe0gVKFYEAeZ10Tk 5K/8qfOktjw3xSxZXrG0PclnF3xyhZhcZ2uOG5i3drY5lXh/u7HNlxcS9mtYDj67vI kmJSqCwUGo4lfWt2czViPmG0JjVkdnu5uMw10nIZfJLyj3opMrLGida0HCggCBdHau 9Y+aK9JPZN4wQ== To: Andrew Sullivan Cc: homenet@ietf.org References: <87r30vomax.fsf@alrua-x1> <20170414143708.GD860@mx4.yitter.info> Date: Fri, 14 Apr 2017 23:41:47 +0200 In-Reply-To: <20170414143708.GD860@mx4.yitter.info> (Andrew Sullivan's message of "Fri, 14 Apr 2017 10:37:09 -0400") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87d1ceoeec.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [homenet] A TOFU approach to naming things in the homenet (with code!) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 21:41:58 -0000 Andrew Sullivan writes: > I really like this idea. Thanks! > Obviously, it's the sort of thing whose scope had better be pretty > limited (e.g. you better know what network those TOFU requests are > coming from), but apart from that it seems quite useful. Yeah. The daemon will only allow new registrations from configured white-listed subnets (and only speaks TCP to avoid spoofing problems). Subsequent authenticated updates can optionally be allowed for any IP. -Toke From nobody Fri Apr 14 14:52:47 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE221294C9 for ; Fri, 14 Apr 2017 14:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRWfzQCltBWF for ; Fri, 14 Apr 2017 14:52:44 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45: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 88E32127077 for ; Fri, 14 Apr 2017 14:52:44 -0700 (PDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1492206762; bh=hTXnfKW9JgwZRveY68DoOZJSZOGwACV7Dg+u7+nOmtU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=M0giDWs2ztYQn4aztq1uvm4OUQsqNTtHQkjllVXRK3VO3nHScvRmVU2Nu6/iuVnnk gSUVj6/dysw4f/f159NDSmzuq5Uvf1O+vdbKMdzFU4V+4phTCaiLppbgVCt8z+uLFW fnhzFuzgAWGrlfPhaTpCHbyed34oM1A9eqn85VvDd745Ti5K5bwJH5jVjzRwUuoX2m yxkjrnoPqDGi4LqnbBJBNO4toVylFh1Rpx9yVVoBjEXPtsy5Fr8ij4ATq61kUty7sG n3eCmRugkPm5pkoi53h5dxVoYRg39iGhs3J2C3QDjzryO/evo9EuhQEpwlfGRTcWi5 uJkxGjsX0yNkA== To: Juliusz Chroboczek Cc: homenet@ietf.org References: <87r30vomax.fsf@alrua-x1> <87r30v3xn5.wl-jch@irif.fr> <87h91rnkgc.fsf@alrua-x1> <7i8tn3xc53.wl-jch@irif.fr> Date: Fri, 14 Apr 2017 23:52:40 +0200 In-Reply-To: <7i8tn3xc53.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Fri, 14 Apr 2017 17:05:44 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <878tn2odw7.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [homenet] A TOFU approach to naming things in the homenet (with code!) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 21:52:46 -0000 Juliusz Chroboczek writes: >> In the current implementation, a single daemon per registration zone. > > Right. Either it could be elected by HNCP, or the daemons could run an > election among themselves. Yeah, this makes sense if this mechanism is also used inside the homenet (to register under dot-home, say). For a globally visible zone (where you'd presumably only install globally routable addresses) the daemon could also be outside the homenet. >> The client will query for a SRV at _nsreg._tcp. to find the >> daemon, which can be anywhere, in principle (the daemon will only speak >> TCP and limits initial registration to a list of configured subnets; I'm >> currently running mine on a separate server rather than on my router). > > Makes sense. The list of prefixes could be configured by HNCP. Yup. >> I punted somewhat on how to discover the zone; the client will currently >> take it as a command line parameter. But figure that can be distributed >> via DHCP/RA? > > Or put it in DNS under dot-home? Since the client already knows how to > speak DNS, this avoids yet another coupling between protocols. Ah yes, that makes sense; since we have a domain that always refers to the homenet, just define a name under that that will return PTRs to the zones available for registration. >> In principle, there's nothing preventing the daemon state from being >> replicated across the homenet routers, I suppose... > > I think it's more complicated and more fragile than having an > election. I'm not too keen on adding another flooding protocol to the > Homenet stack. I said it's possible in principle. I didn't say it was a good idea... ;) -Toke From nobody Mon Apr 17 12:16:35 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375D5131797 for ; Mon, 17 Apr 2017 12:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSbZHouJIvRA for ; Mon, 17 Apr 2017 12:16:31 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 65FE013178C for ; Mon, 17 Apr 2017 12:16:31 -0700 (PDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1492456588; bh=6BD49++wU5V+1qX8/vQquwFB994IS9/yu3Mx2drR14A=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=o3/E4ombvmASFG9HLIPaf5Jnst2HlLu3p8+nLIIs9Vgs0F0PVNiDznWZ6DftL0xbZ 8zG5gHR503IzyZjPHK8h7NL47TSjGr713+9HQnG/0t6Exv/KjYYjFE7InfCLB9Ebpy YAUU+uYxGn7455vbDqooNaPaHWEY1QSurYkDuXAAIQ1OwMfNh19jVnGrwTAfu7Qzel cI8TkHdnE12f3zFjy08LJBOsGD0WD7L3WHajcooKtH8l6va/61FnREp7PGtb0xyrpx RQSnuIkTZEUr9CZgOMNkyjXuBcsDLwI/TWSbBDppn6V5KDW2MtL5UYElZSazCoOp4p YSx+W+rDRI7fA== To: Juliusz Chroboczek Cc: homenet@ietf.org References: <87r30vomax.fsf@alrua-x1> <87r30v3xn5.wl-jch@irif.fr> <87h91rnkgc.fsf@alrua-x1> <7i8tn3xc53.wl-jch@irif.fr> <878tn2odw7.fsf@alrua-x1> Date: Mon, 17 Apr 2017 21:16:28 +0200 In-Reply-To: <878tn2odw7.fsf@alrua-x1> ("Toke =?utf-8?Q?H=C3=B8iland-J?= =?utf-8?Q?=C3=B8rgensen=22's?= message of "Fri, 14 Apr 2017 23:52:40 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87bmruu9o3.fsf@alrua-karlstad> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [homenet] A TOFU approach to naming things in the homenet (with code!) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 19:16:33 -0000 Toke H=C3=B8iland-J=C3=B8rgensen writes: >> Or put it in DNS under dot-home? Since the client already knows how to >> speak DNS, this avoids yet another coupling between protocols. > > Ah yes, that makes sense; since we have a domain that always refers to > the homenet, just define a name under that that will return PTRs to the > zones available for registration. Hmm, turns out RFC6763 already defines a way to do this (in section 11). r._dns-sd._udp.. where is either the in-addr.arpa zone derived from the network address of a host address, or "local.". I guess I'll teach the nsregc client to resolve that... -Toke From nobody Mon Apr 17 12:34:08 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A52131794 for ; Mon, 17 Apr 2017 12:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLuTm6f6DBei for ; Mon, 17 Apr 2017 12:34:05 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 645AD128B8E for ; Mon, 17 Apr 2017 12:34:05 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id c45so108739561qtb.1 for ; Mon, 17 Apr 2017 12:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=uZWkuZgTE2hhhjVLOVzf7JaUnTDBrU4iGuHo+KKZfBM=; b=CEhilVBMVj013quwsZfZW+xpXy0vm/VOA/CTcuSB3wif4FhLlaBpyQkKw8u1ru+Rr7 mBmg6Hf7CNcSEWsYBONT0pa23Ye2PWuD2Y7MUo4B82eT+oqx903PVio25+chMtJiC2Ra Nr/Yd2Tx4WU0J/dxRpTXyz5d6vX+9n2/dPiMUYebylRVzyheXX4BEtEunHoWLhmcitvU h3LQnGoU2FmEZo1V2LXZe2511U9Wa2cW+H1iYIos7/UsZbgY9Y3snjiASex4B8lFC7Rr YGN6IBv/keQD1td9vqR4pxP1D+fAznLoKHOTCrydglKJQZRsCp+fBUGhscNKZV3C/lf2 g3fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=uZWkuZgTE2hhhjVLOVzf7JaUnTDBrU4iGuHo+KKZfBM=; b=Os0cmtDkDFCagDwrGs10sv1lRdfLXDck3o8WEoGKHePW5KD/VM9rDdDs9VrZ3gO8Gn Y/OsMByuJqS7ySB26cTYEQXQJaFdV1npJjkPfwT9oRtFhlgnDxuUjU4zp7/E18IGQFz6 1K0fbWM3VBxpyxwZyMmRVaE44tVg0SqOiOdLMwml36Ml7NIO+ORBjJeX4CfTHyWnifNu SI4Ddj16vk/jplRQBHXJb8brAJgGBMkYMtfeBtnnLjDJJzpQAhQ7a1kh12JWASCQmLGM 8xKmbp7gVgF1PKnJo3LzYEkfyzTTJniIOaEzR1TUvvRGNYDry1zVk6Wqr/tuE/f2yAxz CoYw== X-Gm-Message-State: AN3rC/6+nrocjYvnmT7AadCBHT5L6uiQrPCDVdp71bgR2YmaDxSBOK7S 30zOnJkn/Wm7qQ== X-Received: by 10.200.40.72 with SMTP id 8mr10217389qtr.204.1492457644613; Mon, 17 Apr 2017 12:34:04 -0700 (PDT) Received: from [10.0.20.202] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id a40sm7959559qka.14.2017.04.17.12.34.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 12:34:03 -0700 (PDT) From: Ted Lemon Message-Id: <0CD219A8-3A22-46A7-873B-D6B07C6C04C7@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3CDBBE2B-CF82-48C7-864A-1206B4C9C26C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 17 Apr 2017 15:34:02 -0400 In-Reply-To: <87bmruu9o3.fsf@alrua-karlstad> Cc: Juliusz Chroboczek , homenet@ietf.org To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <87r30vomax.fsf@alrua-x1> <87r30v3xn5.wl-jch@irif.fr> <87h91rnkgc.fsf@alrua-x1> <7i8tn3xc53.wl-jch@irif.fr> <878tn2odw7.fsf@alrua-x1> <87bmruu9o3.fsf@alrua-karlstad> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [homenet] A TOFU approach to naming things in the homenet (with code!) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 19:34:07 -0000 --Apple-Mail=_3CDBBE2B-CF82-48C7-864A-1206B4C9C26C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 17, 2017, at 3:16 PM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: > Hmm, turns out RFC6763 already defines a way to do this (in section = 11). > r._dns-sd._udp.. where is either the in-addr.arpa = zone > derived from the network address of a host address, or "local.". I = guess > I'll teach the nsregc client to resolve that... Cool! Sorry I didn't mention it earlier=E2=80=94haven't had a chance = to try the code yet. Thanks for GPLing it, BTW. --Apple-Mail=_3CDBBE2B-CF82-48C7-864A-1206B4C9C26C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 17, 2017, at 3:16 PM, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> = wrote:
Hmm, turns out = RFC6763 already defines a way to do this (in section 11).
r._dns-sd._udp.<domain>. where = <domain> is either the in-addr.arpa zone
derived from the network address of a host = address, or "local.". I guess
I'll teach the = nsregc client to resolve that...

Cool!   Sorry I didn't mention it = earlier=E2=80=94haven't had a chance to try the code yet.   Thanks = for GPLing it, BTW.

= --Apple-Mail=_3CDBBE2B-CF82-48C7-864A-1206B4C9C26C-- From nobody Thu Apr 20 06:52:12 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EADD13145D; Thu, 20 Apr 2017 06:52:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: homenet-chairs@ietf.org, homenet@ietf.org, ray@bellis.me.uk, terry.manderson@icann.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149269633054.22360.16456376005715758815.idtracker@ietfa.amsl.com> Date: Thu, 20 Apr 2017 06:52:10 -0700 Archived-At: Subject: [homenet] homenet - New Meeting Session Request for IETF 99 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 13:52:11 -0000 A new meeting session request has just been submitted by Ray Bellis, a Chair of the homenet working group. --------------------------------------------------------- Working Group Name: Home Networking Area Name: Internet Area Session Requester: Ray Bellis Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: v6ops intarea dnsop dnssd 6man babel Second Priority: mptcp People who must be present: Mark Townsley Terry Manderson Ray Bellis Resources Requested: Special Requests: Monday morning or immediately after lunch Monday strongly preferred as Ray has to be in the UK on Tuesday for his 25th wedding anniversary. Mark also has family commitments later in the week. --------------------------------------------------------- From nobody Thu Apr 20 07:10:21 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E57C7129573; Thu, 20 Apr 2017 07:10:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: homenet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149269741390.22330.17021208176055357469@ietfa.amsl.com> Date: Thu, 20 Apr 2017 07:10:13 -0700 Archived-At: Subject: [homenet] I-D Action: draft-ietf-homenet-dot-05.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 14:10:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking of the IETF. Title : Special Use Domain '.home.arpa' Authors : Pierre Pfister Ted Lemon Filename : draft-ietf-homenet-dot-05.txt Pages : 7 Date : 2017-04-20 Abstract: This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.', and designates this domain as a special-use domain name. The '.home.arpa' domain replaces '.home' as the default domain used by the Home Networking Control Protocol (HNCP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-homenet-dot-05 https://datatracker.ietf.org/doc/html/draft-ietf-homenet-dot-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dot-05 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 Thu Apr 20 14:16:47 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592E312E9A1 for ; Thu, 20 Apr 2017 14:16:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 G3aI1qiLjKhL for ; Thu, 20 Apr 2017 14:16:43 -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 93644129C70 for ; Thu, 20 Apr 2017 14:16:43 -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/56228) with ESMTP id v3KLGfq7016784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 20 Apr 2017 23:16:41 +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/56228) with ESMTP id v3KLGff2018362 for ; Thu, 20 Apr 2017 23:16:41 +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 123B8D7885 for ; Thu, 20 Apr 2017 23:16:41 +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 1rtTBwgPr0aA; Thu, 20 Apr 2017 23:16:39 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A2CCCD78E4; Thu, 20 Apr 2017 23:16:39 +0200 (CEST) Date: Thu, 20 Apr 2017 23:16:48 +0200 Message-ID: <8737d2kce7.wl-jch@irif.fr> From: Juliusz Chroboczek To: homenet@ietf.org CC: boutier@irif.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]); Thu, 20 Apr 2017 23:16:41 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 20 Apr 2017 23:16:41 +0200 (CEST) X-Miltered: at korolev with ID 58F92539.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58F92539.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58F92539.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58F92539.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 : 58F92539.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58F92539.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: Subject: [homenet] IPv4 source-specific routing in the Linux kernel X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 21:16:45 -0000 « Finally, Martin Kafai Lau asked if work should be done to merge the IPv4 and IPv6 FIB (forwarding information base) trees. The FIB tree is the data structure that represents routing tables in the Linux kernel. Miller explained that the two trees are not semantically equivalent: while IPv6 does source-address lookup and routing, IPv4 does not. We can't remove the source lookups from IPv6, because "people probably use that". According to Alexander Duyck, adding source tables to IPv4 would degrade performance to the level of IPv6 performance, which was jokingly referred to as an incentive to switch to IPv6. « More seriously, Sowa argued that using the same compressed tree IPv4 uses in IPv6 could make sense. People may want to have source routing in IPv4 as well. Miller argued that the kernel is optimized for 32-bit addresses in IPv4, and conceded that it could be scaled to 64-bit subnets, but 128-bit addresses would be much harder. Sowa suggested that they could be limited to 64 bits, as global routes that are announced over BGP usually have such a limit, and more specific routes are usually at discrete prefixes like /65, /127 (for interconnect links) or /128 for (for point-to-point links). He expressed concerns over the reliability of such an implementation so, at this point, it is unlikely that the data structures could be merged. What is more likely is that the code path could be merged and simplified, while keeping the data structures separate. » https://lwn.net/Articles/719297/ From nobody Mon Apr 24 08:09:35 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCF013160B for ; Mon, 24 Apr 2017 08:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxEbBWjXYlku for ; Mon, 24 Apr 2017 08:09:31 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 964531315ED for ; Mon, 24 Apr 2017 08:09:13 -0700 (PDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1493046547; bh=VnAMBz2Wow5xi3bwboHbJ4uWkNPVUQe5LEnzFZQJblM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=h4YsaNFxvspzdxdyBbzrWzWL8CtCqlkAcYL556AjgbS0/g29O7hd4pJ4n3iXESfB6 wJpoaAuxYWFskaQ0QnA2FJJgXJgwgThCrM04HXy8jvY66+hY9Y98FXpQxxJmIiJSXu i0AIrD463/iTpW4dbzmEgQ7iCnbZzQCIxR18Y4HfuqkYbKGgB2YNkN4apT2sAqLrMQ XPtV94VIMAi5t/rvwJvEiw2UCrbBKKRIwKoJocp83zHa34/J8tVl1NkY3bq0qIxFDs QxMteqCsSIr71Huz/iG3ZzDDsYxiITesBy3uEMAfmZDHWd3UXIBq+VhO1mCQLhn4OO 2s0CXY09KqpgA== To: Ted Lemon Cc: Juliusz Chroboczek , homenet@ietf.org References: <87r30vomax.fsf@alrua-x1> <87r30v3xn5.wl-jch@irif.fr> <87h91rnkgc.fsf@alrua-x1> <7i8tn3xc53.wl-jch@irif.fr> <878tn2odw7.fsf@alrua-x1> <87bmruu9o3.fsf@alrua-karlstad> <0CD219A8-3A22-46A7-873B-D6B07C6C04C7@fugue.com> Date: Mon, 24 Apr 2017 17:09:06 +0200 In-Reply-To: <0CD219A8-3A22-46A7-873B-D6B07C6C04C7@fugue.com> (Ted Lemon's message of "Mon, 17 Apr 2017 15:34:02 -0400") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87fugx267h.fsf@alrua-kau> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [homenet] A TOFU approach to naming things in the homenet (with code!) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 15:09:34 -0000 Ted Lemon writes: > On Apr 17, 2017, at 3:16 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Hmm, turns out RFC6763 already defines a way to do this (in section 11). > r._dns-sd._udp.. where is either the in-addr.arpa zone > derived from the network address of a host address, or "local.". I guess > I'll teach the nsregc client to resolve that... > > Cool! Sorry I didn't mention it earlier=E2=80=94haven't had a chance to= try > the code yet.=20 No worries. I added auto-discovery to the client, and improved configuration for both client and server (and the client will now run without any configuration with sensible defaults). The server also supports synthesising reverse PTR records now. Only thing missing now for my own use case is the ability to add local records to Unbound (for having a separate internal view while keeping private addresses out of the global DNS). > Thanks for GPLing it, BTW. You're welcome! The GPL is my default license :) -Toke From nobody Thu Apr 27 06:15:33 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F6F12704B for ; Thu, 27 Apr 2017 06:15:32 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 j0GyPs4ixVF1 for ; Thu, 27 Apr 2017 06:15:30 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9541200DF for ; Thu, 27 Apr 2017 06:15:30 -0700 (PDT) Received: from [46.227.151.81] (port=59593 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1d3jGZ-00083T-El (Exim 4.72) for homenet@ietf.org (return-path ); Thu, 27 Apr 2017 14:15:27 +0100 To: HOMENET From: Ray Bellis Message-ID: <10135536-eed8-5fa9-cf64-84219d8a4408@bellis.me.uk> Date: Thu, 27 Apr 2017 14:15:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [homenet] WGLC on draft-ietf-homenet-dot-05 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 13:15:32 -0000 This email starts a two week WGLC on draft-ietf-homenet-dot-05. Ted has updated this following Terry's ruling on ".homenet" to request ".home.arpa" instead. He has also incorporated other comments that came in after the last WGLC. Ray From nobody Thu Apr 27 07:19:14 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0749A128799 for ; Thu, 27 Apr 2017 07:19:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149330275202.3020.13197024041984055721.idtracker@ietfa.amsl.com> Date: Thu, 27 Apr 2017 07:19:12 -0700 From: IETF Secretariat Archived-At: Subject: [homenet] Milestones changed for homenet WG X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 14:19:12 -0000 Deleted milestone "Charter re-evaluation based on the architecture work". Changed milestone "First WG draft on prefix configuration", resolved as "Done". Changed milestone "First WG draft on routing", resolved as "Done". Changed milestone "First WG draft on name resolution", resolved as "Done". Changed milestone "First WG draft on service discovery", resolved as "Done". Changed milestone "Start of routing related work in the relevant routing area working group, if needed", resolved as "Done". Changed milestone "Submission of the prefix configuration draft to the IESG as Standards Track RFC", resolved as "Done - RFC 7695", added draft-ietf-homenet-prefix-assignment to milestone. Changed milestone "Submission of the routing draft to the IESG as Informational RFC", resolved as "Superceded", added draft-ietf-homenet-routing-consensus-call to milestone. Changed milestone "First WG draft on perimeter security", set due date to November 2017 from February 2012. Changed milestone "Submission of the name resolution draft to the IESG as Standards Track RFC", set due date to March 2018 from September 2012. Changed milestone "Submission of the service discovery draft to the IESG as Standards Track RFC", set due date to March 2018 from November 2012. Changed milestone "Submission of the perimeter security draft to the IESG as Informational RFC", set due date to November 2018 from December 2012. URL: https://datatracker.ietf.org/wg/homenet/about/ From nobody Fri Apr 28 08:55:46 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC1912773A for ; Fri, 28 Apr 2017 08:55:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ySA1pzJ42zXJ for ; Fri, 28 Apr 2017 08:55:41 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD14B12EAEE for ; Fri, 28 Apr 2017 08:52:22 -0700 (PDT) Received: from [46.227.151.81] (port=60448 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1d48Bu-00021j-Qb (Exim 4.72) for homenet@ietf.org (return-path ); Fri, 28 Apr 2017 16:52:18 +0100 To: HOMENET From: Ray Bellis Message-ID: <441b9bbe-c05b-8db3-6aac-01c5ffef5f6c@bellis.me.uk> Date: Fri, 28 Apr 2017 16:52:20 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [homenet] Mailing list for Homenet Babel Security design team X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 15:55:44 -0000 There is now a mailing list for the design team specifying the integration of HNCP and Babel security. The list address is homenet-babel-sec@ietf.org We have added those people that had initial discussions around this during IETF 97. Ray and Mark From nobody Sun Apr 30 17:07:55 2017 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2227F1200F1; Sun, 30 Apr 2017 17:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIvMn8kwGiMm; Sun, 30 Apr 2017 17:07:51 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B44A12947F; Sun, 30 Apr 2017 17:06:11 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id m36so82268621qtb.0; Sun, 30 Apr 2017 17:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8YklooIrXo7s2fMm9QH/74SyOMnBePlPD8Q/7ULgOR0=; b=jTJYk+ZuCHE6DJadr+J8KVu8fa/ZC0Srn8itG2t1ffNU+zFhKQjSX6sNtjdLRfkQeX ZG2EJCU9uouqndDHlduAxGywtmr+E0yRmvZOlQFu0lFW1TnTvPnIzieON2xUL+hqPWWE lSOUJgvMvRZMqXYZvOqT0soXcMJZI37G5FnhZZgLJ+fbd+VWOhA5xgBBC6z5yM1J8SNH 71Q/bojoamlp33QfFkhGxOTM7B6Y2yVVKo5SDPU70NkNHdagigZBbzLEqPeMlJ6GFKQw 90LduLJcb6jOODh2DPQ45DiMUdFxP9akWat14lI2Ut8X5A+Ylw9zwx9WO3/346uc0/Ak L5Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8YklooIrXo7s2fMm9QH/74SyOMnBePlPD8Q/7ULgOR0=; b=rx/8PU85/5gJPL2mlG1CLRupiMd12Ps3DCnFukyT90MKKeQyD3AA0sXpiAju7RauG/ zQE5GRwnVjEbr3KmIE/6jpVnWYBOys0cDJXooNFyyG7souLhfsNiP+DZIbOXaQQkPSQ7 189Y29xvnxNfnXhquTrx68kwpALWKGI7hiecCDVE8hLmFaoX5JWcrzxDKL83LJfuLts3 IyXBIVd4NmpAmUcCiwlXVqLwLYPsbJ4UOdNmIjt02xI7AJlBCsnQcv6/1EOXTl6anbVB /j98sf2KASo85QYpFFoirFG71qtwVHPcqhQG/LPwKHDLegykNW76ROkgiu411b2Ch8qA pLsg== X-Gm-Message-State: AN3rC/5vfXypfJXG21l/tkegLkeC8jKlo1/QuqnPSFnX02TN9Ay5KaWm KYpiH7rpKySHZqrSp/M= X-Received: by 10.237.33.188 with SMTP id l57mr19543533qtc.33.1493597169552; Sun, 30 Apr 2017 17:06:09 -0700 (PDT) Received: from ?IPv6:2601:181:c381:c20:a5c6:7b8a:6160:9b28? ([2601:181:c381:c20:a5c6:7b8a:6160:9b28]) by smtp.gmail.com with ESMTPSA id z42sm9330796qtb.26.2017.04.30.17.06.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 30 Apr 2017 17:06:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Suzanne Woolf In-Reply-To: <10135536-eed8-5fa9-cf64-84219d8a4408@bellis.me.uk> Date: Sun, 30 Apr 2017 20:06:06 -0400 Cc: draft-ietf-homenet-dot.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1418E84E-0A67-4E66-96DF-BECB21DE2176@gmail.com> References: <10135536-eed8-5fa9-cf64-84219d8a4408@bellis.me.uk> To: HOMENET X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [homenet] WGLC on draft-ietf-homenet-dot-05 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 00:07:54 -0000 Ray, > On Apr 27, 2017, at 9:15 AM, Ray Bellis wrote: >=20 > This email starts a two week WGLC on draft-ietf-homenet-dot-05. >=20 > Ted has updated this following Terry's ruling on ".homenet" to request > ".home.arpa" instead. He has also incorporated other comments that = came > in after the last WGLC. >=20 I think it=E2=80=99s time for this document to be finished, and this = version is close to ready. I support advancing it with the changes I=E2=80= =99m suggesting; the most substantive are: * some cleanup of lingering references to .home; * clarification of the authority for .home.arpa (citation of RFC 3172); * clarification of the rationale for an unsigned delegation in the = global DNS for a domain that=E2=80=99s not supposed to be resolvable in = the global context (Introduction and/or Security Considerations)=E2=80=94 = this will matter to DNS admins; * slight reworking of the rationale in the Introduction (dropping the = speculation on legal concerns and adding a couple of technical details) It=E2=80=99s also hard for me at this point to see the need for = draft-ietf-homenet-redact. Since this document is standards track and = updates RFC 7788, I=E2=80=99m not sure what=E2=80=99s actually added to = the protocol or to understanding of it by having a second update to it. = The necessary content of draft-ietf-homenet-redact seems to be mostly to = reinforce that =E2=80=9C.home=E2=80=9D as the default domain for homenet = names was specified only in error and that results from using it are = neither interoperable nor predictable. This could be covered in a couple = of sentences in homenet-dot. I=E2=80=99m including my full comments below=E2=80=94 the changes I=E2=80=99= m suggesting look larger than they are because I=E2=80=99ve tried to = include context for each. Suzanne =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sec. 1, Introduction 1. Existing text: "The '.home.arpa' domain replaces '.home' as the = default domain used by the Home Networking Control Protocol (HNCP)" There's an accepted erratum on this, since the "reservation" of .home = occurred without reference to the relevant registry, so it would be = helpful for anyone trying to understand why this document exists to = point that out. Suggested new text: "The '.home.arpa' domain corrects an error in = RFC7788, replacing '.home' as the default domain used by the Home = Networking Control Protocol (HNCP)." 2. "Also, ICANN has about a dozen applicants for the '.home' top-level = domain name, which creates a significant risk of litigation if it were = claimed by the IETF outside of that process." I don't think it's either necessary or useful to speculate in an IETF = standards-track technical document about either ICANN policy or = associated litigation risk. The technical reason (the risk of name = collision within the homenet or ISP environment) and the standards = process reason (the fact that RFC 7788 entirely sidestepped IETF = discussion of .home as a special use name for this purpose) are probably = adequate justification here. In addition, this text doesn't touch at all on the fact a delegation in = the global DNS is considered necessary for the default zone in order to = properly support DNSSEC, or the rationale for it, or the potential = difficulty of obtaining it in the root zone. Finally, it's unclear why a separate document is needed to support = redaction of ".home" from RFC 7788, when this document replaces it with = ".home.arpa." anyway. This document is standards track and already = updates RFC 7788. The sentence about existing applicants for .home could be simply = removed. Brief additional explanation about why a name in .arpa is = preferable to one in the root might also be helpful. Old text: "The '.home.arpa' domain replaces '.home' which was specified = in [RFC7788] as the default domain-name for home networks. '.home' had been selected as the most user-friendly option. However, there are existing uses of '.home' that may be in conflict with this use: evidence indicates that '.home' queries frequently leak out and reach the root name servers [ICANN1] [ICANN2]. Also, ICANN has about a dozen applicants for the '.home' top-level domain name, which creates a significant risk of litigation if it were claimed by the IETF outside of that process. As a result, the use of '.home' has been deprecated; this document updates [RFC7788] to replace '.home' with '.home.arpa', while another document, [I-D.ietf-homenet-redact] deprecates the use of the '.home' TLD. New text: "The '.home.arpa' domain replaces '.home' which was = specified in [RFC7788] as the default domain-name for home networks. Initially, = '.home' had been selected as the most user-friendly option. However, there are existing uses of '.home' that may be in conflict with this use: evidence indicates that '.home' queries frequently leak out and reach the root name servers [ICANN1] [ICANN2]. In addtion, it's desirable = that there should be a delegation for the homenet default domain name in the = global DNS, for compatibility with DNSSEC. There is an existing process, under = control of the IETF and the IAB, for creating such a delegation under .arpa = [RFC3172]. However, there is no such process for creating a name under the root = zone, which is not administered by the IETF, so creating such a process would = involve unknown costs in time and effort. As a result, the use of '.home' = has been deprecated. =20 This document updates [RFC7788] to replace '.home' with '.home.arpa', = while another document, [I-D.ietf-homenet-redact] deprecates the use of the '.home' TLD." 3. Existing text: "....DNS queries for names whose rightmost = non-terminal label is 'homenet'." Suggested new text: "....DNS queries for names whose rightmost = non-terminal labels are '.home.arpa'." Sec. 2, General Guidance 4. Existing text: "The domain name '.home.arpa.' is to be used for = naming within a home network.=E2=80=9D I looked for a handy reference = for describing what's a "home network=E2=80=9D; the closest I could find = was Sec. 3.7.3 of RFC 7368. 5. Existing text: "DNS queries for names ending with '.home.arpa.' are = resolved using local resolvers on the homenet." It might be helpful to = also note that they're not intended to be resolvable from outside the = homenet (relevant for some new text I think the "Security = Considerations" will need, see below). Sec. 3, Domain Name Reservation Considerations 6. Existing text: "...when serving queries for names ending with = '.home.arpa.'" This sounds odd, as the resolution process isn't usually called "serving = queries" Suggested new text: "....when responding to queries for names ending = with 'home.arpa'."=20 7. Existing text "Applications SHOULD treat domain names ending with = '.home.arpa.' just like any other FQDN, and MUST NOT make any assumption = on the level of additional security implied by its presence." Is the suggestion that the user or system might automatically place a = higher level of trust in "home.arpa" names than other FQDNs, which might = not be appropriate? If so, a sentence clarifying that would be helpful. 8. As a related observation, it would be appropriate to suggest local = "home.arpa" zones should be signed and resolvers should validate them, = particularly given the caution above about assuming too much about = security within the homenet. As the document stands, the reference to = DNSSEC as the reason for requiring a delegation in the global DNS for = .home.arpa stands pretty much alone and unmotivated. (This may belong = under =E2=80=9CSecurity Considerations.=E2=80=9D) 9. Existing text: "Unless configured otherwise, recursive resolvers and = DNS proxies MUST behave as described in Locally Served Zones ([RFC6303] = Section 3)." This text is mildly confusing, because I think it says "resolvers and = proxies must do this, unless they do something different." I'm guessing = it's supposed to mean "This is the expected behavior unless something = more useful is configured," but I'm not sure exactly how to say that. 10. Existing text: "Only a DNS server that is authoritative for the = '.arpa' zone or is configured to be authoritative for '.home.arpa' or a = subdomain of '.home.arpa' will ever answer a query about '.home.arpa.'" It might be wise to note that servers for .arpa will not actually know = about the local instance of .home.arpa, and a query to those servers for = information about the local .home.arpa zone will not produce useful = results. Thus, resolvers inside the homenet should avoid queries to = .arpa for names in home.arpa. (Resolvers outside the homenet will most = likely find the .arpa servers, and terminate the resolution process = there, which is also as it should be.) This isn't a special failing of .arpa or of being in an SLD; if the name = were ".homenet" instead, the same problem would occur: the parent = (whether it's the root or a TLD) is not in a position to know anything = about the local instance of an ambiguously-named child zone from a name = in the root. This is why the recursive resolver that the stub asks for = resolution services should be configured to be authoritative for the = home.arpa zone, including DNSSEC trust anchors. 11. Existing text: "'home.arpa' is a subdomain of the 'arpa' top-level = domain, which is entirely operated by the Internet Architecture Board." Actually, no; it's operated by IANA, under the administrative authority = of the IAB, which in turn is responsible under the rules established in = RFC 3172. This doesn't change the relevant policy of course, but allows = for a reference on why there's no need to worry about registrars. Suggested new text: "'home.arpa' is a subdomain of the 'arpa' top-level = domain, which is operated under the authority of the Internet = Architecture Board according to the rules established in RFC 3172. There = are no other registrars for .arpa." Sec. 4, Updates to Home Networking Control Protocol 12. Existing text: "Names for which the rightmost non-terminal label is = 'homenet' are resolved using the DNS protocol [RFC1035]." Suggested new text: "Names for which the rightmost two labels are = 'home.arpa' are resolved using the DNS protocol [RFC1035]." Sec. 5, Security Considerations 13. Existing text "....query ending with '.home.arpa.' is expected...." = is ambiguous. Suggested new text: "....query for an FQDN in the domain = '.home.arpa.' is expected...." 14. Existing text describing why the delegation needs to exist and not = be signed is not clear. This is a somewhat arcane topic, but DNS = administrators who have been told repeatedly for some years now that = they should use DNSSEC whenever possible will be puzzled by an apparent = directive that home.arpa not be signed. I suggest the document should have an additional paragraph describing = the resolution process in which it's helpful to have the global = delegation exist and be unsigned. The text that's there now ("The reason that this delegation must not be = signed is that not signing the delegation breaks the DNSSEC chain of = trust, which prevents a validating stub resolver from rejecting names = published under 'home.arpa' on a homenet name server.") isn't adequate = because it doesn't explain how this condition could possibly arise: if = the stub resolver is asking the global DNS for names published under = .arpa, it's because it hasn't asked a resolver that has locally = configured .home.arpa. It can't reject names it has no way to get in the = first place. If a stub resolver asks a local, recursive resolver for home.arpa names = and the resolver is configured to serve .home.arpa as a local zone, = authoritative data for the zone (signed or not) is available to the = stub. If the stub resolver asks a resolver that doesn't have .home.arpa = as a locally served zone, it will ask the root, but it's not clear what = happens to allow the stub to find locally relevant information in the = results of that attempt to resolve and validate the name in the global = context of the DNS. So it's not clear what sequence of resolution steps = results in a useful answer that's an unsigned NXDOMAIN. Sec. 9 "References" 15. RFC 3172 should be added as a reference to support the request for a = delegation in .arpa for .home.arpa.