From Ray.Bellis@nominet.org.uk Mon Jul 2 02:23:53 2012 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 2A73621F8BBD for ; Mon, 2 Jul 2012 02:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zfxg8dKJGpDF for ; Mon, 2 Jul 2012 02:23:52 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id D529021F8BBB for ; Mon, 2 Jul 2012 02:23:51 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: Content-Type:MIME-Version; b=1YcVQOqGotO1Q/9RzScxjAurjiwwFjH1b5CtgnC/WbSGNRTmxXue44Qz j1wA7DW7fzx+ilWxJYAmVisVxmPzNtj+1smwFAtQyBvRfbO7vEaJXL6ub +k5QX4Xfc0bA+/P; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1341221036; x=1372757036; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20-03=20comments?|Date:=20Mon,=202=20Jul=202012 =2009:23:54=20+0000|Message-ID:=20<7C3A02EA-4E5E-418A-BDA 9-9616B24167A0@nominet.org.uk>|To:=20"homenet@ietf.org=20 Group"=20|MIME-Version:=201.0; bh=nd+dOXnRL2FkY1q8DL1A3bDjI2gEfi7zJRwHPtIYqW0=; b=Qkwd7ApaLBOuatwsd/7nm1wS6hLTLB+DslYJNXrJ9pScz1VlGfPzg1yo KuSWGxqWEVD9z4IyAscFmVf1mG8URXca83Sst+D4+1zw32bEiiLvHssNk VMV0ewXTYnRkb9D; X-IronPort-AV: E=Sophos;i="4.77,509,1336345200"; d="asc'?scan'208";a="33917277" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 02 Jul 2012 10:23:55 +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%19]) with mapi; Mon, 2 Jul 2012 10:23:55 +0100 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: -03 comments? Thread-Index: AQHNWDRmPMqlwfIQFk2GJA97L+5l3g== Date: Mon, 2 Jul 2012 09:23:54 +0000 Message-ID: <7C3A02EA-4E5E-418A-BDA9-9616B24167A0@nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail=_49DCAD37-C08C-4868-92F5-D9F27AC1D516"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: [homenet] -03 comments? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 09:23:53 -0000 --Apple-Mail=_49DCAD37-C08C-4868-92F5-D9F27AC1D516 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In the heat of the discussion around Olafur's posting on "naming", it = may have escaped people's notice that Tim posted a -03 revision of our = core architecture draft late last week. We'd like to encourage you all to _thoroughly_ review and comment on = this document. I hope to see only one or two more significant revisions = before we can punt this to the IESG. thanks, Ray --Apple-Mail=_49DCAD37-C08C-4868-92F5-D9F27AC1D516 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAk/xaKoACgkQ+cr96znPxN5LdgCfZxUvyg62MwslbDQW/cCVnK0k AKoAnR33I9gPEBVI5JhwKVpX/fuCBbV+ =T8Vf -----END PGP SIGNATURE----- --Apple-Mail=_49DCAD37-C08C-4868-92F5-D9F27AC1D516-- From tjc@ecs.soton.ac.uk Mon Jul 2 03:44:04 2012 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 B1A3E21F8BF2 for ; Mon, 2 Jul 2012 03:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RrP0D7dJSXX for ; Mon, 2 Jul 2012 03:44:04 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id D61BF21F8A23 for ; Mon, 2 Jul 2012 03:44:03 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q62Ai5ZC018419 for ; Mon, 2 Jul 2012 11:44:05 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q62Ai5ZC018419 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1341225846; bh=ySyzo2p6m86cgjf4qIQz4wP+U+E=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=Qiy8YUiu4zPnnQEUNCKt4TPkrg8JHstww+eju160E/tideIEPUF41e0fXEG2S9eVW RpKC2GNhNk00dX1IOihHIbsgIMdTr80N7DnHNRd7QNnXHSIifFp1kT+9HYq6e7BnxX 9WbW42sKrp4iozZXObIRmE10UPyThlInetgyKQXY= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP id o61Bi50544108474Pv ret-id none; Mon, 02 Jul 2012 11:44:05 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q62Ai02m017398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 2 Jul 2012 11:44:00 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Tim Chown In-Reply-To: <7C3A02EA-4E5E-418A-BDA9-9616B24167A0@nominet.org.uk> Date: Mon, 2 Jul 2012 11:43:59 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <7C3A02EA-4E5E-418A-BDA9-9616B24167A0@nominet.org.uk> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1278) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o61Bi5054410847400; tid=o61Bi50544108474Pv; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q62Ai5ZC018419 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] -03 comments? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 10:44:04 -0000 On 2 Jul 2012, at 10:23, Ray Bellis wrote: > In the heat of the discussion around Olafur's posting on "naming", it = may have escaped people's notice that Tim posted a -03 revision of our = core architecture draft late last week. >=20 > We'd like to encourage you all to _thoroughly_ review and comment on = this document. I hope to see only one or two more significant revisions = before we can punt this to the IESG. Thanks Ray, There is a changelog against -02 in the appendix. The main style = difference is that the bulleted points introduced in -02 have been = removed in -03 through chair guidance. The aim is to push out a -04 before Vancouver, integrating the naming/SD = material from the current list discussion. There's also one or two = other comments to catch up on, e.g. about pushing stuff from 2.5 on = borders into section 3 where we talk about the network model. Tim= From mglt.ietf@gmail.com Tue Jul 3 03:11:48 2012 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 68BFC21F87F8 for ; Tue, 3 Jul 2012 03:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BRp0RfmTzMe for ; Tue, 3 Jul 2012 03:11:47 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA7D21F87EE for ; Tue, 3 Jul 2012 03:11:47 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5628185ghb.31 for ; Tue, 03 Jul 2012 03:11: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:cc:content-type; bh=zN2jI3vtXCCZNBJWZWJ7vWiV/lIGqTLEZ8VVxbZbOEo=; b=T5GbZ3LDrNjYjIe6Z0rU9Od1qcnmV4y1Lzlu9fHgNp1ol46jsuvWceY8FpDHiOfJVx vwF0zLgrUk5P9TA+L5DK1sUTbmBRpxnNfGvXOZ6YilCLf8stRHuoythZ2+s2nrkeZ/v1 LXtWVvf1YcH8XzvwTpUEJBXoyK2dtg7B0Es/c39Ps5EQ83uvrDvdM/etKvQuWWtyFMI3 RF9Iu9iMTiOl86uJEYFK/HMKfk3YBFJ5r+SSBviGAFYvEHBfxLWJRjx8MmgHu34VYo5k /5eh6MicknUaW5EbYnLIOw2hACm92CdBv7wTWHxq19V8ePkWh27k+nn408x66SEC7atp GoRg== MIME-Version: 1.0 Received: by 10.43.2.6 with SMTP id ns6mr8198732icb.54.1341310314147; Tue, 03 Jul 2012 03:11:54 -0700 (PDT) Received: by 10.231.219.138 with HTTP; Tue, 3 Jul 2012 03:11:54 -0700 (PDT) Date: Tue, 3 Jul 2012 12:11:54 +0200 Message-ID: From: Daniel Migault To: homenet@ietf.org Content-Type: multipart/alternative; boundary=bcaec50fe015ceef2a04c3ea2419 Cc: Wouter Cloetens , philippe.lemordant@orange.com Subject: [homenet] Delegating Naming Architectures X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 10:11:48 -0000 --bcaec50fe015ceef2a04c3ea2419 Content-Type: text/plain; charset=ISO-8859-1 Hi, Please find two Naming Architectures we would like to discuss at Vancouver: - "IPv6 Home Network Naming Delegation Architecture" http://www.ietf.org/internet-drafts/draft-mglt-naming-delegation-00.txt - "Home Network Front End Naming Delegation" http://www.ietf.org/internet-drafts/draft-mglt-front-end-naming-delegation-00.txt Comments and suggestions are welcome. Best Regards Daniel Abstract: "IPv6 Home Network Naming Delegation Architecture" This document describes the Naming Delegation Architecture that makes IPv6 Home Network globally reachable with Names or Fully Qualified Domain Names (FQDN). In this architecture, the Customer Premise Equipment (CPE) acts as the DNS Authoritative Server of the Home Network also called the Delegated DNS Server. The Naming Delegation is configured between the Delegated DNS Server and the Delegating DNS Server managed by the ISP. The use case considered in this document is an End User that subscribes its ISP a specific Delegated Domain for its Home Network. This document describes how the CPE automatically sets the Naming Delegation between the Delegating and Delegated DNS Server. The Naming Delegation is requested by the CPE. The CPE DHCP Client and the ISP DHCP Server exchange DHCP Options to properly set the Naming Delegation. More specifically, the CPE DHCP Client (resp. the ISP DHCP Server) configures the DNS(SEC) Zones of the Delegated DNS Server (resp. Delegating DNS Server). For the Delegating DNS Server, the necessary pieces of information required to set the Naming Delegation are the IP address of the Delegated DNS Server, and if DNSSEC is used, the Delegation of Signing Information. For the Delegated DNS Server, the necessary information is the Delegated Domain associated to the Home Network. Abstract: "Home Network Front End Naming Delegation" This document proposes a Naming Delegation Architecture that makes possible End Users to reach the hosts or services of their Home Network using Names instead of IP addresses. This document shows how the Naming Delegation between the CPE and the ISP can be set so the CPE is not exposed on the Internet. This document describes an Naming Architecture where ISPs provide Front End Delegating DNS Servers whereas the CPEs constitute a Back End Network of Delegated DNS Servers. All DNS queries for any Home Network are addressed to the Delegating Front End Server. The response is expected to be stored on a CPE, and the Front End Delegating DNS Server sends a DNS Query to that CPE before answering to the initial DNS query. The negotiation between the CPE and the ISP is using DHCP Options. This document provides options so Front End Delegating and the Delegated DNS Servers configure their respective Zone files and so that CPEs restrict access and protect themselves from unauthorized DNS Queries. -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --bcaec50fe015ceef2a04c3ea2419 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
Hi,

Please find two Naming Architectures we would like to discu=
ss at Vancouver:
    - "IPv6 Home Network Naming Delegation Archite=
cture"  http://www.ietf.org/i=
nternet-drafts/draft-mglt-naming-delegation-00.txt

    - "Home Network Front End Naming Delegation" http://www.ietf.org/internet-drafts/draf=
t-mglt-front-end-naming-delegation-00.txt


Comments and suggestions are welcome.

Best Regards

Daniel=



Abstract: "IPv6 Home Network Naming Delegation =
Architecture"

   This document describes the Naming Delegation Architecture that makes
   IPv6 Home Network globally reachable with Names or Fully Qualified
   Domain Names (FQDN).  In this architecture, the Customer Premise
   Equipment (CPE) acts as the DNS Authoritative Server of the Home
   Network also called the Delegated DNS Server.  The Naming Delegation
   is configured between the Delegated DNS Server and the Delegating DNS
   Server managed by the ISP.

   The use case considered in this document is an End User that
   subscribes its ISP a specific Delegated Domain for its Home Network.
   This document describes how the CPE automatically sets the Naming
   Delegation between the Delegating and Delegated DNS Server.

   The Naming Delegation is requested by the CPE.  The CPE DHCP Client
   and the ISP DHCP Server exchange DHCP Options to properly set the
   Naming Delegation.  More specifically, the CPE DHCP Client (resp. the
   ISP DHCP Server) configures the DNS(SEC) Zones of the Delegated DNS
   Server (resp. Delegating DNS Server).  For the Delegating DNS Server,
   the necessary pieces of information required to set the Naming
   Delegation are the IP address of the Delegated DNS Server, and if
   DNSSEC is used, the Delegation of Signing Information.  For the
   Delegated DNS Server, the necessary information is the Delegated
   Domain associated to the Home Network.

Abstract: "Hom=
e Network Front End Naming Delegation"

   This document proposes a Naming Delegation Architecture that makes
   possible End Users to reach the hosts or services of their Home
   Network using Names instead of IP addresses.

   This document shows how the Naming Delegation between the CPE and the
   ISP can be set so the CPE is not exposed on the Internet.  This
   document describes an Naming Architecture where ISPs provide Front
   End Delegating DNS Servers whereas the CPEs constitute a Back End
   Network of Delegated DNS Servers.  All DNS queries for any Home
   Network are addressed to the Delegating Front End Server.  The
   response is expected to be stored on a CPE, and the Front End
   Delegating DNS Server sends a DNS Query to that CPE before answering
   to the initial DNS query.

   The negotiation between the CPE and the ISP is using DHCP Options.
   This document provides options so Front End Delegating and the
   Delegated DNS Servers configure their respective Zone files and so
   that CPEs restrict access and protect themselves from unauthorized
   DNS Queries.


--
Daniel Migault
Orange Labs -- Security
+33 6 70 = 72 69 58
--bcaec50fe015ceef2a04c3ea2419-- From each@isc.org Tue Jul 3 15:45:00 2012 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 EA8FF11E8095 for ; Tue, 3 Jul 2012 15:45:00 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTy35a9c0qP9 for ; Tue, 3 Jul 2012 15:45:00 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id AB6B521F872A for ; Tue, 3 Jul 2012 15:44:59 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id EA30CC959A; Tue, 3 Jul 2012 22:45:01 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 59628216C36; Tue, 3 Jul 2012 22:44:56 +0000 (UTC) Date: Tue, 3 Jul 2012 22:44:56 +0000 From: Evan Hunt To: Curtis Villamizar Message-ID: <20120703224456.GA59827@isc.org> References: <4FEDF39D.8060909@mtcc.com> <201207010227.q612Rhhm036301@gateway.ipv6.occnc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201207010227.q612Rhhm036301@gateway.ipv6.occnc.com> User-Agent: Mutt/1.4.2.3i Cc: homenet@ietf.org, Michael Thomas , Ralph Droms , Olafur Gudmundsson Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 22:45:01 -0000 +1 to everything Curtis said here. I will amplify one point: DNSSEC trust anchors can be configured when shipped (and are in fact included in every BIND 9 release, though they're not trusted unless you say so in named.conf). The only trust anchor you really need is the key for the root zone, and optionally for a DNSSEC Lookaside Validation zone such as dlv.isc.org, and both of these can keep themselves up to date using RFC 5011 trust anchor management. Depending on how things are set up on your network, you might want to have your system automatically generate a key for .local or .lan or whatever you call the private namespace, but that shouldn't be necessary in most cases. This is fiddly, but it's not hard -- my ISCwrt router at home meets more-or-less all of these needs using BIND 9 and ISC DHCP. On Sat, Jun 30, 2012 at 10:27:43PM -0400, Curtis Villamizar wrote: > I'm not sure that some of the respondents later in this thread > understand what DNS can do already with no changes. > > 1. An important domain that is visible to the outside world can also > remain available even if the Internet is not available. > > Local hosts which use DHCP can be told to query a local DNS cache. > That DNS cache can be a DNS secondary (or primary) to your > enterprise's domain, or a local domain. As a primary, it never > expires. As a DNS secondary it can continue to serve DNS queries > for the domain when the Internet is unavailable until the zone > file expires (typically days). > > Example: In every well run enterprise today, the local DNS caches > are DNS primary or DNS secondary for the local domain. > > 2. A local domain can be either visible to the Internet or not > visible. It is also possible to provide different results locally > and to the Internet. > > You can create a .local domain that can't be reached except by > > The NS record available to the outside world can point to a > different nameserver than the set of nameservers for that same > domain that are used internally. This gets annoying for remote > users when switching the enterprise VPN on and off, but otherwise > it works just fine. [btw- An alternate that avoids the VPN issue > is to create site specific subdomains that are not visible to the > outside world.] > > Example: Most enterprises reuse their domain internally, serving > up their name resolutions to private addresses, but only provide > the name resolution for the hosts with global addresses to the > outside world. > > 3. Devices can already register their own host name to IP address > mapping. > > Dynamic DNS is far from a new concept. A DHCP client can provide > its own host name when retrieving an address. The DHCP server can > be coupled to a DNS cache which adds the forward (and optionally > reverse) DNS mappings to the appropriate zones until the DHCP > lease expires. > > Example: ISC dhcpd and ISC bind can be coupled in this way. [Not > intended as an endorsement. No doubt many others can as well.] > > Others have suggested DNSSEC. That may conflict with the zero > configuration goal unless a trust anchor is supplied at shipment time. > Zero configuration and the existing cert hierarchy seem to me to be > conflicting goals, but I'd be open to being told otherwise. > > The "zero configuration" goal implies that the default configuration > for the homenet router in isolation (no other routers discovered) must > be to serve as a DNS cache, offer a .local domain, and add an entry > into the .local domain for any DHCP lease allocated. If other homenet > routers are discovered, then some form of election is needed to figure > out a DNS primary for the .local domain. > > One could argue that the homenet router could also get a proper domain > name from the provider, but most providers will give their domain name > in response to DHCP queries. If the provider is know to provide a > useful domain name, then trusting the domain offerred by the provider > can be a simple configuration override. > > Simple configuration could substitute a real domain name for the > .local default name. Whether to supress providing local mappings to > external queries could also be a simple configuration knob. > > We need a extremely strong motivation to reinvent the wheel on > something as fundamental as name resolution. I don't see that we have > any unmet requirement that can't be solved using DNS as the basis. I > admit that we can't use any of the existing freely available DNS > server software (that I am aware of) because it does not do anything > useful in the absense of configuration and configuration is overly > complex for homenet use. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From mark@townsley.net Fri Jul 6 08:33:37 2012 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 23F9021F85A0 for ; Fri, 6 Jul 2012 08:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKwDvCSdoWrG for ; Fri, 6 Jul 2012 08:33:36 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABE121F85A5 for ; Fri, 6 Jul 2012 08:33:35 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so790604wgb.1 for ; Fri, 06 Jul 2012 08:33:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=GUZcxJ8N757HvN+GDnt4NpJYuJOWLQofqv+5OV/W8pk=; b=er3wZegyIkgyBsuaV7St9jATYA10wOeo16OEn/2o/Or9GEfEBZLZcK+dtUj9fq2oDu +EocUynbnVdfv3LRdtHYvly0g5h3wD7DqzE8n2nzJARDltX0dg2hdNxqIOu2/tXYW7l5 x2TNqvGdfQIV1pnHZ3FWnp6gLWNqITtMX/hLjt2nPaxZB6walYV0sFWydes6xMoDDuXY 1sSFVLNfwighXSRSXIvzlM1IOguqhVYGwSxNPfKTwFNdkhTac9h8ToJNtu+ORM5B5mZz xvCEUcCOhJmf7d3rGll1/Mah2fllpOu+hQlNO6lU7jOmsq/vCOla3/jGRFh+5oEx6t2u GTLw== Received: by 10.180.81.165 with SMTP id b5mr8654203wiy.17.1341588831556; Fri, 06 Jul 2012 08:33:51 -0700 (PDT) Received: from marks-mac-mini.home (AMontsouris-159-1-27-10.w90-46.abo.wanadoo.fr. [90.46.234.10]) by mx.google.com with ESMTPS id fw4sm6268642wib.0.2012.07.06.08.33.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jul 2012 08:33:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_003AD458-A153-482A-8D6D-A4ABBE0423B0" From: Mark Townsley In-Reply-To: Date: Fri, 6 Jul 2012 17:33:45 +0200 Message-Id: <5CF2DFF8-DB46-4295-A2E8-6792CF60F434@townsley.net> References: To: Daniel Migault X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQneNppQn6tLqEH5mYhxNHsYwJei2cNAU0jdDTQgsfa5X7nF+i9tIy6TZcYZfLDHhxs+KtJL Cc: homenet@ietf.org, Wouter Cloetens , philippe.lemordant@orange.com Subject: Re: [homenet] Delegating Naming Architectures X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 15:33:37 -0000 --Apple-Mail=_003AD458-A153-482A-8D6D-A4ABBE0423B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Daniel,=20 Just a bit of housekeeping... If you intend for these drafts to be = considered by homenet, it's much easier for everyone if "homenet" is = somewhere in the filename of the draft. Please consider resubmitting, if = that is your intention.=20 Thank you, - Mark On Jul 3, 2012, at 12:11 PM, Daniel Migault wrote: > Hi, >=20 > Please find two Naming Architectures we would like to discuss at = Vancouver: > - "IPv6 Home Network Naming Delegation Architecture" = http://www.ietf.org/internet-drafts/draft-mglt-naming-delegation-00.txt >=20 > - "Home Network Front End Naming Delegation" = http://www.ietf.org/internet-drafts/draft-mglt-front-end-naming-delegation= -00.txt >=20 >=20 > Comments and suggestions are welcome. >=20 > Best Regards >=20 > Daniel >=20 >=20 > Abstract: "IPv6 Home Network Naming Delegation Architecture" >=20 > This document describes the Naming Delegation Architecture that = makes > IPv6 Home Network globally reachable with Names or Fully Qualified > Domain Names (FQDN). In this architecture, the Customer Premise > Equipment (CPE) acts as the DNS Authoritative Server of the Home > Network also called the Delegated DNS Server. The Naming = Delegation > is configured between the Delegated DNS Server and the Delegating = DNS > Server managed by the ISP. >=20 > The use case considered in this document is an End User that > subscribes its ISP a specific Delegated Domain for its Home = Network. > This document describes how the CPE automatically sets the Naming > Delegation between the Delegating and Delegated DNS Server. >=20 > The Naming Delegation is requested by the CPE. The CPE DHCP Client > and the ISP DHCP Server exchange DHCP Options to properly set the > Naming Delegation. More specifically, the CPE DHCP Client (resp. = the > ISP DHCP Server) configures the DNS(SEC) Zones of the Delegated DNS > Server (resp. Delegating DNS Server). For the Delegating DNS = Server, > the necessary pieces of information required to set the Naming > Delegation are the IP address of the Delegated DNS Server, and if > DNSSEC is used, the Delegation of Signing Information. For the > Delegated DNS Server, the necessary information is the Delegated > Domain associated to the Home Network. >=20 > Abstract: "Home Network Front End Naming Delegation" >=20 > This document proposes a Naming Delegation Architecture that makes > possible End Users to reach the hosts or services of their Home > Network using Names instead of IP addresses. >=20 > This document shows how the Naming Delegation between the CPE and = the > ISP can be set so the CPE is not exposed on the Internet. This > document describes an Naming Architecture where ISPs provide Front > End Delegating DNS Servers whereas the CPEs constitute a Back End > Network of Delegated DNS Servers. All DNS queries for any Home > Network are addressed to the Delegating Front End Server. The > response is expected to be stored on a CPE, and the Front End > Delegating DNS Server sends a DNS Query to that CPE before = answering > to the initial DNS query. >=20 > The negotiation between the CPE and the ISP is using DHCP Options. > This document provides options so Front End Delegating and the > Delegated DNS Servers configure their respective Zone files and so > that CPEs restrict access and protect themselves from unauthorized > DNS Queries. >=20 >=20 > --=20 > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail=_003AD458-A153-482A-8D6D-A4ABBE0423B0 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1

Daniel, 

Just a bit of housekeeping... If you intend for these drafts to be considered by homenet, it's much easier for everyone if "homenet" is somewhere in the filename of the draft. Please consider resubmitting, if that is your intention. 

Thank you,

- Mark

On Jul 3, 2012, at 12:11 PM, Daniel Migault wrote:

Hi,

Please find two Naming Architectures we would like to discuss at Vancouver:
    - "IPv6 Home Network Naming Delegation Architecture"  http://www.ietf.org/internet-drafts/draft-mglt-naming-delegation-00.txt

    - "Home Network Front End Naming Delegation" http://www.ietf.org/internet-drafts/draft-mglt-front-end-naming-delegation-00.txt


Comments and suggestions are welcome.

Best Regards

Daniel


Abstract: "IPv6 Home Network Naming Delegation Architecture"

   This document describes the Naming Delegation Architecture that makes
   IPv6 Home Network globally reachable with Names or Fully Qualified
   Domain Names (FQDN).  In this architecture, the Customer Premise
   Equipment (CPE) acts as the DNS Authoritative Server of the Home
   Network also called the Delegated DNS Server.  The Naming Delegation
   is configured between the Delegated DNS Server and the Delegating DNS
   Server managed by the ISP.

   The use case considered in this document is an End User that
   subscribes its ISP a specific Delegated Domain for its Home Network.
   This document describes how the CPE automatically sets the Naming
   Delegation between the Delegating and Delegated DNS Server.

   The Naming Delegation is requested by the CPE.  The CPE DHCP Client
   and the ISP DHCP Server exchange DHCP Options to properly set the
   Naming Delegation.  More specifically, the CPE DHCP Client (resp. the
   ISP DHCP Server) configures the DNS(SEC) Zones of the Delegated DNS
   Server (resp. Delegating DNS Server).  For the Delegating DNS Server,
   the necessary pieces of information required to set the Naming
   Delegation are the IP address of the Delegated DNS Server, and if
   DNSSEC is used, the Delegation of Signing Information.  For the
   Delegated DNS Server, the necessary information is the Delegated
   Domain associated to the Home Network.

Abstract: "Home Network Front End Naming Delegation"

   This document proposes a Naming Delegation Architecture that makes
   possible End Users to reach the hosts or services of their Home
   Network using Names instead of IP addresses.

   This document shows how the Naming Delegation between the CPE and the
   ISP can be set so the CPE is not exposed on the Internet.  This
   document describes an Naming Architecture where ISPs provide Front
   End Delegating DNS Servers whereas the CPEs constitute a Back End
   Network of Delegated DNS Servers.  All DNS queries for any Home
   Network are addressed to the Delegating Front End Server.  The
   response is expected to be stored on a CPE, and the Front End
   Delegating DNS Server sends a DNS Query to that CPE before answering
   to the initial DNS query.

   The negotiation between the CPE and the ISP is using DHCP Options.
   This document provides options so Front End Delegating and the
   Delegated DNS Servers configure their respective Zone files and so
   that CPEs restrict access and protect themselves from unauthorized
   DNS Queries.


--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

--Apple-Mail=_003AD458-A153-482A-8D6D-A4ABBE0423B0-- From Efrain.Fino@videotron.com Fri Jul 6 13:06:09 2012 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 B810911E80CB for ; Fri, 6 Jul 2012 13:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XnbExH+nM1g for ; Fri, 6 Jul 2012 13:06:09 -0700 (PDT) Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB8211E80C2 for ; Fri, 6 Jul 2012 13:06:09 -0700 (PDT) Auto-Submitted: auto-generated From: Efrain.Fino@videotron.com To: homenet@ietf.org Message-ID: Date: Fri, 6 Jul 2012 16:06:14 -0400 X-MIMETrack: Serialize by Router on DOMSMTP01/SRV/Videotron(Release 8.5.3FP1|March 07, 2012) at 2012-07-06 16:06:16 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Received-SPF: none Subject: [homenet] Efrain Fino est absent(e) / is out of the office X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 20:06:09 -0000 Je serai absent(e) du 2012-07-05 au 2012-07-16. I will be out of the office from July 5th returning on July 16th. From curtis@occnc.com Sun Jul 8 21:21:31 2012 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 83A8721F880B for ; Sun, 8 Jul 2012 21:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWpeFSiuvTVd for ; Sun, 8 Jul 2012 21:21:18 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 491E721F8817 for ; Sun, 8 Jul 2012 21:21:13 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q694Glub059426; Sun, 8 Jul 2012 21:17:03 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201207090417.q694Glub059426@gateway.ipv6.occnc.com> To: Evan Hunt From: Curtis Villamizar In-reply-to: Your message of "Tue, 03 Jul 2012 22:44:56 -0000." <20120703224456.GA59827@isc.org> Date: Mon, 09 Jul 2012 00:16:37 -0400 Cc: homenet@ietf.org, Michael Thomas , Ralph Droms , Olafur Gudmundsson , Curtis Villamizar Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 04:21:31 -0000 Evan, Just one point: > The only trust anchor you really need is the key for the root zone If the local network is going to work in the absense of connection to the Internet (even permanent lack of Internet connectivity as in a low power homenet with nothing but local devices powered on - home alarm, thermostats, etc), then a local trust anchor is needed as well. BTW- The Bind9 ARM gives an example with trusted-keys configured. The dnssec-lookaside statement is not well documents, but might also be useful. Curtis In message <20120703224456.GA59827@isc.org> Evan Hunt writes: +1 to everything Curtis said here. I will amplify one point: DNSSEC trust anchors can be configured when shipped (and are in fact included in every BIND 9 release, though they're not trusted unless you say so in named.conf). The only trust anchor you really need is the key for the root zone, and optionally for a DNSSEC Lookaside Validation zone such as dlv.isc.org, and both of these can keep themselves up to date using RFC 5011 trust anchor management. Depending on how things are set up on your network, you might want to have your system automatically generate a key for .local or .lan or whatever you call the private namespace, but that shouldn't be necessary in most cases. This is fiddly, but it's not hard -- my ISCwrt router at home meets more-or-less all of these needs using BIND 9 and ISC DHCP. On Sat, Jun 30, 2012 at 10:27:43PM -0400, Curtis Villamizar wrote: > I'm not sure that some of the respondents later in this thread > understand what DNS can do already with no changes. > > 1. An important domain that is visible to the outside world can also > remain available even if the Internet is not available. > > Local hosts which use DHCP can be told to query a local DNS cache. > That DNS cache can be a DNS secondary (or primary) to your > enterprise's domain, or a local domain. As a primary, it never > expires. As a DNS secondary it can continue to serve DNS queries > for the domain when the Internet is unavailable until the zone > file expires (typically days). > > Example: In every well run enterprise today, the local DNS caches > are DNS primary or DNS secondary for the local domain. > > 2. A local domain can be either visible to the Internet or not > visible. It is also possible to provide different results locally > and to the Internet. > > You can create a .local domain that can't be reached except by > > The NS record available to the outside world can point to a > different nameserver than the set of nameservers for that same > domain that are used internally. This gets annoying for remote > users when switching the enterprise VPN on and off, but otherwise > it works just fine. [btw- An alternate that avoids the VPN issue > is to create site specific subdomains that are not visible to the > outside world.] > > Example: Most enterprises reuse their domain internally, serving > up their name resolutions to private addresses, but only provide > the name resolution for the hosts with global addresses to the > outside world. > > 3. Devices can already register their own host name to IP address > mapping. > > Dynamic DNS is far from a new concept. A DHCP client can provide > its own host name when retrieving an address. The DHCP server can > be coupled to a DNS cache which adds the forward (and optionally > reverse) DNS mappings to the appropriate zones until the DHCP > lease expires. > > Example: ISC dhcpd and ISC bind can be coupled in this way. [Not > intended as an endorsement. No doubt many others can as well.] > > Others have suggested DNSSEC. That may conflict with the zero > configuration goal unless a trust anchor is supplied at shipment time. > Zero configuration and the existing cert hierarchy seem to me to be > conflicting goals, but I'd be open to being told otherwise. > > The "zero configuration" goal implies that the default configuration > for the homenet router in isolation (no other routers discovered) must > be to serve as a DNS cache, offer a .local domain, and add an entry > into the .local domain for any DHCP lease allocated. If other homenet > routers are discovered, then some form of election is needed to figure > out a DNS primary for the .local domain. > > One could argue that the homenet router could also get a proper domain > name from the provider, but most providers will give their domain name > in response to DHCP queries. If the provider is know to provide a > useful domain name, then trusting the domain offerred by the provider > can be a simple configuration override. > > Simple configuration could substitute a real domain name for the > .local default name. Whether to supress providing local mappings to > external queries could also be a simple configuration knob. > > We need a extremely strong motivation to reinvent the wheel on > something as fundamental as name resolution. I don't see that we have > any unmet requirement that can't be solved using DNS as the basis. I > admit that we can't use any of the existing freely available DNS > server software (that I am aware of) because it does not do anything > useful in the absense of configuration and configuration is overly > complex for homenet use. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From jari.arkko@piuha.net Mon Jul 9 03:32:02 2012 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 143B321F8649 for ; Mon, 9 Jul 2012 03:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.734 X-Spam-Level: X-Spam-Status: No, score=-102.734 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7uLIgvf0AvQ for ; Mon, 9 Jul 2012 03:32:01 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC8521F863D for ; Mon, 9 Jul 2012 03:32:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D11EF2CC5D; Mon, 9 Jul 2012 13:32:21 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2K2a4IcEYdm; Mon, 9 Jul 2012 13:32:21 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 111A02CC44; Mon, 9 Jul 2012 13:32:21 +0300 (EEST) Message-ID: <4FFAB334.9070407@piuha.net> Date: Mon, 09 Jul 2012 13:32:20 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <201207090417.q694Glub059426@gateway.ipv6.occnc.com> In-Reply-To: <201207090417.q694Glub059426@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Benjamin Paterson \(bpaterso\)" , Acee Lindem Subject: [homenet] new version of the OSPFv3-based prefix assignment draft X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 10:32:02 -0000 Hi, We've submitted a new version of our OSPFv3-based prefix assignment draft. This version adds quite a bit of detail to the algorithm, describes ULA prefix generation, etc. Here's the link: http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-02 Comments appreciated. Jari From swmike@swm.pp.se Mon Jul 9 04:30:20 2012 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 EF2B821F85F1 for ; Mon, 9 Jul 2012 04:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBEEPo5aBHbW for ; Mon, 9 Jul 2012 04:30:20 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 58B4C21F85E6 for ; Mon, 9 Jul 2012 04:30:20 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CD3389E; Mon, 9 Jul 2012 13:30:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A19BE9C; Mon, 9 Jul 2012 13:30:42 +0200 (CEST) Date: Mon, 9 Jul 2012 13:30:42 +0200 (CEST) From: Mikael Abrahamsson To: Jari Arkko In-Reply-To: <4FFAB334.9070407@piuha.net> Message-ID: References: <201207090417.q694Glub059426@gateway.ipv6.occnc.com> <4FFAB334.9070407@piuha.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Benjamin Paterson \(bpaterso\)" , homenet@ietf.org, Acee Lindem Subject: Re: [homenet] new version of the OSPFv3-based prefix assignment draft X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 11:30:21 -0000 On Mon, 9 Jul 2012, Jari Arkko wrote: > Hi, > > We've submitted a new version of our OSPFv3-based prefix assignment draft. > This version adds quite a bit of detail to the algorithm, describes ULA > prefix generation, etc. > > Here's the link: > > http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-02 > > Comments appreciated. Hi, I haven't really read up what has been discussed historically here, so please have patience in case I am rehashing what has already been discussed. >From reading the text it is not clear to me exactly what deployment scenario the text is meant to handle. Some ascii drawings might help? I've been pondering how to solve a few different problems for deployment, for instance the problem of the customer having a CPE with a live DHCPv6-PD prefix, unplugging it by means of power-off, and then putting in another CPE. If only a single prefix is allowed on the link, then the customer would have to wait until the PD lease expires until the new CPE can get one (the same problem exists for IPv4 as well, in case only a single IPv4 address is allowed and the customer just powers off the CPE without doing DHCP RELEASE first). I've been considering allowing 4 concurrent PD prefixes, for instance the customer has a statically configured /56 as PD pool, a /64 on-link (which is not from the /56 space), and then handing out /58 with PD from the customer-unique /56. This would mean that the deployment scenario might in worse case look like this: ISP handoff switch/router |/64 -----customer switch---------------- | | | | | | CPE1 CPE2 CPE3 CPE4 PC1 PC2 /58PD /58PD /58PD /58PD | | |---| L2 CPE5 CPE6 CPE7 | | | | PC3 PC4 PC5 PC6 This is in a ETTH scenario, or could also be over for instance DSL where the modem is a bridged L2 handoff. To solve the "power off" problem, I guess it might work with a /57 per CPE as well, and hope the customer long term only wants to have a single CPE. Are CPE1-4 going to talk OSPFv3 between them on the link there according to the draft, or is this just for the CPE3/CPE6/CPE7 shared segment? -- Mikael Abrahamsson email: swmike@swm.pp.se From acee.lindem@ericsson.com Mon Jul 9 07:21:15 2012 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 6896511E8085 for ; Mon, 9 Jul 2012 07:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKnju2980-f2 for ; Mon, 9 Jul 2012 07:21:14 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 53D3011E8079 for ; Mon, 9 Jul 2012 07:21:14 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q69ELbXh030524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Jul 2012 09:21:38 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.205]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 9 Jul 2012 10:21:37 -0400 From: Acee Lindem To: Mikael Abrahamsson Date: Mon, 9 Jul 2012 10:21:34 -0400 Thread-Topic: [homenet] new version of the OSPFv3-based prefix assignment draft Thread-Index: Ac1d3iYnNcQyeaWYTJ6z5dfqCedxRw== Message-ID: <5E36EBF9-8161-4422-89EA-441B7781F7BA@ericsson.com> References: <201207090417.q694Glub059426@gateway.ipv6.occnc.com> <4FFAB334.9070407@piuha.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-50-611758390"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "Benjamin Paterson \(bpaterso\)" , "homenet@ietf.org" , Jari Arkko Subject: Re: [homenet] new version of the OSPFv3-based prefix assignment draft X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 14:21:15 -0000 --Apple-Mail-50-611758390 Content-Type: multipart/alternative; boundary=Apple-Mail-49-611758372 --Apple-Mail-49-611758372 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Mikael, See inline. On Jul 9, 2012, at 7:30 AM, Mikael Abrahamsson wrote: > On Mon, 9 Jul 2012, Jari Arkko wrote: >=20 >> Hi, >>=20 >> We've submitted a new version of our OSPFv3-based prefix assignment = draft.=20 >> This version adds quite a bit of detail to the algorithm, describes = ULA=20 >> prefix generation, etc. >>=20 >> Here's the link: >>=20 >> http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-02 >>=20 >> Comments appreciated. >=20 > Hi, >=20 > I haven't really read up what has been discussed historically here, so=20= > please have patience in case I am rehashing what has already been=20 > discussed. >=20 > =46rom reading the text it is not clear to me exactly what deployment=20= > scenario the text is meant to handle. Some ascii drawings might help? = I've=20 > been pondering how to solve a few different problems for deployment, = for=20 > instance the problem of the customer having a CPE with a live = DHCPv6-PD=20 > prefix, unplugging it by means of power-off, and then putting in = another=20 > CPE. If only a single prefix is allowed on the link, then the customer=20= > would have to wait until the PD lease expires until the new CPE can = get=20 > one (the same problem exists for IPv4 as well, in case only a single = IPv4=20 > address is allowed and the customer just powers off the CPE without = doing=20 > DHCP RELEASE first). >=20 > I've been considering allowing 4 concurrent PD prefixes, for instance = the=20 > customer has a statically configured /56 as PD pool, a /64 on-link = (which=20 > is not from the /56 space), and then handing out /58 with PD from the=20= > customer-unique /56. This would mean that the deployment scenario = might in=20 > worse case look like this: >=20 > ISP handoff switch/router > |/64 > -----customer switch---------------- > | | | | | | > CPE1 CPE2 CPE3 CPE4 PC1 PC2 > /58PD /58PD /58PD /58PD > | | |---| > L2 CPE5 CPE6 CPE7 > | | | | > PC3 PC4 PC5 PC6 >=20 > This is in a ETTH scenario, or could also be over for instance DSL = where=20 > the modem is a bridged L2 handoff. To solve the "power off" problem, I=20= > guess it might work with a /57 per CPE as well, and hope the customer = long=20 > term only wants to have a single CPE. >=20 > Are CPE1-4 going to talk OSPFv3 between them on the link there = according=20 > to the draft, or is this just for the CPE3/CPE6/CPE7 shared segment? Normally, an auto-configured OSPFv3 CPE will not run OSPFv3 on the link = toward the ISP. However, the auto-detection is not standardized.=20 Excerpted =46rom the OSPFv3 auto-configration draft: 2. OSPFv3 SHOULD be auto-configured on for IPv6 on all interfaces intended as general IPv6-capable routers. Optionally, an interface MAY be excluded if it is clear that running OSPFv3 on the interface is not required. For example, if manual configuration or an other condition indicates that an interface is connected to an Internet Service Provider (ISP), there is typically no need to employ OSPv3. However, note that in many environments it can be useful to test whether an OSPFv3 adjacency can be established. In home networking environments, an interface where no OSPFv3 neighbors are found but a DHCP prefix can be acquired may be considered as an ISP interface. Thanks, Acee >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail-49-611758372 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Mikael,
See inline.

On Jul 9, 2012, at 7:30 = AM, Mikael Abrahamsson wrote:

On = Mon, 9 Jul 2012, Jari Arkko wrote:

Hi,

We've submitted = a new version of our OSPFv3-based prefix assignment draft. =
This version adds quite a bit = of detail to the algorithm, describes ULA
prefix generation, etc.

Here's the = link:

http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-02=

Comments appreciated.

Hi,

I = haven't really read up what has been discussed historically here, so =
please have patience in case I am rehashing what has already been =
discussed.

=46rom reading the text it is not clear to me = exactly what deployment
scenario the text is meant to handle. Some = ascii drawings might help? I've
been pondering how to solve a few = different problems for deployment, for
instance the problem of the = customer having a CPE with a live DHCPv6-PD
prefix, unplugging it by = means of power-off, and then putting in another
CPE. If only a = single prefix is allowed on the link, then the customer
would have = to wait until the PD lease expires until the new CPE can get
one = (the same problem exists for IPv4 as well, in case only a single IPv4 =
address is allowed and the customer just powers off the CPE without = doing
DHCP RELEASE first).

I've been considering allowing 4 = concurrent PD prefixes, for instance the
customer has a statically = configured /56 as PD pool, a /64 on-link (which
is not from the /56 = space), and then handing out /58 with PD from the
customer-unique = /56. This would mean that the deployment scenario might in
worse = case look like this:

ISP handoff switch/router
=           |/64
=   -----customer switch----------------
  | =      |      | =         | =      |   |
 CPE1  CPE2 =   CPE3      CPE4 =    PC1 PC2
 /58PD /58PD  /58PD =     /58PD
  | =      |      |---|
=  L2    CPE5   CPE6 CPE7
  | =      |      | =   |
 PC3    PC4   PC5 =  PC6

This is in a ETTH scenario, or could also be over for = instance DSL where
the modem is a bridged L2 handoff. To solve the = "power off" problem, I
guess it might work with a /57 per CPE as = well, and hope the customer long
term only wants to have a single = CPE.

Are CPE1-4 going to talk OSPFv3 between them on the link = there according
to the draft, or is this just for the CPE3/CPE6/CPE7 = shared segment?

Normally, an = auto-configured OSPFv3 CPE will not run OSPFv3 on the link toward the = ISP. However, the auto-detection is not = standardized. 
Excerpted =46rom the OSPFv3 = auto-configration draft:

  = 2.  OSPFv3 SHOULD be auto-configured on for IPv6 on all = interfaces
       intended as = general IPv6-capable routers.  Optionally, = an
       interface MAY be excluded = if it is clear that running OSPFv3 on
    =    the interface is not required.  For example, if = manual
       configuration or an = other condition indicates that an interface
  =      is connected to an Internet Service Provider (ISP), = there is
       typically no need = to employ OSPv3.  However, note that in = many
       environments it can be = useful to test whether an OSPFv3 adjacency
  =      can be established.  In home networking = environments, an
       interface = where no OSPFv3 neighbors are found but a DHCP = prefix
       can be acquired may = be considered as an ISP = interface.



Tha= nks,
Acee




--
Mikael Abrahamsson =    email: swmike@swm.pp.se
_________________= ______________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.= org/mailman/listinfo/homenet

= = --Apple-Mail-49-611758372-- --Apple-Mail-50-611758390 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcwOTE0MjEzNVowIwYJKoZI hvcNAQkEMRYEFJsFKtVglxBzgFPHZuNTKuh0TGD3MFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgDNYf2ddmBTn0XV/RTKr7qVEieDJbqTwVLfXmh2KrfWhESgi1AfQsYjR9NkIwYqD 8000eNP8qt3z1Y8fXGbEB97wZ7WDsV8oHgHDrhxtyx4CFqy1p6yhbMP8LlC36gqm9nSdNZR2NGzo i9rShrrm7w6Scv3TaOfddXBuDrnkYWZgAAAAAAAA --Apple-Mail-50-611758390-- From swmike@swm.pp.se Mon Jul 9 09:01:43 2012 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 0BD5111E80D2 for ; Mon, 9 Jul 2012 09:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XU-SuxAR5r7 for ; Mon, 9 Jul 2012 09:01:42 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 6803311E80B3 for ; Mon, 9 Jul 2012 09:01:42 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id EB8239C; Mon, 9 Jul 2012 18:02:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E6DDF9A; Mon, 9 Jul 2012 18:02:06 +0200 (CEST) Date: Mon, 9 Jul 2012 18:02:06 +0200 (CEST) From: Mikael Abrahamsson To: Michael Richardson In-Reply-To: <28790.1341846114@herring.sandelman.ottawa.on.ca> Message-ID: References: <201207090417.q694Glub059426@gateway.ipv6.occnc.com> <4FFAB334.9070407@piuha.net> <28790.1341846114@herring.sandelman.ottawa.on.ca> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: homenet@ietf.org Subject: Re: [homenet] new version of the OSPFv3-based prefix assignment draft X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 16:01:43 -0000 On Mon, 9 Jul 2012, Michael Richardson wrote: > I'm wondering if you can describe your case, which you write as ETTH. > The deployments that I've done to date, ETTH has either been GPON (so we > have a CPE device just like cable), or we the customer comes in > aggregated on a VLAN, so in fact the switch at the data centre annotates > the DHCP request when it relays it. When you say "annotates", do you mean "option 82"? In that case, yes, this is done here as well, but if the customer powers off their device, the DHCP lease is not invalidated. Deployment cases are ETTH as in "L2 switch in the basement connecting the customer apartment" and DSL as in "L2 dslam and L2 bridging modem" (or modem doing "hybrid", ie IRB). In neither case the DHCP lease is invalidated when the customer access link goes down. -- Mikael Abrahamsson email: swmike@swm.pp.se From each@isc.org Mon Jul 9 09:49:12 2012 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 848D521F86DC for ; Mon, 9 Jul 2012 09:49:12 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDNYb3MmGMzY for ; Mon, 9 Jul 2012 09:49:12 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id E2E1E21F86D1 for ; Mon, 9 Jul 2012 09:49:11 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 0E4235F9917; Mon, 9 Jul 2012 16:49:23 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 37F7E216C3B; Mon, 9 Jul 2012 16:49:21 +0000 (UTC) Date: Mon, 9 Jul 2012 16:49:21 +0000 From: Evan Hunt To: Curtis Villamizar Message-ID: <20120709164921.GC97192@isc.org> References: <20120703224456.GA59827@isc.org> <201207090417.q694Glub059426@gateway.ipv6.occnc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201207090417.q694Glub059426@gateway.ipv6.occnc.com> User-Agent: Mutt/1.4.2.3i Cc: homenet@ietf.org, Michael Thomas , Ralph Droms , Olafur Gudmundsson Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 16:49:12 -0000 > If the local network is going to work in the absense of connection to > the Internet (even permanent lack of Internet connectivity as in a low > power homenet with nothing but local devices powered on - home alarm, > thermostats, etc), then a local trust anchor is needed as well. Maybe, not necessarily. If the validating resolver and the authoritative name server are separate entities, then yes; the resolver will need a trust anchor to believe what the authority server says. If they're the same box, though, then it can answer authoritatively for names in ".local" and recursively for everything else, and it would only bother with validation on the recursive answers. (That's how BIND 9 works, anyway; I'm not particularly knowledgable about other DNS software.) -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From swmike@swm.pp.se Mon Jul 9 09:54:34 2012 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 D613B21F87BD for ; Mon, 9 Jul 2012 09:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNg+WxRwwcqb for ; Mon, 9 Jul 2012 09:54:31 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 3130921F8805 for ; Mon, 9 Jul 2012 09:54:26 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CB7F29C; Mon, 9 Jul 2012 18:54:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C5A7A9A; Mon, 9 Jul 2012 18:54:45 +0200 (CEST) Date: Mon, 9 Jul 2012 18:54:45 +0200 (CEST) From: Mikael Abrahamsson To: Michael Richardson In-Reply-To: <30699.1341850091@herring.sandelman.ottawa.on.ca> Message-ID: References: <201207090417.q694Glub059426@gateway.ipv6.occnc.com> <4FFAB334.9070407@piuha.net> <28790.1341846114@herring.sandelman.ottawa.on.ca> <30699.1341850091@herring.sandelman.ottawa.on.ca> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: homenet@ietf.org Subject: Re: [homenet] new version of the OSPFv3-based prefix assignment draft X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 16:54:34 -0000 On Mon, 9 Jul 2012, Michael Richardson wrote: > Yes, but the option 82 may let one find the right lease to reuse. I have not seen this used in real life (as it involves invalidating existing lease and tell existing lease owner about it). Do you have any references to implementations of this behaviour? -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Mon Jul 9 09:55:39 2012 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 87C7F21F87FD for ; Mon, 9 Jul 2012 09:55:39 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYb6109W5QoO for ; Mon, 9 Jul 2012 09:55:38 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id B6B9021F87DF for ; Mon, 9 Jul 2012 09:55:38 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8C9079C; Mon, 9 Jul 2012 18:56:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7E6139A; Mon, 9 Jul 2012 18:56:03 +0200 (CEST) Date: Mon, 9 Jul 2012 18:56:03 +0200 (CEST) From: Mikael Abrahamsson To: Acee Lindem In-Reply-To: <5E36EBF9-8161-4422-89EA-441B7781F7BA@ericsson.com> Message-ID: References: <201207090417.q694Glub059426@gateway.ipv6.occnc.com> <4FFAB334.9070407@piuha.net> <5E36EBF9-8161-4422-89EA-441B7781F7BA@ericsson.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Benjamin Paterson \(bpaterso\)" , "homenet@ietf.org" , Jari Arkko Subject: Re: [homenet] new version of the OSPFv3-based prefix assignment draft X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 16:55:39 -0000 On Mon, 9 Jul 2012, Acee Lindem wrote: > Normally, an auto-configured OSPFv3 CPE will not run OSPFv3 on the link toward the ISP. However, the auto-detection is not standardized. > Excerpted From the OSPFv3 auto-configration draft: > > 2. OSPFv3 SHOULD be auto-configured on for IPv6 on all interfaces > intended as general IPv6-capable routers. Optionally, an > interface MAY be excluded if it is clear that running OSPFv3 on > the interface is not required. For example, if manual > configuration or an other condition indicates that an interface > is connected to an Internet Service Provider (ISP), there is > typically no need to employ OSPv3. However, note that in many > environments it can be useful to test whether an OSPFv3 adjacency > can be established. In home networking environments, an > interface where no OSPFv3 neighbors are found but a DHCP prefix > can be acquired may be considered as an ISP interface. Ok, sounds good, sounds like it would do what I want. PS. There is a typo approx halfway in, text says "OSPv3", not "OSPFv3". -- Mikael Abrahamsson email: swmike@swm.pp.se From curtis@occnc.com Mon Jul 9 18:16:42 2012 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 8DBFC11E80C5 for ; Mon, 9 Jul 2012 18:16:42 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rWqIrTesm+h for ; Mon, 9 Jul 2012 18:16:42 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id C623611E80B8 for ; Mon, 9 Jul 2012 18:16:41 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q6A1GuAv092989; Mon, 9 Jul 2012 18:16:56 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201207100116.q6A1GuAv092989@gateway.ipv6.occnc.com> To: Evan Hunt From: Curtis Villamizar In-reply-to: Your message of "Mon, 09 Jul 2012 16:49:21 -0000." <20120709164921.GC97192@isc.org> Date: Mon, 09 Jul 2012 21:16:56 -0400 Cc: homenet@ietf.org, Michael Thomas , Ralph Droms , Olafur Gudmundsson , Curtis Villamizar Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 01:16:42 -0000 In message <20120709164921.GC97192@isc.org> Evan Hunt writes: > > If the local network is going to work in the absense of connection to > > the Internet (even permanent lack of Internet connectivity as in a low > > power homenet with nothing but local devices powered on - home alarm, > > thermostats, etc), then a local trust anchor is needed as well. > > Maybe, not necessarily. > > If the validating resolver and the authoritative name server are separate > entities, then yes; the resolver will need a trust anchor to believe what > the authority server says. > > If they're the same box, though, then it can answer authoritatively for > names in ".local" and recursively for everything else, and it would only > bother with validation on the recursive answers. (That's how BIND 9 works, > anyway; I'm not particularly knowledgable about other DNS software.) A local trust anchor is needed for the isolated network with more than one router. This is true for address allocation and routing if they are authenticated (they should be IMHO), and for dnssec if used. Curtis From each@isc.org Mon Jul 9 19:59:31 2012 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 3147B11E80D5 for ; Mon, 9 Jul 2012 19:59:31 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OJXx9nSBN+p for ; Mon, 9 Jul 2012 19:59:30 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id BF62411E80A1 for ; Mon, 9 Jul 2012 19:59:30 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id EF355C9463; Tue, 10 Jul 2012 02:59:51 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id DF824216C3B; Tue, 10 Jul 2012 02:59:44 +0000 (UTC) Date: Tue, 10 Jul 2012 02:59:44 +0000 From: Evan Hunt To: Curtis Villamizar Message-ID: <20120710025944.GA12479@isc.org> References: <20120709164921.GC97192@isc.org> <201207100116.q6A1GuAv092989@gateway.ipv6.occnc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201207100116.q6A1GuAv092989@gateway.ipv6.occnc.com> User-Agent: Mutt/1.4.2.3i Cc: homenet@ietf.org, Michael Thomas , Ralph Droms , Olafur Gudmundsson Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 02:59:31 -0000 > A local trust anchor is needed for the isolated network with more than > one router. Agreed there. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From mike@mtcc.com Tue Jul 10 07:36:51 2012 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 E43CF21F8797 for ; Tue, 10 Jul 2012 07:36:51 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biY4yGAy5Bmj for ; Tue, 10 Jul 2012 07:36:51 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 534BE21F8673 for ; Tue, 10 Jul 2012 07:36:51 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6AEbFfw005565 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 10 Jul 2012 07:37:16 -0700 Message-ID: <4FFC3E1B.80004@mtcc.com> Date: Tue, 10 Jul 2012 07:37:15 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Evan Hunt References: <20120709164921.GC97192@isc.org> <201207100116.q6A1GuAv092989@gateway.ipv6.occnc.com> <20120710025944.GA12479@isc.org> In-Reply-To: <20120710025944.GA12479@isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=859; t=1341931037; x=1342795037; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Name=20service=20design=20p rinciples=3A=20a=20proposal |Sender:=20 |To:=20Evan=20Hunt=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=/9TmMeL9VvHjYBlVZF737RzmltTNqN8WJ1mMBoINEVE=; b=SKLuysuLpKC5uZNErP+4X+o7G9OszBWcXafDWeQ818heGEwL1Bep9S5KH+ KxgKdhKD51dOeOb5U5YthokqyONSY0agkahNSPgnqxVLCuTchWe3WnH9cGTn Dp7fZtZ07jjDBfG2Ue5Fw7YbatmjUFk19bOoeNtBqZQNO9wPX5wdI=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: homenet@ietf.org, Ralph Droms , Olafur Gudmundsson , Curtis Villamizar Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 14:36:52 -0000 On 07/09/2012 07:59 PM, Evan Hunt wrote: >> A local trust anchor is needed for the isolated network with more than >> one router. > Agreed there. > Ok, here's my ignorance. If we want a local DNSsec trust anchor -- which seems like a reasonable want -- how do those root keys get into each client host? And what happens if I visit my neighbor's homenet with my phone, does that imply that I have to enroll with his root keys? And what happens if I can see more than one homenet domain and I use multiple interfaces, say, depending on WIFI strength. Do I enroll in both? Do I use both? Isn't there the implication that I'd want to use each namespace? As in what does it mean to have washer.local and dryer.local when we both have a washer.local and dryer.local in our respective namespaces? Mike, this is not entirely academic for me... From stokcons@xs4all.nl Tue Jul 10 07:38:37 2012 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 0C2B121F86B5 for ; Tue, 10 Jul 2012 07:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.154 X-Spam-Level: X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2kQR5A5xKFL for ; Tue, 10 Jul 2012 07:38:36 -0700 (PDT) Received: from smtp-vbr14.xs4all.nl (smtp-vbr14.xs4all.nl [194.109.24.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3F84421F85E4 for ; Tue, 10 Jul 2012 07:38:36 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube5.xs4all.net [194.109.20.203]) by smtp-vbr14.xs4all.nl (8.13.8/8.13.8) with ESMTP id q6AEcWf4095463 for ; Tue, 10 Jul 2012 16:38:33 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-556-1-257-67.w90-0.abo.wanadoo.fr ([90.0.105.67]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 10 Jul 2012 16:38:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 10 Jul 2012 16:38:32 +0200 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: Message-ID: <2d90555a1067c2d124d16bc14c6d430b@xs4all.nl> X-Sender: stokcons@xs4all.nl (1tuoTYOhtC5w25fq7D36Pn7ipQcYFa0q) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [homenet] Fwd: New Version Notification for draft-vanderstok-core-dna-02.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 14:38:37 -0000 Dear working group, A draft on discovery, naming and addressing has been submitted to the core working group. This information is distributed to the homenet wg given the interest for the subject in this wg Greetings, peter A new version of I-D, draft-vanderstok-core-dna-02.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. Filename: draft-vanderstok-core-dna Revision: 02 Title: CoRE Discovery, Naming, and Addressing Creation date: 2012-07-10 WG ID: Individual Submission Number of pages: 30 URL: http://www.ietf.org/internet-drafts/draft-vanderstok-core-dna-02.txt Status: http://datatracker.ietf.org/doc/draft-vanderstok-core-dna Htmlized: http://tools.ietf.org/html/draft-vanderstok-core-dna-02 Diff: http://tools.ietf.org/rfcdiff?url2=draft-vanderstok-core-dna-02 Abstract: This is a working document intended to focus discussion and refine draft language for the CoAP protocol specification (or other proposed standards) in the areas of discovery, naming, and addressing. Requirements on discovery are motivated. Special emphasis is placed on group definition and discovery. Examples show how groups can be represented in CoAP Resource Directories or DNS-SD. From mike@mtcc.com Tue Jul 10 09:18:22 2012 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 17EE121F85FF for ; Tue, 10 Jul 2012 09:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nN7TfNM847l for ; Tue, 10 Jul 2012 09:18:21 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 3E63121F8644 for ; Tue, 10 Jul 2012 09:18:21 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6AGIj9Y012315 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 10 Jul 2012 09:18:46 -0700 Message-ID: <4FFC55E5.5030706@mtcc.com> Date: Tue, 10 Jul 2012 09:18:45 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Michael Richardson References: <20120709164921.GC97192@isc.org> <201207100116.q6A1GuAv092989@gateway.ipv6.occnc.com> <20120710025944.GA12479@isc.org> <4FFC3E1B.80004@mtcc.com> <16808.1341933293@herring.sandelman.ottawa.on.ca> In-Reply-To: <16808.1341933293@herring.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2218; t=1341937126; x=1342801126; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Name=20service=20design=20p rinciples=3A=20a=20proposal |Sender:=20 |To:=20Michael=20Richardson=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=yUXJWoAbc+xHPMGnEPcnwVgmeJwlCXTE4aZ7yOWVGFY=; b=WBFuXL41kZqGQ5J0MSjlL3jjZWiST1F1W4KlIVLoKe2eHP+hB2RbVdgZj4 Ab0Y4D6RMNovAVE0hP6yPhCD4mlOHkISH9XDxjOGe0oh7TOLIvv3NYJraTEl fo6JnMOlwygJGi5MpslyCkvNE3WVd6G73ZMx3nEmx6xjH4M2RVadw=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: homenet@ietf.org Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 16:18:22 -0000 On 07/10/2012 08:14 AM, Michael Richardson wrote: > > >>> A local trust anchor is needed for the isolated network with > >>> more than one router. > > >> Agreed there. > > Michael> Ok, here's my ignorance. If we want a local DNSsec trust > Michael> anchor -- which seems like a reasonable want -- how do > Michael> those root keys get into each client host? And what happens > Michael> if I visit my neighbor's homenet with my phone, does that > Michael> imply that I have to enroll with his root keys? > > I really think we should find a way to limit our scope here. > > First, we need a bit of localhost behaviour on the part of secure > resolvers to understand that the trust anchor for .local (or .home.lan > or... have we even decided that part yet?) is network dependant. > > Given that, we might not actually care that multiple routers answer > a signed .local with different signatures. > We either trust one, some, or none. We might create some mechanism > whereby a .local trust anchor goes into global DNS somewhere. > e.g. _router1._local_trust_anchor.michaelthomas.com > but, can we make that out of scope for now? Even if we only have one .local, or whatever the root is, how does that root's key get into clients? And I'd think it's pretty important that the local names for my house cannot be spoofed by a local name for your house just because I happened to visit and some auto-conf magic happened because I wanted to talk to your fridge. Which to me seems that a .local root gets into a lot of trouble with (malicious) namespace collisions when you're talking about mobile devices. > > > Second, if we agree that if we have more than one router with a .local > name server that answers securely, then we need to decide how things > are signed. Is this specifically coupled to a "router", or just the generic "thing in my house that might have a DNS server in it"? > > Third, maybe we do not need more than one secure .local name server > in a network that has more than one router. > Seriously, I can see my neighbor's wifi, and I have access to his (guest) net. This problem is already here. Mike From brian.e.carpenter@gmail.com Tue Jul 10 09:31:57 2012 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 78ED111E81A8 for ; Tue, 10 Jul 2012 09:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eg3xCqqm7WX5 for ; Tue, 10 Jul 2012 09:31:57 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C920511E81AA for ; Tue, 10 Jul 2012 09:31:56 -0700 (PDT) Received: by eekd4 with SMTP id d4so81104eek.31 for ; Tue, 10 Jul 2012 09:32:24 -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=W4EaTkz/obsk3dHJV+EjK5x2ME/nbCKAGDC7d4Zlp/A=; b=IN92bwiXmgdDE7NwZ5Q5/1sk6bmlDxbkxw8B3UlQI9KwPYJhbNJC60jqrj0pfMQgYj 3+ortEs3543p9K2/FJmwjbkiYDof2lKkYC84H1kkWlToMu0tB2YHKN2NieNwuZROIyKs BMInJU4xD9zobOj7Kb6v5MF2JfnzZPLXP8yOqgSRUhFXCLo26IBSZ6DV3U+gAhrIUicJ 3XSX4zSbYzbc+D6Y4AsH0mAyKPbmYky+cEq+d7RKCU0PeG0EH3LLBDJthBJParnkr6h/ ZjSYq3Jq4FsFjRHyOG5LdBdK9qw+Xx4f6oNXGZPks+eMO9K8ZMlq6x+nxhk5vnPgfkOQ M/ng== Received: by 10.14.40.18 with SMTP id e18mr10937125eeb.109.1341937944287; Tue, 10 Jul 2012 09:32:24 -0700 (PDT) Received: from [192.168.1.66] (host-2-102-218-176.as13285.net. [2.102.218.176]) by mx.google.com with ESMTPS id y54sm103915048eef.10.2012.07.10.09.32.22 (version=SSLv3 cipher=OTHER); Tue, 10 Jul 2012 09:32:23 -0700 (PDT) Message-ID: <4FFC591B.8030501@gmail.com> Date: Tue, 10 Jul 2012 17:32:27 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Thomas References: <20120709164921.GC97192@isc.org> <201207100116.q6A1GuAv092989@gateway.ipv6.occnc.com> <20120710025944.GA12479@isc.org> <4FFC3E1B.80004@mtcc.com> <16808.1341933293@herring.sandelman.ottawa.on.ca> <4FFC55E5.5030706@mtcc.com> In-Reply-To: <4FFC55E5.5030706@mtcc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Michael Richardson , homenet@ietf.org Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 16:31:57 -0000 On 10/07/2012 17:18, Michael Thomas wrote: ... >> Third, maybe we do not need more than one secure .local name server >> in a network that has more than one router. >> > > Seriously, I can see my neighbor's wifi, and I have access to his > (guest) net. This problem is already here. .local is a problem in exactly the same way that RFC1918 is a problem. For homenet, we should really do better (as ULAs do better than RFC1918). If you want something that walks and talks like a locally defined, locally significant TLD, then that's exactly what you'd better have. So it needs to be . not . Brian From d.sturek@att.net Tue Jul 10 09:50:16 2012 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 3139821F8638 for ; Tue, 10 Jul 2012 09:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAj+9+YFyseY for ; Tue, 10 Jul 2012 09:50:15 -0700 (PDT) Received: from nm26-vm2.bullet.mail.ne1.yahoo.com (nm26-vm2.bullet.mail.ne1.yahoo.com [98.138.91.214]) by ietfa.amsl.com (Postfix) with SMTP id 037B221F8634 for ; Tue, 10 Jul 2012 09:50:14 -0700 (PDT) Received: from [98.138.90.51] by nm26.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jul 2012 16:50:37 -0000 Received: from [68.142.194.243] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jul 2012 16:50:37 -0000 Received: from [66.94.237.119] by t1.bullet.mud.yahoo.com with NNFMP; 10 Jul 2012 16:50:37 -0000 Received: from [127.0.0.1] by omp1024.access.mail.mud.yahoo.com with NNFMP; 10 Jul 2012 16:50:37 -0000 X-Yahoo-Newman-Id: 637049.86535.bm@omp1024.access.mail.mud.yahoo.com Received: (qmail 40137 invoked from network); 10 Jul 2012 16:50:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1341939037; bh=mamdhPe9WwziW2+8OwPjMjUpw3CgKpZqYXaKaDDUSOA=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=vPFSTpo6lxtIvATgf8X12N3n2sh7DnWsXHxZorvWnaxDTEaL2D5wmi6LtDBULzFGnMv9evPjMjEcWR+zL30tYMMWuQ2mPkm1dTu7gHiDThtOmzIAHdkGZf78IzCv3MYpPdV5p+GZu3WDuK5AlsLHSQ3YcckURuxhYg5GVPbTb/g= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Xsr25d4VM1l99Wkt6GEFt7.jln5THOb7Z6YEN5y5ImAQX1O 3RjVn0hDZWP48t5M8o741K7Twu5RSyqOoMP1wNTPL5SzmJxxF679eKcWNeAX 8KqQAaQKoCVadHsx2qN5I.K_jJ5oUYC67sk_TpC3lTOmA43tOq4YhJYQmCNm J8OunreOrcf3YwQPuKTzaHddjA5r0DvWZ48TYROQ1kvj6_vX7EGya9WoG5Ax DzKZ22w2m3yo2ESUpxjAnwKYwdq93.AOocTOBYR7Ly22NpWHsKUi5vwKTKp3 4HzPQrbgCVfLkGpa6GxRFTQg.LvEfCIPpo6MD8L7vDPdMtL812i_SinbJldu t6DVszBEWWLbyvkr8vuuMsm9QpM2ALQqPPNXutLkhZoF23iKOZlbzcgSoYW1 tpajjkVSm_l1stZmHfJvJxUgJNS1.2kTjbH245oW4Gi15ljUCrg1eBHQbdly UzJ7ekyWwVatTNlYBwBA6rs8- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.105] (d.sturek@66.27.60.174 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 10 Jul 2012 09:50:37 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Tue, 10 Jul 2012 09:50:34 -0700 From: Don Sturek To: Brian E Carpenter , Michael Thomas Message-ID: Thread-Topic: [homenet] Name service design principles: a proposal In-Reply-To: <4FFC591B.8030501@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Michael Richardson , homenet@ietf.org Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 16:50:16 -0000 Hi Brian, The complication to what you wrote below is the current sale of internet suffixes by ICANN. It will no longer be clear that . would not conflict with another suffix on the wider internet (or could in the future). I think, in the current environment, we will be lucky to get allocation of a fixed string like <.wellknownString> for free in local home environments. We (the Homenet group) should decide on a useful, unique suffix for local services and see if we can get that reserved by ICANN for local services (and not later sold). Don On 7/10/12 9:32 AM, "Brian E Carpenter" wrote: >On 10/07/2012 17:18, Michael Thomas wrote: >... >>> Third, maybe we do not need more than one secure .local name server >>> in a network that has more than one router. >>> >> >> Seriously, I can see my neighbor's wifi, and I have access to his >> (guest) net. This problem is already here. > >.local is a problem in exactly the same way that RFC1918 is a problem. >For homenet, we should really do better (as ULAs do better than RFC1918). > >If you want something that walks and talks like a locally defined, >locally significant TLD, then that's exactly what you'd better have. >So it needs to be . not . > > Brian >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From mike@mtcc.com Tue Jul 10 10:00:41 2012 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 E004521F865A for ; Tue, 10 Jul 2012 10:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAOBXhjfPoap for ; Tue, 10 Jul 2012 10:00:41 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 4174721F855F for ; Tue, 10 Jul 2012 10:00:41 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6AH16fv027626 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 10 Jul 2012 10:01:07 -0700 Message-ID: <4FFC5FD2.1010804@mtcc.com> Date: Tue, 10 Jul 2012 10:01:06 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Brian E Carpenter References: <20120709164921.GC97192@isc.org> <201207100116.q6A1GuAv092989@gateway.ipv6.occnc.com> <20120710025944.GA12479@isc.org> <4FFC3E1B.80004@mtcc.com> <16808.1341933293@herring.sandelman.ottawa.on.ca> <4FFC55E5.5030706@mtcc.com> <4FFC591B.8030501@gmail.com> In-Reply-To: <4FFC591B.8030501@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=869; t=1341939667; x=1342803667; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Name=20service=20design=20p rinciples=3A=20a=20proposal |Sender:=20 |To:=20Brian=20E=20Carpenter=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=hneJe3vzLppefMs2kmxZe6+qgh1+8fNIKyDER7Lgrvg=; b=mVq7hVYIstYJPsFLHiIhNDiTnS3sm51PXqTypACodZsifb9oyNYStNy5x4 lqe6OYiIpLPYO07JwW98Adx/81cvnRTfn4Nm3KDV3ojJ/DjeADUZtrYbir2G 2QN8Dj9lIPciAY3bvwxHd+eW6BacHtQ09rZRWbC+ctVFR+vJRr6Ts=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Michael Richardson , homenet@ietf.org Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 17:00:42 -0000 On 07/10/2012 09:32 AM, Brian E Carpenter wrote: > On 10/07/2012 17:18, Michael Thomas wrote: > ... >>> Third, maybe we do not need more than one secure .local name server >>> in a network that has more than one router. >>> >> Seriously, I can see my neighbor's wifi, and I have access to his >> (guest) net. This problem is already here. > .local is a problem in exactly the same way that RFC1918 is a problem. > For homenet, we should really do better (as ULAs do better than RFC1918). > > If you want something that walks and talks like a locally defined, > locally significant TLD, then that's exactly what you'd better have. > So it needs to be . not . > I agree. Though it's a little unfriendly to type in a FQDN for a ULA-like-statistically-unique name, right? It would be sort of nice to finesse this. Mike From v6ops@globis.net Tue Jul 10 10:48:44 2012 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 9815021F86DC for ; Tue, 10 Jul 2012 10:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.07 X-Spam-Level: * X-Spam-Status: No, score=1.07 tagged_above=-999 required=5 tests=[AWL=4.669, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PntZp5mt54r9 for ; Tue, 10 Jul 2012 10:48:36 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id ADC5021F86D7 for ; Tue, 10 Jul 2012 10:48:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id BF25887007F for ; Tue, 10 Jul 2012 19:48:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNjRp2EPeoxO for ; Tue, 10 Jul 2012 19:48:24 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E257C870065 for ; Tue, 10 Jul 2012 19:48:23 +0200 (CEST) Message-ID: <4FFC6AE6.2030701@globis.net> Date: Tue, 10 Jul 2012 19:48:22 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: homenet@ietf.org References: <20120709164921.GC97192@isc.org> <201207100116.q6A1GuAv092989@gateway.ipv6.occnc.com> <20120710025944.GA12479@isc.org> <4FFC3E1B.80004@mtcc.com> <16808.1341933293@herring.sandelman.ottawa.on.ca> <4FFC55E5.5030706@mtcc.com> <4FFC591B.8030501@gmail.com> In-Reply-To: <4FFC591B.8030501@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 17:48:44 -0000 +1 on the need for a local trust anchor if users want authentication Without a local trust anchor, how are we ever going to do authenticated reverse resolution of the ULA space? Without a local trust anchor, how would we guarantee stand-alone operations (of DNSSEC)? +1 on the need for a unique/identifiable name space .. might work. e.g. ..homenet. then indeed you'd have to "enroll" with a homenet to be able to trust it's namespace if you wanted authentication. But at least the namespace would be pretty unique once you did so, even for highly mobile devices. Bootstrapping the namespace wouldn't seem to be a problem, as the ULA prefix can be detected by all devices. In the unlikely event of two homenets choosing the same ULA, and thus having overlapping namespace as detected by a highly mobile device, I guess there'd have to be some sort of tie-breaker e.g. the trust anchor itself, or the user is warned and manually regenerates a new ULA for one of her homenets. FYI RFC6821 uses ULA as a unique host identifier. regards, RayH Brian E Carpenter wrote: > On 10/07/2012 17:18, Michael Thomas wrote: > ... >>> Third, maybe we do not need more than one secure .local name server >>> in a network that has more than one router. >>> >> Seriously, I can see my neighbor's wifi, and I have access to his >> (guest) net. This problem is already here. > > .local is a problem in exactly the same way that RFC1918 is a problem. > For homenet, we should really do better (as ULAs do better than RFC1918). > > If you want something that walks and talks like a locally defined, > locally significant TLD, then that's exactly what you'd better have. > So it needs to be . not . > > Brian > From brian.e.carpenter@gmail.com Tue Jul 10 12:14:46 2012 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 BC20F21F8796 for ; Tue, 10 Jul 2012 12:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.166 X-Spam-Level: X-Spam-Status: No, score=-101.166 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCzytyDVyZZv for ; Tue, 10 Jul 2012 12:14:45 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8709221F8792 for ; Tue, 10 Jul 2012 12:14:45 -0700 (PDT) Received: by eaaq13 with SMTP id q13so132260eaa.31 for ; Tue, 10 Jul 2012 12:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PkvWYnbRSh3P/F1s0xXbA+ap7MQKCtDgI2RwyvuKaSA=; b=wY5AvSWlv+Ck/fhuuFMSyei8ygen8klQ1XlZ2Ap8q2ukpvGmW3+p+D21g1/SyBQmB8 wBbjGbkQwBA/TpcRMEvkLf3KkuTUsDZK3nPwahJf5wIR5n/wYVw2WQt2H7l+tB0cviOq 6o9sIIeHgSIHj3UWRn5d1EPVug+ccUD6tYz5/iOmOBp3hBK05Ka/J1nYI+nN8KoHoi8p l21LaLiKNbdsZxUkcJj/XSoLRBpBtnOa+zuWSIh2bmH+cYGjjQY/QXlq5I1+i7HjVtUn BrRTJaPWU6Q+pYgWm8PoVQYMRcm9//twc//H9RLgecWHxGrxPxlm0L/YE0B4tXAxZpiR vPkA== Received: by 10.14.29.71 with SMTP id h47mr11108922eea.129.1341947713192; Tue, 10 Jul 2012 12:15:13 -0700 (PDT) Received: from [192.168.1.66] (host-2-102-218-176.as13285.net. [2.102.218.176]) by mx.google.com with ESMTPS id s4sm105022910eef.2.2012.07.10.12.15.10 (version=SSLv3 cipher=OTHER); Tue, 10 Jul 2012 12:15:12 -0700 (PDT) Message-ID: <4FFC7F44.7040803@gmail.com> Date: Tue, 10 Jul 2012 20:15:16 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Don Sturek References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Michael Richardson , homenet@ietf.org, Michael Thomas Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 19:14:47 -0000 Don, On 10/07/2012 17:50, Don Sturek wrote: > Hi Brian, > > The complication to what you wrote below is the current sale of internet > suffixes by ICANN. It will no longer be clear that . would > not conflict with another suffix on the wider internet (or could in the > future). > > I think, in the current environment, we will be lucky to get allocation of > a fixed string like <.wellknownString> for free in local home > environments. We (the Homenet group) should decide on a useful, unique > suffix for local services and see if we can get that reserved by ICANN for > local services (and not later sold). I don't think we should worry unduly about this. The IETF/IANA MoU allows the IETF to define TLDs for technical purposes, and instruct IANA accordingly. A family of TLDs for local use is clearly within that scope. On 10/07/2012 18:01, Michael Thomas wrote: > ...Though it's a little unfriendly to type in a FQDN for a > ULA-like-statistically-unique name, right? It would be sort of nice > to finesse this. Good point. Maybe we can use some kind of wild card trick. Brian From mellon@fugue.com Tue Jul 10 12:29:59 2012 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 2919511E80BC for ; Tue, 10 Jul 2012 12:29:59 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9a+NI-5fgd08 for ; Tue, 10 Jul 2012 12:29:54 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id B41B011E80A6 for ; Tue, 10 Jul 2012 12:29:54 -0700 (PDT) Received: from [10.1.10.16] (173-162-214-218-NewEngland.hfc.comcastbusiness.net [173.162.214.218]) by toccata.fugue.com (Postfix) with ESMTPSA id 710682380253; Tue, 10 Jul 2012 15:30:21 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_4B5BCAA2-A93F-49FB-83A9-77F71FB005B0" From: Ted Lemon In-Reply-To: <4FFC7F44.7040803@gmail.com> Date: Tue, 10 Jul 2012 15:30:19 -0400 Message-Id: References: <4FFC7F44.7040803@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1278) Cc: Michael Richardson , homenet@ietf.org, Michael Thomas , Don Sturek Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 19:29:59 -0000 --Apple-Mail=_4B5BCAA2-A93F-49FB-83A9-77F71FB005B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 10, 2012, at 3:15 PM, Brian E Carpenter wrote: >> ...Though it's a little unfriendly to type in a FQDN for a >> ULA-like-statistically-unique name, right? It would be sort of nice >> to finesse this. >=20 > Good point. Maybe we can use some kind of wild card trick. I think it's wrong-headed to try to use unqualified domain names to make = the user's life easier. The problem is that in doing so, you are = setting up a security model for them that has implications they = typically have no hope of understanding. If you really want convenient = naming, the security model has to be carefully thought out, and the = method of delivery of those names has to be carefully specified. = Whatever you wind up with, it will not be DNS or mDNS. Trying to use = DNS to securely deliver site-local naming with a shared root is trying = to fit a square peg into a round hole. --Apple-Mail=_4B5BCAA2-A93F-49FB-83A9-77F71FB005B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii ...Though it's a little unfriendly to = type in a FQDN for a
ULA-like-statistically-unique name, right? It would be = sort of nice
to finesse = this.

Good point. Maybe we can use some kind of wild = card trick.
I think it's = wrong-headed to try to use unqualified domain names to make the user's = life easier.   The problem is that in doing so, you are setting up = a security model for them that has implications they typically have no = hope of understanding.   If you really want convenient naming, the = security model has to be carefully thought out, and the method of = delivery of those names has to be carefully specified.   Whatever = you wind up with, it will not be DNS or mDNS.   Trying to use DNS = to securely deliver site-local naming with a shared root is trying to = fit a square peg into a round hole.

= --Apple-Mail=_4B5BCAA2-A93F-49FB-83A9-77F71FB005B0-- From sm@resistor.net Tue Jul 10 12:30:47 2012 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 38D1C21F86BD for ; Tue, 10 Jul 2012 12:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCO8Rto5mIyo for ; Tue, 10 Jul 2012 12:30:42 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D8521F8512 for ; Tue, 10 Jul 2012 12:30:42 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6AJV1E4029940; Tue, 10 Jul 2012 12:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341948666; bh=o59h3+UOfSI+FYQWeakHfvgekbNG0cJiy9WMZwz9uRs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=UvFeNS3BuWfIk6w20ZUFZIjNfIMPWPQjosWkRWTQDHt9pdroknZkD+TprjQjUhw1O 1VLm0adpQtdxw/3lDlxDwPuqywZgSGJ4jJSyLeG/rYnUcsiHCXjO+Hrt/rWQ2laqLJ udqO3ymW4U50+fPed3X+lVevNn2jISjvmGYbvBg4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341948666; i=@resistor.net; bh=o59h3+UOfSI+FYQWeakHfvgekbNG0cJiy9WMZwz9uRs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=nXg9OZX6diGTe/uBytn6/PUPMqszv0f7tGs2bkk0jrLZQ+aJyr5FzHa5UjIFJ7nUq QyopFuvLLSo9JSSaQmAcEJz4j0wNymsGKFzdnckTuUvk4/6tJBw1Z8WH9VSnetrqKc FDUmr8v21n41MYabJrIQgd367q/f6mR6OgneRzaQ= Message-Id: <6.2.5.6.2.20120710122117.0a3739b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Jul 2012 12:30:52 -0700 To: Brian E Carpenter From: SM In-Reply-To: <4FFC7F44.7040803@gmail.com> References: <4FFC7F44.7040803@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: homenet@ietf.org Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 19:30:47 -0000 Hi Brain, At 12:15 10-07-2012, Brian E Carpenter wrote: > >I don't think we should worry unduly about this. The IETF/IANA MoU allows >the IETF to define TLDs for technical purposes, and instruct IANA accordingly. >A family of TLDs for local use is clearly within that scope. > 'IANA understands that a single IANA action is required to be completed upon approval of this document. IANA will create a new registry for "Special Use Domain Names." The registry will consist of domain names and references to IETF Standards Action documents that document the special meaning of the name. The initial registry is empty. Adding new entries to the registry for Special Use Domain Names requires Standards Action.' The document is in the RFC Editor queue. Regards, -sm From jhw@apple.com Tue Jul 10 12:51:54 2012 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 CB90811E8159 for ; Tue, 10 Jul 2012 12:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1u53dp7Hy57 for ; Tue, 10 Jul 2012 12:51:54 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 487C111E8132 for ; Tue, 10 Jul 2012 12:51:54 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0M6Y00EHWN67GM93@mail-out.apple.com> for homenet@ietf.org; Tue, 10 Jul 2012 12:52:17 -0700 (PDT) X-AuditID: 1180711d-b7f406d000004330-57-4ffc87f1410b Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 65.8E.17200.1F78CFF4; Tue, 10 Jul 2012 12:52:17 -0700 (PDT) From: james woodyatt In-reply-to: <4FFC5FD2.1010804@mtcc.com> Date: Tue, 10 Jul 2012 12:52:16 -0700 Message-id: <61F66DB6-E2B5-43FF-86DB-F4EF5A214320@apple.com> References: <20120709164921.GC97192@isc.org> <201207100116.q6A1GuAv092989@gateway.ipv6.occnc.com> <20120710025944.GA12479@isc.org> <4FFC3E1B.80004@mtcc.com> <16808.1341933293@herring.sandelman.ottawa.on.ca> <4FFC55E5.5030706@mtcc.com> <4FFC591B.8030501@gmail.com> <4FFC5FD2.1010804@mtcc.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42IRPMjroPux/Y+/wfWjRhbvFx1icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxs5+yYLt3BVtS14xNTDO5exi5OSQEDCRuHCrhRXCFpO4cG89 WxcjF4eQwGwmiSOLj7ODJJgFtCRu/HvJBGLzCuhJzG6fwwJiCws4Smx5840NxGYTUJH4dvku WA2ngIbEh4vTwYayCKhKHPn0lwVijrbEsoWvmSHm2EhsefiTGWLZYiaJNX+fgTWICOhLPD3y iw3iIlmJ74fPs01g5JuF5I5ZSO6YhWTuAkbmVYyCRak5iZWGxnqJBQU5qXrJ+bmbGEGh1FAo u4Nx/0/+Q4wCHIxKPLwvEv/4C7EmlhVX5h5ilOBgVhLhfegMFOJNSaysSi3Kjy8qzUktPsQo zcGiJM57MgsoJZCeWJKanZpakFoEk2Xi4JRqYMy6uUv5za7A3nV/357mr3d768wavmyKTdQ8 USXTxyk3+AzihKvOK4qWpace+Xu9VGPy9+Of1PWrX9v9rZ73un/TG8UUxdfPIxZfOvfsfXq0 WvGb55bKFr8e3wvul93e+npS60Lh+0bmK7j5OK+qiq5aeOV97wnm6I33ntYmtyk1LrQ5wJHd PkeJpTgj0VCLuag4EQB2haoYIQIAAA== Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 19:51:55 -0000 On Jul 10, 2012, at 10:01 , Michael Thomas wrote: > > ...Though it's a little unfriendly to type in a FQDN for a ULA-like-statistically-unique name, right? Hummm, or maybe we should think about whether typing characters on keyboards is *ever* a good human interface for the most common home networking scenarios. What if we designed a name service that, rather than expecting humans to have a keyboard with which to type out wackily encoded FQDNs--character by character, and hoping they spell the name right with all the fiddly punctuation and everything--we instead designed one that naturally facilitates a human interface built around presenting the human with ordered, readable, collections of names, which allows them to choose the ones corresponding to the services they want to use? What if we went further and designed it with a meta-service discovery feature, so you could use it to discover the domains in which services may be discovered? Would that help? What if IETF already had such a name service in hand, i.e. I-D.cheshire-dnsext-dns-sd, which is already designed, deployed and proven to work well in home networking scenarios? (Yes, it has the meta-service discovery feature too, c.f. section 11, Discovery of Browsing and Registration Domains.) Would *that* help? -- james woodyatt member of technical staff, core os networking From mellon@fugue.com Tue Jul 10 13:33:16 2012 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 EE57D21F8597 for ; Tue, 10 Jul 2012 13:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47eQ16j1iARw for ; Tue, 10 Jul 2012 13:33:16 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 867FA21F8595 for ; Tue, 10 Jul 2012 13:33:16 -0700 (PDT) Received: from [10.1.10.16] (173-162-214-218-NewEngland.hfc.comcastbusiness.net [173.162.214.218]) by toccata.fugue.com (Postfix) with ESMTPSA id 76306238024E; Tue, 10 Jul 2012 16:33:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_1A840A28-BEAB-4B62-881F-75F105EE1B0B" From: Ted Lemon In-Reply-To: <61F66DB6-E2B5-43FF-86DB-F4EF5A214320@apple.com> Date: Tue, 10 Jul 2012 16:33:36 -0400 Message-Id: <87965929-FDE9-4D39-A250-53C9BA7F7D6D@fugue.com> References: <20120709164921.GC97192@isc.org> <201207100116.q6A1GuAv092989@gateway.ipv6.occnc.com> <20120710025944.GA12479@isc.org> <4FFC3E1B.80004@mtcc.com> <16808.1341933293@herring.sandelman.ottawa.on.ca> <4FFC55E5.5030706@mtcc.com> <4FFC591B.8030501@gmail.com> <4FFC5FD2.1010804@mtcc.com> <61F66DB6-E2B5-43FF-86DB-F4EF5A214320@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1278) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 20:33:17 -0000 --Apple-Mail=_1A840A28-BEAB-4B62-881F-75F105EE1B0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 10, 2012, at 3:52 PM, james woodyatt wrote: > What if IETF already had such a name service in hand, i.e. = I-D.cheshire-dnsext-dns-sd, which is already designed, deployed and = proven to work well in home networking scenarios? (Yes, it has the = meta-service discovery feature too, c.f. section 11, Discovery of = Browsing and Registration Domains.) >=20 > Would *that* help? Yes, that's the sort of thing I was talking about. However, I don't = think it answers the trust anchor question. --Apple-Mail=_1A840A28-BEAB-4B62-881F-75F105EE1B0B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii What if IETF = already had such a name service in hand, i.e. = I-D.cheshire-dnsext-dns-sd, which is already designed, deployed and = proven to work well in home networking scenarios? (Yes, it has the = meta-service discovery feature too, c.f. section 11, Discovery of = Browsing and Registration Domains.)

Would *that* = help?
Yes, that's the sort of thing I = was talking about.   However, I don't think it answers the trust = anchor question.

= --Apple-Mail=_1A840A28-BEAB-4B62-881F-75F105EE1B0B-- From jhw@apple.com Tue Jul 10 15:26:34 2012 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 2744111E80B5 for ; Tue, 10 Jul 2012 15:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYdFMaq6WljH for ; Tue, 10 Jul 2012 15:26:29 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 96E2821F85FC for ; Tue, 10 Jul 2012 15:26:29 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M6Y005J4UCQ7950@mail-out.apple.com> for homenet@ietf.org; Tue, 10 Jul 2012 15:26:51 -0700 (PDT) X-AuditID: 11807137-b7f536d000006fcc-b5-4ffcac2bdaac Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 6E.74.28620.B2CACFF4; Tue, 10 Jul 2012 15:26:51 -0700 (PDT) From: james woodyatt In-reply-to: <87965929-FDE9-4D39-A250-53C9BA7F7D6D@fugue.com> Date: Tue, 10 Jul 2012 15:26:50 -0700 Message-id: References: <20120709164921.GC97192@isc.org> <201207100116.q6A1GuAv092989@gateway.ipv6.occnc.com> <20120710025944.GA12479@isc.org> <4FFC3E1B.80004@mtcc.com> <16808.1341933293@herring.sandelman.ottawa.on.ca> <4FFC55E5.5030706@mtcc.com> <4FFC591B.8030501@gmail.com> <4FFC5FD2.1010804@mtcc.com> <61F66DB6-E2B5-43FF-86DB-F4EF5A214320@apple.com> <87965929-FDE9-4D39-A250-53C9BA7F7D6D@fugue.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42IRPMjroKu95o+/wcxF7BbvFx1icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRte68ywFR1gqNt89w9jAeIa5i5GDQ0LARGLbd6EuRk4gU0zi wr31bF2MXBxCArOZJO4t+MoGkmAW0JK48e8lE4jNK6AnMbt9DguILSzgKLHlzTewGjYBFYlv l++C1XAK2Er8nbsIrIZFQFVi1bzJrBBztCWWLXzNDDHHRqK5cR47xLJWZon/51YzgiREBPQl nh75xQZxkazE98Pn2SYw8s1CcscsJHfMQjJ3ASPzKkbBotScxEpDM73EgoKcVL3k/NxNjKBQ aig038G4/a/cIUYBDkYlHt6XiX/8hVgTy4orcw8xSnAwK4nwcs4BCvGmJFZWpRblxxeV5qQW H2KU5mBREuc9mwWUEkhPLEnNTk0tSC2CyTJxcEo1MObvXKRWm5Gityzw0D6LM/Nmts9/teGf +PyFjo9Eny74VRj7L1r0in5Qdg6XRZienQR78IHt+byXr22ceG5Z3qzAGXJ777xfvN9QUIwv rvt2eNRZ8yVaue9lnHamLzq+bXNp3O8TjUt8ijtjfdlmnf9xfpJtQfrU5U7zRI78Lb51+aaA /w7p1r9KLMUZiYZazEXFiQCYwxrvIQIAAA== Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 22:26:34 -0000 On Jul 10, 2012, at 13:33 , Ted Lemon wrote: > > However, I don't think it answers the trust anchor question. I think we can answer your "trust anchor question" as posed, then we will *also* have figured out how to use DNSSEC to secure the "local." domain as it is used in I-D.cheshire-dnsext-mdns. Before going there, I think I would start by questioning whether any cryptographic system based on the PKI is the right choice in these scenarios. -- james woodyatt member of technical staff, core os networking From mike@mtcc.com Tue Jul 10 18:10:39 2012 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 AC2AF11E80A1 for ; Tue, 10 Jul 2012 18:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKznmvIDJJMP for ; Tue, 10 Jul 2012 18:10:39 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id EC74F11E8079 for ; Tue, 10 Jul 2012 18:10:38 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6B1B6wI030191 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 10 Jul 2012 18:11:07 -0700 Message-ID: <4FFCD2AA.2040504@mtcc.com> Date: Tue, 10 Jul 2012 18:11:06 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Michael Richardson References: <20120709164921.GC97192@isc.org> <201207100116.q6A1GuAv092989@gateway.ipv6.occnc.com> <20120710025944.GA12479@isc.org> <4FFC3E1B.80004@mtcc.com> <16808.1341933293@herring.sandelman.ottawa.on.ca> <4FFC55E5.5030706@mtcc.com> <18840.1341951036@herring.sandelman.ottawa.on.ca> In-Reply-To: <18840.1341951036@herring.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1999; t=1341969067; x=1342833067; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Name=20service=20design=20p rinciples=3A=20a=20proposal |Sender:=20 |To:=20Michael=20Richardson=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=CLtfVFtslOUajMBOoAjPSy+GzbwNFkXvxjGinLR5/ek=; b=Qm32rucHMMMh5EBzdQyBbgkqinJzEc0NGiGD7SGtKVhbPZL0kobYmn7JFu eCJviSVagBDb/ebsjxFLUuMiH72xc420hXqYfJF8+w70saTS+tDqC/41S0i3 muO+iHTpXTvBDu/PH7/JNlPiGpKil2CZ4enqNFlKEp9R6qH5+PlT8=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: homenet@ietf.org Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 01:10:39 -0000 On 07/10/2012 01:10 PM, Michael Richardson wrote: > I'm gonna repeat what I said: > > >> First, we need a bit of localhost behaviour on the part of secure > >> resolvers to understand that the trust anchor for .local (or > >> .home.lan or... have we even decided that part yet?) is network > >> dependant. > > Michael> Even if we only have one .local, or whatever the root is, > Michael> how does that root's key get into clients? > > So, it's not just a question, as you observed, of getting the .local > anchor in, but to know *which* .local anchor to use. > They are all valid "from a certain point of view". > ("This is not the androids.local you are looking for!") Yes. As in, enrollment is hard :) > > If .local was never signed, but in a homenet-compliant network, instead > returned > foo.local IN CNAME foo.myhouse.something-unique.someisp.net Just out of curiosity, is there any significance to .someisp.net in your example? I'd think -- and it's the way I read Brian's note -- that it would stop at .something-unique. > > then we are back to how to get a local delegation done. > > If you are on your neighbour's wifi, and your fridge is accessible, and > you have the name fridge.michaelthomashouse.something-unique.someisp.net, > then you are set, right? Assuming that I'm not running a split horizon DNS for my .unique, I suppose it would be. But that sort of leads to weirdness with local DNS leakage beyond the homenet. I'm not sure what the working group thinks about boundaries (my bad most likely), but wouldn't that be one of them? I believe that James asked whether integrity of some sort was needed. I wonder if one practical reason why the answer might be yes is because without it these phones shifting back and forth between administrative domains purely for network reasons (eg, better signal strength) wouldn't be able to know which local namespace they should resolve from. Mike From mike@mtcc.com Wed Jul 11 09:27:54 2012 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 012DA11E80CF for ; Wed, 11 Jul 2012 09:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59n4xHzb6tOR for ; Wed, 11 Jul 2012 09:27:53 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id E8ED011E80C6 for ; Wed, 11 Jul 2012 09:27:52 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6BGSLS4023333 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 11 Jul 2012 09:28:21 -0700 Message-ID: <4FFDA9A5.5050502@mtcc.com> Date: Wed, 11 Jul 2012 09:28:21 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: james woodyatt References: <20120709164921.GC97192@isc.org> <201207100116.q6A1GuAv092989@gateway.ipv6.occnc.com> <20120710025944.GA12479@isc.org> <4FFC3E1B.80004@mtcc.com> <16808.1341933293@herring.sandelman.ottawa.on.ca> <4FFC55E5.5030706@mtcc.com> <4FFC591B.8030501@gmail.com> <4FFC5FD2.1010804@mtcc.com> <61F66DB6-E2B5-43FF-86DB-F4EF5A214320@apple.com> In-Reply-To: <61F66DB6-E2B5-43FF-86DB-F4EF5A214320@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=517; t=1342024101; x=1342888101; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Name=20service=20design=20p rinciples=3A=20a=20proposal |Sender:=20 |To:=20james=20woodyatt=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=VohKn3aLepda4IFB9swO5lQJOrJm8m/awBFj6NQxRU4=; b=LbkvM19LFycw2Qyko2d40onL8II1cqVAdOLKxKbL5ARU5p2Rxp0a9wh4me UPAO8AOnNVmr6NVFv9Tz3YVGbyDRdlhHBAZnj1MCLYzAUKL+BG1bW2+3bEgf q34r+66Wpbwv90ERM1QUWLebG57LtcCARtGVyNyteQwp6P0NEfP3E=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 16:27:54 -0000 On 07/10/2012 12:52 PM, james woodyatt wrote: > On Jul 10, 2012, at 10:01 , Michael Thomas wrote: >> ...Though it's a little unfriendly to type in a FQDN for a ULA-like-statistically-unique name, right? > > Hummm, or maybe we should think about whether typing characters on keyboards is *ever* a good human interface for the most common home networking scenarios. On the internet at large, I think the world has already decided what interface it prefers. Search. For better or worse. Mike From internet-drafts@ietf.org Mon Jul 16 07:01:50 2012 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 DBB3821F88BA; Mon, 16 Jul 2012 07:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jA+-K9w5LPy7; Mon, 16 Jul 2012 07:01:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B5621F88B1; Mon, 16 Jul 2012 07:01:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716140148.5492.60572.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 07:01:48 -0700 Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-arch-04.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 14:01:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Home Networking Working Group of the IETF. Title : Home Networking Architecture for IPv6 Author(s) : Tim Chown Jari Arkko Anders Brandt Ole Troan Jason Weil Filename : draft-ietf-homenet-arch-04.txt Pages : 39 Date : 2012-07-16 Abstract: This text describes evolving networking technology within increasingly large residential home networks. The goal of this document is to define an architecture for IPv6-based home networking, while describing the associated principles, considerations and requirements. The text briefly highlights the 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-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-arch-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bortzmeyer@nic.fr Mon Jul 16 07:09:56 2012 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 4455821F883E for ; Mon, 16 Jul 2012 07:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.612 X-Spam-Level: X-Spam-Status: No, score=-101.612 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTC--QgUsFLC for ; Mon, 16 Jul 2012 07:09:55 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3A521F88BD for ; Mon, 16 Jul 2012 07:09:55 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 89F13280231; Mon, 16 Jul 2012 16:10:09 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 845B82801BD; Mon, 16 Jul 2012 16:10:09 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay1.nic.fr (Postfix) with ESMTP id 82AD04C007F; Mon, 16 Jul 2012 16:09:39 +0200 (CEST) Date: Mon, 16 Jul 2012 16:09:39 +0200 From: Stephane Bortzmeyer To: Daniel Migault Message-ID: <20120716140939.GA16979@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux wheezy/sid X-Kernel: Linux 3.2.0-2-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: homenet@ietf.org, Wouter Cloetens , philippe.lemordant@orange.com Subject: Re: [homenet] Delegating Naming Architectures X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 14:09:56 -0000 On Tue, Jul 03, 2012 at 12:11:54PM +0200, Daniel Migault wrote a message of 155 lines which said: > Please find two Naming Architectures we would like to discuss at Vancouver: I won't be in sunny British Columbia but I've read the drafts and I have a philosophical question. You did not say clearly if the delegated domain must be under an ISP's domain. If yes, it ties the user to the ISP ("I've switched ISPs, use and no longer "). If no, the ISP won't be able to update the DNS delegation. IMHO, it would be a good idea to have a high-level discussion of the service provided to the user, before getting into protocol details. A technical remark: since the DS record is sent by the client, one can assume that it may suddenly be a new one (key rollover). Then, DNSSEC validation will break for validators which have the old DS in the caches. Two possible solutions: have a very low TTL, or just say that it is the client's job to do rollovers properly (having two DS in parallel, etc). The second solution implies that the CPE includes rollover logic (like OpenDNSSEC does). DNSSEC in practice is hard and you may want to have two drafts, one without DNSSEC and one for DNSSEC gory details. Also, a security remark. When you say: > First delegation preserves the Home Network privacy, by avoiding ISP > to know the Home Network hosts. It certainly deserves a mention in Security Considerations saying that it is a limited protection. Many names will be predictible ("printer", "fridge", "nas", "iPad") and also the first DNS request to the parent domain (which is probably controlled by the ISP) will include the FQDN, thus revealing a name. (And I did not even mention the ability of the ISP to sniff the network.) From mcr@sandelman.ca Mon Jul 16 07:30:32 2012 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 1892611E80E0 for ; Mon, 16 Jul 2012 07:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.592 X-Spam-Level: X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPWxowri0vWe for ; Mon, 16 Jul 2012 07:30:31 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 784EE11E80C6 for ; Mon, 16 Jul 2012 07:30:31 -0700 (PDT) Received: from marajade.sandelman.ca (herring.sandelman.ca [209.87.252.231]) by relay.sandelman.ca (Postfix) with ESMTPS id E66DE8692 for ; Mon, 16 Jul 2012 10:27:35 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id B554F2003A; Mon, 16 Jul 2012 10:31:13 -0400 (EDT) Received: from herring.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 9CCA31FBD2 for ; Mon, 16 Jul 2012 10:31:13 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <20120716140939.GA16979@nic.fr> References: <20120716140939.GA16979@nic.fr> X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 16 Jul 2012 10:31:13 -0400 Message-ID: <24728.1342449073@herring.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Delegating Naming Architectures X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 14:30:32 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Stephane" =3D=3D Stephane Bortzmeyer writes: Stephane> I won't be in sunny British Columbia but I've read the drafts= and I Stephane> have a philosophical question. You did not say clearly if the Stephane> delegated domain must be under an ISP's domain. If yes, it ti= es the Stephane> user to the ISP ("I've switched ISPs, use Stephane> and no longer Stephane> "). If no, the ISP won't be= able to Stephane> update the DNS delegation. IMHO, it would be a good idea to h= ave a Stephane> high-level discussion of the service provided to the user, be= fore Stephane> getting into protocol details. This is an important concern, but given that 90% of residential customers already have this problem with their email addresses, I do not think it's a new issue. More clueful users have moved away from ISP domains, and they will also do the same thing for their home networks. So, we need to mandate those controls, and we need to think about transition from one ISP to another, but the immense value of having names automatically delegated from the ISP exceeds the pain of an eventual switch. Stephane> caches. Two possible solutions: have a very low TTL, or Stephane> just say that=20 Stephane> it is the client's job to do rollovers properly (having two D= S in Stephane> parallel, etc). The second solution implies that the CPE incl= udes Stephane> rollover logic (like OpenDNSSEC does). DNSSEC in practice Stephane> is hard and=20 Stephane> you may want to have two drafts, one without DNSSEC and Stephane> one for DNSSEC=20 Stephane> gory details. That's an interesting solution to the problem... "basic" and "secure" :-) =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUBUAQlroqHRg3pndX9AQIg6wP/WHkEC6JeLk4dZJyVtXets3RfA877UiPy D/3HXYSa52UHpeeAARGIYGY5H8dXmm8UIVmF3DCKBdv1r6zOInYeWY8r3u5YmlQ1 m5TvQ+JW+JRLV97hXyB8F1qjJ8DBh656LYmzMyV7mhj7Lm7WaEwUKws8KNvwf8Kc iPJt1VOTw54= =UyJB -----END PGP SIGNATURE----- --=-=-=-- From bortzmeyer@nic.fr Mon Jul 16 07:36:56 2012 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 955C021F8611 for ; Mon, 16 Jul 2012 07:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.739 X-Spam-Level: X-Spam-Status: No, score=-101.739 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoulhUbAYckM for ; Mon, 16 Jul 2012 07:36:56 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2EB21F85F9 for ; Mon, 16 Jul 2012 07:36:56 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id C56E228027D; Mon, 16 Jul 2012 16:37:08 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id C117A2801BD; Mon, 16 Jul 2012 16:37:08 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay1.nic.fr (Postfix) with ESMTP id B5AA74C0082; Mon, 16 Jul 2012 16:36:38 +0200 (CEST) Date: Mon, 16 Jul 2012 16:36:38 +0200 From: Stephane Bortzmeyer To: Michael Richardson Message-ID: <20120716143638.GA5078@nic.fr> References: <20120716140939.GA16979@nic.fr> <24728.1342449073@herring.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24728.1342449073@herring.sandelman.ca> X-Operating-System: Debian GNU/Linux wheezy/sid X-Kernel: Linux 3.2.0-2-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: homenet@ietf.org Subject: Re: [homenet] Delegating Naming Architectures X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 14:36:56 -0000 On Mon, Jul 16, 2012 at 10:31:13AM -0400, Michael Richardson wrote a message of 80 lines which said: > This is an important concern, but given that 90% of residential > customers already have this problem with their email addresses, I do > not think it's a new issue. More clueful users have moved away from > ISP domains, and they will also do the same thing for their home > networks. My point was not "this technique is broken" but "the exact service must be clearly stated". For instance, a high-level discussion at the beginning of the draft explaining that these names are tied to the ISP and the consequences (switching pain). From zehn.cao@gmail.com Wed Jul 18 05:09:21 2012 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 A920B21F86F7 for ; Wed, 18 Jul 2012 05:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+Fo97t3Nl+q for ; Wed, 18 Jul 2012 05:09:21 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D535321F8679 for ; Wed, 18 Jul 2012 05:09:20 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1627926ghb.31 for ; Wed, 18 Jul 2012 05:10:10 -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=c8ATDctrrQcLlD6UDE2gTVPmgH328q/yFIIMLkGZEkw=; b=LttaZv3CryiMUHBsty2OxiIzLQ0Ly//KMz7TkRuIb+PiElF2PECwi/F/iWQuoHsltN BdgycRcdxXuW7HzEcho5Yszlz6stnWhpQd66Nnl7Cg5y7e5ZfE1RbdsyDQKF05Wcujym rOYfUjR5Nxcn71SVfwbstS1lbsM4+QmF7d/4YflakmkbHf3e941F6MfM1eUam8htCtAV OTsfJKaEHrwtczkyIlNYW5pPKx0gD+kmBvRqo/lqhvkR6a3wAiP7itYUgNBPrLSJDd/6 44HCsDwnGwr+sohgpUlTB6OqP4elhmc05AhhEJm1oXidinfRH3OEr0u0iQEY/g37ISCS 2AbA== MIME-Version: 1.0 Received: by 10.68.219.162 with SMTP id pp2mr6984470pbc.85.1342613410301; Wed, 18 Jul 2012 05:10:10 -0700 (PDT) Received: by 10.68.60.8 with HTTP; Wed, 18 Jul 2012 05:10:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Jul 2012 20:10:10 +0800 Message-ID: From: Zhen Cao To: Daniel Migault Content-Type: text/plain; charset=ISO-8859-1 Cc: homenet@ietf.org, Wouter Cloetens , philippe.lemordant@orange.com Subject: Re: [homenet] Delegating Naming Architectures X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 12:09:21 -0000 Hi Daniel , I have read the drafts, and found the problem you would like to solve very interesting. Thanks for the work. Before going to the details of the solution part, I have some questions about the necessity of home network naming delegation. There are already technologies that make the home devices accessible from the outside, e.g., RFC6281, the back-to-my-mac solution, and DDNS solution RFC2136. I tried to get the answer by myself, e.g., the integration of this functionality into CPE makes the homenet devices more configurable, etc... But I would very like to hear your opinion about the answer. And I suggest the document to include a section of comparison with existing tech. Best regards, ----------- Zhen/CMCC Labs On Tue, Jul 3, 2012 at 6:11 PM, Daniel Migault wrote: > Hi, > > Please find two Naming Architectures we would like to discuss at Vancouver: > - "IPv6 Home Network Naming Delegation Architecture" > http://www.ietf.org/internet-drafts/draft-mglt-naming-delegation-00.txt > > - "Home Network Front End Naming Delegation" > http://www.ietf.org/internet-drafts/draft-mglt-front-end-naming-delegation-00.txt > > > Comments and suggestions are welcome. > > Best Regards > > Daniel > > > Abstract: "IPv6 Home Network Naming Delegation Architecture" > > This document describes the Naming Delegation Architecture that makes > IPv6 Home Network globally reachable with Names or Fully Qualified > Domain Names (FQDN). In this architecture, the Customer Premise > Equipment (CPE) acts as the DNS Authoritative Server of the Home > Network also called the Delegated DNS Server. The Naming Delegation > is configured between the Delegated DNS Server and the Delegating DNS > Server managed by the ISP. > > The use case considered in this document is an End User that > subscribes its ISP a specific Delegated Domain for its Home Network. > This document describes how the CPE automatically sets the Naming > Delegation between the Delegating and Delegated DNS Server. > > The Naming Delegation is requested by the CPE. The CPE DHCP Client > and the ISP DHCP Server exchange DHCP Options to properly set the > Naming Delegation. More specifically, the CPE DHCP Client (resp. the > ISP DHCP Server) configures the DNS(SEC) Zones of the Delegated DNS > Server (resp. Delegating DNS Server). For the Delegating DNS Server, > the necessary pieces of information required to set the Naming > Delegation are the IP address of the Delegated DNS Server, and if > DNSSEC is used, the Delegation of Signing Information. For the > Delegated DNS Server, the necessary information is the Delegated > Domain associated to the Home Network. > > > Abstract: "Home Network Front End Naming Delegation" > > This document proposes a Naming Delegation Architecture that makes > possible End Users to reach the hosts or services of their Home > Network using Names instead of IP addresses. > > This document shows how the Naming Delegation between the CPE and the > ISP can be set so the CPE is not exposed on the Internet. This > document describes an Naming Architecture where ISPs provide Front > End Delegating DNS Servers whereas the CPEs constitute a Back End > Network of Delegated DNS Servers. All DNS queries for any Home > Network are addressed to the Delegating Front End Server. The > response is expected to be stored on a CPE, and the Front End > Delegating DNS Server sends a DNS Query to that CPE before answering > to the initial DNS query. > > The negotiation between the CPE and the ISP is using DHCP Options. > This document provides options so Front End Delegating and the > Delegated DNS Servers configure their respective Zone files and so > that CPEs restrict access and protect themselves from unauthorized > DNS Queries. > > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From Ray.Bellis@nominet.org.uk Thu Jul 19 00:27:27 2012 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 7768C11E80E5 for ; Thu, 19 Jul 2012 00:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.579 X-Spam-Level: X-Spam-Status: No, score=-10.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-BjWb8+5Gn4 for ; Thu, 19 Jul 2012 00:27:26 -0700 (PDT) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 90CD311E80C5 for ; Thu, 19 Jul 2012 00:27:25 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: Content-Type:MIME-Version; b=3JnxeVl/7rNGz7wi9ziDSZIGFz/I9vOJiAxUIsk3FNf/ARn7IgVPb4Wn x6U0v72XB2gLDQMwOh8KYr4FictGnQDdjcJRmuQKJzSiRyUPWJxueSCTa y6DbAPyimn1ubEs; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1342682899; x=1374218899; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Draft=20Agenda=20uploaded|Date:=20Thu,=2019 =20Jul=202012=2007:28:01=20+0000|Message-ID:=20<97EA30AD- C943-4ABF-A894-585C1F759463@nominet.org.uk>|To:=20"homene t@ietf.org=20Group"=20|MIME-Version:=20 1.0; bh=uL8rI5FKtWZxnz6HQCCmTqRwse5cWVHN3ho7H0o63g8=; b=53A9L9MGroeQB3plK82mgGMB+9h6wpOCWHUAR0ykW3nPmy77copPVDmj 5DtmFqsiQzMxa8QCVgt/a9ZhWThokw4mJS+jIpfnWriMVMnPrMJeFFKiw n6yag9Dl9bcPvN2; X-IronPort-AV: E=Sophos;i="4.77,615,1336345200"; d="scan'208,217";a="34227355" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx4.nominet.org.uk with ESMTP; 19 Jul 2012 08:28:02 +0100 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%19]) with mapi; Thu, 19 Jul 2012 08:28:02 +0100 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: Draft Agenda uploaded Thread-Index: AQHNZYAH5DMbomSNNE+NjBSLtfsN3Q== Date: Thu, 19 Jul 2012 07:28:01 +0000 Message-ID: <97EA30AD-C943-4ABF-A894-585C1F759463@nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_97EA30ADC9434ABFA894585C1F759463nominetorguk_" MIME-Version: 1.0 Subject: [homenet] Draft Agenda uploaded X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 07:27:27 -0000 --_000_97EA30ADC9434ABFA894585C1F759463nominetorguk_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft agenda is available at: Ray --_000_97EA30ADC9434ABFA894585C1F759463nominetorguk_ Content-Type: text/html; charset="us-ascii" Content-ID: <1ab657a2-8f7d-479a-a367-6dfc9f0a181f> Content-Transfer-Encoding: quoted-printable The draft agenda is available at:

Ray

= --_000_97EA30ADC9434ABFA894585C1F759463nominetorguk_-- From mcr@sandelman.ca Mon Jul 23 15:23:36 2012 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 0E2BE11E80CF for ; Mon, 23 Jul 2012 15:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFiqfefWLOv6 for ; Mon, 23 Jul 2012 15:23:35 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEED11E80BE for ; Mon, 23 Jul 2012 15:23:29 -0700 (PDT) Received: from sandelman.ca (herring.sandelman.ca [209.87.252.231]) by relay.sandelman.ca (Postfix) with ESMTPS id DE1B18199; Mon, 23 Jul 2012 18:19:30 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7A42D9811D; Mon, 23 Jul 2012 18:23:21 -0400 (EDT) Received: from herring.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 76E94980DA; Mon, 23 Jul 2012 18:23:21 -0400 (EDT) From: Michael Richardson To: Mikael Abrahamsson In-Reply-To: References: <201207090417.q694Glub059426@gateway.ipv6.occnc.com> <4FFAB334.9070407@piuha.net> <28790.1341846114@herring.sandelman.ottawa.on.ca> <30699.1341850091@herring.sandelman.ottawa.on.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 23 Jul 2012 18:23:21 -0400 Message-ID: <23799.1343082201@herring.sandelman.ca> Sender: mcr@sandelman.ca Cc: homenet@ietf.org Subject: Re: [homenet] new version of the OSPFv3-based prefix assignment draft X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 22:23:36 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Mikael" =3D=3D Mikael Abrahamsson writes: >> Yes, but the option 82 may let one find the right lease to reuse. Mikael> I have not seen this used in real life (as it involves invalida= ting existing Mikael> lease and tell existing lease owner about it). Do you have any = references to Mikael> implementations of this behaviour? I thought that cable networks used the subscriber ID which was inserted somewhere (option 82 was the obvious place) by the CMTS (the "modem") to manage leases. I asked a cable operator and was told, no. If the subscribe changes their CPE router, they get new leases in IPv4 land. It seems, however, to me that a DHCPv6 PD server ought to therefore use some additional DHCP identifiers to avoid the problem that you noted, that you wind up having to allocate many prefixes to what ought to be recognized as a single customer. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAUA3O2YqHRg3pndX9AQJNfwQA1ZbEMVW3zKlwy4AsopRaTGbzfDpJlzGS WDP692SMZ7DcdgmjiqDjEKeoGdq+IcZHzQak0PBM8W+EdwuvXAJOHnTvztaSQ0FE WfY+O1vwRHiFqBAkQTou4KGgXftJiAoVN/2zXUfKWqvIlBt0wGD9fsMd1Nf2r26t Sxg68JTtnYI= =5SNh -----END PGP SIGNATURE----- --=-=-=-- From mglt.ietf@gmail.com Sun Jul 29 22:06:46 2012 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 D78A921F8466 for ; Sun, 29 Jul 2012 22:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.165 X-Spam-Level: X-Spam-Status: No, score=-0.165 tagged_above=-999 required=5 tests=[AWL=3.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsLeHMV3Qv1y for ; Sun, 29 Jul 2012 22:06:43 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D212211E8127 for ; Sun, 29 Jul 2012 22:06:42 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9618686obb.31 for ; Sun, 29 Jul 2012 22:06:37 -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=NKz+8gSwLql3p74gWY1cz48iBIa6ZJywMbeAnf0Sr/4=; b=0zhoZ2qZJXyuR/aQhQkZWvmDxGxcmGHSjCZa11mKspIG9W2YB/hu1qT7m2GapcVmOw Z5WVS8EttytxAmPWyELw90srgrliXcU0Qm7VUmRcsUjXxiZMJiNhE8wq7PVqDmETvNcD 8lwN1RfhqqZpx146Z5sep0BJ71s8WJJCwio8REe4Zue1HJq4oVg5WXOTeku3tmEvdQEK V9P7lhY6E8/2K+3b5AGrhW7hdLhMWs9mPUuuWFIpJ3svlPWQKdaqtAPydKuc+xCr+VTW P0L3yW6ttUyqFz2HaawGC3mnh5pfRXQt3qRwlPRzZj43rEsOBLLShJLLqITAM4WS/l2q J2vw== MIME-Version: 1.0 Received: by 10.182.39.39 with SMTP id m7mr15602899obk.20.1343624797786; Sun, 29 Jul 2012 22:06:37 -0700 (PDT) Received: by 10.182.196.38 with HTTP; Sun, 29 Jul 2012 22:06:37 -0700 (PDT) In-Reply-To: <5CF2DFF8-DB46-4295-A2E8-6792CF60F434@townsley.net> References: <5CF2DFF8-DB46-4295-A2E8-6792CF60F434@townsley.net> Date: Mon, 30 Jul 2012 07:06:37 +0200 Message-ID: From: Daniel Migault To: Mark Townsley Content-Type: multipart/alternative; boundary=f46d04478babc892cc04c60506e3 Cc: homenet@ietf.org, Wouter Cloetens , philippe.lemordant@orange.com Subject: Re: [homenet] Delegating Naming Architectures X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 05:06:47 -0000 --f46d04478babc892cc04c60506e3 Content-Type: text/plain; charset=ISO-8859-1 Hi Mark, Thanks for the comment. I am re-submitting the drafts tonight, with the homenet in the file name. BR, Daniel On Fri, Jul 6, 2012 at 5:33 PM, Mark Townsley wrote: > > Daniel, > > Just a bit of housekeeping... If you intend for these drafts to be > considered by homenet, it's much easier for everyone if "homenet" is > somewhere in the filename of the draft. Please consider resubmitting, if > that is your intention. > > Thank you, > > - Mark > > On Jul 3, 2012, at 12:11 PM, Daniel Migault wrote: > > Hi, > > Please find two Naming Architectures we would like to discuss at Vancouver: > - "IPv6 Home Network Naming Delegation Architecture" http://www.ietf.org/internet-drafts/draft-mglt-naming-delegation-00.txt > > - "Home Network Front End Naming Delegation" http://www.ietf.org/internet-drafts/draft-mglt-front-end-naming-delegation-00.txt > > Comments and suggestions are welcome. > > Best Regards > > Daniel > > > Abstract: "IPv6 Home Network Naming Delegation Architecture" > > This document describes the Naming Delegation Architecture that makes > IPv6 Home Network globally reachable with Names or Fully Qualified > Domain Names (FQDN). In this architecture, the Customer Premise > Equipment (CPE) acts as the DNS Authoritative Server of the Home > Network also called the Delegated DNS Server. The Naming Delegation > is configured between the Delegated DNS Server and the Delegating DNS > Server managed by the ISP. > > The use case considered in this document is an End User that > subscribes its ISP a specific Delegated Domain for its Home Network. > This document describes how the CPE automatically sets the Naming > Delegation between the Delegating and Delegated DNS Server. > > The Naming Delegation is requested by the CPE. The CPE DHCP Client > and the ISP DHCP Server exchange DHCP Options to properly set the > Naming Delegation. More specifically, the CPE DHCP Client (resp. the > ISP DHCP Server) configures the DNS(SEC) Zones of the Delegated DNS > Server (resp. Delegating DNS Server). For the Delegating DNS Server, > the necessary pieces of information required to set the Naming > Delegation are the IP address of the Delegated DNS Server, and if > DNSSEC is used, the Delegation of Signing Information. For the > Delegated DNS Server, the necessary information is the Delegated > Domain associated to the Home Network. > > > Abstract: "Home Network Front End Naming Delegation" > > This document proposes a Naming Delegation Architecture that makes > possible End Users to reach the hosts or services of their Home > Network using Names instead of IP addresses. > > This document shows how the Naming Delegation between the CPE and the > ISP can be set so the CPE is not exposed on the Internet. This > document describes an Naming Architecture where ISPs provide Front > End Delegating DNS Servers whereas the CPEs constitute a Back End > Network of Delegated DNS Servers. All DNS queries for any Home > Network are addressed to the Delegating Front End Server. The > response is expected to be stored on a CPE, and the Front End > Delegating DNS Server sends a DNS Query to that CPE before answering > to the initial DNS query. > > The negotiation between the CPE and the ISP is using DHCP Options. > This document provides options so Front End Delegating and the > Delegated DNS Servers configure their respective Zone files and so > that CPEs restrict access and protect themselves from unauthorized > DNS Queries. > > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --f46d04478babc892cc04c60506e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mark,

Thanks for the comment. I am re-submitting the drafts toni= ght, with the homenet in the file name.

BR,

Daniel

On Fri, Jul 6, 2012 at 5:33 PM, Mark Townsley <ma= rk@townsley.net> wrote:
Daniel,=A0

Just a bit of housekeeping.= .. If you intend for these drafts to be considered by homenet, it's muc= h easier for everyone if "homenet" is somewhere in the filename o= f the draft. Please consider resubmitting, if that is your intention.=A0

Thank you,

- Mark

On Jul 3, 2012, at 12:11 PM, Daniel Migault w= rote:

Hi,

Please find two Naming Architectures we would like to discuss at=
 Vancouver:
    - "IPv6 Home Network Naming Delegation Architecture=
"  http://www.ietf.org/internet-drafts/draf=
t-mglt-naming-delegation-00.txt


    - "Home Network Front End Naming Delegation" http://www.ietf.org/internet-drafts/draft-mglt-front-e=
nd-naming-delegation-00.txt



Comments and suggestions are welcome.

Best Regards

Daniel=



Abstract: "IPv6 Home Network Naming Delegation =
Architecture"

   This document describes the Naming Delegation Architecture that makes
   IPv6 Home Network globally reachable with Names or Fully Qualified
   Domain Names (FQDN).  In this architecture, the Customer Premise
   Equipment (CPE) acts as the DNS Authoritative Server of the Home
   Network also called the Delegated DNS Server.  The Naming Delegation
   is configured between the Delegated DNS Server and the Delegating DNS
   Server managed by the ISP.

   The use case considered in this document is an End User that
   subscribes its ISP a specific Delegated Domain for its Home Network.
   This document describes how the CPE automatically sets the Naming
   Delegation between the Delegating and Delegated DNS Server.

   The Naming Delegation is requested by the CPE.  The CPE DHCP Client
   and the ISP DHCP Server exchange DHCP Options to properly set the
   Naming Delegation.  More specifically, the CPE DHCP Client (resp. the
   ISP DHCP Server) configures the DNS(SEC) Zones of the Delegated DNS
   Server (resp. Delegating DNS Server).  For the Delegating DNS Server,
   the necessary pieces of information required to set the Naming
   Delegation are the IP address of the Delegated DNS Server, and if
   DNSSEC is used, the Delegation of Signing Information.  For the
   Delegated DNS Server, the necessary information is the Delegated
   Domain associated to the Home Network.

Abstract: "Hom=
e Network Front End Naming Delegation"

   This document proposes a Naming Delegation Architecture that makes
   possible End Users to reach the hosts or services of their Home
   Network using Names instead of IP addresses.

   This document shows how the Naming Delegation between the CPE and the
   ISP can be set so the CPE is not exposed on the Internet.  This
   document describes an Naming Architecture where ISPs provide Front
   End Delegating DNS Servers whereas the CPEs constitute a Back End
   Network of Delegated DNS Servers.  All DNS queries for any Home
   Network are addressed to the Delegating Front End Server.  The
   response is expected to be stored on a CPE, and the Front End
   Delegating DNS Server sends a DNS Query to that CPE before answering
   to the initial DNS query.

   The negotiation between the CPE and the ISP is using DHCP Options.
   This document provides options so Front End Delegating and the
   Delegated DNS Servers configure their respective Zone files and so
   that CPEs restrict access and protect themselves from unauthorized
   DNS Queries.


--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
_______________________________________________
homenet mailing list
= homenet@ietf.org<= br>https://www.ietf.org/mailman/listinfo/homenet




-= -
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
--f46d04478babc892cc04c60506e3-- From mglt.ietf@gmail.com Sun Jul 29 22:54:35 2012 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 7BC1B11E8099 for ; Sun, 29 Jul 2012 22:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 tagged_above=-999 required=5 tests=[AWL=2.575, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdDHdJQzUIrl for ; Sun, 29 Jul 2012 22:54:34 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id F07B111E8098 for ; Sun, 29 Jul 2012 22:54:33 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9684354obb.31 for ; Sun, 29 Jul 2012 22:54:33 -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=3kk0OAVDarlN8AjRjVcabo4KcPDPak2qFFjuaoJZkZM=; b=bwa7+dFfryIuz2S38W1W7kgWikTTXDDrX3+kOCnjhOsp6JKGXQBknbn6LvmlXDiPbM WNq5YikMQR9KKrZdVJneqsCutFArGaoGkqIoFa5YyeFd1qAK3CAMLwg6U7MmwGJbkcr4 Nwp9bbnTjYP33oY8c4sSFMZKDrTx+U8VGIYwwDpYQHbUGXJA3O1eOap+OGXCXUNm5zAS cjkserruP7ahHSSSrGL+patz/KVMShAVyNGYXXklzerM90Et1QuCOFwGgGJaMLknvsru bQaeOIcv4okc9NJRWp4LBis2ncf/LCXA6suKPDdUTyXQcELnVjs29T/IHm7UZAsLg9Qb KgTg== MIME-Version: 1.0 Received: by 10.60.2.34 with SMTP id 2mr15757874oer.71.1343627673503; Sun, 29 Jul 2012 22:54:33 -0700 (PDT) Received: by 10.182.196.38 with HTTP; Sun, 29 Jul 2012 22:54:33 -0700 (PDT) In-Reply-To: <20120716140939.GA16979@nic.fr> References: <20120716140939.GA16979@nic.fr> Date: Mon, 30 Jul 2012 07:54:33 +0200 Message-ID: From: Daniel Migault To: Stephane Bortzmeyer Content-Type: multipart/alternative; boundary=e89a8fb2060030876304c605b2a5 Cc: homenet@ietf.org, Wouter Cloetens , philippe.lemordant@orange.com Subject: Re: [homenet] Delegating Naming Architectures X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 05:54:35 -0000 --e89a8fb2060030876304c605b2a5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi St=E9phane, Thank you for reading the drafts. My responses are added in the text. On Mon, Jul 16, 2012 at 4:09 PM, Stephane Bortzmeyer wro= te: > On Tue, Jul 03, 2012 at 12:11:54PM +0200, > Daniel Migault wrote > a message of 155 lines which said: > > > Please find two Naming Architectures we would like to discuss at > Vancouver: > > I won't be in sunny British Columbia but I've read the drafts and I > have a philosophical question. You did not say clearly if the > delegated domain must be under an ISP's domain. If yes, it ties the > user to the ISP ("I've switched ISPs, use > and no longer > "). If no, the ISP won't be able to > update the DNS delegation. IMHO, it would be a good idea to have a > high-level discussion of the service provided to the user, before > getting into protocol details. > > The delegated domain name is under the ISP domain. If that is not clear, we will clarify it in the next version. In the current document, when the end user changes ISP, it has to change its domain name too. Actually the service the ISP provide name connectivity. Like IP addresses, phone numbers, email addresses, they are resources provided by the ISP and people understand that changing ISP, in most cases requires these resources to be changed. As Michael mentioned it is an important concern but not a new issue. The service ISP provides is different from providing a FQDN as registrars do. In order to benefit from this latest service, the end user can use CNAME/DNAME. CNAME / DNAME would need to be updated only when the end user changes ISP, rather than any time the Homenetwork is being assigned a new prefix. However, we will clarify this in the next version. > A technical remark: since the DS record is sent by the client, one can > assume that it may suddenly be a new one (key rollover). Then, DNSSEC > validation will break for validators which have the old DS in the > caches. Two possible solutions: have a very low TTL, or just say that > it is the client's job to do rollovers properly (having two DS in > parallel, etc). The second solution implies that the CPE includes > rollover logic (like OpenDNSSEC does). DNSSEC in practice is hard and > you may want to have two drafts, one without DNSSEC and one for DNSSEC > gory details. > > Good points. First we have to mention these two alternatives in the next version, even though, I think we will consider it is the client's job to perform the key rollover. Secondly, the current document does not make possible to send multiple DS, so we have to add this in the next version. I am not sure we need to split the draft for DNS and DNSSEC, but we will ask the WG. Also, a security remark. When you say: > > > First delegation preserves the Home Network privacy, by avoiding ISP > > to know the Home Network hosts. > > It certainly deserves a mention in Security Considerations saying that > it is a limited protection. Many names will be predictible ("printer", > "fridge", "nas", "iPad") and also the first DNS request to the parent > domain (which is probably controlled by the ISP) will include the > FQDN, thus revealing a name. (And I did not even mention the ability > of the ISP to sniff the network.) > You are right it is a limited protection. ISPs have means to determine the mostly used FQDN of a zone. However, this requires much processing, than if the end user provides the list of its fqdn's hosts. We will mention this in the next version too. Thank you for reading the documents! Daniel --=20 Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --e89a8fb2060030876304c605b2a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi St=E9phane,

Thank you for reading the drafts. My responses are a= dded in the text.

On Mon, Jul 16, 2012 at= 4:09 PM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Tue, Jul 03, 2012 at 12:11:54PM +0200, =A0Daniel Migault <mglt.ietf@gmai= l.com> wrote
=A0a message of 155 lines which said:

> Please find two Naming Architectures we would like to discuss at Vanco= uver:

I won't be in sunny British Columbia but I've read the drafts= and I
have a philosophical question. You did not say clearly if the
delegated domain must be under an ISP's domain. If yes, it ties the
user to the ISP ("I've switched ISPs, use
<http://fri= dge.migault.free.fr/> and no longer
<http://f= ridge.migault.orange.fr/>"). If no, the ISP won't be able t= o
update the DNS delegation. IMHO, it would be a good idea to have a
high-level discussion of the service provided to the user, before
getting into protocol details.

The delegated domain name is under the ISP domain. If= that is not clear, we will clarify it in the next version.
In the curr= ent document, when the end user changes ISP, it has to change its domain na= me too. Actually the service the ISP provide name connectivity. Like IP add= resses, phone numbers, email addresses, they are resources provided by the = ISP and people understand that changing ISP, in most cases requires these r= esources to be changed. As Michael mentioned it is an important concern but= not a new issue.
The service ISP provides is different from providing a FQDN as registrars d= o. In order to benefit from this latest service, the end user can use CNAME= /DNAME. CNAME / DNAME would need to be updated only when the end user chang= es ISP, rather than any time the Homenetwork is being assigned a new prefix= .

However, we will clarify this in the next version.


=A0
A technical remark: since the DS record is sent by the client, one can
assume that it may suddenly be a new one (key rollover). Then, DNSSEC
validation will break for validators which have the old DS in the
caches. Two possible solutions: have a very low TTL, or just say that
it is the client's job to do rollovers properly (having two DS in
parallel, etc). The second solution implies that the CPE includes
rollover logic (like OpenDNSSEC does). DNSSEC in practice is hard and
you may want to have two drafts, one without DNSSEC and one for DNSSEC
gory details.

Good points. First we have to mention these two alter= natives in the next version, even though, I think we will consider it is th= e client's job to perform the key rollover.=A0 Secondly, the current do= cument does not make possible to send multiple DS, so we have to add this i= n the next version.

I am not sure we need to split the draft for DNS and DNSSEC, but we wil= l ask the WG.


Also, a security remark. When you say:

> First delegation preserves the Home Network privacy, by avoiding ISP > to know the Home Network hosts.

It certainly deserves a mention in Security Considerations saying that
it is a limited protection. Many names will be predictible ("printer&q= uot;,
"fridge", "nas", "iPad") and also the first D= NS request to the parent
domain (which is probably controlled by the ISP) will include the
FQDN, thus revealing a name. (And I did not even mention the ability
of the ISP to sniff the network.)

You are right it is a limited protection. ISPs have = means to determine the mostly used FQDN of a zone. However, this requires m= uch processing, than if the end user provides the list of its fqdn's ho= sts. We will mention this in the next version too.


Thank you for reading the documents!

Daniel



--
Daniel Migault
Orange Labs -- Security
+33 6 70 7= 2 69 58
--e89a8fb2060030876304c605b2a5-- From Ray.Bellis@nominet.org.uk Mon Jul 30 10:56:22 2012 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 44AD611E8133 for ; Mon, 30 Jul 2012 10:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.535 X-Spam-Level: X-Spam-Status: No, score=-10.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENi1RS4pBh-x for ; Mon, 30 Jul 2012 10:56:21 -0700 (PDT) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6253821F8627 for ; Mon, 30 Jul 2012 10:56:21 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: Content-Type:MIME-Version; b=3mlXmhfuZkzxfMgnuveo6RkB+yngU9F52PH8qAds/wyuOEbQAeBs3JXX 9HtD7KThdDDi7NTqkRYj3kTuWOHh85xweYqly7CoNvEH+GsZkEvz9L9k+ jObyFqagQuwslth; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1343670981; x=1375206981; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20IETF84=20Agenda=20updated|Date:=20Mon,=2030 =20Jul=202012=2017:56:18=20+0000|Message-ID:=20<2C576F45- 5799-4047-ACF2-BC93FED9DB46@nominet.org.uk>|To:=20"homene t@ietf.org"=20|MIME-Version:=201.0; bh=ZW28lHlykTeCyA9M2VtAO7jMBNl8mciz8whHzBf7RUM=; b=OkexguYaauqZNUAFdK1a3/MGblSviw3YKoH0joR7OQt7COEJW5HSQz03 xqhB85fnNycP/fQBUgRT03LOja7fYlam3sWxEFBvOJGj7UaxsJRoCY9Eo txzlXYY755zeKp2; X-IronPort-AV: E=Sophos;i="4.77,681,1336345200"; d="scan'208,217";a="34443142" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx4.nominet.org.uk with ESMTP; 30 Jul 2012 18:56:19 +0100 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%19]) with mapi; Mon, 30 Jul 2012 18:56:19 +0100 From: Ray Bellis To: "homenet@ietf.org" Thread-Topic: IETF84 Agenda updated Thread-Index: AQHNbnyeMrrtC5DbTECsNrwsSd+AiA== Date: Mon, 30 Jul 2012 17:56:18 +0000 Message-ID: <2C576F45-5799-4047-ACF2-BC93FED9DB46@nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_2C576F4557994047ACF2BC93FED9DB46nominetorguk_" MIME-Version: 1.0 Subject: [homenet] IETF84 Agenda updated X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 17:56:22 -0000 --_000_2C576F4557994047ACF2BC93FED9DB46nominetorguk_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The session agenda for IETF84 has been updated: http://www.ietf.org/proceedings/84/agenda/agenda-84-homenet We have one volunteer note taker. We would appreciate advance volunteers f= or another note taker and jabber relays! thanks, Ray & Mark --_000_2C576F4557994047ACF2BC93FED9DB46nominetorguk_ Content-Type: text/html; charset="us-ascii" Content-ID: <1e80516f-9bc0-4c47-a7a2-39f5a5b99e3a> Content-Transfer-Encoding: quoted-printable The session agenda for IETF84 has bee= n updated:


We have one volunteer note taker. =  We would appreciate advance volunteers for another note taker and jab= ber relays!

thanks,

Ray &= amp; Mark


= --_000_2C576F4557994047ACF2BC93FED9DB46nominetorguk_-- From jhw@apple.com Mon Jul 30 11:52:24 2012 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 8405211E8163 for ; Mon, 30 Jul 2012 11:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHnDUsQZWzNm for ; Mon, 30 Jul 2012 11:52:23 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id ADAC511E8151 for ; Mon, 30 Jul 2012 11:52:23 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M7Z00CUCLN5MF26@mail-out.apple.com> for homenet@ietf.org; Mon, 30 Jul 2012 11:52:23 -0700 (PDT) X-AuditID: 11807137-b7f626d0000059a0-da-5016d7e62702 Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 05.67.22944.6E7D6105; Mon, 30 Jul 2012 11:52:22 -0700 (PDT) From: james woodyatt Message-id: <4999ED78-B0DF-4DE7-9B51-0524592E5061@apple.com> Date: Mon, 30 Jul 2012 11:52:22 -0700 To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGJMWRmVeSWpSXmKPExsUieJDXQffZdbEAg/bzVhbvFx1icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsYz71kKtvNWnLvxiLmB8QVXFyMnh4SAiUTD7IPMELaYxIV7 69m6GLk4hARmM0lM7bzICJJgE1CR+Hb5LhOIzSygJXHj30soW1ti2cLXYM3CAiISC57/ZgGx eQVsJNrO/AGLswioSkzvaGUFsUUE9CWeHvnFBlGjJzG7fQ4LxGJZie+Hz7NNYOSZhWTFLCQr ZiFpWcDIvIpRsCg1J7HS0EwvsaAgJ1UvOT93EyMoNBoKzXcwbv8rd4hRgINRiYfX8ZBYgBBr YllxZe4hRgkOZiUR3osngEK8KYmVValF+fFFpTmpxYcYpTlYlMR5/y4XChASSE8sSc1OTS1I LYLJMnFwSjUwLmNlZdtuXPL4xZKXFyUyVFjb087sLvofNCv1V3edhauGqlvA/nuFZn+vWYe8 NtpyRuLIxNPF1uu841T4vj4Kuv5CL0nZp1VfpPhc2L6qLUUT9jJ8NhXo5ws56il4xPObMbvy caH5XyXatl9zvF/00PrPfvZdZT0b1ZnfMWzVfsqqW39mu4aPEktxRqKhFnNRcSIAmXO3iQkC AAA= Subject: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 18:52:24 -0000 everyone-- Before we get too far down the road dreaming up how to register names for hosts on home networks, I'd like to suggest gently that a related problem, i.e. how to register authoritative name services for the subdomains of ip6.arpa corresponding to prefixes delegated to home networks, is a lot more pressing. For your consideration, my personal home server currently resides at 2001:5a8:4:2290::102. Here's what dig -x currently returns for that IPv6 host address: > $ dig -x 2001:5a8:4:2290::102 > > ; <<>> DiG 9.8.1-P1 <<>> -x 2001:5a8:4:2290::102 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2427 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;2.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.2.2.4.0.0.0.8.a.5.0.1.0.0.2.ip6.arpa. IN PTR > > ;; ANSWER SECTION: > 2.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.2.2.4.0.0.0.8.a.5.0.1.0.0.2.ip6.arpa. 86400 IN PTR grymling.conjury.org. > > ;; Query time: 371 msec > ;; SERVER: 2620:149:5:f09::53#53(2620:149:5:f09::53) > ;; WHEN: Mon Jul 30 11:43:57 2012 > ;; MSG SIZE rcvd: 124 The steps I had to go through to be sure that such queries were answerable were not the steps I would want to defend in a feature usability review. I realize that solving this problem with a standard would involve more working groups than HOMENET, but clearly the effort needs to start here. Once we have a good idea how to solve this problem, then I think it will be easier to talk about forward DNS coherently. -- james woodyatt member of technical staff, core os networking From Ray.Bellis@nominet.org.uk Mon Jul 30 13:26:12 2012 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 8BD9911E8133 for ; Mon, 30 Jul 2012 13:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpYGyQOC-xNF for ; Mon, 30 Jul 2012 13:26:11 -0700 (PDT) Received: from mx3.nominet.org.uk (mail.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3C211E8126 for ; Mon, 30 Jul 2012 13:26:09 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=P1vyKQDfYyojqhHM5N8CYiSs2QmOY0RXlDsnRHMFbpD9Sa8Hs6KclCaz 0Q1yXSqM8OCj2jwy11ueNsEn1ZJ+O+3/9X0f+lhl3tc0cEnvWkBxN2WaG MXO0npdWmc0HvHD; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1343679971; x=1375215971; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20Reverse=20DNS|Date:=20Mon, =2030=20Jul=202012=2020:26:07=20+0000|Message-ID:=20|To:=20ja mes=20woodyatt=20|CC:=20"homenet@ietf.org =20Group"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<981c6c58-bbec-44b9-8327-e29a216d1e93> |In-Reply-To:=20<4999ED78-B0DF-4DE7-9B51-0524592E5061@app le.com>|References:=20<4999ED78-B0DF-4DE7-9B51-0524592E50 61@apple.com>; bh=Qd3VvcYOnFQ1zgPGYCaHPJR+nl69SxlMKv4+jc7FwlE=; b=R54a7BjuMo9w6BOO7MvuDE422JlPHE4QShy8AEgJ43IXNvhWbFoEprax SAjrWALjGxODQ/nMsBZ3rYKpV2BclZRGcPEsWnrNb5TatdLcgce/ElYuQ MM5axIjmbGy0xe0; X-IronPort-AV: E=Sophos;i="4.77,681,1336345200"; d="scan'208";a="41939508" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx3.nominet.org.uk with ESMTP; 30 Jul 2012 21:26:08 +0100 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%19]) with mapi; Mon, 30 Jul 2012 21:26:07 +0100 From: Ray Bellis To: james woodyatt Thread-Topic: [homenet] Reverse DNS Thread-Index: AQHNboSLVGLL7xVC20e+bCpkKutovZdCNUyA Date: Mon, 30 Jul 2012 20:26:07 +0000 Message-ID: References: <4999ED78-B0DF-4DE7-9B51-0524592E5061@apple.com> In-Reply-To: <4999ED78-B0DF-4DE7-9B51-0524592E5061@apple.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <981c6c58-bbec-44b9-8327-e29a216d1e93> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 20:26:12 -0000 On 30 Jul 2012, at 11:52, james woodyatt wrote: > I'd like to suggest gently that a related problem, i.e. how to register a= uthoritative name services for the subdomains of ip6.arpa corresponding to = prefixes delegated to home networks, is a lot more pressing. Could you explain _why_ you consider it more pressing? As I understand it, the consensus in groups such as DNSOP is that there's n= o need for reverse DNS for end-user IPv6 hosts. Ray From mellon@fugue.com Mon Jul 30 13:28:19 2012 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 EB90911E8146 for ; Mon, 30 Jul 2012 13:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd2YdAcHkoj7 for ; Mon, 30 Jul 2012 13:28:19 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A4DAD11E8133 for ; Mon, 30 Jul 2012 13:28:18 -0700 (PDT) Received: from [IPv6:2001:df8::80:b5a5:d85d:6d94:3df8] (unknown [IPv6:2001:df8:0:80:b5a5:d85d:6d94:3df8]) by toccata.fugue.com (Postfix) with ESMTPSA id 343CF2380C5D; Mon, 30 Jul 2012 16:28:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_396FF1C2-52D9-4B18-A6C9-4CCBB8AA1530" From: Ted Lemon In-Reply-To: <4999ED78-B0DF-4DE7-9B51-0524592E5061@apple.com> Date: Mon, 30 Jul 2012 13:28:15 -0700 Message-Id: <47B88B0C-EA3E-4222-85A1-95C9D1E67CD3@fugue.com> References: <4999ED78-B0DF-4DE7-9B51-0524592E5061@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1278) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 20:28:20 -0000 --Apple-Mail=_396FF1C2-52D9-4B18-A6C9-4CCBB8AA1530 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 30, 2012, at 11:52 AM, james woodyatt wrote: > I realize that solving this problem with a standard would involve more = working groups than HOMENET, but clearly the effort needs to start here. = Once we have a good idea how to solve this problem, then I think it = will be easier to talk about forward DNS coherently. The work's already started in the dhc working group: http://tools.ietf.org/id/draft-lemon-dhc-dns-pd-01.txt I'd be curious to hear your feedback on this draft. --Apple-Mail=_396FF1C2-52D9-4B18-A6C9-4CCBB8AA1530 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I realize = that solving this problem with a standard would involve more working = groups than HOMENET, but clearly the effort needs to start here. =  Once we have a good idea how to solve this problem, then I think = it will be easier to talk about forward DNS = coherently.

The work's already = started in the dhc working group:


= I'd be curious to hear your feedback on this = draft.

= --Apple-Mail=_396FF1C2-52D9-4B18-A6C9-4CCBB8AA1530-- From bkerensa@gmail.com Mon Jul 30 13:45:55 2012 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 1699211E818F for ; Mon, 30 Jul 2012 13:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d00N-jzgsTmz for ; Mon, 30 Jul 2012 13:45:54 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 39BB111E8133 for ; Mon, 30 Jul 2012 13:45:54 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so10349949pbc.31 for ; Mon, 30 Jul 2012 13:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=76N7+vRaFnC8V6IsXA9J6778WY0vd9JIi2A6zE/vcuA=; b=J+xsLh7qXT9GMGazlpcXzPdCCTlmEJsL90er7VFVQz2vtvSurM2In48wXPDctXoSc4 FaKqBTQpj7XV6dPqWNoCBkcJynL9Tc2LEqfJN8IO/WjPdfrwP3AZDYD+1Rtv1nr3Zz/q dJjbRsnuxWVeFCe/venz6L4/qED8MrCgjYw4wpcZ5spcnVYD3bq4nF/Yv8VeZfLASgnG 2hA4MBZT4oszudqnLFN2IqvJf2NQ9jIaTy4PJhFMuJql3UJGRpziDdEe7+KqPz3VHdQ2 wkB6Y6+qxwC26RqVdWV7Fl6+EzSRObBA+GyPIy8JMAHrHcyvNlLNj/2feE3ysTpfOCRf 2g8A== Received: by 10.68.204.129 with SMTP id ky1mr39032448pbc.32.1343681150763; Mon, 30 Jul 2012 13:45:50 -0700 (PDT) Received: from [192.168.1.113] (c-67-171-138-170.hsd1.or.comcast.net. [67.171.138.170]) by mx.google.com with ESMTPS id oo6sm8565910pbc.22.2012.07.30.13.45.49 (version=SSLv3 cipher=OTHER); Mon, 30 Jul 2012 13:45:50 -0700 (PDT) Message-ID: <5016F27D.7050601@gmail.com> Date: Mon, 30 Jul 2012 13:45:49 -0700 From: Benjamin Kerensa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120724 Thunderbird/15.0 MIME-Version: 1.0 To: homenet@ietf.org References: <4999ED78-B0DF-4DE7-9B51-0524592E5061@apple.com> <47B88B0C-EA3E-4222-85A1-95C9D1E67CD3@fugue.com> In-Reply-To: <47B88B0C-EA3E-4222-85A1-95C9D1E67CD3@fugue.com> Content-Type: multipart/alternative; boundary="------------000307010309010704060002" X-Mailman-Approved-At: Mon, 30 Jul 2012 14:02:49 -0700 Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 20:45:55 -0000 This is a multi-part message in MIME format. --------------000307010309010704060002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/30/2012 01:28 PM, Ted Lemon wrote: > On Jul 30, 2012, at 11:52 AM, james woodyatt wrote: >> I realize that solving this problem with a standard would involve >> more working groups than HOMENET, but clearly the effort needs to >> start here. Once we have a good idea how to solve this problem, then >> I think it will be easier to talk about forward DNS coherently. > > The work's already started in the dhc working group: > > http://tools.ietf.org/id/draft-lemon-dhc-dns-pd-01.txt > > I'd be curious to hear your feedback on this draft. > The draft looks good so far --------------000307010309010704060002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 07/30/2012 01:28 PM, Ted Lemon wrote:
On Jul 30, 2012, at 11:52 AM, james woodyatt wrote:
I realize that solving this problem with a standard would involve more working groups than HOMENET, but clearly the effort needs to start here.  Once we have a good idea how to solve this problem, then I think it will be easier to talk about forward DNS coherently.

The work's already started in the dhc working group:


I'd be curious to hear your feedback on this draft.

The draft looks good so far

--------------000307010309010704060002-- From mcr+ietf@sandelman.ca Mon Jul 30 15:16:15 2012 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 2776611E81FC for ; Mon, 30 Jul 2012 15:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.647, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tghZYkoE9qDw for ; Mon, 30 Jul 2012 15:16:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id AC01C11E81FF for ; Mon, 30 Jul 2012 15:16:13 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id 1410720168; Mon, 30 Jul 2012 18:28:29 -0400 (EDT) From: Michael Richardson To: "homenet@ietf.org Group" In-Reply-To: References: <4999ED78-B0DF-4DE7-9B51-0524592E5061@apple.com> X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) 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 Cc: Ray Bellis , james woodyatt Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:16:15 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Ray" =3D=3D Ray Bellis writes: Ray> Ray> Could you explain _why_ you consider it more pressing? Ray> As I understand it, the consensus in groups such as DNSOP is Ray> that there's no need for reverse DNS for end-user IPv6 hosts. I'm not interested in re-opening this debate. Yeah, the DNS people don't see a need.=20=20 Application people and security people *do* see a need. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBcHqIqHRg3pndX9AQJykAP8Dq3ArrLe3eWSVlCDZLO/IXfDtXs/N1dO dHrFwaeLL0NfRVnLREHfjd2OlDcJOGddO5mga6/dIR7ujEMk687oHe32j95rN0g7 DiS5oVxEneEMDB4Nh/hYIu0kdqvAcm3pdmxV7iL2ct/6qglTWu+TjZV+/mqxRdyF LTwMv8L182M= =A43r -----END PGP SIGNATURE----- --=-=-=-- From mellon@fugue.com Mon Jul 30 15:27:02 2012 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 5E68C11E8087 for ; Mon, 30 Jul 2012 15:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHKq+OGmFy96 for ; Mon, 30 Jul 2012 15:27:01 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFB211E8097 for ; Mon, 30 Jul 2012 15:27:01 -0700 (PDT) Received: from dhcp-534c.meeting.ietf.org (dhcp-534c.meeting.ietf.org [130.129.83.76]) by toccata.fugue.com (Postfix) with ESMTPSA id E7F2B2380756; Mon, 30 Jul 2012 18:26:59 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_95F43FF0-6768-487A-8EC8-AC8215B27225" From: Ted Lemon In-Reply-To: Date: Mon, 30 Jul 2012 15:26:58 -0700 Message-Id: References: <4999ED78-B0DF-4DE7-9B51-0524592E5061@apple.com> To: Ray Bellis X-Mailer: Apple Mail (2.1278) Cc: "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:27:02 -0000 --Apple-Mail=_95F43FF0-6768-487A-8EC8-AC8215B27225 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 30, 2012, at 1:26 PM, Ray Bellis wrote: > As I understand it, the consensus in groups such as DNSOP is that = there's no need for reverse DNS for end-user IPv6 hosts. This isn't actually true. What's true is that there is no consensus = either way. Whenever we have discussions about this, a dozen people = get up to say "no reverse DNS!" And a dozen other people get up and = say "we'd like reverse DNS!" So the IETF really can't take a position = either that there shouldn't be reverse DNS, or that there should. But = standards exist that describe how you would do it if you chose to, up to = a point. The question is, should we specify how to do the missing = pieces? The goal with the dns-pd draft is to provide a mechanism that places = this decision firmly in the hands of the operator and knowledgeable = users, rather than simply allowing it to fail by default, or requiring = that all users, knowledgable or not, accept the same functionality. --Apple-Mail=_95F43FF0-6768-487A-8EC8-AC8215B27225 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii As I = understand it, the consensus in groups such as DNSOP is that there's no = need for reverse DNS for end-user IPv6 = hosts.

This isn't actually true. =   What's true is that there is no consensus either way.   = Whenever we have discussions about this, a dozen people get up to say = "no reverse DNS!"   And a dozen other people get up and say "we'd = like reverse DNS!"   So the IETF really can't take a position = either that there shouldn't be reverse DNS, or that there should.   = But standards exist that describe how you would do it if you chose to, = up to a point.   The question is, should we specify how to do the = missing pieces?

The goal with the dns-pd draft = is to provide a mechanism that places this decision firmly in the hands = of the operator and knowledgeable users, rather than simply allowing it = to fail by default, or requiring that all users, knowledgable or not, = accept the same functionality.

= --Apple-Mail=_95F43FF0-6768-487A-8EC8-AC8215B27225-- From lee.howard@twcable.com Mon Jul 30 15:28:26 2012 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 6459111E8097 for ; Mon, 30 Jul 2012 15:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaShSI4DDfZh for ; Mon, 30 Jul 2012 15:28:26 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id BBB7E11E8087 for ; Mon, 30 Jul 2012 15:28:25 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,681,1336363200"; d="scan'208";a="399555878" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 30 Jul 2012 18:28:10 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 30 Jul 2012 18:28:24 -0400 From: "Howard, Lee" To: Michael Richardson , "homenet@ietf.org Group" Date: Mon, 30 Jul 2012 18:28:24 -0400 Thread-Topic: [homenet] Reverse DNS Thread-Index: Ac1uoqG1RnNUy0SsQn6ulhW1pgbXHg== Message-ID: In-Reply-To: <29105.1343686568@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ray Bellis , james woodyatt Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:28:26 -0000 On 7/30/12 3:16 PM, "Michael Richardson" wrote: > >>>>>> "Ray" =3D=3D Ray Bellis writes: > Ray> > > Ray> Could you explain _why_ you consider it more pressing? > > Ray> As I understand it, the consensus in groups such as DNSOP is > Ray> that there's no need for reverse DNS for end-user IPv6 hosts. > >I'm not interested in re-opening this debate. >Yeah, the DNS people don't see a need. >Application people and security people *do* see a need. Who? I've heard a lot of people say, "Them," but I've never heard anyone say, "Me." Lee This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From mike@mtcc.com Mon Jul 30 16:03:17 2012 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 C2BBD21F8625 for ; Mon, 30 Jul 2012 16:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.887 X-Spam-Level: X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FY858r2dvc2o for ; Mon, 30 Jul 2012 16:03:17 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 18EB021F861F for ; Mon, 30 Jul 2012 16:03:17 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6UI8E9Y016239 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 30 Jul 2012 11:08:14 -0700 Message-ID: <5016CD8E.1000008@mtcc.com> Date: Mon, 30 Jul 2012 11:08:14 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=338; t=1343671695; x=1344535695; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20a=20modest=20proposal |Sender:=20 |To:=20=22=22=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=TSE6u72n1NnYVuDExPL4RpAaVFjrfbHWn/8VczzLwSA=; b=Qmc4iWjUkD4PUe2nAI3sewSO3TZIFUJlDTIqCMXvHoZe81u5cEyJNnIwdN H02BuhLfGWCRNlnAaTFucpLHbcJlBWfAzQKgaQ10Aan7iE8jyQqlaFZu6aMM pedrfBz+M0TKiOodMOGhLhdm43wKIZ8pPAE9MdY7heF01yg4H6yKI=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:03:17 -0000 I know this is ietf week, but... If we believe that ipv6 is ready to go for mass deployment, why do we not pressure home router vendors to default to sending router advertisements with ULA addresses that, if necessary, get NAT'd at the border just like 192.168 space does today. I mean, nothing bad would happen, right? Mike From mike@mtcc.com Mon Jul 30 16:03:19 2012 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 552BB11E80AE for ; Mon, 30 Jul 2012 16:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.857 X-Spam-Level: X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nM2FwaadFiMz for ; Mon, 30 Jul 2012 16:03:18 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 63D9721F8623 for ; Mon, 30 Jul 2012 16:03:17 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6UJ8sjI004367 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Jul 2012 12:08:54 -0700 Message-ID: <5016DBC6.6030105@mtcc.com> Date: Mon, 30 Jul 2012 12:08:54 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Daniel Migault References: <20120716140939.GA16979@nic.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2050; t=1343675336; x=1344539336; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Delegating=20Naming=20Archi tectures |Sender:=20 |To:=20Daniel=20Migault=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=208bit |MIME-Version:=201.0; bh=xkOKDhyZL7dHKD1OWxvAZ7RXoEGsfJqLVixGMLQ6u9s=; b=f0Jiqy/uqoGuErq7GcFUD5crCHrdCBCqweHZ3DWQ42QmxR3NUqQEJkisAp RyWfZ7d1aDlKN31w7g3A+PmzfFFsmAOi0OEwyYDQdCozu3peFy/zvRiXWIPv 3Z/Gl4M3Vj6DV4FyOhiwnYieeSNEn0gkb7GQkZh7d/yHrbUXpe+s8=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Wouter Cloetens , homenet@ietf.org, Stephane Bortzmeyer , philippe.lemordant@orange.com Subject: Re: [homenet] Delegating Naming Architectures X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:03:19 -0000 On 07/29/2012 10:54 PM, Daniel Migault wrote: > Hi Stéphane, > > Thank you for reading the drafts. My responses are added in the text. > > On Mon, Jul 16, 2012 at 4:09 PM, Stephane Bortzmeyer > wrote: > > On Tue, Jul 03, 2012 at 12:11:54PM +0200, > Daniel Migault > wrote > a message of 155 lines which said: > > > Please find two Naming Architectures we would like to discuss at Vancouver: > > I won't be in sunny British Columbia but I've read the drafts and I > have a philosophical question. You did not say clearly if the > delegated domain must be under an ISP's domain. If yes, it ties the > user to the ISP ("I've switched ISPs, use > and no longer > "). If no, the ISP won't be able to > update the DNS delegation. IMHO, it would be a good idea to have a > high-level discussion of the service provided to the user, before > getting into protocol details. > > The delegated domain name is under the ISP domain. If that is not clear, we will clarify it in the next version. Shouldn't we consider the case of over the top providers too? That is, suppose that, oh say, google wanted to get into the DNS naming business. There's nothing really stopping them or anybody else, nor do I think we should limit them. I'm a little confused by the section of why DHCP is needed here between ISP and CPE. With bind, for example, it's very easy to set up an authoritative server to be a slave for zone transfers. That is, you can set up CPE to be the master of zone information and do zone transfers to an authoritative server with lots of bandwidth, etc. This has the property that it decouples the locality requirement with DHCP, so yahoo-names works too in addition to $ISP. And of course, it need not involve CPE at all because naming could all be done as a web UI to their DNS servers. Mike From mcr@sandelman.ca Mon Jul 30 16:06:37 2012 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 44DE111E80B8 for ; Mon, 30 Jul 2012 16:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k6z0NpzMC3S for ; Mon, 30 Jul 2012 16:06:35 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id B501611E80AE for ; Mon, 30 Jul 2012 16:06:32 -0700 (PDT) Received: from sandelman.ca (dhcp-12fc.meeting.ietf.org [130.129.18.252]) by relay.sandelman.ca (Postfix) with ESMTPS id A99168D1C for ; Mon, 30 Jul 2012 19:02:18 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C7C5BCA90D for ; Mon, 30 Jul 2012 19:06:30 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Mon, 30 Jul 2012 19:06:30 -0400 Message-ID: <5615.1343689590@sandelman.ca> Sender: mcr@sandelman.ca Subject: [homenet] how to bookmark .lan,/.home,/.my-homenet when not home X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:06:37 -0000 while reading drafts on the airplane, I have come to think that picking any specific name a la ".local" for the homenet name service is fraught with RFC1918-like confusion. For the actual printer and refridgerator (which does not move, but needs to talk to the TV) it's not a big deal, but for mobile devices, I think it's gonna lead to confusion. When I'm at your house, and I visit "fridge.local", do I get your fridge, or mine? Assuming I want mine, if I've discovered it when I was at home, how would I bookmark and remember it, assuming it had a GUA? I therefore propose adding a level of indirection (because that solves every problem....), which (mobile) hosts will ideally become aware of. I think of this as a layer above the current LLMNR/mDNS/Bonjour++ layer. My idea is that the .homenet/.local discovery protocol would, in addition to the AAAA ULA or GUA record, would provide a reference a unique name which might not be globally resolvable from the DNS root, but can be resolved by arrangement. This would be not unlike split-horizon DNS, but given IPv6 reachability, no VPN necessary. For sites where mglt-name-delegation works, great, use that! For those where this doesn't work, we need a new well known name. Perhaps it can find a "logical" place in arpa. Let's say it's based upon the ULA, and the home with prefix A:B:C:D gets D.C.B.A.homenet.arpa. (add this to DNS search path...) When an application resolves fridge.local, if the fridge has a GUA which it has provided to the CPE's DNS server, then it also returns a pointer to the "long-term name" (probably in a new RR) like "fridge.D.C.B.A.homenet.arpa". Any bookmarks and the like would contain that address (HTTP/HTML has existing mechanisms to deal with this), other applications might see this as the canonical name. (getaddrinfo(3) already has a canonname) My idea is that given IPv6 reachability for the HOME's CPE(s), that a mobile recursive (secure) DNS resolver can learn to make queries for D.C.B.A.homenet.arpa. directly to the home CPE, even when the mobile device is not "at home". The mobile device needs to be "pair"ed with the CPE such that it agrees to do this side-ways lookup. It's pretty much identical to a windows desktop joining an AD (but I can't speak to the "home edition" being able to do that... don't do windows). This process is, I admit, a form of walled garden DNS, something I've argued against as being unnecessary. I'd rather that the ISPs provided a name, but I feel that ISPs won't be very fast to offer this, and for the home user with no native IPv6 (using a managed tunnel, for instance), that a protocol such as I am suggesting, would provide a clear value (something people would brag about to their friends...) without requiring people to "wait" for their ISP. This does not replace "fridge.local" referring to the fridge on the network that you are on, but it does provide a way to easily discover and then bookmark "my fridge". (written offline using xemacs on android) From mcr@sandelman.ca Mon Jul 30 16:07:05 2012 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 C700B11E80B8 for ; Mon, 30 Jul 2012 16:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HgJ4HtfQUFr for ; Mon, 30 Jul 2012 16:07:03 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB9911E80AE for ; Mon, 30 Jul 2012 16:07:03 -0700 (PDT) Received: from sandelman.ca (dhcp-12fc.meeting.ietf.org [130.129.18.252]) by relay.sandelman.ca (Postfix) with ESMTPS id F18508D1C for ; Mon, 30 Jul 2012 19:02:43 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9F701CA913 for ; Mon, 30 Jul 2012 19:06:56 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Mon, 30 Jul 2012 19:06:56 -0400 Message-ID: <5655.1343689616@sandelman.ca> Sender: mcr@sandelman.ca Subject: [homenet] section 3.2.2.1 of homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:07:06 -0000 I read arch-04. I want to suggest some minor changes to section 3.2.2.1. First, we have 8 IPv6 Hosts, can we number/name them H1 through H8? Second, H3 and H4 have, I guess, two network interfaces, can we number them as H3.B, H3.E and H4.B/H4.E. (Diagrams in section 3.2.2.2 should number their hosts too. I don't know if they should be H9-H12, or H1-H4) The top label for Network B/E should say instead "Network B(E)" and the bottom label for Network B/E should say instead "Network E(B)" I suggest labelling the link from CER to Internal Router as "Link F" (or Network F) I wonder if we should identify architectural statements as numbered requirements. This doesn't have to imply that we write things in a list form. I suggest adding this text to 3.2.2.1, after the diagram; ==== In this diagram there is one CER. It has a single uplink interface. It has three additional interfaces connected to Network A, Link F, and Network B. IPv6 Internal Router (IR) has four interfaces connected to Link F, Network C, Network D and Network E. Network B and Network E have been bridged, likely inadvertedly. This could be as a result of connecting a wire between a switch for Network B and a switch for Network E. Any of logical Networks A through F might be wired or wireless. Where multiple hosts are shown, this might be through one or more physical ports on the CER or IPv6 (IR), wireless networks, or through one or more layer-2 only ethernet switches. ==== page 21, paragraph 2, "the internal operation": s/should/SHOULD/ section 3.4.2 as well. oh, wait. no RFC2119 text at all. Is it inappropriate for an architecture to state requirements in 2119 language? I'm also surprised that we think we have to cope with flash renumbering as a regular event, rather than a service-interrupting, ISP truck roll catastrophy. From jhw@apple.com Mon Jul 30 16:08:00 2012 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 F229F11E80B8 for ; Mon, 30 Jul 2012 16:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8x9P7yYQVO01 for ; Mon, 30 Jul 2012 16:07:59 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 18BCE11E80AE for ; Mon, 30 Jul 2012 16:07:59 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0M7Z00CNBXAWMFH8@mail-out.apple.com> for homenet@ietf.org; Mon, 30 Jul 2012 16:07:49 -0700 (PDT) X-AuditID: 11807130-b7fb86d000004da6-5c-501713c5835d Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 89.DB.19878.5C317105; Mon, 30 Jul 2012 16:07:49 -0700 (PDT) From: james woodyatt In-reply-to: <47B88B0C-EA3E-4222-85A1-95C9D1E67CD3@fugue.com> Date: Mon, 30 Jul 2012 16:07:49 -0700 Message-id: References: <4999ED78-B0DF-4DE7-9B51-0524592E5061@apple.com> <47B88B0C-EA3E-4222-85A1-95C9D1E67CD3@fugue.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42IRPMjroHtUWDzA4GePrMX7RYdYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcevffraCmWIVDQ88Ghj/CHYxcnJICJhITJj9hwnCFpO4cG89 WxcjF4eQwGwmiZMbDrGDJJgFtCRu/HsJVsQroCcxu30OC4gtLKAksXTVYlYQm01AReLb5btg NZwCthJHLixgBLFZBFQlXh4/BTVHW2LZwtfMEHNsJNa9PgxmCwnkSqzsuAJmiwjoSzw98osN 4iBZie+Hz7NNYOSbheSMWUjOmIVk7AJG5lWMgkWpOYmVhoZ6iQUFOal6yfm5mxhBgdRQaLCD ce1P/kOMAhyMSjy8jofEAoRYE8uKK3MPMUpwMCuJ8OZyiAcI8aYkVlalFuXHF5XmpBYfYpTm YFES5/29XChASCA9sSQ1OzW1ILUIJsvEwSnVwHh20dVHP5Plf+0vrWLhVksx2XX6817GJRvt gxXiDPc4fTuxhuHKlABLg8qXO8W1ah8FdngvrJj0yZe9jSP38I7O3sdpx798VnYP9M2NcvhT FPVjUYxcMNd8v6JlptXcC44HyGu6b7skVPTuuSFrZv0C6WtOG9zCw18xhFu8XbT2U3aPZPP6 MiWW4oxEQy3mouJEANXss8ogAgAA Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:08:00 -0000 On Jul 30, 2012, at 13:28 , Ted Lemon wrote: > > The work's already started in the dhc working group: > > > > I'd be curious to hear your feedback on this draft. That's a good submission for the DHC group. I'm thinking I'd much more like to see a specific recommendation that HOMENET gateways implement a site-managed reverse tree, optionally augmented with a zero-configuration method for generating content explicitly managed by a knowledgeable home network administrator. For example, after I install a fresh HOMENET gateway in my new house, I expect the following things just to happen correctly without any forethought: 1. The integrated DNS content server should have authority for all of the ip6.arpa corresponding to the IPv6 prefixes delegated by its service provider; 2. The integrated DNS resolving server should answer [on the local network only] for the locally generated ULA prefixes required by RFC 6106. 3. Queries for PTR records in zones for which it's authoritative should always produce a synthesized answer if no explicitly configured records are stored in the content server. For examples, 3a. dig -x fd35:5a4b:92a9:fb::1 -> fd35-5a4b-92a9-fb--1.local. 3b. dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc -> 2001-5a8-4-2290-a95f-dd2e-3201-eafc.subscriber-3021134.example.net. 4. I should be able to override explicitly the domain automatically delegated by my service provider with my own registered FQDN if I want to do so, so that example 3b above becomes: 3b.(2). dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc -> 2001-5a8-4-2290-a95f-dd2e-3201-eafc.conjury.org. 5. I should be able to override explicitly the automatically generated FQDN for any hosts on my network if I want to do so, so that examples 3a and 3b above become: 3b.(3). dig -x fd35:5a4b:92a9:fb::1 -> zardoz.local. 3b.(4). dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc -> zardoz.subscriber-3021134.example.net. 6. I should be able to do both. 3b.(5). dig -x fd35:5a4b:92a9:fb::1 -> zardoz.home.conjury.org. 3b.(6). dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc -> zardoz.conjury.org. Yes, I get that DNSOP people don't like to contemplate this problem. I don't want to debate about why I think they're wrong to defer it, but my thoughts aren't all that different from those of anyone else in the application/security community. Can we skip past the part when I enumerate them again? I guess I had hoped the HOMENET group would more easily find consensus around addressing this promptly, but that may have been wishful thinking. -- james woodyatt member of technical staff, core os networking From mcr+ietf@sandelman.ca Mon Jul 30 16:09:03 2012 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 3B69911E80C5 for ; Mon, 30 Jul 2012 16:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.641, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XD+LrK6ViVdX for ; Mon, 30 Jul 2012 16:09:02 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id 4B36B11E80DC for ; Mon, 30 Jul 2012 16:09:02 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id 1DC2720168 for ; Mon, 30 Jul 2012 19:21:19 -0400 (EDT) From: Michael Richardson To: "" In-Reply-To: <5016CD8E.1000008@mtcc.com> References: <5016CD8E.1000008@mtcc.com> X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) 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 Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:09:03 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Michael" =3D=3D Michael Thomas writes: Michael> If we believe that ipv6 is ready to go for mass deployment, wh= y do we Michael> not pressure home router vendors to default to sending router = advertisements Michael> with ULA addresses that, if necessary, get NAT'd at the border= just like Michael> 192.168 space does today. Michael> I mean, nothing bad would happen, right? Do you mean, NAT64'ed? =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBcUCoqHRg3pndX9AQIx+gP/cJafv1dSA3FcfEcv/5+PmTYv4pk9RWGZ qJu8nAdjIK4oIv/Cl60NAuayVSFZ3fsaqOYDCwcpRTiegkPnCasnBLUVqcP5hBGU pgO/ov0wM1aa3exd+ddzeTeSWl6TsRc9KYMoetMzQqsryCdcXODcZ3MXV4Isi/Yf Tfo81ocobjc= =JRf5 -----END PGP SIGNATURE----- --=-=-=-- From ek@google.com Mon Jul 30 16:09:54 2012 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 7BD0011E80BA for ; Mon, 30 Jul 2012 16:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zphZvzWhq6-d for ; Mon, 30 Jul 2012 16:09:53 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 79B2F11E80AE for ; Mon, 30 Jul 2012 16:09:53 -0700 (PDT) Received: by qaea16 with SMTP id a16so1320579qae.10 for ; Mon, 30 Jul 2012 16:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=enJQqP00HS1BV926TNz8UJtYwD+lnxfAfEZl8PRgu7U=; b=JFnl417HANuU6Sz6QXJ+uexm2XqaZnE9XSMNlxG49iPvGR6F4uizWZKtLM8FX5icDQ IPKKbXImSEzoR7kCijCnMdIRcKYbh/eZ0JxsNGrj2m8h1CLf2ypao7f9A6RV+3PmLjKA bSDxCQcGPE4wUBvPlh8mW1FcvZ/tiWgkmBhb5Uv4l7UtNOJt+OmzOIN22N/1080w8ejT f947pJlsqliSjH09oOq5c26lImni7qF4XPBMyllYwc45hVbw6BAId2NjMeYGCwf5UDZ6 zdGCEDz/jBwRefJMvlaVJ+55/aHo+P6xvLpPagAydVOJUgHiisxJyqzFenltB3AAbChF rt4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=enJQqP00HS1BV926TNz8UJtYwD+lnxfAfEZl8PRgu7U=; b=fbO/2zooveSiR9n33Nsi9Zet14B55XYcxjEiKO6NmPhQu65l3IO5cylwj+c92M37g9 EZnVszsMpFTavErvOXBjyyGRhRnM0WDguWFhe+uPsmF9n8Dy4JYh/kKtfAyXwt1l1ZIc iSzLCynymifUzHLqODQNysxqWZrwWV4y/wLQTDsI8ZLicuY2Ohzsh70DVmu0/76nkRGp OjerqSPjS+jVXjCSe3J/nY5yAju+3cYZyW5QKu6c/i5BRAvKnD+XNdiNos4w8rcvxg/2 UeqqiNbR2yLvphHu3E6oAYd5CO3dNU+NQeoA4aWJ7w3p6zQ/JOr7qPOhf3bWXt8tNjbe MhQA== Received: by 10.224.52.205 with SMTP id j13mr25937378qag.62.1343689789730; Mon, 30 Jul 2012 16:09:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.52.205 with SMTP id j13mr25937361qag.62.1343689789537; Mon, 30 Jul 2012 16:09:49 -0700 (PDT) Received: by 10.229.139.144 with HTTP; Mon, 30 Jul 2012 16:09:49 -0700 (PDT) In-Reply-To: <5016CD8E.1000008@mtcc.com> References: <5016CD8E.1000008@mtcc.com> Date: Tue, 31 Jul 2012 08:09:49 +0900 Message-ID: From: Erik Kline To: Michael Thomas Content-Type: multipart/alternative; boundary=20cf3074b1e297ff5c04c61428fd X-System-Of-Record: true X-Gm-Message-State: ALoCoQmsevyAydjehUuwEjcOmp1dqwH/ZUOjRD18L8BaPjziJC/eM6gcH2kTN/mf/zE2mf58VC7NxkHEQ26GsFX0KR2NLpm8fzaw+4/Ba+rrcar++fftGiSuhMJrRayPZDM332W9Puz6IjZuCI+EKqd4Y25eT798xMNYcVRoIzszsDRzvzQiUF4b+c5+4aPC7gG44bVuH40r Cc: "" Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:09:55 -0000 --20cf3074b1e297ff5c04c61428fd Content-Type: text/plain; charset=UTF-8 > > I mean, nothing bad would happen, right? > Even if the user doesn't have global IPv6 connectivity? And: what /good/ would happen? --20cf3074b1e297ff5c04c61428fd Content-Type: text/html; charset=UTF-8
I mean, nothing bad would happen, right?

Even if the user doesn't have global IPv6 connectivity?

And: what /good/ would happen?
--20cf3074b1e297ff5c04c61428fd-- From curtis@occnc.com Mon Jul 30 16:13:27 2012 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 11F4711E80E4 for ; Mon, 30 Jul 2012 16:13:27 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Dcp6XWJpouS for ; Mon, 30 Jul 2012 16:13:26 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id B00E811E80F6 for ; Mon, 30 Jul 2012 16:13:25 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q6UNDAkJ059526; Mon, 30 Jul 2012 19:13:10 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201207302313.q6UNDAkJ059526@gateway.ipv6.occnc.com> To: Ted Lemon From: Curtis Villamizar In-reply-to: Your message of "Mon, 30 Jul 2012 13:28:15 PDT." <47B88B0C-EA3E-4222-85A1-95C9D1E67CD3@fugue.com> Date: Mon, 30 Jul 2012 19:13:10 -0400 Cc: "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:13:27 -0000 > > = James > = Ted In message <47B88B0C-EA3E-4222-85A1-95C9D1E67CD3@fugue.com> Ted Lemon writes: > On Jul 30, 2012, at 11:52 AM, james woodyatt wrote: > > I realize that solving this problem with a standard would involve > > more working groups than HOMENET, but clearly the effort needs to > > start here. Once we have a good idea how to solve this problem, then > > I think it will be easier to talk about forward DNS coherently. > > The work's already started in the dhc working group: > > http://tools.ietf.org/id/draft-lemon-dhc-dns-pd-01.txt > > I'd be curious to hear your feedback on this draft. In most cases where a site has delegation of DNS or rDNS. it is not negociated using DHCP. This draft appears to allow that extension. That is good (IMHO). I think it would be wonderful if providers offered delegation of rDNS and making it trivial for them might not hurt. [Aside: my ISP will not do delegation of rDNS. You have to put in a support call (not web page, not email, a phone call) for any change and that is hugely time consuming for me, and very time consuming and therefore expensive for them. My ISP is stupid in some ways. My IPv6 tunnel provider OTOH has an option on their web page to specify where the rDNS name servers reside and it all works very nicely. Native IPv6 would be better but only if my ISP had a clue about rDNS.] Back to the original email. > > The steps I had to go through to be sure that such queries were > > answerable were not the steps I would want to defend in a feature > > usability review. James gave an example and I don't know what his gripe was, other than getting rDNS to work was not something the home user could tolerate. I agree with that usability point. Looking at the practical side, right now there is a good tie in between ISC dhcpd (DHCP server) and ISC bind (DNS server) for forward DNS. I don't think that rDNS is handled by ISC but I could be wrong. Even so, there is nothing preventing rDNS from being handled. The issue is then that rDNS (like DNS itself) is hard to configure with some of today's tools. ISC tools (for example) are powerful but hard to configure. Some low end routers exist that are much easier to configure, but they lack capabilities. Some of the prior discussions centered around using a default zone of local, such that if a host claimed to be host name "foo" and another claimed to be "bar" then the fqdn would be "foo.local" and "bar.local". It would then be a small matter of configuration to change "local" to "example.com" and have the fqdn reported by rDNS be "foo.example.com" and "bar.example.com". For any of this to make sense some configuration is needed. Someone has to configure "foo" as the host name on one host, and "bar" as the host name on the other, and maybe if they have just one router, they could give it a name too. This would be simple enough to configure. No protocol extension is neede to accomplish this. This is something that could be mentioned in a homenet arch document if we decide that the default local domain is a good idea (and get the appropriate blessings on this use of that TLD) and that dynamic DNS and dynamic rDNS should be available and enabled by default. There are two decisions to be made 1) dynamic DNS and rDNS should be available, 2) they should be enabled by default with "local" domain, easily configured to another name. btw - Even without delegation, accurate rDNS can be provided *locally* which for some users (like those using the default "local" domain) would be sufficient. Curtis From ek@google.com Mon Jul 30 16:13:28 2012 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 80C5411E80F7 for ; Mon, 30 Jul 2012 16:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD-3G5kJ++8o for ; Mon, 30 Jul 2012 16:13:28 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5D9E11E80D3 for ; Mon, 30 Jul 2012 16:13:27 -0700 (PDT) Received: by qcac10 with SMTP id c10so3619517qca.31 for ; Mon, 30 Jul 2012 16:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=0wX3zkZn4cupaAx/s9kAvu+AMTap0P4fcyAgT12FmaQ=; b=IUGG6XmemfiBYsfg8VlZ2W3XJKdFgS11JSSfuHPn3bdl/ROoiIvB4e072ZU6I3iIXL HC0+gjSSsSGp5rKrYFlFl0QsiNJvNa3sIyRIF1/4hpLNtEERRsi+JiELvoQ6AU25OqSK SnaN5DSpJCc/rzRMqqdsnbLcDWSFcx/AzypJ+h2ksx9mBCOpPSjoqfYSWvZ35lu1mSi8 9hhS4kpo3wY0IxULrQGkg2fCbu+ycTgFfkLURQ1TUsh/135WzFYJyjojTNPnyVPZH8xp makW9uguxi2rg5pQG0IDgN+GrIaL7gwVfClJs2q4Iu6yWBE3xma5yJKRLlO4dsr6lxOt 9zaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=0wX3zkZn4cupaAx/s9kAvu+AMTap0P4fcyAgT12FmaQ=; b=aklD+ZBzR6bTdyb+969NzAwT7T7qzbd4fCUsXhbGRrVnOINc8PVpDpxHYbTd91hvCO +oHQYrebEQUDZjODm6n+s2FrjRxLiqbCNQknla1c+siPZMqU91Cb3isl5C9deUF0+OBi 8aWoRzo5T0IWEiAXjwMWx18Blc8JdJC9oLGbmpn75kPkmHn9B066zwCbZ06Hq4cu3eeD MbkstqgwP9QQoPPLeGntKuUJhn25ytYW0oi01ukU55FXk6b/JrwG/76akNgJgcF0HYa4 8deZ29PSUl6TzVd673tjiXMP/II/Jb4q7FgpwhTpxvilMrPKAULeH9epGeYbSnTLxBUa EI0w== Received: by 10.229.135.206 with SMTP id o14mr6425884qct.91.1343690007391; Mon, 30 Jul 2012 16:13:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.206 with SMTP id o14mr6425878qct.91.1343690007274; Mon, 30 Jul 2012 16:13:27 -0700 (PDT) Received: by 10.229.139.144 with HTTP; Mon, 30 Jul 2012 16:13:27 -0700 (PDT) In-Reply-To: <5615.1343689590@sandelman.ca> References: <5615.1343689590@sandelman.ca> Date: Tue, 31 Jul 2012 08:13:27 +0900 Message-ID: From: Erik Kline To: Michael Richardson Content-Type: multipart/alternative; boundary=00248c6a66a292673604c6143536 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnAwkIfTkumjAi08sFCTTw88Jb2a9tZ7xKYEq597cg5S1HVlAFXBKbuT53pPcaB4FhlxRjNWgxeOL8V0aljiZUuNUXvkHKn9sjPnniassqyjg9x4vrxaroTWdJ7Edf0KWyGGxx0zs9GFiInQpxhqhDQP+bw6xP/3kJ16eJUjQ+rHRq5VQTE+2gjmjYpZcpTSiRKlrvK Cc: homenet@ietf.org Subject: Re: [homenet] how to bookmark .lan, /.home, /.my-homenet when not home X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:13:28 -0000 --00248c6a66a292673604c6143536 Content-Type: text/plain; charset=UTF-8 > > > For sites where mglt-name-delegation works, great, use that! > For those where this doesn't work, we need a new well known name. > Perhaps it can find a "logical" place in arpa. Let's say it's based > upon the ULA, and the home with prefix A:B:C:D gets > D.C.B.A.homenet.arpa. (add this to DNS search path...) > Whenever the home prefix is renumbered (which has happened to me already), do all the names have to change then? --00248c6a66a292673604c6143536 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

For sites where mglt-name-delegation works, great, use that!
For those where this doesn't work, =C2=A0we need a new well known name.=
Perhaps it can find a "logical" place in arpa. =C2=A0 Let's s= ay it's based
upon the ULA, and the home with prefix A:B:C:D gets
D.C.B.A.homenet.arpa. =C2=A0(add this to DNS search path...)

Whenever the home prefix is renumbered (which has hap= pened to me already), do all the names have to change then?
--00248c6a66a292673604c6143536-- From mike@mtcc.com Mon Jul 30 16:14:03 2012 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 738EC11E80E4 for ; Mon, 30 Jul 2012 16:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gS7QuI6WvAOK for ; Mon, 30 Jul 2012 16:14:02 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id C222F11E80D5 for ; Mon, 30 Jul 2012 16:14:02 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6UNE2na023762 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Jul 2012 16:14:02 -0700 Message-ID: <5017153A.9040103@mtcc.com> Date: Mon, 30 Jul 2012 16:14:02 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Michael Richardson References: <5016CD8E.1000008@mtcc.com> <6112.1343689738@obiwan.sandelman.ca> In-Reply-To: <6112.1343689738@obiwan.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=720; t=1343690042; x=1344554042; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20a=20modest=20proposal |Sender:=20 |To:=20Michael=20Richardson=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=S3bXNHtGlQ6A9rmu5D3poJPd+8PM3zYRUriNFMy19Fo=; b=mOhipDMY7PCgg985jJ0MCR7pmfZ/DBJnN+OBJk4TL9kPgDe2RyFnhaLPZY MxzVVLJE3rn0haIGXFyi4ASfD6fyZS4zqKWWUKVqh0lMVlHZa8yzTgZVWeu8 qfnTcfWcI0BLZPZEU2citGuqh8eeP7tApG8G2sAc1FwwCCarxoloE=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "" Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:14:03 -0000 On 07/30/2012 04:08 PM, Michael Richardson wrote: >>>>>> "Michael" == Michael Thomas writes: > Michael> If we believe that ipv6 is ready to go for mass deployment, why do we > Michael> not pressure home router vendors to default to sending router advertisements > Michael> with ULA addresses that, if necessary, get NAT'd at the border just like > Michael> 192.168 space does today. > > Michael> I mean, nothing bad would happen, right? > > Do you mean, NAT64'ed? > > Yes, just nat v6 internal addresses to v4 on the isp side when you don't have v6 connectivity. If you're reading this and inclined to a NAT rant, you probably didn't understand my post. Mike From mcr+ietf@sandelman.ca Mon Jul 30 16:28:25 2012 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 A938C11E80BA for ; Mon, 30 Jul 2012 16:28:25 -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=[AWL=0.621, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnUNJuyzZ1JD for ; Mon, 30 Jul 2012 16:28:25 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id D701C11E8130 for ; Mon, 30 Jul 2012 16:28:24 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id EED8C20168; Mon, 30 Jul 2012 19:40:41 -0400 (EDT) From: Michael Richardson To: james woodyatt In-Reply-To: References: <4999ED78-B0DF-4DE7-9B51-0524592E5061@apple.com> <47B88B0C-EA3E-4222-85A1-95C9D1E67CD3@fugue.com> X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) 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 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:28:25 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "james" =3D=3D james woodyatt writes: james> 3. Queries for PTR records in zones for which it's james> authoritative should always produce a synthesized answer if james> no explicitly configured records are stored in the content james> server.=20 I think you that the answer should come from the Bonjour cache. james> For examples, james> 3a. dig -x fd35:5a4b:92a9:fb::1 -> james> fd35-5a4b-92a9-fb--1.local. okay, so here I think that I disagree. Is that name valid in the forward?=20=20 james> 4. I should be able to override explicitly the domain james> automatically delegated by my service provider with my own james> registered FQDN if I want to do so, so that example 3b above james> becomes:=20 james> 3b.(2). dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc -> james> 2001-5a8-4-2290-a95f-dd2e-3201-eafc.conjury.org. I agree. james> 5. I should be able to override explicitly the automatically james> generated FQDN for any hosts on my network if I want to do james> so, so that examples 3a and 3b above become:=20 .. james> 6. I should be able to do both. .. james> Yes, I get that DNSOP people don't like to contemplate this james> problem. I don't want to debate about why I think they're james> wrong to defer it, but my thoughts aren't all that different james> from those of anyone else in the application/security james> community. Can we skip past the part when I enumerate them james> again?=20 james> I guess I had hoped the HOMENET group would more easily find james> consensus around addressing this promptly, but that may have james> been wishful thinking.=20 I am 400% behind you, and if buying you beer will help, tell me. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBcYlYqHRg3pndX9AQK96AP9Ga/swleK2eTih6FsAS0bcaOFSB/32DEb mDtifj1KChVi3keUM1csdit6T6vPwZQQ98pTEDtp2hLVGYFx6spgHHaO9TfmH7+n LdCyO1HDzL0aEUZVvnBubmdKp3BWR0oEtG11xq2WP5g+f8Y1yUcAS4LrcJmmsI5Q hMtDTF6tUfo= =h9k+ -----END PGP SIGNATURE----- --=-=-=-- From mcr+ietf@sandelman.ca Mon Jul 30 16:32:54 2012 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 E543011E8109 for ; Mon, 30 Jul 2012 16:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7VidKJ-senX for ; Mon, 30 Jul 2012 16:32:54 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id F189C11E80BA for ; Mon, 30 Jul 2012 16:32:53 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id 9F49C20168; Mon, 30 Jul 2012 19:45:10 -0400 (EDT) From: Michael Richardson To: Michael Thomas In-Reply-To: <5017153A.9040103@mtcc.com> References: <5016CD8E.1000008@mtcc.com> <6112.1343689738@obiwan.sandelman.ca> <5017153A.9040103@mtcc.com> X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) 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 Cc: "" Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:32:55 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Michael" =3D=3D Michael Thomas writes: Michael> If we believe that ipv6 is ready to go for mass deployment, wh= y do we Michael> not pressure home router vendors to default to sending router = advertisements Michael> with ULA addresses that, if necessary, get NAT'd at the border= just like Michael> 192.168 space does today. Michael> I mean, nothing bad would happen, right? >> Do you mean, NAT64'ed? Michael> Yes, just nat v6 internal addresses to v4 on the isp side when= you Michael> don't have v6 connectivity. If you're reading this and incline= d to Michael> a NAT rant, you probably didn't understand my post. I'm not going to rant until I understand you, thus my question. How does ULA+NAT64 at the edge replacing RFC1918+NAT44 change the world? I think it would be a nice thing to do, and it requires no standards action. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBcZooqHRg3pndX9AQLMKAQAsz6QIsxYKHx0qPKQbEH75OaX+SmzZ3nQ UjCd4adVBgGW4S/YrZAA0LWxoqdXJdhvVJNZkRubUjK/NkBdIsfizAYmS9+yxgpU 1mAPeUIuastsK60+8ceRncXa9+P8Apo9UtBiT0uS+dS7ZKwtxcDKJY5uuNETnDOz jVOom0alWFw= =DJhm -----END PGP SIGNATURE----- --=-=-=-- From ek@google.com Mon Jul 30 16:37:41 2012 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 A9D0511E8109 for ; Mon, 30 Jul 2012 16:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EekacVLaqe7c for ; Mon, 30 Jul 2012 16:37:41 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 282DD11E80BA for ; Mon, 30 Jul 2012 16:37:41 -0700 (PDT) Received: by qcac10 with SMTP id c10so3627783qca.31 for ; Mon, 30 Jul 2012 16:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=tCcfFJAPr+R3YV6ac2MExzGrwO+WeSFL6TEvPBai2Eg=; b=N/2P4tdjlpNJXKgl/k25QbdhpjoRNjE9SEINknJfc2cWU7nc9Lht39SE8/Hk+X7OEK QQFUgO5bW8XXgVel2dUZtatCPG/dAprbXro2lC7UWmUzk63XFHfcH9Oimwej7n7mTgqi uQGr1IvacXjSeCDdXFYWD9O1F+4q+y5loWNk9vp9v2U5+Us0i3A/lekKi5bSa1ksVnl1 rFrHil/HpFGuxq4frS9VXYQaeqfTvIcTiKb4yBubrLPWXKiZeHtS+g8TPyOWik5vmIKh x5EmmVfrvyKnfI5Dqw/Gv/XFRyBgopMFykcNBHIDIfwPWtDFi982O2G0OtMKf/Alj0ms M1oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=tCcfFJAPr+R3YV6ac2MExzGrwO+WeSFL6TEvPBai2Eg=; b=bh3NA8bde0nKUq0Fisilc1P6ZGu8VudMh3nSGHMklFxsgJZByFcsROzQniMpf5mcj+ f3m0w6jl20NvoZOgIdHTRLMuuaubZDPlL5UQyo/JWUHLxNUkEOcm08Pdd1J09lmDrcck zL9Wh/uhklbE8Ufb4SNF2gzbZGkThp1PnwE28nW3hbix8AMKmmXPH2Vcrlfls1DjTwcW dN66Z6wwqT+15A4blr0O/ErhIbugT1ZWG63wcTfm99hkN8pLp63xz7ZMlDG1kdnWijmG xd8iG9DGE4SmDdW2Rk3sdACyg9Bg13iTz6f9OZ4FmtK94FH+wJJQqnnr6LTQXsD41akC L85w== Received: by 10.224.42.68 with SMTP id r4mr26298175qae.84.1343691460500; Mon, 30 Jul 2012 16:37:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.42.68 with SMTP id r4mr26298162qae.84.1343691460417; Mon, 30 Jul 2012 16:37:40 -0700 (PDT) Received: by 10.229.139.144 with HTTP; Mon, 30 Jul 2012 16:37:40 -0700 (PDT) In-Reply-To: <10251.1343691170@obiwan.sandelman.ca> References: <5016CD8E.1000008@mtcc.com> <6112.1343689738@obiwan.sandelman.ca> <5017153A.9040103@mtcc.com> <10251.1343691170@obiwan.sandelman.ca> Date: Tue, 31 Jul 2012 08:37:40 +0900 Message-ID: From: Erik Kline To: Michael Richardson Content-Type: multipart/alternative; boundary=20cf3074b6302f99e304c6148c55 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnJhVGQ2BExZe+9b7GULW9J8HvxqJ+UQbvNGwEW/0R6hru/eUu7bKZfQklZ9kNR9fe3YL0wo1p+T9uIsmcYwPOwzFNtKScKEDRt0EWFNrYVDhA8uNJf+XfKKHFLQUAfXSSCPCWYZ5noy6oB8eXBibZWoEApcDgrHLDMBfQ1nqNvycuzctgt2BKnmmJLU52GU24Uhyqr Cc: "" , Michael Thomas Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:37:41 -0000 --20cf3074b6302f99e304c6148c55 Content-Type: text/plain; charset=UTF-8 > > > I'm not going to rant until I understand you, thus my question. > How does ULA+NAT64 at the edge replacing RFC1918+NAT44 change the world? > > I think it would be a nice thing to do, and it requires no standards > action. > > What happens when that customer's ISP eventually gets around to IPv6-provisioning the customer. If some customer device chooses the wrong prefix to originate connections we'll be introducing a requirement for NAT66. You could try to rely on longest prefix matching 3484 behaviour to save you, but...idk. --20cf3074b6302f99e304c6148c55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'm not going to rant until I understand you, thus my question.
How does ULA+NAT64 at the edge replacing RFC1918+NAT44 change the world?
I think it would be a nice thing to do, and it requires no standards
action.


What happens when that cust= omer's ISP eventually gets around to IPv6-provisioning the customer. = =C2=A0If some customer device chooses the wrong prefix to originate connect= ions we'll be introducing a requirement for NAT66. =C2=A0You could try = to rely on longest prefix matching 3484 behaviour to save you, but...idk.
--20cf3074b6302f99e304c6148c55-- From mike@mtcc.com Mon Jul 30 16:40:50 2012 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 3450321F8569 for ; Mon, 30 Jul 2012 16:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Wt7mIrlYFrq for ; Mon, 30 Jul 2012 16:40:49 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 2D56921F855B for ; Mon, 30 Jul 2012 16:40:49 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6UNemdN032637 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Jul 2012 16:40:48 -0700 Message-ID: <50171B80.50308@mtcc.com> Date: Mon, 30 Jul 2012 16:40:48 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Michael Richardson References: <5016CD8E.1000008@mtcc.com> <6112.1343689738@obiwan.sandelman.ca> <5017153A.9040103@mtcc.com> <10251.1343691170@obiwan.sandelman.ca> In-Reply-To: <10251.1343691170@obiwan.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1595; t=1343691648; x=1344555648; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20a=20modest=20proposal |Sender:=20 |To:=20Michael=20Richardson=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=5dSze7yU2Uu2qH0qKsecspFOMfwXEcOou5EJwtCRyKA=; b=r5EoFh9xoRIg1XCeF4i1QsMiVEVDzM+xUpAdXQ1PpFPlS+EjdSrl969/cS i86RtfDP3o1lE6TxaIh2oJErWDyUOO+7yfyYtPtJyWSx0AzJF+YUZbS1eRrm ap8Q5XNYLCz5U+xbURI+VG3Zjq/pFOUguTGxXk/OSUBXdKOR3StHU=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "" Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:40:50 -0000 On 07/30/2012 04:32 PM, Michael Richardson wrote: >>>>>> "Michael" == Michael Thomas writes: > Michael> If we believe that ipv6 is ready to go for mass deployment, why do we > Michael> not pressure home router vendors to default to sending router advertisements > Michael> with ULA addresses that, if necessary, get NAT'd at the border just like > Michael> 192.168 space does today. > > Michael> I mean, nothing bad would happen, right? > > >> Do you mean, NAT64'ed? > > Michael> Yes, just nat v6 internal addresses to v4 on the isp side when you > Michael> don't have v6 connectivity. If you're reading this and inclined to > Michael> a NAT rant, you probably didn't understand my post. > > I'm not going to rant until I understand you, thus my question. > How does ULA+NAT64 at the edge replacing RFC1918+NAT44 change the world? > > I think it would be a nice thing to do, and it requires no standards > action. > Yes, that's exactly what I meant. It changes the world in that it gets the masses of people using and getting familiar with v6 and all of its considerations. I've heard (?) there are v6-only ISP's but for the rest of us unwashed masses, it's still rfc1918 and NAT's where if you are geeky enough to look at an ifconfig you'd see a boring link local address that never gets used for much of anything. As far as standards, one thing it may be interesting to this working group is the assignment of ULA's across homenet routers. AFAIK there isn't a way to do that automagically? Mike From mike@mtcc.com Mon Jul 30 16:44:11 2012 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 8970F21F856D for ; Mon, 30 Jul 2012 16:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.817 X-Spam-Level: X-Spam-Status: No, score=-2.817 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LV1n22yJoBlC for ; Mon, 30 Jul 2012 16:44:10 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id A78DA21F8568 for ; Mon, 30 Jul 2012 16:44:10 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6UNi698001255 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Jul 2012 16:44:06 -0700 Message-ID: <50171C46.5010401@mtcc.com> Date: Mon, 30 Jul 2012 16:44:06 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Erik Kline References: <5016CD8E.1000008@mtcc.com> <6112.1343689738@obiwan.sandelman.ca> <5017153A.9040103@mtcc.com> <10251.1343691170@obiwan.sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=750; t=1343691847; x=1344555847; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20a=20modest=20proposal |Sender:=20 |To:=20Erik=20Kline=20 |Content-Type:=20text/plain=3B=20charset=3DUTF-8=3B=20forma t=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=p1Qw5LFH8u69CRFkNyjz3EkbvUq+6eB4tjgCO9JAQTI=; b=kqPLLNRWM7RlFxmNouAlg4ULzwy4xsg2/bVMZRN7i1uf5bHPRuiP+2AitH y68DZ6c9fVQeTPW0RoWlDEKucEfE7N3Vh8PqTkZY+S2n2Ikz0RL49sQ72ORu b4vUi6OQSLqBjr1VoZRP+Y11gYkTK9fK6k/oM5lA7pVk0+VV/EkjQ=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Michael Richardson , "" Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:44:12 -0000 On 07/30/2012 04:37 PM, Erik Kline wrote: > > > I'm not going to rant until I understand you, thus my question. > How does ULA+NAT64 at the edge replacing RFC1918+NAT44 change the world? > > I think it would be a nice thing to do, and it requires no standards > action. > > > What happens when that customer's ISP eventually gets around to IPv6-provisioning the customer. If some customer device chooses the wrong prefix to originate connections we'll be introducing a requirement for NAT66. You could try to rely on longest prefix matching 3484 behaviour to save you, but...idk. As I said, what could go wrong, right? That's sort of the point of my most modest proposal -- find out sooner rather than later. Mike From jhw@apple.com Mon Jul 30 16:54:16 2012 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 1331A11E8072 for ; Mon, 30 Jul 2012 16:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1KIw3z7BvHw for ; Mon, 30 Jul 2012 16:54:15 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7441111E80D5 for ; Mon, 30 Jul 2012 16:54:15 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M7Z00750ZP9BYY2@mail-out.apple.com> for homenet@ietf.org; Mon, 30 Jul 2012 16:54:15 -0700 (PDT) X-AuditID: 11807136-b7fed6d000005bf5-24-50171ea638ee Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id A4.CD.23541.7AE17105; Mon, 30 Jul 2012 16:54:15 -0700 (PDT) From: james woodyatt In-reply-to: <9474.1343690901@obiwan.sandelman.ca> Date: Mon, 30 Jul 2012 16:54:14 -0700 Message-id: <709DF1F0-FD14-4FD3-8D7E-A6583D379A42@apple.com> References: <4999ED78-B0DF-4DE7-9B51-0524592E5061@apple.com> <47B88B0C-EA3E-4222-85A1-95C9D1E67CD3@fugue.com> <9474.1343690901@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUieJDXQXe5nHiAwd3FTBbvFx1iseg51M/u wOSxZMlPJo+WOXuYA5iiuGxSUnMyy1KL9O0SuDK2PtvJVrBFqOLDO/0GxrN8XYycHBICJhJf Pi1lgbDFJC7cW8/WxcjFISQwm0liz9QrTCAJZgEtiRv/XoLZvAJ6ErPb54A1CAsoSSxdtZgV xGYTUJH4dvkuUA0HB6eAkcST+4kgYRYBVYk3X6exQIzRl+jd85ANwtaWWLbwNTPESBuJxh0L mSD2HmGUOH1iH9hMEaBdy488Y4Q4Tlbi++HzbBMY+WchOWkWkpNmIZm7gJF5FaNgUWpOYqWh qV5iQUFOql5yfu4mRlDQNRSa7WDc8VfuEKMAB6MSD6/jIbEAIdbEsuLK3EOMEhzMSiK8uRzi AUK8KYmVValF+fFFpTmpxYcYpTlYlMR5/ywXChASSE8sSc1OTS1ILYLJMnFwSjUw7nm9s22f i5vqFNVansjQlAtC6te5a620pL+GB7UUu9svlu/zOqtQb2PkI8JyM/NA54vD+gn+hxNb3y4u XnqOPT7GutnHP7p2/5kHnQdfn95ucabJ6oNbT9LFM+fLtocXrIrckrxBcefuRia+Zw6WV56I uBxcc1btV+OyCTr/OTjdLM5urr6qxFKckWioxVxUnAgAnVs+VzYCAAA= Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:54:16 -0000 On Jul 30, 2012, at 16:28 , Michael Richardson wrote: > > I think you that the answer should come from the Bonjour cache. > > james> For examples, > james> 3a. dig -x fd35:5a4b:92a9:fb::1 -> fd35-5a4b-92a9-fb--1.local. I chose a ULA address instead of a LL address because mDNS doesn't handle reverse mappings for the "d.f.ip6.arpa." domain, c.f. section 4 of I-D.cheshire-dnsext-multicastdns-15: >> Likewise, any DNS query for a name within the reverse mapping >> domains for IPv6 Link-Local addresses ("8.e.f.ip6.arpa.", >> "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.") MUST >> be sent to the IPv6 mDNS link-local multicast address FF02::FB or >> the IPv4 mDNS multicast address 224.0.0.251. > okay, so here I think that I disagree. Is that name valid in the forward? I could accept a standard that required every reverse mapped name to be resolvable in the forward over unicast DNS, but I would say that's a separable problem from the one I'm suggesting could be taken up now. One step at a time... ----- Perhaps my choice of "local." as the default zone for RFC 6106 ULA prefix addresses is unwise as it could be confusing in the presence of mDNS on the same segment as the unicast DNS service. Suppose a host named "zardoz" is attached to the link at several interface addresses: fd35:5a4b:92a9:fb::1001 2001:5a8:4:2290::1001 2001:5a8:4:2290:a95f:dd2e:3201:eafc fe80::0200:ff:fe00:1 All those addresses will be reverse mapped over mDNS to "zardoz.local." under every implementation that I know about today. Which makes sense if you think about it. Every mDNS responder host is responsible for knowing its own name and answering to it. In the unicast DNS case, the content server probably does not know-- and arguably should not know-- the name of every host in the zone, so that's why it's wise to expect it will be synthesizing host names. Whether the default zone for ULA reverse mapping names over unicast DNS is "local." or "homenet." or something else is only tangentially relevant here. It's the same problem no matter what TLD we allocate for this purpose. -- james woodyatt member of technical staff, core os networking From mike@mtcc.com Mon Jul 30 16:59:27 2012 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 2DB5911E80CC for ; Mon, 30 Jul 2012 16:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.803 X-Spam-Level: X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zPH2Z2gD4fm for ; Mon, 30 Jul 2012 16:59:26 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB9011E809B for ; Mon, 30 Jul 2012 16:59:26 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6UNxPok006465 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Jul 2012 16:59:25 -0700 Message-ID: <50171FDD.10003@mtcc.com> Date: Mon, 30 Jul 2012 16:59:25 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: james woodyatt References: <4999ED78-B0DF-4DE7-9B51-0524592E5061@apple.com> <47B88B0C-EA3E-4222-85A1-95C9D1E67CD3@fugue.com> <9474.1343690901@obiwan.sandelman.ca> <709DF1F0-FD14-4FD3-8D7E-A6583D379A42@apple.com> In-Reply-To: <709DF1F0-FD14-4FD3-8D7E-A6583D379A42@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=634; t=1343692766; x=1344556766; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Reverse=20DNS |Sender:=20 |To:=20james=20woodyatt=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=cDeFnlHtcHREHkjUvQAZcSvq+JiPZ0LLxlmKS2teARw=; b=ZqacJ0lbETwUyhgpmBNRPKbEPq6MvrpDg/bceiW5OdBDYnCB7q8aHbAeX2 VtHyvkKj10JlToGAk2P5y3KvHRvB+hFajAEQz79m3IMgw1zAmCwt8hdB2KYt LZXSeihZOur9HciwSm8bJHJ8ZHXQvq4JHVfLhLwsWW89oUaewYwHY=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Michael Richardson , "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:59:27 -0000 On 07/30/2012 04:54 PM, james woodyatt wrote: > In the unicast DNS case, the content server probably does not know-- and arguably should not know-- the name of every host in the zone, so that's why it's wise to expect it will be synthesizing host names. Whether the default zone for ULA reverse mapping names over unicast DNS is "local." or "homenet." or something else is only tangentially relevant here. It's the same problem no matter what TLD we allocate for this purpose. > Maybe I missed it, but why is lack of reverse map a problem, minus the security desire to show some weak control of the allocated prefix? Mike From curtis@occnc.com Mon Jul 30 17:11:07 2012 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 0E9CB11E80DE for ; Mon, 30 Jul 2012 17:11:07 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+YosXF+9WlV for ; Mon, 30 Jul 2012 17:11:06 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 99B5411E809B for ; Mon, 30 Jul 2012 17:10:54 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q6V0Annp061316; Mon, 30 Jul 2012 20:10:50 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201207310010.q6V0Annp061316@gateway.ipv6.occnc.com> To: Michael Thomas From: Curtis Villamizar In-reply-to: Your message of "Mon, 30 Jul 2012 16:14:02 PDT." <5017153A.9040103@mtcc.com> Date: Mon, 30 Jul 2012 20:10:49 -0400 Cc: Michael Richardson , "" Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 00:11:07 -0000 In message <5017153A.9040103@mtcc.com> Michael Thomas writes: > On 07/30/2012 04:08 PM, Michael Richardson wrote: > >>>>>> "Michael" == Michael Thomas writes: > > Michael> If we believe that ipv6 is ready to go for mass > > Michael> deployment, why do we > > Michael> not pressure home router vendors to default to sending > > Michael> router advertisements > > Michael> with ULA addresses that, if necessary, get NAT'd at > > Michael> the border just like > > Michael> 192.168 space does today. > > > > Michael> I mean, nothing bad would happen, right? > > > > Do you mean, NAT64'ed? > > > > > > Yes, just nat v6 internal addresses to v4 on the isp side when you > don't have v6 connectivity. If you're reading this and inclined to > a NAT rant, you probably didn't understand my post. > > Mike Mike, There would be no advantage to either the user or the service provider to allocate from IPv6 PI space rather than IPv4 PI. Whether the user has a 10/8 with 16 million hosts, or a /64 with 16 billion billion (whatever that is called), makes no difference. The provider needs to allocate exactly one IPv4 address if we are doing NAT64. If the whole neighborhood is connected as in a consumer ISP, then they allocate a large pool. Last I was on one of those, the pool was a /20 with 4,906 IPv4 addresses. It doesn't take long to run out of IPv4 addresses that way. And we pretty much have done so. Allocating IPV4 PI addresses on the client side and IPv6 on the service provider side doesn't help either. The client could only address IPv4 content providers and to make a IPv4-in-IPV6 address at least one routable IPv4 address is needed on the NAT. If the NAT still needs one IPv4 address, nothing is gained on the provider side (where the IPv4 address depletion resides). If you see some advantage that solves the IPv4 address depletion (a big point of the transition to IPv6 exercise), then I've missed it. If so, please point out what I missed. If both side, client and provider, are IPv6, then there is no reason to bother with a NAT at all. The router doing the NAT has to know its own IPv6 routable address. That address has to be configured or learned somehow such as via DHCP. There is nothing to be gained by handing out a /128 to the router for it to NAT, rather than handing out a routable /64 and letting the customer router allocate routable addresses. There are 4 billion times as many IPv6 /64 available as there are IPv4 addresses so NAT is unnecessary. I hope this wasn't perceived as a rant about NAT. Curtis From mike@mtcc.com Mon Jul 30 17:20:12 2012 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 C768621F8559 for ; Mon, 30 Jul 2012 17:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.79 X-Spam-Level: X-Spam-Status: No, score=-2.79 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4DogYO2FVhV for ; Mon, 30 Jul 2012 17:20:12 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id EA82E21F848F for ; Mon, 30 Jul 2012 17:20:11 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6V0KAVY013572 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Jul 2012 17:20:11 -0700 Message-ID: <501724BA.6010303@mtcc.com> Date: Mon, 30 Jul 2012 17:20:10 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: curtis@occnc.com References: <201207310010.q6V0Annp061316@gateway.ipv6.occnc.com> In-Reply-To: <201207310010.q6V0Annp061316@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=487; t=1343694011; x=1344558011; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20a=20modest=20proposal |Sender:=20 |To:=20curtis@occnc.com |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=485o75c0g1FF3O/+wW8v2OeJmkXCUOKrT+Zo2uYwD+Q=; b=KMeMy8b+8XSCFjM7kxPHNr5fWJZPaTxF14G8LHQLIjqobXy5xUJtDcIRBl 5dIpBAza0/3PGJovSmQCKbLYvXpxfrf1rnphWZXLbD65P8kmsRUuyndnjlnB BXaUTgcV4Aw1DOhtBPgh5zcjBwA0ISyirm9YonM2xJs1P28a7ymno=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Michael Richardson , "" Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 00:20:12 -0000 On 07/30/2012 05:10 PM, Curtis Villamizar wrote: > If you see some advantage that solves the IPv4 address depletion (a > big point of the transition to IPv6 exercise), then I've missed it. > If so, please point out what I missed. No, not at all and not the point. I'm just of the mind that if we believe that v6 is really, really ready to go there shouldn't be any problem in substituting rfc1918 v4 space with v6 ULA space. If that modest change leads to trouble... Mike From jhw@apple.com Mon Jul 30 17:21:08 2012 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 4C60811E80CC for ; Mon, 30 Jul 2012 17:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQR72b-pJhHG for ; Mon, 30 Jul 2012 17:21:07 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0A611E80D3 for ; Mon, 30 Jul 2012 17:21:07 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M8000JEK07YI5B0@mail-out.apple.com> for homenet@ietf.org; Mon, 30 Jul 2012 17:21:02 -0700 (PDT) X-AuditID: 11807136-b7fed6d000005bf5-72-501724ee9384 Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id FF.0C.23541.EE427105; Mon, 30 Jul 2012 17:21:02 -0700 (PDT) From: james woodyatt In-reply-to: <5016CD8E.1000008@mtcc.com> Date: Mon, 30 Jul 2012 17:21:02 -0700 Message-id: <5B3D5AA4-8825-4D63-9114-941D6807FA03@apple.com> References: <5016CD8E.1000008@mtcc.com> To: Michael Thomas , "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUieJDXQfediniAwa59fBbvFx1isVg5cQmb A5PHkiU/mTxWrzvPHsAUxWWTkpqTWZZapG+XwJXxeFUbc0E/a8XfBbNYGhjbWLoYOTkkBEwk /v/YAmWLSVy4t56ti5GLQ0hgNpPE7n/drCAJZgEtiRv/XjKB2LwCehKz2+eANQgLaEjMn/8D zGYTUJH4dvkuUA0HBydQ/P55dZAwi4CqxOK9E9kgxmhLLFv4mhlijI3EmUMrGEHKhQTUJTo6 LEFMEYFAiWcTmCCukZX4fvg82wRGvllIbpiF5IZZSIYuYGRexShYlJqTWGloqpdYUJCTqpec n7uJERRYDYVmOxh3/JU7xCjAwajEw+t4SCxAiDWxrLgy9xCjBAezkghvLod4gBBvSmJlVWpR fnxRaU5q8SFGaQ4WJXHeP8uFAoQE0hNLUrNTUwtSi2CyTBycUg2Muzu6pe/mxb98uj5BflX2 2oPl8fo2c7fZpXNWZy+VXPH7i2jprh2H1FuUb5yXvH9e7fOO1u8q2QLdWQufGjs1nrS7dnLS xu5C+1SHZW9spyfc62Dd/LXknGHTJq+PE+ulri1ade9FxaQ6icTACb82Tb61ZpflDs+JjCwZ J5QVc+xOBnAUyv76o8RSnJFoqMVcVJwIAMUHxkQoAgAA Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 00:21:08 -0000 On Jul 30, 2012, at 11:08 , Michael Thomas wrote: > > If we believe that ipv6 is ready to go for mass deployment, why do we > not pressure home router vendors to default to sending router advertisements > with ULA addresses that, if necessary, get NAT'd at the border just like > 192.168 space does today. > > I mean, nothing bad would happen, right? What does the conditional phrase "if necessary" mean in your mind? Under what circumstances do you imagine this would not be "necessary" for operational continuity? -- james woodyatt member of technical staff, core os networking From mike@mtcc.com Mon Jul 30 17:22:24 2012 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 B8FFF11E80F6 for ; Mon, 30 Jul 2012 17:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.779 X-Spam-Level: X-Spam-Status: No, score=-2.779 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bScymHDoiUiq for ; Mon, 30 Jul 2012 17:22:23 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id E8D9011E80EE for ; Mon, 30 Jul 2012 17:22:22 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6V0MLxM014324 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Jul 2012 17:22:22 -0700 Message-ID: <5017253D.1020109@mtcc.com> Date: Mon, 30 Jul 2012 17:22:21 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: james woodyatt References: <5016CD8E.1000008@mtcc.com> <5B3D5AA4-8825-4D63-9114-941D6807FA03@apple.com> In-Reply-To: <5B3D5AA4-8825-4D63-9114-941D6807FA03@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=645; t=1343694142; x=1344558142; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20a=20modest=20proposal |Sender:=20 |To:=20james=20woodyatt=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=2t7r/OSH2K2lHykOInEQKIXFTNwUD0sygVZFD+X7Y3o=; b=twMyS9nB2zqM3hkDTgoiVZKw4Ve7yOg6n1V8Nw/CmygSNG8dZWabvpw2Zt n6xok8qqAE5QZXjAEgkgZKdRlQiCVuaPRkxoXaVtLLhEDgCQ9rPcwdLRQ+OZ BArQ9MkYvaLAt2Q+0qkCJ0ADafpdtw6BJkTWC/SaiuiJorLWyQ+VM=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 00:22:25 -0000 On 07/30/2012 05:21 PM, james woodyatt wrote: > On Jul 30, 2012, at 11:08 , Michael Thomas wrote: >> If we believe that ipv6 is ready to go for mass deployment, why do we >> not pressure home router vendors to default to sending router advertisements >> with ULA addresses that, if necessary, get NAT'd at the border just like >> 192.168 space does today. >> >> I mean, nothing bad would happen, right? > What does the conditional phrase "if necessary" mean in your mind? Under what circumstances do you imagine this would not be "necessary" for operational continuity? When you have native v6 connectivity. Mike From mike@mtcc.com Mon Jul 30 17:23:56 2012 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 438DA11E80D3 for ; Mon, 30 Jul 2012 17:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.769 X-Spam-Level: X-Spam-Status: No, score=-2.769 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4pbkUaN3IAO for ; Mon, 30 Jul 2012 17:23:55 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id ADA7F11E80BA for ; Mon, 30 Jul 2012 17:23:55 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6V0Nrrs014840 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Jul 2012 17:23:54 -0700 Message-ID: <50172599.2040609@mtcc.com> Date: Mon, 30 Jul 2012 17:23:53 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: james woodyatt References: <5016CD8E.1000008@mtcc.com> <5B3D5AA4-8825-4D63-9114-941D6807FA03@apple.com> In-Reply-To: <5B3D5AA4-8825-4D63-9114-941D6807FA03@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=736; t=1343694235; x=1344558235; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20a=20modest=20proposal |Sender:=20 |To:=20james=20woodyatt=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=8cINS5/3kfWXhCRhoQtqzTsYFiQOgFgF+O+D8cl5mLs=; b=EhnCsRFd3F0kfdrcSX915n9/RCsHpqfhtXhM9hfVh9uak34CdXCuo91YDT LfsJZ9yS3Wn+7PB+DPenAjp2w24+NExJF9UrseTVxQ4PPMvbr/M5nWv4/0UF jl1b/uWoFYsttFvHzz3QfiGnvBjVdRkDHCLVKu+aIySZJT2gJLsrw=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 00:23:56 -0000 On 07/30/2012 05:21 PM, james woodyatt wrote: > On Jul 30, 2012, at 11:08 , Michael Thomas wrote: >> If we believe that ipv6 is ready to go for mass deployment, why do we >> not pressure home router vendors to default to sending router advertisements >> with ULA addresses that, if necessary, get NAT'd at the border just like >> 192.168 space does today. >> >> I mean, nothing bad would happen, right? > What does the conditional phrase "if necessary" mean in your mind? Under what circumstances do you imagine this would not be "necessary" for operational continuity? > I should add that by native v6 connectivity, you'd also be getting a provider public v6 as well where rfc3484 saves the day. Mike From mcr+ietf@sandelman.ca Mon Jul 30 17:51:20 2012 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 CE7CC21F8539 for ; Mon, 30 Jul 2012 17:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.013 X-Spam-Level: X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HB3X6eEID6zN for ; Mon, 30 Jul 2012 17:51:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id BA8DB21F8526 for ; Mon, 30 Jul 2012 17:51:17 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id 68DD820168; Mon, 30 Jul 2012 21:03:34 -0400 (EDT) From: Michael Richardson To: "homenet@ietf.org Group" In-Reply-To: <709DF1F0-FD14-4FD3-8D7E-A6583D379A42@apple.com> References: <4999ED78-B0DF-4DE7-9B51-0524592E5061@apple.com> <47B88B0C-EA3E-4222-85A1-95C9D1E67CD3@fugue.com> <9474.1343690901@obiwan.sandelman.ca> <709DF1F0-FD14-4FD3-8D7E-A6583D379A42@apple.com> X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) 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 Cc: james woodyatt Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 00:51:20 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "james" =3D=3D james woodyatt writes: >> okay, so here I think that I disagree. Is that name valid in the fo= rward?=20=20 james> I could accept a standard that required every reverse mapped james> name to be resolvable in the forward over unicast DNS, but I james> would say that's a separable problem from the one I'm james> suggesting could be taken up now. One step at a time...=20 okay. james> ----- james> Perhaps my choice of "local." as the default zone for RFC james> 6106 ULA prefix addresses is unwise as it could be confusing james> in the presence of mDNS on the same segment as the unicast james> DNS service.=20 james> Suppose a host named "zardoz" is attached to the link at several= interface addresses: james> fd35:5a4b:92a9:fb::1001 james> 2001:5a8:4:2290::1001 james> 2001:5a8:4:2290:a95f:dd2e:3201:eafc james> fe80::0200:ff:fe00:1 james> All those addresses will be reverse mapped over mDNS to james> "zardoz.local." under every implementation that I know about james> today. Which makes sense if you think about it. Every mDNS james> responder host is responsible for knowing its own name and james> answering to it.=20 yes, I know... mDNS already has the info, which is why I suggest that the info come from there. james> In the unicast DNS case, the content server probably does not james> know-- and arguably should not know-- the name of every host james> in the zone, so that's why it's wise to expect it will be james> synthesizing host names. Whether the default zone for ULA james> reverse mapping names over unicast DNS is "local." or james> "homenet." or something else is only tangentially relevant james> here. It's the same problem no matter what TLD we allocate james> for this purpose.=20 so, you are suggesting that zardoz's reverse entries does not get answered by unicast DNS unless I click on "zardoz" in my content server's UI, and say, "export". I'm suggesting that the "export" button should be in the UI of zardoz, and be signaled via mDNS. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBcsAYqHRg3pndX9AQImfgQApEjpzC+uf2w30ayAZmzAYcQ/aGsk8QQg IxN3Ua7d3Ug8/MTx2Ya2LwEzgmjBN47gfwkyp0uDgiQY/eEL+af/dekTYDr2ogWM s5xQcpu7u7EqzMSlqeTupi1+v0Jt2VxJLVrW869pE12gvu+noleeFd95hTx4iMYB ZcIMudhPvXc= =DEXw -----END PGP SIGNATURE----- --=-=-=-- From mcr+ietf@sandelman.ca Mon Jul 30 17:54:38 2012 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 01D8321F85E7 for ; Mon, 30 Jul 2012 17:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[AWL=0.570, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YhwdeVaUTIl for ; Mon, 30 Jul 2012 17:54:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id 847F321F85CD for ; Mon, 30 Jul 2012 17:54:36 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id 1BA8120168 for ; Mon, 30 Jul 2012 21:06:51 -0400 (EDT) From: Michael Richardson To: "homenet@ietf.org Group" In-Reply-To: <50171FDD.10003@mtcc.com> References: <4999ED78-B0DF-4DE7-9B51-0524592E5061@apple.com> <47B88B0C-EA3E-4222-85A1-95C9D1E67CD3@fugue.com> <9474.1343690901@obiwan.sandelman.ca> <709DF1F0-FD14-4FD3-8D7E-A6583D379A42@apple.com> <50171FDD.10003@mtcc.com> X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) 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 Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 00:54:38 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Michael" =3D=3D Michael Thomas writes: Michael> Maybe I missed it, but why is lack of reverse map a problem, m= inus the Michael> security desire to show some weak control of the allocated pre= fix? http://www.ietf.org/mail-archive/web/homenet/current/msg01286.html =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBcsxoqHRg3pndX9AQIwLAP9GAe8fxCpucOmFn90859S826B+tTIhBlc Xi34owcrODFcMmtsHab+c2iAmdEvi/osy2N6N8VpUAaD7VlrlzUL4Bd21+6ULE+q L6UaeIxULuWAq+tEYEiqqxj0R8pFzvcDdcbLqILljTndMVsIK5c9jwhyzWetX9gG hu28Z6qgvbQ= =FJrM -----END PGP SIGNATURE----- --=-=-=-- From mellon@fugue.com Mon Jul 30 17:58:02 2012 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 56C7421F85DD for ; Mon, 30 Jul 2012 17:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74wzwbnVjQQ9 for ; Mon, 30 Jul 2012 17:58:01 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id E4BF321F85BB for ; Mon, 30 Jul 2012 17:58:01 -0700 (PDT) Received: from dhcp-462a.meeting.ietf.org (dhcp-462a.meeting.ietf.org [130.129.70.42]) by toccata.fugue.com (Postfix) with ESMTPSA id 4FD0A2380C5D; Mon, 30 Jul 2012 20:58:00 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_9BAA1259-B71E-4867-8EF8-F0FF03A0821C" From: Ted Lemon In-Reply-To: <50171FDD.10003@mtcc.com> Date: Mon, 30 Jul 2012 17:57:58 -0700 Message-Id: <5B72C03D-18E1-42BE-9263-544B672BABE0@fugue.com> References: <4999ED78-B0DF-4DE7-9B51-0524592E5061@apple.com> <47B88B0C-EA3E-4222-85A1-95C9D1E67CD3@fugue.com> <9474.1343690901@obiwan.sandelman.ca> <709DF1F0-FD14-4FD3-8D7E-A6583D379A42@apple.com> <50171FDD.10003@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1278) Cc: Michael Richardson , "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 00:58:02 -0000 --Apple-Mail=_9BAA1259-B71E-4867-8EF8-F0FF03A0821C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 30, 2012, at 4:59 PM, Michael Thomas wrote: > Maybe I missed it, but why is lack of reverse map a problem, minus the > security desire to show some weak control of the allocated prefix? This is the wrong way to ask the question. Let me restate it: Is there some application for the reverse DNS, aside from the totally = useless "security" provided by matching the PTR with the AAAA? The answer is yes. There are a number of uses: peer-to-peer = rendezvous, a place to publish keys, debugging info are examples. = AFAIK there is no controversy about the fact that that using the PTR = record as a confirmation that you are who you say you are is completely = useless and should not be done. --Apple-Mail=_9BAA1259-B71E-4867-8EF8-F0FF03A0821C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Maybe I = missed it, but why is lack of reverse map a problem, minus = the
security desire to show some weak control of the allocated = prefix?

This is the wrong way to = ask the question.   Let me restate it:

Is = there some application for the reverse DNS, aside from the totally = useless "security" provided by matching the PTR with the = AAAA?

The answer is yes.   There are a = number of uses: peer-to-peer rendezvous, a place to publish keys, = debugging info are examples.   AFAIK there is no controversy about = the fact that that using the PTR record as a confirmation that you are = who you say you are is completely useless and should not be = done.

= --Apple-Mail=_9BAA1259-B71E-4867-8EF8-F0FF03A0821C-- From jhw@apple.com Mon Jul 30 18:03:11 2012 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 3857B21F8593 for ; Mon, 30 Jul 2012 18:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.532 X-Spam-Level: X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CqiSOeWCc7X for ; Mon, 30 Jul 2012 18:03:10 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFAA21F855D for ; Mon, 30 Jul 2012 18:03:10 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M8000C5X2OUMFM9@mail-out.apple.com> for homenet@ietf.org; Mon, 30 Jul 2012 18:03:10 -0700 (PDT) X-AuditID: 11807137-b7f626d0000059a0-0b-50172ece571a Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 48.C0.22944.ECE27105; Mon, 30 Jul 2012 18:03:10 -0700 (PDT) From: james woodyatt In-reply-to: <5017253D.1020109@mtcc.com> Date: Mon, 30 Jul 2012 18:03:10 -0700 Message-id: References: <5016CD8E.1000008@mtcc.com> <5B3D5AA4-8825-4D63-9114-941D6807FA03@apple.com> <5017253D.1020109@mtcc.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42IRPMjroHtOTzzA4MsmPov3iw6xODB6LFny kymAMYrLJiU1J7MstUjfLoErY+PiI0wFMwUqnj08x97A+IOni5GTQ0LAROLQ0bPsELaYxIV7 69m6GLk4hARmM0m0/utiA0kwC2hJ3Pj3kgnE5hXQk5jdPocFxBYW0JCYP/8HmM0moCLx7fJd sBpOoPiZLVMZuxg5OFgEVCUO9mtCjNGWWLbwNTPEGBuJbwdfgNlCAiUSnc8Pgt0gIqAv8fTI LzaIe2Qlvh8+zzaBkW8WkitmIbliFpKxCxiZVzEKFqXmJFYamuklFhTkpOol5+duYgQFUkOh +Q7G7X/lDjEKcDAq8fA6HhILEGJNLCuuzD3EKMHBrCTCm8shHiDEm5JYWZValB9fVJqTWnyI UZqDRUmc9+9yoQAhgfTEktTs1NSC1CKYLBMHp1QDY+fzrXcjaxZcfbCv7Kb4lKgO9oP9x7ck feJwS9IVenOo85zrhj2z+u7yMm5NO7K9R+KCrBG3FVc/22aZa7r/DpYuzPKo/O+hVf972eKC TU2XizrV4ny1Z66eLnOUI/e/JX+wnNPV4As8b6SclvU9CDUIrXK4VOT47MnC7KlZe9q/rarX kXitrsRSnJFoqMVcVJwIAOGnE14gAgAA Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 01:03:11 -0000 On Jul 30, 2012, at 17:22 , Michael Thomas wrote: > On 07/30/2012 05:21 PM, james woodyatt wrote: >> On Jul 30, 2012, at 11:08 , Michael Thomas wrote: >>> >>> If we believe that ipv6 is ready to go for mass deployment, why do we >>> not pressure home router vendors to default to sending router advertisements >>> with ULA addresses that, if necessary, get NAT'd at the border just like >>> 192.168 space does today. >>> >>> I mean, nothing bad would happen, right? >> >> What does the conditional phrase "if necessary" mean in your mind? Under what circumstances do you imagine this would not be "necessary" for operational continuity? > > When you have native v6 connectivity. On Jul 30, 2012, at 17:23 , Michael Thomas wrote: > > I should add that by native v6 connectivity, you'd also be getting a provider public v6 as well where rfc3484 saves the day. I thought as much. Here's why I considered that idea and rejected it when I was thinking about this problem in the context of a certain home router product. What happens when I have a persistent connection from my ULA address through the NAT64 path to a remote IPv4 address when the router acquires IPv6 connectivity? + If we stop translating all packets to and from the ULA address, then that connection is broken. + If we only stop translating packets for new flows, then we effectively break 3rd-party referral for the 64:ff9b::/64 prefix. + If we continue translating every packet, potentially in perpetuity, then we break locality of uniqueness by leaking our ULA routability into the global IPv4 Internet. It seemed clear to me that all of these options collectively exhausted the available alternatives, and they all came with damaging outcomes without any real benefit visible to anyone that I could identify, so I decided not to pursue the idea very vigorously. -- james woodyatt member of technical staff, core os networking From mike@mtcc.com Mon Jul 30 18:15:26 2012 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 D75D221F853E for ; Mon, 30 Jul 2012 18:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJK-NAGDAK-Q for ; Mon, 30 Jul 2012 18:15:26 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 1543C21F846D for ; Mon, 30 Jul 2012 18:15:25 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6V1FKws030506 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Jul 2012 18:15:21 -0700 Message-ID: <501731A8.2070808@mtcc.com> Date: Mon, 30 Jul 2012 18:15:20 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Ted Lemon References: <4999ED78-B0DF-4DE7-9B51-0524592E5061@apple.com> <47B88B0C-EA3E-4222-85A1-95C9D1E67CD3@fugue.com> <9474.1343690901@obiwan.sandelman.ca> <709DF1F0-FD14-4FD3-8D7E-A6583D379A42@apple.com> <50171FDD.10003@mtcc.com> <5B72C03D-18E1-42BE-9263-544B672BABE0@fugue.com> In-Reply-To: <5B72C03D-18E1-42BE-9263-544B672BABE0@fugue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1035; t=1343697321; x=1344561321; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Reverse=20DNS |Sender:=20 |To:=20Ted=20Lemon=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=84Ney1wUNYz6hoGkaXMCw0H/V2TyzTzLlYIDsbR/bJg=; b=q/9mRwdaH6uwta6PqEidK0G2NF5wRZFuTGj4WOMG5BPLhI5avuBsF0h97R y3B60mq3k4SkyQ1KMHgzrRjKdtziMoaPWppOv08ODJZCAj/0VCx6pDKf46dJ dj5ostcHT8gkv4a45vus3QIvWw1eLyRUGXUbv+Tc8vRREQFc2QjCU=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Michael Richardson , "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 01:15:27 -0000 On 07/30/2012 05:57 PM, Ted Lemon wrote: > On Jul 30, 2012, at 4:59 PM, Michael Thomas wrote: >> Maybe I missed it, but why is lack of reverse map a problem, minus the >> security desire to show some weak control of the allocated prefix? > > This is the wrong way to ask the question. Let me restate it: > > Is there some application for the reverse DNS, aside from the totally useless "security" provided by matching the PTR with the AAAA? > > The answer is yes. There are a number of uses: peer-to-peer rendezvous, a place to publish keys, debugging info are examples. AFAIK there is no controversy about the fact that that using the PTR record as a confirmation that you are who you say you are is completely useless and should not be done. > Tell that to the maintainers of this mailing list where I was just bitten by not having a reverse map for a v6 address from my tunnel provider so that my outbound mail to the list was rejected :) That's SOP for mail these days, not that I disagree with you. Mike From mike@mtcc.com Mon Jul 30 18:29:30 2012 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 5CBB611E810F for ; Mon, 30 Jul 2012 18:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6yF2u2yFBe3 for ; Mon, 30 Jul 2012 18:29:29 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 675A311E80E4 for ; Mon, 30 Jul 2012 18:29:29 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6V1TMd5002601 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Jul 2012 18:29:22 -0700 Message-ID: <501734F2.2050601@mtcc.com> Date: Mon, 30 Jul 2012 18:29:22 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: james woodyatt References: <5016CD8E.1000008@mtcc.com> <5B3D5AA4-8825-4D63-9114-941D6807FA03@apple.com> <5017253D.1020109@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2258; t=1343698162; x=1344562162; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20a=20modest=20proposal |Sender:=20 |To:=20james=20woodyatt=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=uRGOJvsI1Vukd/bax21JLNbUpARcxAGIt3m0SND+Jvg=; b=B+Rlze3SZ0LCuyoahQqpg09S45sncPJ4P7uGnbGkjJIdh19OVsVuMrrrB7 bwCvLqm8hDifE67rVJmwAUXs+79y9BfBjPcbkeZEuUhvqe14r+v+7UWAziCk 6zQTU90n1G/c3mMKa2Ql0UsFjOxHaPIgAR1KQnOjv50XtNQCkl1qo=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 01:29:30 -0000 On 07/30/2012 06:03 PM, james woodyatt wrote: > On Jul 30, 2012, at 17:22 , Michael Thomas wrote: >> On 07/30/2012 05:21 PM, james woodyatt wrote: >>> On Jul 30, 2012, at 11:08 , Michael Thomas wrote: >>>> If we believe that ipv6 is ready to go for mass deployment, why do we >>>> not pressure home router vendors to default to sending router advertisements >>>> with ULA addresses that, if necessary, get NAT'd at the border just like >>>> 192.168 space does today. >>>> >>>> I mean, nothing bad would happen, right? >>> What does the conditional phrase "if necessary" mean in your mind? Under what circumstances do you imagine this would not be "necessary" for operational continuity? >> When you have native v6 connectivity. > On Jul 30, 2012, at 17:23 , Michael Thomas wrote: >> I should add that by native v6 connectivity, you'd also be getting a provider public v6 as well where rfc3484 saves the day. > I thought as much. Here's why I considered that idea and rejected it when I was thinking about this problem in the context of a certain home router product. What happens when I have a persistent connection from my ULA address through the NAT64 path to a remote IPv4 address when the router acquires IPv6 connectivity? > > + If we stop translating all packets to and from the ULA address, then that connection is broken. > > + If we only stop translating packets for new flows, then we effectively break 3rd-party referral for the 64:ff9b::/64 prefix. > > + If we continue translating every packet, potentially in perpetuity, then we break locality of uniqueness by leaking our ULA routability into the global IPv4 Internet. > > It seemed clear to me that all of these options collectively exhausted the available alternatives, and they all came with damaging outcomes without any real benefit visible to anyone that I could identify, so I decided not to pursue the idea very vigorously. > I didn't understand your second bullet. So is this a cutover problem or worse? Even if it's persistent, it surely needs to be able to cope with the connection being briefly broken. And of course, such a router or provider would still need to deal with v4-only sites. Mike From Dmitry.Anipko@microsoft.com Mon Jul 30 19:10:27 2012 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 2FC0A11E80F5 for ; Mon, 30 Jul 2012 19:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.867 X-Spam-Level: X-Spam-Status: No, score=-2.867 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wR-1nHYxwGk for ; Mon, 30 Jul 2012 19:10:25 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 832F711E8124 for ; Mon, 30 Jul 2012 19:10:19 -0700 (PDT) Received: from mail270-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 31 Jul 2012 02:10:15 +0000 Received: from mail270-va3 (localhost [127.0.0.1]) by mail270-va3-R.bigfish.com (Postfix) with ESMTP id 6E8C6240331 for ; Tue, 31 Jul 2012 02:10:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh2a8h683h839h944hd25hf0ah107ah) Received-SPF: pass (mail270-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Dmitry.Anipko@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.244.37; KIP:(null); UIP:(null); (null); H:CH1PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail270-va3 (localhost.localdomain [127.0.0.1]) by mail270-va3 (MessageSwitch) id 134370061342649_4080; Tue, 31 Jul 2012 02:10:13 +0000 (UTC) Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.237]) by mail270-va3.bigfish.com (Postfix) with ESMTP id F35DF380049 for ; Tue, 31 Jul 2012 02:10:12 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 31 Jul 2012 02:10:12 +0000 Received: from co1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 31 Jul 2012 02:10:06 +0000 Received: from mail37-co1-R.bigfish.com (10.243.78.245) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Tue, 31 Jul 2012 02:10:06 +0000 Received: from mail37-co1 (localhost [127.0.0.1]) by mail37-co1-R.bigfish.com (Postfix) with ESMTP id D99368C0105 for ; Tue, 31 Jul 2012 02:10:05 +0000 (UTC) Received: from mail37-co1 (localhost.localdomain [127.0.0.1]) by mail37-co1 (MessageSwitch) id 1343700603592432_25704; Tue, 31 Jul 2012 02:10:03 +0000 (UTC) Received: from CO1EHSMHS016.bigfish.com (unknown [10.243.78.225]) by mail37-co1.bigfish.com (Postfix) with ESMTP id 8ED3D80004C for ; Tue, 31 Jul 2012 02:10:03 +0000 (UTC) Received: from CH1PRD0310HT001.namprd03.prod.outlook.com (157.56.244.37) by CO1EHSMHS016.bigfish.com (10.243.66.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 31 Jul 2012 02:10:03 +0000 Received: from CH1PRD0310MB368.namprd03.prod.outlook.com ([169.254.11.5]) by CH1PRD0310HT001.namprd03.prod.outlook.com ([10.255.137.36]) with mapi id 14.16.0175.005; Tue, 31 Jul 2012 02:10:02 +0000 From: Dmitry Anipko To: "homenet@ietf.org" Thread-Topic: homenet hosts security requirements and realm discovery Thread-Index: Ac1uwZXfXWpDUNUcSe2GSq0FlyscMw== Date: Tue, 31 Jul 2012 02:10:02 +0000 Message-ID: <96DD85EB136DCD49AB5CDB6DEC9639AD120CEB1B@CH1PRD0310MB368.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AkRe BwDr CZP+ CatC Cg/t Cpah C++w ECME Ewkz GHEp GcwX HZ6g Idjz Iuhu Klmk KvgD; 1; aABvAG0AZQBuAGUAdABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {15D38D01-CF8B-4820-91F5-ECC65F08D81F}; ZABtAGkAdAByAHkALgBhAG4AaQBwAGsAbwBAAG0AaQBjAHIAbwBzAG8AZgB0AC4AYwBvAG0A; Tue, 31 Jul 2012 02:09:58 GMT; aABvAG0AZQBuAGUAdAAgAGgAbwBzAHQAcwAgAHMAZQBjAHUAcgBpAHQAeQAgAHIAZQBxAHUAaQByAGUAbQBlAG4AdABzACAAYQBuAGQAIAByAGUAYQBsAG0AIABkAGkAcwBjAG8AdgBlAHIAeQA= x-cr-puzzleid: {15D38D01-CF8B-4820-91F5-ECC65F08D81F} x-originating-ip: [131.107.192.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC106.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC106.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: [homenet] homenet hosts security requirements and realm discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:10:27 -0000 In draft-ietf-homenet-arch-04, I was looking for and could not find a requi= rement for the network to provide homenet hosts with the information about = the realms - as a basic example, which prefixes are associated with the mos= t trusted homenet realm, as opposed to guest/Internet. For the hosts, described in section 3.6.3, which opt into transparent inbou= nd communication, this capability would be useful to enable on the host sce= narios such as "share resource A, require user authentication for guest/Int= ernet realms and don't require for homenet", or "share resource B within th= e homenet only, while share resource C with all realms". Is there already a section that implies such requirement, or if not, are th= ere concerns with adding such requirement to the draft? -Dmitry From ek@google.com Mon Jul 30 23:56:40 2012 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 5247621F85D4 for ; Mon, 30 Jul 2012 23:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMu302S+CepU for ; Mon, 30 Jul 2012 23:56:39 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9F021F85D1 for ; Mon, 30 Jul 2012 23:56:39 -0700 (PDT) Received: by qaea16 with SMTP id a16so1475321qae.10 for ; Mon, 30 Jul 2012 23:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record; bh=LF8C0ev9HElPvm7kyqpvk4CP3U5ujStXdxwsozVogaA=; b=i6/yckxJ6dTfcCvIwjC5obIvYqbho9rKOaszMt/Zt8DeUhXwscbyZcHo6+FjGSllNa MStmlV0R4pdg6fpKsDRV3KRbKd8Iebd1Cq5SVlD0MQX8/PDXEmQGC1oVNSCDulcQ7/nG OERurN1dhaBBw1zWex0OBhqY9eXv3XS9zyCHrrHxgv90c9e1ZB52ed0xsGUSNbfzgVmB oGwA+33Jy2i6pLEdhPX8YmLlWYNqC2tdesyQqKbnoEAutLYt/zqklKg8JHocJfp4W/9M IX5qkncgP8XL2FV0a8pbG0oGc4xuY8TIi3W6LNtmqja8aLtttucMV5Vrza95GgDoQFKz 4fbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record:x-gm-message-state; bh=LF8C0ev9HElPvm7kyqpvk4CP3U5ujStXdxwsozVogaA=; b=dI0vYl5H6u15KzJj+NHqd4s4olAjgS8CAvqNgsSCKUCUlSCdBtcs7murbLN6tp2/aX 3EQfvgdwxLVOuGdRvmlwyxEFTI6WV+Ejs6KrDEqaEoEdqG047UQpBeuOprRQ2XfH8ZBy 2BhQ0hIuwiVSjwbdFwFQuf/iNQXXneUa9VG5VvpvXQLs1eRnMAvIK/8W41IcT7meQ3I6 Xq+osYwyb3MsgZ9UMb3pXBtqurKb1j8SWPBmNUH8V3TtWu9WPn2rW/347N86MBRTiQDu 548+v7+JFxdUZtOkjz7xTVEOsWGnTL9LBuF0Z5+9HLbtlNUJVxve2w4bSsNCY4yANduB ePnA== Received: by 10.229.134.193 with SMTP id k1mr6871486qct.2.1343717798639; Mon, 30 Jul 2012 23:56:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.134.193 with SMTP id k1mr6871481qct.2.1343717798531; Mon, 30 Jul 2012 23:56:38 -0700 (PDT) Received: by 10.229.139.144 with HTTP; Mon, 30 Jul 2012 23:56:38 -0700 (PDT) Date: Tue, 31 Jul 2012 15:56:38 +0900 Message-ID: From: Erik Kline To: "" Content-Type: multipart/alternative; boundary=00248c7118fd0f52e404c61aae47 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl+qbw/4NIIvw4lD2FwWgLoZdz0tjMeuVoLbePGEAAyefBAjS1Og1hnWmi7rxtKAT6vgWFRO0svOomOe4A8mlVTPJC1jDujmxShQdEvrC0drFoE3zLv1OXCsslX+eViv2FAh8RR1j5/BiEbOTytNxDHZ4es6FK3xHxVIrVj/6X6fxVvNTX9dIuW4H4SE1eu26zWFnTo Subject: [homenet] some thoughts about perimeter identification X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 06:56:40 -0000 --00248c7118fd0f52e404c61aae47 Content-Type: text/plain; charset=UTF-8 All, Sorry for the extremely late work, but here are some -00 thoughts about perimeter identification. http://tools.ietf.org/html/draft-kline-default-perimeter-00 After some discussion with Townsley I think the core issue to discuss will be what default openness stance to adopt: default open or closed, as it affects how a device learns to classify interfaces and whether or not the routing protocol needs to be authenticated (i.e. how much should a device trust the ISP). Apologies again, -Erik --00248c7118fd0f52e404c61aae47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All,

Sorry for the extremely late work, but here are som= e -00 thoughts about perimeter identification.


After some discussion with Townsley I think the core is= sue to discuss will be what default openness stance to adopt: default open = or closed, as it affects how a device learns to classify interfaces and whe= ther or not the routing protocol needs to be authenticated (i.e. how much s= hould a device trust the ISP).

Apologies again,
-Erik
--00248c7118fd0f52e404c61aae47-- From brian.e.carpenter@gmail.com Tue Jul 31 00:49:05 2012 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 4DDAF21F8611 for ; Tue, 31 Jul 2012 00:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMk0lASWhXgN for ; Tue, 31 Jul 2012 00:49:04 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCD121F85F3 for ; Tue, 31 Jul 2012 00:49:04 -0700 (PDT) Received: by eekb45 with SMTP id b45so1470432eek.31 for ; Tue, 31 Jul 2012 00:49:03 -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=czff8ef6HBRweS0ba08BqxAeNmKdluWbFomXSBSfW5w=; b=sw4joTg9BEJ4hnBvJ7XZ0C6viw7G5sj/v7ONNSSTL5lN2ZiuMZHgyKtZZA8m09nOko Z+cp4kXlr1+MoIW8WtJV5Fk1ubQYZ4W8pIwlj8qWP1aVDhr0N/DBwejygU7nJsg/Mnkw XMqaU+bExAzd7R7D51Oe3sIRfdI95ONFDSk9iAjfbyj/bMl3qBV82a2l9I1+M2dMmiI3 Cu97qYa5H6kJSe7dFnw5Mr7GBp2itBtAGrQLXINwi5feV812vTMTHmOs0v7PIxKRyAyL s0dhYM66loJkJtm9gXsrRq6YcMxOBJmmGS2Ya9t9fbbcXrIS34KFwqOkV3J64uJ3aEFd hyYg== Received: by 10.14.177.3 with SMTP id c3mr15313512eem.30.1343720943652; Tue, 31 Jul 2012 00:49:03 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-131.as13285.net. [2.101.189.131]) by mx.google.com with ESMTPS id g46sm34389224eep.15.2012.07.31.00.49.00 (version=SSLv3 cipher=OTHER); Tue, 31 Jul 2012 00:49:01 -0700 (PDT) Message-ID: <50178DEE.1010202@gmail.com> Date: Tue, 31 Jul 2012 08:49:02 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson References: <5655.1343689616@sandelman.ca> In-Reply-To: <5655.1343689616@sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] section 3.2.2.1 of homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 07:49:05 -0000 On 31/07/2012 00:06, Michael Richardson wrote: ... > I'm also surprised that we think we have to cope with flash renumbering > as a regular event, rather than a service-interrupting, ISP truck roll > catastrophy. But every time you reboot your antiquated v4-only CPE and/or the antiquated v4-only PCs behind it, the PCs all get new IP addresses, which may or may not be the same as the previous time. There's nothing new in flash renumbering for homenets. Not handling this would be a step backwards. Homenets are out of scope for 6renum, but there will be considerable overlap. Brian From brian.e.carpenter@gmail.com Tue Jul 31 01:00:42 2012 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 7ADC321F8670 for ; Tue, 31 Jul 2012 01:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2R7yJQUB0miN for ; Tue, 31 Jul 2012 01:00:41 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D21021F8522 for ; Tue, 31 Jul 2012 01:00:41 -0700 (PDT) Received: by eaaa11 with SMTP id a11so1318059eaa.31 for ; Tue, 31 Jul 2012 01:00:40 -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=t7GTWJdwYs6U+wY8QHZBZcYVZoELfrssQDeZ41DMkK4=; b=FA9BdsnRT6qMiby/9VjxHF9CKxAntGwhekn9UbI6xNjGTp2ZJFPoBk+f/QLv23F7qA +gyEw0S1geipxalUM8ClNn+HU9dRBU9Ck84M6QDVbKkhwXtdK9ayMX4st/mDjMv/xZPk eEVHD3TdgOne26NbmhYRAQWwSo7Bs7cdm2jgrCil3n3VxPxy8u/ZOBq8MP0CsLrGFlnn /heHfEol0MoARdFIjf10oHxsd8u9zw+ktSGqn77pIZwagRTK83OxAv+U5GBQ195JntO6 AAeezXeg1ZtF7Mvmsuyq6nzdykWifQan0DmV2f8cs4yOiOUe7uEwEania72krM/aHwTt k9eg== Received: by 10.14.177.135 with SMTP id d7mr15444617eem.42.1343721640634; Tue, 31 Jul 2012 01:00:40 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-131.as13285.net. [2.101.189.131]) by mx.google.com with ESMTPS id k41sm11434597eep.13.2012.07.31.01.00.39 (version=SSLv3 cipher=OTHER); Tue, 31 Jul 2012 01:00:39 -0700 (PDT) Message-ID: <501790A9.1010007@gmail.com> Date: Tue, 31 Jul 2012 09:00:41 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Thomas References: <201207310010.q6V0Annp061316@gateway.ipv6.occnc.com> <501724BA.6010303@mtcc.com> In-Reply-To: <501724BA.6010303@mtcc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Michael Richardson , "" , curtis@occnc.com Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 08:00:42 -0000 On 31/07/2012 01:20, Michael Thomas wrote: > > On 07/30/2012 05:10 PM, Curtis Villamizar wrote: >> If you see some advantage that solves the IPv4 address depletion (a >> big point of the transition to IPv6 exercise), then I've missed it. >> If so, please point out what I missed. > > No, not at all and not the point. I'm just of the mind that if > we believe that v6 is really, really ready to go there shouldn't > be any problem in substituting rfc1918 v4 space with v6 ULA > space. If that modest change leads to trouble... Well, it surely requires a DNS64 resolver in the CPE too. Brian From mike@mtcc.com Tue Jul 31 06:05:36 2012 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 7C01121F86C3 for ; Tue, 31 Jul 2012 06:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.745 X-Spam-Level: X-Spam-Status: No, score=-2.745 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRQHUZnfNWZf for ; Tue, 31 Jul 2012 06:05:36 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id C527221F86C2 for ; Tue, 31 Jul 2012 06:05:35 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6VD5Tiq013791 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 31 Jul 2012 06:05:30 -0700 Message-ID: <5017D819.9030607@mtcc.com> Date: Tue, 31 Jul 2012 06:05:29 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: homenet@ietf.org References: <201207310010.q6V0Annp061316@gateway.ipv6.occnc.com> <501724BA.6010303@mtcc.com> <501790A9.1010007@gmail.com> In-Reply-To: <501790A9.1010007@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=849; t=1343739935; x=1344603935; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20a=20modest=20proposal |Sender:=20 |To:=20homenet@ietf.org |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=LF9FDz0j1Vz4/LTdfmR8RjGWNpIA/WUVKPEVb0Q0pl0=; b=nzRBQaJ9+TbKr+AqrxppH8Fv1jpjO50PeZtxk1SRPW1dSAVMSEEjDj5WTU XF9OS5T8PP9rBEMEcjzjPYd+HZZo0ytJE7XqGbFOyWLIc2e8Mz2gZf4ES/a3 zU19MbSs6ctPWE/CMnHC+KGxkhHIQpBvOurqca8eV10SY1VDwLKEA=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 13:05:36 -0000 On 07/31/2012 01:00 AM, Brian E Carpenter wrote: > On 31/07/2012 01:20, Michael Thomas wrote: >> On 07/30/2012 05:10 PM, Curtis Villamizar wrote: >>> If you see some advantage that solves the IPv4 address depletion (a >>> big point of the transition to IPv6 exercise), then I've missed it. >>> If so, please point out what I missed. >> No, not at all and not the point. I'm just of the mind that if >> we believe that v6 is really, really ready to go there shouldn't >> be any problem in substituting rfc1918 v4 space with v6 ULA >> space. If that modest change leads to trouble... > Well, it surely requires a DNS64 resolver in the CPE too. > Having embedded DNS functionality in the CPE is sort of a newish requirement, yes? If we think that's inevitable for real homenets, maybe this is a means of moving the ball forward? Mike From lee.howard@twcable.com Tue Jul 31 06:25:48 2012 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 0352621F85D5 for ; Tue, 31 Jul 2012 06:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.337 X-Spam-Level: X-Spam-Status: No, score=0.337 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iqc2YNhymMJx for ; Tue, 31 Jul 2012 06:25:47 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4E54E21F85D4 for ; Tue, 31 Jul 2012 06:25:47 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,686,1336363200"; d="scan'208,217";a="417307435" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 31 Jul 2012 09:25:36 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Tue, 31 Jul 2012 09:25:46 -0400 From: "Howard, Lee" To: Michael Thomas , "curtis@occnc.com" Date: Tue, 31 Jul 2012 09:25:46 -0400 Thread-Topic: [homenet] a modest proposal Thread-Index: Ac1vH/5FLWojBY5aToyidC72D3vVKg== Message-ID: In-Reply-To: <501724BA.6010303@mtcc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC3D2A4D76F3leehowardtwcablecom_" MIME-Version: 1.0 Cc: Michael Richardson , "" Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 13:25:48 -0000 --_000_CC3D2A4D76F3leehowardtwcablecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 7/30/12 5:20 PM, "Michael Thomas" > = wrote: On 07/30/2012 05:10 PM, Curtis Villamizar wrote: If you see some advantage that solves the IPv4 address depletion (a big point of the transition to IPv6 exercise), then I've missed it. If so, please point out what I missed. No, not at all and not the point. I'm just of the mind that if we believe that v6 is really, really ready to go there shouldn't be any problem in substituting rfc1918 v4 space with v6 ULA space. If that modest change leads to trouble... Why would you try to create problems that don't yet exist? IPv6 isn't really, really ready to go until it arrives at your doorstep. Lee ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_CC3D2A4D76F3leehowardtwcablecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable




On 07/30/2012 05:10 PM, Curtis Villamizar wrote:
If you see some advantage that solves the IPv4 address depletion (a
big point of the transition to IPv6 exercise), then I've missed it.
If so, please point out what I missed.

No, not at all and not the point. I'm just of the mind that if
we believe that v6 is really, really ready to go there shouldn't
be any problem in substituting rfc1918 v4 space with v6 ULA
space. If that modest change leads to trouble...

Why would you try to create problems that don't yet exist?
IPv6 isn't really, really ready to go until it arrives at your doorste= p.  

Lee



This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_CC3D2A4D76F3leehowardtwcablecom_-- From curtis@occnc.com Tue Jul 31 08:15:44 2012 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 5CE8021F8673 for ; Tue, 31 Jul 2012 08:15:44 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGGk7s06F1yQ for ; Tue, 31 Jul 2012 08:15:43 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 99C0221F8582 for ; Tue, 31 Jul 2012 08:15:43 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q6VFFIi4076676; Tue, 31 Jul 2012 11:15:18 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201207311515.q6VFFIi4076676@gateway.ipv6.occnc.com> To: Michael Thomas From: Curtis Villamizar In-reply-to: Your message of "Mon, 30 Jul 2012 17:20:10 PDT." <501724BA.6010303@mtcc.com> Date: Tue, 31 Jul 2012 11:15:18 -0400 Cc: Michael Richardson , "" , curtis@occnc.com Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 15:15:44 -0000 In message <501724BA.6010303@mtcc.com> Michael Thomas writes: > > On 07/30/2012 05:10 PM, Curtis Villamizar wrote: > > If you see some advantage that solves the IPv4 address depletion (a > > big point of the transition to IPv6 exercise), then I've missed it. > > If so, please point out what I missed. > > No, not at all and not the point. I'm just of the mind that if > we believe that v6 is really, really ready to go there shouldn't > be any problem in substituting rfc1918 v4 space with v6 ULA > space. If that modest change leads to trouble... > > Mike It may yield no benefit except to shake out bugs at customer sites. If so, it would increase support costs for the provider. Grandma's Windows98 machine needs an IPv4 address and without it she can't fetch recipes and read occasional email and run bots in the background. :-) Curtis From mike@mtcc.com Tue Jul 31 08:27:20 2012 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 1E49821F86BD for ; Tue, 31 Jul 2012 08:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.738 X-Spam-Level: X-Spam-Status: No, score=-2.738 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tQnf9xQ+0kB for ; Tue, 31 Jul 2012 08:27:19 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 22B8421F862A for ; Tue, 31 Jul 2012 08:27:18 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6VFRHm5009395 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 31 Jul 2012 08:27:18 -0700 Message-ID: <5017F955.1020305@mtcc.com> Date: Tue, 31 Jul 2012 08:27:17 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: curtis@occnc.com References: <201207311515.q6VFFIi4076676@gateway.ipv6.occnc.com> In-Reply-To: <201207311515.q6VFFIi4076676@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1319; t=1343748438; x=1344612438; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20a=20modest=20proposal |Sender:=20 |To:=20curtis@occnc.com |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=To0gz1H5cCkwi9zMTApuiYW7wLKa5BJFx8Sr/mB3GjU=; b=HZL2WU2BIQ9XAKJeWiHrvz1I3zjNq/7YdXJTyMYVF8LjOgcv4rWc9JeCWV iQyzEMaeEBTgqsz8cczffOzpsaSAdlN1ieaVUSft05f2GLNQ6r35Vna2GvcO AkduNDzyq/oJI8NHtPG6713GpLzyifZN/oQ9q9aoxdHEE2S7zE76c=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Michael Richardson , "" Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 15:27:20 -0000 On 07/31/2012 08:15 AM, Curtis Villamizar wrote: > In message <501724BA.6010303@mtcc.com> > Michael Thomas writes: > >> >> On 07/30/2012 05:10 PM, Curtis Villamizar wrote: >>> If you see some advantage that solves the IPv4 address depletion (a >>> big point of the transition to IPv6 exercise), then I've missed it. >>> If so, please point out what I missed. >> >> No, not at all and not the point. I'm just of the mind that if >> we believe that v6 is really, really ready to go there shouldn't >> be any problem in substituting rfc1918 v4 space with v6 ULA >> space. If that modest change leads to trouble... >> >> Mike > > It may yield no benefit except to shake out bugs at customer sites. > If so, it would increase support costs for the provider. > > Grandma's Windows98 machine needs an IPv4 address and without it she > can't fetch recipes and read occasional email and run bots in the > background. :-) > To be fair, I think some of the new features being contemplated here both require ipv6, and would be potentially beneficial without requiring global v6 connectivity. But shaking out bugs -- and getting people used to ipv6 -- isn't a Bad Thing, IMO. The more old hat and normal v6 usage is, the less frightening it will be for ISP's to roll out, right? Mike From marka@isc.org Tue Jul 31 08:40:52 2012 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 B072B21F861F for ; Tue, 31 Jul 2012 08:40:52 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BN7Jn+j5F6-q for ; Tue, 31 Jul 2012 08:40:52 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 385BB21F85C3 for ; Tue, 31 Jul 2012 08:40:52 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 48FAE5F997A; Tue, 31 Jul 2012 15:40:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:64:a16e:ac57:fd8f:4c53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B584C216C36; Tue, 31 Jul 2012 15:40:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 517992325968; Wed, 1 Aug 2012 01:40:35 +1000 (EST) To: Michael Thomas From: Mark Andrews References: <5016CD8E.1000008@mtcc.com> In-reply-to: Your message of "Mon, 30 Jul 2012 11:08:14 MST." <5016CD8E.1000008@mtcc.com> Date: Wed, 01 Aug 2012 01:40:35 +1000 Message-Id: <20120731154035.517992325968@drugs.dv.isc.org> Cc: "" Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 15:40:52 -0000 In message <5016CD8E.1000008@mtcc.com>, Michael Thomas writes: > I know this is ietf week, but... > > If we believe that ipv6 is ready to go for mass deployment, why do we > not pressure home router vendors to default to sending router advertisements > with ULA addresses that, if necessary, get NAT'd at the border just like > 192.168 space does today. > > I mean, nothing bad would happen, right? > > Mike Well if you think every piece of software supports HE go for it. If you want to find every piece of software that doesn't support HE go for it. One doesn't need to NAT, just introduce a second prefix when the home is eventually connected. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From kerlyn2001@gmail.com Tue Jul 31 08:59:50 2012 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 1196421F8710 for ; Tue, 31 Jul 2012 08:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.851 X-Spam-Level: X-Spam-Status: No, score=-101.851 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJBdlafUFJzP for ; Tue, 31 Jul 2012 08:59:49 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB19821F870E for ; Tue, 31 Jul 2012 08:59:48 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4423945lbb.31 for ; Tue, 31 Jul 2012 08:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6qnUcgdGPRHgIBUjo0iGFoDaIm6NNebYsCqdHjx7oeA=; b=c4o74roStV3IC+5FUkpNhBG72z+8vYvtUZdpTzQ1lAx0ETfL9nlZysDGQx4lE2Jz3t fhpplNBLhFk17D5I1CoA5EGFkfC9/NhzQEwG3wLru2V/QRv4PvhmNwmQ7t721qLxeKrQ /f6QoREWMJneeijlMTj3pgjdkoGTP1B1oOVOuwr8tm5lUu0n2QUl7qDG7hu8eUGJG8ro Y8zg4pJnmyDZI1v2r/qoNZISoj0m+vWKR55wmCdl7iOyMbwTTMAMqSfkHXClbuavbP8X I3d62gDwg4B/s5xWAj7FL+X+T7xTIV8KLMzGHCMTXcUGM27n5f2tgS86SMYqxhx52r6/ HR3g== MIME-Version: 1.0 Received: by 10.112.40.36 with SMTP id u4mr6915249lbk.70.1343750387662; Tue, 31 Jul 2012 08:59:47 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.10.199 with HTTP; Tue, 31 Jul 2012 08:59:47 -0700 (PDT) In-Reply-To: <5615.1343689590@sandelman.ca> References: <5615.1343689590@sandelman.ca> Date: Tue, 31 Jul 2012 11:59:47 -0400 X-Google-Sender-Auth: iu3u6SOB9JeQfgC9nWzdH1TbLwM Message-ID: From: Kerry Lynn To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Cc: homenet@ietf.org Subject: Re: [homenet] how to bookmark .lan, /.home, /.my-homenet when not home X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 15:59:50 -0000 On Mon, Jul 30, 2012 at 7:06 PM, Michael Richardson wrote: > > while reading drafts on the airplane, I have come to think that picking > any specific name a la ".local" for the homenet name service is fraught > with RFC1918-like confusion. For the actual printer and refridgerator > (which does not move, but needs to talk to the TV) it's not a big deal, > but for mobile devices, I think it's gonna lead to confusion. > Michael, For those of us familiar with http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns the continued use of ".local." in these threads is leading to some confusion, as we synonymize this with using Multicast DNS (mDNS) instead of Unicast DNS. As was noted in a previous thread, "Special-Use Domain Names" has been approved as a Proposed Standard: http://www.ietf.org/mail-archive/web/ietf-announce/current/msg10435.html The mDNS draft places ".local" in this category and specifies: that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully- qualified name ending in ".local." is link-local, and names within this domain are meaningful only on the link where they originate. > When I'm at your house, and I visit "fridge.local", do I get your > fridge, or mine? Mine, by definition. Given that I'm not sure how you mean ".homenet" to work by comparison, I'm not sure I completely understand the rest of the discussion. > Assuming I want mine, if I've discovered it when I was > at home, how would I bookmark and remember it, assuming it had a GUA? > If you are remotely accessing resources in your home, you are probably more advanced than 99% of all home network users. Why wouldn't the solution you use on the road apply equally well at your neighbor's house? (I'm thinking here of services like dyndns.) You simply put the domain in which your fridge is registered earlier than ".local." in your DNS search path, no? If all else fails, put it in /etc/hosts? > I therefore propose adding a level of indirection (because that solves > every problem....), which (mobile) hosts will ideally become aware of. > > I think of this as a layer above the current LLMNR/mDNS/Bonjour++ layer. > > My idea is that the .homenet/.local discovery protocol would, in > addition to the AAAA ULA or GUA record, would provide a reference a > unique name which might not be globally resolvable from the DNS root, > but can be resolved by arrangement. This would be not unlike > split-horizon DNS, but given IPv6 reachability, no VPN necessary. > > For sites where mglt-name-delegation works, great, use that! > For those where this doesn't work, we need a new well known name. > Perhaps it can find a "logical" place in arpa. Let's say it's based > upon the ULA, and the home with prefix A:B:C:D gets > D.C.B.A.homenet.arpa. (add this to DNS search path...) > I think defining new "zones" under .arpa. may have merit in the following respect: ICANN is now in the business of selling dotless domain names. Despite the fact that there are many grandfathered special domain names (including .local.) nobody that I know of has yet attempted to allocate a new one. Defining new special use names under .arpa. may be a way of allocating them within IETF's authority, without approval from ICANN. Note also that http://tools.ietf.org/html/rfc6303 defines a registry that is apparently similar to special-names (at least there appears to be some overlap): http://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xml Regards, -K- > When an application resolves fridge.local, if the fridge has a GUA > which it has provided to the CPE's DNS server, then it also returns a > pointer to the "long-term name" (probably in a new RR) like > "fridge.D.C.B.A.homenet.arpa". Any bookmarks and the like would contain > that address (HTTP/HTML has existing mechanisms to deal with this), > other applications might see this as the canonical name. (getaddrinfo(3) > already has a canonname) > > My idea is that given IPv6 reachability for the HOME's CPE(s), that a > mobile recursive (secure) DNS resolver can learn to make queries for > D.C.B.A.homenet.arpa. directly to the home CPE, even when the mobile > device is not "at home". > > The mobile device needs to be "pair"ed with the CPE such that it agrees > to do this side-ways lookup. It's pretty much identical to a windows > desktop joining an AD (but I can't speak to the "home edition" being > able to do that... don't do windows). > > This process is, I admit, a form of walled garden DNS, something I've > argued against as being unnecessary. I'd rather that the ISPs provided > a name, but I feel that ISPs won't be very fast to offer this, and for > the home user with no native IPv6 (using a managed tunnel, for > instance), that a protocol such as I am suggesting, would provide a > clear value (something people would brag about to their friends...) > without requiring people to "wait" for their ISP. > > This does not replace "fridge.local" referring to the fridge on the > network that you are on, but it does provide a way to easily discover > and then bookmark "my fridge". > > (written offline using xemacs on android) > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From lee.howard@twcable.com Tue Jul 31 09:20:44 2012 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 F3D7221F86EB for ; Tue, 31 Jul 2012 09:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhpuW0HjvRNz for ; Tue, 31 Jul 2012 09:20:43 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5758D21F86EA for ; Tue, 31 Jul 2012 09:20:43 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,686,1336363200"; d="scan'208";a="417442859" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 31 Jul 2012 12:19:57 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Tue, 31 Jul 2012 12:20:02 -0400 From: "Howard, Lee" To: Michael Thomas , "curtis@occnc.com" Date: Tue, 31 Jul 2012 12:20:01 -0400 Thread-Topic: [homenet] a modest proposal Thread-Index: Ac1vOFY9kHdyo35hStqqNtfaGuBc2A== Message-ID: In-Reply-To: <5017F955.1020305@mtcc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , "" Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:20:44 -0000 On 7/31/12 8:27 AM, "Michael Thomas" wrote: >> >> It may yield no benefit except to shake out bugs at customer sites. >> If so, it would increase support costs for the provider. >> >> Grandma's Windows98 machine needs an IPv4 address and without it she >> can't fetch recipes and read occasional email and run bots in the >> background. :-) >> > >To be fair, I think some of the new features being contemplated >here both require ipv6, and would be potentially beneficial without >requiring global v6 connectivity. But shaking out bugs -- and getting >people used to ipv6 -- isn't a Bad Thing, IMO. The more old hat and >normal v6 usage is, the less frightening it will be for ISP's to roll out, >right? No. I don't want to shake out bugs in consumers' homes. Let's say we did this, and Grandma's machine had a problem. Who is supposed to troubleshoot that problem, identify it as IPv6-related, and submit a bug report? ISPs are rolling out IPv6. There is nothing to be gained by breaking consumer networks before they have IPv6 access. Let early adopters find and squish bugs. Lee This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From bkerensa@gmail.com Mon Jul 30 19:45:03 2012 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 74ECE21F8496 for ; Mon, 30 Jul 2012 19:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.043 X-Spam-Level: X-Spam-Status: No, score=-3.043 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGK8LwMMj7Tu for ; Mon, 30 Jul 2012 19:45:03 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C70A521F8495 for ; Mon, 30 Jul 2012 19:45:02 -0700 (PDT) Received: by ggnc4 with SMTP id c4so6018652ggn.31 for ; Mon, 30 Jul 2012 19:45:02 -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=g1757hcTo7DvUlNwQJSQRB9BTxz57+5BTFG4ioydXM0=; b=p5uC6nEZf0bqY1HFYU1LKT8jlTTtSlVYbd2KPyz35RxsArNG1/9PPx3OVn0/VRvOXy jaEQc/WoDSjBz+b0ThXyMhmNaBN/MBoMmPW57A40tONdEJYAssqH5AgtBf6oFO8z6gFb l8L32+Qa+5/IdgEf1yq/H37p6JdOzTrOv2mcQrHXacy7trykt0w3NSW6w3hgBzUE+5nJ 97RH+QcNdWZmnRJG7ItHCWywrClEnIhT7fV0Nnx/p16Wbs1uXLWn+uKDLXSgcEUFGcM8 oU/rIp8LxqUQoJFkOW+vjwvtbIFcfU0M9ApUZ9p1GkeTCA8xGbmoP08XJZ5RjKSULB2x wqbg== MIME-Version: 1.0 Received: by 10.50.189.135 with SMTP id gi7mr45689igc.8.1343702702163; Mon, 30 Jul 2012 19:45:02 -0700 (PDT) Received: by 10.64.82.6 with HTTP; Mon, 30 Jul 2012 19:45:02 -0700 (PDT) Received: by 10.64.82.6 with HTTP; Mon, 30 Jul 2012 19:45:02 -0700 (PDT) In-Reply-To: <5016CD8E.1000008@mtcc.com> References: <5016CD8E.1000008@mtcc.com> Date: Mon, 30 Jul 2012 19:45:02 -0700 Message-ID: From: Benjamin Kerensa To: Michael Thomas Content-Type: multipart/alternative; boundary=14dae934040b3f056504c6172a2f X-Mailman-Approved-At: Tue, 31 Jul 2012 09:26:19 -0700 Cc: "<,homenet@ietf.org>," Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:45:03 -0000 --14dae934040b3f056504c6172a2f Content-Type: text/plain; charset=ISO-8859-1 On Jul 30, 2012 4:03 PM, "Michael Thomas" wrote: > > I know this is ietf week, but... > > If we believe that ipv6 is ready to go for mass deployment, why do we > not pressure home router vendors to default to sending router advertisements > with ULA addresses that, if necessary, get NAT'd at the border just like > 192.168 space does today. > > I mean, nothing bad would happen, right? > Correct. --14dae934040b3f056504c6172a2f Content-Type: text/html; charset=ISO-8859-1


On Jul 30, 2012 4:03 PM, "Michael Thomas" <mike@mtcc.com> wrote:
>
> I know this is ietf week, but...
>
> If we believe that ipv6 is ready to go for mass deployment, why do we
> not pressure home router vendors to default to sending router advertisements
> with ULA addresses that, if necessary, get NAT'd at the border just like
> 192.168 space does today.
>
> I mean, nothing bad would happen, right?
>

Correct.

--14dae934040b3f056504c6172a2f-- From bs7652@att.com Tue Jul 31 09:55:03 2012 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 CBC9C21F8643 for ; Tue, 31 Jul 2012 09:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.448 X-Spam-Level: X-Spam-Status: No, score=-106.448 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6W0EJ4bI-LM for ; Tue, 31 Jul 2012 09:55:00 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 080AB21F8726 for ; Tue, 31 Jul 2012 09:54:59 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 3ed08105.52bf0940.565506.00-510.1555730.nbfkord-smmo04.seg.att.com (envelope-from ); Tue, 31 Jul 2012 16:54:59 +0000 (UTC) X-MXL-Hash: 50180de3042a8525-f60e662837d1904d398c06e1c0f35f7ec2f1b422 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 1ed08105.0.565497.00-414.1555692.nbfkord-smmo04.seg.att.com (envelope-from ); Tue, 31 Jul 2012 16:54:57 +0000 (UTC) X-MXL-Hash: 50180de143588e95-d5dc95d7721c20cab6e02acffd57717f4a12a092 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q6VGsuN6025874; Tue, 31 Jul 2012 12:54:56 -0400 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q6VGsaOr025546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jul 2012 12:54:50 -0400 Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (gaalpa1msghub9a.itservices.sbc.com [130.8.36.87]) by sflint03.pst.cso.att.com (RSA Interceptor); Tue, 31 Jul 2012 12:54:13 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([130.8.36.71]) by GAALPA1MSGHUB9A.ITServices.sbc.com ([130.8.36.87]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 12:54:12 -0400 From: "STARK, BARBARA H" To: Benjamin Kerensa , Michael Thomas Thread-Topic: [homenet] a modest proposal Thread-Index: AQHNbqeGXhm2vfNcP0a4H8jmbL65cJdC8rYAgAClRLA= Date: Tue, 31 Jul 2012 16:54:11 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611157388@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <5016CD8E.1000008@mtcc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.237.198] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E611157388GAALPA1MSGUSR9NIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=kCfitQJcpzcA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a=P_dBUBuSck_uU1F7wVIA] X-AnalysisOut: [:9 a=CjuIK1q_8ugA:10 a=kMrnzbb4RaomGL9I:21 a=0TjgROuIRXlIx] X-AnalysisOut: [b90:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVkA:10] X-AnalysisOut: [ a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10] Cc: "<,homenet@ietf.org>," Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:55:03 -0000 --_000_2D09D61DDFA73D4C884805CC7865E611157388GAALPA1MSGUSR9NIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Incorrect. It's my experience that router manufacturers don't have people sitting arou= nd twiddling their thumbs wondering how to spend their precious work hours. The Internet ecosystem is best served by CE routers that have rock-solid "n= ative IPv6" implementations. Given the relatively large quantity of 6rd cur= rently in use to supply IPv6 to customers (around the world), having rock-s= olid 6rd is also a priority. Any cycles that router manufacturers spend on development and QA of what yo= u propose, are cycles taken away from coding and QA of the IPv6 functions w= e really do need. When cycles are taken away from that critical code, the s= tretched QA resources miss the bugs that the stretched developers introduce= both in the code we do need, and in the code for this new function. Which leaves the ISP's stretched help desk resources supporting customers w= ho not only have buggy native IPv6 and 6rd in their CE routers, but also th= e IPv4-only customers who now have buggy code for this new proposed functio= nality. Which would have the end result of taking resources away from IPv6 deployme= nts and development. Which would slow down IPv6 deployment. Adding moving parts, potentially breaking things that aren't broken (while = providing no discernible-to-the-average-user functionality), and stretching= already-stretched resources is not a way to speed up IPv6 deployment. Rath= er, it's a very good way to slow it down. Barbara > If we believe that ipv6 is ready to go for mass deployment, why do we > not pressure home router vendors to default to sending router advertiseme= nts > with ULA addresses that, if necessary, get NAT'd at the border just like > 192.168 space does today. > > I mean, nothing bad would happen, right? > Correct. --_000_2D09D61DDFA73D4C884805CC7865E611157388GAALPA1MSGUSR9NIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Incorrect.

It’s my experience that router ma= nufacturers don’t have people sitting around twiddling their thumbs w= ondering how to spend their precious work hours.

The Internet ecosystem is best served b= y CE routers that have rock-solid “native IPv6” implementations= . Given the relatively large quantity of 6rd currently in use to supply IPv6 to customers (around the world), having rock-solid 6rd is also a prio= rity.

 

Any cycles that router manufacturers sp= end on development and QA of what you propose, are cycles taken away from c= oding and QA of the IPv6 functions we really do need. When cycles are taken away from that critical code, the stretched QA resources = miss the bugs that the stretched developers introduce both in the code we d= o need, and in the code for this new function.

 

Which leaves the ISP’s stretched = help desk resources supporting customers who not only have buggy native IPv= 6 and 6rd in their CE routers, but also the IPv4-only customers who now have buggy code for this new proposed functionality.

 

Which would have the end result of taki= ng resources away from IPv6 deployments and development. Which would slow d= own IPv6 deployment.

 

Adding moving parts, potentially breaki= ng things that aren’t broken (while providing no discernible-to-the-a= verage-user functionality), and stretching already-stretched resources is not a way to speed up IPv6 deployment. Rather, it’s a very good w= ay to slow it down.

Barbara

> If we believe that ipv6 is ready to go for mass deployment, why do = we
> not pressure home router vendors to default to sending router advertis= ements
> with ULA addresses that, if necessary, get NAT'd at the border just li= ke
> 192.168 space does today.
>
> I mean, nothing bad would happen, right?
>

Correct.

--_000_2D09D61DDFA73D4C884805CC7865E611157388GAALPA1MSGUSR9NIT_-- From mcr+ietf@sandelman.ca Tue Jul 31 09:59:24 2012 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 BBAAA21F86CF for ; Tue, 31 Jul 2012 09:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdVLKcOXf6Mp for ; Tue, 31 Jul 2012 09:59:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id C486121F86CB for ; Tue, 31 Jul 2012 09:59:23 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id 7BD522016A; Tue, 31 Jul 2012 13:11:42 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <50178DEE.1010202@gmail.com> References: <5655.1343689616@sandelman.ca> <50178DEE.1010202@gmail.com> X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) 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 Cc: homenet@ietf.org Subject: Re: [homenet] section 3.2.2.1 of homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:59:24 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Brian" =3D=3D Brian E Carpenter writes: >> I'm also surprised that we think we have to cope with flash renumber= ing >> as a regular event, rather than a service-interrupting, ISP truck ro= ll >> catastrophy.=20 Brian> But every time you reboot your antiquated v4-only CPE and/or the= antiquated Brian> v4-only PCs behind it, the PCs all get new IP addresses, which m= ay or Brian> may not be the same as the previous time. There's nothing new in= flash Brian> renumbering for homenets. Not handling this would be a step Brian> backwards. Well...=20 1) sure, but the *customer* does this, not the ISP. 2) the clients do have DHCP leases, and if they ask to renew their previous IP, it usually gets honored. In IPv6 space, the host part will generally stay the same (modulo privacy extensions, which are default on for some clients). We've said that the ULA ought to stay the same, so in fact, I agree, the internal addresses actually all stay the same. I'm still surprised that an ISP will need to flash renumber faster than it can just expire leases. If it's just repartitioning of network to deal with growth, that ought to be predictable and prefix lifetimes can be reduced in advance.=20=20 If it's actually some equipment failing, resulting in service interruptions, and then restoration by rewiring the network... then I understand.=20=20 =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBgO54qHRg3pndX9AQKTXAQA4IBCgN4k4aqw94MrYHcli7hRKJfTeJu3 3HpTQ73WM7X5rzugeowU7yavHByvtQNYeVbb23nfbqfV1LeR16TzbkO/E7SehBKS gA5ZZN1OpLDot9yClN4UzVk3eUPQO5l1jMhla6WrEPRtI1mmks6WKW/mlitPlAVP h4VZjggvYjQ= =ELA9 -----END PGP SIGNATURE----- --=-=-=-- From mark@townsley.net Tue Jul 31 10:01:14 2012 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 E947521F86D9 for ; Tue, 31 Jul 2012 10:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHXK9Hecnciz for ; Tue, 31 Jul 2012 10:01:14 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 18DE221F873C for ; Tue, 31 Jul 2012 10:01:14 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so625768pbb.31 for ; Tue, 31 Jul 2012 10:01:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=AlfvmebSsl94hkgEZ4OTTbgKa/9raIGBoeWFw3+RY9A=; b=T1ftWvmrSWQcqFYgx4PvJRTf8bJ5bSybNCZ06RkAZelUm4XHV8hGw/t0T6F1Trsd08 x/oS7attdGk6BvD17p52DZw/YxcIwOa8mtER+yOeDHedFu2oNUWiEmge2hIEzi8pfc2z jHMyyMrm8fohIEgbyRk0z2jrHf6smvYMNIwI4W89fcUSstIE3w/qJczVzlSlQ83ISO3m +z9HOvrBVtbr4JT+y42ZopiaapMTubjls0LNy8suIIlljG8KmOqmZejk41KzmUC1180x Vbve7FS0EIek1blkeWEGatgTQa7yikKy5zs+3HiUbhREyWPZMt2aZfPxMcMeE6flpzHV pX+A== Received: by 10.68.224.233 with SMTP id rf9mr45643950pbc.141.1343754073885; Tue, 31 Jul 2012 10:01:13 -0700 (PDT) Received: from [192.168.10.168] ([64.114.255.126]) by mx.google.com with ESMTPS id qb10sm625708pbc.21.2012.07.31.10.01.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 Jul 2012 10:01:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <9474.1343690901@obiwan.sandelman.ca> Date: Tue, 31 Jul 2012 10:01:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4999ED78-B0DF-4DE7-9B51-0524592E5061@apple.com> <47B88B0C-EA3E-4222-85A1-95C9D1E67CD3@fugue.com> <9474.1343690901@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnSilD3756EM0pEqr5ilXQrawN9cDhK4SpHgDoWfhNX9a3BUY0HK7RPzKjHdMsKxm2JHh4z Cc: "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 17:01:15 -0000 On Jul 30, 2012, at 4:28 PM, Michael Richardson wrote: >=20 >=20 > james> I guess I had hoped the HOMENET group would more easily find > james> consensus around addressing this promptly, but that may have > james> been wishful thinking.=20 >=20 > I am 400% behind you, and if buying you beer will help, tell me. One of the primary purposes of homenet's scope being what it is, is to = help us make some tough calls that might prove impossible in the context = of every conceivable network on the planet, but are within reach given = the context of a homenet. I'd like to strongly encourage the WG to work = towards consensus of what is right for our problem at hand. We will then = have to see if it flies in the broader context, but let's try and figure = out what we want for the home first.=20 - Mark From mark@townsley.net Tue Jul 31 10:17:44 2012 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 C199E21F8737 for ; Tue, 31 Jul 2012 10:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-1.601, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIF4CEmiyE5s for ; Tue, 31 Jul 2012 10:17:43 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 29C8221F8747 for ; Tue, 31 Jul 2012 10:17:31 -0700 (PDT) Received: by ggnc4 with SMTP id c4so6811576ggn.31 for ; Tue, 31 Jul 2012 10:17:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=zY2ogFFmiZvpZ2dpGe1Eb8GILJH4DsyvMIvBan0pkmA=; b=kznMbSafSNuCaNW2VF4pKLNK28X9GuDQoJC2NRcCwzX84NMG4KUFsMm/yNL4D+/t79 XJmZl+HmYnllwjoTMLVEq6b0iqzkvV72pOrksQzt1Vsyiw8I6cfMTmxXcfTqjJhB63Zq G2G6II4LH+Mi9IjKXW3MP3IcvNJK+697gmmlQdXRZK2jGPNj1bogfch/ZcTRqclPj8j3 i3D0ImOcop9Pe3vmqhY7JpEeHhJ4b2JNzMStvxzQ06KVVnd+V3DfdO7pgSqB6GKFdF50 jNjOTQP0Yd+FqQOgg3OwW7c9/7yCXf891r4NEjrCAI9Xjtccuum0xhUWYIsw9K2rVqYs vTAQ== Received: by 10.66.81.232 with SMTP id d8mr33688129pay.66.1343755050420; Tue, 31 Jul 2012 10:17:30 -0700 (PDT) Received: from [192.168.10.168] ([64.114.255.126]) by mx.google.com with ESMTPS id se9sm650805pbc.25.2012.07.31.10.17.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 Jul 2012 10:17:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_1663BE62-91AF-46E2-B207-E995B7B55578" From: Mark Townsley In-Reply-To: Date: Tue, 31 Jul 2012 10:17:26 -0700 Message-Id: <1681395B-8057-4410-AB17-13BDDE4D3366@townsley.net> References: To: "Howard, Lee" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmZLxSxGY2JYa0VAUP9xD+zlk2RKjacWilXB3n8AiJQ27ew9JlY+REBxk4PfzD3z4fZ6JNe Cc: Michael Richardson , "" , Michael Thomas , "curtis@occnc.com" Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 17:17:45 -0000 --Apple-Mail=_1663BE62-91AF-46E2-B207-E995B7B55578 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 31, 2012, at 6:25 AM, Howard, Lee wrote: >=20 >=20 > On 7/30/12 5:20 PM, "Michael Thomas" wrote: >=20 >>=20 >> On 07/30/2012 05:10 PM, Curtis Villamizar wrote: >>> If you see some advantage that solves the IPv4 address depletion (a >>> big point of the transition to IPv6 exercise), then I've missed it. >>> If so, please point out what I missed. >>=20 >> No, not at all and not the point. I'm just of the mind that if >> we believe that v6 is really, really ready to go there shouldn't >> be any problem in substituting rfc1918 v4 space with v6 ULA >> space. If that modest change leads to trouble... >=20 > Why would you try to create problems that don't yet exist? > IPv6 isn't really, really ready to go until it arrives at your = doorstep. =20 Agreed. In terms of Internet connectivity, the homenet WG is about getting IPv6 = working within the home, once it has arrived from the ISP. There remains = the question of the "disconnected" home, where ULAs and LLs are = important and within scope. But, we're not working on "transition = mechanisms" here. See softwires, behave, v6ops, or maybe sunset4 for = that discussion. - Mark >=20 > Lee >=20 >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail=_1663BE62-91AF-46E2-B207-E995B7B55578 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jul 31, 2012, at 6:25 AM, Howard, Lee wrote:



On 7/30/12 5:20 PM, "Michael Thomas" <mike@mtcc.com> wrote:


On 07/30/2012 05:10 PM, Curtis Villamizar wrote:
If you see some advantage that solves the IPv4 address depletion (a
big point of the transition to IPv6 exercise), then I've missed it.
If so, please point out what I missed.

No, not at all and not the point. I'm just of the mind that if
we believe that v6 is really, really ready to go there shouldn't
be any problem in substituting rfc1918 v4 space with v6 ULA
space. If that modest change leads to trouble...

Why would you try to create problems that don't yet exist?
IPv6 isn't really, really ready to go until it arrives at your doorstep.  

Agreed.

<chair hat on>

In terms of Internet connectivity, the homenet WG is about getting IPv6 working within the home, once it has arrived from the ISP. There remains the question of the "disconnected" home, where ULAs and LLs are important and within scope. But, we're not working on "transition mechanisms" here. See softwires, behave, v6ops, or maybe sunset4 for that discussion.

- Mark


Lee



This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

--Apple-Mail=_1663BE62-91AF-46E2-B207-E995B7B55578-- From mcr+ietf@sandelman.ca Tue Jul 31 10:42:52 2012 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 273EC21F883F for ; Tue, 31 Jul 2012 10:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7t7Oi7zuJ0k for ; Tue, 31 Jul 2012 10:42:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id 5287721F883E for ; Tue, 31 Jul 2012 10:42:51 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id 1F00E2016A; Tue, 31 Jul 2012 13:55:10 -0400 (EDT) From: Michael Richardson To: Kerry Lynn In-Reply-To: References: <5615.1343689590@sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) 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 Cc: homenet@ietf.org Subject: Re: [homenet] how to bookmark .lan, /.home, /.my-homenet when not home X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 17:42:52 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Kerry" =3D=3D Kerry Lynn writes: >> When I'm at your house, and I visit "fridge.local", do I get your >> fridge, or mine? Kerry> Mine, by definition. Given that I'm not sure how you mean ".hom= enet" Kerry> to work by comparison, I'm not sure I completely understand the = rest Kerry> of the discussion. Yes, I agree that when I lookup "fridge.local", I'll get yours. *unless* the mapping to a GUA is still in my browser's cache...=20 (I deleted a realistic situation for my smartphone talking to my stove to find out when the roast is done) So what I'm after is a way for the fridge to say, when I lookup "fridge.local" that it's GUA is 2001::F001 (mDNS can already do this), but also that it's unicast DNS name is fridge.kerlyn.com. Kerry> If you are remotely accessing resources in your home, you are pr= obably Kerry> more advanced than 99% of all home network users. Why wouldn't = the Kerry> solution you use on the road apply equally well at your Kerry> neighbor's house? Kerry, the point of end-to-end connectivity into the home is to permit the things that us "1%" do, to be doable by everyone... Right? So, yes, dyndns is *a* solution, but I don't know how to automate it in a scalable way. I'm concerned that for the homenet protocols to be incrementally deployable ("create value") that we can not rely too much on the ISPs doing the right thing for forward DNS delegation. Kerry> I think defining new "zones" under .arpa. may have merit in the = following Kerry> respect: ICANN is now in the business of selling dotless Kerry> domain names. Just to be clear: my idea isn't that IETF run a dyndns under arpa, but that we have a WKN under arpa which is treated specially. I understand that my idea is hard to evaluate without a document. Should I write one then? =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBgZFoqHRg3pndX9AQLzAgQAxmpCQEGbpMfVNNiZWakrIetrn4qdLqBz 6yH3Qc/B3SNlhB290yuxr7vw6NWR/wGFwr/Oasw4qCyqVP+32U3sM2Oa6ZVyk9HA Fs5nqaa9jENKdQfS51FoLLOamNJ3e7u0YuVApky9HlwSwepN+ERBDb9/ZtBxzyFa ch5uGv6LUc4= =vR0T -----END PGP SIGNATURE----- --=-=-=-- From brian.e.carpenter@gmail.com Tue Jul 31 10:47:07 2012 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 C823C21F885F for ; Tue, 31 Jul 2012 10:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8Cs3r8Zu8g9 for ; Tue, 31 Jul 2012 10:47:07 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB2F21F8665 for ; Tue, 31 Jul 2012 10:47:06 -0700 (PDT) Received: by eaaa11 with SMTP id a11so1538439eaa.31 for ; Tue, 31 Jul 2012 10:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cndcch0Ccl37ZlBQfkuT7bj2LS9e56J5gcqJrLQlCHU=; b=xjwn6SfWFddxAYsUX2rV9w78ZA7sAkS+uFpQxUiJ4XZftSJpnzHHNlddZSBzCM6xm5 887eXoxX353Ubm6ZAp7TH0lqYfl7LVd87eANKf0jSqmTIj2ooQHzBTES+rtbDmIPTMJL /9/esA+gWqOX2hcB7ug2yItews87K1YK6UE+EewN1QvfvYD0ecRbDIKQir8HLG1ZPJHw BYcUIXVppBA0m6EzLInxSZANM0UMtn0WyWnTdgBL39w9im8MIgmxbY3Dja7zCIKnTN0j FQgoGdqFvtDabTch2AYoaKshnQpN1kJXPONecgzb7IdHfl+6Z8IorvnG0aeiFu8a2HUg WnGA== Received: by 10.14.179.135 with SMTP id h7mr18516645eem.35.1343756826277; Tue, 31 Jul 2012 10:47:06 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-131.as13285.net. [2.101.189.131]) by mx.google.com with ESMTPS id 8sm2086969eeg.16.2012.07.31.10.47.04 (version=SSLv3 cipher=OTHER); Tue, 31 Jul 2012 10:47:05 -0700 (PDT) Message-ID: <50181A1C.5050803@gmail.com> Date: Tue, 31 Jul 2012 18:47:08 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson References: <5655.1343689616@sandelman.ca> <50178DEE.1010202@gmail.com> <26048.1343753959@obiwan.sandelman.ca> In-Reply-To: <26048.1343753959@obiwan.sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] section 3.2.2.1 of homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 17:47:07 -0000 On 31/07/2012 17:59, Michael Richardson wrote: >>>>>> "Brian" == Brian E Carpenter writes: > >> I'm also surprised that we think we have to cope with flash renumbering > >> as a regular event, rather than a service-interrupting, ISP truck roll > >> catastrophy. > > Brian> But every time you reboot your antiquated v4-only CPE and/or the antiquated > Brian> v4-only PCs behind it, the PCs all get new IP addresses, which may or > Brian> may not be the same as the previous time. There's nothing new in flash > Brian> renumbering for homenets. Not handling this would be a step > Brian> backwards. > > Well... > > 1) sure, but the *customer* does this, not the ISP. > 2) the clients do have DHCP leases, and if they ask to renew their > previous IP, it usually gets honored. It doesn't matter whether it's the user or the ISP that triggers a change, does it? The point is, users don't care about this, except if they reach their shiny new wireless printer via its IP static address. There are definitely parts of draft-ietf-6renum-static-problem that apply here. Brian > > In IPv6 space, the host part will generally stay the same (modulo > privacy extensions, which are default on for some clients). We've said > that the ULA ought to stay the same, so in fact, I agree, the internal > addresses actually all stay the same. > > I'm still surprised that an ISP will need to flash renumber faster than > it can just expire leases. If it's just repartitioning of network to > deal with growth, that ought to be predictable and prefix lifetimes can > be reduced in advance. > > If it's actually some equipment failing, resulting in service > interruptions, and then restoration by rewiring the network... then I > understand. > From curtis@occnc.com Tue Jul 31 10:49:14 2012 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 1B51021F8875 for ; Tue, 31 Jul 2012 10:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l00zVfrzHy7Z for ; Tue, 31 Jul 2012 10:49:12 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE2821F8873 for ; Tue, 31 Jul 2012 10:49:11 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q6VHn2eI081028; Tue, 31 Jul 2012 13:49:02 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201207311749.q6VHn2eI081028@gateway.ipv6.occnc.com> To: Kerry Lynn From: Curtis Villamizar In-reply-to: Your message of "Tue, 31 Jul 2012 11:59:47 EDT." Date: Tue, 31 Jul 2012 13:49:02 -0400 Cc: Michael Richardson , homenet@ietf.org Subject: Re: [homenet] how to bookmark .lan, /.home, /.my-homenet when not home X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 17:49:14 -0000 In message Kerry Lynn writes: > On Mon, Jul 30, 2012 at 7:06 PM, Michael Richardson > wrote: > > > > while reading drafts on the airplane, I have come to think that picking > > any specific name a la ".local" for the homenet name service is fraught > > with RFC1918-like confusion. For the actual printer and refridgerator > > (which does not move, but needs to talk to the TV) it's not a big deal, > > but for mobile devices, I think it's gonna lead to confusion. > > > Michael, > > For those of us familiar with > http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns the > continued use of ".local." in these threads is leading to some > confusion, as we synonymize this with using Multicast DNS (mDNS) > instead of Unicast DNS. > > As was noted in a previous thread, "Special-Use Domain Names" has been > approved as a Proposed Standard: > http://www.ietf.org/mail-archive/web/ietf-announce/current/msg10435.html > The mDNS draft places ".local" in this category and specifies: > > that the DNS top-level domain ".local." is a > special domain with special semantics, namely that any fully- > qualified name ending in ".local." is link-local, and names within > this domain are meaningful only on the link where they originate. > > > When I'm at your house, and I visit "fridge.local", do I get your > > fridge, or mine? > > Mine, by definition. Given that I'm not sure how you mean ".homenet" > to work by comparison, I'm not sure I completely understand the rest > of the discussion. I am not a fan of mDNS but avoiding conflict with mDNS is a good thing and since this is decided one course of action is to define a sitelocal. The intent here is to allow routing within a site, not just bridging. With ULA the problem that link local addresses are not supposed to be routed is solved. ULA avoids the issue of site boundaries that made IPv6 site local addresses get depricated (a good thing IMHO). It then becomes necessary only to coordinate the sitelocal domain among router on the site and avoid leaking among sites. This is easily accomplished if the provider router offers a global routable prefix and refusing to become part of or recognize the DNS site. The issue is what happens when *my* fridge is not on the same home subnet as *my* home computer. (Sustituting a more realistic example, like thermostats, water heater, alarm system, etc, where temp/time profiles might be altered, but we'll stick with the fridge example). > > Assuming I want mine, if I've discovered it when I was > > at home, how would I bookmark and remember it, assuming it had a GUA? > > > > If you are remotely accessing resources in your home, you are probably > more advanced than 99% of all home network users. Why wouldn't the > solution you use on the road apply equally well at your neighbor's house? > (I'm thinking here of services like dyndns.) You simply put the domain > in which your fridge is registered earlier than ".local." in your DNS search > path, no? If all else fails, put it in /etc/hosts? A separate issue is how to address the fridge from a computer at work or a mobile phone where clearly neither are on the same site. Here a domain name has to be assigned and most likely something of the form . if there is not going to be a registration fee. The subdomain might be the same as the email address provided by most home providers or .site.. At worst the mobile phone would need to have .site. in the DNS search path so "fridge" can be resolved. The sitelocal name then only serves a purpose when the site is not connected to the provider and doesn't know its domain name. > > I therefore propose adding a level of indirection (because that solves > > every problem....), which (mobile) hosts will ideally become aware of. > > > > I think of this as a layer above the current LLMNR/mDNS/Bonjour++ layer. > > > > My idea is that the .homenet/.local discovery protocol would, in > > addition to the AAAA ULA or GUA record, would provide a reference a > > unique name which might not be globally resolvable from the DNS root, > > but can be resolved by arrangement. This would be not unlike > > split-horizon DNS, but given IPv6 reachability, no VPN necessary. > > > > For sites where mglt-name-delegation works, great, use that! > > For those where this doesn't work, we need a new well known name. > > Perhaps it can find a "logical" place in arpa. Let's say it's based > > upon the ULA, and the home with prefix A:B:C:D gets > > D.C.B.A.homenet.arpa. (add this to DNS search path...) > > > I think defining new "zones" under .arpa. may have merit in the following > respect: ICANN is now in the business of selling dotless domain names. > Despite the fact that there are many grandfathered special domain names > (including .local.) nobody that I know of has yet attempted to allocate a > new one. Defining new special use names under .arpa. may be a way of > allocating them within IETF's authority, without approval from ICANN. > > Note also that http://tools.ietf.org/html/rfc6303 defines a registry that is > apparently similar to special-names (at least there appears to be some > overlap): > http://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xml > > Regards, -K- A local router which provides DHCP can offer itself as a DNS resolver and effectively become primary for the /128 of any inaddr for any ULA within the site, returning the .sitelocal address or the . address depending on whether a domain for the site is unknown or known (either configured or learned). If the provider offers a routeable address and a domain, then the provider should also delegate both the forward domain and rDNS. Of course it would be real nice if the provider also offered a DNS secondary and updated the NS record if it was accepted. The site router would then have to allow zone transfers to that secondary. This is a fair amount of code that isn't written, but requires very little more than 1) some extensions to DHCP and 2) a BCP to say that this is a good idea and 3) the blessing to use sitelocal in this way if no domain is configured (since local is defined to be linklocal). draft-lemon-dhc-dns-pd-01.txt covers a lot of 1) above (some extensions to DHCP). It does not provide a means for the provider to offer to be DNS secondary and that might be a usefule addition. > > When an application resolves fridge.local, if the fridge has a GUA > > which it has provided to the CPE's DNS server, then it also returns a > > pointer to the "long-term name" (probably in a new RR) like > > "fridge.D.C.B.A.homenet.arpa". Any bookmarks and the like would contain > > that address (HTTP/HTML has existing mechanisms to deal with this), > > other applications might see this as the canonical name. (getaddrinfo(3) > > already has a canonname) > > > > My idea is that given IPv6 reachability for the HOME's CPE(s), that a > > mobile recursive (secure) DNS resolver can learn to make queries for > > D.C.B.A.homenet.arpa. directly to the home CPE, even when the mobile > > device is not "at home". > > > > The mobile device needs to be "pair"ed with the CPE such that it agrees > > to do this side-ways lookup. It's pretty much identical to a windows > > desktop joining an AD (but I can't speak to the "home edition" being > > able to do that... don't do windows). > > > > This process is, I admit, a form of walled garden DNS, something I've > > argued against as being unnecessary. I'd rather that the ISPs provided > > a name, but I feel that ISPs won't be very fast to offer this, and for > > the home user with no native IPv6 (using a managed tunnel, for > > instance), that a protocol such as I am suggesting, would provide a > > clear value (something people would brag about to their friends...) > > without requiring people to "wait" for their ISP. > > > > This does not replace "fridge.local" referring to the fridge on the > > network that you are on, but it does provide a way to easily discover > > and then bookmark "my fridge". > > > > (written offline using xemacs on android) From curtis@occnc.com Tue Jul 31 11:02:16 2012 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 05FB921F8899 for ; Tue, 31 Jul 2012 11:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-3UEuilfSgR for ; Tue, 31 Jul 2012 11:02:15 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 2B52021F88A5 for ; Tue, 31 Jul 2012 11:02:15 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q6VI2Bpg081298; Tue, 31 Jul 2012 14:02:11 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201207311802.q6VI2Bpg081298@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Mon, 30 Jul 2012 19:06:30 EDT." <5615.1343689590@sandelman.ca> Date: Tue, 31 Jul 2012 14:02:11 -0400 Cc: homenet@ietf.org Subject: Re: [homenet] how to bookmark .lan, /.home, /.my-homenet when not home X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 18:02:16 -0000 In message <5615.1343689590@sandelman.ca> Michael Richardson writes: > while reading drafts on the airplane, I have come to think that picking > any specific name a la ".local" for the homenet name service is fraught > with RFC1918-like confusion. For the actual printer and refridgerator > (which does not move, but needs to talk to the TV) it's not a big deal, > but for mobile devices, I think it's gonna lead to confusion. > > When I'm at your house, and I visit "fridge.local", do I get your > fridge, or mine? Assuming I want mine, if I've discovered it when I was > at home, how would I bookmark and remember it, assuming it had a GUA? > > I therefore propose adding a level of indirection (because that solves > every problem....), which (mobile) hosts will ideally become aware of. > > I think of this as a layer above the current LLMNR/mDNS/Bonjour++ layer. If you have your own domain, whether by default you get your fridge or the one at the site that you are at depends on whther your domain is ahead or or after sitelocal in your DNS search path. This affect only how a short name like fridge gets expanded into a FQDN. You can still access either fridge. Printer might be a good example. Use the one at home or have a copy printed where you are now. I've printed things from remotely a few times for my wife to pick up at home and sign. And I've also wanted a local copy at times. > My idea is that the .homenet/.local discovery protocol would, in > addition to the AAAA ULA or GUA record, would provide a reference a > unique name which might not be globally resolvable from the DNS root, > but can be resolved by arrangement. This would be not unlike > split-horizon DNS, but given IPv6 reachability, no VPN necessary. If I'm at your house I don't want to have to configure your router so I can talk to my printer. Also, not local can mean on a mobile device including a mobile phone or at a WiFi hotspot. I don't think the barista is going to allow you to configure their router to share with you local DNS. > For sites where mglt-name-delegation works, great, use that! > For those where this doesn't work, we need a new well known name. > Perhaps it can find a "logical" place in arpa. Let's say it's based > upon the ULA, and the home with prefix A:B:C:D gets > D.C.B.A.homenet.arpa. (add this to DNS search path...) > > When an application resolves fridge.local, if the fridge has a GUA > which it has provided to the CPE's DNS server, then it also returns a > pointer to the "long-term name" (probably in a new RR) like > "fridge.D.C.B.A.homenet.arpa". Any bookmarks and the like would contain > that address (HTTP/HTML has existing mechanisms to deal with this), > other applications might see this as the canonical name. (getaddrinfo(3) > already has a canonname) > > My idea is that given IPv6 reachability for the HOME's CPE(s), that a > mobile recursive (secure) DNS resolver can learn to make queries for > D.C.B.A.homenet.arpa. directly to the home CPE, even when the mobile > device is not "at home". > > The mobile device needs to be "pair"ed with the CPE such that it agrees > to do this side-ways lookup. It's pretty much identical to a windows > desktop joining an AD (but I can't speak to the "home edition" being > able to do that... don't do windows). > > This process is, I admit, a form of walled garden DNS, something I've > argued against as being unnecessary. I'd rather that the ISPs provided > a name, but I feel that ISPs won't be very fast to offer this, and for > the home user with no native IPv6 (using a managed tunnel, for > instance), that a protocol such as I am suggesting, would provide a > clear value (something people would brag about to their friends...) > without requiring people to "wait" for their ISP. > > This does not replace "fridge.local" referring to the fridge on the > network that you are on, but it does provide a way to easily discover > and then bookmark "my fridge". > > (written offline using xemacs on android) > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mcr+ietf@sandelman.ca Tue Jul 31 11:19:09 2012 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 CB3F121F88FE for ; Tue, 31 Jul 2012 11:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBlXSXlRLs+B for ; Tue, 31 Jul 2012 11:19:09 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id 344E321F88FB for ; Tue, 31 Jul 2012 11:19:09 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id D76EB2016A for ; Tue, 31 Jul 2012 14:31:28 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <201207311749.q6VHn2eI081028@gateway.ipv6.occnc.com> References: <201207311749.q6VHn2eI081028@gateway.ipv6.occnc.com> X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) 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 Subject: Re: [homenet] how to bookmark .lan, /.home, /.my-homenet when not home X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 18:19:09 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Curtis" =3D=3D Curtis Villamizar writes: Curtis> The issue is what happens when *my* fridge is not on the same h= ome Curtis> subnet as *my* home computer. (Sustituting a more realistic ex= ample, Curtis> like thermostats, water heater, alarm system, etc, where temp/t= ime Curtis> profiles might be altered, but we'll stick with the fridge Curtis> example). this is an issue, and we have some proposals to solve this. It's not the issue that I'm talking about. I'm saying that I want to leverage the sitelocal host discovery protocol to also discover a global name for the host. I'm suggeting that an application (e.g. browser, cups, etc.) on a mobile device should never (by default) actually bookmark "fridge.local", because it's not globally meaningful. Curtis> A separate issue is how to address the fridge from a computer a= t work Curtis> or a mobile phone where clearly neither are on the same site. = Here a Curtis> domain name has to be assigned and most likely something of the= form Curtis> . if there is not going to be a regis= tration Curtis> fee. The subdomain might be the same as the email address prov= ided by Curtis> most home providers or .site.. At worst = the Curtis> mobile phone would need to have .site. in= the Curtis> DNS search path so "fridge" can be resolved. Curtis> The sitelocal name then only serves a purpose when the site is = not Curtis> connected to the provider and doesn't know its domain name. It's not a hard problem, technically (layer 1-7) It's a hard layer 8/9 problem, and I'm suggesting that maybe we need to think about whether there are layer-5/6/7 things that we can do as we are specifying the sitelocal discovery process to ease the layer 8/9 problem. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBghmYqHRg3pndX9AQJvagP/RYlAkWS3UdVIDTHxnMs6w9MJ+xOrqD9r K6fAAiYrdkPp65b8Vms8zdjzz+JDxIKZsTCD0ku6jYJmQiSQ6oayNYFtFnhBnNCU 4b6hJKYcW7bK2+yeAZe053MJdJzoWZoilfIZ2thS4aZrD1VW6GFIHmox+sycPV2E 0P4uYnA7p6c= =WZC0 -----END PGP SIGNATURE----- --=-=-=-- From mcr+ietf@sandelman.ca Tue Jul 31 11:23:15 2012 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 7C0F221F891F for ; Tue, 31 Jul 2012 11:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zx-BEFPG15m for ; Tue, 31 Jul 2012 11:23:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id 57D5121F8909 for ; Tue, 31 Jul 2012 11:23:14 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id AB0762016A for ; Tue, 31 Jul 2012 14:35:25 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <50181A1C.5050803@gmail.com> References: <5655.1343689616@sandelman.ca> <50178DEE.1010202@gmail.com> <26048.1343753959@obiwan.sandelman.ca> <50181A1C.5050803@gmail.com> X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) 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 Subject: Re: [homenet] section 3.2.2.1 of homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 18:23:15 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Brian" =3D=3D Brian E Carpenter writes: Brian> But every time you reboot your antiquated v4-only CPE and/or the= antiquated Brian> v4-only PCs behind it, the PCs all get new IP addresses, which m= ay or Brian> may not be the same as the previous time. There's nothing new in= flash Brian> renumbering for homenets. Not handling this would be a step Brian> backwards. >> Well...=20 >>=20 >> 1) sure, but the *customer* does this, not the ISP. >> 2) the clients do have DHCP leases, and if they ask to renew their >> previous IP, it usually gets honored. Brian> It doesn't matter whether it's the user or the ISP that triggers Brian> a change, does it? It does. When the customer power cycles their device, everything starts again. They know they did this. If the ISP renegs on the lifetimes of the leases, and wants to flash renumber the customer, either: a) there is protocol for forcing the renumbering (does 6renum provide this?) b) the customer is offline until *they* reboot their device. Brian> The point is, users don't care about this, except if they reach = their Brian> shiny new wireless printer via its IP static address. There are = definitely Brian> parts of draft-ietf-6renum-static-problem that apply here. okay, I'll read it. But, the printer is addressed as "printer.local", and is reached with the ULA, and we agreed that having this work regardless of whether or not the ISP was alive was in-scope. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBgihoqHRg3pndX9AQLJ2QP/aaOkIXPcrzlEHYU2ugTv3SyK90FjRjbb tuHQt89JaV64XQWHBGeLgMhFKOgmFZGgpiFoXdBjKnYq+JUuGM8XMnqTIJ4EIdx9 g1Yl8eQ8Ktf2NvBD7o9gOFSQAFPyx+pV+F1VZ3lVWh9HFCBV1EcsFxDjaK4HR6Am sF3gSEIR6CM= =MjGk -----END PGP SIGNATURE----- --=-=-=-- From curtis@occnc.com Tue Jul 31 11:32:51 2012 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 C2ACE21F8888 for ; Tue, 31 Jul 2012 11:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNg0-JbWTOVS for ; Tue, 31 Jul 2012 11:32:51 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 43D4521F8847 for ; Tue, 31 Jul 2012 11:32:50 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q6VIWdqG081645; Tue, 31 Jul 2012 14:32:40 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> To: james woodyatt From: Curtis Villamizar In-reply-to: Your message of "Mon, 30 Jul 2012 16:07:49 PDT." Date: Tue, 31 Jul 2012 14:32:39 -0400 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 18:32:51 -0000 In message james woodyatt writes: > On Jul 30, 2012, at 13:28 , Ted Lemon wrote: > > > > The work's already started in the dhc working group: > > > > > > > > I'd be curious to hear your feedback on this draft. > > That's a good submission for the DHC group. > > I'm thinking I'd much more like to see a specific recommendation that HOMENET gateways implement a site-managed reverse tree, optionally augmented with a zero-configuration method for generating content explicitly managed by a knowledgeable home network administrator. > > For example, after I install a fresh HOMENET gateway in my new house, I expect the following things just to happen correctly without any forethought: > > 1. The integrated DNS content server should have authority for all of the ip6.arpa corresponding to the IPv6 prefixes delegated by its service provider; > > 2. The integrated DNS resolving server should answer [on the local network only] for the locally generated ULA prefixes required by RFC 6106. > > 3. Queries for PTR records in zones for which it's authoritative should always produce a synthesized answer if no explicitly configured records are stored in the content server. > > For examples, > > 3a. dig -x fd35:5a4b:92a9:fb::1 -> > fd35-5a4b-92a9-fb--1.local. > > 3b. dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc -> > 2001-5a8-4-2290-a95f-dd2e-3201-eafc.subscriber-3021134.example.net. > > 4. I should be able to override explicitly the domain automatically delegated by my service provider with my own registered FQDN if I want to do so, so that example 3b above becomes: > > 3b.(2). dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc -> > 2001-5a8-4-2290-a95f-dd2e-3201-eafc.conjury.org. > > 5. I should be able to override explicitly the automatically generated FQDN for any hosts on my network if I want to do so, so that examples 3a and 3b above become: > > 3b.(3). dig -x fd35:5a4b:92a9:fb::1 -> > zardoz.local. > > 3b.(4). dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc -> > zardoz.subscriber-3021134.example.net. > > 6. I should be able to do both. > > 3b.(5). dig -x fd35:5a4b:92a9:fb::1 -> > zardoz.home.conjury.org. > > 3b.(6). dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc -> > zardoz.conjury.org. > > Yes, I get that DNSOP people don't like to contemplate this problem. I don't want to debate about why I think they're wrong to defer it, but my thoughts aren't all that different from those of anyone else in the application/security community. Can we skip past the part when I enumerate them again? > > I guess I had hoped the HOMENET group would more easily find consensus around addressing this promptly, but that may have been wishful thinking. > > > -- > james woodyatt > member of technical staff, core os networking I agree with 99.8% of this. s/\.local/.sitelocal/ and allow a home network to be routed and then I agree with 100% of this. I think you could add to the above that the provider should offer to delegate a forward zone and a reverse zone via DHCP extension and offer to provide DNS secondary for those zones. Note that draft-lemon-dhc-dns-pd doesn't go that far (offering a forward zone name to use), but it would be a useful addition. It would be nice if the customer router could request that the provider secondary also pick up a zone allocated to the site by a registrar. The provider router can verify this by looking up the NS records for that zone and determining that the A or AAAA for at least one of the existing nameservers falls with the static address allocation of the site. This would be for advanced users and the advanced user (or a sufficiently advanced DHCP/nameserver coupling) could then update the list of NS records adding the provider secondary. Again draft-lemon-dhc-dns-pd doesn't go that far. The provider side would have to be able to offer to secondary for both a zone offerred by the provider and offer to accept a zone name in a DHCP response (with verification against NS records). No zone name in the response could imply acceptance of the provider offerred zone or it could be explicitly accepted. Given the support for these extensions in a provider side DNS nameserver and support for these extensions in at least a subset of home routers, this can all be automated such that there is no real work for DNS ops. The worst that can happen is the provider becomes a DNS secondary for bad-name.example.com but can easily identify the perpetrator and in a manner of their choosing the provider can bludgeon said perpetrator with their AUP. As long as funny-characters+code.example.com or really-long-name+code.example.com doesn't cause some resolvers to crash or run code, then there is no harm in bad-name.example.com. Curtis From mellon@fugue.com Tue Jul 31 11:48:33 2012 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 8CF5111E80EE for ; Tue, 31 Jul 2012 11:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwKIvJh-waGI for ; Tue, 31 Jul 2012 11:48:33 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 36EEF11E80ED for ; Tue, 31 Jul 2012 11:48:33 -0700 (PDT) Received: from dhcp-534c.meeting.ietf.org (dhcp-534c.meeting.ietf.org [130.129.83.76]) by toccata.fugue.com (Postfix) with ESMTPSA id E639C2380C5D; Tue, 31 Jul 2012 14:48:31 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Ted Lemon In-Reply-To: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> Date: Tue, 31 Jul 2012 11:48:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1283) Cc: "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 18:48:33 -0000 The problem of secondarying the reverse zone isn't really discussed in = the dns-pd draft, and there are a number of operational details I'd like = to flesh out, but the specific question of secondarying the reverse zone = isn't quite what it seems.=20 You secondary a zone so that the contents of the zone will be there when = a query happens, but why would a query happen if the CPE device isn't = reachable? What would trigger that query? So I think you can get away = with _not_ secondarying the zone. But if you do want to secondary it, = why would the ISP be responsible for that? Presumably the customer is = pretty savvy; a secondary for their reverse tree would just be another = service they'd want to buy or set up, and the ISP could wash their hands = of it or sell it, whichever they chose. From jhw@apple.com Tue Jul 31 11:52:11 2012 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 A2DA621F8779 for ; Tue, 31 Jul 2012 11:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRX1q59nGPPa for ; Tue, 31 Jul 2012 11:52:11 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id DD55611E80A2 for ; Tue, 31 Jul 2012 11:52:10 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M8100A5OFHY9GO7@mail-out.apple.com> for homenet@ietf.org; Tue, 31 Jul 2012 11:52:09 -0700 (PDT) X-AuditID: 11807136-b7fed6d000005bf5-aa-501829599df2 Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id B4.31.23541.95928105; Tue, 31 Jul 2012 11:52:09 -0700 (PDT) From: james woodyatt In-reply-to: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> Date: Tue, 31 Jul 2012 11:52:09 -0700 Message-id: References: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42IRPMjroBupKRFgsPugoMX7RYdYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8eV6J3PBUc6KvRsOsDUwXmDvYuTkkBAwkXiw5QcLhC0mceHe erYuRi4OIYHZTBJPVlwASzALaEnc+PeSCcTmFdCTmN0+BywuLKAksXTVYlYQm01AReLb5btg NZwCjhLbZl5jBLFZBFQlfnyYzgQxR1ti2cLXzBBzbCTmXPoJFhcScJC42PINLC4ioC/x9Mgv NoiDZCW+Hz7PNoGRbxaSM2YhOWMWkrELGJlXMQoWpeYkVhqa6iUWFOSk6iXn525iBIVSQ6HZ DsYdf+UOMQpwMCrx8DaoSQQIsSaWFVfmHmKU4GBWEuFlXSEeIMSbklhZlVqUH19UmpNafIhR moNFSZz3z3KhACGB9MSS1OzU1ILUIpgsEwenVAOjRPYjJ657KSbPhCNnNqgLnHb505f0cXb3 OaUjckd0y7kaWr0XnI6KT3F/nHngT46Wv3qx/SXd1Q/uPHj2pV5UYF/kfkYj4fTcGa1aE/+/ MFPmcGD+KzJBLPO53zqnHXZTGS7l+arcb75zfuOpzQ9emCzqMTsreaHjxG7BpYGqC7I0pRI2 sqxSYinOSDTUYi4qTgQA8xemaSECAAA= Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 18:52:12 -0000 On Jul 31, 2012, at 11:32 , Curtis Villamizar wrote: > > s/\.local/.sitelocal/ and allow a home network to be routed and then I agree with 100% of this. I consider it a minor oversight that I wrote "local." without remembering that recent developments in the effort to standardize mDNS have strengthened the requirement for the "local." TLD to have an officially special usage. I was mired by my habit of thinking about the practical consequences of many actual networks in the wild not respecting this proposed special usage. I suppose HOMENET shouldn't contribute to the ongoing festival of error, so I'm okay with "sitelocal." as the TLD even when home networks are single links. Also, the reason I proposed constraining the scope of a working group task to handling just reverse DNS is that solving that problem properly will necessarily involve solving a critical subset of the problems that need to be solved to handle forward DNS as well. Do the reverse DNS case first, then extending that work to cover the forward DNS case will be much easier. -- james woodyatt member of technical staff, core os networking From mellon@fugue.com Tue Jul 31 11:54:09 2012 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 3349C11E8105 for ; Tue, 31 Jul 2012 11:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0twEtVLkrc-V for ; Tue, 31 Jul 2012 11:54:08 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id BCEB711E80FA for ; Tue, 31 Jul 2012 11:54:08 -0700 (PDT) Received: from dhcp-534c.meeting.ietf.org (dhcp-534c.meeting.ietf.org [130.129.83.76]) by toccata.fugue.com (Postfix) with ESMTPSA id DE5532380C5D; Tue, 31 Jul 2012 14:54:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_55A3C6ED-237F-4F75-8EE9-29D7A3D3096D" From: Ted Lemon In-Reply-To: Date: Tue, 31 Jul 2012 11:54:06 -0700 Message-Id: <23916A9B-4B1B-4F22-976D-A08217B5C720@fugue.com> References: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> To: james woodyatt X-Mailer: Apple Mail (2.1283) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 18:54:09 -0000 --Apple-Mail=_55A3C6ED-237F-4F75-8EE9-29D7A3D3096D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 31, 2012, at 11:52 AM, james woodyatt wrote: > Also, the reason I proposed constraining the scope of a working group = task to handling just reverse DNS is that solving that problem properly = will necessarily involve solving a critical subset of the problems that = need to be solved to handle forward DNS as well. Do the reverse DNS = case first, then extending that work to cover the forward DNS case will = be much easier. +1 I'm a bit worried about the security implications of some of the ideas = I'm seeing thrown around here, and would like to see us start with the = basics and build from there, rather than trying to come up with a = slapdash solution that does everything, and turns into a big problem in = a few years time when it's deployed on millions of routers. --Apple-Mail=_55A3C6ED-237F-4F75-8EE9-29D7A3D3096D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Also, the = reason I proposed constraining the scope of a working group task to = handling just reverse DNS is that solving that problem properly will = necessarily involve solving a critical subset of the problems that need = to be solved to handle forward DNS as well.  Do the reverse DNS = case first, then extending that work to cover the forward DNS case will = be much = easier.

+1

= I'm a bit worried about the security implications of some of the ideas = I'm seeing thrown around here, and would like to see us start with the = basics and build from there, rather than trying to come up with a = slapdash solution that does everything, and turns into a big problem in = a few years time when it's deployed on millions of = routers.

= --Apple-Mail=_55A3C6ED-237F-4F75-8EE9-29D7A3D3096D-- From curtis@occnc.com Tue Jul 31 11:54:42 2012 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 45C5121F8904 for ; Tue, 31 Jul 2012 11:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw0yyeyDklXY for ; Tue, 31 Jul 2012 11:54:41 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id AB2D921F88F6 for ; Tue, 31 Jul 2012 11:54:41 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q6VIsZbY081951; Tue, 31 Jul 2012 14:54:35 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201207311854.q6VIsZbY081951@gateway.ipv6.occnc.com> To: Michael Thomas From: Curtis Villamizar In-reply-to: Your message of "Mon, 30 Jul 2012 16:59:25 PDT." <50171FDD.10003@mtcc.com> Date: Tue, 31 Jul 2012 14:54:35 -0400 Cc: Michael Richardson , "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 18:54:42 -0000 In message <50171FDD.10003@mtcc.com> Michael Thomas writes: > On 07/30/2012 04:54 PM, james woodyatt wrote: > > In the unicast DNS case, the content server probably does not know-- > > and arguably should not know-- the name of every host in the zone, so > > that's why it's wise to expect it will be synthesizing host names. > > Whether the default zone for ULA reverse mapping names over unicast > > DNS is "local." or "homenet." or something else is only tangentially > > relevant here. It's the same problem no matter what TLD we allocate > > for this purpose. > > > > Maybe I missed it, but why is lack of reverse map a problem, minus the > security desire to show some weak control of the allocated prefix? > > Mike Mike, rDNS answers questions like who is that trying to connect to port X. If its just misconfiguration or a benign but unexpected behaviour, then knowing the host name helps. For a local mailserver having an accurate reverse DNS entry is a real good idea. If not some other mail servers will reject your mail, most often large consumer oriented ISP mail servers. Some of the same ISPs that won't do rDNS delegation reject mail from hosts with no rDNS entries or wrong entries. Curtis From kerlyn2001@gmail.com Tue Jul 31 12:38:46 2012 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 3155911E80FF for ; Tue, 31 Jul 2012 12:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.239 X-Spam-Level: X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfOj16yMsRk6 for ; Tue, 31 Jul 2012 12:38:45 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4844821F8463 for ; Tue, 31 Jul 2012 12:38:45 -0700 (PDT) Received: by wibhm11 with SMTP id hm11so2543524wib.13 for ; Tue, 31 Jul 2012 12:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wCpvAtpXuEDzTHrRx2yIRh0QalIHo71pDjXqmuOKMAE=; b=lFCwMBiQwh5eRKtiNHKBg7uurjetue9SzM9gnTB3qe4fkbw4JCio8mjZ0jl5c63YAt cW/VD/FdluU53OE5pEVUTd9Oq8lrPwvqJWtMTc/EY8WtA1FnM6utScACLbBJ61U1XwEW Y6HgB9MYgbXTKvc5F+500+J5QwsMW2FyWNW+GPByTJKc0tI+qBWFh2VWjFvpVS3pupIy jipiq0hjFYjeEaG3OvMVvb1xw7JgMxVWnecYc5sKkkcdPyuTjzMlzANKbHxau+SutMtx /N0p73utcdi31wg8DcE0dZuQt8kMGo4XCusM2vfEJBPdGFQ6ax6aHRLEc6FeXbLNeIpq 4dwA== MIME-Version: 1.0 Received: by 10.180.95.193 with SMTP id dm1mr5074827wib.10.1343763507460; Tue, 31 Jul 2012 12:38:27 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.194.32.196 with HTTP; Tue, 31 Jul 2012 12:38:27 -0700 (PDT) In-Reply-To: <1314.1343756566@obiwan.sandelman.ca> References: <5615.1343689590@sandelman.ca> <1314.1343756566@obiwan.sandelman.ca> Date: Tue, 31 Jul 2012 15:38:27 -0400 X-Google-Sender-Auth: ugGniefByqdawD6N8WI8ZiTbFyA Message-ID: From: Kerry Lynn To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Cc: homenet@ietf.org Subject: Re: [homenet] how to bookmark .lan, /.home, /.my-homenet when not home X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 19:38:46 -0000 On Tue, Jul 31, 2012 at 1:42 PM, Michael Richardson wrote: > >>>>>> "Kerry" == Kerry Lynn writes: > >> When I'm at your house, and I visit "fridge.local", do I get your > >> fridge, or mine? > > Kerry> Mine, by definition. Given that I'm not sure how you mean ".homenet" > Kerry> to work by comparison, I'm not sure I completely understand the rest > Kerry> of the discussion. > > Yes, I agree that when I lookup "fridge.local", I'll get yours. > *unless* the mapping to a GUA is still in my browser's cache... > I haven't tried the scenario you mention, and since I'm not home it will be a while until I can... > (I deleted a realistic situation for my smartphone talking to my stove > to find out when the roast is done) > > So what I'm after is a way for the fridge to say, when I lookup > "fridge.local" that it's GUA is 2001::F001 (mDNS can already do this), > but also that it's unicast DNS name is fridge.kerlyn.com. > Now I am starting to get what you mean. If you have a unicast DNS service deployed in your home you can populate it with specially named PTR records to indicate preferred registration zones (see section 11 of http://tools.ietf.org/html/draft-cheshire-dnsext-dns-sd). I guess in theory these names could also be discovered via mDNS. > Kerry> If you are remotely accessing resources in your home, you are probably > Kerry> more advanced than 99% of all home network users. Why wouldn't the > Kerry> solution you use on the road apply equally well at your > Kerry> neighbor's house? > > Kerry, the point of end-to-end connectivity into the home is to permit > the things that us "1%" do, to be doable by everyone... Right? > Sure, but we shouldn't break things that already work, nor require additional configuration hassles for ALL users. It should be made relatively painless to introduce new functionality. What I'm trying to figure out is whether most people in these conversations are envisioning a unicast DNS service in the home that has a "locally defined" zone, as opposed to mDNS which *distributes* the name service. One way in which the latter may be deployed may be to have some "agent" that listens to mDNS announcements and then enters RRs into a unicast DNS. This still doesn't buy us FQDNs, however, unless the DNS has a delegated zone. > So, yes, dyndns is *a* solution, but I don't know how to automate it in > a scalable way. I'm concerned that for the homenet protocols to be > incrementally deployable ("create value") that we can not rely too much > on the ISPs doing the right thing for forward DNS delegation. > So you want to remotely access hosts in your residence, but without configuration of any sort? > Kerry> I think defining new "zones" under .arpa. may have merit in the following > Kerry> respect: ICANN is now in the business of selling dotless > Kerry> domain names. > > Just to be clear: my idea isn't that IETF run a dyndns under arpa, but > that we have a WKN under arpa which is treated specially. > Right. And even though, in theory, we are able to request new TLDs from ICANN that warrant special semantics, this hasn't yet been attempted to my knowledge. > I understand that my idea is hard to evaluate without a document. > Should I write one then? > I'd support seeing more about naming/service discovery in homenet drafts as opposed to the mailing list. -K- > -- > Michael Richardson , Sandelman Software Works > > From marka@isc.org Tue Jul 31 13:07:10 2012 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 8E53921F88D9 for ; Tue, 31 Jul 2012 13:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lDnKJ3ijebV for ; Tue, 31 Jul 2012 13:07:10 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id F1A9121F88D4 for ; Tue, 31 Jul 2012 13:07:09 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 07783C9476; Tue, 31 Jul 2012 20:06:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:96:61a1:6853:806e:5e69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id DED02216C33; Tue, 31 Jul 2012 20:06:56 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id E49F123269C4; Wed, 1 Aug 2012 06:06:55 +1000 (EST) To: Ted Lemon From: Mark Andrews References: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> In-reply-to: Your message of "Tue, 31 Jul 2012 11:48:30 MST." Date: Wed, 01 Aug 2012 06:06:55 +1000 Message-Id: <20120731200655.E49F123269C4@drugs.dv.isc.org> Cc: "homenet@ietf.org Group" , james woodyatt , curtis@occnc.com Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:07:10 -0000 In message , Ted Lemon writes: > The problem of secondarying the reverse zone isn't really discussed in the dn > s-pd draft, and there are a number of operational details I'd like to flesh o > ut, but the specific question of secondarying the reverse zone isn't quite wh > at it seems. > > You secondary a zone so that the contents of the zone will be there when a qu > ery happens, but why would a query happen if the CPE device isn't reachable? Log processing. > What would trigger that query? So I think you can get away with _not_ seco > ndarying the zone. It's trivial to secondary a zone. It's even easier when you can have the forward and reverse zones be the same. .ip6.arpa. DNAME . or .ip6.arpa. DNAME .. No on the fly setup of zones when a new prefix is allocated. Just install a DNAME record. The second form is for when machines don't have the same suffix in all prefixes. The CPE device can make the decision about which form to use. > But if you do want to secondary it, why would the ISP be > responsible for that? So they don't get extra request due to the delegated servers being unreachable. Giving good answers is cheaper than have to cope with the effects of the customer's servers being unreachable. > Presumably the customer is pretty savvy; a secondary > for their reverse tree would just be another service they'd want to buy or s > et up, and the ISP could wash their hands of it or sell it, whichever they ch > ose. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mcr@sandelman.ca Tue Jul 31 13:12:41 2012 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 6E76721F88A9 for ; Tue, 31 Jul 2012 13:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=0.932, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbUfBoBANHd2 for ; Tue, 31 Jul 2012 13:12:40 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBBE21F87FE for ; Tue, 31 Jul 2012 13:12:40 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id 7DC622016A; Tue, 31 Jul 2012 16:24:59 -0400 (EDT) From: Michael Richardson To: james woodyatt In-Reply-To: References: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) 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 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:12:41 -0000 >>>>> "james" == james woodyatt writes: james> Also, the reason I proposed constraining the scope of a james> working group task to handling just reverse DNS is that james> solving that problem properly will necessarily involve james> solving a critical subset of the problems that need to be james> solved to handle forward DNS as well. Do the reverse DNS james> case first, then extending that work to cover the forward DNS james> case will be much easier. This is a good approach. +1. From mcr+ietf@sandelman.ca Tue Jul 31 13:29:06 2012 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 A7B3221F88E4 for ; Tue, 31 Jul 2012 13:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6x25DAWB84C for ; Tue, 31 Jul 2012 13:29:06 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id E876921F88E6 for ; Tue, 31 Jul 2012 13:29:05 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id 12F422016A for ; Tue, 31 Jul 2012 16:41:26 -0400 (EDT) From: Michael Richardson To: "homenet@ietf.org Group" In-Reply-To: References: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) 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 Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:29:06 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Ted" =3D=3D Ted Lemon writes: Ted> You secondary a zone so that the contents of the zone will be Ted> there when a query happens, but why would a query happen if the Ted> CPE device isn't reachable? What would trigger that query? Ted> So I think you can get away with _not_ secondarying the zone. Ted> But if you do want to secondary it, why would the ISP be Ted> responsible for that? Presumably the customer is pretty Ted> savvy; a secondary for their reverse tree would just be another Ted> service they'd want to buy or set up, and the ISP could wash Ted> their hands of it or sell it, whichever they chose.=20 My suggestion is that the ISP secondary the zone from the CPE, but actually advertise only their server in the NS delegation. (The CPE remains a stealth primary) The CPE will have multiple addresses, usually at least two, as it has at least two interfaces. The CPE address which the ISP most knows about and is most easily reachable is the outside address (the ISP facing one). That address, if auto-configured, could trivially change if the CPE is replaced (or replugged into a different port), or if the CPE used privacy extensions. So we'll need a low TTL on that NS/AAAA record. If we use the internal address from the CPE, which is likely in the prefix that was delegated, and therefore very unlikely to change (and I think some people have even proposed to make the host part well-known!), it is possibly more stable, but it instantly introduces an exception to the CPE firewall rules. Out of these two choices, neither is particularly bad, but as you indicated, when the customer is down, the data is inaccessible. If the ISP has a copy (and might keep some history of it), then the ISP is in a position to indicate to the customer what host is what. Consider an ISP that has detected a home system infected with some malware. Said ISP has either quaranteed or has disconnected that customer. Customer will not understand "host 2001:DB8:0001:1234:0234:45fe:ff01:4567 is infected" but, might understand: "host suzie-derkins is infected" this could also be done if the ISP actually recorded the mapping from ..:4567->susie-derkins at the time the event occured, and maybe that's really the answer here. I'm thinking that ISPs might want to have more control over what's in the reverse. (I don't really like that myself, but...) Perhaps there are privacy concerns if the ISP has this mapping recorded, and it would be better if the CPE was the only place with the info. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBhADoqHRg3pndX9AQLY8AP/feDVKvk3UIKPk76V6grvnuCmqadQgveH X/h4Bd5wvI2T8NB7XM6AiP+g3LNEvsdAbApdrznaA78ApkbMd+tucP37SrgC1y7r 0ApE7RuEDSrKUigXX4LM83/P4YMk6535WoCeX+vlRJ1jgGw1kISuduh7lnwp+XSw dYQvCs1EyN4= =jHn5 -----END PGP SIGNATURE----- --=-=-=-- From marka@isc.org Tue Jul 31 13:31:55 2012 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 5B3F021F895F for ; Tue, 31 Jul 2012 13:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5b-N9GI7RPZg for ; Tue, 31 Jul 2012 13:31:53 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id B8AFF21F8950 for ; Tue, 31 Jul 2012 13:31:52 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 11C0AC9496; Tue, 31 Jul 2012 20:31:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:96:61a1:6853:806e:5e69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id F1AAF216C3B; Tue, 31 Jul 2012 20:31:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 36F2B2326F11; Wed, 1 Aug 2012 06:31:31 +1000 (EST) To: Michael Richardson From: Mark Andrews References: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> <27005.1343765554@obiwan.sandelman.ca> In-reply-to: Your message of "Tue, 31 Jul 2012 16:12:34 -0400." <27005.1343765554@obiwan.sandelman.ca> Date: Wed, 01 Aug 2012 06:31:31 +1000 Message-Id: <20120731203131.36F2B2326F11@drugs.dv.isc.org> Cc: "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:31:55 -0000 In message <27005.1343765554@obiwan.sandelman.ca>, Michael Richardson writes: > > >>>>> "james" == james woodyatt writes: > james> Also, the reason I proposed constraining the scope of a > james> working group task to handling just reverse DNS is that > james> solving that problem properly will necessarily involve > james> solving a critical subset of the problems that need to be > james> solved to handle forward DNS as well. Do the reverse DNS > james> case first, then extending that work to cover the forward DNS > james> case will be much easier. > > This is a good approach. +1. DH key exchange over DHCPv6 for the border CPE to get a TSIG key to install NS / DNAME records for the assigned prefixes using secure dynamic DNS update. All this requires is an appropriate DHCPv6 option to be allocated. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From lee.howard@twcable.com Tue Jul 31 13:36:06 2012 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 9333811E80E8 for ; Tue, 31 Jul 2012 13:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.888 X-Spam-Level: X-Spam-Status: No, score=-0.888 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRkhX-H4f+ZZ for ; Tue, 31 Jul 2012 13:36:06 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 10B8211E80A2 for ; Tue, 31 Jul 2012 13:36:05 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,689,1336363200"; d="scan'208";a="417613586" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 31 Jul 2012 16:35:54 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Tue, 31 Jul 2012 16:36:04 -0400 From: "Howard, Lee" To: Michael Richardson , "homenet@ietf.org Group" Date: Tue, 31 Jul 2012 16:36:04 -0400 Thread-Topic: [homenet] Reverse DNS Thread-Index: Ac1vXBrUPhBLZfgISEC+r3d3PTt7Gg== Message-ID: In-Reply-To: <29762.1343766542@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:36:06 -0000 On 7/31/12 1:29 PM, "Michael Richardson" wrote: > >>>>>> "Ted" =3D=3D Ted Lemon writes: > Ted> You secondary a zone so that the contents of the zone will be > Ted> there when a query happens, but why would a query happen if the > Ted> CPE device isn't reachable? What would trigger that query? > Ted> So I think you can get away with _not_ secondarying the zone. > Ted> But if you do want to secondary it, why would the ISP be > Ted> responsible for that? Presumably the customer is pretty > Ted> savvy; a secondary for their reverse tree would just be another > Ted> service they'd want to buy or set up, and the ISP could wash > Ted> their hands of it or sell it, whichever they chose. > >My suggestion is that the ISP secondary the zone from the CPE, but >actually advertise only their server in the NS delegation. (The CPE >remains a stealth primary) I need to see an internet-draft problem statement. I still don't believe there is one, and I have no plans to provide IPv6 reverse DNS for residential subscribers. Any ISPs planning to do this? Lee This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From mellon@fugue.com Tue Jul 31 13:37:10 2012 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 9DA8011E8120 for ; Tue, 31 Jul 2012 13:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h038VLSVhmoR for ; Tue, 31 Jul 2012 13:37:10 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4672311E80A2 for ; Tue, 31 Jul 2012 13:37:10 -0700 (PDT) Received: from dhcp-462a.meeting.ietf.org (dhcp-462a.meeting.ietf.org [130.129.70.42]) by toccata.fugue.com (Postfix) with ESMTPSA id 0A5C42380756; Tue, 31 Jul 2012 16:37:08 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Ted Lemon In-Reply-To: <20120731200655.E49F123269C4@drugs.dv.isc.org> Date: Tue, 31 Jul 2012 13:37:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8E433067-77B2-4449-B409-B692306024FA@fugue.com> References: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> <20120731200655.E49F123269C4@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1283) Cc: "homenet@ietf.org Group" , james woodyatt , curtis@occnc.com Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:37:10 -0000 On Jul 31, 2012, at 1:06 PM, Mark Andrews wrote: > Log processing. Maybe, but I think only the customer is really going to care about this, = so if they want it to work, they'd be responsible for setting it up. > It's trivial to secondary a zone. It's even easier when you can have > the forward and reverse zones be the same. No, it's *technically* trivial to secondary a zone. There's a lot of = extra business stuff that goes on top of that, plus the problem of = dealing with customer brokenness, so it makes sense to charge money to = secondary your customers' reverse tree, if you decide to do it at all. = Of course it's hard to know how this will play out in practice, but I = think it's naive to think that there won't be issues. > So they don't get extra request due to the delegated servers being > unreachable. Giving good answers is cheaper than have to cope with > the effects of the customer's servers being unreachable. Extra SOA or NS requests? Or just customer traffic to a CPE that's not = connected? Either way, I think the additional load, if it exists at = all, is trivial. From mcr+ietf@sandelman.ca Tue Jul 31 13:40:23 2012 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 3D4AD21F84C2 for ; Tue, 31 Jul 2012 13:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFTfWb4danbt for ; Tue, 31 Jul 2012 13:40:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBD721F84B9 for ; Tue, 31 Jul 2012 13:40:22 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id 4EE642016A for ; Tue, 31 Jul 2012 16:52:42 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: References: <5615.1343689590@sandelman.ca> <1314.1343756566@obiwan.sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) 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 Subject: Re: [homenet] how to bookmark .lan, /.home, /.my-homenet when not home X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:40:23 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable (cutting to get to the point) >>>>> "Kerry" =3D=3D Kerry Lynn writes: Kerry> What I'm trying to figure out is whether most people in these co= nversations Kerry> are envisioning a unicast DNS service in the home that has a "lo= cally Kerry> defined" zone, as opposed to mDNS which *distributes* the name s= ervice. We want to make this possible, but not required. And when possible, make it easy. The easiest way I can think of is; Kerry> One way in which the latter may be deployed may be to have some = "agent" Kerry> that listens to mDNS announcements and then enters RRs into a un= icast Kerry> DNS. This still doesn't buy us FQDNs, however, unless the DNS h= as a Kerry> delegated zone. 1) the listener populates the reverse zone, which we have proposals on how to delegate via DHCPv6. 2) the listener could populate a forward zone, if one existed. I'm talking about #2.=20 a) if said forward zone existed, it would be nice if mDNS would permit the "canonical" FQDN for a host to be discoverable (and therefore bookmarkable). b) if said forward zone existed, should nodes be able to indicate their desire to be in it (or not in it) via mDNS? or DHCP? Or ??? Finally, I was wondering if we can through some to-be-defined-magic, get a new FQDN-ish thing which can be used without pre-arrangement in the home. Before I propose a solution (my first email hinted at one), I would like to know if it's a problem worth solving. Kerry> So you want to remotely access hosts in your residence, but with= out Kerry> configuration of any sort? Yes. I want to discover things in my home, and then remember how to talk to them.=20=20 Kerry> I'd support seeing more about naming/service discovery in homene= t drafts as Kerry> opposed to the mailing list. okay. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBhCsoqHRg3pndX9AQIsowP8CBAlOzgp6vdzhQL7mtJrkexKRwaq2/Qf qV55eSer83bRi9UVAtZTDJkMfrDkHdyVXrIFQwKijwlLhhpBEcdI9/nUYT3aTlnS xwdsHZa9GvIlpYcUTKfLdwe3myNpibW5C5lEPn65jYnYdmKKWugeSQtE2DTd1+rU w4XqQJv2eIA= =a4mT -----END PGP SIGNATURE----- --=-=-=-- From mellon@fugue.com Tue Jul 31 13:40:59 2012 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 610FD21F8596 for ; Tue, 31 Jul 2012 13:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DCo7lJFFj2g for ; Tue, 31 Jul 2012 13:40:59 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id EA2F821F84B9 for ; Tue, 31 Jul 2012 13:40:58 -0700 (PDT) Received: from dhcp-462a.meeting.ietf.org (dhcp-462a.meeting.ietf.org [130.129.70.42]) by toccata.fugue.com (Postfix) with ESMTPSA id 0F34A2380756; Tue, 31 Jul 2012 16:40:57 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_A074EE5F-B03B-44F5-8B88-4247DE9144AD" From: Ted Lemon In-Reply-To: <29762.1343766542@obiwan.sandelman.ca> Date: Tue, 31 Jul 2012 13:40:57 -0700 Message-Id: <3CE821F2-807B-488B-85EC-8FB711D7BC86@fugue.com> References: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> <29762.1343766542@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1283) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:40:59 -0000 --Apple-Mail=_A074EE5F-B03B-44F5-8B88-4247DE9144AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 31, 2012, at 1:29 PM, Michael Richardson wrote: > Perhaps there are privacy concerns if the ISP has this mapping = recorded, > and it would be better if the CPE was the only place with the info. I think the overall strategy you described is a valid one, but probably = not the only valid one. And when I've had conversations with people = about this in the past, there has definitely been concern about = publishing _every_ IP address in a public-facing zone. But likely the = answer to that is split-horizon (shudder) DNS with some out-facing = information either anonymized or elided. --Apple-Mail=_A074EE5F-B03B-44F5-8B88-4247DE9144AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Perhaps there = are privacy concerns if the ISP has this mapping recorded,
and it = would be better if the CPE was the only place with the = info.

I think the overall strategy = you described is a valid one, but probably not the only valid one. =   And when I've had conversations with people about this in the = past, there has definitely been concern about publishing _every_ IP = address in a public-facing zone.   But likely the answer to that is = split-horizon (shudder) DNS with some out-facing information either = anonymized or elided.

= --Apple-Mail=_A074EE5F-B03B-44F5-8B88-4247DE9144AD-- From mellon@fugue.com Tue Jul 31 13:42:00 2012 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 B995E21F8599 for ; Tue, 31 Jul 2012 13:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGFiX955jMGg for ; Tue, 31 Jul 2012 13:42:00 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8E121F84EA for ; Tue, 31 Jul 2012 13:42:00 -0700 (PDT) Received: from dhcp-462a.meeting.ietf.org (dhcp-462a.meeting.ietf.org [130.129.70.42]) by toccata.fugue.com (Postfix) with ESMTPSA id 57E4E2380756; Tue, 31 Jul 2012 16:41:59 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_9C5343E4-F214-4AD6-8666-9BAC80BFD37A" From: Ted Lemon In-Reply-To: <20120731203131.36F2B2326F11@drugs.dv.isc.org> Date: Tue, 31 Jul 2012 13:41:58 -0700 Message-Id: References: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> <27005.1343765554@obiwan.sandelman.ca> <20120731203131.36F2B2326F11@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1283) Cc: "homenet@ietf.org Group" , Michael Richardson , james woodyatt Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:42:00 -0000 --Apple-Mail=_9C5343E4-F214-4AD6-8666-9BAC80BFD37A Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Jul 31, 2012, at 1:31 PM, Mark Andrews wrote: > All this requires is an appropriate DHCPv6 option to be allocated. You could probably piggyback this on the CGA key if we start doing this. --Apple-Mail=_9C5343E4-F214-4AD6-8666-9BAC80BFD37A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jul 31, 2012, at 1:31 PM, Mark Andrews wrote:
All this requires is an appropriate DHCPv6 option to be allocated.

You could probably piggyback this on the CGA key if we start doing this.

--Apple-Mail=_9C5343E4-F214-4AD6-8666-9BAC80BFD37A-- From curtis@occnc.com Tue Jul 31 13:44:43 2012 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 6B61C21F8599 for ; Tue, 31 Jul 2012 13:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=1.112, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QJSB9AJE1i2 for ; Tue, 31 Jul 2012 13:44:42 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 97A3A21F84EA for ; Tue, 31 Jul 2012 13:44:42 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q6VKiWZg083438; Tue, 31 Jul 2012 16:44:33 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201207312044.q6VKiWZg083438@gateway.ipv6.occnc.com> To: Ted Lemon From: Curtis Villamizar In-reply-to: Your message of "Mon, 30 Jul 2012 17:57:58 PDT." <5B72C03D-18E1-42BE-9263-544B672BABE0@fugue.com> Date: Tue, 31 Jul 2012 16:44:32 -0400 Cc: Michael Richardson , "homenet@ietf.org Group" , Michael Thomas , james woodyatt Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:44:43 -0000 Ted, I'm agreeing with you that there are other uses for PTR records than a misguided notion of security. Every log file that tries to record host names becomes much more readable if it is successful in recording host names than if it records IP addresses. In some cases for performance reasons the log files have to record IP addresses, but that would not be expected to be the case for home use. It is even worse if the log files record IP addresses and the person reading the logs has no reverse map. The example cited by Michael in http://www.ietf.org/mail-archive/web/homenet/current/msg01286.html is a good one. Particularly the "double use case" in that example. Since a home user is not likely to know to consult DHCP logs or dynamic (m?)DNS logs, that use case where the provider logs had DNS names is a good example. Curtis In message <5B72C03D-18E1-42BE-9263-544B672BABE0@fugue.com> Ted Lemon writes: --===============3943190178831859519== Content-Type: multipart/alternative; boundary="Apple-Mail=_9BAA1259-B71E-4867-8EF8-F0FF03A0821C" --Apple-Mail=_9BAA1259-B71E-4867-8EF8-F0FF03A0821C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 30, 2012, at 4:59 PM, Michael Thomas wrote: > Maybe I missed it, but why is lack of reverse map a problem, minus the > security desire to show some weak control of the allocated prefix? This is the wrong way to ask the question. Let me restate it: Is there some application for the reverse DNS, aside from the totally = useless "security" provided by matching the PTR with the AAAA? The answer is yes. There are a number of uses: peer-to-peer = rendezvous, a place to publish keys, debugging info are examples. = AFAIK there is no controversy about the fact that that using the PTR = record as a confirmation that you are who you say you are is completely = useless and should not be done. --Apple-Mail=_9BAA1259-B71E-4867-8EF8-F0FF03A0821C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Maybe I = missed it, but why is lack of reverse map a problem, minus = the
security desire to show some weak control of the allocated = prefix?

This is the wrong way to = ask the question.   Let me restate it:

Is = there some application for the reverse DNS, aside from the totally = useless "security" provided by matching the PTR with the = AAAA?

The answer is yes.   There are a = number of uses: peer-to-peer rendezvous, a place to publish keys, = debugging info are examples.   AFAIK there is no controversy about = the fact that that using the PTR record as a confirmation that you are = who you say you are is completely useless and should not be = done.

= --Apple-Mail=_9BAA1259-B71E-4867-8EF8-F0FF03A0821C-- --===============3943190178831859519== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet --===============3943190178831859519==-- From mellon@fugue.com Tue Jul 31 13:50:42 2012 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 8123121F888F for ; Tue, 31 Jul 2012 13:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAxtC009v11y for ; Tue, 31 Jul 2012 13:50:41 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A0A9121F87F1 for ; Tue, 31 Jul 2012 13:50:41 -0700 (PDT) Received: from dhcp-462a.meeting.ietf.org (dhcp-462a.meeting.ietf.org [130.129.70.42]) by toccata.fugue.com (Postfix) with ESMTPSA id B1A392380756; Tue, 31 Jul 2012 16:50:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Ted Lemon In-Reply-To: <201207312044.q6VKiWZg083438@gateway.ipv6.occnc.com> Date: Tue, 31 Jul 2012 13:50:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <40C70A16-5B8B-49BC-BD48-40308F5BD0A5@fugue.com> References: <201207312044.q6VKiWZg083438@gateway.ipv6.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1283) Cc: Michael Richardson , "homenet@ietf.org Group" , Michael Thomas , james woodyatt Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:50:42 -0000 On Jul 31, 2012, at 1:44 PM, Curtis Villamizar wrote: > Every log file that tries to record host names becomes much more > readable if it is successful in recording host names than if it > records IP addresses. In some cases for performance reasons the log > files have to record IP addresses, but that would not be expected to > be the case for home use. It is even worse if the log files record IP > addresses and the person reading the logs has no reverse map. Yes. Of course, it's important to have a clear understanding of the = recipient of the data=97if you are using it to communicate with the = customer, as in Michael's example, then it makes sense to log it. It's = useless for law enforcement or copyright tattling. Anyway, I think there's a case to be made for a system like the one = Michael is describing; I just don't think every ISP will want to do = that. From wouter.cloetens@softathome.com Tue Jul 31 13:53:42 2012 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 3F00C21F88A2 for ; Tue, 31 Jul 2012 13:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZbLAfphU2ZS for ; Tue, 31 Jul 2012 13:53:41 -0700 (PDT) Received: from e2big.org (e2big-1-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:d5b::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6021E21F8898 for ; Tue, 31 Jul 2012 13:53:40 -0700 (PDT) Received: from d54c6f8b3.access.telenet.be ([84.198.248.179]) by e2big.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SwJRk-0001sq-Dx for homenet@ietf.org; Tue, 31 Jul 2012 22:53:40 +0200 Message-ID: <501845D2.1000205@softathome.com> Date: Tue, 31 Jul 2012 22:53:38 +0200 From: Wouter Cloetens User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: homenet@ietf.org References: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> In-Reply-To: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:53:42 -0000 On 31/07/12 20:32, Curtis Villamizar wrote: >> I'm thinking I'd much more like to see a specific recommendation that HOMENET gateways implement a site-managed reverse tree, optionally augmented with a zero-configuration method for generating content explicitly managed by a knowledgeable home network administrator. >> >> For example, after I install a fresh HOMENET gateway in my new house, I expect the following things just to happen correctly without any forethought: >> >> 1. The integrated DNS content server should have authority for all of the ip6.arpa corresponding to the IPv6 prefixes delegated by its service provider; >> >> 2. The integrated DNS resolving server should answer [on the local network only] for the locally generated ULA prefixes required by RFC 6106. >> >> 3. Queries for PTR records in zones for which it's authoritative should always produce a synthesized answer if no explicitly configured records are stored in the content server. [...] > I think you could add to the above that the provider should offer to > delegate a forward zone and a reverse zone via DHCP extension and > offer to provide DNS secondary for those zones. Note that > draft-lemon-dhc-dns-pd doesn't go that far (offering a forward zone > name to use), but it would be a useful addition. Covered in: http://www.ietf.org/id/draft-mglt-homenet-naming-delegation-00.txt This also covers security considerations. > It would be nice if the customer router could request that the > provider secondary also pick up a zone allocated to the site by a > registrar. The provider router can verify this by looking up the NS > records for that zone and determining that the A or AAAA for at least > one of the existing nameservers falls with the static address > allocation of the site. This would be for advanced users and the > advanced user (or a sufficiently advanced DHCP/nameserver coupling) > could then update the list of NS records adding the provider > secondary. Covered in a completely different way in: http://www.ietf.org/id/draft-mglt-homenet-front-end-naming-delegation-00.txt From mcr+ietf@sandelman.ca Tue Jul 31 13:54:58 2012 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 E551D21F84B2 for ; Tue, 31 Jul 2012 13:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3p9R4IoDFyB for ; Tue, 31 Jul 2012 13:54:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id 6062B21F88A9 for ; Tue, 31 Jul 2012 13:54:58 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id 4312A2016A for ; Tue, 31 Jul 2012 17:07:18 -0400 (EDT) From: Michael Richardson To: "homenet@ietf.org Group" In-Reply-To: <201207312044.q6VKiWZg083438@gateway.ipv6.occnc.com> References: <201207312044.q6VKiWZg083438@gateway.ipv6.occnc.com> X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) 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 Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:54:59 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Curtis" =3D=3D Curtis Villamizar writes: Curtis> Every log file that tries to record host names becomes much more Curtis> readable if it is successful in recording host names than if it Curtis> records IP addresses. In some cases for performance reasons th= e log Curtis> files have to record IP addresses, but that would not be expect= ed to Curtis> be the case for home use. It is even worse if the log files re= cord IP Curtis> addresses and the person reading the logs has no reverse Curtis> map. the machines recording the addresses/names are not in the home. They are the web servers that the home user talks to. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBhGHoqHRg3pndX9AQLYygP/VTa6OCnlcaTQCn8Bt5B/jvqt8IfFbUzt 9oW9OFTnJOsh+L6y5UsGgQFeQc9qQfbiBgwkPiczjpsnPFRfihIm02UiZFYHf1L5 vjTYrLcas8Axne8o+NbWpCIG4X/3FuGOrF6W1DBIbUBR0G/8eGZ8XnS9KIR0RxmC MZpaPVn6uTY= =5pua -----END PGP SIGNATURE----- --=-=-=-- From cb.list6@gmail.com Tue Jul 31 14:13:17 2012 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 CE83B21F8917 for ; Tue, 31 Jul 2012 14:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.452 X-Spam-Level: X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-iKEKwD2uGV for ; Tue, 31 Jul 2012 14:13:17 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 544C621F88C0 for ; Tue, 31 Jul 2012 14:13:16 -0700 (PDT) Received: by lagv3 with SMTP id v3so4482381lag.31 for ; Tue, 31 Jul 2012 14:13:15 -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=/2j7CrAiHbL55z/V5+nramlm5JVgLYXf1YhM9k8MIQ8=; b=oemB7OrkhddQXr6NpXasPOOYC9xqqLsrUhG9nP/oJoNc5Dq6dtKA4TxOLOEyxSSbgg GwmFLs6Z80Efd5iLgPhB+WdhLD4q/KbXTa1MltSrKB/31N69XypbW4APCDp34n3yJ+h6 cP9UUZIRDl+JhGocDYa12I9UqaVOv0dAA6pypTswWycSHOQvhUwCIkRZ87PbqxI6pIHT vOJcj4V7L+flDtYlqUw1WtGLuFWQ+9hVhDKHhWWGqmQ0wdYbKdJ/okWtDuWBYL2LUify 0lCDaOMLc70jb7HBi0f5tij+0Ms9yybfotoYyGaEq7UHdd/9cQrO1cOlihss4A54Q52/ nxOg== MIME-Version: 1.0 Received: by 10.152.106.233 with SMTP id gx9mr16038906lab.48.1343769195213; Tue, 31 Jul 2012 14:13:15 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Tue, 31 Jul 2012 14:13:15 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Tue, 31 Jul 2012 14:13:15 -0700 (PDT) In-Reply-To: References: <29762.1343766542@obiwan.sandelman.ca> Date: Tue, 31 Jul 2012 14:13:15 -0700 Message-ID: From: Cameron Byrne To: "Howard, Lee" Content-Type: multipart/alternative; boundary=f46d040890278a71b904c626a51c Cc: Michael Richardson , "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 21:13:17 -0000 --f46d040890278a71b904c626a51c Content-Type: text/plain; charset=ISO-8859-1 On Jul 31, 2012 1:36 PM, "Howard, Lee" wrote: > > > > On 7/31/12 1:29 PM, "Michael Richardson" wrote: > > > > >>>>>> "Ted" == Ted Lemon writes: > > Ted> You secondary a zone so that the contents of the zone will be > > Ted> there when a query happens, but why would a query happen if the > > Ted> CPE device isn't reachable? What would trigger that query? > > Ted> So I think you can get away with _not_ secondarying the zone. > > Ted> But if you do want to secondary it, why would the ISP be > > Ted> responsible for that? Presumably the customer is pretty > > Ted> savvy; a secondary for their reverse tree would just be another > > Ted> service they'd want to buy or set up, and the ISP could wash > > Ted> their hands of it or sell it, whichever they chose. > > > >My suggestion is that the ISP secondary the zone from the CPE, but > >actually advertise only their server in the NS delegation. (The CPE > >remains a stealth primary) > > I need to see an internet-draft problem statement. I still don't believe > there is one, and I have no plans to provide IPv6 reverse DNS for > residential subscribers. Any ISPs planning to do this? > > Lee > I see no reason for it in mobile networks. I do not support it in my current 3gpp network for ipv6, no plans for future. CB > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --f46d040890278a71b904c626a51c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 31, 2012 1:36 PM, "Howard, Lee" <lee.howard@twcable.com> wrote:
>
>
>
> On 7/31/12 1:29 PM, "Michael Richardson" <mcr+ietf@sandelman.ca> wrote:
>
> >
> >>>>>> "Ted" =3D=3D Ted Lemon <mellon@fugue.com> writes:
> > =A0 =A0Ted> You secondary a zone so that the contents of the z= one will be
> > =A0 =A0Ted> there when a query happens, but why would a query = happen if the
> > =A0 =A0Ted> CPE device isn't reachable? =A0What would trig= ger that query?
> > =A0 =A0Ted> So I think you can get away with _not_ secondaryin= g the zone.
> > =A0 =A0Ted> But if you do want to secondary it, why would the = ISP be
> > =A0 =A0Ted> responsible for that? =A0 Presumably the customer = is pretty
> > =A0 =A0Ted> savvy; a secondary for their reverse tree would ju= st be another
> > =A0 =A0Ted> service they'd want to buy or set up, and the = ISP could wash
> > =A0 =A0Ted> their hands of it or sell it, whichever they chose= .
> >
> >My suggestion is that the ISP secondary the zone from the CPE, but=
> >actually advertise only their server in the NS delegation. =A0(The= CPE
> >remains a stealth primary)
>
> I need to see an internet-draft problem statement. =A0I still don'= t believe
> there is one, and I have no plans to provide IPv6 reverse DNS for
> residential subscribers. =A0Any ISPs planning to do this?
>
> Lee
>

I see no reason for it in mobile networks. I do not support it in my cur= rent 3gpp network for ipv6, no plans for future.

CB

>
> This E-mail and any of its attachments may contain Time Warner Cable p= roprietary information, which is privileged, confidential, or subject to co= pyright belonging to Time Warner Cable. This E-mail is intended solely for = the use of the individual or entity to which it is addressed. If you are no= t the intended recipient of this E-mail, you are hereby notified that any d= issemination, distribution, copying, or action taken in relation to the con= tents of and attachments to this E-mail is strictly prohibited and may be u= nlawful. If you have received this E-mail in error, please notify the sende= r immediately and permanently delete the original and any copy of this E-ma= il and any printout.
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.= ietf.org/mailman/listinfo/homenet

--f46d040890278a71b904c626a51c-- From curtis@occnc.com Tue Jul 31 14:30:58 2012 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 3A28A21F880C for ; Tue, 31 Jul 2012 14:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13NdId8c0Hlp for ; Tue, 31 Jul 2012 14:30:57 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 8017821F886B for ; Tue, 31 Jul 2012 14:30:57 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q6VLUk1c083981; Tue, 31 Jul 2012 17:30:47 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201207312130.q6VLUk1c083981@gateway.ipv6.occnc.com> To: Dmitry Anipko From: Curtis Villamizar In-reply-to: Your message of "Tue, 31 Jul 2012 02:10:02 -0000." <96DD85EB136DCD49AB5CDB6DEC9639AD120CEB1B@CH1PRD0310MB368.namprd03.prod.outlook.com> Date: Tue, 31 Jul 2012 17:30:46 -0400 Cc: "homenet@ietf.org" Subject: Re: [homenet] homenet hosts security requirements and realm discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 21:30:58 -0000 In message <96DD85EB136DCD49AB5CDB6DEC9639AD120CEB1B@CH1PRD0310MB368.namprd03.prod.outlook.com> Dmitry Anipko writes: > In draft-ietf-homenet-arch-04, I was looking for and could not find a > requirement for the network to provide homenet hosts with the > information about the realms - as a basic example, which prefixes are > associated with the most trusted homenet realm, as opposed to > guest/Internet. > > For the hosts, described in section 3.6.3, which opt into transparent > inbound communication, this capability would be useful to enable on > the host scenarios such as "share resource A, require user > authentication for guest/Internet realms and don't require for > homenet", or "share resource B within the homenet only, while share > resource C with all realms". > > Is there already a section that implies such requirement, or if not, > are there concerns with adding such requirement to the draft? > > -Dmitry Dmitry, Look at the first sentence in section 3.3.1. "The homenet will need to be aware of the extent of its own 'site', which will define the borders for ULAs, site scope multicast, service discovery and security policies." A host gets connected to a realm and the realm simply determines the boundary of where the ULA, site scope multicast, etc is propogated beyond the local subnet. In many cases a realm consists of one local subnet. Borders in this case imply a firewall, though the realms could have a null firewall (pass everything) if security is accomplished using IPSEC, TLS, or applications layer security. In a current enterprise, internal WiFi users are connected to a subset of channels with slightly stronger authentication. Guest within the building may use a shared password authentication given to them when they enter the building or none at all (open WiFi if the building has RF shielding or the campus is large enough that WiFi range doesn't extend beyond the campus (or both). Section 3.6.3 does not imply that host security should be based on the homenet realm. A host security using TLS for example should be applied the same regardless of the homenet realm. For example, a connection from a mobile phone (without WiFi) would come from the external internet homenet realm. Firewalls should only block access to insecure or very weakly secured services behind the firewall. IMHO there should be no insecure or very weakly secured services anywhere. If so, there is no need for a firewall. (BTW - the 1990s T3-NSFNET infrastructure and NMS had no firewalls and was quite secure even by today's standards, much more secure than most enterprises that I have encountered). This has nothing to do with any notion of domain, realm, etc in Windows (or krb5/gssapi) if that is the question. Curtis From mike@mtcc.com Tue Jul 31 14:35:41 2012 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 E8E9221F8896 for ; Tue, 31 Jul 2012 14:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3auEjrzeucTV for ; Tue, 31 Jul 2012 14:35:41 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 097C821F88AD for ; Tue, 31 Jul 2012 14:35:40 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6VLZaZj008773 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 31 Jul 2012 14:35:37 -0700 Message-ID: <50184FA8.1070302@mtcc.com> Date: Tue, 31 Jul 2012 14:35:36 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Michael Richardson References: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> <29762.1343766542@obiwan.sandelman.ca> In-Reply-To: <29762.1343766542@obiwan.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1069; t=1343770537; x=1344634537; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Reverse=20DNS |Sender:=20 |To:=20Michael=20Richardson=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=1T/c3qKN6tzzXDHw9dvDXmdZPH/7pxD1JlRjEGEMKAk=; b=uIRk7lCEa2d6rVOFklzPuDwlQBZLx1ZeDqXqOmU2EwpVnKRIvinW2hVVkj gTQQ2Ez/WYtK0PhtVYqSQIsfFIxYqii1CkDcd0JAfVF7UFqrZF21wLz9Zq6g vgJQFgrTDDTFYZPBF8ee/sPgiX3DFWVxjAmesRP22NlNXsxabsDYc=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 21:35:42 -0000 On 07/31/2012 01:29 PM, Michael Richardson wrote: >>>>>> "Ted" == Ted Lemon writes: > Ted> You secondary a zone so that the contents of the zone will be > Ted> there when a query happens, but why would a query happen if the > Ted> CPE device isn't reachable? What would trigger that query? > Ted> So I think you can get away with _not_ secondarying the zone. > Ted> But if you do want to secondary it, why would the ISP be > Ted> responsible for that? Presumably the customer is pretty > Ted> savvy; a secondary for their reverse tree would just be another > Ted> service they'd want to buy or set up, and the ISP could wash > Ted> their hands of it or sell it, whichever they chose. > > My suggestion is that the ISP secondary the zone from the CPE, but > actually advertise only their server in the NS delegation. (The CPE > remains a stealth primary) Do you mean (in bind parlance at least) the CPE is the master, and the ISP is the slave even though it's authoritative? Mike From marka@isc.org Tue Jul 31 14:39:57 2012 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 AEAD721F88C6 for ; Tue, 31 Jul 2012 14:39:57 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+zc9UQNFeuT for ; Tue, 31 Jul 2012 14:39:57 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 3D23E21F884D for ; Tue, 31 Jul 2012 14:39:57 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 69D50C9579 for ; Tue, 31 Jul 2012 21:39:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:96:61a1:6853:806e:5e69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 50FD1216C3D for ; Tue, 31 Jul 2012 21:39:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id D8C282327647 for ; Wed, 1 Aug 2012 07:39:43 +1000 (EST) To: homenet@ietf.org From: Mark Andrews Date: Wed, 01 Aug 2012 07:39:43 +1000 Message-Id: <20120731213943.D8C282327647@drugs.dv.isc.org> Subject: [homenet] draft-ietf-homenet-arch-04 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 21:39:57 -0000 Section 2.6 IPv6-only, overlooks node based DS-Lite as a viable solution. The DS-Lite BR could be learnt from the ISP or be provided internally presumably by a CPE router when the homenet has both dual stack connectivity and ipv6-only subnets. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From curtis@occnc.com Tue Jul 31 14:45:18 2012 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 E1E2121F88A2 for ; Tue, 31 Jul 2012 14:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGAo9zYc++6S for ; Tue, 31 Jul 2012 14:45:18 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id B010B21F8895 for ; Tue, 31 Jul 2012 14:45:17 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q6VLj24S084224; Tue, 31 Jul 2012 17:45:03 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201207312145.q6VLj24S084224@gateway.ipv6.occnc.com> To: Michael Thomas From: Curtis Villamizar In-reply-to: Your message of "Tue, 31 Jul 2012 06:05:29 PDT." <5017D819.9030607@mtcc.com> Date: Tue, 31 Jul 2012 17:45:02 -0400 Cc: homenet@ietf.org Subject: Re: [homenet] a modest proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 21:45:19 -0000 In message <5017D819.9030607@mtcc.com> Michael Thomas writes: > On 07/31/2012 01:00 AM, Brian E Carpenter wrote: > > On 31/07/2012 01:20, Michael Thomas wrote: > >> On 07/30/2012 05:10 PM, Curtis Villamizar wrote: > >>> If you see some advantage that solves the IPv4 address depletion (a > >>> big point of the transition to IPv6 exercise), then I've missed it. > >>> If so, please point out what I missed. > >> No, not at all and not the point. I'm just of the mind that if > >> we believe that v6 is really, really ready to go there shouldn't > >> be any problem in substituting rfc1918 v4 space with v6 ULA > >> space. If that modest change leads to trouble... > > Well, it surely requires a DNS64 resolver in the CPE too. > > > Having embedded DNS functionality in the CPE is sort of a newish > requirement, yes? If we think that's inevitable for real homenets, > maybe this is a means of moving the ball forward? > > Mike This requirement is Not at all new. Most low endish CPE get a single IPv4 address from the provider, do NAT, offer PI addresses on the "home" side, offer themselves as DNS resolvers on the home side. Act as a DNS cache using the nameserver(s) offerred by the service provider as forwarders. Most home users get the CPE from the provider and the providers like having a resolver in the CPE so today this is a business requirement, not an IETF requirement. Curtis From Ray.Bellis@nominet.org.uk Tue Jul 31 14:49:27 2012 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 EC6A621F8907 for ; Tue, 31 Jul 2012 14:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.541 X-Spam-Level: X-Spam-Status: No, score=-10.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x3GxVQscLXz for ; Tue, 31 Jul 2012 14:49:27 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 204B121F88FB for ; Tue, 31 Jul 2012 14:49:26 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=qtRUS3dmAtuWLyhL/SFzJjCXz4Jjwax0q1mMmx3w4R8TfnhzQqZnNDb8 +7VNTt4C4zu5a/DDr9PBYw8o3k0MX+a2fsIbmwcvr34+ta3jYNOEsbTJd hdUBnU3lbMdfp8A; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1343771367; x=1375307367; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20Reverse=20DNS|Date:=20Tue, =2031=20Jul=202012=2021:49:23=20+0000|Message-ID:=20<2626 6CD1-7B82-4E94-9A0C-879601FAE0E4@nominet.org.uk>|To:=20Mi chael=20Thomas=20|CC:=20"homenet@ietf.org =20Group"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20 |In-Reply-To:=20<50184FA8.1070302@mtcc.com>|References: =20<201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> =0D=0A=20 =0D=0A=20<29762.1343766542@obiwan.sandelman.ca>=20<50184F A8.1070302@mtcc.com>; bh=pZkplDJA2a1FfmGfdOMNLOnYrjqDr3WCe6DKqYnb2FQ=; b=C/Bd9E9o08sJVsCX4mmpVN+Otcun6yHVr8wdI26ZIraPE76l7GEREONf CdPQO7lhs9IxRSu95nvCX8uRfWbWSIFl2xsFExFUOgXPlXDeEuQVlUlQj BjGs+K45jqjOaio; X-IronPort-AV: E=Sophos;i="4.77,689,1336345200"; d="scan'208";a="34465556" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx4.nominet.org.uk with ESMTP; 31 Jul 2012 22:49:25 +0100 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%19]) with mapi; Tue, 31 Jul 2012 22:49:24 +0100 From: Ray Bellis To: Michael Thomas Thread-Topic: [homenet] Reverse DNS Thread-Index: AQHNb0rdVGLL7xVC20e+bCpkKutovZdDqs4AgAAcFwCAABKZAIAAA9qA Date: Tue, 31 Jul 2012 21:49:23 +0000 Message-ID: <26266CD1-7B82-4E94-9A0C-879601FAE0E4@nominet.org.uk> References: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> <29762.1343766542@obiwan.sandelman.ca> <50184FA8.1070302@mtcc.com> In-Reply-To: <50184FA8.1070302@mtcc.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 21:49:28 -0000 On 31 Jul 2012, at 14:35, Michael Thomas wrote: > Do you mean (in bind parlance at least) the CPE is the master, and the > ISP is the slave even though it's authoritative? To the outside world, all published name servers are equally "authoritative= ". The master/slave (or "primary / secondary") relationship only matters for d= istribution of zone content between those servers. Ray From marka@isc.org Tue Jul 31 14:51:12 2012 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 106DA21F8503 for ; Tue, 31 Jul 2012 14:51:12 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9kfYN+rPopN for ; Tue, 31 Jul 2012 14:51:11 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF3421F8501 for ; Tue, 31 Jul 2012 14:51:11 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 3C4F05F99AC; Tue, 31 Jul 2012 21:50:56 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:96:61a1:6853:806e:5e69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 6EA72216C33; Tue, 31 Jul 2012 21:50:54 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id B1A5E2327A29; Wed, 1 Aug 2012 07:50:53 +1000 (EST) To: Michael Thomas From: Mark Andrews References: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> <29762.1343766542@obiwan.sandelman.ca> <50184FA8.1070302@mtcc.com> In-reply-to: Your message of "Tue, 31 Jul 2012 14:35:36 MST." <50184FA8.1070302@mtcc.com> Date: Wed, 01 Aug 2012 07:50:53 +1000 Message-Id: <20120731215053.B1A5E2327A29@drugs.dv.isc.org> Cc: Michael Richardson , "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 21:51:12 -0000 In message <50184FA8.1070302@mtcc.com>, Michael Thomas writes: > On 07/31/2012 01:29 PM, Michael Richardson wrote: > >>>>>> "Ted" == Ted Lemon writes: > > Ted> You secondary a zone so that the contents of the zone will be > > Ted> there when a query happens, but why would a query happen if the > > Ted> CPE device isn't reachable? What would trigger that query? > > Ted> So I think you can get away with _not_ secondarying the zone. > > Ted> But if you do want to secondary it, why would the ISP be > > Ted> responsible for that? Presumably the customer is pretty > > Ted> savvy; a secondary for their reverse tree would just be another > > Ted> service they'd want to buy or set up, and the ISP could wash > > Ted> their hands of it or sell it, whichever they chose. > > > > My suggestion is that the ISP secondary the zone from the CPE, but > > actually advertise only their server in the NS delegation. (The CPE > > remains a stealth primary) > > Do you mean (in bind parlance at least) the CPE is the master, and the > ISP is the slave even though it's authoritative? All listed nameservers for a zone are presumed to be authoritative for the zone. slave/master (primary/secondary) are only relevent w.r.t. the zone transfer graph between these servers and where update requests are forwarded to. > Mike > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mellon@fugue.com Tue Jul 31 14:51:36 2012 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 E028821F884E for ; Tue, 31 Jul 2012 14:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hugRJJtskpU for ; Tue, 31 Jul 2012 14:51:35 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id DCF8521F86BE for ; Tue, 31 Jul 2012 14:51:31 -0700 (PDT) Received: from dhcp-462a.meeting.ietf.org (dhcp-462a.meeting.ietf.org [130.129.70.42]) by toccata.fugue.com (Postfix) with ESMTPSA id 895232380C5D; Tue, 31 Jul 2012 17:51:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_69330587-CD20-481B-81C1-70739F93B5E5" From: Ted Lemon In-Reply-To: <50184FA8.1070302@mtcc.com> Date: Tue, 31 Jul 2012 14:51:28 -0700 Message-Id: <7DF56F63-DEAB-4F1F-9016-5E9C5E4A3F98@fugue.com> References: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> <29762.1343766542@obiwan.sandelman.ca> <50184FA8.1070302@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1283) Cc: Michael Richardson , "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 21:51:36 -0000 --Apple-Mail=_69330587-CD20-481B-81C1-70739F93B5E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 31, 2012, at 2:35 PM, Michael Thomas wrote: > Do you mean (in bind parlance at least) the CPE is the master, and the > ISP is the slave even though it's authoritative? I mean that the CPE is the primary and the ISP is the secondary, yes. = The CPE is in a much better position to maintain the contents of the = zone=97the ISP doesn't have access to the information necessary to do = this. --Apple-Mail=_69330587-CD20-481B-81C1-70739F93B5E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Do you mean = (in bind parlance at least) the CPE is the master, and the
ISP is the = slave even though it's = authoritative?

I mean that the CPE = is the primary and the ISP is the secondary, yes.   The CPE is in a = much better position to maintain the contents of the zone=97the ISP = doesn't have access to the information necessary to do = this.

= --Apple-Mail=_69330587-CD20-481B-81C1-70739F93B5E5-- From mike@mtcc.com Tue Jul 31 15:14:24 2012 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 4AC6511E8136 for ; Tue, 31 Jul 2012 15:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.726 X-Spam-Level: X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aW78NRKthBLt for ; Tue, 31 Jul 2012 15:14:23 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id B15B321F8864 for ; Tue, 31 Jul 2012 15:14:23 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q6VMELrv021742 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 31 Jul 2012 15:14:22 -0700 Message-ID: <501858BD.2040700@mtcc.com> Date: Tue, 31 Jul 2012 15:14:21 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Ray Bellis References: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> <29762.1343766542@obiwan.sandelman.ca> <50184FA8.1070302@mtcc.com> <26266CD1-7B82-4E94-9A0C-879601FAE0E4@nominet.org.uk> In-Reply-To: <26266CD1-7B82-4E94-9A0C-879601FAE0E4@nominet.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=838; t=1343772863; x=1344636863; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Reverse=20DNS |Sender:=20 |To:=20Ray=20Bellis=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=BdH7EgiYPVKJSxsEh4mnEFZgAr4JojSF5jpYPVTjiu8=; b=eyKrsm3AkrzYYwnsXIqk+qBj5c8GScT7xbye9Ef4QOtufsxu9HJLwzMrUs Sk1ziAsKuPKju5dAkqKbmx4n176WCRuKvVyBWeGpB3KyjiuUpZBJTYfvh8YW fQDljqH8yjlVG5gUPYdN3VXC3uqXl5bEIXUWMo6KdbTp0OYfMeG+w=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 22:14:24 -0000 On 07/31/2012 02:49 PM, Ray Bellis wrote: > On 31 Jul 2012, at 14:35, Michael Thomas wrote: > >> Do you mean (in bind parlance at least) the CPE is the master, and the >> ISP is the slave even though it's authoritative? > To the outside world, all published name servers are equally "authoritative". > > The master/slave (or "primary / secondary") relationship only matters for distribution of zone content between those servers. > I'm probably going to get myself in trouble for ignorance, but if my CPE's dns is not listed as an NS from the root servers, I don't think it's authoritative. It may be supplying the zone via some master/slave arrangement with the ISP, but that's only how the ISP getting its brains for the home zone, and is just using zone transfers to affect that. Sorry if this is a rathole. Mike From mellon@fugue.com Tue Jul 31 15:21:04 2012 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 D78CB11E814E for ; Tue, 31 Jul 2012 15:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYnvA3n4pTld for ; Tue, 31 Jul 2012 15:21:04 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0D85F11E814D for ; Tue, 31 Jul 2012 15:21:04 -0700 (PDT) Received: from [IPv6:2001:df8::64:197d:90c7:3a25:40e0] (unknown [IPv6:2001:df8:0:64:197d:90c7:3a25:40e0]) by toccata.fugue.com (Postfix) with ESMTPSA id 0624423814E4; Tue, 31 Jul 2012 18:21:02 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_7FC8CF23-8BD1-4B85-B583-10751BEE8F82" From: Ted Lemon In-Reply-To: <501858BD.2040700@mtcc.com> Date: Tue, 31 Jul 2012 15:21:01 -0700 Message-Id: <2EE972B4-14C3-494D-94F6-C51FFF8BE330@fugue.com> References: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> <29762.1343766542@obiwan.sandelman.ca> <50184FA8.1070302@mtcc.com> <26266CD1-7B82-4E94-9A0C-879601FAE0E4@nominet.org.uk> <501858BD.2040700@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1283) Cc: Ray Bellis , "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 22:21:05 -0000 --Apple-Mail=_7FC8CF23-8BD1-4B85-B583-10751BEE8F82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 31, 2012, at 3:14 PM, Michael Thomas wrote: > I'm probably going to get myself in trouble for ignorance, but if my > CPE's dns is not listed as an NS from the root servers, I don't think = it's > authoritative. It may be supplying the zone via some master/slave > arrangement with the ISP, but that's only how the ISP getting its = brains > for the home zone, and is just using zone transfers to affect that. Doing the primary/secondary relationship this way is an operational = choice; you are correct that the primary in this case wouldn't be listed = as authoritative, but it would respond as if it were authoritative if = queried=97it would set the 'A' bit. But it would never receive a query = other than a zone transfer from a secondary. --Apple-Mail=_7FC8CF23-8BD1-4B85-B583-10751BEE8F82 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I'm probably = going to get myself in trouble for ignorance, but if my
CPE's dns is = not listed as an NS from the root servers, I don't think = it's
authoritative. It may be supplying the zone via some = master/slave
arrangement with the ISP, but that's only how the ISP = getting its brains
for the home zone, and is just using zone = transfers to affect that.
Doing the = primary/secondary relationship this way is an operational choice; you = are correct that the primary in this case wouldn't be listed as = authoritative, but it would respond as if it were authoritative if = queried=97it would set the 'A' bit.   But it would never receive a = query other than a zone transfer from a = secondary.

= --Apple-Mail=_7FC8CF23-8BD1-4B85-B583-10751BEE8F82-- From mcr+ietf@sandelman.ca Tue Jul 31 17:35:20 2012 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 D94B121F8850 for ; Tue, 31 Jul 2012 17:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZUW4dRXCiOT for ; Tue, 31 Jul 2012 17:35:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCD421F884E for ; Tue, 31 Jul 2012 17:35:20 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id 17B2D2016A; Tue, 31 Jul 2012 20:47:41 -0400 (EDT) From: Michael Richardson To: Michael Thomas In-Reply-To: <50184FA8.1070302@mtcc.com> References: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> <29762.1343766542@obiwan.sandelman.ca> <50184FA8.1070302@mtcc.com> X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) 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 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 00:35:21 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Michael" =3D=3D Michael Thomas writes: Ted> You secondary a zone so that the contents of the zone will be Ted> there when a query happens, but why would a query happen if the Ted> CPE device isn't reachable? What would trigger that query? So Ted> I think you can get away with _not_ secondarying the zone. But Ted> if you do want to secondary it, why would the ISP be Ted> responsible for that? Presumably the customer is pretty savvy; Ted> a secondary for their reverse tree would just be another Ted> service they'd want to buy or set up, and the ISP could wash Ted> their hands of it or sell it, whichever they chose. >> My suggestion is that the ISP secondary the zone from the CPE, >> but actually advertise only their server in the NS delegation. >> (The CPE remains a stealth primary) Michael> Do you mean (in bind parlance at least) the CPE is the Michael> master, and the ISP is the slave even though it's Michael> authoritative? Yes, and when I first started this thread, I had forgotten that draft-mglt-front-end-naming-delegation-00.txt, says something very similar. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBh5xIqHRg3pndX9AQIGQAP/T8mNur9KflatOda4l3hwB9fClCWaf3T0 vEsK0GRmkbR1aQ33LuvOUer80Px646q4Md8TiE5coMDpadXSTCoePctIENp0UY55 phI0poRWmXF9y/etyEVnfJaKqp2UsEQ6ts+MsQSWkcM5tbHeAQM3At68TVkgsRLN /wuU/y6QEPM= =CwWN -----END PGP SIGNATURE----- --=-=-=-- From curtis@occnc.com Tue Jul 31 18:26:45 2012 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 5CE9B11E816E for ; Tue, 31 Jul 2012 18:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+w2iYIIWU3S for ; Tue, 31 Jul 2012 18:26:44 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id A09D511E80E7 for ; Tue, 31 Jul 2012 18:26:44 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q711Q8sQ087703; Tue, 31 Jul 2012 21:26:10 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208010126.q711Q8sQ087703@gateway.ipv6.occnc.com> To: Ted Lemon From: Curtis Villamizar In-reply-to: Your message of "Tue, 31 Jul 2012 11:48:30 PDT." Date: Tue, 31 Jul 2012 21:26:08 -0400 Cc: "homenet@ietf.org Group" , james woodyatt , curtis@occnc.com Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 01:26:45 -0000 In message Ted Lemon writes: > The problem of secondarying the reverse zone isn't really discussed in > the dns-pd draft, and there are a number of operational details I'd > like to flesh out, but the specific question of secondarying the > reverse zone isn't quite what it seems. > > You secondary a zone so that the contents of the zone will be there > when a query happens, but why would a query happen if the CPE device > isn't reachable? What would trigger that query? So I think you can > get away with _not_ secondarying the zone. But if you do want to > secondary it, why would the ISP be responsible for that? Presumably > the customer is pretty savvy; a secondary for their reverse tree would > just be another service they'd want to buy or set up, and the ISP > could wash their hands of it or sell it, whichever they chose. Anything DNS related should be reliable. Therefore a secondary would be preferable to not having one. For example, someone looking at logs that store only IP address for performance reasons (this is common for http logs) would have only an IP address. Using the example in http://www.ietf.org/mail-archive/web/homenet/current/msg01286.html an email reporting a compromised host would have Mary-Perkins-Laptop" in the email rather than a:b:c:d::123 in the email. Yes. I agree that ISPs won't even give you the time of day without wanting to charge you for it. [Ever ask about NTP service? :)] That doesn't mean we shouldn't define protocols that support doing useful things, even if later an ISP may try to charge for it. There are a few places where you can still get a free DNS secondary. Definitely not at my ISP (not free or even for a fee). Curtis From mike@mtcc.com Tue Jul 31 18:55:16 2012 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 EC70311E8150 for ; Tue, 31 Jul 2012 18:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GKqHr3uMk+T for ; Tue, 31 Jul 2012 18:55:16 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 3492011E80DB for ; Tue, 31 Jul 2012 18:55:16 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q711tCgS029156 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 31 Jul 2012 18:55:12 -0700 Message-ID: <50188C80.9070809@mtcc.com> Date: Tue, 31 Jul 2012 18:55:12 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Ted Lemon References: <201207311832.q6VIWdqG081645@gateway.ipv6.occnc.com> <29762.1343766542@obiwan.sandelman.ca> <50184FA8.1070302@mtcc.com> <26266CD1-7B82-4E94-9A0C-879601FAE0E4@nominet.org.uk> <501858BD.2040700@mtcc.com> <2EE972B4-14C3-494D-94F6-C51FFF8BE330@fugue.com> In-Reply-To: <2EE972B4-14C3-494D-94F6-C51FFF8BE330@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=975; t=1343786114; x=1344650114; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Reverse=20DNS |Sender:=20 |To:=20Ted=20Lemon=20 |Content-Type:=20text/plain=3B=20charset=3Dwindows-1252=3B= 20format=3Dflowed |Content-Transfer-Encoding:=208bit |MIME-Version:=201.0; bh=iqgGMJZ0+ze3m3d9SKBtBxktiJblI7NzwubA6v1GsYA=; b=WA9y1ky2+Jh1E/FOdC/tjMJf3YmnMeqIQNPbbHOZFFIxSPwC0Q+FSPqwO3 iK7+EKGqEZvQ6Is0M8VH2KlXjodi+E0b2DWIkfdV9pZ2h0ESTr17KbHg8ftf Ypg+aLTaVcjrwL3RJFiD0fa8vXWAcFbVCPh9VESrgedf2s40VZZBY=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Ray Bellis , "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 01:55:17 -0000 On 07/31/2012 03:21 PM, Ted Lemon wrote: > On Jul 31, 2012, at 3:14 PM, Michael Thomas wrote: >> I'm probably going to get myself in trouble for ignorance, but if my >> CPE's dns is not listed as an NS from the root servers, I don't think it's >> authoritative. It may be supplying the zone via some master/slave >> arrangement with the ISP, but that's only how the ISP getting its brains >> for the home zone, and is just using zone transfers to affect that. > > Doing the primary/secondary relationship this way is an operational choice; you are correct that the primary in this case wouldn't be listed as authoritative, but it would respond as if it were authoritative if queried—it would set the 'A' bit. But it would never receive a query other than a zone transfer from a secondary. > Ok, thanks. I have it my head that "primary/secondary" means something else wrt DNS zone transfers, but I guess I'm just confusing it with bind's terminology. Mike From mike@mtcc.com Tue Jul 31 19:04:41 2012 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 ABD7311E81A0 for ; Tue, 31 Jul 2012 19:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.717 X-Spam-Level: X-Spam-Status: No, score=-2.717 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qH9W+1TbGkKu for ; Tue, 31 Jul 2012 19:04:40 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id C94EC11E819D for ; Tue, 31 Jul 2012 19:04:40 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q7124WRP032245 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 31 Jul 2012 19:04:32 -0700 Message-ID: <50188EB0.2040008@mtcc.com> Date: Tue, 31 Jul 2012 19:04:32 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=830; t=1343786672; x=1344650672; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20tunnels=20as=20way=20to=20disambiguate=20.local |Sender:=20 |To:=20=22=22=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=gu2ok3RSC4pH8NLshmNONUEFxbg/U4auiouxL/zYu3Q=; b=QeqMOI4C0+syIgkxAyPypVzViLO8ILyKqhCjLHx83oMLPZYEl0b9t1poOF ZfRlvBjqAZHIbavXPGPfxAVHdWAdNINX34hsWzmhELM8Wzrm/FtT/pmzHoFX IunqWMsjb6Hx0SQIlc183bBsxnsTSPXWZCu/C83QpIA+MAVKblgZQ=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: [homenet] tunnels as way to disambiguate .local X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 02:04:41 -0000 Since I apparently got a few heads shaking today from my jabber comment, I guess I should at least throw it on the list. My observation -- and I'm not necessarily saying it's a [good] solution -- is that one way that we could deal with the ambiguity of what fridge.local[site] means when I elsewhere is to say that .local[site] is exactly what it says it is: a property of the local site. As such, if I'm roaming and do not have topological connectivity, the proper way to get that connectivity would be to use some form of tunneling back to the .local[site] I actually intended and thus be part of the .local[site] topology again. On the plus side, this puts it into the hands of somebody to deal with the ambiguity. On the minus side, this puts it into the hands of somebody to deal with the ambiguity. Mike From curtis@occnc.com Tue Jul 31 19:23:45 2012 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 AC3FB21F8548 for ; Tue, 31 Jul 2012 19:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNi2RLsyddHp for ; Tue, 31 Jul 2012 19:23:45 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id D7A0821F853E for ; Tue, 31 Jul 2012 19:23:44 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q712Nbnj088471; Tue, 31 Jul 2012 22:23:37 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208010223.q712Nbnj088471@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Tue, 31 Jul 2012 13:42:46 EDT." <1314.1343756566@obiwan.sandelman.ca> Date: Tue, 31 Jul 2012 22:23:37 -0400 Cc: Kerry Lynn , homenet@ietf.org Subject: Re: [homenet] how to bookmark .lan, /.home, /.my-homenet when not home X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 02:23:45 -0000 In message <1314.1343756566@obiwan.sandelman.ca> Michael Richardson writes: > >>>>> "Kerry" == Kerry Lynn writes: > >> When I'm at your house, and I visit "fridge.local", do I get your > >> fridge, or mine? > > Kerry> Mine, by definition. Given that I'm not sure how you mean > Kerry> ".homenet" > Kerry> to work by comparison, I'm not sure I completely understand > Kerry> the rest > Kerry> of the discussion. > > Yes, I agree that when I lookup "fridge.local", I'll get yours. > *unless* the mapping to a GUA is still in my browser's cache... > > (I deleted a realistic situation for my smartphone talking to my stove > to find out when the roast is done) > > So what I'm after is a way for the fridge to say, when I lookup > "fridge.local" that it's GUA is 2001::F001 (mDNS can already do this), > but also that it's unicast DNS name is fridge.kerlyn.com. Regular DNS can do that too. :-) [btw - this wasn't dyndns] host fridge fridge.ipv6.occnc.com has IPv6 address 2001:470:1f07:1545::4:f00d That only works because ipv6.occnc.com is in my search path. In the prior example I gave if sitelocal was in my search path and there was no DNS name given to my zone, then I'd get fridge.sitelocal. If OTOH a provider gave me curtis.site.myprovider.evil then I'd get fridge.curtis.site.myprovider.evil in response to a "host fridge" command. That is because the provider would put curtis.site.myprovider.evil in the domain and search response in DHCP and the router would pass it along. [btw- I don't have a ISP provided email (that I know of) and I doubt "curtis" is not taken, however the contact email for them is curtis@occnc.com.] > Kerry> If you are remotely accessing resources in your home, you > Kerry> are probably > Kerry> more advanced than 99% of all home network users. Why wouldn't the > Kerry> solution you use on the road apply equally well at your > Kerry> neighbor's house? > > Kerry, the point of end-to-end connectivity into the home is to permit > the things that us "1%" do, to be doable by everyone... Right? Exactly. > So, yes, dyndns is *a* solution, but I don't know how to automate it in > a scalable way. I'm concerned that for the homenet protocols to be > incrementally deployable ("create value") that we can not rely too much > on the ISPs doing the right thing for forward DNS delegation. The dyndns would be localized to the site. The provider just delegates a name to use that is a subdomain of their own, or as I suggested in an earlier email, perhaps of the form .site.. That would be completely static and set up at customer service setup and never changed. At worst, the customer could opt not to use it or have equipment that can't make use of it. A provider run DNS secondary would similarly just be statically configured. Today the customer is given a dynamic address (unless explicitly asking for and paying for a single static address). That is because IPv4 addresses are in short supply. IPv6 /64 prefixes are not is short supply, therefore a provider supporting IPv6 native (or tunnels) could easily offer a static /64 reserved when the customer service is initially setup and never changed until the customer leaves. This is two things configured on the provider side when the customer is setup and never touched until the customer leaves. That is not a large burden on the provider dns ops staff. > Kerry> I think defining new "zones" under .arpa. may have merit in > Kerry> the following > Kerry> respect: ICANN is now in the business of selling dotless > Kerry> domain names. > > Just to be clear: my idea isn't that IETF run a dyndns under arpa, but > that we have a WKN under arpa which is treated specially. The homenet.arpa subdomain adds nothing IMHO. If the provider is completely non-cooperative in all ways except basic IPv6 connectivity and granting a /64 via DHCP or statically configured on provider owned CPE, then the customer simply gets fridge.sitelocal and can't access his own fridge from the neighbor's house. > I understand that my idea is hard to evaluate without a document. > Should I write one then? Could you summarize in an outline what you would put in that document? Curtis From curtis@occnc.com Tue Jul 31 19:48:14 2012 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 C74E321F8855 for ; Tue, 31 Jul 2012 19:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.865 X-Spam-Level: X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 tests=[AWL=-3.435, BAYES_00=-2.599, MANGLED_HOME=2.3, MANGLED_REGSTR=2.3, MANGLED_TIME=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxkEPan5w259 for ; Tue, 31 Jul 2012 19:48:14 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 2551921F884F for ; Tue, 31 Jul 2012 19:48:14 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q712m9st088743; Tue, 31 Jul 2012 22:48:09 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208010248.q712m9st088743@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Tue, 31 Jul 2012 14:19:05 EDT." <7732.1343758745@obiwan.sandelman.ca> Date: Tue, 31 Jul 2012 22:48:09 -0400 Cc: homenet@ietf.org Subject: Re: [homenet] how to bookmark .lan, /.home, /.my-homenet when not home X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 02:48:14 -0000 In message <7732.1343758745@obiwan.sandelman.ca> Michael Richardson writes: > >>>>> "Curtis" =3D=3D Curtis Villamizar writes: > Curtis> The issue is what happens when *my* fridge is not on the same h= > ome > Curtis> subnet as *my* home computer. (Sustituting a more realistic ex= > ample, > Curtis> like thermostats, water heater, alarm system, etc, where temp/t= > ime > Curtis> profiles might be altered, but we'll stick with the fridge > Curtis> example). > > this is an issue, and we have some proposals to solve this. > > It's not the issue that I'm talking about. I'm saying that I want to > leverage the sitelocal host discovery protocol to also discover a global > name for the host. I'm suggeting that an application (e.g. browser, > cups, etc.) on a mobile device should never (by default) actually > bookmark "fridge.local", because it's not globally meaningful. > > Curtis> A separate issue is how to address the fridge from a computer a= > t work > Curtis> or a mobile phone where clearly neither are on the same site. = > Here a > Curtis> domain name has to be assigned and most likely something of the= > form > Curtis> . if there is not going to be a regis= > tration > Curtis> fee. The subdomain might be the same as the email address prov= > ided by > Curtis> most home providers or .site.. At worst = > the > Curtis> mobile phone would need to have .site. in= > the > Curtis> DNS search path so "fridge" can be resolved. > > Curtis> The sitelocal name then only serves a purpose when the site is = > not > Curtis> connected to the provider and doesn't know its domain name. > > It's not a hard problem, technically (layer 1-7) > It's a hard layer 8/9 problem, and I'm suggesting that maybe we need to > think about whether there are layer-5/6/7 things that we can do as we > are specifying the sitelocal discovery process to ease the layer 8/9 > problem. > > > =2D-=20 > Michael Richardson , Sandelman Software Works=20 Getting sitelocal allocated should be no more difficult than getting local allocated. It is a TLD that does not resolve globally but does resolve differently at each site. It can be used in the absense of a DNS domain. It can also be used in the absense of IETF action and in the absense of provider cooperation because no one can stop you. :-) But I'm not advocating doing that. host fridge.sitelocal fridge.sitelocal is an alias for fridge.ipv6.occnc.com. fridge.ipv6.occnc.com has IPv6 address 2001:470:1f07:1545::4:f00d [ :-) no cooperation from IETF or from my provider required and no harm done. I could have made it an AAAA record rather than a CNAME. To see this you need to direct queries at my name server. fridge.sitelocal is entirely local. fridge.ipv6.occnc.com is in the global DNS. Please don't try to ping6 my fridge. It won't answer. ] Curtis From curtis@occnc.com Tue Jul 31 20:33:53 2012 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 42CD721F85D5 for ; Tue, 31 Jul 2012 20:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u78tPVwOLmeJ for ; Tue, 31 Jul 2012 20:33:52 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA4621F85CE for ; Tue, 31 Jul 2012 20:33:51 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q713XjUb089327; Tue, 31 Jul 2012 23:33:45 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208010333.q713XjUb089327@gateway.ipv6.occnc.com> To: Brian E Carpenter From: Curtis Villamizar In-reply-to: Your message of "Tue, 31 Jul 2012 18:47:08 BST." <50181A1C.5050803@gmail.com> Date: Tue, 31 Jul 2012 23:33:45 -0400 Cc: Michael Richardson , homenet@ietf.org Subject: Re: [homenet] section 3.2.2.1 of homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 03:33:53 -0000 In message <50181A1C.5050803@gmail.com> Brian E Carpenter writes: > On 31/07/2012 17:59, Michael Richardson wrote: > >>>>>> "Brian" == Brian E Carpenter writes: > > >> I'm also surprised that we think we have to cope with flash renumbering > > >> as a regular event, rather than a service-interrupting, ISP truck roll > > >> catastrophy. > > > > Brian> But every time you reboot your antiquated v4-only CPE > > Brian> and/or the antiquated > > Brian> v4-only PCs behind it, the PCs all get new IP addresses, > > Brian> which may or > > Brian> may not be the same as the previous time. There's nothing > > Brian> new in flash > > Brian> renumbering for homenets. Not handling this would be a step > > Brian> backwards. > > > > Well... > > > > 1) sure, but the *customer* does this, not the ISP. > > 2) the clients do have DHCP leases, and if they ask to renew their > > previous IP, it usually gets honored. > > It doesn't matter whether it's the user or the ISP that triggers a > change, does it? > > The point is, users don't care about this, except if they reach their > shiny new wireless printer via its IP static address. There are > definitely parts of draft-ietf-6renum-static-problem that apply here. > > Brian Brian, Enterprise renumbering and homenet renumbering are generally quite different. Most homehets have short uptimes. Most enterprises have very long uptimes. (insert favorite Microsoft reliability joke here). If a renumbering is done right, there is an time when both the old and new numbers are in use. As in "ifconfig inet6 newaddr ... alias" in the *ix world. During that transition time any use of DHCP will hand out the new address. Then comes a time when the leases refuse to be renewed. Then the old addresses go away. This can be day, weeks, or longer depending on the size of the transition. During that time a lot of "please reboot at least once ..." messages get sent. Today there is no DHCP help in avoiding the "please reboot" messages. It should be possible for a DHCP client (ISC guys, are you out there?) to do the following if a lease can't be renew and a new address is provided: 1. Add the new address using an "ifconfig ... alias" equivalent. 2. Check (using netstat -an equivalent) for use of the old address. Don't delete the old address if a socket still exists. 3. Periodically repeat step 2 until there is no connection using the old address. 4. Delete the old address using the equivalent of "ifconfig ... -alias". This would work for all client side connects that either were done before the end of the transition period. For home nets this covers 99.something percent of the sites with no user intervention or reboot. This requires no protocol change, just better coding in the DHCP client software. What this does not cover is a service that is listenning on a well known port. This is rare among home nets (except for homes of readers of IETF lists) but very common among enterprises. Many points made about license servers, etc in draft-ietf-6renum-static-problem don't apply to home nets. Renumbering an enterprise is doable. Renumbering my home net has been quite easy. I've done it a few times already and I'm sure will have to again. The procedure suggested above is just done manually. One hint is that on BSD and Linux at least a "netstat -an" should reveal any listens on old addresses. An automated scan on an enterprise network can identify servers and services needing a reconfig and a service restart without any system reboot. [ Microsoft systems may need to reboot or power down and remove the CMOS battery from the motherboard or maybe buy new hardware. :-) ] > > > > In IPv6 space, the host part will generally stay the same (modulo > > privacy extensions, which are default on for some clients). We've said > > that the ULA ought to stay the same, so in fact, I agree, the internal > > addresses actually all stay the same. > > > > I'm still surprised that an ISP will need to flash renumber faster than > > it can just expire leases. If it's just repartitioning of network to > > deal with growth, that ought to be predictable and prefix lifetimes can > > be reduced in advance. > > > > If it's actually some equipment failing, resulting in service > > interruptions, and then restoration by rewiring the network... then I > > understand. From curtis@occnc.com Tue Jul 31 20:47:51 2012 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 83E6C21F876F for ; Tue, 31 Jul 2012 20:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aG+9HroMZVM for ; Tue, 31 Jul 2012 20:47:50 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 93BFE21F8750 for ; Tue, 31 Jul 2012 20:47:50 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q713lkGj089475; Tue, 31 Jul 2012 23:47:46 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208010347.q713lkGj089475@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Tue, 31 Jul 2012 16:29:02 EDT." <29762.1343766542@obiwan.sandelman.ca> Date: Tue, 31 Jul 2012 23:47:46 -0400 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 03:47:51 -0000 In message <29762.1343766542@obiwan.sandelman.ca> Michael Richardson writes: > > >>>>> "Ted" =3D=3D Ted Lemon writes: > Ted> You secondary a zone so that the contents of the zone will be > Ted> there when a query happens, but why would a query happen if the > Ted> CPE device isn't reachable? What would trigger that query? > Ted> So I think you can get away with _not_ secondarying the zone. > Ted> But if you do want to secondary it, why would the ISP be > Ted> responsible for that? Presumably the customer is pretty > Ted> savvy; a secondary for their reverse tree would just be another > Ted> service they'd want to buy or set up, and the ISP could wash > Ted> their hands of it or sell it, whichever they chose.=20 > > My suggestion is that the ISP secondary the zone from the CPE, but > actually advertise only their server in the NS delegation. (The CPE > remains a stealth primary) > > The CPE will have multiple addresses, usually at least two, as it has at > least two interfaces. The CPE address which the ISP most knows about > and is most easily reachable is the outside address (the ISP facing > one). That address, if auto-configured, could trivially change if > the CPE is replaced (or replugged into a different port), or if the CPE > used privacy extensions. So we'll need a low TTL on that NS/AAAA > record. > > If we use the internal address from the CPE, which is likely in the > prefix that was delegated, and therefore very unlikely to change (and I > think some people have even proposed to make the host part well-known!), > it is possibly more stable, but it instantly introduces an exception to > the CPE firewall rules. > > Out of these two choices, neither is particularly bad, but as you > indicated, when the customer is down, the data is inaccessible. > > If the ISP has a copy (and might keep some history of it), then the ISP > is in a position to indicate to the customer what host is what. > Consider an ISP that has detected a home system infected with some > malware. Said ISP has either quaranteed or has disconnected that > customer. Customer will not understand > "host 2001:DB8:0001:1234:0234:45fe:ff01:4567 is infected" > > but, might understand: > "host suzie-derkins is infected" > > this could also be done if the ISP actually recorded the mapping from > ..:4567->susie-derkins at the time the event occured, and maybe that's > really the answer here. The ISP is not doing dyndns, the CPE router is doing that and the provider is secondary to that zone. The zone should have a short TTL (less than lease duration) and a long expire time to make it likely that the secondary is giving accurate answers and keeps giving answers for a while after the primary has gone away. > I'm thinking that ISPs might want to have more control over what's in > the reverse. (I don't really like that myself, but...) But not the forward? If the forward is ..site. -> and the reverse is .arpa -> ..site., why is one OK and the other not OK. > Perhaps there are privacy concerns if the ISP has this mapping recorded, > and it would be better if the CPE was the only place with the info. If its published in global DNS, recording it should not be a privacy concern. > Michael Richardson , Sandelman Software Works=20 > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ Curtis From curtis@occnc.com Tue Jul 31 21:01:08 2012 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 EFC7A21F8504 for ; Tue, 31 Jul 2012 21:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fHXSpPlWVVl for ; Tue, 31 Jul 2012 21:01:08 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 367F821F84F5 for ; Tue, 31 Jul 2012 21:01:08 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q71414Kw089743; Wed, 1 Aug 2012 00:01:04 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208010401.q71414Kw089743@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Tue, 31 Jul 2012 16:54:54 EDT." <2034.1343768094@obiwan.sandelman.ca> Date: Wed, 01 Aug 2012 00:01:04 -0400 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 04:01:09 -0000 In message <2034.1343768094@obiwan.sandelman.ca> Michael Richardson writes: > >>>>> "Curtis" =3D=3D Curtis Villamizar writes: > Curtis> Every log file that tries to record host names becomes much more > Curtis> readable if it is successful in recording host names than if it > Curtis> records IP addresses. In some cases for performance reasons the log > Curtis> files have to record IP addresses, but that would not be expected to > Curtis> be the case for home use. It is even worse if the log files record IP > Curtis> addresses and the person reading the logs has no reverse > Curtis> map. > > the machines recording the addresses/names are not in the home. > They are the web servers that the home user talks to. Yes. I know that. Or a mail server, etc none of which is not in the home. If a problem is reported to the home user, then having a mapping of address in the logs to host name would be a real good idea. http logs on heavily loaded servers always record just the IP address because the overhead of the rDNS lookups is too high. I mentioned that in prior email. Very rarely is an end customer ever contacted, except perhaps an automated mail from postmaster on an email server or a rare note from a provider saying their host is compromised and is attacking others. > Michael Richardson , Sandelman Software Works=20 > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ Curtis From curtis@occnc.com Tue Jul 31 21:09:34 2012 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 B157621F858A for ; Tue, 31 Jul 2012 21:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+1fETPRUniL for ; Tue, 31 Jul 2012 21:09:34 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id EE18121F8585 for ; Tue, 31 Jul 2012 21:09:33 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q7149T5J089788; Wed, 1 Aug 2012 00:09:29 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208010409.q7149T5J089788@gateway.ipv6.occnc.com> To: "Howard, Lee" From: Curtis Villamizar In-reply-to: Your message of "Tue, 31 Jul 2012 16:36:04 EDT." Date: Wed, 01 Aug 2012 00:09:29 -0400 Cc: Michael Richardson , "homenet@ietf.org Group" Subject: Re: [homenet] Reverse DNS X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 04:09:34 -0000 In message "Howard, Lee" writes: > > > On 7/31/12 1:29 PM, "Michael Richardson" wrote: > > > > >>>>>> "Ted" == Ted Lemon writes: > > Ted> You secondary a zone so that the contents of the zone will be > > Ted> there when a query happens, but why would a query happen if the > > Ted> CPE device isn't reachable? What would trigger that query? > > Ted> So I think you can get away with _not_ secondarying the zone. > > Ted> But if you do want to secondary it, why would the ISP be > > Ted> responsible for that? Presumably the customer is pretty > > Ted> savvy; a secondary for their reverse tree would just be another > > Ted> service they'd want to buy or set up, and the ISP could wash > > Ted> their hands of it or sell it, whichever they chose. > > > >My suggestion is that the ISP secondary the zone from the CPE, but > >actually advertise only their server in the NS delegation. (The CPE > >remains a stealth primary) > > I need to see an internet-draft problem statement. I still don't believe > there is one, and I have no plans to provide IPv6 reverse DNS for > residential subscribers. Any ISPs planning to do this? > > Lee Lee, IMO IPv4 residential customer use is different than IPv6 use. With IPv4 residential customers the only externally visible address is the address of the NAT and that is dynamically allocated. For IPv6 residential customers there is no reason not to statically allocate a /64. Each host can have a persistant globally routable IPv6 address and then rDNS starts to make sense. btw- How about SoHo customers and small business customers paying more for their service and demanding static addresses? Curtis > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, [ ...] redirect to /dev/null please. From curtis@occnc.com Tue Jul 31 21:48:13 2012 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 6B20E21F86D5 for ; Tue, 31 Jul 2012 21:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UFocBvJu6K6 for ; Tue, 31 Jul 2012 21:48:12 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD4E21F86D3 for ; Tue, 31 Jul 2012 21:48:12 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q714m8KI091107; Wed, 1 Aug 2012 00:48:08 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> To: Michael Thomas From: Curtis Villamizar In-reply-to: Your message of "Tue, 31 Jul 2012 19:04:32 PDT." <50188EB0.2040008@mtcc.com> Date: Wed, 01 Aug 2012 00:48:08 -0400 Cc: "" Subject: Re: [homenet] tunnels as way to disambiguate .local X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 04:48:13 -0000 In message <50188EB0.2040008@mtcc.com> Michael Thomas writes: > Since I apparently got a few heads shaking today from my jabber > comment, I guess I should at least throw it on the list. > > My observation -- and I'm not necessarily saying it's a [good] > solution -- is that one way that we could deal with the ambiguity of > what fridge.local[site] means when I elsewhere is to say that > .local[site] is exactly what it says it is: a property of the local > site. As such, if I'm roaming and do not have topological > connectivity, the proper way to get that connectivity would be to use > some form of tunneling back to the .local[site] I actually intended > and thus be part of the .local[site] topology again. > > On the plus side, this puts it into the hands of somebody to deal with > the ambiguity. On the minus side, this puts it into the hands of > somebody to deal with the ambiguity. > > Mike For a mobile device, including a laptop, sitelocal should reflect where you are. In someone else's house, printer.sitelocal should be their printer. If that someone else gives you authentication credentials or you give then a public key and they install it on the printer, then you can print. Today, more likely the home printer is USB and you plug it in to your laptop. Getting to your own fridge or printer from elsewhere would require that you have a domain name and know what your domain name is. Presumably you'd already have whatever you need for authentication. There is no ambiguity. It is a personal choice whether you want to put sitelocal first in the search path or your own domain first. I suggest that your own domain would be a better choice. fridge means the same thing no matter where you are. fridge.sitelocal means the fridge near you if you are elsewhere. fridge.sitelocal. is a FQDN with site local scope. fridge.yourdomain is a FQDN with global scope. Curtis From curtis@occnc.com Tue Jul 31 22:02:28 2012 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 EBE0521F854A for ; Tue, 31 Jul 2012 22:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Azk0JCAdgfoq for ; Tue, 31 Jul 2012 22:02:27 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id D7F8D21F8751 for ; Tue, 31 Jul 2012 22:02:26 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q71520uN092382; Wed, 1 Aug 2012 01:02:00 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208010502.q71520uN092382@gateway.ipv6.occnc.com> To: curtis@occnc.com From: Curtis Villamizar In-reply-to: Your message of "Wed, 01 Aug 2012 00:48:08 EDT." <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> Date: Wed, 01 Aug 2012 01:02:00 -0400 Cc: "" , Michael Thomas Subject: Re: [homenet] tunnels as way to disambiguate .local X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 05:02:29 -0000 Correction. A mobile device on the a site's wireless LAN would see fridge.sitelocal. The cellular provider would be better off just populating sitelocal with any services offerred by the cellular provider, such as mediadownload.sitelocal or ntp.sitelocal (unlikely, but hopeful). Sitelocal might be problematic for a mobile phone in a fast moving car on a highway through an urban area. Sitelocal would change with each cell tower handoff. Curtis In message <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> Curtis Villamizar writes: In message <50188EB0.2040008@mtcc.com> Michael Thomas writes: > Since I apparently got a few heads shaking today from my jabber > comment, I guess I should at least throw it on the list. > > My observation -- and I'm not necessarily saying it's a [good] > solution -- is that one way that we could deal with the ambiguity of > what fridge.local[site] means when I elsewhere is to say that > .local[site] is exactly what it says it is: a property of the local > site. As such, if I'm roaming and do not have topological > connectivity, the proper way to get that connectivity would be to use > some form of tunneling back to the .local[site] I actually intended > and thus be part of the .local[site] topology again. > > On the plus side, this puts it into the hands of somebody to deal with > the ambiguity. On the minus side, this puts it into the hands of > somebody to deal with the ambiguity. > > Mike For a mobile device, including a laptop, sitelocal should reflect where you are. In someone else's house, printer.sitelocal should be their printer. If that someone else gives you authentication credentials or you give then a public key and they install it on the printer, then you can print. Today, more likely the home printer is USB and you plug it in to your laptop. Getting to your own fridge or printer from elsewhere would require that you have a domain name and know what your domain name is. Presumably you'd already have whatever you need for authentication. There is no ambiguity. It is a personal choice whether you want to put sitelocal first in the search path or your own domain first. I suggest that your own domain would be a better choice. fridge means the same thing no matter where you are. fridge.sitelocal means the fridge near you if you are elsewhere. fridge.sitelocal. is a FQDN with site local scope. fridge.yourdomain is a FQDN with global scope. Curtis _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet