From brian.e.carpenter@gmail.com Wed Aug 1 00:17: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 7A5CF21F8687 for ; Wed, 1 Aug 2012 00:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.424 X-Spam-Level: X-Spam-Status: No, score=-101.424 tagged_above=-999 required=5 tests=[AWL=0.267, 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 Ac-DaBzm8Lbb for ; Wed, 1 Aug 2012 00:17:34 -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 64F8F21F867E for ; Wed, 1 Aug 2012 00:17:34 -0700 (PDT) Received: by wgbfm10 with SMTP id fm10so4005996wgb.1 for ; Wed, 01 Aug 2012 00:17:33 -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=6OOAf0ZK0ASnZQj9LqqySV6dpd+ZCqQTsnDzPacaHMk=; b=dMVtK+P09IF2yCU7+7FdlidCCu0gCpLUXEyK5PfKD6JAPeuBpkVYT0PFG5wEoGmRqn lF+G8R56RujnN1QRfs8XDkx5I26TmpxhZjbqxXtpb5Zxa0naReDUzdtcdyfqR98UuxpC 6ZOQhrgS17zA3Uf00ybxNKRa3eEufxtG67YA1dy40u18QGzOkXZ3VX45w7/Glj/15OGJ RntY9nrj+0+9p6GuoAHCgWNDq75d5wL0yCNNOb0PLCdJV+yy3vxON2XpQJBISBBg9wql uCi8G8M2Vuxpa9W939KS7SyGVeNn5hK5pPRPnuiUaGu/WQLyG83dlpsfKZfM02j6HnGh ausg== Received: by 10.180.109.166 with SMTP id ht6mr14054186wib.11.1343805453516; Wed, 01 Aug 2012 00:17:33 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-65.as13285.net. [2.102.218.65]) by mx.google.com with ESMTPS id bc2sm6657386wib.0.2012.08.01.00.17.32 (version=SSLv3 cipher=OTHER); Wed, 01 Aug 2012 00:17:32 -0700 (PDT) Message-ID: <5018D80C.90705@gmail.com> Date: Wed, 01 Aug 2012 08:17:32 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: curtis@occnc.com References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> In-Reply-To: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [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 07:17:35 -0000 On 01/08/2012 05:48, Curtis Villamizar wrote: ... > fridge.sitelocal. is a FQDN with site local scope. And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil. IMHO we shouldn't be discussing how to make it work less badly; we should be discussing how to avoid it entirely. Brian From brian.e.carpenter@gmail.com Wed Aug 1 00:41: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 168C221F8694 for ; Wed, 1 Aug 2012 00:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.428 X-Spam-Level: X-Spam-Status: No, score=-101.428 tagged_above=-999 required=5 tests=[AWL=0.263, 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 XrO-aTmiqyGm for ; Wed, 1 Aug 2012 00:40:59 -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 E807721F8686 for ; Wed, 1 Aug 2012 00:40:56 -0700 (PDT) Received: by eekb45 with SMTP id b45so1833516eek.31 for ; Wed, 01 Aug 2012 00:40:55 -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=JB8RU90Mr2qPZv612nVlVjG3Cv13hVK5dPIOBYj1gzA=; b=hXIeOyFrUwK6OI3u3Yo7ixufFoUOw2w8kxZNPd7HC6gW8VYr87aRbDorqqunvzDOlC oV/z28mGGUXDUOffXSCT9Sa4zvRgDPpVSX/hFE7Sr5Wyg31h+BN2yazO2q/l51Pi7api ImhmN6Q16qEgISJgnH6qlqkaLMjK19r3ZkkDt5GsfQfTc8mJEpNmUEUw8wmNuwMRp9VQ laJQ0Tf/YXNbFdDCmHgw6PInV2yp2bJ3uvRHViM7aC8hNSqzKgOh1ObzfHstk4YLpu5D BQe/ZMo9btvHnngxRYv2Jz452CayE5N9WHhWh2Abk9i1IpiqFqzsjBte/AeiuT8AsLZD STOQ== Received: by 10.14.216.198 with SMTP id g46mr13924345eep.32.1343806855589; Wed, 01 Aug 2012 00:40:55 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-65.as13285.net. [2.102.218.65]) by mx.google.com with ESMTPS id t6sm6361289eeo.17.2012.08.01.00.40.53 (version=SSLv3 cipher=OTHER); Wed, 01 Aug 2012 00:40:54 -0700 (PDT) Message-ID: <5018DD8A.2070900@gmail.com> Date: Wed, 01 Aug 2012 08:40:58 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: curtis@occnc.com References: <201208010333.q713XjUb089327@gateway.ipv6.occnc.com> In-Reply-To: <201208010333.q713XjUb089327@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 07:41:00 -0000 Excuse front posting, but... > Today there is no DHCP help in avoiding the "please reboot" messages. Don't RECONFIGURE (DHCPv6) and FORCERENEW (DHCP) cover this, in theory? They are unicast, which is a scaling issue in enterprise networks but presumably not in homenets. Regards Brian On 01/08/2012 04:33, Curtis Villamizar wrote: > 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 wouter.cloetens@softathome.com Wed Aug 1 00:42: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 4D62B21F86D1 for ; Wed, 1 Aug 2012 00:42:06 -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 WixWznr99Gpv for ; Wed, 1 Aug 2012 00:42:05 -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 BC12521F86C6 for ; Wed, 1 Aug 2012 00:42:05 -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 1SwTZE-0002Ld-BK for homenet@ietf.org; Wed, 01 Aug 2012 09:42:04 +0200 Message-ID: <5018DDCA.1010702@softathome.com> Date: Wed, 01 Aug 2012 09:42:02 +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: <201208010126.q711Q8sQ087703@gateway.ipv6.occnc.com> In-Reply-To: <201208010126.q711Q8sQ087703@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: Wed, 01 Aug 2012 07:42:06 -0000 On 01/08/12 03:26, Curtis Villamizar wrote: > Anything DNS related should be reliable. Therefore a secondary would > be preferable to not having one. OTOH, the use case of a DNS lookup for a hostname or IP address for which the last-hop router is offline (at the time of the lookup) is limited. It is there; e.g. batch log processing on web servers, but that is for informative purposes only, and doesn't cause connection failures. From brian.e.carpenter@gmail.com Wed Aug 1 00:48: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 6D5F521F86D3 for ; Wed, 1 Aug 2012 00:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.431 X-Spam-Level: X-Spam-Status: No, score=-101.431 tagged_above=-999 required=5 tests=[AWL=0.260, 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 GXZWOBJRw42a for ; Wed, 1 Aug 2012 00:48: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 AD58621F867E for ; Wed, 1 Aug 2012 00:48:44 -0700 (PDT) Received: by eaaa11 with SMTP id a11so1683825eaa.31 for ; Wed, 01 Aug 2012 00:48:43 -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=8O87tt2rxOep5b8+vIDJkVOjmYk/mZs+pdT3zkuFTHs=; b=H/9OC74SpcTt2IRCqld53VNA+CVkLWKzHuSyYuTA0gxUwPheii11jHaz8GE4uWAmqB BQ+IaCvU3dIASXwejeYfKBBodhP2awgP1i0t0cqLZ2nzl49lmQMHySXAULMCFWYKOPhw XR30pyoSFGCrnjcZJRkMGunF1DavNlqg/XE+rUPic3YA3j+TJmqtvKgIzE5STTlBJ0ww +fdniLG0oESmm+BpH0NMmd7T33bhqrtCf1RDQrcw1AbCvw0Om+QPJ7tLS6ClpqnzskGW 4OMKJ/+iWlo46h9UnCH85mS7N/I7xeKWYyNnWSmzAoYKUo4UmkfMKvhO2YHKklbPxbmX 4VHA== Received: by 10.14.210.194 with SMTP id u42mr21452702eeo.11.1343807323879; Wed, 01 Aug 2012 00:48:43 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-65.as13285.net. [2.102.218.65]) by mx.google.com with ESMTPS id t6sm6415552eeo.17.2012.08.01.00.48.42 (version=SSLv3 cipher=OTHER); Wed, 01 Aug 2012 00:48:43 -0700 (PDT) Message-ID: <5018DF5E.6040904@gmail.com> Date: Wed, 01 Aug 2012 08:48:46 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: curtis@occnc.com References: <201207312145.q6VLj24S084224@gateway.ipv6.occnc.com> In-Reply-To: <201207312145.q6VLj24S084224@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, 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: Wed, 01 Aug 2012 07:48:45 -0000 On 31/07/2012 22:45, Curtis Villamizar wrote: > 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. That's true. My point was that the CPE resolver will have to be upgraded to support DNS64 for, and *only* for, IPv6-only hosts. How it knows which hosts are IPv6-only is another mystery. Brian From brian.e.carpenter@gmail.com Wed Aug 1 00:53: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 1A4AE21F85D6 for ; Wed, 1 Aug 2012 00:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.434 X-Spam-Level: X-Spam-Status: No, score=-101.434 tagged_above=-999 required=5 tests=[AWL=0.257, 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 frhtuI4+2B7b for ; Wed, 1 Aug 2012 00:53:51 -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 A02C021F8567 for ; Wed, 1 Aug 2012 00:53:44 -0700 (PDT) Received: by eaaa11 with SMTP id a11so1685515eaa.31 for ; Wed, 01 Aug 2012 00:53:43 -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=x7drq3wo8LBXZ5VrddRft1jOeXThJ8Gpdb9kQsRaCyc=; b=rDic7SHdkcULFLLDjoqw2M3PcomCeIF/JW51RTUZoowqy4eGKafl8mZMAjheKN+cOL +ESW3u6sXQMzGty1FuEpjgywjHL+Z+kCJkKBVdfFT/Ly9oCvpiOyaLkTLyPd51IALyTz GbQ0WvPmJqL1JGLMJUQ0546Fzj51+mRNsMsztjQTn7LN6KwnskUmN525K0I1LwygzpIL Xmd8k5NDrbOBFt3NXdPd0rNO+mgK3r9FK8QE08SCBYAtWLkpl0V69Yc2nGIxyK9xoHWA 7RmO4v44uKnTK5XICD+MsoGnFeHj9j/ta5f58vlo8/pHKG5lftZQt2c5QJiK1DSvB8o6 2z4Q== Received: by 10.14.220.193 with SMTP id o41mr21284929eep.27.1343807623865; Wed, 01 Aug 2012 00:53:43 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-65.as13285.net. [2.102.218.65]) by mx.google.com with ESMTPS id 7sm6526711eeb.3.2012.08.01.00.53.42 (version=SSLv3 cipher=OTHER); Wed, 01 Aug 2012 00:53:42 -0700 (PDT) Message-ID: <5018E08A.5070009@gmail.com> Date: Wed, 01 Aug 2012 08:53:46 +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> <50181A1C.5050803@gmail.com> <8399.1343758982@obiwan.sandelman.ca> In-Reply-To: <8399.1343758982@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: Wed, 01 Aug 2012 07:53:52 -0000 On 31/07/2012 19:23, Michael Richardson wrote: >>>>>> "Brian" == 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 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. > > 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?) I already mentioned RECONFIGURE (DHCPv6) and FORCERENEW (DHCP). Whatever we adopt for prefix delegation needs the equivalent. > 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. Sure, except IMHO the printer should have an unambiguous FQDN and we need dynamic DNS updates, just in case. Brian From swmike@swm.pp.se Wed Aug 1 01:13: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 7E2EB21F8666 for ; Wed, 1 Aug 2012 01:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_13=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 9St9RL9Fvm2u for ; Wed, 1 Aug 2012 01:13:05 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id C81F821F866D for ; Wed, 1 Aug 2012 01:13:04 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8DC699F; Wed, 1 Aug 2012 10:13:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8911A9E for ; Wed, 1 Aug 2012 10:13:02 +0200 (CEST) Date: Wed, 1 Aug 2012 10:13:02 +0200 (CEST) From: Mikael Abrahamsson To: homenet@ietf.org In-Reply-To: <5018DF5E.6040904@gmail.com> Message-ID: References: <201207312145.q6VLj24S084224@gateway.ipv6.occnc.com> <5018DF5E.6040904@gmail.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 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: Wed, 01 Aug 2012 08:13:05 -0000 On Wed, 1 Aug 2012, Brian E Carpenter wrote: > That's true. My point was that the CPE resolver will have to be upgraded > to support DNS64 for, and *only* for, IPv6-only hosts. How it knows > which hosts are IPv6-only is another mystery. Indeed, I started a thread about this on v6ops the other day: Seems there is no solution to this problem and I'm seem to be having trouble getting traction there that this might actually be a real problem that needs solving. -- Mikael Abrahamsson email: swmike@swm.pp.se From marka@isc.org Wed Aug 1 01:20: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 CA43921F85E1 for ; Wed, 1 Aug 2012 01:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 4ajG6UO8plto for ; Wed, 1 Aug 2012 01:20:21 -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 AF3F821F85D5 for ; Wed, 1 Aug 2012 01:20:20 -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 8F50EC9569; Wed, 1 Aug 2012 08:20:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:64:909:bbc7:2ebb:ba74]) (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 46AF0216C3B; Wed, 1 Aug 2012 08:20:07 +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 25B4C23298EA; Wed, 1 Aug 2012 18:20:04 +1000 (EST) To: curtis@occnc.com From: Mark Andrews References: <201208010333.q713XjUb089327@gateway.ipv6.occnc.com> In-reply-to: Your message of "Tue, 31 Jul 2012 23:33:45 -0400." <201208010333.q713XjUb089327@gateway.ipv6.occnc.com> Date: Wed, 01 Aug 2012 18:20:04 +1000 Message-Id: <20120801082004.25B4C23298EA@drugs.dv.isc.org> 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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 08:20:21 -0000 In message <201208010333.q713XjUb089327@gateway.ipv6.occnc.com>, Curtis Villamizar writes: > > 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). Define short? There are plenty of homes with equipment that isn't powered down every day and that has been up for months. I don't know about other but I maintain ssh connections for weeks from home to the main office at work. > 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. What's the dhcp stuff in the home? RA's work fine here. What is needed is a way to signal in the DNS to only use a deprecated address as a last resort measure. Named to address and address to name mappings need to exist until after the address has ceased being used. > 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". Actually you should be asking the OS vendors / distro maintainers to do this and send fixes to ISC. This is all done in shell scripts that are highly customised to the client platform. There isn't one linux script that works for all linux distros. This also doesn't work for many udp based services. > 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. At the moment. There is no good reason to not be listening on standard ports if you want to provide your own servers within the home. DNS will almost certainly be done if only to as hidden masters. Just publish your current addresses in the DNS and they can be reached. Cable and DSL are always on services. Homes are no longer dialup. > 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. > _______________________________________________ > 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 marka@isc.org Wed Aug 1 07:13: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 0406A21F8B70 for ; Wed, 1 Aug 2012 07:13:36 -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 KYdTOo0Tu5-s for ; Wed, 1 Aug 2012 07:13:35 -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 7045021F8B6F for ; Wed, 1 Aug 2012 07:13:35 -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 3373AC9593; Wed, 1 Aug 2012 14:13:23 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:64:909:bbc7:2ebb:ba74]) (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 1E8FE216C36; Wed, 1 Aug 2012 14:13:23 +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 1B3C2232A2B2; Thu, 2 Aug 2012 00:13:22 +1000 (EST) To: Wouter Cloetens From: Mark Andrews References: <201208010126.q711Q8sQ087703@gateway.ipv6.occnc.com> <5018DDCA.1010702@softathome.com> In-reply-to: Your message of "Wed, 01 Aug 2012 09:42:02 +0200." <5018DDCA.1010702@softathome.com> Date: Thu, 02 Aug 2012 00:13:22 +1000 Message-Id: <20120801141322.1B3C2232A2B2@drugs.dv.isc.org> Cc: homenet@ietf.org 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 14:13:36 -0000 In message <5018DDCA.1010702@softathome.com>, Wouter Cloetens writes: > On 01/08/12 03:26, Curtis Villamizar wrote: > > Anything DNS related should be reliable. Therefore a secondary would > > be preferable to not having one. > > OTOH, the use case of a DNS lookup for a hostname or IP address for > which the last-hop router is offline (at the time of the lookup) is limited. > It is there; e.g. batch log processing on web servers, but that is for > informative purposes only, and doesn't cause connection failures. This is crazy talk. We have absolutely no idea what will or will not end up being run from the home. Whether people will need to lookup information about the home when it is unreachable or not. How do you debug if you can reach home or not if you can't get the addresses of the machines at home? The DNS was designed with the idea that there would be redundent servers. It is not designed to deal with not being able to connect to any servers for a zone and it really does not work well when this is the case. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From curtis@occnc.com Wed Aug 1 07:17: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 9A76B21F8CF6 for ; Wed, 1 Aug 2012 07:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.198, 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 St0RWl+XeXT8 for ; Wed, 1 Aug 2012 07:17: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 E62D421F8CF5 for ; Wed, 1 Aug 2012 07:17: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 q71EH60q004849; Wed, 1 Aug 2012 10:17:06 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208011417.q71EH60q004849@gateway.ipv6.occnc.com> To: Brian E Carpenter From: Curtis Villamizar In-reply-to: Your message of "Wed, 01 Aug 2012 08:17:32 BST." <5018D80C.90705@gmail.com> Date: Wed, 01 Aug 2012 10:17:06 -0400 Cc: homenet@ietf.org, curtis@occnc.com 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 14:17:34 -0000 In message <5018D80C.90705@gmail.com> Brian E Carpenter writes: > On 01/08/2012 05:48, Curtis Villamizar wrote: > ... > > fridge.sitelocal. is a FQDN with site local scope. > > And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil. > > IMHO we shouldn't be discussing how to make it work less badly; we should > be discussing how to avoid it entirely. > > Brian Brian, Not being connected to the Internet and not having any configuration at all might also be intrinsically evil, but that's the situation when a consumer takes some gadget out of the box. What we are trying to accomplish with the sitelocal is a way to name things on a local network that have no domain name assigned through a registry and have not had a domain name assigned as part of some subdomain of the provider. Even if the homenet WG was extremely thoroughthe gadget did 100% of what we specify and implemented everything perfectly, we can't control the user who almost never has a domain name of their own or the ISP that can't be bothered delegating some subdomain of theirs to a customer. The customer then has no global domain to hang names off of and has no choice but to not use DNS or make use of a sitelocal domain with site local scope. So sitelocal is inherently needed, either during a transition (until the uplink comes up at least for the first time and a domain name is learned) or permanently (if no domain name ever gets delegated to the residential customer site). Curtis ps - Yes - it is inherently evil. So is not delegating rDNS IMHO. But we can't control those MSO and ILEC residential ISPs. From brian.e.carpenter@gmail.com Wed Aug 1 07:26:49 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 3CB9621F8D6D for ; Wed, 1 Aug 2012 07:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.437 X-Spam-Level: X-Spam-Status: No, score=-101.437 tagged_above=-999 required=5 tests=[AWL=0.254, 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 1ANIYBefj5HR for ; Wed, 1 Aug 2012 07:26:48 -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 5E25A21F8D6C for ; Wed, 1 Aug 2012 07:26:48 -0700 (PDT) Received: by eekb45 with SMTP id b45so1984426eek.31 for ; Wed, 01 Aug 2012 07:26:47 -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=lqM1TZB9Eo4ydaHWH5VeZM8gSRCddWAsjbAfai/CSrI=; b=c/VGt2/mUhBO1EgDGpGMPyBTAij7cebGOFn4r7R2B7jrc2k1BaXNsuOj2CPPExu+ng 50kONuJgcj+LKKk12zlY2rktDpHFbEmw2NWoKOK5PgNar6ma+LojwhiAQMt6y5EV8h3H c6TYa9nj6wzoxE8KaI3BGPwnY7Y8wyoVXntO/yyxIvIq7fhWMJBeFL4Yz365rHfwh3/u a6+EpjHQD7Pqev2bwJfXXmeCDbxeNmcrRoZe59WVOecARRsZ8qQlDgjuuC5dmenAQl5s i9L+tnglqh6+8P1vJ3AL8FnKD1HJVQc2YSd0tkZRZKPpfKfh5ZWy8C5jDoXKolqMf3v+ 8ZCA== Received: by 10.14.173.71 with SMTP id u47mr22761783eel.22.1343831207465; Wed, 01 Aug 2012 07:26:47 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-65.as13285.net. [2.102.218.65]) by mx.google.com with ESMTPS id d48sm9352113eeo.10.2012.08.01.07.26.45 (version=SSLv3 cipher=OTHER); Wed, 01 Aug 2012 07:26:46 -0700 (PDT) Message-ID: <50193CAB.5070803@gmail.com> Date: Wed, 01 Aug 2012 15:26:51 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: curtis@occnc.com References: <201208011417.q71EH60q004849@gateway.ipv6.occnc.com> In-Reply-To: <201208011417.q71EH60q004849@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [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 14:26:49 -0000 Synthesise a pseudo-TLD from the ULA prefix. Brian On 01/08/2012 15:17, Curtis Villamizar wrote: > In message <5018D80C.90705@gmail.com> > Brian E Carpenter writes: > >> On 01/08/2012 05:48, Curtis Villamizar wrote: >> ... >>> fridge.sitelocal. is a FQDN with site local scope. >> >> And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil. >> >> IMHO we shouldn't be discussing how to make it work less badly; we should >> be discussing how to avoid it entirely. >> >> Brian > > > Brian, > > Not being connected to the Internet and not having any configuration > at all might also be intrinsically evil, but that's the situation when > a consumer takes some gadget out of the box. > > What we are trying to accomplish with the sitelocal is a way to name > things on a local network that have no domain name assigned through a > registry and have not had a domain name assigned as part of some > subdomain of the provider. > > Even if the homenet WG was extremely thoroughthe gadget did 100% of > what we specify and implemented everything perfectly, we can't control > the user who almost never has a domain name of their own or the ISP > that can't be bothered delegating some subdomain of theirs to a > customer. The customer then has no global domain to hang names off of > and has no choice but to not use DNS or make use of a sitelocal domain > with site local scope. > > So sitelocal is inherently needed, either during a transition (until > the uplink comes up at least for the first time and a domain name is > learned) or permanently (if no domain name ever gets delegated to the > residential customer site). > > Curtis > > > ps - Yes - it is inherently evil. So is not delegating rDNS IMHO. > But we can't control those MSO and ILEC residential ISPs. > From curtis@occnc.com Wed Aug 1 07:39: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 3AD6611E8100 for ; Wed, 1 Aug 2012 07:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.188, 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 Rn5Sce7vx6op for ; Wed, 1 Aug 2012 07:39:31 -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 BAAEB11E80D5 for ; Wed, 1 Aug 2012 07:39:30 -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 q71Ed183005154; Wed, 1 Aug 2012 10:39:01 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208011439.q71Ed183005154@gateway.ipv6.occnc.com> To: Brian E Carpenter From: Curtis Villamizar In-reply-to: Your message of "Wed, 01 Aug 2012 08:40:58 BST." <5018DD8A.2070900@gmail.com> Date: Wed, 01 Aug 2012 10:39:01 -0400 Cc: Michael Richardson , homenet@ietf.org, curtis@occnc.com 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 14:39:32 -0000 In message <5018DD8A.2070900@gmail.com> Brian E Carpenter writes: > Excuse front posting, but... > > > Today there is no DHCP help in avoiding the "please reboot" messages. > > Don't RECONFIGURE (DHCPv6) and FORCERENEW (DHCP) cover this, in theory? > They are unicast, which is a scaling issue in enterprise networks but > presumably not in homenets. > > Regards > Brian These only force a renew before the lease expires. For the sometimes very long IPv6 leases, this is essential. For often relatively shorter IPv4 leases, it is nice but not quite as essential. The issue is not forcing the renew to occur earlier, it is the way in which a renew that changes the address is handled. Maybe its just implementations taking a shortcut, but I think in practice changing the IP address takes the interface down, kills all connections, including listens, and then brings it back up with a new address. Its a bit like a reboot as implemented, except the user doesn't know its coming and therefore may have open TCP connections that break. What I've suggested is what to do on a renew that changes the address. Add an alias. Until the old address has no more connections or listens on the old address, keep the old address. Then remove the old address. If someone has an open connection, ssh for example, the old address could be in use indefinitely, but if the transition is weeks, then its unlikely to go beyond that. For example, if someone was using ssh to do a long compile on another machine, breaking the connection and killing the compile would be bad. There are certain to be plenty of other uses of long duration TCP connections that would have to be broken in this sort of transition, unless we can also extend TCP to negotiate a change to one side of the address pair. Curtis > On 01/08/2012 04:33, Curtis Villamizar wrote: > > 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 Wed Aug 1 07: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 CDE2C21F84F1 for ; Wed, 1 Aug 2012 07:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.180, 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 oxoPUP1X7Keo for ; Wed, 1 Aug 2012 07:45:02 -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 56F6A21F84C2 for ; Wed, 1 Aug 2012 07:45:00 -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 q71EiXbc005269; Wed, 1 Aug 2012 10:44:33 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208011444.q71EiXbc005269@gateway.ipv6.occnc.com> To: Brian E Carpenter From: Curtis Villamizar In-reply-to: Your message of "Wed, 01 Aug 2012 08:48:46 BST." <5018DF5E.6040904@gmail.com> Date: Wed, 01 Aug 2012 10:44:33 -0400 Cc: homenet@ietf.org, Michael Thomas , 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: Wed, 01 Aug 2012 14:45:04 -0000 In message <5018DF5E.6040904@gmail.com> Brian E Carpenter writes: > On 31/07/2012 22:45, Curtis Villamizar wrote: > > 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. > > That's true. My point was that the CPE resolver will have to be > upgraded to support DNS64 for, and *only* for, IPv6-only hosts. How it > knows which hosts are IPv6-only is another mystery. > > Brian Brian, I was responding to the question: > >> Having embedded DNS functionality in the CPE is sort of a newish > >> requirement, yes? Having DNS in the CPE is not a new requirement (at least in practice). Extending the requirement to include DNS64 is new. > How it knows which hosts are IPv6-only is another mystery. I'm not if favor of using IPv4 in IPv6 and then having a NAT to turn the IPv6 addresses into a single IPv4. I agree with a prior comment that this is complexity added with no significant gain. Curtis From wouter.cloetens@softathome.com Wed Aug 1 07:58: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 A0AB011E80DC for ; Wed, 1 Aug 2012 07:58:48 -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 9BQbd39ap-Nx for ; Wed, 1 Aug 2012 07:58:47 -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 D243B11E8097 for ; Wed, 1 Aug 2012 07:58:46 -0700 (PDT) Received: from [2001:470:d39b:1f80:67d:7bff:fe3a:49af] by e2big.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SwaNq-0002z2-8b; Wed, 01 Aug 2012 16:58:46 +0200 Message-ID: <50194422.6070702@softathome.com> Date: Wed, 01 Aug 2012 16:58:42 +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: Mark Andrews References: <201208010126.q711Q8sQ087703@gateway.ipv6.occnc.com> <5018DDCA.1010702@softathome.com> <20120801141322.1B3C2232A2B2@drugs.dv.isc.org> In-Reply-To: <20120801141322.1B3C2232A2B2@drugs.dv.isc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: homenet@ietf.org 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 14:58:48 -0000 On 01/08/12 16:13, Mark Andrews wrote: > In message<5018DDCA.1010702@softathome.com>, Wouter Cloetens writes: >> On 01/08/12 03:26, Curtis Villamizar wrote: >>> Anything DNS related should be reliable. Therefore a secondary would >>> be preferable to not having one. >> >> OTOH, the use case of a DNS lookup for a hostname or IP address for >> which the last-hop router is offline (at the time of the lookup) is limited. >> It is there; e.g. batch log processing on web servers, but that is for >> informative purposes only, and doesn't cause connection failures. > > This is crazy talk. We have absolutely no idea what will or will > not end up being run from the home. Whether people will need to > lookup information about the home when it is unreachable or not. > How do you debug if you can reach home or not if you can't get the > addresses of the machines at home? If you need to run a reliable service, you shouldn't be running it from your home. The use case of homenet is restricted to that. What you understand as "crazy talk," I see as; trying to get something working, in best-effort mode, taking into account the limitations of a home network with a CE router in front of it. We assume that a DynDNS-style approach simply will never scale for every IPv6 address in the home, and therefore the home router has to be authoritative, handling the requests. > The DNS was designed with the idea that there would be redundent > servers. It is not designed to deal with not being able to connect > to any servers for a zone and it really does not work well when > this is the case. If you *are* running a service from home, there is always the option of setting up DynDNS specifically for those hosts that need to be accessible. -- Architect Core Gateway SoftAtHome R&D RGW http://www.softathome.com/ http://www.linkedin.com/in/wcloetens Vaartdijk 3/B701, B-3018 Wijgmaal Tel: +32-16-852010 Mobile: +32-492-277790 Fax: +32-16-852099 This message and any attachments are confidential, intended solely for the addressees and are SoftAtHome’s ownership. Any unauthorized use or dissemination is prohibited. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. From curtis@occnc.com Wed Aug 1 08:18: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 2D45021F88FC for ; Wed, 1 Aug 2012 08:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.172, 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 JYozkKQdiTO9 for ; Wed, 1 Aug 2012 08:18:40 -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 B423D21F88A7 for ; Wed, 1 Aug 2012 08:18:39 -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 q71FI8iw005698; Wed, 1 Aug 2012 11:18:08 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208011518.q71FI8iw005698@gateway.ipv6.occnc.com> To: Mark Andrews From: Curtis Villamizar In-reply-to: Your message of "Wed, 01 Aug 2012 18:20:04 +1000." <20120801082004.25B4C23298EA@drugs.dv.isc.org> Date: Wed, 01 Aug 2012 11:18:08 -0400 Cc: Michael Richardson , homenet@ietf.org, curtis@occnc.com 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 15:18:41 -0000 In message <20120801082004.25B4C23298EA@drugs.dv.isc.org> Mark Andrews writes: > In message <201208010333.q713XjUb089327@gateway.ipv6.occnc.com>, Curtis Villamizar writes: > > > > 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). > > Define short? There are plenty of homes with equipment that isn't > powered down every day and that has been up for months. As long as the equipment is idle, an attempted renew on the DHCP lease that fails won't hurt unless it causes something to hang. Microsoft has trained users to be used to power cycling things for no apparent reason. > I don't know about other but I maintain ssh connections for weeks > from home to the main office at work. I've been know to do that. For long compiles I've learned to use "nohup" and keep a log file that I can check on now and then. > > 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. > > What's the dhcp stuff in the home? RA's work fine here. What is > needed is a way to signal in the DNS to only use a deprecated address > as a last resort measure. Named to address and address to name > mappings need to exist until after the address has ceased being > used. Below is what the CPE and host need to do. The provider also needs to keep around the old rDNS until the old address is no longer in use. The provider needs to 1) grant new leases from the new number space, 2) request that users force a renew themselves in case there would be any disruption, 3) allow time for users to force a renew, 4) force a renew and refuse torenew the old leases, granting new ones (may be disruptive to some), 4) allow more time, then completely get rid of the old address space. > > 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". > > Actually you should be asking the OS vendors / distro maintainers > to do this and send fixes to ISC. This is all done in shell scripts > that are highly customised to the client platform. There isn't one > linux script that works for all linux distros. > > This also doesn't work for many udp based services. You are right. There are other retained IP addresses. For example, a DNS secondary might try to renew a lease based on the old address until the primary name server DNS AAAA entry TTL expires. Perhaps a minimum time in which there is no use of the old address is necessary. Note that netstat -in on *ix reports statistics per alias so it is possible to detect when a specific address has gone idle for a long time, but there is no guarentee that it won't ever be used again. > > 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. > > At the moment. There is no good reason to not be listening on > standard ports if you want to provide your own servers within the > home. DNS will almost certainly be done if only to as hidden > masters. Just publish your current addresses in the DNS and they > can be reached. Cable and DSL are always on services. Homes are > no longer dialup. The CPE router may stay up but the hosts get shut down. The concern about changing addresses and breaking something is related more to the hosts (computers, set top box, etc). A SIP phone is a concern. A server can bind to 0/0 and ::/0. If some interfaces are to be excluded (or you run BSD jails), then services have to bind to addresses. Most of those services read the address from a configuration file and need a change to the configuration and may need to be nudged or restarted after the configuration change. A DNS server for example, may filter on many addresses in its config. Which nets to allow queries from, which to allow zone transfers to, where to find forwarders, etc. It should be easy enough to nudge or restart servers within the CPE when addresses change. It is less easy for the CPE to insure that the hosts have been successful in the address change. > > 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. > > _______________________________________________ > > 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 ajs@anvilwalrusden.com Wed Aug 1 08: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 8C6FC11E8091 for ; Wed, 1 Aug 2012 08:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 l97A58cO6FMJ for ; Wed, 1 Aug 2012 08:40:50 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB4221F89A1 for ; Wed, 1 Aug 2012 08:40:50 -0700 (PDT) Received: from mail.yitter.info (dhcp-473a.meeting.ietf.org [130.129.71.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 537F98A031 for ; Wed, 1 Aug 2012 15:40:48 +0000 (UTC) Date: Wed, 1 Aug 2012 11:40:45 -0400 From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20120801154044.GB32338@mail.yitter.info> References: <201208010126.q711Q8sQ087703@gateway.ipv6.occnc.com> <5018DDCA.1010702@softathome.com> <20120801141322.1B3C2232A2B2@drugs.dv.isc.org> <50194422.6070702@softathome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50194422.6070702@softathome.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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 15:40:51 -0000 On Wed, Aug 01, 2012 at 04:58:42PM +0200, Wouter Cloetens wrote: > We assume that a DynDNS-style approach simply will never scale for > every IPv6 address in the home, and therefore the home router has to > be authoritative, handling the requests. If I may ask, why do you make that assumption? I assure you that Dyn is running some very large zones with high change rates. Now, it might be that nobody would be willing to pay for such a service at the rate Dyn would charge to make this profitable, assuming large numbers of records and a high rate of change. If that's your argument, however, I'd like to know understand how this is going to be worth doing for someone else when Dyn already has the sunk investment in infrastructure. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From mike@mtcc.com Wed Aug 1 09:43:01 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 D965211E81C0 for ; Wed, 1 Aug 2012 09:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.712 X-Spam-Level: X-Spam-Status: No, score=-2.712 tagged_above=-999 required=5 tests=[AWL=-0.113, 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 U9u1OCwkbB+j for ; Wed, 1 Aug 2012 09:43:01 -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 D91E911E81BC for ; Wed, 1 Aug 2012 09:43:00 -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 q71Ggv5D003007 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 09:42:58 -0700 Message-ID: <50195C91.20500@mtcc.com> Date: Wed, 01 Aug 2012 09:42:57 -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: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <5018D80C.90705@gmail.com> In-Reply-To: <5018D80C.90705@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=1010; t=1343839378; x=1344703378; 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]=20tunnels=20as=20way=20to=20d isambiguate=20.local |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=3fEfNr0xCyrPqNHnK0ThVK+3YErYU2iuyr5Jop6gIiM=; b=ImGdmw1DPnc4qGYzphsYcI88PLIZsSIQ9+T8pQZwgphJgYpnqF+eR9jN0Y KrSzI3Hx3GfxxH8QBDDnKgLJ6Ouk0562pYL5s0YD+nOnfGkRNQGFTw780yja syUZc5G+aRF5KclodN6qWhmUM0N0OXcnw1ndkWefdNHz0jKFYiHC4=; 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, curtis@occnc.com Subject: Re: [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 16:43:02 -0000 On 08/01/2012 12:17 AM, Brian E Carpenter wrote: > On 01/08/2012 05:48, Curtis Villamizar wrote: > ... >> fridge.sitelocal. is a FQDN with site local scope. > And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil. > > IMHO we shouldn't be discussing how to make it work less badly; we should > be discussing how to avoid it entirely. > I think the implications of my note is that there really isn't anything that needs to be done here. If you want to use naming that requires that you be in some topology-defined boundary, then tunnel back to that network if you're not there. VPN technology is pretty well understood, after all, and there are probably a lot of reasons you might want to do that besides naming. That said, my interpretation of the requirements is that we want to do something with names such that they are quasi-global, or truly global. I'm inclined to agree that grafting those requirement onto .local is most likely the road to madness. Mike From mcr+ietf@sandelman.ca Wed Aug 1 09:52: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 DED1B11E8176 for ; Wed, 1 Aug 2012 09:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.861 X-Spam-Level: X-Spam-Status: No, score=-1.861 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, 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 lKNgL+Ar1xBt for ; Wed, 1 Aug 2012 09:52:38 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id EBEC011E8155 for ; Wed, 1 Aug 2012 09:52:37 -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 4811E2016A; Wed, 1 Aug 2012 13:04:59 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <5018D80C.90705@gmail.com> References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <5018D80C.90705@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, curtis@occnc.com Subject: Re: [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 16:52:39 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Brian" =3D=3D Brian E Carpenter writes: Brian> And therefore intrinsically evil, just like 10.0.0.0/8 is Brian> intrinsically evil. Brian> IMHO we shouldn't be discussing how to make it work less Brian> badly; we should be discussing how to avoid it entirely. Right, but we have installed base. Based upon comments in Jabber yesterday, I think that the right way is for fridge.local mDNS to return a series of SRV records in the additional information, one of which would contain a FQDN (having a GUA) for the fridge, if it had one. I don't know exactly what that would look like, but it seems like the right process: discovery gives us a name, and the name is sometimes a FQDN. That would also have solved Stuart's problem printing to bluehawaii, had his laptop CUPS bookmarked bluehawaii.apple.com rather than bluehawaii.local (nothing that bluehawaii.apple.com works just fine when in the office) =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBle0IqHRg3pndX9AQJ3QAP+JW2O9bWe5pXYdexAm98cCpVnmqhoSVq0 uWc0Xu7mlp1ah4CVIr4NzvtUHOk5YAa/96akzmR7gjRIWwEEQRlO11bR0wFX6R4D +IQ1ven/bNowKwpICaFwNpk3Gh+FVoa757pzKIAcKweS3jvOEAN4J/O/l+TleYQA uLlJhnvvL5k= =N7b3 -----END PGP SIGNATURE----- --=-=-=-- From curtis@occnc.com Wed Aug 1 10:19: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 0DEB611E82E5 for ; Wed, 1 Aug 2012 10:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, J_CHICKENPOX_13=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 hpoKKOLCTtkY for ; Wed, 1 Aug 2012 10:19: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 6788411E82DD for ; Wed, 1 Aug 2012 10:19:27 -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 q71HJL6a007243; Wed, 1 Aug 2012 13:19:21 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208011719.q71HJL6a007243@gateway.ipv6.occnc.com> To: Mikael Abrahamsson From: Curtis Villamizar In-reply-to: Your message of "Wed, 01 Aug 2012 10:13:02 +0200." Date: Wed, 01 Aug 2012 13:19:21 -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: Wed, 01 Aug 2012 17:19:28 -0000 In message Mikael Abrahamsson writes: > On Wed, 1 Aug 2012, Brian E Carpenter wrote: > > > That's true. My point was that the CPE resolver will have to be upgraded > > to support DNS64 for, and *only* for, IPv6-only hosts. How it knows > > which hosts are IPv6-only is another mystery. > > Indeed, I started a thread about this on v6ops the other day: > > > > Seems there is no solution to this problem and I'm seem to be having > trouble getting traction there that this might actually be a real problem > that needs solving. Same answer as one given on that thread. If a device can support IPv4, then use NAT4. If a device can only support IPv6, then the DNS64 belongs on the IPv6-only device. To that device all host return AAAA records, since the A records are translated into ipv4-in-ipv6 space. The CPE should be dual stack and be capable of both NAT4 and NAT64 translations to allow reachability into the IPv4 world. This is simple. As pointed out on the thread, a patch has already been submitted to android and some 3gpp phone already do DNS64. If the CPE doesn't do NAT64, the packet will wander along some route, most likely the default route, until it either hits a NAT64 or runs into a black hole. Propogating DNS64 translated address can cause severe problems and therefore should never leak outside the single IPv6 only host that needs it to get to IPv4 addresses. DNS64 and NAT64 already exist for BSD and Linux (bind and pf for BSD, bind and linuxnat64 for linux). Curtis From v6ops@globis.net Wed Aug 1 10:23: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 0D62611E836B for ; Wed, 1 Aug 2012 10:23:08 -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 aOcH7Pzu70Br for ; Wed, 1 Aug 2012 10:23:07 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 491E111E8169 for ; Wed, 1 Aug 2012 10:23:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 2EFE28700E4; Wed, 1 Aug 2012 19:22:51 +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 KrBM2Pf9sb+i; Wed, 1 Aug 2012 19:22:34 +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 78DE9870061; Wed, 1 Aug 2012 19:22:34 +0200 (CEST) Message-ID: <501965D4.1040300@globis.net> Date: Wed, 01 Aug 2012 19:22:28 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: Brian E Carpenter References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <5018D80C.90705@gmail.com> In-Reply-To: <5018D80C.90705@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, curtis@occnc.com Subject: Re: [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 17:23:08 -0000 Isn't it possible to combine the two ideas of sitelocal. with pseudo-domains generated from ULA to give a usable solution? e.g. fridge..sitelocal. Don't you then avoid the evilness of identifier overloading (my fridge versus your fridge) and potential problems with clashing TLD's? e.g. someone registering a bunch of . TLD records as their company brand for manual administration. How else are homenet devices going to know not to bother the root servers with fridge.. NS queries given that TLD's are now basically a free for all? Wouldn't it also potentially give a unique anchor point for storing DNSSEC zone signing with an implicit sitelocal. trust anchor? regards, RayH Brian E Carpenter wrote: > Synthesise a pseudo-TLD from the ULA prefix. > > Brian Brian E Carpenter wrote: > On 01/08/2012 05:48, Curtis Villamizar wrote: > ... >> fridge.sitelocal. is a FQDN with site local scope. > > And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil. > > IMHO we shouldn't be discussing how to make it work less badly; we should > be discussing how to avoid it entirely. > > Brian > From curtis@occnc.com Wed Aug 1 10:25: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 665DB11E818B for ; Wed, 1 Aug 2012 10:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.170, 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 lA-nhm-PXnz8 for ; Wed, 1 Aug 2012 10:25: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 2D46611E83E0 for ; Wed, 1 Aug 2012 10:25:40 -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 q71HPCdT008017; Wed, 1 Aug 2012 13:25:12 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208011725.q71HPCdT008017@gateway.ipv6.occnc.com> To: Brian E Carpenter From: Curtis Villamizar In-reply-to: Your message of "Wed, 01 Aug 2012 15:26:51 BST." <50193CAB.5070803@gmail.com> Date: Wed, 01 Aug 2012 13:25:12 -0400 Cc: homenet@ietf.org, curtis@occnc.com 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 17:25:45 -0000 In message <50193CAB.5070803@gmail.com> Brian E Carpenter writes: > Synthesise a pseudo-TLD from the ULA prefix. > > Brian If the whole ULA is used, then the scope is single host. If the ULA prefix is used, then the scope is all reachable ULA which is the same as sitelocal but with an obscure name. Curtis > On 01/08/2012 15:17, Curtis Villamizar wrote: > > In message <5018D80C.90705@gmail.com> > > Brian E Carpenter writes: > > > >> On 01/08/2012 05:48, Curtis Villamizar wrote: > >> ... > >>> fridge.sitelocal. is a FQDN with site local scope. > >> > >> And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil. > >> > >> IMHO we shouldn't be discussing how to make it work less badly; we should > >> be discussing how to avoid it entirely. > >> > >> Brian > > > > > > Brian, > > > > Not being connected to the Internet and not having any configuration > > at all might also be intrinsically evil, but that's the situation when > > a consumer takes some gadget out of the box. > > > > What we are trying to accomplish with the sitelocal is a way to name > > things on a local network that have no domain name assigned through a > > registry and have not had a domain name assigned as part of some > > subdomain of the provider. > > > > Even if the homenet WG was extremely thoroughthe gadget did 100% of > > what we specify and implemented everything perfectly, we can't control > > the user who almost never has a domain name of their own or the ISP > > that can't be bothered delegating some subdomain of theirs to a > > customer. The customer then has no global domain to hang names off of > > and has no choice but to not use DNS or make use of a sitelocal domain > > with site local scope. > > > > So sitelocal is inherently needed, either during a transition (until > > the uplink comes up at least for the first time and a domain name is > > learned) or permanently (if no domain name ever gets delegated to the > > residential customer site). > > > > Curtis > > > > > > ps - Yes - it is inherently evil. So is not delegating rDNS IMHO. > > But we can't control those MSO and ILEC residential ISPs. From marka@isc.org Wed Aug 1 10:55: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 42D7011E8258 for ; Wed, 1 Aug 2012 10:55:14 -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 i-6vy09-HJDa for ; Wed, 1 Aug 2012 10:55: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 6E99821F8723 for ; Wed, 1 Aug 2012 10:55:12 -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 BE1775F9981; Wed, 1 Aug 2012 17:54:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:96:c88a:1d17:4455:7e5b]) (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 18748216C36; Wed, 1 Aug 2012 17:54: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 817CA232B245; Thu, 2 Aug 2012 03:54:53 +1000 (EST) To: Wouter Cloetens From: Mark Andrews References: <201208010126.q711Q8sQ087703@gateway.ipv6.occnc.com> <5018DDCA.1010702@softathome.com> <20120801141322.1B3C2232A2B2@drugs.dv.isc.org> <50194422.6070702@softathome.com> In-reply-to: Your message of "Wed, 01 Aug 2012 16:58:42 +0200." <50194422.6070702@softathome.com> Date: Thu, 02 Aug 2012 03:54:53 +1000 Message-Id: <20120801175453.817CA232B245@drugs.dv.isc.org> Cc: homenet@ietf.org 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 17:55:14 -0000 In message <50194422.6070702@softathome.com>, Wouter Cloetens writes: > On 01/08/12 16:13, Mark Andrews wrote: > > In message<5018DDCA.1010702@softathome.com>, Wouter Cloetens writes: > >> On 01/08/12 03:26, Curtis Villamizar wrote: > >>> Anything DNS related should be reliable. Therefore a secondary would > >>> be preferable to not having one. > >> > >> OTOH, the use case of a DNS lookup for a hostname or IP address for > >> which the last-hop router is offline (at the time of the lookup) is limited. > >> It is there; e.g. batch log processing on web servers, but that is for > >> informative purposes only, and doesn't cause connection failures. > > > > This is crazy talk. We have absolutely no idea what will or will > > not end up being run from the home. Whether people will need to > > lookup information about the home when it is unreachable or not. > > How do you debug if you can reach home or not if you can't get the > > addresses of the machines at home? > > If you need to run a reliable service, you shouldn't be running it from > your home. The use case of homenet is restricted to that. The only real difference between home and commercial is SLA agreements and MTR. Home is a perfectly fine place to run some services. Some services can only be run from the home. Additionally PTR records are not the only think that gets stored in the reverse DNS. > What you understand as "crazy talk," I see as; trying to get something > working, in best-effort mode, taking into account the limitations of a > home network with a CE router in front of it. > We assume that a DynDNS-style approach simply will never scale for every > IPv6 address in the home, and therefore the home router has to be > authoritative, handling the requests. Actually dynamic DNS is extremely cheap and can scale to every device. Costs to host zones in volume are in single dollar digits / zone / year. Automation reduces these costs towards the pure hardware and comm costs which continue to drop. > > The DNS was designed with the idea that there would be redundent > > servers. It is not designed to deal with not being able to connect > > to any servers for a zone and it really does not work well when > > this is the case. > > If you *are* running a service from home, there is always the option of > setting up DynDNS specifically for those hosts that need to be accessible. > -- > Architect Core Gateway SoftAtHome R&D RGW http://www.softathome.com/ > http://www.linkedin.com/in/wcloetens Vaartdijk 3/B701, B-3018 Wijgmaal > Tel: +32-16-852010 Mobile: +32-492-277790 Fax: +32-16-852099 > > This message and any attachments are confidential, intended solely for > the addressees and are SoftAtHome’s ownership. > Any unauthorized use or dissemination is prohibited. If you are not the > intended addressee of this message, please cancel it immediately and > inform the sender. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mcr+ietf@sandelman.ca Wed Aug 1 11:09: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 B4A6911E8274 for ; Wed, 1 Aug 2012 11:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.427, 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 XufukUG5yA2y for ; Wed, 1 Aug 2012 11:09:40 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id A561A11E8269 for ; Wed, 1 Aug 2012 11:09: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 870742016A; Wed, 1 Aug 2012 14:22:03 -0400 (EDT) From: Michael Richardson To: Kerry Lynn In-Reply-To: References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <5018D80C.90705@gmail.com> <17002.1343839952@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 Cc: "homenet@ietf.org" , "curtis@occnc.com" Subject: Re: [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 18:09:41 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Kerry" =3D=3D Kerry Lynn writes: Kerry> Actually, I think the problem may be that CUPS insists on Kerry> re-resolving the name every time it prints, rather than Kerry> trying the GUA that it would have learned at initial Kerry> discovery. Do we want applications caching mDNS replies into configuration files? I think not, and I think the DNS people will shout loudly about that. Kerry> Nobody seems to be complaining about the need to be on-site Kerry> to discover the service initially. The issues seem to be No, in fact, it's a feature. Kerry> my desk, unless I connect my host to that same link. I Kerry> cannot remember a time when I needed to use it remotely. I regularly print to both my work and home printer remotely (yes, over IPv6. The CUPS server speaks IPv6 even if my home printer speaks only USB). I do this will all sorts of paperwork, receipts for online expenses, etc. Yes, I sometimes print to the wrong printer. I also regularly print to these printers when "offline", knowing that CUPS will punt it out when I get "home" I believe that Google Cloud Print is getting close to eliminating my need to own one of these infernal mechanical devices.=20 Kerry> BTW, I agree with the earlier comment that the may be several Kerry> good reasons to include VPN tunnels in the homenet Kerry> architecture. They exist. It would be nice if our secure setup protocol for homenet could also be leveraged to setup remote access. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBlw4IqHRg3pndX9AQJOhQQAhZX7PxcDPF+QhlS0DUH4eRJgO2N1g5ZO rl1t2Yo1/LN/+5OoUDWaIK0PivDslTiWA6k/7SX99+SmyBbgXd48nLJnF13ucthL SleCNopgsOkgQkl4ukmy1PNP9aHIvrD2g2R/1LIzm0AdZp+MkVFv3D1AsVf9Z+9K vLDUD04kJwg= =wDRn -----END PGP SIGNATURE----- --=-=-=-- From curtis@occnc.com Wed Aug 1 11:48: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 E84F611E829A for ; Wed, 1 Aug 2012 11:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=-0.137, 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 3S9kT4tnYS+I for ; Wed, 1 Aug 2012 11:48:59 -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 4C1FC11E8180 for ; Wed, 1 Aug 2012 11:48:59 -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 q71ImWga009132; Wed, 1 Aug 2012 14:48:32 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208011848.q71ImWga009132@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Wed, 01 Aug 2012 12:52:32 EDT." <17002.1343839952@obiwan.sandelman.ca> Date: Wed, 01 Aug 2012 14:48:31 -0400 Cc: homenet@ietf.org, curtis@occnc.com 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 18:49:00 -0000 In message <17002.1343839952@obiwan.sandelman.ca> Michael Richardson writes: > > >>>>> "Brian" =3D=3D Brian E Carpenter writes: > Brian> And therefore intrinsically evil, just like 10.0.0.0/8 is > Brian> intrinsically evil. > > Brian> IMHO we shouldn't be discussing how to make it work less > Brian> badly; we should be discussing how to avoid it entirely. > > Right, but we have installed base. > Based upon comments in Jabber yesterday, I think that the right way is > for fridge.local mDNS to return a series of SRV records in the > additional information, one of which would contain a FQDN (having a GUA) > for the fridge, if it had one. > > I don't know exactly what that would look like, but it seems like the > right process: discovery gives us a name, and the name is sometimes a > FQDN. That would also have solved Stuart's problem printing to > bluehawaii, had his laptop CUPS bookmarked bluehawaii.apple.com rather > than bluehawaii.local (nothing that bluehawaii.apple.com works just fine > when in the office) > > Michael Richardson , Sandelman Software Works=20 It might be reasonable for mDNS or dynamic DNS to populate the FQDN with an A and AAAA record and create a CNAME in local or sitelocal that points to the FQDN. Tools like host or dig would report the CNAME, the FQDN, and the final A and/or AAAA records if sitelocal was in the search path before the domain. I'm not sure how that works with CUPS bookmarking. Curtis From each@isc.org Wed Aug 1 11:49: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 643D611E83EE for ; Wed, 1 Aug 2012 11:49:15 -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 DRzWxqnTbAIL for ; Wed, 1 Aug 2012 11:49:14 -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 E1CE111E809B for ; Wed, 1 Aug 2012 11:49:13 -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 DB9525F9941; Wed, 1 Aug 2012 18:48:56 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 616E2216C3B; Wed, 1 Aug 2012 18:48:55 +0000 (UTC) Date: Wed, 1 Aug 2012 18:48:55 +0000 From: Evan Hunt To: Mark Andrews Message-ID: <20120801184855.GA73640@isc.org> References: <201208010126.q711Q8sQ087703@gateway.ipv6.occnc.com> <5018DDCA.1010702@softathome.com> <20120801141322.1B3C2232A2B2@drugs.dv.isc.org> <50194422.6070702@softathome.com> <20120801175453.817CA232B245@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120801175453.817CA232B245@drugs.dv.isc.org> User-Agent: Mutt/1.4.2.3i Cc: homenet@ietf.org, Wouter Cloetens 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 18:49:16 -0000 > What you understand as "crazy talk," I see as; trying to get something > working, in best-effort mode, taking into account the limitations of a > home network with a CE router in front of it. Then again, the point of this WG as I understand it is to get rid of some of those limitations, not to accomodate or perpetuate them. :) > We assume that a DynDNS-style approach simply will never scale for every > IPv6 address in the home, and therefore the home router has to be > authoritative, handling the requests. You can have a router be authoritative for its own zones and also have a reliable secondary name service elsewhere. I run BIND 9 on my home router (netgear wndr3700 running customized openwrt/cerowrt, thank you Dave Taht); it's authoritative for several zones, both forward and reverse, some of which are split into internal and external views, and all of which are DNSSEC signed. When any of the zones is updated due to the addition or removal of a device, a NOTIFY is sent to the secondary name service, which IXFRs up the changes. (I use ISC's SNS for this because I'm an employee and get it for free, but there are similar inexpensive services out there including, IIRC, a recent offering from Amazon -- and it wouldn't be a difficult service for an ISP to offer.) For queries originating inside my network, the router handles recursion and will answer authoritatively when asked for a name in the site-local namespace or in the internal view of the public namespaces. Queries originating outside the network generally go to the secondary servers. If I'd wanted to, I could have configured my router to be a hidden master, and then *all* the queries would go to the secondaries (except for *XFR requests coming from the secondaries). So in this model both the router and the secondary servers are authoritative for the externally visible view of the network; the router is solely authoritative for the internally visible view. I don't know of any reason this approach couldn't scale. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From each@isc.org Wed Aug 1 12:17: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 C94B611E809B for ; Wed, 1 Aug 2012 12:17:38 -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 8uPDjnaWOFRj for ; Wed, 1 Aug 2012 12:17:38 -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 2113D21F8826 for ; Wed, 1 Aug 2012 12:17:37 -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 76C40C9541; Wed, 1 Aug 2012 19:17:27 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 62080216C36; Wed, 1 Aug 2012 19:17:27 +0000 (UTC) Date: Wed, 1 Aug 2012 19:17:27 +0000 From: Evan Hunt To: Michael Richardson Message-ID: <20120801191727.GB73640@isc.org> References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <5018D80C.90705@gmail.com> <17002.1343839952@obiwan.sandelman.ca> <30312.1343844576@obiwan.sandelman.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30312.1343844576@obiwan.sandelman.ca> User-Agent: Mutt/1.4.2.3i Cc: "homenet@ietf.org" , "curtis@occnc.com" , Kerry Lynn Subject: Re: [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 19:17:39 -0000 > Do we want applications caching mDNS replies into configuration files? > I think not, and I think the DNS people will shout loudly about that. Hm... I'm a DNS people, but I'm not sure I object to this. You'd want some mechanism for clearing old records out after the devices had been gone from the network for a long-enough time, but that's not intrinsically hard. > I regularly print to both my work and home printer remotely (yes, over > IPv6. The CUPS server speaks IPv6 even if my home printer speaks only > USB). I'm of the opinion that "remote access from offsite" should be a service you can configure your printer to provide, but which is not the default. In my ideal world (please indulge me in a moment of handwaving), you plug in your printer, and tell it what its name is (or let it pick its own default such as "LaserPrinter-3"); it announces itself to the local network as providing local printing, and its name is placed in the .sitelocal domain. *If* you check the box for "let the outside world print to me" -- which you and I might want to do but most people wouldn't -- then it announces itself as providing both local and remote printing, and its name is placed in .sitelocal and then mirrored into the globally addressable domain that you'd previously configured for your network: by preference, that would be your private domain name, but if you don't have one of those then it could mirror into a namespace controlled by your ISP, Apple, DynDNS or whatever. If you were printing something, and you a found a printer via service discovery which indicate that it could provide remote access, then you'd be given the option to bookmark its global name and use it when you're away; if it isn't configured for remote access then you woulnd't be given that option. A similar mental model could apply to the "fridge" and "lamp" examples we've been kicking around as well -- you won't normally *want* them to be globally accessible, but if you do, you should tell them so and let them work it out with your network. (This is the point I was trying to make at the mic yesterday, but I'm not sure it came across.) -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From mellon@fugue.com Wed Aug 1 12:37: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 10BB511E80A3 for ; Wed, 1 Aug 2012 12:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.041, 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 HQWu0YUii4Jd for ; Wed, 1 Aug 2012 12:36:59 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 213B111E809B for ; Wed, 1 Aug 2012 12:36:59 -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 D510C2380762; Wed, 1 Aug 2012 15:36:57 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_4D1AEF8E-D112-499F-B87D-890937D06E93" From: Ted Lemon In-Reply-To: <20120801184855.GA73640@isc.org> Date: Wed, 1 Aug 2012 12:36:58 -0700 Message-Id: <1F360E63-A913-46E8-BB0D-63FCB1BC3DB6@fugue.com> References: <201208010126.q711Q8sQ087703@gateway.ipv6.occnc.com> <5018DDCA.1010702@softathome.com> <20120801141322.1B3C2232A2B2@drugs.dv.isc.org> <50194422.6070702@softathome.com> <20120801175453.817CA232B245@drugs.dv.isc.org> <20120801184855.GA73640@isc.org> To: Evan Hunt X-Mailer: Apple Mail (2.1283) Cc: homenet@ietf.org, Wouter Cloetens , Mark Andrews 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 19:37:00 -0000 --Apple-Mail=_4D1AEF8E-D112-499F-B87D-890937D06E93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 1, 2012, at 11:48 AM, Evan Hunt wrote: >> What you understand as "crazy talk," I see as; trying to get = something=20 >> working, in best-effort mode, taking into account the limitations of = a=20 >> home network with a CE router in front of it. >=20 > Then again, the point of this WG as I understand it is to get rid of = some > of those limitations, not to accomodate or perpetuate them. :) Exactly. I think that the wish for an expedient solution often ignores = the fact that a step-by-step implementation of the real solution isn't = as hard as the proponents of expedient solutions often fear. Regarding the question of whether to update the primary on the CPE = device or update the primary on the ISP, the main motivation in my mind = for doing it on the CPE device is that it avoids a massive key = management problem. If the CPE device is primary and the ISP device is = secondary, the ISP can publish a SIG(0) key in a well-known zone and use = that to authenticate zone transfers. Going the other direction = requires the ISP to have a public key somewhere for every single = customer. There's nothing fundamentally hard about this, but I think = the other way is easier. Having said that, of course we should describe how to do it both ways. = I just think the CPE being primary is going to be more popular, assuming = both solutions are equally well-supported. --Apple-Mail=_4D1AEF8E-D112-499F-B87D-890937D06E93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii What you understand as "crazy talk," I = see as; trying to get something 
working, in best-effort mode, taking into account the = limitations of a 
home network with a CE router in front of = it.

Then again, the point of this WG as I understand = it is to get rid of some
of those limitations, not to accomodate or = perpetuate them. :)
Exactly. =   I think that the wish for an expedient solution often ignores the = fact that a step-by-step implementation of the real solution isn't as = hard as the proponents of expedient solutions often = fear.

Regarding the question of whether to = update the primary on the CPE device or update the primary on the ISP, = the main motivation in my mind for doing it on the CPE device is that it = avoids a massive key management problem.   If the CPE device is = primary and the ISP device is secondary, the ISP can publish a SIG(0) = key in a well-known zone and use that to authenticate zone transfers. =   Going the other direction requires the ISP to have a public key = somewhere for every single customer.   There's nothing = fundamentally hard about this, but I think the other way is = easier.

Having said that, of course we should = describe how to do it both ways.   I just think the CPE being = primary is going to be more popular, assuming both solutions are equally = well-supported.

= --Apple-Mail=_4D1AEF8E-D112-499F-B87D-890937D06E93-- From wouter.cloetens@softathome.com Wed Aug 1 13:07: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 AE7FE11E814C for ; Wed, 1 Aug 2012 13:07:53 -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 Xre7fCJ4PdZk for ; Wed, 1 Aug 2012 13:07:53 -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 175B911E810A for ; Wed, 1 Aug 2012 13:07:53 -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 1SwfCx-0003E4-FY for homenet@ietf.org; Wed, 01 Aug 2012 22:07:51 +0200 Message-ID: <50198C95.7000800@softathome.com> Date: Wed, 01 Aug 2012 22:07:49 +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: <201208010126.q711Q8sQ087703@gateway.ipv6.occnc.com> <5018DDCA.1010702@softathome.com> <20120801141322.1B3C2232A2B2@drugs.dv.isc.org> <50194422.6070702@softathome.com> <20120801154044.GB32338@mail.yitter.info> In-Reply-To: <20120801154044.GB32338@mail.yitter.info> 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: Wed, 01 Aug 2012 20:07:53 -0000 On 01/08/12 17:40, Andrew Sullivan wrote: > On Wed, Aug 01, 2012 at 04:58:42PM +0200, Wouter Cloetens wrote: >> We assume that a DynDNS-style approach simply will never scale for >> every IPv6 address in the home, and therefore the home router has to >> be authoritative, handling the requests. > > If I may ask, why do you make that assumption? I assure you that Dyn > is running some very large zones with high change rates. Now, it > might be that nobody would be willing to pay for such a service at the > rate Dyn would charge to make this profitable, assuming large numbers > of records and a high rate of change. If that's your argument, > however, I'd like to know understand how this is going to be worth > doing for someone else when Dyn already has the sunk investment in > infrastructure. Internet of Things. Home automation. 5, 10 years from now. 10k nodes low-power nodes for a site. (Not unrealistic for an office building, I've been told). It is sensible to have those nodes visible in the DNS, forward and reverse, for remote management and other reasons. You basically never, ever want to type in an IPv6 address. It is not sensible to have them register themselves to DynDNS, or have the router register to Dyn for them. draft-mglt-homenet-naming-delegation and mglt-homenet-front-end-naming-delegation provide a solution that will work securely, out of the box, without any end user configuration at all, and consuming no bandwidth if the home DNS feature is not used. The end user doesn't even have to register for a DynDNS account. *That* is what this WG should be about IMO; making things scale to unimaginable proportions (we are designing for the next 100 years), simple, without any need for configuration, and without cost. bfn, Wouter From marka@isc.org Wed Aug 1 14:54: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 D07EA11E8305 for ; Wed, 1 Aug 2012 14:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=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 Bq4yZZavcpSu for ; Wed, 1 Aug 2012 14:54:39 -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 11E3B11E8235 for ; Wed, 1 Aug 2012 14:54:39 -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 0DA9EC9547; Wed, 1 Aug 2012 21:54:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:df8:0:96:2464:ed8c:bf09:2ecd]) (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 D4CA9216C33; Wed, 1 Aug 2012 21:54:24 +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 84267232CC4B; Thu, 2 Aug 2012 07:54:22 +1000 (EST) To: curtis@occnc.com From: Mark Andrews References: <201208011719.q71HJL6a007243@gateway.ipv6.occnc.com> In-reply-to: Your message of "Wed, 01 Aug 2012 13:19:21 -0400." <201208011719.q71HJL6a007243@gateway.ipv6.occnc.com> Date: Thu, 02 Aug 2012 07:54:22 +1000 Message-Id: <20120801215422.84267232CC4B@drugs.dv.isc.org> Cc: homenet@ietf.org, Mikael Abrahamsson 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: Wed, 01 Aug 2012 21:54:40 -0000 In message <201208011719.q71HJL6a007243@gateway.ipv6.occnc.com>, Curtis Villamizar writes: > > In message > Mikael Abrahamsson writes: > > > On Wed, 1 Aug 2012, Brian E Carpenter wrote: > > > > > That's true. My point was that the CPE resolver will have to be upgraded > > > to support DNS64 for, and *only* for, IPv6-only hosts. How it knows > > > which hosts are IPv6-only is another mystery. > > > > Indeed, I started a thread about this on v6ops the other day: > > > > > > > > Seems there is no solution to this problem and I'm seem to be having > > trouble getting traction there that this might actually be a real problem > > that needs solving. > > > Same answer as one given on that thread. If a device can support > IPv4, then use NAT4. If a device can only support IPv6, then the > DNS64 belongs on the IPv6-only device. To that device all host return > AAAA records, since the A records are translated into ipv4-in-ipv6 > space. The CPE should be dual stack and be capable of both NAT4 and > NAT64 translations to allow reachability into the IPv4 world. This is > simple. As pointed out on the thread, a patch has already been > submitted to android and some 3gpp phone already do DNS64. > > If the CPE doesn't do NAT64, the packet will wander along some route, > most likely the default route, until it either hits a NAT64 or runs > into a black hole. > > Propogating DNS64 translated address can cause severe problems and > therefore should never leak outside the single IPv6 only host that > needs it to get to IPv4 addresses. DNS64 and NAT64 already exist for > BSD and Linux (bind and pf for BSD, bind and linuxnat64 for linux). DNS64 does not add synthesised addresses to existing AAAA RRsets. IPv6-only nodes will not be able to connect to dual stack servers as there is no IPv6 path. > Curtis > _______________________________________________ > 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 mcr+ietf@sandelman.ca Wed Aug 1 15:54: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 5964911E8131 for ; Wed, 1 Aug 2012 15:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.419, 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 XkwTkDw4m3Ph for ; Wed, 1 Aug 2012 15:54:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id D0D2611E811E for ; Wed, 1 Aug 2012 15:54:10 -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 8F8BA2016A for ; Wed, 1 Aug 2012 19:06:25 -0400 (EDT) From: Michael Richardson To: "homenet@ietf.org" In-Reply-To: <20120801191727.GB73640@isc.org> References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <5018D80C.90705@gmail.com> <17002.1343839952@obiwan.sandelman.ca> <30312.1343844576@obiwan.sandelman.ca> <20120801191727.GB73640@isc.org> 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] 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 22:54:12 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Evan" =3D=3D Evan Hunt writes: >> Do we want applications caching mDNS replies into configuration >> files? I think not, and I think the DNS people will shout loudly >> about that. Evan> Hm... I'm a DNS people, but I'm not sure I object to this. Evan> You'd want some mechanism for clearing old records out after Evan> the devices had been gone from the network for a long-enough Evan> time, but that's not intrinsically hard. so, after your ISP renumberers you (not a flash renumber), or if you change routers (get a new ULA), or change ISPs, you have to discover your printer again? Evan> I'm of the opinion that "remote access from offsite" should be Evan> a service you can configure your printer to provide, but which Evan> is not the default. Uhm, so let's seperate discovery, naming, and reachability from authorization. (being able to reach it doesn't mean you can print...) Evan> In my ideal world (please indulge me in a moment of Evan> handwaving), you plug in your printer, and tell it what its Evan> name is (or let it pick its own default such as Evan> "LaserPrinter-3"); it announces itself to the local network as Evan> providing local printing, and its name is placed in the Evan> .sitelocal domain. okay, so far. Evan> *If* you check the box for "let the outside world print to me" Evan> -- which you and I might want to do but most people wouldn't I agree that this is a box. I'd like to see some more authentication and authorization things happen, but that's a detail for CUPS/IPP. What's relevant here is that we have a new requirement for sitelocal mDNS: we need to signal via mDNS from the printer to the holder of the FQDN zone (probably the CPE).=20=20=20 =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBmzhYqHRg3pndX9AQIsswQAqg85Tr3itCf+k/AhVLaN5bQqatQSQmdq QvVozCcbGXnAulBJl5b56rr23N4HnhWCiOPGLSBRM3HPMkJSk6fpkikr/GqkIjXJ vn9Q0XISov6jpFQC2fJZe00+0xBTe8lAsg2YRjthAND/oAyN25adPHpQ5jm9jlXh C+i3+tr/WB8= =oCsV -----END PGP SIGNATURE----- --=-=-=-- From swmike@swm.pp.se Wed Aug 1 22:58: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 ABF1C11E814F for ; Wed, 1 Aug 2012 22:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 XLQUV8VltsHR for ; Wed, 1 Aug 2012 22:58:39 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 8A86E11E8148 for ; Wed, 1 Aug 2012 22:58:39 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A969B9C; Thu, 2 Aug 2012 07:58:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A083B9A; Thu, 2 Aug 2012 07:58:38 +0200 (CEST) Date: Thu, 2 Aug 2012 07:58:38 +0200 (CEST) From: Mikael Abrahamsson To: Curtis Villamizar In-Reply-To: <201208011719.q71HJL6a007243@gateway.ipv6.occnc.com> Message-ID: References: <201208011719.q71HJL6a007243@gateway.ipv6.occnc.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: 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: Thu, 02 Aug 2012 05:58:40 -0000 On Wed, 1 Aug 2012, Curtis Villamizar wrote: > Same answer as one given on that thread. If a device can support > IPv4, then use NAT4. If a device can only support IPv6, then the > DNS64 belongs on the IPv6-only device. To that device all host return Am I interpreting you correctly in that you're saying that an IPv6 only device should have a built in resolver that does DNS64 in case of v6 only connectivity? I can see that this would work, but is that a generally accepted solution? On Android, this would mean that dnsmasq would need to gain DNS64 functionality (and also needs to be able to detect the NAT64 prefix somehow). -- Mikael Abrahamsson email: swmike@swm.pp.se From brian.e.carpenter@gmail.com Thu Aug 2 03:02: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 0CBB921F8D95 for ; Thu, 2 Aug 2012 03:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.446 X-Spam-Level: X-Spam-Status: No, score=-101.446 tagged_above=-999 required=5 tests=[AWL=0.245, 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 lnnCP+L2AOQ7 for ; Thu, 2 Aug 2012 03:02:16 -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 C352C21F8D94 for ; Thu, 2 Aug 2012 03:02:15 -0700 (PDT) Received: by eekb45 with SMTP id b45so2230352eek.31 for ; Thu, 02 Aug 2012 03:02:15 -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=w6rr/oHKfXY35TnbKgZnv+8p7cJEHEos27NswO/XTCU=; b=Kp616rZdXN6fIpX8A8WSWuHmYU2gpqCt7xxoibrmPec88mGP9lnC1vrpRuUEhzB5wB UjQDr9Tx71IEYS9eVM/4zS9JXb5XjRx8cmCywRwG1B4XXBLRwcVUO+OINmU+pSbSSRiT vWifuammXpKQ8iYCmV73utUnmohzhywMut33UiQe7MJlleO1hJdMXmCZeD/hBki2giTp pVxy43wMDbw9z84G8r8dfghVLqn+xmrlTqfQNmi8K9OGp84WcGC8r4BFZq71LA/r/dp5 pym4TF7WC5yXkNq+dTUVtdyeC4yEveCx6yPxC0bAS4lCQT2E3jBsw8uM9w1SL8bzPHwu hHVA== Received: by 10.14.198.200 with SMTP id v48mr26446742een.3.1343901734929; Thu, 02 Aug 2012 03:02:14 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-46.as13285.net. [2.102.219.46]) by mx.google.com with ESMTPS id v5sm15996376eel.6.2012.08.02.03.02.12 (version=SSLv3 cipher=OTHER); Thu, 02 Aug 2012 03:02:13 -0700 (PDT) Message-ID: <501A502D.30408@gmail.com> Date: Thu, 02 Aug 2012 11:02:21 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: curtis@occnc.com References: <201208011439.q71Ed183005154@gateway.ipv6.occnc.com> In-Reply-To: <201208011439.q71Ed183005154@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 10:02:17 -0000 On 01/08/2012 15:39, Curtis Villamizar wrote: > In message <5018DD8A.2070900@gmail.com> > Brian E Carpenter writes: > >> Excuse front posting, but... >> >>> Today there is no DHCP help in avoiding the "please reboot" messages. >> >> Don't RECONFIGURE (DHCPv6) and FORCERENEW (DHCP) cover this, in theory? >> They are unicast, which is a scaling issue in enterprise networks but >> presumably not in homenets. >> >> Regards >> Brian > > > These only force a renew before the lease expires. For the sometimes > very long IPv6 leases, this is essential. For often relatively > shorter IPv4 leases, it is nice but not quite as essential. > > The issue is not forcing the renew to occur earlier, it is the way in > which a renew that changes the address is handled. Maybe its just > implementations taking a shortcut, but I think in practice changing > the IP address takes the interface down, kills all connections, > including listens, and then brings it back up with a new address. Really? I can't test it in my current native-IPv6-deprived state, but it seems to me that Windows (at least) runs happily with multiple IPv6 addresses on one interface, and I can't imagine that changing one of them will kill the others. I have to admit I haven't studied the semantics of RECONFIGURE closely, though. The RFC 4192 model would look a bit sick if the interfaces get reset. Brian Its > a bit like a reboot as implemented, except the user doesn't know its > coming and therefore may have open TCP connections that break. > > What I've suggested is what to do on a renew that changes the address. > Add an alias. Until the old address has no more connections or > listens on the old address, keep the old address. Then remove the old > address. > > If someone has an open connection, ssh for example, the old address > could be in use indefinitely, but if the transition is weeks, then its > unlikely to go beyond that. For example, if someone was using ssh to > do a long compile on another machine, breaking the connection and > killing the compile would be bad. There are certain to be plenty of > other uses of long duration TCP connections that would have to be > broken in this sort of transition, unless we can also extend TCP to > negotiate a change to one side of the address pair. > > Curtis > > >> On 01/08/2012 04:33, Curtis Villamizar wrote: >>> 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 brian.e.carpenter@gmail.com Thu Aug 2 03:22: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 79B5821F8DF5 for ; Thu, 2 Aug 2012 03:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.452 X-Spam-Level: X-Spam-Status: No, score=-101.452 tagged_above=-999 required=5 tests=[AWL=0.239, 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 QdIJbo17VTqj for ; Thu, 2 Aug 2012 03:22:33 -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 ACE9A21F8DF4 for ; Thu, 2 Aug 2012 03:22:32 -0700 (PDT) Received: by eekb45 with SMTP id b45so2237683eek.31 for ; Thu, 02 Aug 2012 03:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=l8MAbqiYwCjRqNQ4Xdl+TRrXsd8eepoOc7dA64Spmls=; b=dcuIxUeL3pEl018mmDHtIjulGYbz27ckvwT2Sgijk9BPa7gjYEUH7sBPl/tz086LBV +dx07OBcTSCwAHluMy/gnKpsqJtdo4PkzrdExL7ycfOYRkZEyJR492FkTG0V0/7GklSz HSiKgkMFMLjw2qCtfK93LiUknwrpAgUZLUD02PHtKS7Dn6c6p02lGc/Z/6b9mA2qekgE 0fXuRLhsnjGz376CCoz5dsk8+KqG09L0FKn6yJpK3bX3/QkA9Yx/ObHud3pr7ZwAgCTH OGal+js1x/AzeJ9IMjJfeRak68mptLGST+y748/hGyAU/AlyIP4i1tm9pATU18MidBUC /mJA== Received: by 10.14.213.137 with SMTP id a9mr4434998eep.38.1343902951888; Thu, 02 Aug 2012 03:22:31 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-46.as13285.net. [2.102.219.46]) by mx.google.com with ESMTPS id k41sm16102767eep.13.2012.08.02.03.22.29 (version=SSLv3 cipher=OTHER); Thu, 02 Aug 2012 03:22:30 -0700 (PDT) Message-ID: <501A54EE.3080404@gmail.com> Date: Thu, 02 Aug 2012 11:22:38 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: curtis@occnc.com References: <201208011725.q71HPCdT008017@gateway.ipv6.occnc.com> In-Reply-To: <201208011725.q71HPCdT008017@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [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: Thu, 02 Aug 2012 10:22:33 -0000 On 01/08/2012 18:25, Curtis Villamizar wrote: > In message <50193CAB.5070803@gmail.com> > Brian E Carpenter writes: > >> Synthesise a pseudo-TLD from the ULA prefix. >> >> Brian > > If the whole ULA is used, then the scope is single host. If the ULA > prefix is used, then the scope is all reachable ULA which is the same > as sitelocal but with an obscure name. Correct, but the name is unambiguous, which IMHO is a MUST property for anything that looks like an FQDN. We have to live with .local but it should be just a nasty memory like 10.0.0.0/8 fifty years from now. I would suggest instructing IANA to reserve all TLD strings that start with "local" and using something like .local-fd952a92a67d to name the homenet domain. It's only a convenience to use a ULA prefix; it's simply a unique string that the CPE needs to generate anyway, but it has no significance beyond that. The point is that if an FQDN or a URL including such a name escapes from its home, it cannot be misinterpreted at another site. By contrast, printer3.sitelocal might easily be misinterpreted elswhere. Brian > > Curtis > >> On 01/08/2012 15:17, Curtis Villamizar wrote: >>> In message <5018D80C.90705@gmail.com> >>> Brian E Carpenter writes: >>> >>>> On 01/08/2012 05:48, Curtis Villamizar wrote: >>>> ... >>>>> fridge.sitelocal. is a FQDN with site local scope. >>>> >>>> And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil. >>>> >>>> IMHO we shouldn't be discussing how to make it work less badly; we should >>>> be discussing how to avoid it entirely. >>>> >>>> Brian >>> >>> Brian, >>> >>> Not being connected to the Internet and not having any configuration >>> at all might also be intrinsically evil, but that's the situation when >>> a consumer takes some gadget out of the box. >>> >>> What we are trying to accomplish with the sitelocal is a way to name >>> things on a local network that have no domain name assigned through a >>> registry and have not had a domain name assigned as part of some >>> subdomain of the provider. >>> >>> Even if the homenet WG was extremely thoroughthe gadget did 100% of >>> what we specify and implemented everything perfectly, we can't control >>> the user who almost never has a domain name of their own or the ISP >>> that can't be bothered delegating some subdomain of theirs to a >>> customer. The customer then has no global domain to hang names off of >>> and has no choice but to not use DNS or make use of a sitelocal domain >>> with site local scope. >>> >>> So sitelocal is inherently needed, either during a transition (until >>> the uplink comes up at least for the first time and a domain name is >>> learned) or permanently (if no domain name ever gets delegated to the >>> residential customer site). >>> >>> Curtis >>> >>> >>> ps - Yes - it is inherently evil. So is not delegating rDNS IMHO. >>> But we can't control those MSO and ILEC residential ISPs. > . > From brian.e.carpenter@gmail.com Thu Aug 2 03:29: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 1646321F8E3B for ; Thu, 2 Aug 2012 03:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.454 X-Spam-Level: X-Spam-Status: No, score=-101.454 tagged_above=-999 required=5 tests=[AWL=0.237, 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 R1UByde-FtV0 for ; Thu, 2 Aug 2012 03:29:26 -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 5F2DF21F8E3A for ; Thu, 2 Aug 2012 03:29:26 -0700 (PDT) Received: by eaai11 with SMTP id i11so96799eaa.31 for ; Thu, 02 Aug 2012 03:29:25 -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=nIxLwtDjUmzg8P0CzOHipfFglSgfYVmyaw/loGQrfKM=; b=KZJN3lqs9H0GAVt8OzqmIbN0s3DQ2SIkDM02/4qGhSR+VY/CEnlnisBPKqELxltoyQ N3eeLXHwXOvMfcWryGdsRW9dKDQpRt0+vRfS22c3bdQHx8t5sdrCH7rhfn78BSiDhhED AyiqKdmwdvAgswD5aSRa7Qs2ch9rxQd4WP/ubi1HCkP+Ulvh+b02+ELQfe+qolX6NWn8 rvpmzG6lluYScbRCa1OhxRWTLOy8meagxDaLQvEQ60COzb6Tl45KzyPB8PgXSDIafUnW R3XLHZAkvDHN3dx/OEazy4Aeq4D45KtcFuhV9vuygCuHLg4PGAWoWMzlrHngRpKv1wDk vAGQ== Received: by 10.14.214.197 with SMTP id c45mr26229057eep.37.1343903365450; Thu, 02 Aug 2012 03:29:25 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-46.as13285.net. [2.102.219.46]) by mx.google.com with ESMTPS id 9sm16161375eei.12.2012.08.02.03.29.24 (version=SSLv3 cipher=OTHER); Thu, 02 Aug 2012 03:29:24 -0700 (PDT) Message-ID: <501A568C.9040606@gmail.com> Date: Thu, 02 Aug 2012 11:29:32 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mikael Abrahamsson References: <201208011719.q71HJL6a007243@gateway.ipv6.occnc.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, Curtis Villamizar 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: Thu, 02 Aug 2012 10:29:27 -0000 On 02/08/2012 06:58, Mikael Abrahamsson wrote: > On Wed, 1 Aug 2012, Curtis Villamizar wrote: > >> Same answer as one given on that thread. If a device can support >> IPv4, then use NAT4. If a device can only support IPv6, then the >> DNS64 belongs on the IPv6-only device. To that device all host return > > Am I interpreting you correctly in that you're saying that an IPv6 only > device should have a built in resolver that does DNS64 in case of v6 > only connectivity? > > I can see that this would work, but is that a generally accepted > solution? On Android, this would mean that dnsmasq would need to gain > DNS64 functionality (and also needs to be able to detect the NAT64 > prefix somehow). That is one of the models discussed in BEHAVE, of course, and it deals neatly with the DNSSEC conundrum for DNS64. But the normal model is the one that Curtis doesn't like. NAT64/DNS64 plays better when the client network is truly IPv6-only; with mixed hosts, you really need to provision dual stack hosts with a normal DNS server, and the IPv6-only hosts with a DNS64. Brian From mcr+ietf@sandelman.ca Thu Aug 2 07:18: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 9FBF211E80AE for ; Thu, 2 Aug 2012 07:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.411, 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 yiguQUf-MK9S for ; Thu, 2 Aug 2012 07:18:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id F0B3911E80A6 for ; Thu, 2 Aug 2012 07:18:30 -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 889CB2016A for ; Thu, 2 Aug 2012 10:30:55 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <501A502D.30408@gmail.com> References: <201208011439.q71Ed183005154@gateway.ipv6.occnc.com> <501A502D.30408@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: [homenet] forced renumbering in the home (was Re: 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: Thu, 02 Aug 2012 14:18:31 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Brian" =3D=3D Brian E Carpenter writes: Brian> Really? I can't test it in my current native-IPv6-deprived Brian> state, but it seems to me that Windows (at least) runs Brian> happily with multiple IPv6 addresses on one interface, and I Linux too, and sometimes this is a bad thing. If you suspend/resume between home/work wired, I've had the problem where I can't reach the other because said address still lingering on interface makes my laptop think it's still "on the wire" with both. (you have to suspend-then-unplug, otherwise, disconnecting the cable works as a clue to flush the addresses) =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBqMMIqHRg3pndX9AQLRRQQApXVExIBOKRjFkPd0jLJRNztrZMhGI7u1 hjT3xL5YceAK3LfXXlromXDoGV4rv3T1TiSj8oBODWHSf5eLHpzezdiJ0rH7SLwx 9ZTZD608PUziAeLWW1qOm+0DKIzRNRQllFVfXSfg+umOjrHPE4ntZLG2LmvlosG1 59HCpa0Vrb0= =7cq9 -----END PGP SIGNATURE----- --=-=-=-- From mcr+ietf@sandelman.ca Thu Aug 2 07: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 5ED4921F85C7 for ; Thu, 2 Aug 2012 07:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=0.404, 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 hkEa15ScyVAZ for ; Thu, 2 Aug 2012 07:20:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id A8E1821F85C5 for ; Thu, 2 Aug 2012 07:20:43 -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 EC8C52016A for ; Thu, 2 Aug 2012 10:33:07 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <501A54EE.3080404@gmail.com> References: <201208011725.q71HPCdT008017@gateway.ipv6.occnc.com> <501A54EE.3080404@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] 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: Thu, 02 Aug 2012 14:20:44 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Brian" =3D=3D Brian E Carpenter writes: Brian> Correct, but the name is unambiguous, which IMHO is a MUST Brian> property for anything that looks like an FQDN. We have to Brian> live with .local but it should be just a nasty memory like Brian> 10.0.0.0/8 fifty years from now. Brian> I would suggest instructing IANA to reserve all TLD strings Brian> that start with "local" and using something like Brian> .local-fd952a92a67d to name the homenet domain. It's only a Brian> convenience to use a ULA prefix; it's simply a unique string Brian> that the CPE needs to generate anyway, but it has no Brian> significance beyond that. huh, you want to do it that way? Why not fd952a92a67d.local? I'm asking for clarification, not disagreeing. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBqMtYqHRg3pndX9AQIhiwQAyPNG5Cn/0VzK4jmhww5Um28dL83y5GJp 4HUoW1hhY3mwTsbi0EGAnKd2BTJB7ptKnx/b0TuKhWBEdcKpBcHN7+J14Dmb5Gxv +ayVjCNnPkeabG5vc1bdidrv3lQtMq0pFFsSaUJk1sA3dV3ljAFXvtE9s50jGEPU nFYkRv/sbWY= =cSkW -----END PGP SIGNATURE----- --=-=-=-- From brian.e.carpenter@gmail.com Thu Aug 2 07:28: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 2D8DA21F86A7 for ; Thu, 2 Aug 2012 07:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.457 X-Spam-Level: X-Spam-Status: No, score=-101.457 tagged_above=-999 required=5 tests=[AWL=0.234, 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 H5M8QrWLEoFi for ; Thu, 2 Aug 2012 07:28:45 -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 4EA5021F8462 for ; Thu, 2 Aug 2012 07:28:45 -0700 (PDT) Received: by eekb45 with SMTP id b45so2327741eek.31 for ; Thu, 02 Aug 2012 07:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nD9HZrvBVBCx5GEeonx+LhHu+JFUeIGvAVWngHV58VM=; b=bRdZQMFgMhpKqkEjNCIEtANAoVRpHWFQ1ysyFstPWa9pjNCUCt2r5VFDWvIsBpqRrQ 9cZLrJBc55x5ZORdunDwnu5XJ3IN+36rNlZz+5BUQt0ht5koLkh3Fm8U70pGR1zRBiqr Mm84x1BW/sjQFpXpc4NKqqCeKe4guKLYIPKKJRxtka6mkjV9Pjc2PN847aMu7ll4azIR ovYglcvZTvQOkV77I83iDT0o8jHfe1e7buVYCsGaP1RuI3WJVRYASknryQlZBNs8+Gtf u8aWFfh2ZmgOteAJqOvfMtN5kf4kPuzyMyreHxyQOETVGgpSzQL2MjqTfd+F1M8JV4ja B5lA== Received: by 10.14.180.67 with SMTP id i43mr27060383eem.23.1343917724401; Thu, 02 Aug 2012 07:28:44 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-46.as13285.net. [2.102.219.46]) by mx.google.com with ESMTPS id 8sm17880163eeg.16.2012.08.02.07.28.42 (version=SSLv3 cipher=OTHER); Thu, 02 Aug 2012 07:28:43 -0700 (PDT) Message-ID: <501A8EA2.8090205@gmail.com> Date: Thu, 02 Aug 2012 15:28:50 +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: <201208011725.q71HPCdT008017@gateway.ipv6.occnc.com> <501A54EE.3080404@gmail.com> <8857.1343917237@obiwan.sandelman.ca> In-Reply-To: <8857.1343917237@obiwan.sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [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: Thu, 02 Aug 2012 14:28:46 -0000 On 02/08/2012 15:20, Michael Richardson wrote: >>>>>> "Brian" == Brian E Carpenter writes: > Brian> Correct, but the name is unambiguous, which IMHO is a MUST > Brian> property for anything that looks like an FQDN. We have to > Brian> live with .local but it should be just a nasty memory like > Brian> 10.0.0.0/8 fifty years from now. > > Brian> I would suggest instructing IANA to reserve all TLD strings > Brian> that start with "local" and using something like > Brian> .local-fd952a92a67d to name the homenet domain. It's only a > Brian> convenience to use a ULA prefix; it's simply a unique string > Brian> that the CPE needs to generate anyway, but it has no > Brian> significance beyond that. > > huh, you want to do it that way? > Why not fd952a92a67d.local? Yes, that would work too, as long as nobody gets cute and starts resolving the TLD in the open Internet. Brian > > I'm asking for clarification, not disagreeing. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From kerlyn2001@gmail.com Thu Aug 2 07:52: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 1751921F86BB for ; Thu, 2 Aug 2012 07:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.886 X-Spam-Level: X-Spam-Status: No, score=-101.886 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, 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 Sd0rGDo0nvZb for ; Thu, 2 Aug 2012 07:52:34 -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 7368D21F86B7 for ; Thu, 2 Aug 2012 07:52:33 -0700 (PDT) Received: by lagv3 with SMTP id v3so5614232lag.31 for ; Thu, 02 Aug 2012 07:52:31 -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=Kc13zUL9wNt6rPqGNRMPBboeCECHEphqmV95vU5ms3o=; b=bDv5LupNlh3cu4tO0midDpjhu1zxD4iBRiBjo3JZl0yb+X/URxvTuuYozBG3IXk6PV lYHhKEiy6AInt9uM1asmRII5ek6s07quMKNjNdO6hlpT0LOYxIu4c4b8GxL+lRKxhwc/ HoML7Eld9FAXQO9H3tzeHVJivMR1FB6ceYgk6U4pf4zaOf0A5Z8uIdmiNsqzEbFNc3vZ AWTcovs+oJ5et+efyLXOgofSspytHwXQRrsGHlEYnPdSQe9A1RSkm8khbkKpCGmJZy/B w7VznS/rurWKSrU0OpoSkghj5RYM8BWFYDoej+zjftUPXyXy/AtpzqtCQdbiUHmtdgrR 0nAA== MIME-Version: 1.0 Received: by 10.112.10.198 with SMTP id k6mr9868274lbb.83.1343919151571; Thu, 02 Aug 2012 07:52:31 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.10.199 with HTTP; Thu, 2 Aug 2012 07:52:31 -0700 (PDT) In-Reply-To: <20120801191727.GB73640@isc.org> References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <5018D80C.90705@gmail.com> <17002.1343839952@obiwan.sandelman.ca> <30312.1343844576@obiwan.sandelman.ca> <20120801191727.GB73640@isc.org> Date: Thu, 2 Aug 2012 10:52:31 -0400 X-Google-Sender-Auth: 3C8swoYlbGoR2QaMyUjbrcw7DGs Message-ID: From: Kerry Lynn To: Evan Hunt Content-Type: multipart/alternative; boundary=e0cb4efe3502a2e4fc04c6498f72 Cc: Michael Richardson , "homenet@ietf.org" , "curtis@occnc.com" Subject: Re: [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: Thu, 02 Aug 2012 14:52:35 -0000 --e0cb4efe3502a2e4fc04c6498f72 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 1, 2012 at 3:17 PM, Evan Hunt wrote: > > Do we want applications caching mDNS replies into configuration files? > > I think not, and I think the DNS people will shout loudly about that. > > Hm... I'm a DNS people, but I'm not sure I object to this. You'd want > some mechanism for clearing old records out after the devices had been > gone from the network for a long-enough time, but that's not intrinsically > hard. > > Printing is an example, but this could apply to other apps as well (it's just that there are already millions of deployed mDNS printers about). One thing to keep in mind is that it is easier to modify the end hosts (OS providers regularly push updates) and print servers than the printers themselves. The idea assumes you need to be on-site to discover and add the printer in the first place (establishing some level of "trust" in the process). The mDNS draft enforces this by filtering out a) multicast discovery responses that don't have a link-local multicast destination address, or b) unicast responses that don't have the same source prefix as the querier. CUPS (and I presume other print systems) already cache a great deal of info about my printer and additionally caching a GUA if it was advertised does not seem a reach. Here's an example from my /etc/cups/printers.conf: UUID urn:uuid:dbb55a90-16ba-3534-5c4a-6da0e0d327a1 Info Officejet Pro 8500 A909g MakeModel HP Officejet Pro 8500 A909g Series DeviceURI dnssd://Officejet%20Pro%208500%20A909g%20%5B4C0EA4%5D._pdl-datastream._tcp.local./?bidi ... Here you see the service instance name "Officejet Pro 8500 A909g" which appears in my print dialog, together with other unique info that prevents it from being confused with yours, if you had one and I was visiting. If, at service discovery time, my printer had advertised a GUA then I'm suggesting it could have been cached as well. In that case, the print system would formulate a *unicast* DNS query to that GUA for a AAAA RR named "Officejet%20Pro%208500%20A909g%20%5B4C0EA4%5D". If a response is returned, that strongly implies the printer is reachable and no resolution is necessary (this would also solve the problem I currently have with printing to other LAN segments). If that query *fails* then indicates I need to do a fresh resolution. Here's where Michael's idea to advertise a FQDN binding (which can also be cached) comes in. But first... ** TERMINOLOGY ALERT ** I suggest we reserve the term "FQDN" to refer to names that have been fully qualified in the global DNS namespace (as they all probably were when the term was first coined) and use something like "LQDN" to refer to names that are qualified in a locally-served (non-delegated) DNS zone. ...so by FQDN I mean that the original mDNS query return something like foo.local. CNAME foo.example.com. (Yes, I realize we may need to invent some new RR to express the LQDN-to-FQDN mapping). > I regularly print to both my work and home printer remotely (yes, over > > IPv6. The CUPS server speaks IPv6 even if my home printer speaks only > > USB). > > I'm of the opinion that "remote access from offsite" should be a service > you can configure your printer to provide, but which is not the default. > > I think this is part and parcel of advertising the GUA and/or LQDN-to-FQDN mapping, as above, or not, under control of the user. Alternately, this functionality could be deployed in a print server which just connects via USB to the printer. Such a server could be tightly coupled to the client functionality and provide mutual authentication, privacy, etc. Of course, you get all these things if you just tunnel back to your site in the first place ;-) > In my ideal world (please indulge me in a moment of handwaving), you plug > in your printer, and tell it what its name is (or let it pick its own > default such as "LaserPrinter-3"); it announces itself to the local network > as providing local printing, and its name is placed in the .sitelocal > domain. > > *If* you check the box for "let the outside world print to me" -- which you > and I might want to do but most people wouldn't -- then it announces itself > as providing both local and remote printing, and its name is placed in > .sitelocal and then mirrored into the globally addressable domain that > you'd previously configured for your network: by preference, that would be > your private domain name, but if you don't have one of those then it could > mirror into a namespace controlled by your ISP, Apple, DynDNS or whatever. > > If you were printing something, and you a found a printer via service > discovery which indicate that it could provide remote access, then you'd be > given the option to bookmark its global name and use it when you're away; > if it isn't configured for remote access then you woulnd't be given that > option. > > A similar mental model could apply to the "fridge" and "lamp" examples > we've been kicking around as well -- you won't normally *want* them to be > globally accessible, but if you do, you should tell them so and let them > work it out with your network. (This is the point I was trying to make at > the mic yesterday, but I'm not sure it came across.) > > Yep. I'm pretty sure this could be accomplished by some form of "gateway" (like the print server I described above). -K- > -- > Evan Hunt -- each@isc.org > Internet Systems Consortium, Inc. > --e0cb4efe3502a2e4fc04c6498f72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Aug 1, 2012 at 3:17 PM, Evan Hunt <each@isc.org> wrote:
> Do we want applications caching mDNS replies into co= nfiguration files?
> I think not, and I think the DNS people will shout loudly about that.<= br>
Hm... I'm a DNS people, but I'm not sure I object to this. = =A0You'd want
some mechanism for clearing old records out after the devices had been
gone from the network for a long-enough time, but that's not intrinsica= lly
hard.

Printing is an example, but t= his could apply to other apps as well (it's just
that there a= re already millions of deployed mDNS printers about). =A0One thing
to keep in mind is that it is easier to modify the end hosts (OS providers<= /div>
regularly push updates) and print servers than the printers thems= elves.

The idea assumes you need to be on-sit= e to discover and add the printer
in the first place (establishing some level of "trust" in th= e process). =A0The
mDNS draft enforces this by filtering ou= t a) multicast discovery responses
that don't have a link-loc= al multicast destination address, or b) unicast
responses that don't have the same source prefix as the querier.

CUPS (and I presume other print systems) already ca= che a great deal of info
about my printer and additionally cachin= g a GUA if it was advertised does not
seem a reach. =A0Here's an example from my /etc/cups/printers.conf= :

<Printer Officejet_Pro_8500_A909g>
UUID urn:uuid:dbb55a90-16ba-3534-5c4a-6da0e0d327a1
Info O= fficejet Pro 8500 A909g
MakeModel HP Officejet Pro 8500 A909g Series
DeviceURI dnssd= ://Officejet%20Pro%208500%20A909g%20%5B4C0EA4%5D._pdl-datastream._tcp.local= ./?bidi
...
</Printer>

Here you see the service instance name "Officejet Pro 8500 A909g&= quot; which
appears in my print dialog, together with other uniqu= e info that prevents it
from being confused with yours, if you ha= d one and I was visiting.

If, at service discovery time, my printer had advertise= d a GUA then I'm
suggesting it could have been cached as well= . =A0In that case, the print system
would formulate a *unicast* D= NS query to that GUA for a AAAA RR named
"Officejet%20Pro%208500%20A909g%20%5B4C0EA4%5D". =A0If a res= ponse
is returned, that strongly implies the printer is reachable= and no resolution
is necessary (this would also solve the proble= m I currently have with printing
to other LAN segments).

If that query *fails*= then indicates I need to do a fresh resolution. =A0Here's
wh= ere Michael's idea to advertise a FQDN binding (which can also be cache= d)
comes in. =A0But first...

** TERMINOLOGY ALER= T **
I suggest we reserve the term "FQDN" to refer to n= ames that have been
fully qualified in the global DNS namespace (= as they all probably were when
the term was first coined) and use something like "LQDN" to = refer to names
that are qualified in a locally-served (non-delega= ted) DNS zone.

...so by FQDN I mean that the origi= nal mDNS query return something like
=A0 foo.local. CNAME foo.example.co= m.
(Yes, I realize we may need to invent some new RR to expre= ss the
LQDN-to-FQDN mapping).

> I regularly print to both my work and home printer remotely (yes, over=
> IPv6. The CUPS server speaks IPv6 even if my home printer speaks only<= br> > USB).

I'm of the opinion that "remote access from offsite" sh= ould be a service
you can configure your printer to provide, but which is not the default.
I think this is part and parcel of advertising the GU= A and/or LQDN-to-FQDN
mapping, as above, or not, under control of= the user. =A0Alternately, this
functionality could be deployed i= n a print server which just connects via
USB to the printer. =A0Such a server could be tightly coupled to the c= lient
functionality and provide mutual authentication, privacy, e= tc. =A0Of course,
you get all these things if you just tunnel bac= k to your site in the first place ;-)
=A0
In my ideal world (please indulge me in a moment of handwaving), you plug in your printer, and tell it what its name is (or let it pick its own
default such as "LaserPrinter-3"); it announces itself to the loc= al network
as providing local printing, and its name is placed in the .sitelocal
domain.

*If* you check the box for "let the outside world print to me" --= which you
and I might want to do but most people wouldn't -- then it announces it= self
as providing both local and remote printing, and its name is placed in
.sitelocal and then mirrored into the globally addressable domain that
you'd previously configured for your network: by preference, that would= be
your private domain name, but if you don't have one of those then it co= uld
mirror into a namespace controlled by your ISP, Apple, DynDNS or whatever.<= br>
If you were printing something, and you a found a printer via service
discovery which indicate that it could provide remote access, then you'= d be
given the option to bookmark its global name and use it when you're awa= y;
if it isn't configured for remote access then you woulnd't be given= that
option.

A similar mental model could apply to the "fridge" and "lamp= " examples
we've been kicking around as well -- you won't normally *want* them= to be
globally accessible, but if you do, you should tell them so and let them work it out with your network. =A0(This is the point I was trying to make a= t
the mic yesterday, but I'm not sure it came across.)

Yep. =A0I'm pretty sure this could be accomplished by some form= of "gateway"
(like the print server I described above)= .

-K-
--
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.

--e0cb4efe3502a2e4fc04c6498f72-- From kerlyn2001@gmail.com Thu Aug 2 08:11: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 CDACC21F84D2 for ; Thu, 2 Aug 2012 08:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.532 X-Spam-Level: X-Spam-Status: No, score=-101.532 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 UvPKfy3RI+GE for ; Thu, 2 Aug 2012 08:10:59 -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 54A5A21F8433 for ; Thu, 2 Aug 2012 08:10:59 -0700 (PDT) Received: by lagv3 with SMTP id v3so5626758lag.31 for ; Thu, 02 Aug 2012 08:10:58 -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=3zEJEuWO8A7eD75yVpn6vBXf/oQNoZ/TrwBqC7MLqbs=; b=GTWpnDHL97O562e0Ng+6b4n0LRximl5fEHPA3XHPB/TpmRqBWQYHBIdIRp8Ie1SpCh OhvG49ZbQjDHxmS8C/OjQwtVzpBmXnW4F118jX3ffBNFlZwsP+ISudc2z8wXyj+EhOwv g8gxumgyDAJXjcz+lLgbA+exlVxFBaPRTI5vU3sF91t8k+MggRrZA7uuN96aDAKibpEf ZlKjvaKDq1Z+JLF5SxjycC867Pl8kSRmNoGg2qdkxxKitG7Wzd3V7w/DBCwWj9GNf9i+ w04XeR+STcLBrLpzr/OW4d6CAGH755t49mnzGOeIpPF1GfE1HGJVQLBP/6UQS9oelt9k 9Z9Q== MIME-Version: 1.0 Received: by 10.152.136.18 with SMTP id pw18mr21791203lab.17.1343920258317; Thu, 02 Aug 2012 08:10:58 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.10.199 with HTTP; Thu, 2 Aug 2012 08:10:58 -0700 (PDT) In-Reply-To: <501965D4.1040300@globis.net> References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <5018D80C.90705@gmail.com> <501965D4.1040300@globis.net> Date: Thu, 2 Aug 2012 11:10:58 -0400 X-Google-Sender-Auth: lfT5hqf3BzRUAp2tYzkx4b--3jQ Message-ID: From: Kerry Lynn To: Ray Hunter Content-Type: multipart/alternative; boundary=f46d042f927a9a7c8404c649d1cb Cc: homenet@ietf.org, curtis@occnc.com Subject: Re: [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: Thu, 02 Aug 2012 15:11:01 -0000 --f46d042f927a9a7c8404c649d1cb Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 1, 2012 at 1:22 PM, Ray Hunter wrote: > Isn't it possible to combine the two ideas of sitelocal. with > pseudo-domains generated from ULA to give a usable solution? > > e.g. fridge..**sitelocal. > > Two points. As I mentioned at the mic yesterday, this maps onto the ULA distribution problem. You'd either have to identify a deterministic "root" ULA for this "zone" or guarantee that multiple such zones within a given site all appear as being "on-site". Second, is the unique string part of the name or a zone of the domain? mDNS recommends that all host names in .local. appear as a flat namespace, but this is only a recommendation. We humans started using surnames some time ago to disambiguate our identities regardless of location (although I note that many such attempts were of the form "O'There"). > Don't you then avoid the evilness of identifier overloading (my fridge > versus your fridge) and potential problems with clashing TLD's? > e.g. someone registering a bunch of . TLD records as > their company brand for manual administration. > > How else are homenet devices going to know not to bother the root servers > with fridge.. NS queries given that TLD's are now > basically a free for all? > > I think this is a darned good point. It saves every resolver from having to parse ".local-." to decide whether it should delegate or not. > Wouldn't it also potentially give a unique anchor point for storing DNSSEC > zone signing with an implicit sitelocal. trust anchor? > > An even better point. -K- > regards, > RayH > > > > Brian E Carpenter wrote: > >> Synthesise a pseudo-TLD from the ULA prefix. >> >> Brian >> > > > > > Brian E Carpenter wrote: > >> On 01/08/2012 05:48, Curtis Villamizar wrote: >> ... >> >>> fridge.sitelocal. is a FQDN with site local scope. >>> >> >> And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically >> evil. >> >> IMHO we shouldn't be discussing how to make it work less badly; we should >> be discussing how to avoid it entirely. >> >> Brian >> >> ______________________________**_________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/**listinfo/homenet > --f46d042f927a9a7c8404c649d1cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Aug 1, 2012 at 1:22 PM, Ray Hunter <v6ops@globis.net>= wrote:
Isn't it possible to combine the two ideas of sitelocal. with pseudo-do= mains generated from ULA to give a usable solution?

e.g. fridge.<pseudo-ula-domain>.sitelocal.

Two points. =A0As I mentioned at the mic yesterday, t= his maps onto the
ULA distribution problem. =A0You'd either h= ave to identify a deterministic
"root" ULA for this &qu= ot;zone" or guarantee that multiple such zones within
a given site all appear as being "on-site". =A0Second, is th= e unique string
part of the name or a zone of the domain? =A0mDNS= recommends that all
host names in .local. appear as a flat names= pace, but this is only a
recommendation. =A0We humans started using surnames some time ago
to disambiguate our identities regardless of location (although I not= e that
many such attempts were of the form "O'There"= ;).
=A0
Don't you then avoid the evilness of identifier overloading (my fridge = versus your fridge) and potential problems with clashing TLD's?
e.g. someone registering a bunch of <pseudo-ula-domain>. TLD records = as their company brand for manual administration.

How else are homenet devices going to know not to bother the root servers w= ith fridge.<pseudo-ula-domain>. NS queries given that TLD's are n= ow basically a free for all?

I think this is a darned good point. =A0It saves ever= y resolver from having
to parse ".local-<mumble>."= ; to decide whether it should delegate or not.
=A0
Wouldn't it also potentially give a unique anchor point for storing DNS= SEC zone signing with an implicit sitelocal. trust anchor?

An even better point.

-K-
=A0
regards,
RayH



Brian E Carpenter wrote:
Synthesise a pseudo-TLD from the ULA prefix.

=A0 =A0 =A0Brian




Brian E Carpenter wrote:
On 01/08/2012 05:48, Curtis Villamizar wrote:
...
fridge.sitelocal. is a FQDN with site local scope.

And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil.

IMHO we shouldn't be discussing how to make it work less badly; we shou= ld
be discussing how to avoid it entirely.

=A0 =A0 =A0Brian

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

--f46d042f927a9a7c8404c649d1cb-- From kerlyn2001@gmail.com Thu Aug 2 07:57: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 E063111E80C5 for ; Thu, 2 Aug 2012 07:57:42 -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 LfgnBLZKZO-F for ; Thu, 2 Aug 2012 07:57:42 -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 F2BDE11E8072 for ; Thu, 2 Aug 2012 07:57:41 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1108559lbb.31 for ; Thu, 02 Aug 2012 07:57:41 -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=aYZvUFQlwlbCLnVize3V1o6aORL5fWoj/av/feDezyY=; b=APV77xwEeLqjZqParLPX5YHgaa87DK+GHv6fiOGkwe+ZHxVjEiaxNUqVeZHu9AebpI 7TqOaWIRc567pJksnWMMBW90W0vAgt7klMd+iXGJ//nImAEPP6PQLu52p/pJ1CYFaAdC RAUfPeG2ydixJMkfW2BV93qn94NKPxwZIU3s90VM0B9P0mc+HFBuD19aNy4M6KLTKNON h9E5G5iX8cMIGLWJJroC0ZPOO0J21PoRiu3rtzH2lHy7wA2Aa0++74idxPaCjGBDPZxP pJzzJRiZexwcOK9XTLEYEJWoLeq+bhi7w/N6Qo2kA5OoFTju+n172f4a7g/7bZu1TFKY GTGA== MIME-Version: 1.0 Received: by 10.112.40.33 with SMTP id u1mr9782709lbk.28.1343919460927; Thu, 02 Aug 2012 07:57:40 -0700 (PDT) Received: by 10.112.10.199 with HTTP; Thu, 2 Aug 2012 07:57:40 -0700 (PDT) In-Reply-To: <30312.1343844576@obiwan.sandelman.ca> References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <5018D80C.90705@gmail.com> <17002.1343839952@obiwan.sandelman.ca> <30312.1343844576@obiwan.sandelman.ca> Date: Thu, 2 Aug 2012 10:57:40 -0400 Message-ID: From: Kerry Lynn To: Michael Richardson Content-Type: multipart/alternative; boundary=e0cb4efe306013495304c649a225 X-Mailman-Approved-At: Thu, 02 Aug 2012 16:20:58 -0700 Cc: "homenet@ietf.org" , "curtis@occnc.com" Subject: Re: [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: Thu, 02 Aug 2012 14:57:43 -0000 --e0cb4efe306013495304c649a225 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 1, 2012 at 2:09 PM, Michael Richardson wrote: > Kerry> BTW, I agree with the earlier comment that the may be several > Kerry> good reasons to include VPN tunnels in the homenet > Kerry> architecture. > > They exist. It would be nice if our secure setup protocol for homenet > could also be leveraged to setup remote access. > > The VLAN service access point may be the only thing I (and perhaps many others) would ever want to advertise in the global DNS namespace. -K- -- > Michael Richardson , Sandelman Software Works > > > --e0cb4efe306013495304c649a225 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Aug 1, 2012 at 2:09 PM, Michael Richardson <mcr+ietf@sandelman= .ca> wrote:

<snip>
=A0
=A0 =A0 Kerry> BTW, I agree with the earlier comment that the may be sev= eral
=A0 =A0 Kerry> good reasons to include VPN tunnels in the homenet
=A0 =A0 Kerry> architecture.

They exist. It would be nice if our secure setup protocol for homenet
could also be leveraged to setup remote access.

T= he VLAN service access point may be the only thing I (and perhaps many
others) would ever want to advertise in the global DNS namespace.

-K-

=
--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works



--e0cb4efe306013495304c649a225-- From swmike@swm.pp.se Thu Aug 2 22:44: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 85D4511E80D5 for ; Thu, 2 Aug 2012 22:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 m14ikQQHQCP7 for ; Thu, 2 Aug 2012 22:44:53 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id E678211E80B8 for ; Thu, 2 Aug 2012 22:44:52 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0688E9C; Fri, 3 Aug 2012 07:44:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 023F19A; Fri, 3 Aug 2012 07:44:51 +0200 (CEST) Date: Fri, 3 Aug 2012 07:44:50 +0200 (CEST) From: Mikael Abrahamsson To: Michael Richardson In-Reply-To: <8469.1343917104@obiwan.sandelman.ca> Message-ID: References: <201208011439.q71Ed183005154@gateway.ipv6.occnc.com> <501A502D.30408@gmail.com> <8469.1343917104@obiwan.sandelman.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] forced renumbering in the home (was Re: 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: Fri, 03 Aug 2012 05:44:53 -0000 On Thu, 2 Aug 2012, Michael Richardson wrote: > Linux too, and sometimes this is a bad thing. > If you suspend/resume between home/work wired, I've had the problem > where I can't reach the other because said address still lingering on > interface makes my laptop think it's still "on the wire" with both. > (you have to suspend-then-unplug, otherwise, disconnecting the cable > works as a clue to flush the addresses) I complained about this on ubuntu before, and at least the connection manager in Ubuntu 12.04 does the right thing now. -- Mikael Abrahamsson email: swmike@swm.pp.se From curtis@occnc.com Sat Aug 4 13:06: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 9AB0B21F87EA for ; Sat, 4 Aug 2012 13:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.169, 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 1DOBO-VxYios for ; Sat, 4 Aug 2012 13:06: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 D9C0021F87E0 for ; Sat, 4 Aug 2012 13:06:49 -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 q74K62U9060674; Sat, 4 Aug 2012 16:06:02 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208042006.q74K62U9060674@gateway.ipv6.occnc.com> To: Ray Hunter From: Curtis Villamizar In-reply-to: Your message of "Wed, 01 Aug 2012 19:22:28 +0200." <501965D4.1040300@globis.net> Date: Sat, 04 Aug 2012 16:06:02 -0400 Cc: homenet@ietf.org, curtis@occnc.com 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: Sat, 04 Aug 2012 20:06:50 -0000 With all due respect, any suggestion to use the ULA in a domain name produces either a domain that is unique to one host or a domain that is every bit as global as sitelocal, depending on whether by stating "ULA prefix" you mean the local ULA or the well-known global ULA prefix. In rfc4193: Local IPv6 unicast addresses have the following characteristics: - Globally unique prefix (with high probability of uniqueness). - Well-known prefix to allow for easy filtering at site boundaries. [...] If you mean the first (the local ULA prefix), then the domain is unique to one host. My computer could never find my fridge using the hostname "fridge" unless it knew every ULA on the local network and created an entry in the dns search path. Very long entries in the dns search path are a very bad thing (tm). If you means the second (the assigned prefix under which all ULA fall) then the domain is common to all hosts in the universe that generate a ULA address. The only difference is it is ..sitelocal. Curtis In message <501965D4.1040300@globis.net> Ray Hunter writes: > Isn't it possible to combine the two ideas of sitelocal. with > pseudo-domains generated from ULA to give a usable solution? > > e.g. fridge..sitelocal. > > Don't you then avoid the evilness of identifier overloading (my fridge > versus your fridge) and potential problems with clashing TLD's? > e.g. someone registering a bunch of . TLD records as > their company brand for manual administration. > > How else are homenet devices going to know not to bother the root > servers with fridge.. NS queries given that TLD's are > now basically a free for all? > > Wouldn't it also potentially give a unique anchor point for storing > DNSSEC zone signing with an implicit sitelocal. trust anchor? > > regards, > RayH > > > Brian E Carpenter wrote: > > Synthesise a pseudo-TLD from the ULA prefix. > > > > Brian > > > > > Brian E Carpenter wrote: > > On 01/08/2012 05:48, Curtis Villamizar wrote: > > ... > >> fridge.sitelocal. is a FQDN with site local scope. > > > > And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil. > > > > IMHO we shouldn't be discussing how to make it work less badly; we should > > be discussing how to avoid it entirely. > > > > Brian From Dmitry.Anipko@microsoft.com Sat Aug 4 17:19: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 B7E7A21F880C for ; Sat, 4 Aug 2012 17:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 RQtcQjoCWAww for ; Sat, 4 Aug 2012 17:19:04 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 60D9121F876A for ; Sat, 4 Aug 2012 17:19:03 -0700 (PDT) Received: from mail115-db3-R.bigfish.com (10.3.81.230) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Sun, 5 Aug 2012 00:19:01 +0000 Received: from mail115-db3 (localhost [127.0.0.1]) by mail115-db3-R.bigfish.com (Postfix) with ESMTP id 9B17E3E0229 for ; Sun, 5 Aug 2012 00:19:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371I542M1432Izz1202hzz1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah107ah) Received-SPF: pass (mail115-db3: 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=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.244.37; KIP:(null); UIP:(null); (null); H:CH1PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail115-db3 (localhost.localdomain [127.0.0.1]) by mail115-db3 (MessageSwitch) id 1344125939560876_23086; Sun, 5 Aug 2012 00:18:59 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.252]) by mail115-db3.bigfish.com (Postfix) with ESMTP id 87246480055 for ; Sun, 5 Aug 2012 00:18:59 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 5 Aug 2012 00:18:59 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.309.3; Sun, 5 Aug 2012 00:18:58 +0000 Received: from mail89-ch1-R.bigfish.com (10.43.68.226) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Sun, 5 Aug 2012 00:18:57 +0000 Received: from mail89-ch1 (localhost [127.0.0.1]) by mail89-ch1-R.bigfish.com (Postfix) with ESMTP id 5D7B81C02A7 for ; Sun, 5 Aug 2012 00:18:57 +0000 (UTC) Received: from mail89-ch1 (localhost.localdomain [127.0.0.1]) by mail89-ch1 (MessageSwitch) id 1344125935348056_18075; Sun, 5 Aug 2012 00:18:55 +0000 (UTC) Received: from CH1EHSMHS037.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.225]) by mail89-ch1.bigfish.com (Postfix) with ESMTP id 51AA64201B4; Sun, 5 Aug 2012 00:18:55 +0000 (UTC) Received: from CH1PRD0310HT004.namprd03.prod.outlook.com (157.56.244.37) by CH1EHSMHS037.bigfish.com (10.43.69.246) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 5 Aug 2012 00:18:54 +0000 Received: from CH1PRD0310MB368.namprd03.prod.outlook.com ([169.254.11.46]) by CH1PRD0310HT004.namprd03.prod.outlook.com ([10.255.137.39]) with mapi id 14.16.0175.005; Sun, 5 Aug 2012 00:18:54 +0000 From: Dmitry Anipko To: "curtis@occnc.com" Thread-Topic: [homenet] homenet hosts security requirements and realm discovery Thread-Index: AQHNb2PUmlvEWJ2IHU2z9gfdTrH+5JdKU7Zg Date: Sun, 5 Aug 2012 00:18:54 +0000 Message-ID: <96DD85EB136DCD49AB5CDB6DEC9639AD120ED973@CH1PRD0310MB368.namprd03.prod.outlook.com> References: Your message of "Tue, 31 Jul 2012 02:10:02 -0000." <96DD85EB136DCD49AB5CDB6DEC9639AD120CEB1B@CH1PRD0310MB368.namprd03.prod.outlook.com> <201207312130.q6VLUk1c083981@gateway.ipv6.occnc.com> In-Reply-To: <201207312130.q6VLUk1c083981@gateway.ipv6.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: CH1PRD0310HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%OCCNC.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com 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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 00:19:04 -0000 Hi Curtis, Re terminology, I used the term "realm" as it is defined/used in draft-ietf= -homenet-arch-04, and not in some other meaning. I think there are two majo= r points in your email I want to comment on: 1. Whether or not the draft already provides that realm information is avai= lable to all participants of the homenet, including hosts. 2. Whether or not security decisions made on hosts can or should use/be bas= ed on such realm information. On the first point, I agree that the text in section 3.3.1 could be underst= ood in a way that the realm information is known to the homenet and hence h= osts can access it. However I think the current text is fairly high level a= nd can also be understood differently - that e.g. *routers*, which happened= to be on the respective borders, shall be able to discover those borders o= f the realms and perform filtering correspondingly to the definition of rea= lms. If sharing of the realm information with all participants of the homen= et is already implied by 3.3.1, there should be no issue to say that more e= xplicitly. For the second point: The current text says in 3.3.1 that " then the borders will include ...that= from the homenet to a guest network...for an appropriate default policy to= be applied as to what type of traffic/data can flow across such borders" T= his seems to match the intuitive meaning of "guest" vs "homenet" realms, wh= ich implies that "guest" doesn't have exactly the same access as "homenet".= The text I'd like to see added would simply provide that hosts, which opte= d into transparent communication, are able to implement the same richness a= nd easiness of access control as the routers do.=20 Also, a typical user can understand that they need provide credentials when= they are remote (i.e. coming from the Internet, from outside of "their net= work"), but they often have hard time to understand why they or their visit= ing mom who they joined to home WiFi are also asked to provide user creds i= f they are already connected to their own network either using cable or sec= ure WiFi, and they've chosen previously "share with everyone at home". For= better or worse, today physical proximity matters and layer 2 access contr= ol is often perceived as easier to understand and use rather than layer 7 a= uthentication (that of course also means, we have work to do :) ). And sect= ion 3.6.3 doesn't prohibit such usage of realm information. -Dmitry -----Original Message----- From: Curtis Villamizar [mailto:curtis@occnc.com]=20 Sent: Tuesday, July 31, 2012 2:31 PM To: Dmitry Anipko Cc: homenet@ietf.org Subject: Re: [homenet] homenet hosts security requirements and realm discov= ery In message <96DD85EB136DCD49AB5CDB6DEC9639AD120CEB1B@CH1PRD0310MB368.namprd= 03.prod.outlook.com> Dmitry Anipko writes: =20 > 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. > =20 > 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". > =20 > Is there already a section that implies such requirement, or if not, > are there concerns with adding such requirement to the draft? > =20 > -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 v6ops@globis.net Sat Aug 4 23:59: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 0F2AB21F876A for ; Sat, 4 Aug 2012 23:59:19 -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 BVWJqkhvfYrq for ; Sat, 4 Aug 2012 23:59:18 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id DB56E21F8723 for ; Sat, 4 Aug 2012 23:59:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 325798700BB; Sun, 5 Aug 2012 08:59:01 +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 TrymFs6smVoD; Sun, 5 Aug 2012 08:58:40 +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 3A26C87005C; Sun, 5 Aug 2012 08:58:40 +0200 (CEST) Message-ID: <501E199A.4060607@globis.net> Date: Sun, 05 Aug 2012 08:58:34 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: curtis@occnc.com References: <201208042006.q74K62U9060674@gateway.ipv6.occnc.com> In-Reply-To: <201208042006.q74K62U9060674@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [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: Sun, 05 Aug 2012 06:59:19 -0000 I disagree. The context of my message is that there should be some identifier that can disambiguate the namespace per Homenet. I'm talking about using the ULA to generate a HomenetID for use in the namespace. See RFC6281. The HomenetID and DNS subomain (or as you put it "") may be generated by one unique host (e.g. each Homenet border router) based on a ULA. But that does not mean it cannot be discovered by all hosts and routers in the Homenet (via some bunch of discovery mechanisms such as automatic prefix distribution for router-router and DHCPv6 for router - fridge). The HomenetID will remain constant as long as the ULA of the border router remains constant. If it appears to vary (because the border router changes) then highly mobile nodes will get some indication that they may not be connected to their own Homenet, and ask for user input to accept an update. Static nodes would only know their local HomenetID, and if it changed they could be set to always accept the update without user input. Eventually you would probably end up with a search list linked to the number of border routers the end node has ever encountered, but end nodes can automatically age out old entries. We might also want to be able to manually override the auto-generated HomenetID to cover the case where border router hardware is replaced by the user, but that's no different to MAC address cloning on CPE's in the past (where ISPs used the MAC address of the CPE as an identifier in management systems). Sure there's a downside in complexity of the namespace. The potential upside of this approach is that the same .sitelocal. zone file could also be mounted as a secondary on . or . if the ISP or enterprise wished to provide this service for global name resolution. Highly mobile nodes would only need two items in their DNS search list, the search list can be pretty much auto-generated, and they can use the same name resolution technology (DNS) wherever they are located. It also completely avoids trying to synch mDNS with DNS, which I think you'll agree is likely to be very difficult. > Curtis Villamizar > 4 August 2012 22:06 > With all due respect, any suggestion to use the ULA in a domain name > produces either a domain that is unique to one host or a domain that > is every bit as global as sitelocal, depending on whether by stating > "ULA prefix" you mean the local ULA or the well-known global ULA > prefix. > > In rfc4193: > > Local IPv6 unicast addresses have the following characteristics: > > - Globally unique prefix (with high probability of uniqueness). > > - Well-known prefix to allow for easy filtering at site > boundaries. > > [...] > > If you mean the first (the local ULA prefix), then the domain is > unique to one host. My computer could never find my fridge using the > hostname "fridge" unless it knew every ULA on the local network and > created an entry in the dns search path. Very long entries in the dns > search path are a very bad thing (tm). > > If you means the second (the assigned prefix under which all ULA fall) > then the domain is common to all hosts in the universe that generate a > ULA address. The only difference is it is > ..sitelocal. > > Curtis > > > In message <501965D4.1040300@globis.net> > ------------------------------------------------------------------------ From brian.e.carpenter@gmail.com Sun Aug 5 00:22: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 A0D1621F86B6 for ; Sun, 5 Aug 2012 00:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.467 X-Spam-Level: X-Spam-Status: No, score=-101.467 tagged_above=-999 required=5 tests=[AWL=0.224, 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 Nlukl33VHLyF for ; Sun, 5 Aug 2012 00:22:55 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id D3EAF21F86AA for ; Sun, 5 Aug 2012 00:22:53 -0700 (PDT) Received: by wibhq12 with SMTP id hq12so670019wib.1 for ; Sun, 05 Aug 2012 00:22:53 -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=0k72A01GLnYclAaS80rAJx1g1GlMZ5DYeshZfRCjo4A=; b=GKcjcs2MyNgMYOuvuQxuDmIPtvZQVtMFOX54GwLw+YK4LeMTeUoz17ig87Pmunz29I cuW6fKAmWIEkIY3ntC+SH2XcohHZ0g8bFzm6/k8IgwsxAlHjo7TBIZ9yUaPP7hSQ7gf6 YglQt6M0GP4Qq7Z6WM0o5WmJ3i7zRt9hHFQcTVnhxfSJwoCFzdbrOfp9Q5hnLwu2ZlPi WWgFNqDLCaxTxg2CpuSrrfxBuk2mF+x7hiIcs3HNw4Pt+F4bQ6tacN+D8I12sdBIRKLV 5e30tUmXwPp3Oq98M3iEBvHoPH+S2NVGEUZmdfdZKWTo4zD3vhIsHiCs6VSu5P+lL6Wj XG6Q== Received: by 10.216.242.204 with SMTP id i54mr3858072wer.114.1344151372984; Sun, 05 Aug 2012 00:22:52 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-214.as13285.net. [2.102.218.214]) by mx.google.com with ESMTPS id ef5sm11741520wib.3.2012.08.05.00.22.50 (version=SSLv3 cipher=OTHER); Sun, 05 Aug 2012 00:22:51 -0700 (PDT) Message-ID: <501E1F44.2030302@gmail.com> Date: Sun, 05 Aug 2012 08:22:44 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter References: <201208042006.q74K62U9060674@gateway.ipv6.occnc.com> <501E199A.4060607@globis.net> In-Reply-To: <501E199A.4060607@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, curtis@occnc.com Subject: Re: [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: Sun, 05 Aug 2012 07:22:55 -0000 On 05/08/2012 07:58, Ray Hunter wrote: > I disagree. The context of my message is that there should be some > identifier that can disambiguate the namespace per Homenet. That's what I meant too. The only point is to avoid ambiguity in the namespace. The only reason for using a ULA prefix to create a unique identifier string is to avoid the bother of inventing a new method of creating a unique identifier string. The name has no relation to addressing or routing whatever. If you prefer some other way of creating a string with a very high probability of uniqueness, that's fine. Brian > I'm talking > about using the ULA to generate a HomenetID for use in the namespace. > See RFC6281. > > The HomenetID and DNS subomain (or as you put it > "") may be generated by one unique host (e.g. each > Homenet border router) based on a ULA. But that does not mean it cannot > be discovered by all hosts and routers in the Homenet (via some bunch of > discovery mechanisms such as automatic prefix distribution for > router-router and DHCPv6 for router - fridge). > > The HomenetID will remain constant as long as the ULA of the border > router remains constant. If it appears to vary (because the border > router changes) then highly mobile nodes will get some indication that > they may not be connected to their own Homenet, and ask for user input > to accept an update. Static nodes would only know their local HomenetID, > and if it changed they could be set to always accept the update without > user input. Eventually you would probably end up with a search list > linked to the number of border routers the end node has ever > encountered, but end nodes can automatically age out old entries. > > We might also want to be able to manually override the auto-generated > HomenetID to cover the case where border router hardware is replaced by > the user, but that's no different to MAC address cloning on CPE's in the > past (where ISPs used the MAC address of the CPE as an identifier in > management systems). > > Sure there's a downside in complexity of the namespace. The potential > upside of this approach is that the same > .sitelocal. zone file could also be mounted as a > secondary on . or > . if the ISP or enterprise > wished to provide this service for global name resolution. Highly mobile > nodes would only need two items in their DNS search list, the search > list can be pretty much auto-generated, and they can use the same name > resolution technology (DNS) wherever they are located. It also > completely avoids trying to synch mDNS with DNS, which I think you'll > agree is likely to be very difficult. > >> Curtis Villamizar >> 4 August 2012 22:06 >> With all due respect, any suggestion to use the ULA in a domain name >> produces either a domain that is unique to one host or a domain that >> is every bit as global as sitelocal, depending on whether by stating >> "ULA prefix" you mean the local ULA or the well-known global ULA >> prefix. >> >> In rfc4193: >> >> Local IPv6 unicast addresses have the following characteristics: >> >> - Globally unique prefix (with high probability of uniqueness). >> >> - Well-known prefix to allow for easy filtering at site >> boundaries. >> >> [...] >> >> If you mean the first (the local ULA prefix), then the domain is >> unique to one host. My computer could never find my fridge using the >> hostname "fridge" unless it knew every ULA on the local network and >> created an entry in the dns search path. Very long entries in the dns >> search path are a very bad thing (tm). >> >> If you means the second (the assigned prefix under which all ULA fall) >> then the domain is common to all hosts in the universe that generate a >> ULA address. The only difference is it is >> ..sitelocal. >> >> Curtis >> >> >> In message <501965D4.1040300@globis.net> >> ------------------------------------------------------------------------ > > From mike@mtcc.com Sun Aug 5 08:18: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 B135621F848F for ; Sun, 5 Aug 2012 08:18:02 -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 k3PaHZ1bS79S for ; Sun, 5 Aug 2012 08:18: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 EFB3221F84A2 for ; Sun, 5 Aug 2012 08:18:01 -0700 (PDT) Received: from piolinux.mtcc.com (65-172-208-69.dsl.volcano.net [65.172.208.69]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q75FHeLY025327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Aug 2012 08:17:40 -0700 Message-ID: <501E8E90.80003@mtcc.com> Date: Sun, 05 Aug 2012 08:17:36 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Brian E Carpenter References: <201208042006.q74K62U9060674@gateway.ipv6.occnc.com> <501E199A.4060607@globis.net> <501E1F44.2030302@gmail.com> In-Reply-To: <501E1F44.2030302@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=1621; t=1344179861; x=1345043861; 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]=20tunnels=20as=20way=20to=20d isambiguate=20.local |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=SQ7rWNsgOn1C9IQak4Gz3R3w9eJu6dDYJf5xRhF6s+g=; b=qgowuTSlT67aJaKJS62Uf5jTYZRyHtp4UKxp+bqjdrf/a4icbZAxSsmucn /6jPDsgV9cTjOl+MOBkkvtNOSbRSUJIoiBGVNGBDQDUVKiRJVBAK8Kz0m5N1 QVLHC/5sDmwrPUKvGHfCFUPPxMf0bXuf8/kvbZuppik6xRC1f4Y44=; 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: Ray Hunter , homenet@ietf.org, curtis@occnc.com Subject: Re: [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: Sun, 05 Aug 2012 15:18:02 -0000 Brian E Carpenter wrote: > On 05/08/2012 07:58, Ray Hunter wrote: >> I disagree. The context of my message is that there should be some >> identifier that can disambiguate the namespace per Homenet. > > That's what I meant too. The only point is to avoid ambiguity in the > namespace. The only reason for using a ULA prefix to create a unique > identifier string is to avoid the bother of inventing a new method of > creating a unique identifier string. The name has no relation to > addressing or routing whatever. If you prefer some other way of creating > a string with a very high probability of uniqueness, that's fine. So I think I understand the point of a ULA like suffix. However, that doesn't translate into a name that anybody would use. Locally, you could just have it as part of the DNS search list, I suppose, but that's limited to resources that are accessed locally which .local more or less works now. So it seems a small gain with some ugliness to boot. What I really want though is to have resources that I can access regardless of where I am though. I don't see how this is of any help at all for that problem. The only thing I see is that either I make the name globally accessible -- in which case I'd use a real DNS name, or to make myself topologically part of the .local[site] namespace. Isn't that what this all boils down to? TANSTAAFL? Mike PS: the 40 bits of a ULA was constrained by v6 prefix length. if we were to do this for sitelocal, we'd probably want to add some bits to better cope with the birthday paradox. iirc, 64 bits is a lot safer. From brian.e.carpenter@gmail.com Sun Aug 5 11:32: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 E017221F84F2 for ; Sun, 5 Aug 2012 11:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.469 X-Spam-Level: X-Spam-Status: No, score=-101.469 tagged_above=-999 required=5 tests=[AWL=0.222, 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 qAMUI53KNwpk for ; Sun, 5 Aug 2012 11:32:30 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED69221F84EB for ; Sun, 5 Aug 2012 11:32:29 -0700 (PDT) Received: by weyu54 with SMTP id u54so1704581wey.31 for ; Sun, 05 Aug 2012 11:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lNfdqyIbbrxsbH/SyOpNOfAqtafKK3G8R3cB6Qqlr/k=; b=yTiu0/93pcDuAXvnhHQM216I5kT1VkGCE+k/v7Y4fZ70tfWqFBRp+9JGX2NI+USgpr /rW+RA2baQDz3KbLXJF1Gcb7P/0OOXGUKd36V7rWG7v/ExJjmE/yugdeSDyZ0xl7NEwq YVINAXOLpJo/mWdEAivRfWl7+zqTGle+eqYZCBgAkKn3g+9/eXRdH4EXSuMhwDZohEXZ uhr8t2IiP19krFbA2eB6cOJWqSk1pOlv6HmjbCzeOL9oSnq+RIPC9nZAckBAjyf0Zy5s q75cnMrWybXCPzJ3eaAfu2rqlL9kwy5uJtG70lIvmKsMIBNj0GQXxLw7twvHooE3VF2l ub4g== Received: by 10.180.14.34 with SMTP id m2mr11987676wic.21.1344191546086; Sun, 05 Aug 2012 11:32:26 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-214.as13285.net. [2.102.218.214]) by mx.google.com with ESMTPS id fb20sm16292637wid.1.2012.08.05.11.32.24 (version=SSLv3 cipher=OTHER); Sun, 05 Aug 2012 11:32:25 -0700 (PDT) Message-ID: <501EBC38.2090801@gmail.com> Date: Sun, 05 Aug 2012 19:32:24 +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: <201208042006.q74K62U9060674@gateway.ipv6.occnc.com> <501E199A.4060607@globis.net> <501E1F44.2030302@gmail.com> <501E8E90.80003@mtcc.com> In-Reply-To: <501E8E90.80003@mtcc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ray Hunter , homenet@ietf.org, curtis@occnc.com Subject: Re: [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: Sun, 05 Aug 2012 18:32:31 -0000 Regards Brian Carpenter On 05/08/2012 16:17, Michael Thomas wrote: > Brian E Carpenter wrote: >> On 05/08/2012 07:58, Ray Hunter wrote: >>> I disagree. The context of my message is that there should be some >>> identifier that can disambiguate the namespace per Homenet. >> >> That's what I meant too. The only point is to avoid ambiguity in the >> namespace. The only reason for using a ULA prefix to create a unique >> identifier string is to avoid the bother of inventing a new method of >> creating a unique identifier string. The name has no relation to >> addressing or routing whatever. If you prefer some other way of creating >> a string with a very high probability of uniqueness, that's fine. > > So I think I understand the point of a ULA like suffix. However, that doesn't > translate into a name that anybody would use. Locally, you could just have it > as part of the DNS search list, I suppose, but that's limited to resources > that are accessed locally which .local more or less works now. So it seems a > small gain with some ugliness to boot. I don't think that elminating ambguity in scope is a small gain. The best defence we have against ambiguous addresses is an unambiguous namespace. > What I really want though is to have resources that I can access regardless of > where I am though. I don't see how this is of any help at all for that problem. At least it will *tell* you that the FQDN is meaningless where you are, if you are out of the homenet. > The only thing I see is that either I make the name globally accessible -- in which > case I'd use a real DNS name, Absolutely - a local namespace is always second best to a genuine FQDN. > or to make myself topologically part of the .local[site] > namespace. Right - and giving it a unique name can only help in that process. Brian Isn't that what this all boils down to? TANSTAAFL? > > Mike > > PS: the 40 bits of a ULA was constrained by v6 prefix length. if we were > to do this > for sitelocal, we'd probably want to add some bits to better cope > with the birthday paradox. > iirc, 64 bits is a lot safer. > From tjc@ecs.soton.ac.uk Sun Aug 5 14:12: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 4DABE21F850D for ; Sun, 5 Aug 2012 14:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 CCLnoUlyXPGi for ; Sun, 5 Aug 2012 14:12:53 -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 50E6621F8501 for ; Sun, 5 Aug 2012 14:12:50 -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 q75LClV1002598 for ; Sun, 5 Aug 2012 22:12:47 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q75LClV1002598 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1344201167; bh=OOXS8DD+FdRsF/EuT73+pQHSvJs=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=DlwhLWs2dcubsb9gRd6U6/hHA2wIH7m25y4Ac7fiB0TTvfzpf/0b9cBnznd9lrY6D izDClz4wzktaF9yKsoCLjmeX7EufbuTsgGQmOMY61c1zdr8m0n5YHhDptdy2bCX77A EBfTxdhB+4HTD6z8IX/fD9pZPKCaTD6JqMjPoXQ4= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id o74MCl043064901222 ret-id none; Sun, 05 Aug 2012 22:12:47 +0100 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q75LCeoZ026445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 5 Aug 2012 22:12:40 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Tim Chown In-Reply-To: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> Date: Sun, 5 Aug 2012 22:12:38 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1485) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o74MCl043064901200; tid=o74MCl043064901222; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q75LClV1002598 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [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: Sun, 05 Aug 2012 21:12:54 -0000 On 1 Aug 2012, at 05:48, Curtis Villamizar wrote: > fridge.sitelocal. is a FQDN with site local scope. fridge.yourdomain > is a FQDN with global scope. The apparent consensus in Vancouver was to use a global domain if you = have one available otherwise use an "auto-generated" unique local = domain. Tim From each@isc.org Sun Aug 5 19:07: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 C84DE21F854A for ; Sun, 5 Aug 2012 19:07:11 -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 dD0GFWcsUvn7 for ; Sun, 5 Aug 2012 19:07: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 1BD8C21F8577 for ; Sun, 5 Aug 2012 19:07: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 CB5965F98B9; Mon, 6 Aug 2012 02:06:58 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id F173B216C36; Mon, 6 Aug 2012 02:06:56 +0000 (UTC) Date: Mon, 6 Aug 2012 02:06:56 +0000 From: Evan Hunt To: Tim Chown Message-ID: <20120806020656.GA88914@isc.org> References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "homenet@ietf.org Group" Subject: Re: [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: Mon, 06 Aug 2012 02:07:12 -0000 > > fridge.sitelocal. is a FQDN with site local scope. fridge.yourdomain > > is a FQDN with global scope. > > The apparent consensus in Vancouver was to use a global domain if you > have one available I agree there was consensus on this point. > otherwise use an "auto-generated" unique local domain. ...but I did not hear a clear consensus on this one. (For the record, though I'm open to being convinced otherwise, my current preference is for a reserved generic namespace such as ".local" and/or ".sitelocal", and *not* for ULA-style domains.) -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From mellon@fugue.com Sun Aug 5 19:18: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 9EC0521F853F for ; Sun, 5 Aug 2012 19:18:38 -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 WFEHtSAxmiW3 for ; Sun, 5 Aug 2012 19:18:38 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD0D21F8523 for ; Sun, 5 Aug 2012 19:18:38 -0700 (PDT) Received: from agape-4.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 65F3B238069B; Sun, 5 Aug 2012 22:18:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_0FDAD889-5FF5-4770-8153-DC23B68DB35F" From: Ted Lemon In-Reply-To: <20120806020656.GA88914@isc.org> Date: Sun, 5 Aug 2012 22:18:34 -0400 Message-Id: References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> To: Evan Hunt X-Mailer: Apple Mail (2.1283) Cc: Tim Chown , "homenet@ietf.org Group" Subject: Re: [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: Mon, 06 Aug 2012 02:18:39 -0000 --Apple-Mail=_0FDAD889-5FF5-4770-8153-DC23B68DB35F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 5, 2012, at 10:06 PM, Evan Hunt wrote: > (For the record, though I'm open to being convinced otherwise, > my current preference is for a reserved generic namespace such > as ".local" and/or ".sitelocal", and *not* for ULA-style domains.) i wasn't able to participate in this discussion because I had other = business during homenet, but I'm a bit frustrated by this conclusion. = Domains like .local seem like a good idea to geeks like us, but how many = regular users ever use them? How many have a mental model of how = naming works that would allow these domains to function for them? IMHO, we shouldn't promote bad solutions, and .local is a bad solution. = Whether we come up with some way to leverage a ULA to present things = sensibly in some UI is another question, but if we are trying to come up = with a solution for geeks, why not come up with a _real_ solution, = instead of the .local hack? --Apple-Mail=_0FDAD889-5FF5-4770-8153-DC23B68DB35F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii (For the = record, though I'm open to being convinced otherwise,
my current = preference is for a reserved generic namespace such
as ".local" = and/or ".sitelocal", and *not* for ULA-style = domains.)

i wasn't able to participate = in this discussion because I had other business during homenet, but I'm = a bit frustrated by this conclusion.   Domains like .local seem = like a good idea to geeks like us, but how many regular users ever use = them?   How many have a mental model of how naming works that would = allow these domains to function for them?

IMHO, = we shouldn't promote bad solutions, and .local is a bad solution.   = Whether we come up with some way to leverage a ULA to present things = sensibly in some UI is another question, but if we are trying to come up = with a solution for geeks, why not come up with a _real_ solution, = instead of the .local hack?

= --Apple-Mail=_0FDAD889-5FF5-4770-8153-DC23B68DB35F-- From each@isc.org Sun Aug 5 20:28:49 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 A844121F8501 for ; Sun, 5 Aug 2012 20:28:49 -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 rLFFUiw2vx1i for ; Sun, 5 Aug 2012 20:28:49 -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 276D221F84A6 for ; Sun, 5 Aug 2012 20:28:49 -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 6C0945F98A2; Mon, 6 Aug 2012 03:28:34 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id D2955216C36; Mon, 6 Aug 2012 03:28:32 +0000 (UTC) Date: Mon, 6 Aug 2012 03:28:32 +0000 From: Evan Hunt To: Ted Lemon Message-ID: <20120806032832.GA89953@isc.org> References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Tim Chown , "homenet@ietf.org Group" Subject: Re: [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: Mon, 06 Aug 2012 03:28:49 -0000 > i wasn't able to participate in this discussion because I had other > business during homenet, but I'm a bit frustrated by this conclusion. I was speaking for myself and I believe the issue is in flux; please don't take it as a "conclusion". :) > IMHO, we shouldn't promote bad solutions, and .local is a bad solution. IMHO . is also a bad solution. It's, at least potentially, a worse one: you buy a new router, and suddenly your devices all have new names and your bookmarks don't work. To make them work again, you have to remember the hexidecimal-gibberish that was assigned by your previous router and configure it to use the same one. Ugly. I'm not really happy with either of these choices, but I'm less unhappy with .sitelocal. > Whether we come up with some way to leverage a ULA to present things > sensibly in some UI is another question, but if we are trying to come up > with a solution for geeks, why not come up with a _real_ solution, > instead of the .local hack? I'd love to hear the plan. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From brian.e.carpenter@gmail.com Mon Aug 6 02:05: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 6C33E21F8602 for ; Mon, 6 Aug 2012 02:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.472 X-Spam-Level: X-Spam-Status: No, score=-101.472 tagged_above=-999 required=5 tests=[AWL=0.219, 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 mO50MAwWF3nW for ; Mon, 6 Aug 2012 02:05:34 -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 4AFAA21F850B for ; Mon, 6 Aug 2012 02:05:34 -0700 (PDT) Received: by eekb45 with SMTP id b45so669345eek.31 for ; Mon, 06 Aug 2012 02:05:33 -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=klh+20DDtIVtmys0LeUtphpo6Nkptmyu9od93/zHax0=; b=MQcaAEtOe78oKc/O5bOPrJAh15Pj3DtvlX7qOd397+zM3ShhSczEqX4AagUK3ooLwx z+jIrumM4UJOIdIRSWtIZu5pGKJkBYMWNf9uTnD3hb6Nj6Mbnsy6XLnwilYgyoZnkdid nA72uALadE1B4wPP799mKxvQ7joajJ+NiW6Wi2LibmucT/V7ZyZIbWzGKVrLS70teJno xHyDSIiXeQlfJ/xV1aON2iNcVgxqgSn//uTyrRt2QHBMnMDNOZxNTfhF07N8XNiu9ZUz HKd5P55yPhA7V2/gAhMIpIsYFEmdv4zUfy8duOApQjaCZ6BVLmbTKryRYLR8erqNzp+x Xhhw== Received: by 10.14.179.135 with SMTP id h7mr12135146eem.35.1344243933363; Mon, 06 Aug 2012 02:05:33 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-73.as13285.net. [2.102.216.73]) by mx.google.com with ESMTPS id h42sm45745348eem.5.2012.08.06.02.05.31 (version=SSLv3 cipher=OTHER); Mon, 06 Aug 2012 02:05:32 -0700 (PDT) Message-ID: <501F88D9.2040006@gmail.com> Date: Mon, 06 Aug 2012 10:05:29 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Evan Hunt References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> <20120806032832.GA89953@isc.org> In-Reply-To: <20120806032832.GA89953@isc.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Tim Chown , Ted Lemon , "homenet@ietf.org Group" Subject: Re: [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: Mon, 06 Aug 2012 09:05:35 -0000 On 06/08/2012 04:28, Evan Hunt wrote: >> i wasn't able to participate in this discussion because I had other >> business during homenet, but I'm a bit frustrated by this conclusion. > > I was speaking for myself and I believe the issue is in flux; please > don't take it as a "conclusion". :) > >> IMHO, we shouldn't promote bad solutions, and .local is a bad solution. > > IMHO . is also a bad solution. It's, at least > potentially, a worse one: you buy a new router, and suddenly your devices > all have new names and your bookmarks don't work. To make them work again, > you have to remember the hexidecimal-gibberish that was assigned by your > previous router and configure it to use the same one. Ugly. I do agree that expecting ordinary users to keep track of a pseudorandom string is unreasonable. Maybe we can take a hint from mailman. When you install a new CPE router, and it's unable to discover the current unique string, you could be asked to enter your existing unique string, but also be offered the option of the router creating a new one. So the requirements seem to be 1. A discovery mechanism so that new devices on a homenet can find the local unique string. 2. The string and the discovery mechanism need to survive a cold start and the replacement of the CPE router (in all scenarios except a "factory reset"). That means a distributed solution. 3. If there really is no unique string, the CPE router generates one, unless the user prefers to type it in. Undoubtedly .sitelocal is simpler. Brian > > I'm not really happy with either of these choices, but I'm less unhappy > with .sitelocal. > >> Whether we come up with some way to leverage a ULA to present things >> sensibly in some UI is another question, but if we are trying to come up >> with a solution for geeks, why not come up with a _real_ solution, >> instead of the .local hack? > > I'd love to hear the plan. > From mellon@fugue.com Mon Aug 6 05: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 DD5C121F8616 for ; Mon, 6 Aug 2012 05:00:41 -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] 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 PEWAV+75Ue6M for ; Mon, 6 Aug 2012 05:00:41 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 46B3721F860B for ; Mon, 6 Aug 2012 05:00:41 -0700 (PDT) Received: from agape-4.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 28A312380630; Mon, 6 Aug 2012 08:00:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Ted Lemon In-Reply-To: <20120806032832.GA89953@isc.org> Date: Mon, 6 Aug 2012 08:00:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> <20120806032832.GA89953@isc.org> To: Evan Hunt X-Mailer: Apple Mail (2.1283) Cc: Tim Chown , "homenet@ietf.org Group" Subject: Re: [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: Mon, 06 Aug 2012 12:00:42 -0000 On Aug 5, 2012, at 11:28 PM, Evan Hunt wrote: > I was speaking for myself and I believe the issue is in flux; please > don't take it as a "conclusion". :) Fair enough. :) > IMHO . is also a bad solution. Yes, definitely. If that gibberish is ever visible to the user, we've = done it wrong. > It's, at least > potentially, a worse one: you buy a new router, and suddenly your = devices > all have new names and your bookmarks don't work. To make them work = again, > you have to remember the hexidecimal-gibberish that was assigned by = your > previous router and configure it to use the same one. Ugly. Even forgetting the hexadecimal gibberish, if there is any sort of local = name that is based on the router, switching routers is always going to = be ugly. Ideally we want the solution to be tied to something "in the = cloud" so that the replacement router can restore its brains. > I'd love to hear the plan. For geeks, you register a domain, or pay a small monthly fee for a = subdomain of something like dyndns.org. Maybe the brains for your = router live there too, so that if you replace it, you can just punch in = your domain, and it figures out the rest. This works for geeks; = everyone else uses friendly names presented in a UI. Of course, I also think that ULAs ought to be allocated rather than = guessed at, which I gather is not a popular position. From mellon@fugue.com Mon Aug 6 07:17: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 DDD8521F868A for ; Mon, 6 Aug 2012 07:17:37 -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 ehm-ebIeGNLa for ; Mon, 6 Aug 2012 07:17:37 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4560721F86B3 for ; Mon, 6 Aug 2012 07:17:37 -0700 (PDT) Received: from agape-4.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 8AD532380630 for ; Mon, 6 Aug 2012 10:17:35 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1283) From: Ted Lemon In-Reply-To: Date: Mon, 6 Aug 2012 10:17:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1283) Subject: Re: [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: Mon, 06 Aug 2012 14:17:38 -0000 On Aug 6, 2012, at 12:58 AM, Unindicted Coconspirator wrote: >> Domains like .local seem like a good idea to geeks like us, but how = many regular users ever use them? > Every single user who has added a printer to OS X or Linux in the last > several years. No. You think that because you're a geek like the rest of us. Every = single user who has added a printer to OS X has done so from a UI that = presented a list of printers doing bonjour. This list named the = printers by brand. The user clicked on a printer from the list, and = that was the end of it. The user certainly never saw = Canon_PIXMA_900.local in any UI. I'm fairly sure this is true of Linux = as well. > Apparently multicast DNS works even in the absence of mental models. It works in the sense that if you know the name of the machine you are = trying, and tack ".local" on the end, there is a small chance that you = will get to that machine. But usually you won't, because various = network glitches will have caused the machine to rename itself to = machine-04.local by the time you try to address it, even though there = were never any machine.locals other than that one. mDNS is a nice = hack, but fairly useless for the particular application we are talking = about. It's pretty good for service discovery (showing a list of = printers in a UI). >> IMHO, we shouldn't promote bad solutions, and .local is a bad = solution. > A bad solution to what problem? Well, indeed. We are clearly talking about different problems. > Several people spoke in favor of supporting existing solutions (a.k.a. > running code). > I'd like to see us gauge consensus for this point here on the list. I'm against it, as you know. The problem with the current running code = is that namespaces overlap, and the UI has no way to detect or present = this. Settling on a half solution because we have running code is the = wrong way to go. > I tried to show in the print server example that the client > may cache unique information about the server (GUID, unique host name, = etc.) that makes > disambiguation a non-issue. But it's not a non-issue, because the user doesn't know the GUID, and = hence doesn't know which "fridge" is the right one. (I'm just = repeating Stuart Cheshire here, from a conversation we had last week). = So the GUID doesn't give us the information we want, and indeed can = produce confusing results in the UI. A per-site naming scheme, with a = nice UI on top of it, _does_ give us that. Fridge can be fridge (home) = and fridge (here) in the UI, for instance, because we know we aren't at = home. > It was agreed that name-.local. is equivalent to > name.local-. from a CS standpoint. Here you are definitely arguing about the wrong problem. At the = presentation layer, both are equivalent, and both are wrong. What we = want is not fridge-1.local and fridge-2.local, but fridge (here) and = fridge (there). > - it is relatively easy to retrofit this behavior to hosts and servers > and difficult (or > impossible) to reflash existing printers You don't need to update the printers. Just have the CPE device say = where you are. This stuff can all happen at the presentation layer=97at = the protocol layer, it's perfectly fine if the printer is = "printer.local" as long as the CPE says what "local" means, and the UI = presents it correctly. > - using .local-. based on ULA means complexity equivalent to = ULA > distribution problem. This is a big issue when homenets are coalesced = and > can't be solved by routing alone. In general, the homenet merge is not likely to be a homenet merge in the = sense you mean, but rather a decommissioning of one of two routers, and = a migration of the devices formerly connected to the one router to the = network operated by the other router. In this case, a CPE-advertised = location will solve the problem in a nice, intuitive way=97all the = devices will appear in the UI as being connected to the local network. > I think you're referring to a _different_ problem; resolving your > site's resources > while you are mobile. Am I mistaken? I'm claiming that this isn't a separate problem. From kerlyn2001@gmail.com Mon Aug 6 07:40: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 7BF0E21F841C for ; Mon, 6 Aug 2012 07:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=0.572, 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 gqnzBRu5s8Ky for ; Mon, 6 Aug 2012 07:40:37 -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 E028521F84DF for ; Mon, 6 Aug 2012 07:40:36 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so495376lbb.31 for ; Mon, 06 Aug 2012 07:40:35 -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:content-type :content-transfer-encoding; bh=Wa8SwrQwT2SzC+zzv0wHzTFsOMIFH2+BpcO+rIU+tAc=; b=A7K6TxNVg3G6a8q0NEnipr/GpHseHDbiGQM0qr1DYSF9amMqJNANymmwOEPBgemaxG 95dInK36VkhDmeOdugDLukCmaD/y6gZALWmfsCOHHJ+6ega20vLrbLBVAamuK6aAfoIL sk1A9yojLFlGgSGF15MtbkNArZ1t7IxCIfigJji9ZjX8zrYamBUpN3mG7zLVT/0y6N58 26jS/p2w6PDcKRK1/5vldPPjSUJexKfmiSWBLNg20wGleozPo5K7W/xcLaaKYhd/6AF5 St52Eycm0dnwLRtqqMkXaWomqwG4oHxaPv59pSa+Wy/IKtfEC9N5b5pdscSqAF9uJn7g 38Jg== MIME-Version: 1.0 Received: by 10.112.29.233 with SMTP id n9mr4712289lbh.91.1344264035723; Mon, 06 Aug 2012 07:40:35 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.10.199 with HTTP; Mon, 6 Aug 2012 07:40:35 -0700 (PDT) In-Reply-To: References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> Date: Mon, 6 Aug 2012 10:40:35 -0400 X-Google-Sender-Auth: xgqh37JA63kqngUoRgAuBFTGB0Y Message-ID: From: Kerry Lynn To: "homenet@ietf.org Group" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [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: Mon, 06 Aug 2012 14:40:38 -0000 On Mon, Aug 6, 2012 at 8:18 AM, Ted Lemon wrote: > On Aug 6, 2012, at 12:58 AM, Kerry Lynn wrote: >>> Domains like .local seem like a good idea to geeks like us, but how man= y regular users ever use them? >> Every single user who has added a printer to OS X or Linux in the last >> several years. > > No. You think that because you're a geek like the rest of us. I think there may be two kinds of geeks on this list, those who want to tak= e corporate networks and scale them down for home users and those who want to extend existing home networks and make them more functional. These two points of view may lead to a common solution for any given problem, but that's not yet evident. > Every single user who has added a printer to OS X has done so from a UI t= hat presented a list of printers doing bonjour. This list named the print= ers by brand. The user clicked on a printer from the list, and that was t= he end of it. The user certainly never saw Canon_PIXMA_900.local in any U= I. I'm fairly sure this is true of Linux as well. > Sorry, not sure I'm getting your point. Yes, the user is using a UI to sol= ve her problem. The UI in this case is using (multicast) DNS. DNS requires a zone to scope the query. That zone is ".local.". My car probably has 15 microcontrollers and I use them when I drive to the market whether I'm aware of it (which I don't want to be) or not. What appears in my list is a _default_ SRV record name consisting of the printer model plus "gibberish" (in my case "Office Jet Pro A909g [4C0EA4]")= . The gibberish is the least significant 24-bits of the MAC address (printed = on the box, on a sticker near the network port, on the test page that ejects f= rom the printer, and from the setup menu on the printer's screen. The user is given the chance to change the name when the printer is added; thereafter it is only slightly more complicated to change it. Another advantage to adding gibberish to the SRV name (aside from those I listed earlier) is that it reduces the probability of name conflicts. Th= ere can be many sources for this gibberish, but it is relatively easy to use so= me intrinsic identifier. The "hack" above is slightly worse than a five-digit= zip code, slightly better than a nine-digit zip code - the point being that use= rs already deal with a certain amount of gibberish in their lives. >> Apparently multicast DNS works even in the absence of mental models. > > It works in the sense that if you know the name of the machine you are tr= ying, and tack ".local" on the end, there is a small chance that you will g= et to that machine. But usually you won't, because various network glitch= es will have caused the machine to rename itself to machine-04.local by the= time you try to address it, even though there were never any machine.local= s other than that one. Hard for me to buy this, unless the device is hearing from itself via tape delay. > mDNS is a nice hack, but fairly useless for the particular application we= are talking about. It's pretty good for service discovery (showing a lis= t of printers in a UI). > >>> IMHO, we shouldn't promote bad solutions, and .local is a bad solution. >> A bad solution to what problem? > > Well, indeed. We are clearly talking about different problems. > Yes, there are at least two problems: how to disambiguate name collisions in locally served zones and how to access remote resources. We agree that these problems collapse if you outlaw locally served zones. We disagree on the utility and/or reliability of locally served zones. This is why I'm pushing back and saying the problems you raise with mDNS are solvable. I think that in the short run it is easier to connect users to their existi= ng networks (e.g. through tunnels) than it is to educate them on the workings of DNS and require them to deploy a global zone before they can connect to any device. >> Several people spoke in favor of supporting existing solutions (a.k.a. >> running code). >> I'd like to see us gauge consensus for this point here on the list. > > I'm against it, as you know. The problem with the current running code = is that namespaces overlap, and the UI has no way to detect or present this= . Settling on a half solution because we have running code is the wrong w= ay to go. > >> I tried to show in the print server example that the client >> may cache unique information about the server (GUID, unique host name, e= tc.) that makes >> disambiguation a non-issue. > > But it's not a non-issue, because the user doesn't know the GUID, and hen= ce doesn't know which "fridge" is the right one. (I'm just repeating Stua= rt Cheshire here, from a conversation we had last week). So the GUID does= n't give us the information we want, and indeed can produce confusing resul= ts in the UI. A per-site naming scheme, with a nice UI on top of it, _doe= s_ give us that. Fridge can be fridge (home) and fridge (here) in the UI,= for instance, because we know we aren't at home. > And I'm saying it can just as easily be presented as fridge(this) and fridge(that). While I haven't tried the experiment, I believe that if you and I both had = HP Mumble Jet printers and I was connected to your homenet and I tried to prin= t something then my printer would not even appear as an available option, because under the hood the UI has determined that my printer is not on the local network. >> It was agreed that name-.local. is equivalent to >> name.local-. from a CS standpoint. > > Here you are definitely arguing about the wrong problem. At the present= ation layer, both are equivalent, and both are wrong. What we want is not= fridge-1.local and fridge-2.local, but fridge (here) and fridge (there). > I thought I was discussing the problem referenced in the subject line... >> - it is relatively easy to retrofit this behavior to hosts and servers >> and difficult (or >> impossible) to reflash existing printers > > You don't need to update the printers. Just have the CPE device say whe= re you are. This stuff can all happen at the presentation layer=97at the = protocol layer, it's perfectly fine if the printer is "printer.local" as lo= ng as the CPE says what "local" means, and the UI presents it correctly. > >> - using .local-. based on ULA means complexity equivalent to ULA >> distribution problem. This is a big issue when homenets are coalesced = and >> can't be solved by routing alone. > > In general, the homenet merge is not likely to be a homenet merge in the = sense you mean, but rather a decommissioning of one of two routers, and a m= igration of the devices formerly connected to the one router to the network= operated by the other router. Even though we can locally route between them just fine? This sounds like = a new thread... > In this case, a CPE-advertised location will solve the problem in a nice,= intuitive way=97all the devices will appear in the UI as being connected t= o the local network. > >> I think you're referring to a _different_ problem; resolving your >> site's resources >> while you are mobile. Am I mistaken? > > I'm claiming that this isn't a separate problem. > Well, the definition of "solution" certainly depends on the problem stateme= nt. If you define the problem as being able to access remote resources then the= re are existing ways to solve this, e.g. tunnels and dyndns. At every step in the transition, the dominant paradigm is likely to be the one that is most understandable and least expensive. -K- From mike@mtcc.com Mon Aug 6 09:00: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 C5D7321F861F for ; Mon, 6 Aug 2012 09:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.708 X-Spam-Level: X-Spam-Status: No, score=-2.708 tagged_above=-999 required=5 tests=[AWL=-0.109, 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 cTq82d7Kyce5 for ; Mon, 6 Aug 2012 09:00:05 -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 3E95921F85F4 for ; Mon, 6 Aug 2012 09:00:05 -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 q76G00TB029817 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 6 Aug 2012 09:00:01 -0700 Message-ID: <501FEA00.2070702@mtcc.com> Date: Mon, 06 Aug 2012 09:00:00 -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: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5063; t=1344268802; x=1345132802; 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]=20tunnels=20as=20way=20to=20d isambiguate=20.local |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=9Ax9o5wiKKP5AIbpyrzWRBYtKtdV6TgHNyP230C/unE=; b=rxD3ZEdvlta2Zzh4T3/QInoM7d7F6InCnKQhizLVNW4tSa0kxMDUtNDNfz YebktKCnW9RrgmDPOaDl4ddR/Q3kcxSHZr8dK5QwfY8f8FfCPmiBpu9JHJKw 6BD52J6p7LZnsPPuYs5BKrp0+R1b+cnP2mKdfWj7q59g0nRA51hP8=; 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] 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: Mon, 06 Aug 2012 16:00:07 -0000 On 08/06/2012 07:17 AM, Ted Lemon wrote: >> Every single user who has added a printer to OS X or Linux in the last >> several years. > No. You think that because you're a geek like the rest of us. Every single user who has added a printer to OS X has done so from a UI that presented a list of printers doing bonjour. This list named the printers by brand. The user clicked on a printer from the list, and that was the end of it. The user certainly never saw Canon_PIXMA_900.local in any UI. I'm fairly sure this is true of Linux as well. Speaking as a geek who not only remembers NBP but actually wrote an implementation of it, I have to say that it never even occurred to me that there is some sort of IP equivalent of NBP. It just doesn't fit the same mental model as fqdn's which is how I and just about everybody else thinks of net naming. In fact, I'm being far too generous with fqdn's. People don't even think about them other than maybe top level brand names.com. Nowadays, people expect to just search for whatever's relevant. If it doesn't come up in search, it must not exist. I have to say that part of my struggle here is just understanding the problem(s) coming in from the cold. I see lots of hammers being applied to things that may or may not resemble nails, but much less about the real world aspects of this problem, cf search above. Mike > >> Apparently multicast DNS works even in the absence of mental models. > It works in the sense that if you know the name of the machine you are trying, and tack ".local" on the end, there is a small chance that you will get to that machine. But usually you won't, because various network glitches will have caused the machine to rename itself to machine-04.local by the time you try to address it, even though there were never any machine.locals other than that one. mDNS is a nice hack, but fairly useless for the particular application we are talking about. It's pretty good for service discovery (showing a list of printers in a UI). > >>> IMHO, we shouldn't promote bad solutions, and .local is a bad solution. >> A bad solution to what problem? > Well, indeed. We are clearly talking about different problems. > >> Several people spoke in favor of supporting existing solutions (a.k.a. >> running code). >> I'd like to see us gauge consensus for this point here on the list. > I'm against it, as you know. The problem with the current running code is that namespaces overlap, and the UI has no way to detect or present this. Settling on a half solution because we have running code is the wrong way to go. > >> I tried to show in the print server example that the client >> may cache unique information about the server (GUID, unique host name, etc.) that makes >> disambiguation a non-issue. > But it's not a non-issue, because the user doesn't know the GUID, and hence doesn't know which "fridge" is the right one. (I'm just repeating Stuart Cheshire here, from a conversation we had last week). So the GUID doesn't give us the information we want, and indeed can produce confusing results in the UI. A per-site naming scheme, with a nice UI on top of it, _does_ give us that. Fridge can be fridge (home) and fridge (here) in the UI, for instance, because we know we aren't at home. > >> It was agreed that name-.local. is equivalent to >> name.local-. from a CS standpoint. > Here you are definitely arguing about the wrong problem. At the presentation layer, both are equivalent, and both are wrong. What we want is not fridge-1.local and fridge-2.local, but fridge (here) and fridge (there). > >> - it is relatively easy to retrofit this behavior to hosts and servers >> and difficult (or >> impossible) to reflash existing printers > You don't need to update the printers. Just have the CPE device say where you are. This stuff can all happen at the presentation layer—at the protocol layer, it's perfectly fine if the printer is "printer.local" as long as the CPE says what "local" means, and the UI presents it correctly. > >> - using .local-. based on ULA means complexity equivalent to ULA >> distribution problem. This is a big issue when homenets are coalesced and >> can't be solved by routing alone. > In general, the homenet merge is not likely to be a homenet merge in the sense you mean, but rather a decommissioning of one of two routers, and a migration of the devices formerly connected to the one router to the network operated by the other router. In this case, a CPE-advertised location will solve the problem in a nice, intuitive way—all the devices will appear in the UI as being connected to the local network. > >> I think you're referring to a _different_ problem; resolving your >> site's resources >> while you are mobile. Am I mistaken? > I'm claiming that this isn't a separate problem. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mike@mtcc.com Mon Aug 6 09:12: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 27B6421F85CC for ; Mon, 6 Aug 2012 09:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.704 X-Spam-Level: X-Spam-Status: No, score=-2.704 tagged_above=-999 required=5 tests=[AWL=-0.105, 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 Ea6X38EdySJM for ; Mon, 6 Aug 2012 09:12:07 -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 4AD2921F84D2 for ; Mon, 6 Aug 2012 09:12:07 -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 q76GAUum001046 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 6 Aug 2012 09:10:31 -0700 Message-ID: <501FEC76.7010600@mtcc.com> Date: Mon, 06 Aug 2012 09:10:30 -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: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> <20120806032832.GA89953@isc.org> 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=1283; t=1344269431; x=1345133431; 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]=20tunnels=20as=20way=20to=20d isambiguate=20.local |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=ggHJ2KiZainDVK6GfXX17HS2aakLSTr6gG5VVD3HVpM=; b=ZeF0ZOhVTXxVjPBMYxazsW5h3UYANayxMqyrHbTvxwwU/jIZwwP7w1AX0I G+BNUIcWaNp/JlBs9ITxjEG1ga7XWl5e7TC1BwMSbKOvmbHSe7CBdwUhp0pg 8KUYgCj1YwUJD5/2a7JwkRhkPh+42quF+BqVyL9M/P3NJn04UpEx4=; 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: Evan Hunt , Tim Chown , "homenet@ietf.org Group" Subject: Re: [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: Mon, 06 Aug 2012 16:12:08 -0000 On 08/06/2012 05:00 AM, Ted Lemon wrote: > Even forgetting the hexadecimal gibberish, if there is any sort of local name that is based on the router, switching routers is always going to be ugly. Ideally we want the solution to be tied to something "in the cloud" so that the replacement router can restore its brains. >> I'd love to hear the plan. > For geeks, you register a domain, or pay a small monthly fee for a subdomain of something like dyndns.org. Maybe the brains for your router live there too, so that if you replace it, you can just punch in your domain, and it figures out the rest. This works for geeks; everyone else uses friendly names presented in a UI. I think this is a similar issue with real live ULA's too: where does the authoritative memory for site addressing ultimately reside? In real sites, you pay people to make certain that such things are cared and tended for. I don't know where that memory or clue comes from in a homenet. > > Of course, I also think that ULAs ought to be allocated rather than guessed at, which I gather is not a popular position. > I wonder how many fd:0:0:0:: networks are out there despite rfc 4193? If there is any human involvement required whatsoever, I expect that the number is very high. Mike From each@isc.org Mon Aug 6 11:25: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 8605311E80B8 for ; Mon, 6 Aug 2012 11:25:26 -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 VsM5jrj6i8rh for ; Mon, 6 Aug 2012 11:25:25 -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 67DE411E80D5 for ; Mon, 6 Aug 2012 11:25:25 -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 58AE85F9960; Mon, 6 Aug 2012 18:25:11 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 91CE9216C3B; Mon, 6 Aug 2012 18:25:09 +0000 (UTC) Date: Mon, 6 Aug 2012 18:25:09 +0000 From: Evan Hunt To: Ted Lemon Message-ID: <20120806182509.GA99606@isc.org> References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "homenet@ietf.org Group" Subject: Re: [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: Mon, 06 Aug 2012 18:25:26 -0000 On Mon, Aug 06, 2012 at 10:17:34AM -0400, Ted Lemon wrote: > Here you are definitely arguing about the wrong problem. At the > presentation layer, both are equivalent, and both are wrong. What we > want is not fridge-1.local and fridge-2.local, but fridge (here) and > fridge (there). If you want access to fridge (there), then fridge (there) has to have a globally-addressable domain name. If it doesn't have one, then there's no way for you to reach it, and I can't think of any reason for a well-designed UI to display it. If "fridge.local" is available, then it must be fridge (here). As I see it, those who have devices that they wish to reach remotely will have to either own their own domain names, or acquire delegated subdomains from e.g. their ISP or their hardware vendor (I could see Apple including one in the price of an Airport Express, for example). If your network is configured with such a name, and if you have a printer configured to allow remote access, then the name it advertises and which your UI will cache will be something like "printer-2.my-personal-domain.com" or "printer-3.smithfamily1137.mac.com". I think we have general consensus in the WG that this is a good approach for remote access. So now we're just talking about people who *don't* choose to have their devices remotely accessible; those people's devices would use non-globally- addressable names. Now (as I understand it) the primary advantage to using "." or "..local" naming is the ability to cache separate lists of discovered devices for different networks that you happen to visit. That is, if I'm visiting Ted's house, I'd like to see the list of devices I've previously found on Ted's network, and if I'm at home, I'd like to see the list of devices on mine. But I don't see a requirement for a network name to be globally unique if it isn't globally addressable. I could simply *choose* a name to disambiguate my network from Ted's, just as most of us choose our own SSIDs. You'd want to choose one unique enough that you wouldn't run into duplicates very frequently, but that would be at most a recommendation, not a requirement. So let's say my house uses names in the "evanshouse.local" namespace. For most visitors, this is sufficient to separate things out. If a visitor happens to have the same network name as I do, then my devices and theirs could get mixed up in their lists of cached names, and that's suboptimal and inconvenient, but not (as far as I can see) particularly harmful. If I buy a new router, it will ask me what network name to use, and I will easily remember that I've been using "evanshouse". There's no need to look up the hexadecimal gibberish supplied by my previous router. If I absolutely refuse to give my router a network name, then it could choose one for me, and in that event a ULA-style name seems like a good choice. But I would expect it to be a rare one. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From mike@mtcc.com Mon Aug 6 11:30: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 F243111E80E5 for ; Mon, 6 Aug 2012 11:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[AWL=-0.102, 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 YbQzAda1CfRY for ; Mon, 6 Aug 2012 11:30:20 -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 2B85511E80B8 for ; Mon, 6 Aug 2012 11:30:20 -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 q76IUIQO014677 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 6 Aug 2012 11:30:19 -0700 Message-ID: <50200D3A.5070308@mtcc.com> Date: Mon, 06 Aug 2012 11:30:18 -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=1678; t=1344277819; x=1345141819; 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:=20naming,=20what's=20the=20problem? |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=ivZjdYMsV1AYebEWKoJcsVNdzoXanNrn+C6F2Oc+0oU=; b=kIEgnFX7mtjM0q94l18D+kV8y326k0N5RH6U9Xs6eKMUhNtNPC2WhYnkDi +pBofhW6DWM7DIDvoH9lm/ky8iYDZab85i5Ls58POwuSHWxgEIPkyqAvFQ8O DhSMtnv3pLnZQoK89F8dtToDe9n44XU2RN5oetmUSj8AXiULBbAg8=; 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 Subject: [homenet] naming, what's the problem? 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, 06 Aug 2012 18:30:21 -0000 I've been rereading the charter and the -arch document and they both seem to make a presumption that we actually know what the problems are in a homenet. At the very least, I'm not convinced that we've captured what those problems are. The charter seems to say that we have some tools (dns, zeroconf...) that we should be able to tweak. The -arch document seems to be very "device" oriented -- as in from the dns-sd perspective, where my printer is the canonical example. I think there's more to this. Maybe an example is in order. I have a weather station: http://mtcc.com/~mike/sanchez.php This is not a service to be discovered like a printer, though I might want to discover it were I to get an off-the-shelf IP enabled version from, say, oregon scientific. It's much more like a web site. I want to be able to see it not only at home, but when I'm away so that I can see whether my Pioneer house has snow in the driveway. I've done this using v4, but I'm a geek. What I think we want to enable is non-geeks to be able to install these kinds of devices in a v6 world with some minimum muss and fuss. That is, we need to account for not just services, but *servers* in the form of traditional web-headed servers. That is, the normal browser-centric view of the world. That browser-centric view of the world knows nothing about .local. Nor do I want to learn about .local either. I want to have a real name that I can use as a real URL to send -- as I just did -- to people that might want to see my weather station. And I want -- literally -- for my mother to be able to do the same. It is beyond her now. So there's one problem. Mike From mellon@fugue.com Mon Aug 6 11:51: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 518C811E80AD for ; Mon, 6 Aug 2012 11:51:53 -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 J60QNo97Ftsz for ; Mon, 6 Aug 2012 11:51:52 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id D795911E808A for ; Mon, 6 Aug 2012 11:51:52 -0700 (PDT) Received: from [10.1.10.11] (173-162-214-218-NewEngland.hfc.comcastbusiness.net [173.162.214.218]) by toccata.fugue.com (Postfix) with ESMTPSA id 5B3C12380630; Mon, 6 Aug 2012 14:51:51 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Ted Lemon In-Reply-To: <20120806182509.GA99606@isc.org> Date: Mon, 6 Aug 2012 14:51:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> <20120806182509.GA99606@isc.org> To: Evan Hunt X-Mailer: Apple Mail (2.1283) Cc: "homenet@ietf.org Group" Subject: Re: [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: Mon, 06 Aug 2012 18:51:53 -0000 The problem is that you are assuming (a) that only geeks will ever want = remotely-addressable networks (and hence, we don't need to specify a = mechanism for automatically setting that up, because they can do it = manually), and (b) that no network will ever go from being = locally-addressed to globally-addressed. Both of these are self-fulfilling prophecies that I would like to = prevent fulfilling themselves. Oh, and (c) that a person with a local-only homenet will never take = their laptop or cell phone to someone else's house where a naming scheme = conflict happens to exist, and accidentally tweak something because of = the clash. Global naming implies state, among other things. mDNS is sort of = stateless, except of course that it's not completely stateless, and = breaks badly in some cases when you treat it as if it is. So state is, = IMHO, a better solution even in the local-only situation, because you're = owning the fact that you have state, and you have to go to the trouble = to get it right. And it has a clean upgrade path to the local/remote = situation. And it doesn't surprise anyone with naming clashes when = visiting the neighbors' network. From mcr+ietf@sandelman.ca Mon Aug 6 13:34: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 4791A11E80DE for ; Mon, 6 Aug 2012 13:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24] 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 oCUgOWELllUd for ; Mon, 6 Aug 2012 13:33:57 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id DEA0811E80DC for ; Mon, 6 Aug 2012 13:33:56 -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 A34A420168 for ; Mon, 6 Aug 2012 16:46:36 -0400 (EDT) From: Michael Richardson To: "homenet@ietf.org Group" In-Reply-To: <20120806182509.GA99606@isc.org> References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> <20120806182509.GA99606@isc.org> 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] 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: Mon, 06 Aug 2012 20:34:00 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Evan" =3D=3D Evan Hunt writes: Evan> On Mon, Aug 06, 2012 at 10:17:34AM -0400, Ted Lemon wrote: >> Here you are definitely arguing about the wrong problem. At the >> presentation layer, both are equivalent, and both are wrong. What = we >> want is not fridge-1.local and fridge-2.local, but fridge (here) and >> fridge (there). Evan> If you want access to fridge (there), then fridge (there) has Evan> to have a=20 Evan> globally-addressable domain name. If it doesn't have one, Evan> then there's=20 Evan> no way for you to reach it, and I can't think of any reason for a Evan> well-designed UI to display it. If "fridge.local" is available, = then Evan> it must be fridge (here). No, the fridge must have a globally reachable address (GUA) to be reachable. The name does not need to be globally addressable, but if it is, that certainly helps in solving the problem. What we are discussing, is how my (mobile) device can retrieve/discover a pointer to a name that can be easily translated into an address.=20=20 We want this pointer rather than just having my device cache the GUA that it got from mDNS: caching the GUA from mDNS works in the short term, but fails after a renumber.=20=20 Tunnels are okay, but to use them, but has to get the DNS search order and the DNS server list right, and that's walled garden territory. *If* we are going to turn each home into a walled garden, then let's be aware that we are doing that. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUCAqLYqHRg3pndX9AQK9QQP/YtHwLW5oPHGklpSR50ExH0n4T+eih79o QHD3jAVRtMtOIjtNSpK/zOJ6gDXWiwcHRPYOTjVtc58tguzsjVQKgAQCiBOfELPc zeIxKew5/A0JodM9BVdPJDBy13HVCwAn8rRXB6UWsQb0yQXHedCPEKs3wDqNjQc0 qS6qB8VSats= =WNFz -----END PGP SIGNATURE----- --=-=-=-- From each@isc.org Mon Aug 6 14:44: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 88A9A21F857E for ; Mon, 6 Aug 2012 14:44:24 -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 4HqxsEQNGUXl for ; Mon, 6 Aug 2012 14:44:24 -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 E7A1321F8575 for ; Mon, 6 Aug 2012 14:44:23 -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 1A4715F996A; Mon, 6 Aug 2012 21:44:09 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 4BE88216C3B; Mon, 6 Aug 2012 21:44:07 +0000 (UTC) Date: Mon, 6 Aug 2012 21:44:07 +0000 From: Evan Hunt To: Ted Lemon Message-ID: <20120806214407.GB99606@isc.org> References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> <20120806182509.GA99606@isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "homenet@ietf.org Group" Subject: Re: [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: Mon, 06 Aug 2012 21:44:24 -0000 On Mon, Aug 06, 2012 at 02:51:48PM -0400, Ted Lemon wrote: > The problem is that you are assuming (a) that only geeks will ever want > remotely-addressable networks (and hence, we don't need to specify a > mechanism for automatically setting that up, because they can do it > manually), Not at all -- lots of non-geeks buy domain names, and non-geeks can also get delegated subdomains from their ISP's. Making it easy for them to set up is a UI problem, and not a very hard one. You can't use . to reach a remote device anyway. > and (b) that no network will ever go from being locally-addressed to > globally-addressed. Not really. If you acquire a globally-resolvable domain name, then your printer could detect the fact and start advertising the name printername.domain.com alongside printername.myhouse.local; your laptop could then cache the new name, note that it's a FQDN, and begin showing it to you in a list of available printers when you're away from home. > Oh, and (c) that a person with a local-only homenet will never take their > laptop or cell phone to someone else's house where a naming scheme > conflict happens to exist, and accidentally tweak something because of > the clash. I think this concern is fairly minimal, and could be addressed by noting that the router MAC address has changed and popping up a warning dialog. > breaks badly in some cases when you treat it as if it is. So state is, > IMHO, a better solution even in the local-only situation, because you're > owning the fact that you have state, and you have to go to the trouble to > get it right. Explain what you mean by "state" here please? I'm not sure I'm following you. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From mellon@fugue.com Mon Aug 6 15:38: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 DD5FA11E80BF for ; Mon, 6 Aug 2012 15:38:19 -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 YWOMNiRxd27J for ; Mon, 6 Aug 2012 15:38:18 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id E6A9E11E80DC for ; Mon, 6 Aug 2012 15:38:18 -0700 (PDT) Received: from agape-4.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id CA1452380914; Mon, 6 Aug 2012 18:38:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_16898573-A6BC-40EE-AAB8-33B6030344A1" From: Ted Lemon In-Reply-To: <20120806214407.GB99606@isc.org> Date: Mon, 6 Aug 2012 18:38:13 -0400 Message-Id: References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> <20120806182509.GA99606@isc.org> <20120806214407.GB99606@isc.org> To: Evan Hunt X-Mailer: Apple Mail (2.1283) Cc: "homenet@ietf.org Group" Subject: Re: [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: Mon, 06 Aug 2012 22:38:20 -0000 --Apple-Mail=_16898573-A6BC-40EE-AAB8-33B6030344A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 6, 2012, at 5:44 PM, Evan Hunt wrote: > Not at all -- lots of non-geeks buy domain names, and non-geeks > can also get delegated subdomains from their ISP's. Making it easy > for them to set up is a UI problem, and not a very hard one. You > can't use . to reach a remote device anyway. We're talking past each other. I am not saying that .ULA is the right = solution. And as far as it being a UI problem, this is half true. If = the underlying protocol can set things up cleanly and reliably and = automatically, *then* getting the UI right is a UI problem. But if the = underlying protocol doesn't allow a UI that a regular user can navigate, = it doesn't matter how good the UI is. > Not really. If you acquire a globally-resolvable domain name, then = your > printer could detect the fact and start advertising the name > printername.domain.com alongside printername.myhouse.local; your > laptop could then cache the new name, note that it's a FQDN, and > begin showing it to you in a list of available printers when you're > away from home. Requiring the printer and host to adapt to network conditions in the way = you describe is not a homenet issue except in the sense that the homenet = would have to present the information to the host or printer to allow it = to do what you describe. Which is precisely what (I thought) we were = discussing. > I think this concern is fairly minimal, and could be addressed by = noting > that the router MAC address has changed and popping up a warning = dialog. You are talking about this as if you were the programmer. But we are = the IETF, not the UI programmer. It's not our job to get the UI = right=97it's to make it *possible* to get the UI right. > Explain what you mean by "state" here please? I'm not sure I'm > following you. State is stuff that either your host or some server remembers between = packet exchanges. So for example, your laptop probably remembers its = own name, and provides it using mDNS and DHCP. That's state. If the = DHCP server records it in the DNS, that's also state. No state is when = nothing is recorded anywhere. --Apple-Mail=_16898573-A6BC-40EE-AAB8-33B6030344A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Not at all -- = lots of non-geeks buy domain names, and non-geeks
can also get = delegated subdomains from their ISP's.  Making it easy
for them = to set up is a UI problem, and not a very hard one.  You
can't = use .<ULA> to reach a remote device = anyway.

We're talking past each = other.   I am not saying that .ULA is the right solution.   = And as far as it being a UI problem, this is half true.   If the = underlying protocol can set things up cleanly and reliably and = automatically, *then* getting the UI right is a UI problem.   But = if the underlying protocol doesn't allow a UI that a regular user can = navigate, it doesn't matter how good the UI = is.

Not really. =  If you acquire a globally-resolvable domain name, then = your
printer could detect the fact and start advertising the = name
printername.domain.com al= ongside printername.myhouse.local; your
laptop could then cache the = new name, note that it's a FQDN, and
begin showing it to you in a = list of available printers when you're
away from = home.

Requiring the printer and host to adapt = to network conditions in the way you describe is not a homenet issue = except in the sense that the homenet would have to present the = information to the host or printer to allow it to do what you describe. =   Which is precisely what (I thought) we were = discussing.

I think = this concern is fairly minimal, and could be addressed by noting
that = the router MAC address has changed and popping up a warning = dialog.

You are talking about this as if you = were the programmer.   But we are the IETF, not the UI programmer. =   It's not our job to get the UI right=97it's to make it *possible* = to get the UI right.

Explain what you mean by "state" here please?  I'm = not sure I'm
following you.

State is stuff = that either your host or some server remembers between packet exchanges. =   So for example, your laptop probably remembers its own name, and = provides it using mDNS and DHCP.   That's state.   If the DHCP = server records it in the DNS, that's also state.  No state is when = nothing is recorded = anywhere.


= --Apple-Mail=_16898573-A6BC-40EE-AAB8-33B6030344A1-- From each@isc.org Mon Aug 6 18:39: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 8BD4B11E80A5 for ; Mon, 6 Aug 2012 18:39:15 -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=[AWL=0.000, 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 2VjIqICYlq5s for ; Mon, 6 Aug 2012 18:39:15 -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 E151411E808A for ; Mon, 6 Aug 2012 18:39:14 -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 E5FA7C9450; Tue, 7 Aug 2012 01:39:02 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id BA85F216C3B; Tue, 7 Aug 2012 01:39:02 +0000 (UTC) Date: Tue, 7 Aug 2012 01:39:02 +0000 From: Evan Hunt To: Michael Richardson Message-ID: <20120807013902.GD99606@isc.org> References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> <20120806182509.GA99606@isc.org> <29040.1344285229@obiwan.sandelman.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29040.1344285229@obiwan.sandelman.ca> User-Agent: Mutt/1.4.2.3i Cc: "homenet@ietf.org Group" Subject: Re: [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: Tue, 07 Aug 2012 01:39:15 -0000 On Mon, Aug 06, 2012 at 04:33:49PM -0400, Michael Richardson wrote: > No, the fridge must have a globally reachable address (GUA) to be reachable. You are correct, of course, and I was being unclear; sorry about that. I was trying to reflect what I thought I heard in the discussion in Vancouver, though, which was that a FQDN or the equivalent would be the best way to handle naming of remotely accessible devices. It seemed to me that we had rough consensus on that point (perhaps I was mistaken), but not on naming of devices on "island" networks. > Tunnels are okay, but to use them, but has to get the DNS search order > and the DNS server list right, and that's walled garden territory. > *If* we are going to turn each home into a walled garden, then let's be > aware that we are doing that. For the purposes of my mom's house, I do think "walled garden" is the appropriate default setting, but our design should allow the default to be overridden without great difficulty. I think this general plan would meet those goals: 1) All discoverable devices on all networks MUST answer to a locally reachable name, such as .local, .sitelocal, ..local, ., -.local, etc. (We haven't settled the naming convention here. I personally like ..local, with ..local as a fallback in the event of the network's owner failing to configure a network name); 2) Networks configured to allow remote access to devices SHOULD have a globally reachable domain name, either owned by the user or in a vendor-managed namespace; 3) If a device is configured for remote access and is on a network which has had a FQDN configured as in (2), then in addition to the locally reachable name described in (1), the device MUST also answer to ".". -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From each@isc.org Mon Aug 6 19:21: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 6605521F86B4 for ; Mon, 6 Aug 2012 19:21:45 -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 uEuQZy4GNXAj for ; Mon, 6 Aug 2012 19:21:44 -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 E228321F86B1 for ; Mon, 6 Aug 2012 19:21:43 -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 D797B5F98EB; Tue, 7 Aug 2012 02:21:20 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id D8A5D216C36; Tue, 7 Aug 2012 02:21:18 +0000 (UTC) Date: Tue, 7 Aug 2012 02:21:18 +0000 From: Evan Hunt To: Michael Richardson Message-ID: <20120807022118.GF99606@isc.org> References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> <20120806182509.GA99606@isc.org> <29040.1344285229@obiwan.sandelman.ca> <20120807013902.GD99606@isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120807013902.GD99606@isc.org> User-Agent: Mutt/1.4.2.3i Cc: "homenet@ietf.org Group" Subject: Re: [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: Tue, 07 Aug 2012 02:21:45 -0000 > 3) If a device is configured for remote access and is on a > network which has had a FQDN configured as in (2), then > in addition to the locally reachable name described in (1), > the device MUST also answer to ".". And, I'm not sure these are within the scope of homenet, but to explicitly state the design principles I'm trying to support with the previous recommendations: - Applications wanting to cache information about discovered devices should use the most globally-reachable name available for each device. In other words, if it has a FQDN and a local-only name, cache the FQDN. - When presenting cached information about devices, applications should only display local-only domain names if they were cached from the current local network. - When possible, preference should be given to the use of human-readable, human-memorable, and ideally human-selected names. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From curtis@occnc.com Tue Aug 7 08:35: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 93DAA21F858E for ; Tue, 7 Aug 2012 08:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.163, 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 70RuPt7pEnZG for ; Tue, 7 Aug 2012 08:35: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 5661521F85C9 for ; Tue, 7 Aug 2012 08:35: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 q77FZDs8001731; Tue, 7 Aug 2012 11:35:14 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208071535.q77FZDs8001731@gateway.ipv6.occnc.com> To: Mikael Abrahamsson From: Curtis Villamizar In-reply-to: Your message of "Thu, 02 Aug 2012 07:58:38 +0200." Date: Tue, 07 Aug 2012 11:35:13 -0400 Cc: homenet@ietf.org, Curtis Villamizar 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, 07 Aug 2012 15:35:43 -0000 In message Mikael Abrahamsson writes: > On Wed, 1 Aug 2012, Curtis Villamizar wrote: > > > Same answer as one given on that thread. If a device can support > > IPv4, then use NAT4. If a device can only support IPv6, then the > > DNS64 belongs on the IPv6-only device. To that device all host return > > Am I interpreting you correctly in that you're saying that an IPv6 only > device should have a built in resolver that does DNS64 in case of v6 only > connectivity? > > I can see that this would work, but is that a generally accepted solution? > On Android, this would mean that dnsmasq would need to gain DNS64 > functionality (and also needs to be able to detect the NAT64 prefix > somehow). > > -- > Mikael Abrahamsson email: swmike@swm.pp.se Re "and also needs to be able to detect the NAT64 prefix somehow": Asking DNS to resolve nat64prefix might be a solution. It might find nat64prefix.sitelocal or nat64prefix.. If so, then as long as it is on an IPv6 capable subnet (moot point if it is an IPv6 only host on a IPv4 only subnet) and can reach the nat64prefix, then it can reach the IPv4 world. This would work for mobile devices even without site local nat64 support as long as it knew where to find a remote nat64 gateway. OTOH preventing abuse of a remotely accessible nat64 gateway advertised in DNS would be a challenge. I don't think adding DNS64 to dnsmasq would be all that difficult. It is mostly translating A records into AAAA records unless I am missing something that is hard to do. Putting the DNS64 on the host would allow a mix of v6-only hosts and IPv4 only hosts and DS hosts on a DS network. On a v6-only subnet, v6 and DS hosts could operate with access to v4 only if they did DNS64. The option to put DNS64 in a gateway also exists, but would be a negative on a DS subnet if it were to accommodate a lone v6 only host (for example, a cellphone on the WiFi in a home or a hotspot running mostly v4 at this time). The problem with putting DNS64 at a gateway is that it breaks all of the v4 only devices (which are still plentiful). Curtis From curtis@occnc.com Tue Aug 7 08:40: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 968D421F8718 for ; Tue, 7 Aug 2012 08:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.157, 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 Yud67Eu614a3 for ; Tue, 7 Aug 2012 08:40:01 -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 4218721F8646 for ; Tue, 7 Aug 2012 08:40:01 -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 q77FdWC7001754; Tue, 7 Aug 2012 11:39:32 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208071539.q77FdWC7001754@gateway.ipv6.occnc.com> To: Brian E Carpenter From: Curtis Villamizar In-reply-to: Your message of "Thu, 02 Aug 2012 11:02:21 BST." <501A502D.30408@gmail.com> Date: Tue, 07 Aug 2012 11:39:32 -0400 Cc: Michael Richardson , homenet@ietf.org, curtis@occnc.com 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: Tue, 07 Aug 2012 15:40:02 -0000 In message <501A502D.30408@gmail.com> Brian E Carpenter writes: > On 01/08/2012 15:39, Curtis Villamizar wrote: > > In message <5018DD8A.2070900@gmail.com> > > Brian E Carpenter writes: > > > >> Excuse front posting, but... > >> > >>> Today there is no DHCP help in avoiding the "please reboot" messages. > >> > >> Don't RECONFIGURE (DHCPv6) and FORCERENEW (DHCP) cover this, in theory? > >> They are unicast, which is a scaling issue in enterprise networks but > >> presumably not in homenets. > >> > >> Regards > >> Brian > > > > > > These only force a renew before the lease expires. For the sometimes > > very long IPv6 leases, this is essential. For often relatively > > shorter IPv4 leases, it is nice but not quite as essential. > > > > The issue is not forcing the renew to occur earlier, it is the way in > > which a renew that changes the address is handled. Maybe its just > > implementations taking a shortcut, but I think in practice changing > > the IP address takes the interface down, kills all connections, > > including listens, and then brings it back up with a new address. > > Really? I can't test it in my current native-IPv6-deprived state, but > it seems to me that Windows (at least) runs happily with multiple IPv6 > addresses on one interface, and I can't imagine that changing one of them > will kill the others. I have to admit I haven't studied the semantics > of RECONFIGURE closely, though. > > The RFC 4192 model would look a bit sick if the interfaces get reset. > > Brian Brian, Aliases (more than one address on the same interface) has worked on every OS for a decade at least. The issue is more what occurs when a lease is withdrawn (force to renew and won't renew) and another lease is provided with a different address. AFAIK most implementations take that interface down and bring it back up. They do not keep the old address as an alias for some period of time but put new connections on the new address. Curtis > Its > > a bit like a reboot as implemented, except the user doesn't know its > > coming and therefore may have open TCP connections that break. > > > > What I've suggested is what to do on a renew that changes the address. > > Add an alias. Until the old address has no more connections or > > listens on the old address, keep the old address. Then remove the old > > address. > > > > If someone has an open connection, ssh for example, the old address > > could be in use indefinitely, but if the transition is weeks, then its > > unlikely to go beyond that. For example, if someone was using ssh to > > do a long compile on another machine, breaking the connection and > > killing the compile would be bad. There are certain to be plenty of > > other uses of long duration TCP connections that would have to be > > broken in this sort of transition, unless we can also extend TCP to > > negotiate a change to one side of the address pair. > > > > Curtis From curtis@occnc.com Tue Aug 7 08:49: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 ED57F21F8787 for ; Tue, 7 Aug 2012 08:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.152, 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 3K889Q87w22P for ; Tue, 7 Aug 2012 08:49: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 3782321F8779 for ; Tue, 7 Aug 2012 08:49: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 q77Fmxh2001866; Tue, 7 Aug 2012 11:48:59 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208071548.q77Fmxh2001866@gateway.ipv6.occnc.com> To: Brian E Carpenter From: Curtis Villamizar In-reply-to: Your message of "Thu, 02 Aug 2012 11:29:32 BST." <501A568C.9040606@gmail.com> Date: Tue, 07 Aug 2012 11:48:59 -0400 Cc: homenet@ietf.org, Curtis Villamizar , Mikael Abrahamsson 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, 07 Aug 2012 15:49:27 -0000 In message <501A568C.9040606@gmail.com> Brian E Carpenter writes: > On 02/08/2012 06:58, Mikael Abrahamsson wrote: > > On Wed, 1 Aug 2012, Curtis Villamizar wrote: > > > >> Same answer as one given on that thread. If a device can support > >> IPv4, then use NAT4. If a device can only support IPv6, then the > >> DNS64 belongs on the IPv6-only device. To that device all host return > > > > Am I interpreting you correctly in that you're saying that an IPv6 only > > device should have a built in resolver that does DNS64 in case of v6 > > only connectivity? > > > > I can see that this would work, but is that a generally accepted > > solution? On Android, this would mean that dnsmasq would need to gain > > DNS64 functionality (and also needs to be able to detect the NAT64 > > prefix somehow). > > That is one of the models discussed in BEHAVE, of course, and it deals > neatly with the DNSSEC conundrum for DNS64. But the normal model is > the one that Curtis doesn't like. NAT64/DNS64 plays better when > the client network is truly IPv6-only; with mixed hosts, you really need > to provision dual stack hosts with a normal DNS server, and the IPv6-only > hosts with a DNS64. > > Brian Brian, What you suggest might be accomplished by having DHCP4 return a different nameserver than DHCP6. At the very least the same nameserver (same copy of bind or whatever on a DS machine) could respond differently if the private side query arrives via IPv4 than if it arrives via IPv6. Worst case is DS machines make use of NAT64 when they could have used IPv4. [aside: Bind has views, but I don't know if the view support would allow this. It seems like it would. It would be nice if this were doable today with no changes. ie: existance proof] Curtis From curtis@occnc.com Tue Aug 7 10:46: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 41A9421F867D for ; Tue, 7 Aug 2012 10:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.147, 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 akjQQOitVXtF for ; Tue, 7 Aug 2012 10:46:23 -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 0F60721F8611 for ; Tue, 7 Aug 2012 10:46:22 -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 q77HjY9B003049; Tue, 7 Aug 2012 13:45:34 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208071745.q77HjY9B003049@gateway.ipv6.occnc.com> To: Ray Hunter From: Curtis Villamizar In-reply-to: Your message of "Sun, 05 Aug 2012 08:58:34 +0200." <501E199A.4060607@globis.net> Date: Tue, 07 Aug 2012 13:45:33 -0400 Cc: homenet@ietf.org, curtis@occnc.com 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: Tue, 07 Aug 2012 17:46:24 -0000 Ray, I agree with the intent of RFC6281 aka Apple BTMM, although not with many of the details of the implementation. I agree that syncing mDNS and DNS might be difficult and I propose we avoid using mDNS. A compromise is if a FQDN exists in DNS, both DNS and mDNS return a CNAME to the FQDN for local or sitelocal queries. A bad assumption is that anything on the same subnet deserves some level of trust just as a matter of having been connected to that subnet. The BTMM builds on this bad assumption by providing a means to make it appear as if remote hosts are on the same subnet or at least site by effectively using ULA as a host ID and tunneling the ULA of the remote machine. A much better way of doing things would be to use a GLA if available, particularly for IPv6 where no NAT should ever be needed. For security, on the same LAN segment or not, exchange some credential, such as a private key. This could be done at home the way most *ix people do it (put on USB stick and copy, exchange some insecure way with fingerprint verification, respect key signing by a trusted entity, etc), or for the more typical homenet customer with an insecure transfer encrypted with a shared secret (same password typed in two places, where one place could be the web page used to configure the consumer oriented junk such as printer). Delegating a sub-domain is a necessary part of any good solution that involves remote access to the homenet. sitelocal is different everywhere. .ula-based-sitelocal is unique but available only at the site. We (both in the IETF and in consumer product worlds) sometimes stand on our heads trying to work around horribly insecure home and office devices and practices that are hidden behind firewalls. Using firewalls has been proven time and again to be ineffective. In the office, one compromised PC can compromise an entire enterprise or at least the subnet it is on if weak security is in use behind the firewall. Same at home if "Mom" shows up with her old windows98 PC and an equally old PCMCIA 802.11a/b card. How may of us have been in an office where an email from IT explained that the current local network slowness is due to very high virus activity (behind the firewall!) and fear not because IT is on it? If there is a way to discover the ULA being used at a local site, then printer3..ula-based-sitelocal is functionally equivalent to printer3.sitelocal - either way it is the printer that is found if you ask for printer3 and you (or cups) don't specificy a FQDN that you learned earlier. If the first printer3.sitelocal was a CNAME for a FQDN, then an application could cache the mapping of printer3 to that FQDN or at least inform the user of the FQDN or inform the userwhen specifying printer3 results in a different FQDN than previously. Curtis In message <501E199A.4060607@globis.net> Ray Hunter writes: I disagree. The context of my message is that there should be some identifier that can disambiguate the namespace per Homenet. I'm talking about using the ULA to generate a HomenetID for use in the namespace. See RFC6281. The HomenetID and DNS subomain (or as you put it "") may be generated by one unique host (e.g. each Homenet border router) based on a ULA. But that does not mean it cannot be discovered by all hosts and routers in the Homenet (via some bunch of discovery mechanisms such as automatic prefix distribution for router-router and DHCPv6 for router - fridge). The HomenetID will remain constant as long as the ULA of the border router remains constant. If it appears to vary (because the border router changes) then highly mobile nodes will get some indication that they may not be connected to their own Homenet, and ask for user input to accept an update. Static nodes would only know their local HomenetID, and if it changed they could be set to always accept the update without user input. Eventually you would probably end up with a search list linked to the number of border routers the end node has ever encountered, but end nodes can automatically age out old entries. We might also want to be able to manually override the auto-generated HomenetID to cover the case where border router hardware is replaced by the user, but that's no different to MAC address cloning on CPE's in the past (where ISPs used the MAC address of the CPE as an identifier in management systems). Sure there's a downside in complexity of the namespace. The potential upside of this approach is that the same .sitelocal. zone file could also be mounted as a secondary on . or . if the ISP or enterprise wished to provide this service for global name resolution. Highly mobile nodes would only need two items in their DNS search list, the search list can be pretty much auto-generated, and they can use the same name resolution technology (DNS) wherever they are located. It also completely avoids trying to synch mDNS with DNS, which I think you'll agree is likely to be very difficult. > Curtis Villamizar > 4 August 2012 22:06 > With all due respect, any suggestion to use the ULA in a domain name > produces either a domain that is unique to one host or a domain that > is every bit as global as sitelocal, depending on whether by stating > "ULA prefix" you mean the local ULA or the well-known global ULA > prefix. > > In rfc4193: > > Local IPv6 unicast addresses have the following characteristics: > > - Globally unique prefix (with high probability of uniqueness). > > - Well-known prefix to allow for easy filtering at site > boundaries. > > [...] > > If you mean the first (the local ULA prefix), then the domain is > unique to one host. My computer could never find my fridge using the > hostname "fridge" unless it knew every ULA on the local network and > created an entry in the dns search path. Very long entries in the dns > search path are a very bad thing (tm). > > If you means the second (the assigned prefix under which all ULA fall) > then the domain is common to all hosts in the universe that generate a > ULA address. The only difference is it is > ..sitelocal. > > Curtis > > > In message <501965D4.1040300@globis.net> > ------------------------------------------------------------------------ From brian.e.carpenter@gmail.com Tue Aug 7 11:09: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 5991921F8764 for ; Tue, 7 Aug 2012 11:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.477 X-Spam-Level: X-Spam-Status: No, score=-101.477 tagged_above=-999 required=5 tests=[AWL=0.214, 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 ds3amxwN4tMX for ; Tue, 7 Aug 2012 11:09:11 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B98D21F875B for ; Tue, 7 Aug 2012 11:09:11 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2668676wgb.13 for ; Tue, 07 Aug 2012 11:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ldSB30kqPVDehb3Oy5kcSPRpeHJNusCicMYcqhvi4j4=; b=rDwt75NYJyCrkcStRKfHBwvHEVdV34VgRHyfO2zb7fONJENAmkafeM1jAxL+Db+S4A FCa0X4udD1e5a+6BhrcT/LmI6sCtEI4oWqXpuD7U3dfxjYcSKD/8UrER+Mha+dNNcmI0 Fsze+7Tf5l389uuZcqvVkUds7QwBoQYROOyoMtiKmmOBOImknZ5RyN2dtAOmBqn5vqSj K+PwZtyLEb+Wxaejzgn916+IwQpw1JWY7Ify53Ye2cuH+smoPB7ndkgmCfotSnQ8hOs4 b5lIyEAFXIuX067RU00WWKf2H9RZoSw+PW03JLbkSye+8CC94W3V6Fi2Kym+dwMcVCya tLKw== Received: by 10.180.81.133 with SMTP id a5mr29472224wiy.17.1344362950385; Tue, 07 Aug 2012 11:09:10 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-145.as13285.net. [2.102.216.145]) by mx.google.com with ESMTPS id z11sm761638wiv.10.2012.08.07.11.09.08 (version=SSLv3 cipher=OTHER); Tue, 07 Aug 2012 11:09:09 -0700 (PDT) Message-ID: <502159C6.6060109@gmail.com> Date: Tue, 07 Aug 2012 19:09:10 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: curtis@occnc.com References: <201208071539.q77FdWC7001754@gateway.ipv6.occnc.com> In-Reply-To: <201208071539.q77FdWC7001754@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 18:09:12 -0000 On 07/08/2012 16:39, Curtis Villamizar wrote: > In message <501A502D.30408@gmail.com> > Brian E Carpenter writes: > >> On 01/08/2012 15:39, Curtis Villamizar wrote: >>> In message <5018DD8A.2070900@gmail.com> >>> Brian E Carpenter writes: >>> >>>> Excuse front posting, but... >>>> >>>>> Today there is no DHCP help in avoiding the "please reboot" messages. >>>> >>>> Don't RECONFIGURE (DHCPv6) and FORCERENEW (DHCP) cover this, in theory? >>>> They are unicast, which is a scaling issue in enterprise networks but >>>> presumably not in homenets. >>>> >>>> Regards >>>> Brian >>> >>> These only force a renew before the lease expires. For the sometimes >>> very long IPv6 leases, this is essential. For often relatively >>> shorter IPv4 leases, it is nice but not quite as essential. >>> >>> The issue is not forcing the renew to occur earlier, it is the way in >>> which a renew that changes the address is handled. Maybe its just >>> implementations taking a shortcut, but I think in practice changing >>> the IP address takes the interface down, kills all connections, >>> including listens, and then brings it back up with a new address. >> >> Really? I can't test it in my current native-IPv6-deprived state, but >> it seems to me that Windows (at least) runs happily with multiple IPv6 >> addresses on one interface, and I can't imagine that changing one of them >> will kill the others. I have to admit I haven't studied the semantics >> of RECONFIGURE closely, though. >> >> The RFC 4192 model would look a bit sick if the interfaces get reset. >> >> Brian > > Brian, > > Aliases (more than one address on the same interface) Aliases, as you describe them, sound like a hack. I'd like to hear from Microsoft (for example) whether their support of multiple IPv6 addresses per interface is a hack or genuine. I don't care about IPv4, but the IPv6 model is very clear. You can't read the ND spec and imagine the arrival of a new address resetting sessions that use other addresses. Brian > has worked on > every OS for a decade at least. > > The issue is more what occurs when a lease is withdrawn (force to > renew and won't renew) and another lease is provided with a different > address. AFAIK most implementations take that interface down and > bring it back up. > > They do not keep the old address as an alias for some period of time > but put new connections on the new address. > > Curtis > > >> Its >>> a bit like a reboot as implemented, except the user doesn't know its >>> coming and therefore may have open TCP connections that break. >>> >>> What I've suggested is what to do on a renew that changes the address. >>> Add an alias. Until the old address has no more connections or >>> listens on the old address, keep the old address. Then remove the old >>> address. >>> >>> If someone has an open connection, ssh for example, the old address >>> could be in use indefinitely, but if the transition is weeks, then its >>> unlikely to go beyond that. For example, if someone was using ssh to >>> do a long compile on another machine, breaking the connection and >>> killing the compile would be bad. There are certain to be plenty of >>> other uses of long duration TCP connections that would have to be >>> broken in this sort of transition, unless we can also extend TCP to >>> negotiate a change to one side of the address pair. >>> >>> Curtis > From brian.e.carpenter@gmail.com Tue Aug 7 11:11: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 56EDF21F86E5 for ; Tue, 7 Aug 2012 11:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.479 X-Spam-Level: X-Spam-Status: No, score=-101.479 tagged_above=-999 required=5 tests=[AWL=0.212, 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 c01KBqRQ+pwG for ; Tue, 7 Aug 2012 11:11:14 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7A72E21F866D for ; Tue, 7 Aug 2012 11:11:14 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2669798wgb.13 for ; Tue, 07 Aug 2012 11:11: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=M/eU76nSR99qZrJmo6gVSNTf+SwTeA1h8ecFALOCeiU=; b=svnDvKLWHTLKiYZgH6hoxNViSgcGHNN1wt49nfNYLcLOmo+XUg8niXmxwaE9a32Yk4 67BhstVbhFTINYGkf2qRsUuVzhgRK8FJNCoSH8HIdd+OTA5nKbtFHEw84eRIzznnQmvE 4s0bLnUr5aaZDiiEa0MuhbVDhn2QWvGigOu611nuiJY12MktceXO/ZZF6XN5IKcrsads uXk6eeyC/sAUDOEsRGiZeNfQaB9A+nVhBmXxbEIPej3aoaQg49fFJB89VjW5CfjQWaVL UniltCaJ5uvl4tGbeVbu1fV2bYdxptiKyS3hkntSZ+TDN1x4fqxwAUxf/PhvHf5jK4wZ J7fQ== Received: by 10.180.92.9 with SMTP id ci9mr29435798wib.22.1344363073687; Tue, 07 Aug 2012 11:11:13 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-145.as13285.net. [2.102.216.145]) by mx.google.com with ESMTPS id l6sm565797wiz.4.2012.08.07.11.11.11 (version=SSLv3 cipher=OTHER); Tue, 07 Aug 2012 11:11:12 -0700 (PDT) Message-ID: <50215A42.5010200@gmail.com> Date: Tue, 07 Aug 2012 19:11:14 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: curtis@occnc.com References: <201208071548.q77Fmxh2001866@gateway.ipv6.occnc.com> In-Reply-To: <201208071548.q77Fmxh2001866@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, Mikael Abrahamsson 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, 07 Aug 2012 18:11:15 -0000 On 07/08/2012 16:48, Curtis Villamizar wrote: > In message <501A568C.9040606@gmail.com> > Brian E Carpenter writes: > >> On 02/08/2012 06:58, Mikael Abrahamsson wrote: >>> On Wed, 1 Aug 2012, Curtis Villamizar wrote: >>> >>>> Same answer as one given on that thread. If a device can support >>>> IPv4, then use NAT4. If a device can only support IPv6, then the >>>> DNS64 belongs on the IPv6-only device. To that device all host return >>> Am I interpreting you correctly in that you're saying that an IPv6 only >>> device should have a built in resolver that does DNS64 in case of v6 >>> only connectivity? >>> >>> I can see that this would work, but is that a generally accepted >>> solution? On Android, this would mean that dnsmasq would need to gain >>> DNS64 functionality (and also needs to be able to detect the NAT64 >>> prefix somehow). >> >> That is one of the models discussed in BEHAVE, of course, and it deals >> neatly with the DNSSEC conundrum for DNS64. But the normal model is >> the one that Curtis doesn't like. NAT64/DNS64 plays better when >> the client network is truly IPv6-only; with mixed hosts, you really need >> to provision dual stack hosts with a normal DNS server, and the IPv6-only >> hosts with a DNS64. >> >> Brian > > > Brian, > > What you suggest might be accomplished by having DHCP4 return a > different nameserver than DHCP6. At the very least the same > nameserver (same copy of bind or whatever on a DS machine) could > respond differently if the private side query arrives via IPv4 than if > it arrives via IPv6. Worst case is DS machines make use of NAT64 when > they could have used IPv4. Right, but that is something that people in BEHAVE thought was the worst thing since unsliced bread. Brian > > [aside: Bind has views, but I don't know if the view support would > allow this. It seems like it would. It would be nice if this were > doable today with no changes. ie: existance proof] > > Curtis > From bkerensa@gmail.com Tue Aug 7 11:20:49 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 4E62021F854A for ; Tue, 7 Aug 2012 11:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, 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 Bgc1xT3mOR8B for ; Tue, 7 Aug 2012 11:20:47 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9996E21F8550 for ; Tue, 7 Aug 2012 11:20:46 -0700 (PDT) Received: by yenm5 with SMTP id m5so2277483yen.31 for ; Tue, 07 Aug 2012 11:20:46 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=U8LnH1YNvkxShHPAP9Kb33UFL1/BRA3n8vWhOHjRt9U=; b=UYjJjmzg/FfzOEgy7CTWPtK7EN+SnE1IBXm6Mj/L2L8G0HRfAmWkGov3+KWhfiTqoC E18ouHLVmm7YAKiRSmkndW9gVySWt0tJERF68o22IunCrlC3YEy31RXS8WvDnwtbsRCf TzGXhJohePkEiBOT7AQh5tbM9Cw2kEjtszhBoYuD1kK5OQbBwTPmVopSZ9KFLahb5afC 77sYjmmOzMmuFD0g8Pa9dIsEHcrPOi3UonWvrg0bmPX38mzqb+fXcjTty4WZM1CprC+8 +hGSrt3GmVsOQ2S5C2p6BnpsfgOBVwju7wifYTiZzSbxFB9ZI/YOcpwE7HJjQ75DMofA EFBg== Received: by 10.50.157.136 with SMTP id wm8mr9580099igb.14.1344363645664; Tue, 07 Aug 2012 11:20:45 -0700 (PDT) MIME-Version: 1.0 Sender: bkerensa@gmail.com Received: by 10.64.7.104 with HTTP; Tue, 7 Aug 2012 11:20:05 -0700 (PDT) In-Reply-To: <20120801082004.25B4C23298EA@drugs.dv.isc.org> References: <201208010333.q713XjUb089327@gateway.ipv6.occnc.com> <20120801082004.25B4C23298EA@drugs.dv.isc.org> From: Benjamin Kerensa Date: Tue, 7 Aug 2012 11:20:05 -0700 X-Google-Sender-Auth: w_hjdE-JVbjUdnCg749QvCnpCxE Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=e89a8f234cc38c7df504c6b10d5c Cc: Michael Richardson , homenet@ietf.org, curtis@occnc.com 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, 07 Aug 2012 18:20:49 -0000 --e89a8f234cc38c7df504c6b10d5c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 1, 2012 at 1:20 AM, Mark Andrews wrote: > > In message <201208010333.q713XjUb089327@gateway.ipv6.occnc.com>, Curtis > Villamizar writes: > > > > 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). > > Define short? There are plenty of homes with equipment that isn't > powered down every day and that has been up for months. > > I don't know about other but I maintain ssh connections for weeks > from home to the main office at work. > > > 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. > > What's the dhcp stuff in the home? RA's work fine here. What is > needed is a way to signal in the DNS to only use a deprecated address > as a last resort measure. Named to address and address to name > mappings need to exist until after the address has ceased being > used. > > > 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". > > Actually you should be asking the OS vendors / distro maintainers > to do this and send fixes to ISC. This is all done in shell scripts > that are highly customised to the client platform. There isn't one > linux script that works for all linux distros. > Unfortunately this is true and this hopefully in the future will be more standardized. > > This also doesn't work for many udp based services. > > > 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. > > At the moment. There is no good reason to not be listening on > standard ports if you want to provide your own servers within the > home. DNS will almost certainly be done if only to as hidden > masters. Just publish your current addresses in the DNS and they > can be reached. Cable and DSL are always on services. Homes are > no longer dialup. > I disagree with the assertion that "Homes" are no longer on dial-up since a good portion of Rural America still does not have Broadband which means millions are still on Dial-Up and I hear parts of Europe still use Dial-Up. > > > 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. > > _______________________________________________ > > 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 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Benjamin Kerensa *Team Lead, *Ubuntu Oregon http://ubuntu-oregon.org Phone: 503-894-6005 x701 *This message may contain information which is privileged or confidential. If you are not the named addressee of this message please destroy it without reading, using, copying or disclosing its contents to any other person.* * * --e89a8f234cc38c7df504c6b10d5c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Aug 1, 2012 at 1:20 AM, Mark And= rews <marka@isc.org> wrote:

In message <201208010333.q713XjUb089327@gateway.ipv6.occnc.com>, Curti= s Villamizar writes:
>
> In message <50181A1C.= 5050803@gmail.com>
> Brian E Carpenter writes:
>
> > On 31/07/2012 17:59, Michael Richardson wrote:
> > >>>>>> "Brian" =3D=3D Brian E Carpent= er <Brian> writes:
> > > =A0 =A0 >> I'm also surprised that we think we hav= e to cope with flash renumbering
> > > =A0 =A0 >> as a regular event, rather than a service-i= nterrupting, ISP truck roll
> > > =A0 =A0 >> catastrophy.
> > >
> > > =A0 =A0 Brian> But every time you reboot your antiquated = v4-only CPE
> > > =A0 =A0 Brian> and/or the antiquated
> > > =A0 =A0 Brian> v4-only PCs behind it, the PCs all get new= IP addresses,
> > > =A0 =A0 Brian> which may or
> > > =A0 =A0 Brian> may not be the same as the previous time. = There's nothing
> > > =A0 =A0 Brian> new in flash
> > > =A0 =A0 Brian> renumbering for homenets. Not handling thi= s would be a step
> > > =A0 =A0 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
> > > =A0 =A0previous IP, it usually gets honored.
> >
> > It doesn't matter whether it's the user or the ISP that t= riggers a
> > change, does it?
> >
> > The point is, users don't care about this, except if they rea= ch their
> > shiny new wireless printer via its IP static address. There are > > definitely parts of draft-ietf-6renum-static-problem that apply h= ere.
> >
> > =A0 =A0Brian
>
>
> Brian,
>
> Enterprise renumbering and homenet renumbering are generally quite
> different. =A0Most homehets have short uptimes. =A0Most enterprises ha= ve
> very long uptimes. =A0(insert favorite Microsoft reliability joke here= ).

Define short? =A0There are plenty of homes with equipment that = isn't
powered down every day and that has been up for months.

I don't know about other but I maintain ssh connections for weeks
from home to the main office at work.

> If a renumbering is done right, there is an time when both the old and=
> new numbers are in use. =A0As in "ifconfig <intf> inet6 new= addr
> ... alias" in the *ix world. =A0During that transition time any u= se of
> DHCP will hand out the new address. =A0Then comes a time when the leas= es
> refuse to be renewed. =A0Then the old addresses go away. =A0This can b= e
> day, weeks, or longer depending on the size of the transition. =A0Duri= ng
> that time a lot of "please reboot at least once ..." message= s get
> sent.

What's the dhcp stuff in the home? =A0RA's work fine here. = =A0What is
needed is a way to signal in the DNS to only use a deprecated address
as a last resort measure. =A0Named to address and address to name
mappings need to exist until after the address has ceased being
used.

> 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:
>
> =A0 1. =A0Add the new address using an "ifconfig <intf> ...= alias"
> =A0 =A0 =A0 equivalent.
>
> =A0 2. =A0Check (using netstat -an equivalent) for use of the old addr= ess.
> =A0 =A0 =A0 Don't delete the old address if a socket still exists.=
>
> =A0 3. =A0Periodically repeat step 2 until there is no connection usin= g
> =A0 =A0 =A0 the old address.
>
> =A0 4. =A0Delete the old address using the equivalent of "ifconfi= g <intf>
> =A0 =A0 =A0 ... -alias".

Actually you should be asking the OS vendors / distro maintainers
to do this and send fixes to ISC. =A0This is all done in shell scripts
that are highly customised to the client platform. =A0There isn't one linux script that works for all linux distros.

Unfortunately this is true and this hopefully in the future will be= more standardized.
=A0

This also doesn't work for many udp based services.

> This would work for all client side connects that either were done
> before the end of the transition period. =A0For home nets this covers<= br> > 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. =A0This is rare among home nets (except for homes of reade= rs
> of IETF lists) but very common among enterprises.

At the moment. =A0There is no good reason to not be listening on
standard ports if you want to provide your own servers within the
home. =A0DNS will almost certainly be done if only to as hidden
masters. =A0Just publish your current addresses in the DNS and they
can be reached. =A0Cable and DSL are always on services. =A0Homes are
no longer dialup.

I disagree with the a= ssertion that "Homes" are no longer on dial-up since a good porti= on of Rural America still does not have Broadband which means millions are = still on Dial-Up and I hear parts of Europe still use Dial-Up.=A0

> Many points made about license servers, etc in
> draft-ietf-6renum-static-problem don't apply to home nets.
>
> Renumbering an enterprise is doable. =A0Renumbering my home net has be= en
> quite easy. =A0I've done it a few times already and I'm sure w= ill have
> to again. =A0The procedure suggested above is just done manually.
>
> One hint is that on BSD and Linux at least a "netstat -an" s= hould
> reveal any listens on old addresses. =A0An automated scan on an
> enterprise network can identify servers and services needing a
> reconfig and a service restart without any system reboot. =A0[ Microso= ft
> systems may need to reboot or power down and remove the CMOS battery > from the motherboard or maybe buy new hardware. =A0:-) ]
>
> > >
> > > In IPv6 space, the host part will generally stay the same (m= odulo
> > > privacy extensions, which are default on for some clients). = =A0We've said
> > > that the ULA ought to stay the same, so in fact, I agree, th= e internal
> > > addresses actually all stay the same.
> > >
> > > I'm still surprised that an ISP will need to flash renum= ber faster than
> > > it can just expire leases. =A0If it's just repartitionin= g of network to
> > > deal with growth, that ought to be predictable and prefix li= fetimes can
> > > be reduced in advance.
> > >
> > > If it's actually some equipment failing, resulting in se= rvice
> > > interruptions, and then restoration by rewiring the network.= .. then I
> > > understand.
> _______________________________________________
> 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@isc.org
_____________________= __________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet



--
=
Benjamin Kerensa
Team Lead, Ubuntu Oregon
Phone:=A0503-894-6005 x701
=A0=A0=A0=A0=A0=A0=A0=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0=A0
This message may contain information which is privileged or confide= ntial.
If you are not the named addressee of this message please destroy= it without reading, using, copying or disclosing its contents to any other= person.


--e89a8f234cc38c7df504c6b10d5c-- From mcr+ietf@sandelman.ca Tue Aug 7 11:31: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 BCF4A21F8607 for ; Tue, 7 Aug 2012 11:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=0.838, 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 VUH9i7Oaf8-q for ; Tue, 7 Aug 2012 11:31:53 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB3221F859A for ; Tue, 7 Aug 2012 11:31: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 9C0DA20170; Tue, 7 Aug 2012 14:44:35 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <502159C6.6060109@gmail.com> References: <201208071539.q77FdWC7001754@gateway.ipv6.occnc.com> <502159C6.6060109@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, curtis@occnc.com Subject: [homenet] IPv6 aliases and renumbering (was Re: 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, 07 Aug 2012 18:31:53 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Brian" =3D=3D Brian E Carpenter writes: Brian> Aliases, as you describe them, sound like a hack. I'd like to Brian> hear from Microsoft (for example) whether their support of Brian> multiple IPv6 addresses per interface is a hack or genuine. I Brian> don't care about IPv4, but the IPv6 model is very clear. You Brian> can't read the ND spec and imagine the arrival of a new Brian> address resetting sessions that use other addresses. On Linux and *BSD, (possibly including OSX, but I don't know, but I could do an experiment with my officemate), new addresses get added without an interface flap. Old addresses expire as they expire, no interface flap need occur. Linux does this all in the kernel, *BSD does it in rtsold. I can't speak of what happens with dhcpv6. The choice of which one to use for new connections essentially depends upon the metrics on the route to that destination. Typically, for off-link destinations, it's the default route that matters. Where I think we see interface flaps is as a result of DHCPv4. If we lose connectivity to the DHCPv4, then the dhclient-daemon will reset the interface and start again. With wifi, this is often more frequent. I have had IPv6 connections survive such events, but not always. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUCFfEIqHRg3pndX9AQJFFQQAx2+X732OIsklILbRepXZlllrzcjMZ3QD EcpSIez5TUQOBbD6PC3h99uFGvQZqEW0c1xDI/ZlZFm4gpoCGSbmJor4qOOpR6ZV 8iXTxA48WJ19AgbU9NfvpxKTxdg7c9SwaFuJIRwQtrkSOlu5rvG/6kpqf4SjqSqP QaBloRoRgy8= =BiGD -----END PGP SIGNATURE----- --=-=-=-- From kerlyn2001@gmail.com Tue Aug 7 11:46: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 7CB8621F86A5 for ; Tue, 7 Aug 2012 11:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.520, 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 zwyHiUadvv7h for ; Tue, 7 Aug 2012 11:46:49 -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 0A18321F860B for ; Tue, 7 Aug 2012 11:46:40 -0700 (PDT) Received: by lahm15 with SMTP id m15so2475702lah.31 for ; Tue, 07 Aug 2012 11:46:40 -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=TU4IRJHLuDaz1848HfyAEzazV31X7rMFMf1pgpT1Zv0=; b=Jjiexle8rLEdBafMZfXpVbBDDfapBqiIiy4B5T5Z+2ZbY8mYgGtI7L/476hSwrFD9d eWW4IbooU92dVWlV5tlv9++qyJRP1LRPbh07MYGDb9axyVSA9cG5tf0+GKLhfDGGgqr2 QblWYiHbB66c4F+gxmG40jDOGbjj5B33t7R4EFgh05n5+AxqkCMkKa9OAZNTkGK3K5Qu i6nxuWcOGIn0phHaxzL3NeZ2qADVsukGnA8C0QiXuSv2XZT0UH/Ev+Z4hq2h6/RK0SbY O+UfOa/SFT66LJEgEzjmuibfeaDA3M20mirobf909txpkeKEDpbtO3w5b4gPqjlXGbqF ZlPg== MIME-Version: 1.0 Received: by 10.152.136.18 with SMTP id pw18mr15392157lab.17.1344365199867; Tue, 07 Aug 2012 11:46:39 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.10.199 with HTTP; Tue, 7 Aug 2012 11:46:39 -0700 (PDT) In-Reply-To: <20120807013902.GD99606@isc.org> References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> <20120806182509.GA99606@isc.org> <29040.1344285229@obiwan.sandelman.ca> <20120807013902.GD99606@isc.org> Date: Tue, 7 Aug 2012 14:46:39 -0400 X-Google-Sender-Auth: l_m5b_9h0kMcMgKYfAaaADKGPRU Message-ID: From: Kerry Lynn To: Evan Hunt Content-Type: text/plain; charset=ISO-8859-1 Cc: Michael Richardson , "homenet@ietf.org Group" Subject: Re: [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: Tue, 07 Aug 2012 18:46:50 -0000 On Mon, Aug 6, 2012 at 9:39 PM, Evan Hunt wrote: > On Mon, Aug 06, 2012 at 04:33:49PM -0400, Michael Richardson wrote: >> No, the fridge must have a globally reachable address (GUA) to be reachable. > > You are correct, of course, and I was being unclear; sorry about that. > I was trying to reflect what I thought I heard in the discussion in > Vancouver, though, which was that a FQDN or the equivalent would be the > best way to handle naming of remotely accessible devices. It seemed to > me that we had rough consensus on that point (perhaps I was mistaken), > but not on naming of devices on "island" networks. > >> Tunnels are okay, but to use them, but has to get the DNS search order >> and the DNS server list right, and that's walled garden territory. >> *If* we are going to turn each home into a walled garden, then let's be >> aware that we are doing that. > I'm of the opinion that in a "walled garden" scenario, the tunnel endpoint may be the only resource that needs a global name / address. I note that dyndns supports a wide-area DNS-SD beta (ability to populate PTR, SRV, and TXT RRs) and I'm going to look into this approach as an alternative to BTMM. > For the purposes of my mom's house, I do think "walled garden" is the > appropriate default setting, but our design should allow the default > to be overridden without great difficulty. > I am generally supportive of this approach; certainly it would focus the discussion between now and Atlanta. > I think this general plan would meet those goals: > > 1) All discoverable devices on all networks MUST answer > to a locally reachable name, such as .local, > .sitelocal, ..local, > ., -.local, etc. (We > haven't settled the naming convention here. I personally like > ..local, with ..local > as a fallback in the event of the network's owner failing to > configure a network name); > +1, with the caveat that ".local." has special semantics (multicast DNS-like requests to FF02::FB, port 5353) defined by http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns > 2) Networks configured to allow remote access to devices > SHOULD have a globally reachable domain name, either owned > by the user or in a vendor-managed namespace; > I'd like a bit more explanation re: this requirement. In general it seems there is no relation between a network and a domain name. Exceptions would include ".local." (maps to the local _link_, and therefore to the prefix(es) assigned to that link; or domains ending in ".in-addr.arpa.". http://tools.ietf.org/html/draft-cheshire-dnsext-dns-sd section 11 has a method for determining the preferred registration zone(s) based on a host's address. > 3) If a device is configured for remote access and is on a > network which has had a FQDN configured as in (2), then > in addition to the locally reachable name described in (1), > the device MUST also answer to ".". > I like to see us reserve "FQDN" for host names that are registered in the global DNS namespace, and use "LQDN" (or some other alternative) for host names in locally served zones. Any support for this? -K- > -- > Evan Hunt -- each@isc.org > Internet Systems Consortium, Inc. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mike@mtcc.com Tue Aug 7 12:11: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 AD4D421F86EA for ; Tue, 7 Aug 2012 12:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=-0.099, 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 b6TN7i4QQNh9 for ; Tue, 7 Aug 2012 12:11:45 -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 55BB221F86EC for ; Tue, 7 Aug 2012 12:11:44 -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 q77JBeel026778 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 7 Aug 2012 12:11:41 -0700 Message-ID: <5021686C.60308@mtcc.com> Date: Tue, 07 Aug 2012 12:11:40 -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: Kerry Lynn References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> <20120806182509.GA99606@isc.org> <29040.1344285229@obiwan.sandelman.ca> <20120807013902.GD99606@isc.org> 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=614; t=1344366701; x=1345230701; 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]=20tunnels=20as=20way=20to=20d isambiguate=20.local |Sender:=20 |To:=20Kerry=20Lynn=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=3ozDW9zwSkAVxUJ5bBSpvIdUdB1tPve7vMvNPtAivIE=; b=NUmyDK6/PD7Ce5fNVNgZgt9IjryM29H2/isXbULy7I5XJC4ZpkVxKTnQO+ VyKmea1gk5bkwjvWDa0UdmaLVHOVYGKeK1y471pnsOx7Qs9MYKAPAQ8mc99D R9V8hB1RF7b73OqLaJ2vsKW+YErmcuS2oDnHd6LAXducB7aFzkKlo=; 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: Evan Hunt , Michael Richardson , "homenet@ietf.org Group" Subject: Re: [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: Tue, 07 Aug 2012 19:11:45 -0000 On 08/07/2012 11:46 AM, Kerry Lynn wrote: > On Mon, Aug 6, 2012 at 9:39 PM, Evan Hunt wrote: >> >> Tunnels are okay, but to use them, but has to get the DNS search order >> and the DNS server list right, and that's walled garden territory. >> *If* we are going to turn each home into a walled garden, then let's be >> aware that we are doing that. > I'm of the opinion that in a "walled garden" scenario, the tunnel endpoint may > be the only resource that needs a global name / address. Just checking, but we all think that naming is a separate issue from reachability, right? Mike From ajs@anvilwalrusden.com Tue Aug 7 12:19: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 C6C5121F8717 for ; Tue, 7 Aug 2012 12:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 jtnh3GxaCmCi for ; Tue, 7 Aug 2012 12:19:30 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 42B4121F8713 for ; Tue, 7 Aug 2012 12:19:30 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 558C18A031 for ; Tue, 7 Aug 2012 19:19:29 +0000 (UTC) Date: Tue, 7 Aug 2012 15:19:27 -0400 From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20120807191927.GB53917@mail.yitter.info> References: <20120806020656.GA88914@isc.org> <20120806182509.GA99606@isc.org> <29040.1344285229@obiwan.sandelman.ca> <20120807013902.GD99606@isc.org> <5021686C.60308@mtcc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5021686C.60308@mtcc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [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: Tue, 07 Aug 2012 19:19:30 -0000 On Tue, Aug 07, 2012 at 12:11:40PM -0700, Michael Thomas wrote: > > Just checking, but we all think that naming is a separate issue > from reachability, right? I certainly think so. I also think the idea that you need to "disambiguate" .local is completely broken. Once you need to disambiguate, you're already into a situation where .local is the wrong answer. MIF at least has an excuse for needing to sort out different resolution contexts. What's ours? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From mcr+ietf@sandelman.ca Tue Aug 7 12:54: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 5A67521F8746 for ; Tue, 7 Aug 2012 12:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.629, 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 Y6hEwMZE9uFl for ; Tue, 7 Aug 2012 12:54:46 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id D5BFD21F8745 for ; Tue, 7 Aug 2012 12:54:45 -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 E82442017F; Tue, 7 Aug 2012 16:07:29 -0400 (EDT) From: Michael Richardson To: Michael Thomas In-Reply-To: <5021686C.60308@mtcc.com> References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> <20120806182509.GA99606@isc.org> <29040.1344285229@obiwan.sandelman.ca> <20120807013902.GD99606@isc.org> <5021686C.60308@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: Evan Hunt , Kerry Lynn , "homenet@ietf.org Group" Subject: Re: [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: Tue, 07 Aug 2012 19:54:46 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Michael" =3D=3D Michael Thomas writes: Michael> Just checking, but we all think that naming is a separate Michael> issue from reachability, right? It's separate. The question is: does the set of names you can resolve depend upon the connectivity that you have? (the "reachability")=20=20 I think that this is a form of security through obscurity, and I'd rather that the various carriers who want to impose walled gardens on their video-over-3G-to-smartphone systems (causing changes up to the application layers) would do something different. I overheard a snippit of conversation last week from Lorenzo about what Android will be doing to "support" walled garden DNS. I can't repeat it, because I didn't hear the answer... =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUCFyf4qHRg3pndX9AQKonAQAsqROxOtG/qPsHPuo/LzvFk4XwBO6Mkvz KdrOqFL/Ft/sYJWHtJirlE32aVB0fX9y2ltS070Lj/AAA4hIHEUgZ2kAFugPk8lV ej0Wqe05/jEJ9ri44nN+ft5ij5EkBxqC9ouDuiCaHAd0fH4p9uCHtKu1A1ZcAsG4 dZcJuikJMEQ= =CdHs -----END PGP SIGNATURE----- --=-=-=-- From gettysjim@gmail.com Tue Aug 7 13:00: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 EAC9511E80A3 for ; Tue, 7 Aug 2012 13:00: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 KzBdAxW8r8HK for ; Tue, 7 Aug 2012 13:00:21 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id D728E11E80A6 for ; Tue, 7 Aug 2012 13:00:20 -0700 (PDT) Received: by vcbfw7 with SMTP id fw7so4072399vcb.25 for ; Tue, 07 Aug 2012 13:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=p2oNKck3M02TEKWm9XUm3mz6ZrC+YzHvbcZUKg4HC80=; b=ngmoJCDuxfkq+BEU5WYIUgxTV6AujeFnfoo8zRoYzh75WtCRTgUoZpgc0BKM0p7TJL hgva/mU1aAxRgTnhAmADs9rGwnyF8NomXK9DaIcugb5XxRq8oiWdCvLy9wWJ5qyAaIhP d1AZ4TRtNZcTdq5nBGOKFF5vKmfcqbiE8kclUwuRWLwXI5cuF5CHyaBsLU1aUEQmcCvt //0qlo0ISojS11wVFcLnwelxhPKxy1Hh93A8WSUYoFDcAr1go546HQQlr2cH5HxsAYfk sE7zqLXPXusy9i4Bfk7acH8GHFurI2aPsbH/2RsCocDHAi1GFN+eoG4jITNhDsXhHxhI FewA== Received: by 10.58.74.196 with SMTP id w4mr13454730vev.7.1344369620114; Tue, 07 Aug 2012 13:00:20 -0700 (PDT) Received: from [192.168.1.80] (c-24-218-181-108.hsd1.ma.comcast.net. [24.218.181.108]) by mx.google.com with ESMTPS id l12sm19307936vdh.8.2012.08.07.13.00.19 (version=SSLv3 cipher=OTHER); Tue, 07 Aug 2012 13:00:19 -0700 (PDT) Sender: Jim Gettys Message-ID: <502173D2.3030103@freedesktop.org> Date: Tue, 07 Aug 2012 16:00:18 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Michael Richardson References: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> <20120806182509.GA99606@isc.org> <29040.1344285229@obiwan.sandelman.ca> <20120807013902.GD99606@isc.org> <5021686C.60308@mtcc.com> <23819.1344369279@obiwan.sandelman.ca> In-Reply-To: <23819.1344369279@obiwan.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Evan Hunt , Kerry Lynn , Michael Thomas , "homenet@ietf.org Group" Subject: Re: [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: Tue, 07 Aug 2012 20:00:22 -0000 On 08/07/2012 03:54 PM, Michael Richardson wrote: >>>>>> "Michael" == Michael Thomas writes: > Michael> Just checking, but we all think that naming is a separate > Michael> issue from reachability, right? > > It's separate. > > The question is: does the set of names you can resolve depend upon the > connectivity that you have? (the "reachability") Yes. > > I think that this is a form of security through obscurity, and I'd > rather that the various carriers who want to impose walled gardens on their > video-over-3G-to-smartphone systems (causing changes up to the > application layers) would do something different. > > I overheard a snippit of conversation last week from Lorenzo about what > Android will be doing to "support" walled garden DNS. I can't repeat > it, because I didn't hear the answer... Many corporations also hide internal names from the global DNS. This isn't just a carrier "thing". It is possible to configure bind to "do the right thing" to query different name servers in different part of the name space. So it is technically possible to set up name resolution to work when tunnels come and go. I take no position as to whether these corporations are sane about their security policies, however. - Jim From mike@mtcc.com Tue Aug 7 13:08: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 DB5B021F8720 for ; Tue, 7 Aug 2012 13:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 sthaOce0VQkr for ; Tue, 7 Aug 2012 13:08:50 -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 9133121F870B for ; Tue, 7 Aug 2012 13:08:50 -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 q77K8iug013982 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 7 Aug 2012 13:08:44 -0700 Message-ID: <502175CC.7070802@mtcc.com> Date: Tue, 07 Aug 2012 13:08:44 -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: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> <20120806182509.GA99606@isc.org> <29040.1344285229@obiwan.sandelman.ca> <20120807013902.GD99606@isc.org> <5021686C.60308@mtcc.com> <23819.1344369279@obiwan.sandelman.ca> In-Reply-To: <23819.1344369279@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=1299; t=1344370125; x=1345234125; 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]=20tunnels=20as=20way=20to=20d isambiguate=20.local |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=vWhrDlzZoJCoMqzHm/4vifrSAte78uOz5aOauJx8HPA=; b=SbAHsNZaZq4JLG3Id1dtPI2YJl7+VmkQUlA3vm4oS4qWqScW0rCZXUBXte v151KeO0dEpBdOrlXSap130P8wF39ePH2UsvD8NVTJtRwzV7lxWBJaTAXm4N mMHL7CpsmonyHSR9Xew9kxACnPpg1FUO0LpXNTidW0pE6j9lDv5uw=; 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: Evan Hunt , Kerry Lynn , "homenet@ietf.org Group" Subject: Re: [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: Tue, 07 Aug 2012 20:08:52 -0000 On 08/07/2012 12:54 PM, Michael Richardson wrote: >>>>>> "Michael" == Michael Thomas writes: > Michael> Just checking, but we all think that naming is a separate > Michael> issue from reachability, right? > > It's separate. > > The question is: does the set of names you can resolve depend upon the > connectivity that you have? (the "reachability") > > I think that this is a form of security through obscurity, and I'd > rather that the various carriers who want to impose walled gardens on their > video-over-3G-to-smartphone systems (causing changes up to the > application layers) would do something different. As a security property was mainly what I was getting at. We're not thinking that .local is bringing us anything on the security front wrt reachability (privacy being a different issue). So it seems we all hopefully agree. Now what to with about the privacy issue... bletch. .local[site] has similar considerations along those lines it seems to me, though the mechanisms are different confusing the issue even more. Mike > > I overheard a snippit of conversation last week from Lorenzo about what > Android will be doing to "support" walled garden DNS. I can't repeat > it, because I didn't hear the answer... > > > > From each@isc.org Tue Aug 7 14: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 743E721F8541 for ; Tue, 7 Aug 2012 14:28:25 -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 ob6vx7dm9ITU for ; Tue, 7 Aug 2012 14:28:25 -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 ECCF521F853F for ; Tue, 7 Aug 2012 14:28:24 -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 818425F9953; Tue, 7 Aug 2012 21:28:10 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id C485B216C3D; Tue, 7 Aug 2012 21:28:08 +0000 (UTC) Date: Tue, 7 Aug 2012 21:28:08 +0000 From: Evan Hunt To: Michael Thomas Message-ID: <20120807212808.GA28642@isc.org> References: <20120806020656.GA88914@isc.org> <20120806182509.GA99606@isc.org> <29040.1344285229@obiwan.sandelman.ca> <20120807013902.GD99606@isc.org> <5021686C.60308@mtcc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5021686C.60308@mtcc.com> User-Agent: Mutt/1.4.2.3i Cc: Michael Richardson , Kerry Lynn , "homenet@ietf.org Group" Subject: Re: [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: Tue, 07 Aug 2012 21:28:25 -0000 On Tue, Aug 07, 2012 at 12:11:40PM -0700, Michael Thomas wrote: > Just checking, but we all think that naming is a separate issue > from reachability, right? Separate, but in the context of recommended configuration for home networks under the control of non-geeks, I'd say they're related. In that context, we would like reachable devices to have names, and we would like devices that are reachable remotely to have names that are resolvable remotely. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From curtis@occnc.com Tue Aug 7 15:35: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 362B421F855E for ; Tue, 7 Aug 2012 15:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.142, 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 nIstOlHwWugX for ; Tue, 7 Aug 2012 15:35:31 -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 4537521F8559 for ; Tue, 7 Aug 2012 15:35:31 -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 q77MZPf3005869; Tue, 7 Aug 2012 18:35:25 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208072235.q77MZPf3005869@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Thu, 02 Aug 2012 10:18:24 EDT." <8469.1343917104@obiwan.sandelman.ca> Date: Tue, 07 Aug 2012 18:35:25 -0400 Cc: homenet@ietf.org Subject: Re: [homenet] forced renumbering in the home (was Re: 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: Tue, 07 Aug 2012 22:35:32 -0000 In message <8469.1343917104@obiwan.sandelman.ca> Michael Richardson writes: > >>>>> "Brian" == Brian E Carpenter writes: > Brian> Really? I can't test it in my current native-IPv6-deprived > Brian> state, but it seems to me that Windows (at least) runs > Brian> happily with multiple IPv6 addresses on one interface, and I > > Linux too, and sometimes this is a bad thing. > If you suspend/resume between home/work wired, I've had the problem > where I can't reach the other because said address still lingering on > interface makes my laptop think it's still "on the wire" with both. > (you have to suspend-then-unplug, otherwise, disconnecting the cable > works as a clue to flush the addresses) > > > Michael Richardson , Sandelman Software Works When in doubt RTFC. Digression follows, possibly with something relevant at the end, but maybe more for DHC WG. dhclient.c makes use of dhclient-script BOUND|RENEW|REBIND|REBOOT) check_hostname if [ -n "$old_ip_address" ]; then if [ "$old_ip_address" != "$alias_ip_address" ]; then delete_old_alias fi if [ "$old_ip_address" != "$new_ip_address" ]; then delete_old_address delete_old_routes fi fi That look to me like the old address is deleted, *then* the new address is added whenever the lease that has been selected out of multiple offers is not the one that had previously been selected. This is dhclient on freebsd which is a DHCPv4 client. Looking at the ISC DHCP client (also dhclient, but with DHCPv6 support) I find much different code. if [ ${reason} = BOUND6 ] ; then # ... ifconfig ${interface} inet6 ${new_ip6_address}/${new_ip6_prefixlen} alias # ... exit_with_hooks 0 fi if [ ${reason} = EXPIRE6 -o ${reason} = RELEASE6 -o ${reason} = STOP6 ] ; then # ... ifconfig ${interface} inet6 ${old_ip6_address}/${old_ip6_prefixlen} -alias # ... exit_with_hooks 0 fi In this case, an expire or release is needed to remove an old lease. It may be that if your DHCP server never had the chance to remove a lease and you did suspend and plug in somewhere else and get a new lease, then the old lease will hang around until it expires, potentially days. That may be a bug. Your Linux box is then left free to bind new sockets to the old address and there is no way to mark it as old and avoid it. The behaviour I suggested earlier was (briefly): 1. Install new address as an alias (ie: ifconfig ... alias) 2. Avoid binding sockets to old address (see below) 3. Make sure old address is no longer in use (as best as possible), then remove old address with a -alias (ie: ifconfig ... -alias). That is not what is being done in either case. There is currently no kernel mechanism for step 2 above. (Note: prefer_source is close but not quite). What is needed is something that modifies an alias such that it is not considered in the selection but keeps it. (Possible syntax: "ifconfig ... stale" where stale replaces the alias or -alias, modifying an existing alias). A new interface address flag (as in ifa_flags) might do the trick if used with the SIOCAIFADDR ioctl, however ifaliasreq doesn't have a place for a set of flags. It could be that IFF_DYING could be set on the ifa_flags in the struct ifaddr contained in either struct in6_ifaddr or struct in_ifaddr. IFF_DYING can currently be set on an interface but not on an address and it is only set internally to the kernel. It is only referenced in sys/net/if.c in all of the BSD source and there only four places. This would be an appropriate reuse of that flag bit that would not conflict with the existing use (in the ifnet struct). In any case, this is more appropriate for DHC (if at all) and even DHC isn't chartered with patching the kernel, or changing ifconfig and isc dhcp client, but it could recommend behavior when the lease changes. Curtis From curtis@occnc.com Tue Aug 7 19:32: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 EAAB821F85A0 for ; Tue, 7 Aug 2012 19:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.138, 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 7F66WeRqf0v4 for ; Tue, 7 Aug 2012 19:32:31 -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 4E9C721F8562 for ; Tue, 7 Aug 2012 19:32:29 -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 q782WKeV007846; Tue, 7 Aug 2012 22:32:22 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208080232.q782WKeV007846@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Thu, 02 Aug 2012 10:20:37 EDT." <8857.1343917237@obiwan.sandelman.ca> Date: Tue, 07 Aug 2012 22:32:20 -0400 Cc: homenet@ietf.org 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, 08 Aug 2012 02:32:32 -0000 In message <8857.1343917237@obiwan.sandelman.ca> Michael Richardson writes: > >>>>> "Brian" =- Brian E Carpenter writes: > Brian> Correct, but the name is unambiguous, which IMHO is a MUST > Brian> property for anything that looks like an FQDN. We have to > Brian> live with .local but it should be just a nasty memory like > Brian> 10.0.0.0/8 fifty years from now. > > Brian> I would suggest instructing IANA to reserve all TLD strings > Brian> that start with "local" and using something like > Brian> .local-fd952a92a67d to name the homenet domain. It's only a > Brian> convenience to use a ULA prefix; it's simply a unique string > Brian> that the CPE needs to generate anyway, but it has no > Brian> significance beyond that. > > huh, you want to do it that way? > Why not fd952a92a67d.local? > > I'm asking for clarification, not disagreeing. > > > Michael Richardson , Sandelman Software Works I'd prefer mDNS returns a mapping of printer3.local to a CNAME printer3.fqdn and DNS returns a mapping of printer3.sitelocal (or localsite if you prefer) to CNAME printer3.fqdn. In both cases, if there is a subdomain delegated by the provider, then fqdn is that subdomain, and if no subdomain has been delegated, then the fqdn is of the form .local (ie: fd952a92a67d.local in your example). An application can (though none today do, cups for example could be changed) obtain the query results using the partial domain name (ie: printer3) and gethostbyname2 to get an address and then use gethostbyaddr to do an rDNS lookup to get the FQDN if printer3.sitelocal was first in the DNS search path. If the mapping from printer3.sitelocal were to change, the user could be given a choice to use the new printer3.sitelocal or use the old one through the FQDN. Multiple mappings of printer3.sitelocal could be retained, such that printer3 yielded a list each time a request was made to print using this unqualified name. Of course that would mean rDNS would have to work. Curtis From marka@isc.org Tue Aug 7 23:23: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 0887921F84B6 for ; Tue, 7 Aug 2012 23:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 KGsQE3gh2eU1 for ; Tue, 7 Aug 2012 23:23:21 -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 08B8921F84B3 for ; Tue, 7 Aug 2012 23:23:20 -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 B4AE0C94E1; Wed, 8 Aug 2012 06:23:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (173-11-96-181-SFBA.hfc.comcastbusiness.net [173.11.96.181]) (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 9A093216C33; Wed, 8 Aug 2012 06:23:08 +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 CF24C235B0A4; Wed, 8 Aug 2012 16:23:06 +1000 (EST) To: Benjamin Kerensa From: Mark Andrews References: <201208010333.q713XjUb089327@gateway.ipv6.occnc.com> <20120801082004.25B4C23298EA@drugs.dv.isc.org> In-reply-to: Your message of "Tue, 07 Aug 2012 11:20:05 MST." Date: Wed, 08 Aug 2012 16:23:06 +1000 Message-Id: <20120808062306.CF24C235B0A4@drugs.dv.isc.org> Cc: Michael Richardson , homenet@ietf.org, curtis@occnc.com 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: Wed, 08 Aug 2012 06:23:22 -0000 In message , Benjamin Kerensa writes: > > On Wed, Aug 1, 2012 at 1:20 AM, Mark Andrews wrote: > > > > 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. > > > > At the moment. There is no good reason to not be listening on > > standard ports if you want to provide your own servers within the > > home. DNS will almost certainly be done if only to as hidden > > masters. Just publish your current addresses in the DNS and they > > can be reached. Cable and DSL are always on services. Homes are > > no longer dialup. > > I disagree with the assertion that "Homes" are no longer on dial-up since a > good portion of Rural America still does not have Broadband which means > millions are still on Dial-Up and I hear parts of Europe still use Dial-Up. The argument being made was that homes don't have long lived connections and that isn't true anymore. The majority of homes are always on. This percentage will continue to increase. As of 2006[1] the majority of households in Australia had Internet connections and the majority of those were classed as broadband. The 2011 data isn't available yet but will be before the end of August. Even in the bush it isn't dialup, it's radio links of one form or another. Mark [1] http://www.censusdata.abs.gov.au/ABSNavigation/prenav/ViewData?action=404&documentproductno=0&documenttype=Details&order=1&tabname=Details&areacode=0&issue=2006&producttype=Census%20Tables&javascript=true&textversion=false&navmapdisplayed=true&breadcrumb=LPTD&&collection=Census&period=2006&productlabel=Type%20of%20Internet%20Connection%20by%20Number%20of%20Persons%20Usually%20Resident%20by%20Household%20Composition&producttype=Census%20Tables&method=Place%20of%20Usual%20Residence&topic=Dwellings& -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From brian.e.carpenter@gmail.com Wed Aug 8 05: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 05EB021F859A for ; Wed, 8 Aug 2012 05:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.483 X-Spam-Level: X-Spam-Status: No, score=-101.483 tagged_above=-999 required=5 tests=[AWL=0.208, 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 i9I+1GxUvaTJ for ; Wed, 8 Aug 2012 05:03:10 -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 4A2F021F8512 for ; Wed, 8 Aug 2012 05:03:10 -0700 (PDT) Received: by eekb45 with SMTP id b45so206426eek.31 for ; Wed, 08 Aug 2012 05:03:09 -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=6Mx/0AoyoDlR5PL6A6R1UdqQIWd3aIIfJv15MszebsA=; b=CfnKggTC3mSZcXMA+cjfUeiL+6qmlSjaCG1arqZjcXHEsJjJ144WWh/PB3pSHcZL4G u0if0XDDxkwVe1gSavatXCkInxj5R9bauSsTIzaEuunjJZgz9YcGhglCcZqugPMKz7rs 4PAZnBK5l04UVSgQIlgqgzP0idFwpLXjKwEpfzcqjWnPvpTN6ehw5ZCd0mRBOdgqeGiP VAVHs+J24fUc1XGPceXfUPASM0BEFcCfd4DSGdJss6RGMjFrHEhLMue8V4TjlVpwwG3i GQBGeJuB1q167HkJQ4AfAQoo9JLILHpdl2YSafJ9WtiY3/nbrLy4hxFz3txT14dv6riG xtcg== Received: by 10.14.181.132 with SMTP id l4mr22030831eem.17.1344427389518; Wed, 08 Aug 2012 05:03:09 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-169.as13285.net. [2.102.217.169]) by mx.google.com with ESMTPS id 45sm17117781eed.17.2012.08.08.05.03.06 (version=SSLv3 cipher=OTHER); Wed, 08 Aug 2012 05:03:08 -0700 (PDT) Message-ID: <5022557F.5050105@gmail.com> Date: Wed, 08 Aug 2012 13:03:11 +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: <201208010448.q714m8KI091107@gateway.ipv6.occnc.com> <20120806020656.GA88914@isc.org> <20120806182509.GA99606@isc.org> <29040.1344285229@obiwan.sandelman.ca> <20120807013902.GD99606@isc.org> <5021686C.60308@mtcc.com> In-Reply-To: <5021686C.60308@mtcc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Evan Hunt , Michael Richardson , Kerry Lynn , "homenet@ietf.org Group" Subject: Re: [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, 08 Aug 2012 12:03:11 -0000 On 07/08/2012 20:11, Michael Thomas wrote: > On 08/07/2012 11:46 AM, Kerry Lynn wrote: >> On Mon, Aug 6, 2012 at 9:39 PM, Evan Hunt wrote: >>> >>> Tunnels are okay, but to use them, but has to get the DNS search order >>> and the DNS server list right, and that's walled garden territory. >>> *If* we are going to turn each home into a walled garden, then let's be >>> aware that we are doing that. >> I'm of the opinion that in a "walled garden" scenario, the tunnel >> endpoint may >> be the only resource that needs a global name / address. > > Just checking, but we all think that naming is a separate issue > from reachability, right? It certainly is. But see http://tools.ietf.org/html/draft-carpenter-referral-ps especially section 4.2 "FQDNs are not sufficient". Brian From daveoran@orandom.net Wed Aug 8 05:32: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 6861421F8608 for ; Wed, 8 Aug 2012 05:32:14 -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 pOC8of7gwUbk for ; Wed, 8 Aug 2012 05:32:09 -0700 (PDT) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2001:470:d:21b:3c00::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A55D21F85F7 for ; Wed, 8 Aug 2012 05:32:09 -0700 (PDT) Received: from sjc-vpnasa1-41.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by spark.crystalorb.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id q78CW7jJ032178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Aug 2012 05:32:08 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: David R Oran In-Reply-To: <50200D3A.5070308@mtcc.com> Date: Wed, 8 Aug 2012 08:32:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9DB6BCFF-0603-415F-98D2-873643F59F15@orandom.net> References: <50200D3A.5070308@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1485) Cc: "" Subject: Re: [homenet] naming, what's the problem? 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, 08 Aug 2012 12:32:14 -0000 On Aug 6, 2012, at 2:30 PM, Michael Thomas wrote: > I've been rereading the charter and the -arch document and they both > seem to make a presumption that we actually know what the problems > are in a homenet. At the very least, I'm not convinced that we've = captured > what those problems are. The charter seems to say that we have some > tools (dns, zeroconf...) that we should be able to tweak. The -arch = document > seems to be very "device" oriented -- as in from the dns-sd = perspective, > where my printer is the canonical example. I think there's more to = this. >=20 > Maybe an example is in order. I have a weather station: >=20 > http://mtcc.com/~mike/sanchez.php >=20 > This is not a service to be discovered like a printer, Why not? > though I might want > to discover it were I to get an off-the-shelf IP enabled version from, = say, > oregon scientific. Isn't that the kind of thing we're talking about? If your weather = station doesn't do IP, then perhaps it's simply out of scope. > It's much more like a web site. I want to be able to see > it not only at home, but when I'm away so that I can see whether my > Pioneer house has snow in the driveway. >=20 Sure.=20 > I've done this using v4, but I'm a geek. What I think we want to = enable is > non-geeks to be able to install these kinds of devices in a v6 world > with some minimum muss and fuss. That is, we need to account for not > just services, but *servers* in the form of traditional web-headed = servers. > That is, the normal browser-centric view of the world. >=20 Right, which is why I can bookmark things like OranHomeNas1.local, and = my browser does mDNS lookups and finds it just fine. > That browser-centric view of the world knows nothing about .local. What browser are you using? Safari and I think Chrome know about .local = just fine. > Nor > do I want to learn about .local either. I want to have a real name = that I > can use as a real URL to send -- as I just did -- to people that might = want > to see my weather station. And I want -- literally -- for my mother to = be > able to do the same. It is beyond her now. >=20 For that you definitely need a global DNS domain registration, so we've = cycled back to where we started - things you want to be accessed = globally from anywhere on the internet need global names that can be = resolved from anywhere on the internet. > So there's one problem. >=20 Yes, and a fairly hard one given the manual/administrative nature of = domain registrations and the geek factor of secure dynamic DNS updates = for all services to the global DNS. Much as it would be great for = Homenet to solve this problem and get a lot more functionality for = users, this may be a bridge too far for the current work, which is = focused on getting routing and naming INSIDE the home seamless and = completely auto-configuring. I think the problem of disambiguating names of resources in the home has = to be dealt with to prevent users whose devices are mobile from = violating the principle of least astonishment. I don't think the ability = to resolve names of home resources from anywhere on the Internet has to = be solved in order to solve the disambiguation problem. > Mike > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From ajs@anvilwalrusden.com Wed Aug 8 06:35: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 D3E2C21F8585 for ; Wed, 8 Aug 2012 06:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.182 X-Spam-Level: X-Spam-Status: No, score=-1.182 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 OoFAa-hseYVo for ; Wed, 8 Aug 2012 06:35:44 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id D55CA21F8596 for ; Wed, 8 Aug 2012 06:35:43 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 28C6E8A031 for ; Wed, 8 Aug 2012 13:35:41 +0000 (UTC) Date: Wed, 8 Aug 2012 09:35:33 -0400 From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20120808133532.GB77082@mail.yitter.info> References: <50200D3A.5070308@mtcc.com> <9DB6BCFF-0603-415F-98D2-873643F59F15@orandom.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9DB6BCFF-0603-415F-98D2-873643F59F15@orandom.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [homenet] naming, what's the problem? 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, 08 Aug 2012 13:35:45 -0000 On Wed, Aug 08, 2012 at 08:32:01AM -0400, David R Oran wrote: > Yes, and a fairly hard one given the manual/administrative nature of > domain registrations and the geek factor of secure dynamic DNS > updates for all services to the global DNS. What is this "geek factor" whereof you speak? Once you have a name registered, registered your service with a service like dyn.com's DynDNS service, and told your gateway about it, everything else Just Works. I know this mostly because I know people who don't know anything about what they are doing, but who are able to navigate this far. What probably is true is at least the following: 1. Many people don't want to pay for (thereby use) their own name, and don't want to pay extra for a service like this. Dyn and (I believe) some of its competitors have free services of this sort, but they're somewhat restricted in what they can do. (Still, you can do this today when you buy shipping product from some vendors, without doing a single extra thing.) 2. Registering DNS names and somehow hooking them up to edge systems remains hard. DNSOP is actually investigating this problem, but maybe this WG ought to collaborate on that. 3. Split-horizon DNS isn't that reliable, and tends to leak. 4. Trying to make this work smoothly with .local addresses is probably a good way to cause confusion For what it's worth, after the discussion in Vancouver I went back to colleagues at Dyn to ask about previous work on standardizing what I might call the CPE-to-DNS-provider link, as I was pretty sure there'd been previous work. Indeed there had, and I'm attempting to dust it off. If we're serious about systems inside our target networks being somehow addressable from the global Internet, then it seems to me a mechanism to integrate easily to the global DNS without requiring major lock-in (or major upgrade of DHCP) is going to be something we'll have to tackle. > Much as it would be great for Homenet to solve this problem and get > a lot more functionality for users, this may be a bridge too far for > the current work, which is focused on getting routing and naming > INSIDE the home seamless and completely auto-configuring. If, on the other hand, we are in fact going to limit our scope to inside the home network (and what problem is it, exactly, that we have? My network can already do this, I think?) then of course the above is just needless extra work. > I think the problem of disambiguating names of resources in the home > has to be dealt with to prevent users whose devices are mobile from > violating the principle of least astonishment. I don't think the > ability to resolve names of home resources from anywhere on the > Internet has to be solved in order to solve the disambiguation > problem. I think that's a little optimistic. As soon as you have the problem, "The name in context X is the same as in context Y and I want to be able to tell the difference when I cross context," you are already in Internet land. That's an interoperation problem, at least from the user's point of view. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Wed Aug 8 07:09: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 3840021F85BB for ; Wed, 8 Aug 2012 07:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.178 X-Spam-Level: X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 Qfinz7QNFo7e for ; Wed, 8 Aug 2012 07:09:39 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9344221F8592 for ; Wed, 8 Aug 2012 07:09:39 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id E0FDC8A031 for ; Wed, 8 Aug 2012 14:09:37 +0000 (UTC) Date: Wed, 8 Aug 2012 10:09:36 -0400 From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20120808140935.GC77082@mail.yitter.info> References: <20120806020656.GA88914@isc.org> <20120806182509.GA99606@isc.org> <29040.1344285229@obiwan.sandelman.ca> <20120807013902.GD99606@isc.org> <5021686C.60308@mtcc.com> <5022557F.5050105@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5022557F.5050105@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [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, 08 Aug 2012 14:09:40 -0000 On Wed, Aug 08, 2012 at 01:03:11PM +0100, Brian E Carpenter wrote: > It certainly is. But see http://tools.ietf.org/html/draft-carpenter-referral-ps > especially section 4.2 "FQDNs are not sufficient". I thought one of the things we were trying to do was to address exactly the failure modes in that section of the I-D? Perhaps I'm being naive, but I've been working from the assumption that, if you want to talk to something on the Internet, you need an unambiguous way to identify it. Historically, the best we've had for that has been the DNS, because it provides a layer of indirection so that you can have stable identifiers in the face of changing IP addresses. Given the way the relevant markets have gone, it turns out that DNS names are rather harder to administer and use for ordinary end users than we might like. But there's no reason that has to persist, and it seems to me that if we're going to solve the problems people have using homenet-type resources on the global Internet, then solving the DNS piece in a user-friendly way is going to yield greater benefit than alternatives like ginning up some trick to make mDNS names sometimes work outside their natural context. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From curtis@occnc.com Wed Aug 8 08:04: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 4D6BA21F867F for ; Wed, 8 Aug 2012 08:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.134, 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 vjiuDmn1KgE4 for ; Wed, 8 Aug 2012 08:04:54 -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 2CE4F21F84A1 for ; Wed, 8 Aug 2012 08:04: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 q78F4LaV028658; Wed, 8 Aug 2012 11:04:21 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208081504.q78F4LaV028658@gateway.ipv6.occnc.com> To: Brian E Carpenter From: Curtis Villamizar In-reply-to: Your message of "Tue, 07 Aug 2012 19:09:10 BST." <502159C6.6060109@gmail.com> Date: Wed, 08 Aug 2012 11:04:21 -0400 Cc: Michael Richardson , homenet@ietf.org, curtis@occnc.com 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, 08 Aug 2012 15:04:55 -0000 In message <502159C6.6060109@gmail.com> Brian E Carpenter writes: > On 07/08/2012 16:39, Curtis Villamizar wrote: > > In message <501A502D.30408@gmail.com> > > Brian E Carpenter writes: > > > >> On 01/08/2012 15:39, Curtis Villamizar wrote: > >>> In message <5018DD8A.2070900@gmail.com> > >>> Brian E Carpenter writes: > >>> > >>>> Excuse front posting, but... > >>>> > >>>>> Today there is no DHCP help in avoiding the "please reboot" messages. > >>>> > >>>> Don't RECONFIGURE (DHCPv6) and FORCERENEW (DHCP) cover this, in theory? > >>>> They are unicast, which is a scaling issue in enterprise networks but > >>>> presumably not in homenets. > >>>> > >>>> Regards > >>>> Brian > >>> > >>> These only force a renew before the lease expires. For the sometimes > >>> very long IPv6 leases, this is essential. For often relatively > >>> shorter IPv4 leases, it is nice but not quite as essential. > >>> > >>> The issue is not forcing the renew to occur earlier, it is the way in > >>> which a renew that changes the address is handled. Maybe its just > >>> implementations taking a shortcut, but I think in practice changing > >>> the IP address takes the interface down, kills all connections, > >>> including listens, and then brings it back up with a new address. > >> > >> Really? I can't test it in my current native-IPv6-deprived state, but > >> it seems to me that Windows (at least) runs happily with multiple IPv6 > >> addresses on one interface, and I can't imagine that changing one of them > >> will kill the others. I have to admit I haven't studied the semantics > >> of RECONFIGURE closely, though. > >> > >> The RFC 4192 model would look a bit sick if the interfaces get reset. > >> > >> Brian > > > > Brian, > > > > Aliases (more than one address on the same interface) > > Aliases, as you describe them, sound like a hack. I'd like to > hear from Microsoft (for example) whether their support of multiple > IPv6 addresses per interface is a hack or genuine. I don't care > about IPv4, but the IPv6 model is very clear. You can't read the > ND spec and imagine the arrival of a new address resetting sessions > that use other addresses. > > Brian Brian, An alias is a second (or third or fourth) address bound to an interface. The name alias comes from the 2+ decades old "ifconfig ... alias" syntax. Every dual stack host uses aliases - it has an IPv4 address and more than one IPv6 address. This is also true of an IPv6 only interface with interface local, ULA, and GUA addresses. Every router with a GUA on the loopback (most likely every one deployed in a major provider) has a ::1 and the GUA as an alias on the loopback. Cisco added a loopback over 15 years ago just to support this. The purpose is to have a routable address that remains regardless of which forwarding cards fail or get pulled out. In modern implementations, once an alias is installed, it is no different from the original address. You can remove the original and keep the alias, which at one point you couldn't do. That is the most significant change to aliases in decades and has also been around a very long time. Aliases are critical to renumbering so that a transition period can exist while the renumbering process is in progress with no disruption at all to hosts as they are renumbered. > > has worked on > > every OS for a decade at least. Aliases have been around in BSD for more than two decades and existed before Microsoft had an IP stack in their product and before Linux existed. I would hope that by now *even Microsoft* has got it right. Curtis > > The issue is more what occurs when a lease is withdrawn (force to > > renew and won't renew) and another lease is provided with a different > > address. AFAIK most implementations take that interface down and > > bring it back up. > > > > They do not keep the old address as an alias for some period of time > > but put new connections on the new address. > > > > Curtis > > > > > >> Its > >>> a bit like a reboot as implemented, except the user doesn't know its > >>> coming and therefore may have open TCP connections that break. BTW - "It" in this context is the existing delete old address, then add new address behavior of DHCP. > >>> What I've suggested is what to do on a renew that changes the address. > >>> Add an alias. Until the old address has no more connections or > >>> listens on the old address, keep the old address. Then remove the old > >>> address. > >>> > >>> If someone has an open connection, ssh for example, the old address > >>> could be in use indefinitely, but if the transition is weeks, then its > >>> unlikely to go beyond that. For example, if someone was using ssh to > >>> do a long compile on another machine, breaking the connection and > >>> killing the compile would be bad. There are certain to be plenty of > >>> other uses of long duration TCP connections that would have to be > >>> broken in this sort of transition, unless we can also extend TCP to > >>> negotiate a change to one side of the address pair. > >>> > >>> Curtis From brian.e.carpenter@gmail.com Wed Aug 8 08:12: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 BCB7A11E80E1 for ; Wed, 8 Aug 2012 08:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.487 X-Spam-Level: X-Spam-Status: No, score=-101.487 tagged_above=-999 required=5 tests=[AWL=0.204, 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 NMuEwX6BBwxJ for ; Wed, 8 Aug 2012 08:12:08 -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 EB9D611E80C5 for ; Wed, 8 Aug 2012 08:12:07 -0700 (PDT) Received: by eaai11 with SMTP id i11so278288eaa.31 for ; Wed, 08 Aug 2012 08:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0ehEQ82cIwHzMOosx0Myjd3XcySE4POq/ePIRGIJVLs=; b=c8yihqkGsaD1/5klbg4CSPeK+igHgGuXG7rqq6ICW08aHG+DbdZMIA8wqBxruDlJyh lGymdzgQzbHa3iC/hxElA6RtG86SLT2pDLOWELIziXCCnKEXOdDPw9GO9oK/sl15E/Lp oQqfxl9WnI4Awn4OzVGozdtC8Bqz0AQThmulQFl/mnkkd7A+u7NqBSzFS8w6owjL65qU V3DaJ0yUQ9ggiN82wYaNVH7H5wsnbXoq6GO4jz20oBVaFzhd6/f+CwJyu8atO24RkIKr +TrYkhbA6ltvJeTYfVGeDs1gQJ+uSyVnnClbt4suiEq4oWJj8t47gRgnHueZljey5T4n Szvw== Received: by 10.14.215.197 with SMTP id e45mr22582445eep.36.1344438727130; Wed, 08 Aug 2012 08:12:07 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-169.as13285.net. [2.102.217.169]) by mx.google.com with ESMTPS id q3sm62225211eeo.4.2012.08.08.08.12.05 (version=SSLv3 cipher=OTHER); Wed, 08 Aug 2012 08:12:06 -0700 (PDT) Message-ID: <502281CA.4070803@gmail.com> Date: Wed, 08 Aug 2012 16:12:10 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew Sullivan References: <20120806020656.GA88914@isc.org> <20120806182509.GA99606@isc.org> <29040.1344285229@obiwan.sandelman.ca> <20120807013902.GD99606@isc.org> <5021686C.60308@mtcc.com> <5022557F.5050105@gmail.com> <20120808140935.GC77082@mail.yitter.info> In-Reply-To: <20120808140935.GC77082@mail.yitter.info> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [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, 08 Aug 2012 15:12:09 -0000 On 08/08/2012 15:09, Andrew Sullivan wrote: > On Wed, Aug 08, 2012 at 01:03:11PM +0100, Brian E Carpenter wrote: >> It certainly is. But see http://tools.ietf.org/html/draft-carpenter-referral-ps >> especially section 4.2 "FQDNs are not sufficient". > > I thought one of the things we were trying to do was to address > exactly the failure modes in that section of the I-D? Yes, I guess that's right. I hadn't looked at it that way. > Perhaps I'm being naive, but I've been working from the assumption > that, if you want to talk to something on the Internet, you need an > unambiguous way to identify it. Historically, the best we've had for > that has been the DNS, because it provides a layer of indirection so > that you can have stable identifiers in the face of changing IP > addresses. What's actually happened (IMHO) is that people trying to solve the reference problem have come up with additional ID spaces to solve their particular problem - often hanging them off a trouble-free FQDN to get the top level of uniqueness for free. But then they have to invent things like STUN, ICE or supernodes to get connectivity to those IDs. > Given the way the relevant markets have gone, it turns out that DNS > names are rather harder to administer and use for ordinary end users > than we might like. But there's no reason that has to persist, and it > seems to me that if we're going to solve the problems people have > using homenet-type resources on the global Internet, then solving the > DNS piece in a user-friendly way is going to yield greater benefit > than alternatives like ginning up some trick to make mDNS names > sometimes work outside their natural context. I'm inclined to agree. If we phrase it in terms of specifically eliminating the problems in my draft, I'll even be happy about it ;-). Brian > > Best, > > A > From curtis@occnc.com Wed Aug 8 08:20: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 6016F11E80F7 for ; Wed, 8 Aug 2012 08:20:05 -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.130, 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 hGxq3Vmkir15 for ; Wed, 8 Aug 2012 08:20:04 -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 8B7BB11E80F3 for ; Wed, 8 Aug 2012 08:20:04 -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 q78FJZtp028789; Wed, 8 Aug 2012 11:19:35 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208081519.q78FJZtp028789@gateway.ipv6.occnc.com> To: Brian E Carpenter From: Curtis Villamizar In-reply-to: Your message of "Tue, 07 Aug 2012 19:11:14 BST." <50215A42.5010200@gmail.com> Date: Wed, 08 Aug 2012 11:19:35 -0400 Cc: homenet@ietf.org, Mikael Abrahamsson , 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: Wed, 08 Aug 2012 15:20:05 -0000 In message <50215A42.5010200@gmail.com> Brian E Carpenter writes: > On 07/08/2012 16:48, Curtis Villamizar wrote: > > In message <501A568C.9040606@gmail.com> > > Brian E Carpenter writes: > > > >> On 02/08/2012 06:58, Mikael Abrahamsson wrote: > >>> On Wed, 1 Aug 2012, Curtis Villamizar wrote: > >>> > >>>> Same answer as one given on that thread. If a device can support > >>>> IPv4, then use NAT4. If a device can only support IPv6, then the > >>>> DNS64 belongs on the IPv6-only device. To that device all host return > >>> Am I interpreting you correctly in that you're saying that an IPv6 only > >>> device should have a built in resolver that does DNS64 in case of v6 > >>> only connectivity? > >>> > >>> I can see that this would work, but is that a generally accepted > >>> solution? On Android, this would mean that dnsmasq would need to gain > >>> DNS64 functionality (and also needs to be able to detect the NAT64 > >>> prefix somehow). > >> > >> That is one of the models discussed in BEHAVE, of course, and it deals > >> neatly with the DNSSEC conundrum for DNS64. But the normal model is > >> the one that Curtis doesn't like. NAT64/DNS64 plays better when > >> the client network is truly IPv6-only; with mixed hosts, you really need > >> to provision dual stack hosts with a normal DNS server, and the IPv6-only > >> hosts with a DNS64. > >> > >> Brian > > > > > > Brian, > > > > What you suggest might be accomplished by having DHCP4 return a > > different nameserver than DHCP6. At the very least the same > > nameserver (same copy of bind or whatever on a DS machine) could > > respond differently if the private side query arrives via IPv4 than if > > it arrives via IPv6. Worst case is DS machines make use of NAT64 when > > they could have used IPv4. > > Right, but that is something that people in BEHAVE thought was the worst > thing since unsliced bread. > > Brian Brian, NAT4 or NAT64 are both stateful with state per connection. Things with state per connection don't scale well. But we may be stuck due to the continued use of IPv4 and the depletion of IPv4 addresses. We have already reached a point where providers are running NAT4 to reduce the use of addresses in their infrastructure. When the CPE also runs NAT4 some things break. If the providers run native IPv6 only and do NAT64 rather than DS and NAT4 it might be no worse for the provider and reduce the number of NATs before reaching a globally routable address down to one. For that reason I thing BEHAVE is correct in thinking that DNS64 and NAT64 at a gateway is a better choice. OTOH - For the home network today, there are still IPv4 only devices. For example, I look at my home and see a TV streaming device that make no pretense of understanding IPv6, a SIP phone base station that has minimally functioning IPv6 but can't function without IPv4, and a bunch of computers (which run FreeBSD and are happy being DS). Haven't checked the fridge. I'm not a gadget guy. As long as many customers, probably the vast majority, have one or more IPv4 only devices, it is infeasible for a provider to deploy NAT64, DNS64 and offer IPv6 only. BEHAVE preference or not, it won't work today. Maybe in a decade but we don't have that much time. Curtis > > [aside: Bind has views, but I don't know if the view support would > > allow this. It seems like it would. It would be nice if this were > > doable today with no changes. ie: existance proof] > > > > Curtis From curtis@occnc.com Wed Aug 8 08:23: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 C90B711E80F1 for ; Wed, 8 Aug 2012 08:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.174 X-Spam-Level: X-Spam-Status: No, score=-0.174 tagged_above=-999 required=5 tests=[AWL=-2.174, BAYES_00=-2.599, MANGLED_CNFDTL=2.3, MANGLED_HERE=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 jtc7S-QXOEOh for ; Wed, 8 Aug 2012 08:23: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 A4F5521F86A7 for ; Wed, 8 Aug 2012 08:23: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 q78FN2m5028879; Wed, 8 Aug 2012 11:23:03 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208081523.q78FN2m5028879@gateway.ipv6.occnc.com> To: Benjamin Kerensa From: Curtis Villamizar In-reply-to: Your message of "Tue, 07 Aug 2012 11:20:05 PDT." Date: Wed, 08 Aug 2012 11:23:02 -0400 Cc: Michael Richardson , homenet@ietf.org, Mark Andrews , curtis@occnc.com 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, 08 Aug 2012 15:23:49 -0000 In message Benjamin Kerensa writes: > --e89a8f234cc38c7df504c6b10d5c > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, Aug 1, 2012 at 1:20 AM, Mark Andrews wrote: > > > > > In message <201208010333.q713XjUb089327@gateway.ipv6.occnc.com>, Curtis > > Villamizar writes: > > > > > > 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). > > > > Define short? There are plenty of homes with equipment that isn't > > powered down every day and that has been up for months. > > > > I don't know about other but I maintain ssh connections for weeks > > from home to the main office at work. > > > > > 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. > > > > What's the dhcp stuff in the home? RA's work fine here. What is > > needed is a way to signal in the DNS to only use a deprecated address > > as a last resort measure. Named to address and address to name > > mappings need to exist until after the address has ceased being > > used. > > > > > 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". > > > > Actually you should be asking the OS vendors / distro maintainers > > to do this and send fixes to ISC. This is all done in shell scripts > > that are highly customised to the client platform. There isn't one > > linux script that works for all linux distros. > > > > Unfortunately this is true and this hopefully in the future will be more > standardized. Can someone, maybe someone from ISC, suggest an OS vendor neutral mailing list where this thread can be continued. I've done a little preliminary poking into code, both BSD kernel code and ISC DHCP and would be willing to help. Curtis > > This also doesn't work for many udp based services. > > > > > 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. > > > > At the moment. There is no good reason to not be listening on > > standard ports if you want to provide your own servers within the > > home. DNS will almost certainly be done if only to as hidden > > masters. Just publish your current addresses in the DNS and they > > can be reached. Cable and DSL are always on services. Homes are > > no longer dialup. > > > > I disagree with the assertion that "Homes" are no longer on dial-up since a > good portion of Rural America still does not have Broadband which means > millions are still on Dial-Up and I hear parts of Europe still use Dial-Up. > > > > > > 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. > > > _______________________________________________ > > > 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 > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > > > > > -- > Benjamin Kerensa > *Team Lead, *Ubuntu Oregon > http://ubuntu-oregon.org > Phone: 503-894-6005 x701 > > > > > > > *This message may contain information which is privileged or confidential. > If you are not the named addressee of this message please destroy it > without reading, using, copying or disclosing its contents to any other > person.* > * > * > > --e89a8f234cc38c7df504c6b10d5c > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > >

On Wed, Aug 1, 2012 at 1:20 AM, Mark And= > rews < k">marka@isc.org> wrote:
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > >

> In message < ccnc.com">201208010333.q713XjUb089327@gateway.ipv6.occnc.com>, Curti= > s Villamizar writes:
> >
> > In message <50181A1C.= > 5050803@gmail.com>
> > Brian E Carpenter writes:
> >
> > > On 31/07/2012 17:59, Michael Richardson wrote:
> > > >>>>>> "Brian" =3D=3D Brian E Carpent= > er <Brian> writes:
> > > > =A0 =A0 >> I'm also surprised that we think we hav= > e to cope with flash renumbering
> > > > =A0 =A0 >> as a regular event, rather than a service-i= > nterrupting, ISP truck roll
> > > > =A0 =A0 >> catastrophy.
> > > >
> > > > =A0 =A0 Brian> But every time you reboot your antiquated = > v4-only CPE
> > > > =A0 =A0 Brian> and/or the antiquated
> > > > =A0 =A0 Brian> v4-only PCs behind it, the PCs all get new= > IP addresses,
> > > > =A0 =A0 Brian> which may or
> > > > =A0 =A0 Brian> may not be the same as the previous time. = > There's nothing
> > > > =A0 =A0 Brian> new in flash
> > > > =A0 =A0 Brian> renumbering for homenets. Not handling thi= > s would be a step
> > > > =A0 =A0 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
> > > > =A0 =A0previous IP, it usually gets honored.
> > >
> > > It doesn't matter whether it's the user or the ISP that t= > riggers a
> > > change, does it?
> > >
> > > The point is, users don't care about this, except if they rea= > ch their
> > > shiny new wireless printer via its IP static address. There are r> > > > definitely parts of draft-ietf-6renum-static-problem that apply h= > ere.
> > >
> > > =A0 =A0Brian
> >
> >
> > Brian,
> >
> > Enterprise renumbering and homenet renumbering are generally quite
> > different. =A0Most homehets have short uptimes. =A0Most enterprises ha= > ve
> > very long uptimes. =A0(insert favorite Microsoft reliability joke here= > ).
>
>
Define short? =A0There are plenty of homes with equipment that = > isn't
> powered down every day and that has been up for months.
>
> I don't know about other but I maintain ssh connections for weeks
> from home to the main office at work.
>

> > If a renumbering is done right, there is an time when both the old and= >
> > new numbers are in use. =A0As in "ifconfig <intf> inet6 new= > addr
> > ... alias" in the *ix world. =A0During that transition time any u= > se of
> > DHCP will hand out the new address. =A0Then comes a time when the leas= > es
> > refuse to be renewed. =A0Then the old addresses go away. =A0This can b= > e
> > day, weeks, or longer depending on the size of the transition. =A0Duri= > ng
> > that time a lot of "please reboot at least once ..." message= > s get
> > sent.
>
>
What's the dhcp stuff in the home? =A0RA's work fine here. = > =A0What is
> needed is a way to signal in the DNS to only use a deprecated address
> as a last resort measure. =A0Named to address and address to name
> mappings need to exist until after the address has ceased being
> used.
>

> > 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:
> >
> > =A0 1. =A0Add the new address using an "ifconfig <intf> ...= > alias"
> > =A0 =A0 =A0 equivalent.
> >
> > =A0 2. =A0Check (using netstat -an equivalent) for use of the old addr= > ess.
> > =A0 =A0 =A0 Don't delete the old address if a socket still exists.= >
> >
> > =A0 3. =A0Periodically repeat step 2 until there is no connection usin= > g
> > =A0 =A0 =A0 the old address.
> >
> > =A0 4. =A0Delete the old address using the equivalent of "ifconfi= > g <intf>
> > =A0 =A0 =A0 ... -alias".
>
>
Actually you should be asking the OS vendors / distro maintainers
> to do this and send fixes to ISC. =A0This is all done in shell scripts
> that are highly customised to the client platform. =A0There isn't one r> > linux script that works for all linux distros.

iv>
Unfortunately this is true and this hopefully in the future will be= > more standardized.
=A0
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > > >
> This also doesn't work for many udp based services.
>

> > This would work for all client side connects that either were done
> > before the end of the transition period. =A0For home nets this covers<= > br> > > 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. =A0This is rare among home nets (except for homes of reade= > rs
> > of IETF lists) but very common among enterprises.
>
>
At the moment. =A0There is no good reason to not be listening on
> standard ports if you want to provide your own servers within the
> home. =A0DNS will almost certainly be done if only to as hidden
> masters. =A0Just publish your current addresses in the DNS and they
> can be reached. =A0Cable and DSL are always on services. =A0Homes are
> no longer dialup.

I disagree with the a= > ssertion that "Homes" are no longer on dial-up since a good porti= > on of Rural America still does not have Broadband which means millions are = > still on Dial-Up and I hear parts of Europe still use Dial-Up.=A0
> >
x #ccc solid;padding-left:1ex"> >

> > Many points made about license servers, etc in
> > draft-ietf-6renum-static-problem don't apply to home nets.
> >
> > Renumbering an enterprise is doable. =A0Renumbering my home net has be= > en
> > quite easy. =A0I've done it a few times already and I'm sure w= > ill have
> > to again. =A0The procedure suggested above is just done manually.
> >
> > One hint is that on BSD and Linux at least a "netstat -an" s= > hould
> > reveal any listens on old addresses. =A0An automated scan on an
> > enterprise network can identify servers and services needing a
> > reconfig and a service restart without any system reboot. =A0[ Microso= > ft
> > systems may need to reboot or power down and remove the CMOS battery r> > > from the motherboard or maybe buy new hardware. =A0:-) ]
> >
> > > >
> > > > In IPv6 space, the host part will generally stay the same (m= > odulo
> > > > privacy extensions, which are default on for some clients). = > =A0We've said
> > > > that the ULA ought to stay the same, so in fact, I agree, th= > e internal
> > > > addresses actually all stay the same.
> > > >
> > > > I'm still surprised that an ISP will need to flash renum= > ber faster than
> > > > it can just expire leases. =A0If it's just repartitionin= > g of network to
> > > > deal with growth, that ought to be predictable and prefix li= > fetimes can
> > > > be reduced in advance.
> > > >
> > > > If it's actually some equipment failing, resulting in se= > rvice
> > > > interruptions, and then restoration by rewiring the network.= > .. then I
> > > > understand.
> > _______________________________________________
> > homenet mailing list
> > homenet@ietf.org
> > lank">https://www.ietf.org/mailman/listinfo/homenet
>
--
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2= > 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@isc.org">marka@isc.org
>
_____________________= > __________________________
> homenet mailing list
> homenet@ietf.org
> >https://www.ietf.org/mailman/listinfo/homenet
>



--
= > ">
y:helvetica;font-size:14px"> > > Benjamin Kerensa
ms', sans-serif">Team Lead, Ubuntu Oregon
face=3D"'comic sans ms', sans-serif"> on.org" target=3D"_blank">http://ubuntu-oregon.org
> >
Phone:=A0 ign:left;background-color:rgb(255,255,255)">503-894-6005 x e=3D"font-family:Arial,Helvetica,sans-serif;font-size:11px;text-align:left;= > background-color:rgb(255,255,255)">701
> > > >
=A0 =A0 =A0 =A0 =A0 =A0 =A0=A0
;font-family:verdana,arial,'times new roman',sans,serif;font-size:1= > 0px">This message may contain information which is privileged or confide= > ntial.
If you are not the named addressee of this message please destroy= > it without reading, using, copying or disclosing its contents to any other= > person.
> >
s new roman',sans,serif;font-size:10px">

> > --e89a8f234cc38c7df504c6b10d5c-- From mike@mtcc.com Wed Aug 8 08:29: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 0AC3111E80F2 for ; Wed, 8 Aug 2012 08:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, SARE_BIZOP=0.7] 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 uXI+EAJESJgS for ; Wed, 8 Aug 2012 08:29: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 095A011E80ED for ; Wed, 8 Aug 2012 08:29:01 -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 q78FT0q9013765 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 8 Aug 2012 08:29:01 -0700 Message-ID: <502285BC.2000609@mtcc.com> Date: Wed, 08 Aug 2012 08:29:00 -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: David R Oran References: <50200D3A.5070308@mtcc.com> <9DB6BCFF-0603-415F-98D2-873643F59F15@orandom.net> In-Reply-To: <9DB6BCFF-0603-415F-98D2-873643F59F15@orandom.net> 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=2662; t=1344439741; x=1345303741; 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]=20naming,=20what's=20the=20pr oblem? |Sender:=20 |To:=20David=20R=20Oran=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=K8y2H6MUkwSPhi9AFNY7By4HhP3ppqKP7+2FVlxOP70=; b=XN925mPApbI+vlO6fTIvqbjDDPL1tHrM2Mld5Cvu/KVS9m26ogdJ1wYzk+ QDFmoGNa3HU8GXEFVNQax0wmZrpZhwFxOX0/zTm+guvQ4LjfZ7pN0EC0EMTQ I4VWXIxCNPh30rF3nO74mMVqcKOKaYR5VzF34lKNoEXRvWBuHp8YM=; 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: "" Subject: Re: [homenet] naming, what's the problem? 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, 08 Aug 2012 15:29:03 -0000 On 8/8/12 5:32 AM, David R Oran wrote: >> That browser-centric view of the world knows nothing about .local. > What browser are you using? Safari and I think Chrome know about .local just fine. I'm talking about people, not technology. People know nothing of this, and would be confused that they need to type in weatherstation.local, and doubly more confused by why it doesn't work once they leave the house. It just doesn't map to the way people view naming anymore. >> Nor >> do I want to learn about .local either. I want to have a real name that I >> can use as a real URL to send -- as I just did -- to people that might want >> to see my weather station. And I want -- literally -- for my mother to be >> able to do the same. It is beyond her now. >> > For that you definitely need a global DNS domain registration, so we've cycled back to where we started - things you want to be accessed globally from anywhere on the internet need global names that can be resolved from anywhere on the internet. The global namespace is what people have been taught in the last 20 years and almost nobody remembers NBP. I think that it is an important requirement that we do not mess with people's mental model of what we've forced upon them which is the global DNS. .[site]local fails on that account. When I type an address (or better, search) in a location bar, I want it to seem like it's an fqdn even if it's walled off from the rest of the world -- people understand firewalls to a degree -- and perhaps even if it's a locally synthesized fqdn (ie, camping on a name that I don't have registered). I don't want to think about the antiquated notion of filtering by categories that I didn't create and probably make no sense to me whatsoever as there becomes a vast array of internet-enabled widgets in the house. >> So there's one problem. >> > Yes, and a fairly hard one given the manual/administrative nature of domain registrations and the geek factor of secure dynamic DNS updates for all services to the global There's much that could be done to make this seamless, and probably many business opportunities given that. The main problem right now is that we don't have a very big internet that supports this feature. Once the v6 internet gets to a critical mass, there will be a land rush of purpose built widgets vying for their homenet acreage. I think it would be extremely short sighted to blow that off as "too hard" because it's not, and especially if we stop spending an inordinate amount of brain cycles trying to do unnatural acts with a naming mechanism that nobody even knows about. Mike From mellon@fugue.com Wed Aug 8 08:51: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 ECAC821F8690 for ; Wed, 8 Aug 2012 08:51:37 -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 vsh5Tr6hK4Dy for ; Wed, 8 Aug 2012 08:51:36 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id C191621F866D for ; Wed, 8 Aug 2012 08:51:36 -0700 (PDT) Received: from [10.1.10.11] (173-162-214-218-NewEngland.hfc.comcastbusiness.net [173.162.214.218]) by toccata.fugue.com (Postfix) with ESMTPSA id C8A5F23802B9; Wed, 8 Aug 2012 11:51:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_7056EDEF-B076-43EE-B1C3-D4419126435B" From: Ted Lemon In-Reply-To: <201208081523.q78FN2m5028879@gateway.ipv6.occnc.com> Date: Wed, 8 Aug 2012 11:51:32 -0400 Message-Id: References: <201208081523.q78FN2m5028879@gateway.ipv6.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1283) Cc: Benjamin Kerensa , Michael Richardson , homenet@ietf.org, Mark Andrews 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: Wed, 08 Aug 2012 15:51:38 -0000 --Apple-Mail=_7056EDEF-B076-43EE-B1C3-D4419126435B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 8, 2012, at 11:23 AM, Curtis Villamizar wrote: > Can someone, maybe someone from ISC, suggest an OS vendor neutral > mailing list where this thread can be continued. It's probably worth noting (and I say this as the author of the DHCPv4 = version) that the ISC DHCP client has somewhat fallen out of favor in = some circles, and there are other alternatives being used which may = behave differently (indeed, perhaps that is why the ISC version has = fallen out of favor). --Apple-Mail=_7056EDEF-B076-43EE-B1C3-D4419126435B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Can someone, = maybe someone from ISC, suggest an OS vendor neutral
mailing list = where this thread can be = continued.

It's probably worth noting = (and I say this as the author of the DHCPv4 version) that the ISC DHCP = client has somewhat fallen out of favor in some circles, and there are = other alternatives being used which may behave differently (indeed, = perhaps that is why the ISC version has fallen out of = favor).

= --Apple-Mail=_7056EDEF-B076-43EE-B1C3-D4419126435B-- From curtis@occnc.com Wed Aug 8 09:30: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 AAB8321F86F5 for ; Wed, 8 Aug 2012 09:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=0.185, 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 iDBjtNtEVzpU for ; Wed, 8 Aug 2012 09:30: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 1E1B321F86F0 for ; Wed, 8 Aug 2012 09:30: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 q78GTijg030367; Wed, 8 Aug 2012 12:29:45 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208081629.q78GTijg030367@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Tue, 07 Aug 2012 14:31:44 EDT." <9600.1344364304@obiwan.sandelman.ca> Date: Wed, 08 Aug 2012 12:29:44 -0400 Cc: homenet@ietf.org, curtis@occnc.com Subject: Re: [homenet] IPv6 aliases and renumbering (was Re: 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, 08 Aug 2012 16:30:15 -0000 In message <9600.1344364304@obiwan.sandelman.ca> Michael Richardson writes: > --=-=-= > Content-Transfer-Encoding: quoted-printable > > > >>>>> "Brian" =3D=3D Brian E Carpenter writes: > Brian> Aliases, as you describe them, sound like a hack. I'd like to > Brian> hear from Microsoft (for example) whether their support of > Brian> multiple IPv6 addresses per interface is a hack or genuine. I > Brian> don't care about IPv4, but the IPv6 model is very clear. You > Brian> can't read the ND spec and imagine the arrival of a new > Brian> address resetting sessions that use other addresses. > > On Linux and *BSD, (possibly including OSX, but I don't know, but I > could do an experiment with my officemate), new addresses get added > without an interface flap. > Old addresses expire as they expire, no interface flap need occur. > Linux does this all in the kernel, *BSD does it in rtsold. > I can't speak of what happens with dhcpv6. Thanks. I just took a look at rtsold and rtadvd. If Linux kernel has a similar function (wrong place to put this IMHO, but ...), then perhaps in both rtsold and the Linux kernel in addition to an interface down and up event, a suspend and resume event should trigger a router solicitation. BTW- In BSD neighbor discovery is in the kernel and router solicitation and router advertisement are in userland. Note that in rfc4862 (SLAAC) we have: 5.5.4. Address Lifetime Expiry A preferred address becomes deprecated when its preferred lifetime expires. A deprecated address SHOULD continue to be used as a source address in existing communications, but SHOULD NOT be used to initiate new communications if an alternate (non-deprecated) address of sufficient scope can easily be used instead. The RFC indicates that an old address should remain preferred. It might be better if a newer address was preferred slightly more and could serve as a tie breaker. > The choice of which one to use for new connections essentially depends > upon the metrics on the route to that destination. Typically, for > off-link destinations, it's the default route that matters. > > Where I think we see interface flaps is as a result of DHCPv4. > If we lose connectivity to the DHCPv4, then the dhclient-daemon will > reset the interface and start again. With wifi, this is often more > frequent. I have had IPv6 connections survive such events, but not > always. If you have a USB interface and pull it out, dhcpv4 is killed and does clean up and is restarted. In bsd the netif script is run with stop and start. Otherwise, if you just hop to another channel on the wireless, or unplug and plug the ethernet, the old address gets deleted (ifconfig ... -alias) and the new address added (ifconfig ... alias). > Michael Richardson , Sandelman Software Works=20 It would be nice if for both IPv4 and IPv6 hopping to another channel on the wireless did not break old connections and did the right thing with new ones. Routers have a solution to any interface going down, but that solution is to put a routable address on the loopback. That works fine because the provider can carry the IPv4 /32 or IPv6 /128 routes within its borders, adding only one host route for each router, well worth it for the reliability gain. Within an enterprise, roaming around a building is supported by bridging all the hubs together at layer-2. This won't work for a home user roaming outside the home and down the block to a WiFi hotspot (in my case about 3-4 miles, so I'd have to rely in a lot of neighbors with open wifi). This roaming across subnets case could be made workable using a GUA on the loopback and forcing a tunnel back to the home when roaming outside the home. This could also be a feature supported by a wireless carrier, retaining an address on the loopback given at the tower where the connection started until that address was no longer needed. It would be up to IETF (maybe homenet) to describe how this should work (as described above is a candidate) and then up to home devices to include support for it. Being able to road at will without ever losing connections would be a valuable feature. Curtis From curtis@occnc.com Wed Aug 8 10:09: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 D479121E804E for ; Wed, 8 Aug 2012 10:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.180, 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 MqwXjp2SeRui for ; Wed, 8 Aug 2012 10:09:10 -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 4168A21E8042 for ; Wed, 8 Aug 2012 10:09:10 -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 q78H901G031739; Wed, 8 Aug 2012 13:09:00 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208081709.q78H901G031739@gateway.ipv6.occnc.com> To: Kerry Lynn From: Curtis Villamizar In-reply-to: Your message of "Tue, 07 Aug 2012 14:46:39 EDT." Date: Wed, 08 Aug 2012 13:09:00 -0400 Cc: Evan Hunt , Michael Richardson , "homenet@ietf.org Group" Subject: Re: [homenet] LQDN (was" 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, 08 Aug 2012 17:09:11 -0000 Snipped most of this message. In message Kerry Lynn writes: > I like to see us reserve "FQDN" for host names that are registered in > the global DNS namespace, and use "LQDN" (or some other alternative) > for host names in locally served zones. Any support for this? > > -K- Yes this is a good suggestion. Examples: printer3 is unqualified. printer3.local. in mDNS is a LQDN. printer3.sitelocal. (or any of the .special-tld variants, including any based on ULA or alignment of the stars) in DNS is a LQDN. printer3.. is a FQDN. Note that for both LQDN and FQDN above, a trailing dot exists. printer3.local.. is and always was a valid FQDN even before mDNS existed. local is only reserved when used as a TLD. Curtis From kerlyn2001@gmail.com Wed Aug 8 10:38: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 B8E4B21F8670 for ; Wed, 8 Aug 2012 10:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.477, 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 hppTetHx494Y for ; Wed, 8 Aug 2012 10:38:26 -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 8A4CE21F866A for ; Wed, 8 Aug 2012 10:38:26 -0700 (PDT) Received: by lahm15 with SMTP id m15so592629lah.31 for ; Wed, 08 Aug 2012 10:38:25 -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=1kGuTI5qMwB9jgSuPSLgiJAy7Sq1zdDM/+RcTfbxjNg=; b=xOX3rzyUkCL2zX7amsT9V+U3JvRVha/ywmLHPfmf4tDVpVmxHdtoNMdiMGG2tdvdyC 2g+vKng6l+hsplyQjNfUZRebxVxLLqNp27acPNICe+3/KD8+5LCa7iNYFPczZUZszbrL 1BP7oQ7Z44m/0dguJ6c+FkooQ5c779JMWQKPT+3qK6mpQHLbyKaN1PEuN0azLMI17TtB 9digfUi9EHeQ2I7NvVY7VS3SSurM5r1JERy2WRygTa+yCPxEAUlUJqCbNHqgVeVzhrJx BsxjeccDfjrUYjgUb0GKLomLJEWKnpztkf5uKAOiVT2QVRiqAKQiToIp9M0gPmn/EpZO n+/w== MIME-Version: 1.0 Received: by 10.112.41.2 with SMTP id b2mr8343213lbl.58.1344447505516; Wed, 08 Aug 2012 10:38:25 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.10.199 with HTTP; Wed, 8 Aug 2012 10:38:25 -0700 (PDT) In-Reply-To: <201208081709.q78H901G031739@gateway.ipv6.occnc.com> References: <201208081709.q78H901G031739@gateway.ipv6.occnc.com> Date: Wed, 8 Aug 2012 13:38:25 -0400 X-Google-Sender-Auth: RjYdoa9rKJAaFiN9BGeuRd19h8Y Message-ID: From: Kerry Lynn To: curtis@occnc.com Content-Type: text/plain; charset=ISO-8859-1 Cc: Evan Hunt , Michael Richardson , "homenet@ietf.org Group" Subject: Re: [homenet] LQDN (was" 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, 08 Aug 2012 17:38:27 -0000 On Wed, Aug 8, 2012 at 1:09 PM, Curtis Villamizar wrote: > > Snipped most of this message. > > In message > Kerry Lynn writes: > >> I like to see us reserve "FQDN" for host names that are registered in >> the global DNS namespace, and use "LQDN" (or some other alternative) >> for host names in locally served zones. Any support for this? >> >> -K- > > Yes this is a good suggestion. > > Examples: > > printer3 is unqualified. > > printer3.local. in mDNS is a LQDN. > > printer3.sitelocal. (or any of the .special-tld variants, > including any based on ULA or alignment of the stars) in DNS is a > LQDN. > > printer3.. is a FQDN. > > Note that for both LQDN and FQDN above, a trailing dot exists. > printer3.local.. is and always was a valid FQDN > even before mDNS existed. local is only reserved when used as a TLD. > Yes, a helpful clarification. -K- > Curtis From ajs@anvilwalrusden.com Wed Aug 8 11:22: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 B4B6A21F86E4 for ; Wed, 8 Aug 2012 11:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 BRnWirhL7Izh for ; Wed, 8 Aug 2012 11:22:39 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id A754221F8661 for ; Wed, 8 Aug 2012 11:22:39 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B370F8A031 for ; Wed, 8 Aug 2012 18:22:38 +0000 (UTC) Date: Wed, 8 Aug 2012 14:22:27 -0400 From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20120808182226.GC22220@crankycanuck.ca> References: <201208081709.q78H901G031739@gateway.ipv6.occnc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201208081709.q78H901G031739@gateway.ipv6.occnc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [homenet] LQDN (was" 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, 08 Aug 2012 18:22:41 -0000 On Wed, Aug 08, 2012 at 01:09:00PM -0400, Curtis Villamizar wrote: > > Yes this is a good suggestion. > > Examples: > > printer3 is unqualified. > > printer3.local. in mDNS is a LQDN. Except, of course, that it's not a "DN" at all: it's not a domain name. It's an mDNS name. Different protocol on a different port. Most notably, mDNS always uses UTF-8 and DNS often does not, and normally when you want to look up a Unicode string in the global DNS what you actually look up is a name made of A-labels. This is problematic, because if you just put http://café in your browser's URL bar, you're going to get different behaviour depending on your network, your browser, and your operating system. I'm aware that from the user's point of view, they're all just names, but I don't think it helps us as protocol people to gloss over the differences among different name technologies that are all in use at the same time. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From curtis@occnc.com Wed Aug 8 11:39: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 5B11B11E80BA for ; Wed, 8 Aug 2012 11:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.176, 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 VxdqS-LyqyzP for ; Wed, 8 Aug 2012 11:39: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 9E66511E8097 for ; Wed, 8 Aug 2012 11:39: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 q78IdCBC033524; Wed, 8 Aug 2012 14:39:12 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208081839.q78IdCBC033524@gateway.ipv6.occnc.com> To: Brian E Carpenter From: Curtis Villamizar In-reply-to: Your message of "Wed, 08 Aug 2012 13:03:11 BST." <5022557F.5050105@gmail.com> Date: Wed, 08 Aug 2012 14:39:12 -0400 Cc: Evan Hunt , Michael Richardson , Kerry Lynn , Michael Thomas , "homenet@ietf.org Group" 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, 08 Aug 2012 18:39:27 -0000 In message <5022557F.5050105@gmail.com> Brian E Carpenter writes: > On 07/08/2012 20:11, Michael Thomas wrote: > > On 08/07/2012 11:46 AM, Kerry Lynn wrote: > >> On Mon, Aug 6, 2012 at 9:39 PM, Evan Hunt wrote: > >>> > >>> Tunnels are okay, but to use them, but has to get the DNS search order > >>> and the DNS server list right, and that's walled garden territory. > >>> *If* we are going to turn each home into a walled garden, then let's be > >>> aware that we are doing that. > >> I'm of the opinion that in a "walled garden" scenario, the tunnel > >> endpoint may > >> be the only resource that needs a global name / address. > > > > Just checking, but we all think that naming is a separate issue > > from reachability, right? > > It certainly is. But see http://tools.ietf.org/html/draft-carpenter-referral-ps > especially section 4.2 "FQDNs are not sufficient". > > Brian Brian, MIF may be trying to solve the problem the wrong way. Providing a mapping of DNS to loopback address has long been used (by routers) to provide a stable reachable address. The routing cost to reach that loopback interface (which can change many times for an active connection) is used to determine which physical interface gets used to reach the loopback. For example if one interface is connected to an ethernet which gets isolated due to a router failure, the other interface is used because routing tells us that one of them is unreachable. Multihoming of course pokes holes in the routing tables and causes some routing table bloat. This has always been a problem and IPv6 does nothing to improve the situation that existed in IPv4 two decades ago with a lot of small providers and large enterprises using dual provider multihoming. If we are concerned with hosts that have multiple interfaces both leading to parts of the homenet, that is easily solved. Multihomed homenets is a whole different problem, but solvable if redundancy is to the same provider. A conditional static route can be advertised within the provider, with these routes having limited scope (for example using BGP communities). If this practice were to become commonplace (I doubt it, no consumer provider has that sort of redundancy in the last mile), then the provider would have to limit the scope of these more specific routes to a small subset of their own topology. I get the impression that if NAT didn't exist, then draft-carpenter-referral-ps would server no purpose. Is this draft entirely motivated by problems caused by NAT? Curtis From curtis@occnc.com Wed Aug 8 11:49: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 8599121F861C for ; Wed, 8 Aug 2012 11:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.171, 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 o2qp0bA4UOPO for ; Wed, 8 Aug 2012 11:49:17 -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 489DA21F8619 for ; Wed, 8 Aug 2012 11:49: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 q78ImtCZ033624; Wed, 8 Aug 2012 14:48:56 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208081848.q78ImtCZ033624@gateway.ipv6.occnc.com> To: Andrew Sullivan From: Curtis Villamizar In-reply-to: Your message of "Wed, 08 Aug 2012 09:35:33 EDT." <20120808133532.GB77082@mail.yitter.info> Date: Wed, 08 Aug 2012 14:48:55 -0400 Cc: homenet@ietf.org Subject: Re: [homenet] naming, what's the problem? 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, 08 Aug 2012 18:49:18 -0000 In message <20120808133532.GB77082@mail.yitter.info> Andrew Sullivan writes: > On Wed, Aug 08, 2012 at 08:32:01AM -0400, David R Oran wrote: > > Yes, and a fairly hard one given the manual/administrative nature of > > domain registrations and the geek factor of secure dynamic DNS > > updates for all services to the global DNS. > > What is this "geek factor" whereof you speak? Once you have a name > registered, registered your service with a service like dyn.com's > DynDNS service, and told your gateway about it, everything else Just > Works. I know this mostly because I know people who don't know > anything about what they are doing, but who are able to navigate this > far. > > What probably is true is at least the following: > > 1. Many people don't want to pay for (thereby use) their own > name, and don't want to pay extra for a service like this. Dyn > and (I believe) some of its competitors have free services of this > sort, but they're somewhat restricted in what they can do. (Still, > you can do this today when you buy shipping product from some > vendors, without doing a single extra thing.) > > 2. Registering DNS names and somehow hooking them up to edge systems > remains hard. DNSOP is actually investigating this problem, but > maybe this WG ought to collaborate on that. > > 3. Split-horizon DNS isn't that reliable, and tends to leak. > > 4. Trying to make this work smoothly with .local addresses is probably a > good way to cause confusion > > For what it's worth, after the discussion in Vancouver I went back to > colleagues at Dyn to ask about previous work on standardizing what I > might call the CPE-to-DNS-provider link, as I was pretty sure there'd > been previous work. Indeed there had, and I'm attempting to dust it > off. If we're serious about systems inside our target networks being > somehow addressable from the global Internet, then it seems to me a > mechanism to integrate easily to the global DNS without requiring > major lock-in (or major upgrade of DHCP) is going to be something > we'll have to tackle. > > > Much as it would be great for Homenet to solve this problem and get > > a lot more functionality for users, this may be a bridge too far for > > the current work, which is focused on getting routing and naming > > INSIDE the home seamless and completely auto-configuring. > > If, on the other hand, we are in fact going to limit our scope to > inside the home network (and what problem is it, exactly, that we > have? My network can already do this, I think?) then of course the > above is just needless extra work. > > > I think the problem of disambiguating names of resources in the home > > has to be dealt with to prevent users whose devices are mobile from > > violating the principle of least astonishment. I don't think the > > ability to resolve names of home resources from anywhere on the > > Internet has to be solved in order to solve the disambiguation > > problem. > > I think that's a little optimistic. As soon as you have the problem, > "The name in context X is the same as in context Y and I want to be > able to tell the difference when I cross context," you are already in > Internet land. That's an interoperation problem, at least from the > user's point of view. > > Best, > > A One solution, the one you are describing is where the CPE runs DHCP only and uses the dyndns protocol to make addresses available globally. Another solution is have the CPE run both DHCP and bind (or equiv) and run dyndns. The provider could delegate and secondary a subdomain of the provider with no need to contact a domain registry. When a domain registrar is needed is only when the homenet needs or wants (maybe for ego reasons) a domain residing in a TLD (such as .com or .org) and would not accept a subdomain from the provider. For example the homenet user wants foo.com and would not accept something of the form foo.site.provider.com, which would be less permanet (the delegation is lost if switching providers). Curtis From each@isc.org Wed Aug 8 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 8A4E921F8647 for ; Wed, 8 Aug 2012 11:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24] 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 U2xTunU3VzJP for ; Wed, 8 Aug 2012 11:52:23 -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 8970321F8645 for ; Wed, 8 Aug 2012 11:52:19 -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 A4CB8C9493; Wed, 8 Aug 2012 18:52:07 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 94FFE216C36; Wed, 8 Aug 2012 18:52:07 +0000 (UTC) Date: Wed, 8 Aug 2012 18:52:07 +0000 From: Evan Hunt To: Andrew Sullivan Message-ID: <20120808185207.GA53113@isc.org> References: <201208081709.q78H901G031739@gateway.ipv6.occnc.com> <20120808182226.GC22220@crankycanuck.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120808182226.GC22220@crankycanuck.ca> User-Agent: Mutt/1.4.2.3i Cc: homenet@ietf.org Subject: Re: [homenet] LQDN (was" 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, 08 Aug 2012 18:52:24 -0000 > Except, of course, that it's not a "DN" at all: it's not a domain > name. Also not "qualified", as long as we're quibbling. But I do think the distinction between FQDN and is a useful one to have terminology for, and "LQDN" does get the job done even though it doesn't make proper acronymic sense; I suggest we continue using it here in the short term and plan on switching to a more precisely accurate term by the time we start producing RFC's. I don't have spare cycles to participate in the bikeshedding, but I'll be happy with anything that agrees with the definition previously proposed for "LQDN". -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From curtis@occnc.com Wed Aug 8 12:44: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 EB07B11E80FB for ; Wed, 8 Aug 2012 12:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.167, 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 3+2GIGKTtlGh for ; Wed, 8 Aug 2012 12:44:11 -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 7401A11E80F3 for ; Wed, 8 Aug 2012 12:44: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 q78JhcBc035311; Wed, 8 Aug 2012 15:43:39 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208081943.q78JhcBc035311@gateway.ipv6.occnc.com> To: homenet@ietf.org From: Curtis Villamizar Date: Wed, 08 Aug 2012 15:43:38 -0400 Cc: curtis@occnc.com Subject: [homenet] are FQDNs sufficient and if so for what? 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, 08 Aug 2012 19:44:13 -0000 The following is an excerpt from section "4.2. FQDNs are not sufficient" in Brian's draft-carpenter-referral-ps-02.txt > o In large networks, it is now quite common that the DNS > administrator is out of touch with the applications user or > administrator, and as a result, that the DNS is out of sync with > reality. > o DNS was never designed to accommodate mobile or roaming hosts, > whose locator may change rapidly. > o DNS has never been satisfactorily adapted to isolated, > transiently-connected, or ad hoc networks. > o It is no longer reasonable to assume that all addresses associated > with a DNS name are bound to a single host. One result is that > the DNS name might suffice for an initial connection, but a > specific address is needed to rebind to the same peer, say, to > recover from a broken connection. > o It is no longer reasonable to assume that a DNS query will return > all usable addresses for a host. > o Hosts may be identified by a different URI per service: no unique > URI scheme, meaning no single FQDN, will apply. The bottom line is I really don't see any serious problem with DNS. It doesn't solve everything but wasn't intended to and replacing it with a new mapping of names to address and other stuff won't change anything. The following is comments on each point individually. > o In large networks, it is now quite common that the DNS > administrator is out of touch with the applications user or > administrator, and as a result, that the DNS is out of sync with > reality. This is not a technical problem with DNS. Large DNS domains can be split into multiple subdomains. For example, universities have always delegated subdomains to departments that wanted them. It may be that a lot of enterprises that run Microsoft junk that maps into DNS are loath to use subdomains because it relinquishes control (turf issue) or because the Microsoft junk gets harder to administer when subdomains are in use. [That's the excuse I heard at the last corporation I was at - not sure if it is valid]. > o DNS was never designed to accommodate mobile or roaming hosts, > whose locator may change rapidly. A highly dynamic name resolution is not the answer to mobility. If so, then getting rid of the 15 minute minimal TTL would do it. But that would not solve the problem. The name would have to be updated exactly simultaneously to the new address being acquired if the old address is lost at the same time. The only reliable means of supporting unlimited mobility so far involves using a fixed address, and a fixed base station and a means of updating a tunnel from the base to the mobile device. > o DNS has never been satisfactorily adapted to isolated, > transiently-connected, or ad hoc networks. The suggestion to delegate to the home and provide secondary addresses the transiently-connected domain which wants to be primary. The same solutions to mobility apply to ad-hoc networks. The infrastructure is unnamed, but the nodes within it can be handled as mobile nodes, including any routers that are mobile. > o It is no longer reasonable to assume that all addresses associated > with a DNS name are bound to a single host. One result is that > the DNS name might suffice for an initial connection, but a > specific address is needed to rebind to the same peer, say, to > recover from a broken connection. In the cases where this is true, the FQDN (www.content-provider.com) is intentionally mapped to a set of servers. Using HTTP 1.1 for example, there is no need to get the remaining chunks of a broken connection from the same server. Any of them should return the same result. In cases such as queries where results could vary, a redirect is done on initial query. Often this redirect is done anyway to point to a topologically closer server or a server with lower utilization. > o It is no longer reasonable to assume that a DNS query will return > all usable addresses for a host. Nor does it matter. Only one always reachable address is needed. It is about time that more than just routers started assigning a GUA to the loopback and putting that in the DNS such that no matter which interfaces were down or unreachable, the host was always reachable if at least one interface was up and reachable. > o Hosts may be identified by a different URI per service: no unique > URI scheme, meaning no single FQDN, will apply. CNAMEs are very helpful. I like keeping certain services as CNAME, such as www, krb, cvs, svn. Mail has its own redirection built in as MX records. If I want to ssh into the kerberos kdc I can use the CNAME kdc. It doesn't matter that this host may have other names. I can easily find out the FQDN that the CNAME points to. Curtis From curtis@occnc.com Wed Aug 8 12:50: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 3C41721F8503 for ; Wed, 8 Aug 2012 12:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, 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 Nj054x7lZEB2 for ; Wed, 8 Aug 2012 12:50:21 -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 5839D11E80FB for ; Wed, 8 Aug 2012 12:50:21 -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 q78JnuHv035416; Wed, 8 Aug 2012 15:49:56 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208081949.q78JnuHv035416@gateway.ipv6.occnc.com> To: Andrew Sullivan From: Curtis Villamizar In-reply-to: Your message of "Wed, 08 Aug 2012 14:22:27 EDT." <20120808182226.GC22220@crankycanuck.ca> Date: Wed, 08 Aug 2012 15:49:56 -0400 Cc: homenet@ietf.org Subject: Re: [homenet] LQDN (was" 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, 08 Aug 2012 19:50:23 -0000 In message <20120808182226.GC22220@crankycanuck.ca> Andrew Sullivan writes: > On Wed, Aug 08, 2012 at 01:09:00PM -0400, Curtis Villamizar wrote: > > > > Yes this is a good suggestion. > > > > Examples: > > > > printer3 is unqualified. > > > > printer3.local. in mDNS is a LQDN. > > Except, of course, that it's not a "DN" at all: it's not a domain > name. It's an mDNS name. Different protocol on a different port. > Most notably, mDNS always uses UTF-8 and DNS often does not, and > normally when you want to look up a Unicode string in the global DNS > what you actually look up is a name made of A-labels. Good point. I agree. Change this to: printer3.local. in mDNS is not a domain name at all Perhaps mDNS should not have used DNS in the name. It might be possible to tie mDNS into DNS such that a DNS resolver could return something useful for a printer3.local query in which case printer3.local would be a LQDN. Without that tie in, it is not. Curtis > This is problematic, because if you just put > > http://café > > in your browser's URL bar, you're going to get different behaviour > depending on your network, your browser, and your operating system. > > I'm aware that from the user's point of view, they're all just names, > but I don't think it helps us as protocol people to gloss over the > differences among different name technologies that are all in use at > the same time. > > Best, > > A From bzeeb-lists@lists.zabbadoz.net Wed Aug 8 22:20: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 B527621E805E for ; Wed, 8 Aug 2012 22:20:45 -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 N7CcSmudt6YF for ; Wed, 8 Aug 2012 22:20:44 -0700 (PDT) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by ietfa.amsl.com (Postfix) with ESMTP id B698021E805A for ; Wed, 8 Aug 2012 22:20:43 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 3DF2525D3A13; Thu, 9 Aug 2012 05:20:41 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 52495BE850C; Thu, 9 Aug 2012 05:20:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id Vwlz4KWI93yB; Thu, 9 Aug 2012 05:20:38 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id AAD07BE850A; Thu, 9 Aug 2012 05:20:37 +0000 (UTC) Date: Thu, 9 Aug 2012 05:20:36 +0000 (UTC) From: "Bjoern A. Zeeb" To: Michael Richardson In-Reply-To: <9600.1344364304@obiwan.sandelman.ca> Message-ID: References: <201208071539.q77FdWC7001754@gateway.ipv6.occnc.com> <502159C6.6060109@gmail.com> <9600.1344364304@obiwan.sandelman.ca> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: homenet@ietf.org, curtis@occnc.com Subject: Re: [homenet] IPv6 aliases and renumbering (was Re: 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: Thu, 09 Aug 2012 05:20:45 -0000 On Tue, 7 Aug 2012, Michael Richardson wrote: > >>>>>> "Brian" == Brian E Carpenter writes: > Brian> Aliases, as you describe them, sound like a hack. I'd like to > Brian> hear from Microsoft (for example) whether their support of > Brian> multiple IPv6 addresses per interface is a hack or genuine. I > Brian> don't care about IPv4, but the IPv6 model is very clear. You > Brian> can't read the ND spec and imagine the arrival of a new > Brian> address resetting sessions that use other addresses. > > On Linux and *BSD, (possibly including OSX, but I don't know, but I > could do an experiment with my officemate), new addresses get added > without an interface flap. However there are sometimes "uneducated" (to be polite) NIC driver developers who think that in the 21st centrury they still need to completely reset their modern NIC on programming certain filter events, often for multicast, so it's not uncommon that once in a while you can find a behaviour that configuring addresses on an interface still causes a full down/up cycle. But yes, ne shuld consider that a bug. In general it should not hapen, I agree. > Old addresses expire as they expire, no interface flap need occur. > Linux does this all in the kernel, *BSD does it in rtsold. There is no need for rtsold; it's only helping you on ifUp to trigger the RSes but the moment you learn or "lose" a prefix the kernel handles autoconfiguration for you (unless you told it not to). Things might vary a bit between the different flavours of *BSD. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From swmike@swm.pp.se Wed Aug 8 22:32: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 5D81321F859C for ; Wed, 8 Aug 2012 22:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 a5BkkbwrwQbL for ; Wed, 8 Aug 2012 22:32:24 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 9233521F85A0 for ; Wed, 8 Aug 2012 22:32:24 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B76D69C; Thu, 9 Aug 2012 07:32:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B12749A; Thu, 9 Aug 2012 07:32:22 +0200 (CEST) Date: Thu, 9 Aug 2012 07:32:22 +0200 (CEST) From: Mikael Abrahamsson To: Curtis Villamizar In-Reply-To: <201208081519.q78FJZtp028789@gateway.ipv6.occnc.com> Message-ID: References: <201208081519.q78FJZtp028789@gateway.ipv6.occnc.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: 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: Thu, 09 Aug 2012 05:32:25 -0000 On Wed, 8 Aug 2012, Curtis Villamizar wrote: > As long as many customers, probably the vast majority, have one or more > IPv4 only devices, it is infeasible for a provider to deploy NAT64, > DNS64 and offer IPv6 only. BEHAVE preference or not, it won't work > today. Maybe in a decade but we don't have that much time. What was said in BEHAVE (afaik), was that using a DNS64 resolver for a dual stacked machine is considered harmful. -- Mikael Abrahamsson email: swmike@swm.pp.se From brian.e.carpenter@gmail.com Thu Aug 9 00:17: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 BDEDC21F855B for ; Thu, 9 Aug 2012 00:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.863 X-Spam-Level: X-Spam-Status: No, score=-100.863 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24, 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 stZmk6TWEYXj for ; Thu, 9 Aug 2012 00:17:19 -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 CD3D121F85D2 for ; Thu, 9 Aug 2012 00:17:18 -0700 (PDT) Received: by wibhm11 with SMTP id hm11so33849wib.13 for ; Thu, 09 Aug 2012 00:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LdNLXlDjnd7FquasSj8T/U9NyL1kcyPecyIY7RWDbhs=; b=yGF0v5UcKib9rDxj5WDKVtVWJOIunJ9MR/aJFZQ0iPTPYi/8KXhRFSmab+6MRgFMZl xbC4g1rsR+pxvAcyXd9MUPV4XSJ458pIdMaSlcsToOOdixCPT1OVHsa00zEcsqcLl7ZT RBqYFLMTvXODnciUUFFQqTqLkJ45IoIx6+dp3V+zyBi0jTmFSO6NnPO7J/v4DThHJNPm 6c5MPTqXhihfmDECPcw1C6E/cAGA4+vySXeAR5W4HngSLTFxRKpAhVvpQiA5Dw7IhLDW z2glml2sKg0DXg+eVhdCy+GylfmeOVZ6WUlLqSxMKvNPhE5/ZG12Zk6Zv5EwDCg8U0PS GtIw== Received: by 10.216.85.130 with SMTP id u2mr10506967wee.202.1344496637728; Thu, 09 Aug 2012 00:17:17 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-33.as13285.net. [2.102.216.33]) by mx.google.com with ESMTPS id cl8sm156135wib.10.2012.08.09.00.17.15 (version=SSLv3 cipher=OTHER); Thu, 09 Aug 2012 00:17:16 -0700 (PDT) Message-ID: <50236402.3020007@gmail.com> Date: Thu, 09 Aug 2012 08:17:22 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Evan Hunt References: <201208081709.q78H901G031739@gateway.ipv6.occnc.com> <20120808182226.GC22220@crankycanuck.ca> <20120808185207.GA53113@isc.org> In-Reply-To: <20120808185207.GA53113@isc.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, Andrew Sullivan Subject: Re: [homenet] LQDN (was" 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: Thu, 09 Aug 2012 07:17:19 -0000 On 08/08/2012 19:52, Evan Hunt wrote: >> Except, of course, that it's not a "DN" at all: it's not a domain >> name. > > Also not "qualified", as long as we're quibbling. But I do think the > distinction between FQDN and is a useful one > to have terminology for, and "LQDN" does get the job done even though it > doesn't make proper acronymic sense; I suggest we continue using it here > in the short term and plan on switching to a more precisely accurate term > by the time we start producing RFC's. > > I don't have spare cycles to participate in the bikeshedding, but I'll > be happy with anything that agrees with the definition previously > proposed for "LQDN". As far as I can see there are still two kinds of LQDN: ALQDN - ambiguous, or potentially ambiguous, names (like printer.local) ULQDN - unambiguous, or almost certainly unambiguous, names (like printer..sitelocal) I will be unhappy if ALQDNs are allowed except as legacy. Brian From brian.e.carpenter@gmail.com Thu Aug 9 00:33: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 642AC21F86D9 for ; Thu, 9 Aug 2012 00:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.479 X-Spam-Level: X-Spam-Status: No, score=-101.479 tagged_above=-999 required=5 tests=[AWL=0.212, 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 SitXCZMAfKyf for ; Thu, 9 Aug 2012 00:33:13 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9393121F86CF for ; Thu, 9 Aug 2012 00:33:13 -0700 (PDT) Received: by weyu54 with SMTP id u54so113533wey.31 for ; Thu, 09 Aug 2012 00:33:12 -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=8gasekmlIFmcTokay/J2FlGL0W1Tn4VvNYeBc83pIxY=; b=m6JSieUWpX7Kb1lZH4XzqY15WyMWb0DFjvxzg6JwX3wj3PiWuhCI5hrGVxkt+xJq3d G8Cu5E1IZlPZqec5buFkcjXQQdBJG6vJhTxZLQtSnreSOH1xCtel3TqFCOvbHHPbfXwB joxJWISTvAUjhQcxA5Xdx0gxRF1XGwl/owF8pSbAhzWxjG/ywvFqP6xeI0+UhBGG/PFn hCu9kT4Sekit8B2thmgXTp68VAzrpQGn11hEUXKUdmez62V13NhK7srK2Gx49ubenBiB //qGRDHvS+e4V+l5pFL5vA8GXK/5ON87qdjq3J6KsFTcJPU5DAz7AeBwSRgLW8wlE7Fq F9JA== Received: by 10.180.76.135 with SMTP id k7mr520682wiw.7.1344497592728; Thu, 09 Aug 2012 00:33:12 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-33.as13285.net. [2.102.216.33]) by mx.google.com with ESMTPS id l6sm260681wiz.4.2012.08.09.00.33.10 (version=SSLv3 cipher=OTHER); Thu, 09 Aug 2012 00:33:11 -0700 (PDT) Message-ID: <502367BD.3010005@gmail.com> Date: Thu, 09 Aug 2012 08:33:17 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: curtis@occnc.com References: <201208081839.q78IdCBC033524@gateway.ipv6.occnc.com> In-Reply-To: <201208081839.q78IdCBC033524@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Evan Hunt , Michael Richardson , Kerry Lynn , Michael Thomas , "homenet@ietf.org Group" Subject: [homenet] referrals [ 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: Thu, 09 Aug 2012 07:33:14 -0000 > I get the impression that if NAT didn't exist, then > draft-carpenter-referral-ps would server no purpose. Is this draft > entirely motivated by problems caused by NAT? I don't think so. There are other causes of disjoint address space, which existed even before we had NAT or specialised firewalls - router ACLs for example. Certainly NAT is the major cause today (and NPTv6 will propagate the problem into IPv6). v4-only and v6-only islands will probably arise too. Regards Brian On 08/08/2012 19:39, Curtis Villamizar wrote: > In message <5022557F.5050105@gmail.com> > Brian E Carpenter writes: > >> On 07/08/2012 20:11, Michael Thomas wrote: >>> On 08/07/2012 11:46 AM, Kerry Lynn wrote: >>>> On Mon, Aug 6, 2012 at 9:39 PM, Evan Hunt wrote: >>>>> Tunnels are okay, but to use them, but has to get the DNS search order >>>>> and the DNS server list right, and that's walled garden territory. >>>>> *If* we are going to turn each home into a walled garden, then let's be >>>>> aware that we are doing that. >>>> I'm of the opinion that in a "walled garden" scenario, the tunnel >>>> endpoint may >>>> be the only resource that needs a global name / address. >>> Just checking, but we all think that naming is a separate issue >>> from reachability, right? >> >> It certainly is. But see http://tools.ietf.org/html/draft-carpenter-referral-ps >> especially section 4.2 "FQDNs are not sufficient". >> >> Brian > > > Brian, > > MIF may be trying to solve the problem the wrong way. Providing a > mapping of DNS to loopback address has long been used (by routers) to > provide a stable reachable address. The routing cost to reach that > loopback interface (which can change many times for an active > connection) is used to determine which physical interface gets used to > reach the loopback. For example if one interface is connected to an > ethernet which gets isolated due to a router failure, the other > interface is used because routing tells us that one of them is > unreachable. > > Multihoming of course pokes holes in the routing tables and causes > some routing table bloat. This has always been a problem and IPv6 > does nothing to improve the situation that existed in IPv4 two decades > ago with a lot of small providers and large enterprises using dual > provider multihoming. > > If we are concerned with hosts that have multiple interfaces both > leading to parts of the homenet, that is easily solved. Multihomed > homenets is a whole different problem, but solvable if redundancy is > to the same provider. A conditional static route can be advertised > within the provider, with these routes having limited scope (for > example using BGP communities). If this practice were to become > commonplace (I doubt it, no consumer provider has that sort of > redundancy in the last mile), then the provider would have to limit > the scope of these more specific routes to a small subset of their own > topology. > > I get the impression that if NAT didn't exist, then > draft-carpenter-referral-ps would server no purpose. Is this draft > entirely motivated by problems caused by NAT? > > Curtis > From brian.e.carpenter@gmail.com Thu Aug 9 03:01: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 0F75C21F86F2 for ; Thu, 9 Aug 2012 03:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.551 X-Spam-Level: X-Spam-Status: No, score=-100.551 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_20=-0.74, 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 KpZHxvTOZaem for ; Thu, 9 Aug 2012 03:01:26 -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 D678B21F8683 for ; Thu, 9 Aug 2012 03:01:25 -0700 (PDT) Received: by eekb45 with SMTP id b45so84700eek.31 for ; Thu, 09 Aug 2012 03:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=lq6iBLYE9kb90cbJT6xowSY6Dd7/Id6/Lp+iOQGmvQs=; b=cEbN3vGTh+iYRVWnQKgWH9gAi9qisW7itetRqfU1kzVsg8hulaQvU0qDaRfUcsX9DL VVSuKpyiHEKyud89WyJBRi7qfjuYCKfq3MaWVF7oMbKbLBrQycfRDgBQUYPWz2sh0qLl fA+1ELQQcbzZnA2owzBvZAUPPmx3LVdNUo+5kmN/1OT9EwPvpkutbmMq7D392c3u7bFd wM6ZSGo2wEsTPcSlyIfdsDB9ea3b0LzKQ2tPPiVGRbltHKGbyqCevrlkUatGzUM42M5m QjCo8Y2S4MI5h1kRVYdhVXEVhu4Ft0A2XB6ISoReA6FkxP2xTqpvsDQtYYskdPJ/ISc8 ZXHA== Received: by 10.14.0.198 with SMTP id 46mr5926327eeb.30.1344506485001; Thu, 09 Aug 2012 03:01:25 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-33.as13285.net. [2.102.216.33]) by mx.google.com with ESMTPS id a48sm2131164eeo.1.2012.08.09.03.01.23 (version=SSLv3 cipher=OTHER); Thu, 09 Aug 2012 03:01:24 -0700 (PDT) Message-ID: <50238A7A.9090002@gmail.com> Date: Thu, 09 Aug 2012 11:01:30 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: homenet@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [homenet] Tunnels to 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: Thu, 09 Aug 2012 10:01:27 -0000 All this talk about tunnels and names made me think that people might be interested in the Signpost project, mainly based at the Computer Lab in Cambridge where I am currently a visitor. I think this project is a proof of concept for ideas being discussed here. http://conferences.sigcomm.org/sigcomm/2012/paper/sigcomm/p83.pdf (10MB file) http://conferences.npl.co.uk/satin/presentations/satin2012slides-Madhavapeddy.pdf Regards Brian Carpenter From ajs@anvilwalrusden.com Thu Aug 9 04:51: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 8E54921F86A7 for ; Thu, 9 Aug 2012 04:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.171 X-Spam-Level: X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 MrLXI+lr5IqA for ; Thu, 9 Aug 2012 04:51:26 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 178FA21F8670 for ; Thu, 9 Aug 2012 04:51:26 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D07728A031 for ; Thu, 9 Aug 2012 11:51:24 +0000 (UTC) Date: Thu, 9 Aug 2012 07:51:25 -0400 From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20120809115125.GC23227@crankycanuck.ca> References: <201208081709.q78H901G031739@gateway.ipv6.occnc.com> <20120808182226.GC22220@crankycanuck.ca> <20120808185207.GA53113@isc.org> <50236402.3020007@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50236402.3020007@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [homenet] LQDN (was" 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: Thu, 09 Aug 2012 11:51:26 -0000 On Thu, Aug 09, 2012 at 08:17:22AM +0100, Brian E Carpenter wrote: > > ALQDN - ambiguous, or potentially ambiguous, names (like printer.local) That doesn't need a new name. We have a name for that: "relative". See RFC 1034 section 3.1. > ULQDN - unambiguous, or almost certainly unambiguous, names (like printer..sitelocal) > That example is strictly speaking a relative name, too, since it isn't qualified by the root label. But my point upthread was not about bikeshedding the things we call this, but to observe that there are different naming technologies (we concentrated on DNS and mDNS names, but we also have NetBIOS and llmnr names. The latter is very similar to but not exactly the same as mDNS. We can only wish that NetBIOS names are all gone). I think the impulse to try to get these to work together from the user's perspective is right, but for the purposes of protocol development we need to attend to the fact that they're all just different technologies. > I will be unhappy if ALQDNs are allowed except as legacy. Me too, but since they're built right into RFC 1034 (which is still STD 13), I think we're dreaming. We might as well wish that the world be freed from NAT. Best, A -- Andrew Sullivan ajs@crankycanuck.ca From kerlyn2001@gmail.com Thu Aug 9 07:17: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 3E38E21F869E for ; Thu, 9 Aug 2012 07:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.440, 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 4XZY32fE4KO1 for ; Thu, 9 Aug 2012 07:17:23 -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 DCAD821F866D for ; Thu, 9 Aug 2012 07:17:22 -0700 (PDT) Received: by lahm15 with SMTP id m15so306707lah.31 for ; Thu, 09 Aug 2012 07:17:21 -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=sBIsO0APllQdRnYZ7L0OBil+8pcoliW8V2ISqMuuja4=; b=PThe3SxWkmiKj86hiwjs06OVPg5lRL9L7SJSRD1eJYnh7lDIzcH+Vv3q9C7vQTWoNb hlbSl13J6zdqKwOCACNkNxJsr8hjX6fTXXLRUSua7MrfnouwwQpKeJKBNRNZjIOURwI8 yhM46V/G9ElfvOzangup1X3qo26Nx6K/p1PWcd3ePkF7s2kKYXHb2a3y9iPuIXqYUugj Ii1FD0VheGMMPUEdEyCKqk+9/w96SnGx6IKIE/3UegP4hSQ2NMAKfLBoi7mWb21KD/LX y8mQ/VmcPmHctmmVSri3n8RPoMWuiQCX1e6XlK502y2RJZ0eXKpugwo245Tp5LAbbbpV lvDw== MIME-Version: 1.0 Received: by 10.112.29.233 with SMTP id n9mr872720lbh.91.1344521841781; Thu, 09 Aug 2012 07:17:21 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.10.199 with HTTP; Thu, 9 Aug 2012 07:17:21 -0700 (PDT) In-Reply-To: <20120809115125.GC23227@crankycanuck.ca> References: <201208081709.q78H901G031739@gateway.ipv6.occnc.com> <20120808182226.GC22220@crankycanuck.ca> <20120808185207.GA53113@isc.org> <50236402.3020007@gmail.com> <20120809115125.GC23227@crankycanuck.ca> Date: Thu, 9 Aug 2012 10:17:21 -0400 X-Google-Sender-Auth: iul1Z82j6ENYYmhXC3xpBvDL5dQ Message-ID: From: Kerry Lynn To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Cc: homenet@ietf.org Subject: Re: [homenet] LQDN (was" 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: Thu, 09 Aug 2012 14:17:24 -0000 On Thu, Aug 9, 2012 at 7:51 AM, Andrew Sullivan wrote: > On Thu, Aug 09, 2012 at 08:17:22AM +0100, Brian E Carpenter wrote: >> >> ALQDN - ambiguous, or potentially ambiguous, names (like printer.local) > > That doesn't need a new name. We have a name for that: "relative". > See RFC 1034 section 3.1. > >> ULQDN - unambiguous, or almost certainly unambiguous, names (like printer..sitelocal) >> > Change the leftmost '.' to '-' and I'm with you. > That example is strictly speaking a relative name, too, since it isn't > qualified by the root label. > > But my point upthread was not about bikeshedding the things we call > this, but to observe that there are different naming technologies (we > concentrated on DNS and mDNS names, but we also have NetBIOS and llmnr > names. The latter is very similar to but not exactly the same as > mDNS. We can only wish that NetBIOS names are all gone). I think the > impulse to try to get these to work together from the user's > perspective is right, but for the purposes of protocol development we > need to attend to the fact that they're all just different > technologies. > We all agree we shouldn't call them FQDNs, so that's progress. The distinction I was trying to draw was not which protocol is used for resolution, nor the degree of ambiguity in the name, but that these names are defined within a local scope (e.g. without recourse to recursive DNS lookups outside the site boundary). I feel that names such as those in RFC 6303 would also qualify by my definition, so maybe we should call them Locally Served DNS Names or similar. I also want to draw attention to terminology Erik Kline used in his discussion of http://tools.ietf.org/html/draft-kline-default-perimeter, the notion of "inside the home" versus "The Internet". I think this is a very useful model to enforce with users as it can be applied equivalently to naming, discovery, addressing, and security. >> I will be unhappy if ALQDNs are allowed except as legacy. > That's exactly the point. mDNS isn't going away, so let's fix the issues and leverage it as a basic capability. -K- > Me too, but since they're built right into RFC 1034 (which is still > STD 13), I think we're dreaming. We might as well wish that the world > be freed from NAT. > > Best, > > A > > -- > Andrew Sullivan > ajs@crankycanuck.ca > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mellon@fugue.com Thu Aug 9 07:24: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 A31A121F86DF for ; Thu, 9 Aug 2012 07:24:52 -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.241, 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 geKtdEG7x-PU for ; Thu, 9 Aug 2012 07:24:51 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFB821F86AF for ; Thu, 9 Aug 2012 07:24:49 -0700 (PDT) Received: from [IPv6:2001:470:1f07:1486:2027:78da:9a51:6be0] (unknown [IPv6:2001:470:1f07:1486:2027:78da:9a51:6be0]) by toccata.fugue.com (Postfix) with ESMTPSA id DBAFA2380630; Thu, 9 Aug 2012 10:24:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_DF3C8105-B287-4B64-AB74-93DE1A8FA14A" From: Ted Lemon In-Reply-To: Date: Thu, 9 Aug 2012 10:24:40 -0400 Message-Id: References: <201208081709.q78H901G031739@gateway.ipv6.occnc.com> <20120808182226.GC22220@crankycanuck.ca> <20120808185207.GA53113@isc.org> <50236402.3020007@gmail.com> <20120809115125.GC23227@crankycanuck.ca> To: Kerry Lynn X-Mailer: Apple Mail (2.1283) Cc: homenet@ietf.org, Andrew Sullivan Subject: Re: [homenet] LQDN (was" 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: Thu, 09 Aug 2012 14:24:53 -0000 --Apple-Mail=_DF3C8105-B287-4B64-AB74-93DE1A8FA14A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 9, 2012, at 10:17 AM, Kerry Lynn wrote: > That's exactly the point. mDNS isn't going away, so let's fix the = issues > and leverage it as a basic capability. NAT isn't going away either. Should we fix its issues and leverage its = basic capability as well? (Seriously. Just because something isn't going away doesn't mean we = should standardize on it.) --Apple-Mail=_DF3C8105-B287-4B64-AB74-93DE1A8FA14A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii That's = exactly the point.  mDNS isn't going away, so let's fix the = issues
and leverage it as a basic = capability.

NAT isn't going away = either.   Should we fix its issues and leverage its basic = capability as well?

(Seriously.   Just = because something isn't going away doesn't mean we should standardize on = it.)

= --Apple-Mail=_DF3C8105-B287-4B64-AB74-93DE1A8FA14A-- From mike@mtcc.com Thu Aug 9 07:35: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 6A77C21F85CD for ; Thu, 9 Aug 2012 07:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.080, 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 g0HYSufUNati for ; Thu, 9 Aug 2012 07:35:52 -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 9557421F8562 for ; Thu, 9 Aug 2012 07:35: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 q79EZTC9022371 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 9 Aug 2012 07:35:30 -0700 Message-ID: <5023CAB1.8030908@mtcc.com> Date: Thu, 09 Aug 2012 07:35: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: Ted Lemon References: <201208081709.q78H901G031739@gateway.ipv6.occnc.com> <20120808182226.GC22220@crankycanuck.ca> <20120808185207.GA53113@isc.org> <50236402.3020007@gmail.com> <20120809115125.GC23227@crankycanuck.ca> 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=917; t=1344522932; x=1345386932; 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]=20LQDN=20(was=22=20tunnels=20 as=20way=20to=20disambiguate=20.local) |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=Mjo3Hz64UOt1pa6mXHD6JGmtSS+v0x0JUXbG2YDTYJY=; b=kB498v4rYN/ESMw5L8MlYRI+a1wUY6UwpqrDrozzDQHw8X5GHwwK4FRTLw i/N9IW9isTwmGOZzrL5NpbsL4lCLbW3Ap4YcLK6D+eQbboFFImO/0poAschk Sc3JU/nai2Mlzykvvh3IJUQiFDYcrzU8iyTBF2o7KV8efLGNq6dTE=; 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: Kerry Lynn , homenet@ietf.org, Andrew Sullivan Subject: Re: [homenet] LQDN (was" 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: Thu, 09 Aug 2012 14:35:53 -0000 On 08/09/2012 07:24 AM, Ted Lemon wrote: > On Aug 9, 2012, at 10:17 AM, Kerry Lynn wrote: >> That's exactly the point. mDNS isn't going away, so let's fix the issues >> and leverage it as a basic capability. > > NAT isn't going away either. Should we fix its issues and leverage its basic capability as well? > > (Seriously. Just because something isn't going away doesn't mean we should standardize on it.) > It may not be going away, but it never had its debutante's ball either. I just did a thoroughly scientific and completely non-anecdotal study by conducting a rigorous and peer reviewed survey asking my friends on facebook what they do when they want to configure their home router. The results: o typed in 192.168.x.x -- 3 o uses global name from vanity domain -- 1 o suspicious that this might be a trick question -- 1 o used a name that took advantage of mdns -- 0 Mike From mcr+ietf@sandelman.ca Thu Aug 9 08:01: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 C4B8321F8733 for ; Thu, 9 Aug 2012 08:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.503, 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 V58g+p7+jcMS for ; Thu, 9 Aug 2012 08:01:33 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 8829021F861B for ; Thu, 9 Aug 2012 08:01:33 -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 EC86E2026A; Thu, 9 Aug 2012 11:14:22 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <50238A7A.9090002@gmail.com> References: <50238A7A.9090002@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] Tunnels to 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: Thu, 09 Aug 2012 15:01:35 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I think that this research is bang: the reason we couldn't do Opportunistic Encryption (RFC4322) was because we had no identity, not even local identity. (The fact that reverse DNS was hard to get control of was a clue to this. The fact that NAT makes reverse DNS ambiguous was just an additional complexity, but for many it seemed like the initial complexity)=20 >>>>> "Brian" =3D=3D Brian E Carpenter writes: Brian> All this talk about tunnels and names made me think that people Brian> might be interested in the Signpost project, mainly based at Brian> the Computer Lab in Cambridge where I am currently a visitor. Brian> I think this project is a proof of concept for ideas being Brian> discussed here. Brian> http://conferences.sigcomm.org/sigcomm/2012/paper/sigcomm/p83.pdf Brian> (10MB file) http://conferences.npl.co.uk/satin/presentations/sat= in2012slides-Madhavapeddy.pdf =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUCPQxYqHRg3pndX9AQJq3wQA0Ds/Ckg/vWrdOERe0WVei8Ehxici+ZyK mSzxoEXWeaZiToX9AiZ3nECf9wx+qabAidB22upWGIZxGtnKdgLGCw4z6KoS8gA8 Hr6HjH0SsRqXFMu96Fya67tRzr6uOY1fgcqjtgvl3J2lcOq7LfkeQiOayy6P3olI weK/MvwYa4Y= =8tzm -----END PGP SIGNATURE----- --=-=-=-- From d.sturek@att.net Thu Aug 9 08:37: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 31D9F21F8687 for ; Thu, 9 Aug 2012 08:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, 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 xWceZTgJUjzN for ; Thu, 9 Aug 2012 08:37:36 -0700 (PDT) Received: from nm14-vm0.access.bullet.mail.mud.yahoo.com (nm14-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.15]) by ietfa.amsl.com (Postfix) with SMTP id 7BE0421F878B for ; Thu, 9 Aug 2012 08:37:36 -0700 (PDT) Received: from [66.94.237.194] by nm14.access.bullet.mail.mud.yahoo.com with NNFMP; 09 Aug 2012 15:37:36 -0000 Received: from [98.139.221.54] by tm5.access.bullet.mail.mud.yahoo.com with NNFMP; 09 Aug 2012 15:37:36 -0000 Received: from [127.0.0.1] by smtp107.sbc.mail.bf1.yahoo.com with NNFMP; 09 Aug 2012 15:37:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1344526655; bh=JUj7XP/tGPVA2PUiN1+oziFpGnKRexVWufj+nI2qorE=; h=X-Yahoo-Newman-Id: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=FX6MtKquYWvjnSSXS/95odwmdrPNn/CPL8Jr8zm+JB1J8WdnZlv8EnOEwgxGYA0njUM6qxYzXGwzDiDeCnXWS09yJ5fSODCY+k27/mXxoc5rZx01znXZ5DpngoginuAXBfo0yuaKGqD7+7moJOmq3wNzu8dplNiT4R+DS1UxMIs= X-Yahoo-Newman-Id: 902803.57116.bm@smtp107.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: k1sKf3IVM1lG.DDbjWO0GKOFsfjeaLxcSNqxHDR7DyGAC0m KoW8Lu8Rl1zcTlLjZQMo9eKb1NTjlmP153nDEHOA3zQF2nh5AeV_M80B5JAu XltA2mZyQQ1BfRT9mLfqMnCv3H5NErq8D2iITl0EAXcSLGCc8cEMtttjhBIk Rhdy92MgPADm4rP9ClzGnRWaI0iYU2qtUrstUKk9Hco6GmDAQaniF6P_J1_w UgSsWIImKprDZUK9Bz86GCgptDyfhLcnnDYRMHJ59XCCZMAzJPAHOildq9zJ ru546C33fBrbxOLgpBOctHQqbU1btKjhqufWPZ9LC5W_Ts.8M1gZJk4fOlLF 6eVm9vXvanZfEEKEHojKH06Y6axij2WulMQItLAfq3CFYgXJRWQ_iPoHnQ7L tE0X2.FbN2miNauDKVnKI_bYytnzu9toXD0tZrqfWW5VitxpaER1ZUtKCrYf aTm.2UcLvBTyuJIi5 X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.105] (d.sturek@66.27.60.174 with login) by smtp107.sbc.mail.bf1.yahoo.com with SMTP; 09 Aug 2012 08:37:34 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Thu, 09 Aug 2012 08:37:30 -0700 From: Don Sturek To: Michael Thomas , Ted Lemon Message-ID: Thread-Topic: [homenet] LQDN (was" tunnels as way to disambiguate .local) In-Reply-To: <5023CAB1.8030908@mtcc.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Kerry Lynn , homenet@ietf.org, Andrew Sullivan Subject: Re: [homenet] LQDN (was" 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: Thu, 09 Aug 2012 15:37:37 -0000 Hi Michael, Your note below strangely proves the counterpoint (ie. "debutante ball" for mDNS). In your sample of 5, I am sure most (maybe all?) have some Apple product of sometype. If you actually had a packet sniffers in this study, you will find these devices happily advertising and finding services using mDNS without anyone typing in anything. Don On 8/9/12 7:35 AM, "Michael Thomas" wrote: >On 08/09/2012 07:24 AM, Ted Lemon wrote: >> On Aug 9, 2012, at 10:17 AM, Kerry Lynn wrote: >>> That's exactly the point. mDNS isn't going away, so let's fix the >>>issues >>> and leverage it as a basic capability. >> >> NAT isn't going away either. Should we fix its issues and leverage >>its basic capability as well? >> >> (Seriously. Just because something isn't going away doesn't mean we >>should standardize on it.) >> > >It may not be going away, but it never had its debutante's ball either. > >I just did a thoroughly scientific and completely non-anecdotal study >by conducting a rigorous and peer reviewed survey asking my friends >on facebook what they do when they want to configure their home router. > >The results: > >o typed in 192.168.x.x -- 3 >o uses global name from vanity domain -- 1 >o suspicious that this might be a trick question -- 1 >o used a name that took advantage of mdns -- 0 > >Mike >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From mike@mtcc.com Thu Aug 9 09:38: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 AFFE621F86F3 for ; Thu, 9 Aug 2012 09:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 BV5DBpoz1loc for ; Thu, 9 Aug 2012 09:38:54 -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 D894F21F86EA for ; Thu, 9 Aug 2012 09:38:53 -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 q79GcgLc032663 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 9 Aug 2012 09:38:42 -0700 Message-ID: <5023E792.8020206@mtcc.com> Date: Thu, 09 Aug 2012 09:38:42 -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: Don Sturek References: 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=982; t=1344530324; x=1345394324; 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]=20LQDN=20(was=22=20tunnels=20 as=20way=20to=20disambiguate=20.local) |Sender:=20 |To:=20Don=20Sturek=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=n9XFxt6Fh3eAnNmsocQ1pQ8Ze86kqeSa0+CtDd4JSlI=; b=rVXLF1vAKbwLj+tkcjtzBG7z+9jL+Ran2zeFpwEB2x/LAQjfW3/Pd7L3yv Ci588p8eABA37sIrq3YUG9Le18fclXF7WzbQV+Ev4k2fvsk7FE3RkdPXRXxX EkrneZWQhEhG07sP+l+8mHqudCrul0pjvrJR5oiSD6fOEKcxX6CgA=; 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: Kerry Lynn , Ted Lemon , homenet@ietf.org, Andrew Sullivan Subject: Re: [homenet] LQDN (was" 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: Thu, 09 Aug 2012 16:38:55 -0000 On 08/09/2012 08:37 AM, Don Sturek wrote: > Hi Michael, > > Your note below strangely proves the counterpoint (ie. "debutante ball" > for mDNS). > > In your sample of 5, I am sure most (maybe all?) have some Apple product > of sometype. If you actually had a packet sniffers in this study, you > will find these devices happily advertising and finding services using > mDNS without anyone typing in anything. > > I don't think it's a counterpoint... i think it pretty much makes my point that even if it's there -- which I suspect you're right about -- people don't know about it. I know for myself, it never occurred to me that a location bar -- or worse in the case of Safari where it's buried in a completely obscure place with an even more obscure name (Bonjour, really??) -- might be used for something other than global url's. The UI from a browser/web standpoint is all wrong, and I suspect that the reasons are deeper than bizarre navigation. Mike From ajs@anvilwalrusden.com Thu Aug 9 14:52: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 1E12121F8610 for ; Thu, 9 Aug 2012 14:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 soX3jzVVbO7S for ; Thu, 9 Aug 2012 14:52:23 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id A2C7E21F8608 for ; Thu, 9 Aug 2012 14:52:23 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id AA6F18A031 for ; Thu, 9 Aug 2012 21:52:21 +0000 (UTC) Date: Thu, 9 Aug 2012 17:52:29 -0400 From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20120809215228.GC81190@mail.yitter.info> References: <201208081709.q78H901G031739@gateway.ipv6.occnc.com> <20120808182226.GC22220@crankycanuck.ca> <20120808185207.GA53113@isc.org> <50236402.3020007@gmail.com> <20120809115125.GC23227@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [homenet] LQDN (was" 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: Thu, 09 Aug 2012 21:52:26 -0000 On Thu, Aug 09, 2012 at 10:17:21AM -0400, Kerry Lynn wrote: > The distinction I was trying to draw was not which protocol is used > for resolution, nor the degree of ambiguity in the name, but that these > names are defined within a local scope (e.g. without recourse to > recursive DNS lookups outside the site boundary). Right, I know that, but what I'm trying to say is that merely drawing _that_ point is not enough for our purposes. To a user, these are all just names. To us when we're trying to make them work together, we have to attend to the differences, because they don't all work the same. Just "doesn't use a recursive DNS outside the boundary" isn't even enough. For instance, what about people who are installing local (sometimes-)recursors in order to get DNSSEC validation on their machines? Someone will tell them, "Install this nifty security feature on your laptop." But because Unbound has just inserted itself in a place that Apple wasn't expecting it, stuff starts working funny some of the time only in some circumstances. (I don't think we really disagree. I'm just very concerned to make sure this fact about protocols doesn't get obscured, because I'm not sure that everyone understands how many different naming infrastructures are really involved in a small network with a lot of ad-hocery going on.) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From lorenzo@google.com Thu Aug 9 23:02:29 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 6117621F85C9 for ; Thu, 9 Aug 2012 23:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.85 X-Spam-Level: X-Spam-Status: No, score=-102.85 tagged_above=-999 required=5 tests=[AWL=0.126, 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 TK94xpKEADRp for ; Thu, 9 Aug 2012 23:02:28 -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 4D9A021F85C6 for ; Thu, 9 Aug 2012 23:02:28 -0700 (PDT) Received: by ggnh4 with SMTP id h4so1361511ggn.31 for ; Thu, 09 Aug 2012 23:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=f85Le3g6Dj1Xx2EKrCCS9+pLiDdsr73Wh3w3TRgWmYE=; b=nDnJ2Rbkh/qmMBrlkVZFMDaNdvipsIErYkBrsbImRuRaT3D2t+PbFTNMKcrg0GeLkh bdpGGMzZJEx4rRlxzGpMv8nYP7cSl8oqzh3Gp0Uu+/RP0hTs7C48X4SxBbmnyYML9ZrG I7yquIzmO0JJFf6TEDCDjy3RfmOhNqXw+lb/aYe25KiSDyAp5g/omxX7U51izPnn+iLf d6fiu5jcibpWO7ztB7OTO3Oxy5PbFSoNeGbVl9BbLIZInRj682HdC/TCjx6N67yoUcyQ 0IqCmWfrCJtv58wWdsPVkb2NNsSRL7R575duIY5zV+I6UJWAoDptrCQDCwBJSZRKCeYv E6ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=f85Le3g6Dj1Xx2EKrCCS9+pLiDdsr73Wh3w3TRgWmYE=; b=bLXU10R24R1pczVmlpt8cYTKE6miT2Mng+XqgaJJB9g9ljAwux/FzXqHaBYA+84YHE 0WFe5VCOFNNsD2arm+3x1WwqZO05c2IjGmcIuwO04ExWeWLdggqTwu2kDqMRjnl/iSg2 NiPH8F5JIMPQB4OR+oGyyubAFj8ZmTRxK8SAJL8dZOM4RijBq6TMh4jd2DfcB1CBAUq3 eDwhMfZWHA9RzDQU2M1td8Y4SShbp3zqZaF34GaAcbJATbMfc1Cd1q1Ix4V0A7wTbaDd as5eEE/q9bKL3JtqOqj9A7GjA5JqfQ0+55Tg34yIBQhOVkzaZgu2SHRgemzAl4mf5EYY UO9A== Received: by 10.42.31.5 with SMTP id x5mr488202icc.40.1344578547572; Thu, 09 Aug 2012 23:02:27 -0700 (PDT) Received: by 10.42.31.5 with SMTP id x5mr488188icc.40.1344578547430; Thu, 09 Aug 2012 23:02:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.224.84 with HTTP; Thu, 9 Aug 2012 23:02:06 -0700 (PDT) In-Reply-To: <5018DD8A.2070900@gmail.com> References: <201208010333.q713XjUb089327@gateway.ipv6.occnc.com> <5018DD8A.2070900@gmail.com> From: Lorenzo Colitti Date: Fri, 10 Aug 2012 15:02:06 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=bcaec5101903b1350004c6e31618 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlpU0kBrN9+f0t+IvDsZK9BQwcEa/JcO5sebrfYT0UmYUQmS3S/rNnADj9CS3MIqcT5Sy2PgzcyaDw4lnPPSahidFy0eYz384eXFm1jdIZx6Cioa04KI3AFiaI1+wFPphdF+XT4hgjf+xLHKw9hDPVRpWdAScjCrsr1Kj0Hud95j1ujsCNx3iXBLW08S52lC4KsrQn4 Cc: Michael Richardson , homenet@ietf.org, curtis@occnc.com 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: Fri, 10 Aug 2012 06:02:29 -0000 --bcaec5101903b1350004c6e31618 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 1, 2012 at 4:40 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Excuse front posting, but... > > > Today there is no DHCP help in avoiding the "please reboot" messages. > > Don't RECONFIGURE (DHCPv6) and FORCERENEW (DHCP) cover this, in theory? > They are unicast, which is a scaling issue in enterprise networks but > presumably not in homenets. > They don't work when the DHCPv6 server has been unplugged for the network or has crashed. --bcaec5101903b1350004c6e31618 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 1, 2012 at 4:40 PM, Brian E Carpente= r <brian.e.carpenter@gmail.com> wrote:
Excuse front posting, but...

> Today there is no DHCP help in avoiding the "please reboot" = messages.

Don't RECONFIGURE (DHCPv6) and FORCERENEW (DHCP) cover this, in t= heory?
They are unicast, which is a scaling issue in enterprise networks but
presumably not in homenets.

They don= 9;t work when the DHCPv6 server has been unplugged for the network or has c= rashed.=A0
--bcaec5101903b1350004c6e31618-- From curtis@occnc.com Sun Aug 12 09:18: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 AC31C21F85D4 for ; Sun, 12 Aug 2012 09:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.159, 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 ILFtHjDOKkCb for ; Sun, 12 Aug 2012 09:18: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 CD5AC21F85AD for ; Sun, 12 Aug 2012 09:18: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 q7CGIcRL065741; Sun, 12 Aug 2012 12:18:38 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208121618.q7CGIcRL065741@gateway.ipv6.occnc.com> To: Brian E Carpenter From: Curtis Villamizar In-reply-to: Your message of "Thu, 09 Aug 2012 08:33:17 BST." <502367BD.3010005@gmail.com> Date: Sun, 12 Aug 2012 12:18:38 -0400 Cc: Kerry Lynn , Michael Richardson , Michael Thomas , curtis@occnc.com, Evan Hunt , "homenet@ietf.org Group" Subject: Re: [homenet] referrals [ 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: Sun, 12 Aug 2012 16:18:44 -0000 In message <502367BD.3010005@gmail.com> Brian E Carpenter writes: > > I get the impression that if NAT didn't exist, then > > draft-carpenter-referral-ps would server no purpose. Is this draft > > entirely motivated by problems caused by NAT? > > I don't think so. There are other causes of disjoint address space, > which existed even before we had NAT or specialised firewalls - > router ACLs for example. Certainly NAT is the major cause today (and > NPTv6 will propagate the problem into IPv6). v4-only and v6-only > islands will probably arise too. > > Regards > Brian Brian, Without NAT there is no good reason to have an island. If you create an island (in IPv6) where none was needed, you get what you deserve. NAT64 and DNS64 support v6-only islands. The tide seems to be turning on v4-only islands. For example, I can fetch and build FreeBSD and fetch all of the ports source for ports I use (>500 ports including libraries, etc) on an IPv6 only host. I'm confident the same would be true of most Linux distributions. Hosts are all dual stack. They may end up roaming to a v4-only (or less likely today v6-only) part of the network. In that case a tunnel to a DS network is needed and all is fine, performance suffering a bit. For example, an enterprise could go v6-only and allow either v4 or v6 tunneling (which is done today for VPN) from roaming employees who end up in a v4 only place. The same enterprise could do NAT64 and DNS64 or could just set up a DS http/https proxy and mail relay at a DS border. I still see no purpose for draft-carpenter-referral-ps if NAT is removed. Curtis > On 08/08/2012 19:39, Curtis Villamizar wrote: > > In message <5022557F.5050105@gmail.com> > > Brian E Carpenter writes: > > > >> On 07/08/2012 20:11, Michael Thomas wrote: > >>> On 08/07/2012 11:46 AM, Kerry Lynn wrote: > >>>> On Mon, Aug 6, 2012 at 9:39 PM, Evan Hunt wrote: > >>>>> Tunnels are okay, but to use them, but has to get the DNS search order > >>>>> and the DNS server list right, and that's walled garden territory. > >>>>> *If* we are going to turn each home into a walled garden, then let's be > >>>>> aware that we are doing that. > >>>> I'm of the opinion that in a "walled garden" scenario, the tunnel > >>>> endpoint may > >>>> be the only resource that needs a global name / address. > >>> Just checking, but we all think that naming is a separate issue > >>> from reachability, right? > >> > >> It certainly is. But see http://tools.ietf.org/html/draft-carpenter-referral-ps > >> especially section 4.2 "FQDNs are not sufficient". > >> > >> Brian > > > > > > Brian, > > > > MIF may be trying to solve the problem the wrong way. Providing a > > mapping of DNS to loopback address has long been used (by routers) to > > provide a stable reachable address. The routing cost to reach that > > loopback interface (which can change many times for an active > > connection) is used to determine which physical interface gets used to > > reach the loopback. For example if one interface is connected to an > > ethernet which gets isolated due to a router failure, the other > > interface is used because routing tells us that one of them is > > unreachable. > > > > Multihoming of course pokes holes in the routing tables and causes > > some routing table bloat. This has always been a problem and IPv6 > > does nothing to improve the situation that existed in IPv4 two decades > > ago with a lot of small providers and large enterprises using dual > > provider multihoming. > > > > If we are concerned with hosts that have multiple interfaces both > > leading to parts of the homenet, that is easily solved. Multihomed > > homenets is a whole different problem, but solvable if redundancy is > > to the same provider. A conditional static route can be advertised > > within the provider, with these routes having limited scope (for > > example using BGP communities). If this practice were to become > > commonplace (I doubt it, no consumer provider has that sort of > > redundancy in the last mile), then the provider would have to limit > > the scope of these more specific routes to a small subset of their own > > topology. > > > > I get the impression that if NAT didn't exist, then > > draft-carpenter-referral-ps would server no purpose. Is this draft > > entirely motivated by problems caused by NAT? > > > > Curtis From brian.e.carpenter@gmail.com Sun Aug 12 10:41: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 1184D21F8617 for ; Sun, 12 Aug 2012 10:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.499 X-Spam-Level: X-Spam-Status: No, score=-101.499 tagged_above=-999 required=5 tests=[AWL=0.192, 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 kBXamKIwn9cv for ; Sun, 12 Aug 2012 10:41:06 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id B3BD321F8505 for ; Sun, 12 Aug 2012 10:41:05 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so2169777wib.13 for ; Sun, 12 Aug 2012 10:41:05 -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=esj2+oiCuee6r1z5z+Ssp/eIzYgXft0eTQekwqWdz9Y=; b=j1fZMg7ib7UcatfLbMkPDi3DzWp6rahpcaIesC46ah7FstwT76II/wyPyfiEuCuTsx mn0BtJZHawHuiKMY37agtz6jZwnbYDwDW6JwpWssjK0Ud/SiTcdPKA97ZTUNerpSiSOj l1J66XSAg0Cb2CPh+6IDG1kBpNthodJE19mSr0dMfG5X5SOX7j1cnj+WZrbH7Uu0QQth RKFGCgs6Ck6G8cu45UqKRMvrQuMRBBw4Rlahg8ntgWMOrb508pUqWVg712mr97msbVM5 YBV06spbKtZjNzyy0hWAMgVKsC/mbyZlNTbquBYaxtb5o0INrM5/slbsouOsJkClAyZQ WUgQ== Received: by 10.216.255.148 with SMTP id j20mr2998222wes.106.1344793264859; Sun, 12 Aug 2012 10:41:04 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-150.as13285.net. [2.102.217.150]) by mx.google.com with ESMTPS id el6sm11674778wib.8.2012.08.12.10.41.02 (version=SSLv3 cipher=OTHER); Sun, 12 Aug 2012 10:41:03 -0700 (PDT) Message-ID: <5027EAAF.5070904@gmail.com> Date: Sun, 12 Aug 2012 18:41:03 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: curtis@occnc.com References: <201208121618.q7CGIcRL065741@gateway.ipv6.occnc.com> In-Reply-To: <201208121618.q7CGIcRL065741@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Evan Hunt , Michael Richardson , Kerry Lynn , Michael Thomas , "homenet@ietf.org Group" Subject: Re: [homenet] referrals [ 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: Sun, 12 Aug 2012 17:41:07 -0000 Two quick comments, and then I suggest we drop this thread here. On 12/08/2012 17:18, Curtis Villamizar wrote: > In message <502367BD.3010005@gmail.com> > Brian E Carpenter writes: > >>> I get the impression that if NAT didn't exist, then >>> draft-carpenter-referral-ps would server no purpose. Is this draft >>> entirely motivated by problems caused by NAT? >> >> I don't think so. There are other causes of disjoint address space, >> which existed even before we had NAT or specialised firewalls - >> router ACLs for example. Certainly NAT is the major cause today (and >> NPTv6 will propagate the problem into IPv6). v4-only and v6-only >> islands will probably arise too. >> >> Regards >> Brian > > > Brian, > > Without NAT there is no good reason to have an island. If you create > an island (in IPv6) where none was needed, you get what you deserve. Nevertheless, people do and will create islands, even very big ones, with global-scope prefixes. Of course, if their *goal* is unreachability, the reference problem doesn't matter. > NAT64 and DNS64 support v6-only islands. The tide seems to be turning > on v4-only islands. For example, I can fetch and build FreeBSD and > fetch all of the ports source for ports I use (>500 ports including > libraries, etc) on an IPv6 only host. I'm confident the same would be > true of most Linux distributions. > > Hosts are all dual stack. They may end up roaming to a v4-only (or > less likely today v6-only) part of the network. In that case a tunnel > to a DS network is needed and all is fine, performance suffering a > bit. For example, an enterprise could go v6-only and allow either v4 > or v6 tunneling (which is done today for VPN) from roaming employees > who end up in a v4 only place. The same enterprise could do NAT64 and > DNS64 or could just set up a DS http/https proxy and mail relay at a > DS border. > > I still see no purpose for draft-carpenter-referral-ps if NAT is > removed. Which isn't, unfortunately, going to happen in our lifetimes. Brian > Curtis > > >> On 08/08/2012 19:39, Curtis Villamizar wrote: >>> In message <5022557F.5050105@gmail.com> >>> Brian E Carpenter writes: >>> >>>> On 07/08/2012 20:11, Michael Thomas wrote: >>>>> On 08/07/2012 11:46 AM, Kerry Lynn wrote: >>>>>> On Mon, Aug 6, 2012 at 9:39 PM, Evan Hunt wrote: >>>>>>> Tunnels are okay, but to use them, but has to get the DNS search order >>>>>>> and the DNS server list right, and that's walled garden territory. >>>>>>> *If* we are going to turn each home into a walled garden, then let's be >>>>>>> aware that we are doing that. >>>>>> I'm of the opinion that in a "walled garden" scenario, the tunnel >>>>>> endpoint may >>>>>> be the only resource that needs a global name / address. >>>>> Just checking, but we all think that naming is a separate issue >>>>> from reachability, right? >>>> >>>> It certainly is. But see http://tools.ietf.org/html/draft-carpenter-referral-ps >>>> especially section 4.2 "FQDNs are not sufficient". >>>> >>>> Brian >>> >>> Brian, >>> >>> MIF may be trying to solve the problem the wrong way. Providing a >>> mapping of DNS to loopback address has long been used (by routers) to >>> provide a stable reachable address. The routing cost to reach that >>> loopback interface (which can change many times for an active >>> connection) is used to determine which physical interface gets used to >>> reach the loopback. For example if one interface is connected to an >>> ethernet which gets isolated due to a router failure, the other >>> interface is used because routing tells us that one of them is >>> unreachable. >>> >>> Multihoming of course pokes holes in the routing tables and causes >>> some routing table bloat. This has always been a problem and IPv6 >>> does nothing to improve the situation that existed in IPv4 two decades >>> ago with a lot of small providers and large enterprises using dual >>> provider multihoming. >>> >>> If we are concerned with hosts that have multiple interfaces both >>> leading to parts of the homenet, that is easily solved. Multihomed >>> homenets is a whole different problem, but solvable if redundancy is >>> to the same provider. A conditional static route can be advertised >>> within the provider, with these routes having limited scope (for >>> example using BGP communities). If this practice were to become >>> commonplace (I doubt it, no consumer provider has that sort of >>> redundancy in the last mile), then the provider would have to limit >>> the scope of these more specific routes to a small subset of their own >>> topology. >>> >>> I get the impression that if NAT didn't exist, then >>> draft-carpenter-referral-ps would server no purpose. Is this draft >>> entirely motivated by problems caused by NAT? >>> >>> Curtis > From curtis@occnc.com Sun Aug 12 12:06: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 F18F821F84E1 for ; Sun, 12 Aug 2012 12:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24] 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 hjc+Uaddb1dR for ; Sun, 12 Aug 2012 12:06:05 -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 57E1321F84DC for ; Sun, 12 Aug 2012 12:06:05 -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 q7CJ5lNX070272; Sun, 12 Aug 2012 15:05:47 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208121905.q7CJ5lNX070272@gateway.ipv6.occnc.com> To: Evan Hunt From: Curtis Villamizar In-reply-to: Your message of "Wed, 08 Aug 2012 18:52:07 -0000." <20120808185207.GA53113@isc.org> Date: Sun, 12 Aug 2012 15:05:47 -0400 Cc: homenet@ietf.org, Andrew Sullivan Subject: Re: [homenet] LQDN (was" 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: Sun, 12 Aug 2012 19:06:06 -0000 In message <20120808185207.GA53113@isc.org> Evan Hunt writes: > > Except, of course, that it's not a "DN" at all: it's not a domain > > name. > > Also not "qualified", as long as we're quibbling. But I do think the > distinction between FQDN and is a useful one > to have terminology for, and "LQDN" does get the job done even though it > doesn't make proper acronymic sense; I suggest we continue using it here > in the short term and plan on switching to a more precisely accurate term > by the time we start producing RFC's. > > I don't have spare cycles to participate in the bikeshedding, but I'll > be happy with anything that agrees with the definition previously > proposed for "LQDN". > > -- > Evan Hunt -- each@isc.org > Internet Systems Consortium, Inc. Even, With your definition, an enterprise with private DNS, (with nameservers that are not referenced by the root in any way) could also be considered to be "not a DN". The LQDN is a domain of local scope, tied to a a local sitelocal. domain that does not exist or may be different outside the site local scope. An enterprise hidden domain is a domain of local scope tied to a local domainname that does exists outside and is known to be different outside of the site local scope. So the difference is: sitelocal may not exist everywhere and if it does it is different - an enterprise hidden domain is known to exist everywhere and is known to be different elsewhere. LQDN makes a distinction, separating it from FQDN. LQDN has local scope. FQDN has global scope. The distinction is useful. BTW- If you argued that mDNS was not a form of DNS, I would agree. Curtis From curtis@occnc.com Sun Aug 12 12: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 DB79121F8606 for ; Sun, 12 Aug 2012 12:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24] 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 cDJTKOq78gxL for ; Sun, 12 Aug 2012 12:27:02 -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 8A8E121F8604 for ; Sun, 12 Aug 2012 12:26: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 q7CJQbbr070463; Sun, 12 Aug 2012 15:26:37 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208121926.q7CJQbbr070463@gateway.ipv6.occnc.com> To: Brian E Carpenter From: Curtis Villamizar In-reply-to: Your message of "Thu, 09 Aug 2012 08:17:22 BST." <50236402.3020007@gmail.com> Date: Sun, 12 Aug 2012 15:26:37 -0400 Cc: Evan Hunt , homenet@ietf.org, Andrew Sullivan Subject: Re: [homenet] LQDN (was" 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: Sun, 12 Aug 2012 19:27:03 -0000 In message <50236402.3020007@gmail.com> Brian E Carpenter writes: > On 08/08/2012 19:52, Evan Hunt wrote: > >> Except, of course, that it's not a "DN" at all: it's not a domain > >> name. > > > > Also not "qualified", as long as we're quibbling. But I do think the > > distinction between FQDN and is a useful one > > to have terminology for, and "LQDN" does get the job done even though it > > doesn't make proper acronymic sense; I suggest we continue using it here > > in the short term and plan on switching to a more precisely accurate term > > by the time we start producing RFC's. > > > > I don't have spare cycles to participate in the bikeshedding, but I'll > > be happy with anything that agrees with the definition previously > > proposed for "LQDN". > > As far as I can see there are still two kinds of LQDN: > > ALQDN - ambiguous, or potentially ambiguous, names (like printer.local) > ULQDN - unambiguous, or almost certainly unambiguous, names (like > printer..sitelocal) > > I will be unhappy if ALQDNs are allowed except as legacy. > > Brian Brian, My prior suggestion is that we have both types of LQDN and not just temporarily. printer.{local|sitelocal} is an ALQDN printer..ulalocal is a ULQDN printer. is a FQDN For backward compatibility and to have a constant and easy to type identifier, printer.{local|sitelocal} can be a CNAME where: If an FQDN for printer exists: ALQDN CNAME points to the FQDN printer.{local|sitelocal} is a CNAME for printer. rDNS points to the FQDN points to printer. If an FQDN for print does not exist: ALQDN CNAME points to the ULQDN printer.{local|sitelocal} is a CNAME for printer..ulalocal rDNS points to the ULQDN points to printer..ulalocal The application can detect that the mapping of the ALQDN has changed in three ways. First the CNAME mapping has changed. Second the address that is returned has changed. Third the rDNS has changed. If a domain name is later acquired, then the application can detect this on later use of the ALQDN in two ways. First the CNAME mapping has changed. Second the rDNS has changed. Note that the final forward mapping to an address has not changed in this case. If a domain name appears, but the address remains the same, the mapping to FQDN can silently replace the mapping to ULQDN (retaining the former). If the final address associated with a ALQDN changes, then it may be that the site local scope has changed. If so all ALQDN that map to ULQDN can be retained but the user must be warned if specifying a ALQDN. If the ALQDN had previously mapped to a ULQDN or FQDN that mapped to a GUA, then the user can be given the option to try it. If the ALQDN maps to a FQDN, the mapping can be verified. If the ALQDN maps to a ULQDN, then the mapping cannot be verified but can be tried. This is what I suggested before, just reworded and using your ALQDN vs ULQDN distinction. Curtis From curtis@occnc.com Sun Aug 12 12:34: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 0D43D21F865E for ; Sun, 12 Aug 2012 12:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.172, 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 6AklKmU4GylH for ; Sun, 12 Aug 2012 12:34:20 -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 2D3ED21F863F for ; Sun, 12 Aug 2012 12:34:20 -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 q7CJYIZC070539; Sun, 12 Aug 2012 15:34:18 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208121934.q7CJYIZC070539@gateway.ipv6.occnc.com> To: Brian E Carpenter From: Curtis Villamizar In-reply-to: Your message of "Thu, 09 Aug 2012 11:01:30 BST." <50238A7A.9090002@gmail.com> Date: Sun, 12 Aug 2012 15:34:18 -0400 Cc: homenet@ietf.org Subject: Re: [homenet] Tunnels to 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: Sun, 12 Aug 2012 19:34:21 -0000 In message <50238A7A.9090002@gmail.com> Brian E Carpenter writes: > All this talk about tunnels and names made me think that people > might be interested in the Signpost project, mainly based at > the Computer Lab in Cambridge where I am currently a visitor. > I think this project is a proof of concept for ideas being > discussed here. > > http://conferences.sigcomm.org/sigcomm/2012/paper/sigcomm/p83.pdf > > (10MB file) http://conferences.npl.co.uk/satin/presentations/satin2012slides-Madhavapeddy.pdf > > Regards > Brian Carpenter Remove NAT and the work has no purpose. Curtis From mcr+ietf@sandelman.ca Sun Aug 12 14:09: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 0174021F851B for ; Sun, 12 Aug 2012 14:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.256, 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 RAfed5cRaSRY for ; Sun, 12 Aug 2012 14:09:54 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 20C1C21F8666 for ; Sun, 12 Aug 2012 14:09:54 -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 E39EF20177; Sun, 12 Aug 2012 17:22:53 -0400 (EDT) From: Michael Richardson To: curtis@occnc.com In-Reply-To: <201208121934.q7CJYIZC070539@gateway.ipv6.occnc.com> References: <201208121934.q7CJYIZC070539@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 Subject: Re: [homenet] Tunnels to 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: Sun, 12 Aug 2012 21:09:55 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Curtis" =3D=3D Curtis Villamizar writes: >> All this talk about tunnels and names made me think that people >> might be interested in the Signpost project, mainly based at >> the Computer Lab in Cambridge where I am currently a visitor. >> I think this project is a proof of concept for ideas being >> discussed here. >>=20 >> http://conferences.sigcomm.org/sigcomm/2012/paper/sigcomm/p83.pdf >>=20 >> (10MB file) http://conferences.npl.co.uk/satin/presentations/satin20= 12slides-Madhavapeddy.pdf >>=20 >> Regards >> Brian Carpenter Curtis> Remove NAT and the work has no purpose. I don't quite agree. The external rendezvous is *FORCED* by NAT. The need for a rendezvous goes away with IPv6 end to end, assuming that security policies allow.=20=20 But, if we assume that end users should never type IPv6 addresses, then a rendezvous (which might now, be hosted by one or more devices at the home, rather than in the cloud!!!) is something that very much facilitates use by regular users. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUCgbl4qHRg3pndX9AQIEDAP/XYDx4LwG4bIkut/GlM55RSVbyGbhYF4c Bb1bEDNSf4HuXUVcg2fLbgFCBOUOF3WNAAiKA5+KTwzROfvqLVFTIN8VMk87GF1D rD05s1sp226RkSsTy4JrAE129O8NvHzBbhZHMHJVYue00EYAhr/YlvQyg4clmXde 3nGbPXYANyo= =/m4h -----END PGP SIGNATURE----- --=-=-=-- From curtis@occnc.com Sun Aug 12 15:08: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 2552321F869E for ; Sun, 12 Aug 2012 15:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.169, 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 25-iH3b0r24J for ; Sun, 12 Aug 2012 15:08: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 4E45821F869D for ; Sun, 12 Aug 2012 15:08: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 q7CM7oUh073868; Sun, 12 Aug 2012 18:07:50 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208122207.q7CM7oUh073868@gateway.ipv6.occnc.com> To: Michael Richardson From: Curtis Villamizar In-reply-to: Your message of "Sun, 12 Aug 2012 17:09:43 EDT." <11199.1344805783@obiwan.sandelman.ca> Date: Sun, 12 Aug 2012 18:07:49 -0400 Cc: homenet@ietf.org, curtis@occnc.com Subject: Re: [homenet] Tunnels to 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: Sun, 12 Aug 2012 22:08:15 -0000 In message <11199.1344805783@obiwan.sandelman.ca> Michael Richardson writes: > >>>>> "Curtis" =3D=3D Curtis Villamizar writes: > >> All this talk about tunnels and names made me think that people > >> might be interested in the Signpost project, mainly based at > >> the Computer Lab in Cambridge where I am currently a visitor. > >> I think this project is a proof of concept for ideas being > >> discussed here. > >>=20 > >> http://conferences.sigcomm.org/sigcomm/2012/paper/sigcomm/p83.pdf > >>=20 > >> (10MB file) http://conferences.npl.co.uk/satin/presentations/satin20= > 12slides-Madhavapeddy.pdf > >>=20 > >> Regards > >> Brian Carpenter > > Curtis> Remove NAT and the work has no purpose. > > I don't quite agree. > The external rendezvous is *FORCED* by NAT. > > The need for a rendezvous goes away with IPv6 end to end, assuming that > security policies allow.=20=20 > > But, if we assume that end users should never type IPv6 addresses, then > a rendezvous (which might now, be hosted by one or more devices at the > home, rather than in the cloud!!!) is something that very much > facilitates use by regular users. > > Michael Richardson , Sandelman Software Works=20 You are assuming that DNS would never be available to the home when you state that "But, if we assume that end users should never type IPv6 addresses". This is technically solvable with IPv6, no NAT, and DNS. If some users end up typing IPv6 addresses for lack of DNS cooperation from their provider, they may consider switching providers. Even without cooperation from the provider, a device can have the resolver pointed at the home DNS server as a means of rendezvous if you want a rendezvous in the home. Curtis From richard.mortier@gmail.com Mon Aug 13 01: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 B2D3821F86E1 for ; Mon, 13 Aug 2012 01:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 0UdyyK9V0Yqd for ; Mon, 13 Aug 2012 01:37:10 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D3C7421F86E2 for ; Mon, 13 Aug 2012 01:37:09 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3514707vbb.31 for ; Mon, 13 Aug 2012 01:37:09 -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=UppeD1iaaSnO5G3KbCCzrIZwXceWwNZ+mghln030MBo=; b=Iek8JbQehwkylUQnandT5+ibQU+BwjQYx+6cQA4hh5wlbs1BmQ9bFXLVoMZ+AYHG9f VtRVZZFa9bjzofh8K3hvXO8mkN2eNlrbEzOlsq4iyOmSujAPHmCXz+HJo/tKjqg1fRVz cIH8qJh6raaMbnH85u14p5Y0CoVnCA0yxfoiOL3AEbOZqPoRWHfJlbNJd8m4SGj7cTO0 AAFxjoSZQ5UqrnsxUlfwvQJRMIPrRp6zDNpVe8gOPe46oVCBcYp9RPSo5M07TitEpXoC ls0DMblUy3oHqsgaVa3V7/qLAaSqbhinVHnY8377yUKXwkwL7vWg85nlxv19UJxV2LDu n0SA== MIME-Version: 1.0 Received: by 10.58.144.138 with SMTP id sm10mr8885541veb.31.1344847029312; Mon, 13 Aug 2012 01:37:09 -0700 (PDT) Sender: richard.mortier@gmail.com Received: by 10.58.182.40 with HTTP; Mon, 13 Aug 2012 01:37:09 -0700 (PDT) In-Reply-To: <201208122207.q7CM7oUh073868@gateway.ipv6.occnc.com> References: <11199.1344805783@obiwan.sandelman.ca> <201208122207.q7CM7oUh073868@gateway.ipv6.occnc.com> Date: Mon, 13 Aug 2012 09:37:09 +0100 X-Google-Sender-Auth: noKQrS3AAO9gbFmvY0mr2dIIc_Y Message-ID: From: Richard Mortier To: curtis@occnc.com Content-Type: text/plain; charset=ISO-8859-1 Cc: Michael Richardson , homenet@ietf.org Subject: Re: [homenet] Tunnels to 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, 13 Aug 2012 08:38:06 -0000 hi all; i'm coming into this discussion partway through, so apologies if i miss/repeat anything. i'm one of the collaborators on signpost (the non-cambridge collaborator in fact :) On 12 August 2012 23:07, Curtis Villamizar wrote: > > In message <11199.1344805783@obiwan.sandelman.ca> > Michael Richardson writes: > >> >>>>> "Curtis" =3D=3D Curtis Villamizar writes: .... >> Curtis> Remove NAT and the work has no purpose. >> >> I don't quite agree. >> The external rendezvous is *FORCED* by NAT. >> >> The need for a rendezvous goes away with IPv6 end to end, assuming that >> security policies allow. >> >> But, if we assume that end users should never type IPv6 addresses, then >> a rendezvous (which might now, be hosted by one or more devices at the >> home, rather than in the cloud!!!) is something that very much >> facilitates use by regular users. yes- "regular users" is precisely the constituency we're aiming for :) i guess we're also assuming that the move to ipv6 will continue to happen for some time yet, though i think that some of the other motivations for signposts will persist even in a fully ipv6 world (see below). > You are assuming that DNS would never be available to the home when > you state that "But, if we assume that end users should never type > IPv6 addresses". > > This is technically solvable with IPv6, no NAT, and DNS. If some > users end up typing IPv6 addresses for lack of DNS cooperation from > their provider, they may consider switching providers. part of -- perhaps the main part of -- the motivation for signposts is making things easy enough for the regular users who don't know what any of that means. > Even without cooperation from the provider, a device can have the > resolver pointed at the home DNS server as a means of rendezvous if > you want a rendezvous in the home. i should also point out that we thought there were more motivations/uses for signposts that simply nat punching, or even security acl punching, etc. though i'll admit some of these got rather compressed in the 2 pager brian pointed to - that's the abstract for the demo we should have tomorrow at sigcomm (for anyone who's here in helsinki! :) as we don't have a better, more detailed paper published yet. i guess the other two main motivations from our perspective were: better support for mobility; and secure identities for users. (both may be a bit tangential to the purpose of this list though.) by the former i mean: as you move around between home, work, town, public transport, etc you want to be using the best available path, or paths (fsvo "best") -- the way signposts uses dns should help ensure that your device selects among available paths based on metrics like throughput, latency, jitter as you move between wifi, 3G, or whatever else network. the motivating scenario here was when travelling with laptop and mobile phone or tablet which may well end up being visible to each other on the same (third party) network. we've also thought a bit about using this to support interesting uses of tcp multipath. by the latter i mean: using dnssec as a way to bootstrap secure internet identities for individuals. being able to authenticate the person (as represented by a dnssec domain entry) at the other end of the connection (whether the initiator or the target) seems like it would be useful. and dnssec seems a more secure basis for this than relying on plain old email. ideally we would also then use the secret material that is used to register in dnssec to automatically derive other secrets for ssh etc, but we're still working out the details of that. -- Richard Mortier mort@cantab.net From mcr+ietf@sandelman.ca Mon Aug 13 10:04: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 8DCD021F86C3 for ; Mon, 13 Aug 2012 10:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.235, 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 xm3oEr9ZUwLv for ; Mon, 13 Aug 2012 10:04:28 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id B433F21F86D0 for ; Mon, 13 Aug 2012 10:04: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 C3F7D20168; Mon, 13 Aug 2012 13:17:23 -0400 (EDT) From: Michael Richardson To: Richard Mortier In-Reply-To: References: <11199.1344805783@obiwan.sandelman.ca> <201208122207.q7CM7oUh073868@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, curtis@occnc.com Subject: Re: [homenet] Tunnels to 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, 13 Aug 2012 17:04:28 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable One of the things that I was thinking about years ago when DNSSEC was young, and mDNS was first talked about was using mDNS to exchange DNSSEC chains for FQDNs. So, you and I, sitting in a meadow (I always think about Bloom County... in this context) change use mDNS to find each other, and then, I can give you an additional area like this: . 172800 IN DNSKEY 256 3 8 AwEA... gov. 86400 IN DNSKEY 256 3 7 AQO+tGAvoICmi... whitehouse.gov. 7200 IN DNSKEY 257 3 7 Av//sEnVpZw40... billthecat.whitehouse.gov. 60 IN DNSKEY 257 3 7 FOOBAR which would permit you to validate who I am, even though neither of have connectivity at the time.. I would cache my DNSSEC path, and of course, we each would already have the root DNSSEC key. (no different than how PKIX works...) I see signposts as being additional local trust anchors that can be used. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUCkzioqHRg3pndX9AQIyIAP7B74uFFvVcgH5c8BGcn2I5KAyuvDkXjdY BBoAmDHWXPt3w8j2IXmK3Od7ALzH3ApODe4XdJHpwNLDeqbbPn+u/4sGLqmgmiyM KfkNzQx1bTOc1aOvxsf/o/elgeHrKpdGYSobVvBDlrGCNv5t9Humns16/rFK3SRH m1Al5C9ADFM= =8xzm -----END PGP SIGNATURE----- --=-=-=-- From richard.mortier@gmail.com Wed Aug 15 04:07: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 5B5D921F871C for ; Wed, 15 Aug 2012 04:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 EE8n3yE-dD8p for ; Wed, 15 Aug 2012 04:07:43 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA6421F8712 for ; Wed, 15 Aug 2012 04:07:40 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1584176vcb.31 for ; Wed, 15 Aug 2012 04:07:40 -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=44I55No/rgrUGxGL0D5QaZRVCX7SJ1p2AxStDpA3UZk=; b=J/RAdcOH8RreeHJ+Byj4dV3xvyeNKEetTkPTEpc6pfFwXq3f89fdEpkSq/cwbuGwi4 vf1J3eCfX2UsfDqC9zV3DX4T+gZHGSujX4X3lk4I6uvZmkVAnXqdKBoHFf8QixX0upfN Tl9tnutm4Bawo2bzKi71dLGWVB43NWPutLx4phGYAl37g/fKDkKv8Qpt+f5W2flOPGfO 7ncUfAdtLBGUKaqnJJZ6j357XuEbjmWLVwRj6Myj2ZFHqYkVq3+r/8DgSdEa4VFLKvkY CRrO+nj1uQz8cxeHIl6AMPsBildifX5n3ntgyIQlcq3Vf7NPZ+d1m7c2X8tTaLFlKqJe mHXw== MIME-Version: 1.0 Received: by 10.220.223.201 with SMTP id il9mr12624480vcb.64.1345028860174; Wed, 15 Aug 2012 04:07:40 -0700 (PDT) Sender: richard.mortier@gmail.com Received: by 10.58.182.40 with HTTP; Wed, 15 Aug 2012 04:07:39 -0700 (PDT) In-Reply-To: <7916.1344877450@obiwan.sandelman.ca> References: <11199.1344805783@obiwan.sandelman.ca> <201208122207.q7CM7oUh073868@gateway.ipv6.occnc.com> <7916.1344877450@obiwan.sandelman.ca> Date: Wed, 15 Aug 2012 14:07:39 +0300 X-Google-Sender-Auth: EEwQVqoC1KnEVNvvQTJ9ZbWt1XE Message-ID: From: Richard Mortier To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Cc: homenet@ietf.org, curtis@occnc.com Subject: Re: [homenet] Tunnels to 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: Wed, 15 Aug 2012 11:07:44 -0000 On 13 August 2012 20:04, Michael Richardson wrote: > ... > which would permit you to validate who I am, even though neither of > have connectivity at the time.. I would cache my DNSSEC path, and of > course, we each would already have the root DNSSEC key. (no different > than how PKIX works...) > > I see signposts as being additional local trust anchors that can be > used. yes, i think we would too :) specifically: in the "common case" we'd envisage that each person would have at least one publicly visible signpost, probably hosted in the cloud (whether or not operated directly by them, or through some "signpost-as-a-service" provider) unless they have suitable local resources. but we have certainly discussed supporting suitable state replication/caching among signpost instances so that any locally-connected collection of signpost-enabled clients can do all of this without recourse to the public internet (eg., for cases where you still want to be able to interconnect your own devices and you're travelling, or you're at home your broadband uplink has gone down). -- Richard Mortier mort@cantab.net From curtis@occnc.com Wed Aug 15 11:32:29 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 E670821F86DA for ; Wed, 15 Aug 2012 11:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.162, 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 TJnc7nvmhFSU for ; Wed, 15 Aug 2012 11:32:29 -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 CC8E621F86CB for ; Wed, 15 Aug 2012 11:32:28 -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 q7FIUkrP033557; Wed, 15 Aug 2012 14:30:46 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208151830.q7FIUkrP033557@gateway.ipv6.occnc.com> To: Richard Mortier From: Curtis Villamizar In-reply-to: Your message of "Wed, 15 Aug 2012 14:07:39 +0300." Date: Wed, 15 Aug 2012 14:30:46 -0400 Cc: Michael Richardson , homenet@ietf.org, curtis@occnc.com Subject: Re: [homenet] Tunnels to 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, 15 Aug 2012 18:32:30 -0000 In message Richard Mortier writes: > On 13 August 2012 20:04, Michael Richardson wrote: > > > ... > > which would permit you to validate who I am, even though neither of > > have connectivity at the time.. I would cache my DNSSEC path, and of > > course, we each would already have the root DNSSEC key. (no different > > than how PKIX works...) > > > > I see signposts as being additional local trust anchors that can be > > used. > > yes, i think we would too :) You did trim out the example, where due to the trust, whitehouse.gov and billthecat.whitehouse.gov are all DNSSEC signed domains. I suppose that is why the smiley. > specifically: in the "common case" we'd envisage that each person > would have at least one publicly visible signpost, probably hosted in > the cloud (whether or not operated directly by them, or through some > "signpost-as-a-service" provider) unless they have suitable local > resources. ... and the difference between signed untrustworthy source of information and an unsigned untrustworthy is ... what? This is putting yet another service in the cloud that need not be there, though global DNS could be considered "in the cloud" as commonly practiced for the home user. What we are trying to accomplish is getting a local name service that is somehow authoritative for the local site, and optionally can be made global. Putting the mapping to the local printer in the cloud would break printing if the cloud were not accessible (hopefully temporarily) but for some devices, like home alarms, utility metering, the fridge, ... the kitchen sink, with low power wireless, the cloud might often not be there. > but we have certainly discussed supporting suitable state > replication/caching among signpost instances so that any > locally-connected collection of signpost-enabled clients can do all of > this without recourse to the public internet (eg., for cases where you > still want to be able to interconnect your own devices and you're > travelling, or you're at home your broadband uplink has gone down). Please give us a good reason to reinvent the wheel. I don't see one. You need to say what DNS can't do, possibly with some extension. that signpost offers. > Richard Mortier > mort@cantab.net Regards, Curtis From wouter.cloetens@softathome.com Fri Aug 17 07:49: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 BB35A21F8607 for ; Fri, 17 Aug 2012 07:49:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXYc95nm6R2m for ; Fri, 17 Aug 2012 07:49:16 -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 0F52321F8606 for ; Fri, 17 Aug 2012 07:49:12 -0700 (PDT) Received: from [2001:470:d39b:1f80:67d:7bff:fe3a:49af] by e2big.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1T2NrK-0004vo-5l for homenet@ietf.org; Fri, 17 Aug 2012 16:49:10 +0200 Message-ID: <502E59E2.5040001@softathome.com> Date: Fri, 17 Aug 2012 16:49:06 +0200 From: Wouter Cloetens User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6 MIME-Version: 1.0 To: homenet@ietf.org References: <201208081848.q78ImtCZ033624@gateway.ipv6.occnc.com> In-Reply-To: <201208081848.q78ImtCZ033624@gateway.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] naming, what's the problem? 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, 17 Aug 2012 14:49:16 -0000 On 08/08/12 20:48, Curtis Villamizar wrote: > One solution, the one you are describing is where the CPE runs DHCP > only and uses the dyndns protocol to make addresses available > globally. > > Another solution is have the CPE run both DHCP and bind (or equiv) and > run dyndns. The provider could delegate and secondary a subdomain of > the provider with no need to contact a domain registry. Yes, that is exactly the 13 months old solution, described in these drafts: http://www.ietf.org/id/draft-mglt-homenet-naming-delegation-00.txt http://www.ietf.org/id/draft-mglt-homenet-front-end-naming-delegation-00.txt > When a domain registrar is needed is only when the homenet needs or > wants (maybe for ego reasons) a domain residing in a TLD (such as .com > or .org) and would not accept a subdomain from the provider. For > example the homenet user wants foo.com and would not accept something > of the form foo.site.provider.com, which would be less permanet (the > delegation is lost if switching providers). For security reasons documented in one of the drafts above, it should be disabled by default. A user-defined configuration could open the DNS port to the world, and allow additional domains. bfn, Wouter From curtis@occnc.com Fri Aug 17 20:05: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 47BE621E805A for ; Fri, 17 Aug 2012 20:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WZElbDlpUeB for ; Fri, 17 Aug 2012 20:05:22 -0700 (PDT) Received: from gateway2.ipv6.occnc.com (gateway2.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:145]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA0B21E8048 for ; Fri, 17 Aug 2012 20:05:18 -0700 (PDT) Received: from harbor2.ipv6.occnc.com (harbor2.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:404]) (authenticated bits=0) by gateway2.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q7I35GDL012358; Fri, 17 Aug 2012 23:05:17 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208180305.q7I35GDL012358@gateway2.ipv6.occnc.com> To: Wouter Cloetens From: Curtis Villamizar In-reply-to: Your message of "Fri, 17 Aug 2012 16:49:06 +0200." <502E59E2.5040001@softathome.com> Date: Fri, 17 Aug 2012 23:05:16 -0400 Cc: homenet@ietf.org Subject: Re: [homenet] naming, what's the problem? 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: Sat, 18 Aug 2012 03:05:23 -0000 In message <502E59E2.5040001@softathome.com> Wouter Cloetens writes: > On 08/08/12 20:48, Curtis Villamizar wrote: > > One solution, the one you are describing is where the CPE runs DHCP > > only and uses the dyndns protocol to make addresses available > > globally. > > > > Another solution is have the CPE run both DHCP and bind (or equiv) and > > run dyndns. The provider could delegate and secondary a subdomain of > > the provider with no need to contact a domain registry. > > Yes, that is exactly the 13 months old solution, described in these drafts: > > http://www.ietf.org/id/draft-mglt-homenet-naming-delegation-00.txt > http://www.ietf.org/id/draft-mglt-homenet-front-end-naming-delegation-00.txt Thank you for pointing these out. I will take a look at them. > > When a domain registrar is needed is only when the homenet needs or > > wants (maybe for ego reasons) a domain residing in a TLD (such as .com > > or .org) and would not accept a subdomain from the provider. For > > example the homenet user wants foo.com and would not accept something > > of the form foo.site.provider.com, which would be less permanet (the > > delegation is lost if switching providers). > > For security reasons documented in one of the drafts above, it should be > disabled by default. A user-defined configuration could open the DNS > port to the world, and allow additional domains. I think you missed the point. This is not a security issue. The homenet user that wants foo.com needs to go to a domain registrar. The provider can only give out foo.site.provider.com but if this is for true home use and not business use, then that should be fine. The point is to be able to reach the home without typing in an IPv6 address. The same type of user happily accepts an email address of the form @provider.com where namestring often has to contain numbers to keep it unique because all first names and most last names are already taken at the provider. It would be perfectly fine for the provider to offer .site.provider.com as a domain delegation if namestring has already been assigned to the home as an account ID and email address. If the user want a domain name in a TLD, they need a domain name registrar. > bfn, Wouter > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet Curtis From wouter.cloetens@softathome.com Sat Aug 18 09:11: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 2C31E21F8499 for ; Sat, 18 Aug 2012 09:11: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1x8c44MxvdR for ; Sat, 18 Aug 2012 09:11:35 -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 A47AA21F8498 for ; Sat, 18 Aug 2012 09:11:34 -0700 (PDT) Received: from d51536abe.access.telenet.be ([81.83.106.190]) by e2big.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1T2lcc-000640-18 for homenet@ietf.org; Sat, 18 Aug 2012 18:11:34 +0200 Message-ID: <502FBEB4.40907@softathome.com> Date: Sat, 18 Aug 2012 18:11:32 +0200 From: Wouter Cloetens User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6 MIME-Version: 1.0 To: homenet@ietf.org References: <201208180305.q7I35GDL012358@gateway2.ipv6.occnc.com> In-Reply-To: <201208180305.q7I35GDL012358@gateway2.ipv6.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] naming, what's the problem? 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: Sat, 18 Aug 2012 16:11:52 -0000 DOn 18/08/12 05:05, Curtis Villamizar wrote: >>> When a domain registrar is needed is only when the homenet needs or >>> wants (maybe for ego reasons) a domain residing in a TLD (such as .com >>> or .org) and would not accept a subdomain from the provider. For >>> example the homenet user wants foo.com and would not accept something >>> of the form foo.site.provider.com, which would be less permanet (the >>> delegation is lost if switching providers). >> >> For security reasons documented in one of the drafts above, it should be >> disabled by default. A user-defined configuration could open the DNS >> port to the world, and allow additional domains. > > I think you missed the point. This is not a security issue. Yes, I got your point, but I'm adding an implication. The draft explains that this requires opening up the gateway's DNS port to the world, rather than only to the trusted DNS infrastructure of the provider. That has some security issues. Also, only the provider can give you reverse DNS. Whereas the provider-delegated domain can be a fully automatic feature, setting up a personal domain requires the user to do some work. Registering a domain (could be made simple, from a gateway's web UI), pointing a nameserver at his gateway (could be automated, DynDNS-style). It is only logical that a user should also have to disable the secure default source address restriction of DNS requests. Nonetheless, it is a perfectly valid use case; the IPv6 functional equivalent of widely used DynDNS in the IPv4 world today. And, of course, not every operator may implement the automated domain delegation. bfn, Wouter From anil@recoil.org Sat Aug 18 10:46: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 8FB8221F8493 for ; Sat, 18 Aug 2012 10:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X99uVv4dasGe for ; Sat, 18 Aug 2012 10:46:11 -0700 (PDT) Received: from dark.recoil.org (recoil.dh.bytemark.co.uk [89.16.177.154]) by ietfa.amsl.com (Postfix) with SMTP id B372121F8491 for ; Sat, 18 Aug 2012 10:46:10 -0700 (PDT) Received: (qmail 27447 invoked by uid 634); 18 Aug 2012 17:46:06 -0000 X-Spam-Check-By: dark.recoil.org Received: from c-69-181-69-199.hsd1.ca.comcast.net (HELO [192.168.1.3]) (69.181.69.199) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Sat, 18 Aug 2012 18:46:06 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Anil Madhavapeddy In-Reply-To: <201208151830.q7FIUkrP033557@gateway.ipv6.occnc.com> Date: Sat, 18 Aug 2012 10:46:02 -0700 Content-Transfer-Encoding: 7bit Message-Id: <02564EA7-5FEF-4B23-AED1-A64F408893F7@recoil.org> References: <201208151830.q7FIUkrP033557@gateway.ipv6.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1485) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: Michael Richardson , homenet@ietf.org, Richard Mortier Subject: Re: [homenet] Tunnels to 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: Sat, 18 Aug 2012 17:46:11 -0000 On 15 Aug 2012, at 11:30, Curtis Villamizar wrote: > > ... and the difference between signed untrustworthy source of > information and an unsigned untrustworthy is ... what? > > This is putting yet another service in the cloud that need not be > there, though global DNS could be considered "in the cloud" as > commonly practiced for the home user. > > What we are trying to accomplish is getting a local name service that > is somehow authoritative for the local site, and optionally can be > made global. > > Putting the mapping to the local printer in the cloud would break > printing if the cloud were not accessible (hopefully temporarily) but > for some devices, like home alarms, utility metering, the fridge, > ... the kitchen sink, with low power wireless, the cloud might often > not be there. > >> but we have certainly discussed supporting suitable state >> replication/caching among signpost instances so that any >> locally-connected collection of signpost-enabled clients can do all of >> this without recourse to the public internet (eg., for cases where you >> still want to be able to interconnect your own devices and you're >> travelling, or you're at home your broadband uplink has gone down). > > Please give us a good reason to reinvent the wheel. I don't see one. > You need to say what DNS can't do, possibly with some extension. that > signpost offers. I think you're missing the point. Signposts *is* a DNS(SEC)-based implementation and not trying to invent a new protocol, but has a very different focus from conventional DNS servers (personal tailored DNS for the individual). The server currently distributes presence information out-of-band to the other authoritative server for that domain (using the tunnels it has setup between devices). This means that you can have an authoritative server for your domain within your home network, which continues to function offline if disconnected from the wider Internet. When reconnected, it will resync with other nodes (in a loosely consistent way, which may result in a few tunnels being non-optimal, but only briefly). This'll be much more obvious as soon as we release some working code, which we're furiously hacking on at the moment. -anil From curtis@occnc.com Tue Aug 21 07:03: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 6FD7C21F8652 for ; Tue, 21 Aug 2012 07:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+B3fA1xgdOt for ; Tue, 21 Aug 2012 07:03:31 -0700 (PDT) Received: from gateway2.orleans.occnc.com (gateway2.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:145]) by ietfa.amsl.com (Postfix) with ESMTP id 330E521F8621 for ; Tue, 21 Aug 2012 07:03:31 -0700 (PDT) Received: from harbor2.ipv6.occnc.com (harbor2.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:404]) (authenticated bits=0) by gateway2.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q7LE3TWa039352; Tue, 21 Aug 2012 10:03:30 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201208211403.q7LE3TWa039352@gateway2.orleans.occnc.com> To: Wouter Cloetens From: Curtis Villamizar In-reply-to: Your message of "Sat, 18 Aug 2012 18:11:32 +0200." <502FBEB4.40907@softathome.com> Date: Tue, 21 Aug 2012 10:03:29 -0400 Cc: homenet@ietf.org Subject: Re: [homenet] naming, what's the problem? 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, 21 Aug 2012 14:03:32 -0000 In message <502FBEB4.40907@softathome.com> Wouter Cloetens writes: > DOn 18/08/12 05:05, Curtis Villamizar wrote: > >>> When a domain registrar is needed is only when the homenet needs or > >>> wants (maybe for ego reasons) a domain residing in a TLD (such as .com > >>> or .org) and would not accept a subdomain from the provider. For > >>> example the homenet user wants foo.com and would not accept something > >>> of the form foo.site.provider.com, which would be less permanet (the > >>> delegation is lost if switching providers). > >> > >> For security reasons documented in one of the drafts above, it should be > >> disabled by default. A user-defined configuration could open the DNS > >> port to the world, and allow additional domains. > > > > I think you missed the point. This is not a security issue. > > Yes, I got your point, but I'm adding an implication. > The draft explains that this requires opening up the gateway's DNS port > to the world, rather than only to the trusted DNS infrastructure of the > provider. That has some security issues. There is the option for split horzon, but I don't think it should be the default. Having a GUA and not having a DNS name is not a *security* feature. More like paranoia IMHO. Security by obscurity has never worked. > Also, only the provider can give you reverse DNS. The provider can delegate reverse DNS. That is a problem with uncooperative providers. Otherwise accurate rDNS is site local only, but at least it is accurate at the site. > Whereas the provider-delegated domain can be a fully automatic feature, > setting up a personal domain requires the user to do some work. > Registering a domain (could be made simple, from a gateway's web UI), > pointing a nameserver at his gateway (could be automated, DynDNS-style). > It is only logical that a user should also have to disable the secure > default source address restriction of DNS requests. If the user wants no work, the provider delegated subdomain can be reduced to zero work on the part of the customer, and a one time mechanical configuration on the part of the provider at the time that service is initiated (when new customer buys service for first time). Working with a registrar could be made simpler by the registrar, but most homes will never need a *vanity* domain in a TLD. > Nonetheless, it is a perfectly valid use case; the IPv6 functional > equivalent of widely used DynDNS in the IPv4 world today. And, of > course, not every operator may implement the automated domain delegation. It seems that today, getting operators to do anything is difficult. Too bad we have so little competition in Internet service. :-( > bfn, Wouter Curtis From Ray.Bellis@nominet.org.uk Tue Aug 28 02:01: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 81AF711E80FD for ; Tue, 28 Aug 2012 02:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[AWL=-1.252, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etKAyX-kZnNh for ; Tue, 28 Aug 2012 02:01:54 -0700 (PDT) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE2811E80FC for ; Tue, 28 Aug 2012 02:01:54 -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=fKkZ1q20kkONCzDAZy+bCUKfy5/G8oEIdMgDHKbhiMNz3iM4uY6t7H1x hkQqFAzpQXUBS4wGzbnmmtgZ/SXypNt+nRF0H9Bmwv7N3w+BVU9cdZyGV v7TdYrfSmXsBDgo; 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=1346144514; x=1377680514; 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=20minutes|Date:=20Tue,=2028=20Aug=2020 12=2009:01:51=20+0000|Message-ID:=20<509EC0F7-36D7-430E-8 2F7-8E8E4EE379D1@nominet.org.uk>|To:=20"homenet@ietf.org =20Group"=20|MIME-Version:=201.0; bh=TjLW47bf1bjL49qV60HHTeAQw+4raej/B6tTG1nX7pc=; b=GFD25Wuau29C5jrX9PVBVMytvzSLhsaglWHRsaPTk5V9PH+Uz7Z24C2m n7KPjbtWt9u2044dB3n3OoGIQyuxL4gEu68Z3n0Cmf3VHHNgV69Yi/QoS KLHRLwyRx5NmTSK; X-IronPort-AV: E=Sophos;i="4.77,841,1336345200"; d="scan'208,217";a="35082702" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 28 Aug 2012 10:01:53 +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; Tue, 28 Aug 2012 10:01:52 +0100 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: IETF84 minutes Thread-Index: AQHNhPvDfckuwhIL/k6S/qOVg7v9aQ== Date: Tue, 28 Aug 2012 09:01:51 +0000 Message-ID: <509EC0F7-36D7-430E-82F7-8E8E4EE379D1@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_509EC0F736D7430E82F78E8E4EE379D1nominetorguk_" MIME-Version: 1.0 Subject: [homenet] IETF84 minutes 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, 28 Aug 2012 09:01:55 -0000 --_000_509EC0F736D7430E82F78E8E4EE379D1nominetorguk_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft minutes are now online at: with massive thanks to Jiazi Yi & Thomas Clausen for taking those notes, an= d subsequently combining them for us. Please note that there are several places therein where speakers failed to = identify themselves. If you are one of those and can tell us which sections= can be attributed to you, please let me know! Similarly, please let me have any other corrections that may be required. The deadline for both the above is 12th September. thanks, Ray --_000_509EC0F736D7430E82F78E8E4EE379D1nominetorguk_ Content-Type: text/html; charset="us-ascii" Content-ID: <51b88818-317a-4bc5-b6e1-53577d767071> Content-Transfer-Encoding: quoted-printable The draft minutes are now online at:<= div>

with massive thanks to Jiazi Yi & Thomas Clausen for taking= those notes, and subsequently combining them for us.

Please note that there are several places therein wh= ere speakers failed to identify themselves. If you are one of those and ca= n tell us which sections can be attributed to you, please let me know!

= Similarly, please let me have any o= ther corrections that may be required.

The deadline for both the above is 12th September.

thanks,

Ray

= --_000_509EC0F736D7430E82F78E8E4EE379D1nominetorguk_-- From wouter.cloetens@softathome.com Tue Aug 28 16:21: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 C168C21F8421 for ; Tue, 28 Aug 2012 16:21: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVh8POgOS8K8 for ; Tue, 28 Aug 2012 16:21:56 -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 5163121F841E for ; Tue, 28 Aug 2012 16:21:55 -0700 (PDT) Received: from p578bca27.dip0.t-ipconnect.de ([87.139.202.39] helo=[172.22.2.184]) by e2big.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1T6V6W-0007rI-EB; Wed, 29 Aug 2012 01:21:52 +0200 Message-ID: <503D528D.3000504@softathome.com> Date: Wed, 29 Aug 2012 01:21:49 +0200 From: Wouter Cloetens User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6 MIME-Version: 1.0 To: curtis@occnc.com, homenet@ietf.org References: <201208211403.q7LE3TWa039352@gateway2.orleans.occnc.com> In-Reply-To: <201208211403.q7LE3TWa039352@gateway2.orleans.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] naming, what's the problem? 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, 28 Aug 2012 23:21:57 -0000 On 21/08/12 16:03, Curtis Villamizar wrote: > > In message<502FBEB4.40907@softathome.com> > Wouter Cloetens writes: > >> DOn 18/08/12 05:05, Curtis Villamizar wrote: >>>>> When a domain registrar is needed is only when the homenet needs or >>>>> wants (maybe for ego reasons) a domain residing in a TLD (such as .com >>>>> or .org) and would not accept a subdomain from the provider. For >>>>> example the homenet user wants foo.com and would not accept something >>>>> of the form foo.site.provider.com, which would be less permanet (the >>>>> delegation is lost if switching providers). >>>> >>>> For security reasons documented in one of the drafts above, it should be >>>> disabled by default. A user-defined configuration could open the DNS >>>> port to the world, and allow additional domains. >>> >>> I think you missed the point. This is not a security issue. >> >> Yes, I got your point, but I'm adding an implication. >> The draft explains that this requires opening up the gateway's DNS port >> to the world, rather than only to the trusted DNS infrastructure of the >> provider. That has some security issues. > > There is the option for split horzon, but I don't think it should be > the default. Having a GUA and not having a DNS name is not a > *security* feature. More like paranoia IMHO. Security by obscurity > has never worked. Well, there is the issue of discoverability of the addresses in the home. A /64 for your home network is prohibitively expensive to scan by enumerating IP addresses. Scanning a list of hostnames based on a dictionary reduces the space considerably. Personally, I agree that not having a DNS name is indeed security by obscurity. Your IP address can be seen by any server with which you communicate already, so I think the whole discoverability security element will just shift attackers' focus to XSS attacks on web pages. I also think that the advantages of the DNS name outweigh the (IMHO small) security risks. > >> Also, only the provider can give you reverse DNS. > > The provider can delegate reverse DNS. That is a problem with > uncooperative providers. True, and well, that's a matter of making a business case. If the customer is willing to pay for it, or if it creates a competitive advantage, then yes. I suspect that there is just not enough money in it to make it worth their effort. > Otherwise accurate rDNS is site local only, but at least it is > accurate at the site. >> Whereas the provider-delegated domain can be a fully automatic feature, >> setting up a personal domain requires the user to do some work. >> Registering a domain (could be made simple, from a gateway's web UI), >> pointing a nameserver at his gateway (could be automated, DynDNS-style). >> It is only logical that a user should also have to disable the secure >> default source address restriction of DNS requests. > > If the user wants no work, the provider delegated subdomain can be > reduced to zero work on the part of the customer, and a one time > mechanical configuration on the part of the provider at the time that > service is initiated (when new customer buys service for first time). > > Working with a registrar could be made simpler by the registrar, but > most homes will never need a *vanity* domain in a TLD. Exactly. It isn't necessarily a registrar that needs to offer the option though. A DynDNS provider could offer a vanity non-TLD domain, and delegate queries to the gateway. It's even perfect to combine the existing IPv4 service (e.g. foo.homeunix.net from dyn.com) with the new IPv6 delegation (router.foo.homeunix.net, printer.foo.homeunix.net, mylaptop.foo.homeunix.net, ...) >> Nonetheless, it is a perfectly valid use case; the IPv6 functional >> equivalent of widely used DynDNS in the IPv4 world today. And, of >> course, not every operator may implement the automated domain delegation. > > It seems that today, getting operators to do anything is difficult. > Too bad we have so little competition in Internet service. :-( Note the list of authors on the drafts. ;-) I realised that without operator cooperation, nothing is likely to happen, so I was delighted when an operator contacted me, and even more delighted when they showed a working proof of concept implementation, and were willing to co-author the draft. From marka@isc.org Tue Aug 28 17:43: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 8C13521F8460 for ; Tue, 28 Aug 2012 17:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tOPQFNraoKv for ; Tue, 28 Aug 2012 17:43:01 -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 E2B6021F8464 for ; Tue, 28 Aug 2012 17:43:00 -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 9F6395F9920; Wed, 29 Aug 2012 00:42:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:3412:bd6d:96eb:b7ba]) (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 51E23216C6D; Wed, 29 Aug 2012 00:42:46 +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 EA8402448A7C; Wed, 29 Aug 2012 10:42:31 +1000 (EST) To: Wouter Cloetens From: Mark Andrews References: <201208211403.q7LE3TWa039352@gateway2.orleans.occnc.com> <503D528D.3000504@softathome.com> In-reply-to: Your message of "Wed, 29 Aug 2012 01:21:49 +0200." <503D528D.3000504@softathome.com> Date: Wed, 29 Aug 2012 10:42:30 +1000 Message-Id: <20120829004231.EA8402448A7C@drugs.dv.isc.org> Cc: homenet@ietf.org, curtis@occnc.com Subject: Re: [homenet] naming, what's the problem? 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, 29 Aug 2012 00:43:03 -0000 In message <503D528D.3000504@softathome.com>, Wouter Cloetens writes: > On 21/08/12 16:03, Curtis Villamizar wrote: > > > > In message<502FBEB4.40907@softathome.com> > > Wouter Cloetens writes: > > > >> DOn 18/08/12 05:05, Curtis Villamizar wrote: > >>>>> When a domain registrar is needed is only when the homenet needs or > >>>>> wants (maybe for ego reasons) a domain residing in a TLD (such as .com > >>>>> or .org) and would not accept a subdomain from the provider. For > >>>>> example the homenet user wants foo.com and would not accept something > >>>>> of the form foo.site.provider.com, which would be less permanet (the > >>>>> delegation is lost if switching providers). > >>>> > >>>> For security reasons documented in one of the drafts above, it should be > >>>> disabled by default. A user-defined configuration could open the DNS > >>>> port to the world, and allow additional domains. > >>> > >>> I think you missed the point. This is not a security issue. > >> > >> Yes, I got your point, but I'm adding an implication. > >> The draft explains that this requires opening up the gateway's DNS port > >> to the world, rather than only to the trusted DNS infrastructure of the > >> provider. That has some security issues. > > > > There is the option for split horzon, but I don't think it should be > > the default. Having a GUA and not having a DNS name is not a > > *security* feature. More like paranoia IMHO. Security by obscurity > > has never worked. > > Well, there is the issue of discoverability of the addresses in the > home. A /64 for your home network is prohibitively expensive to scan by > enumerating IP addresses. Scanning a list of hostnames based on a > dictionary reduces the space considerably. Personally, I agree that not > having a DNS name is indeed security by obscurity. Your IP address can > be seen by any server with which you communicate already, so I think the > whole discoverability security element will just shift attackers' focus > to XSS attacks on web pages. I also think that the advantages of the DNS > name outweigh the (IMHO small) security risks. It is trivial to scan a /48 if ip6.arpa is populated for it. There is too much structure in ip6.arpa to prevent the scan succeeding. This is independent of whether the zones are signed or not or whether NSEC or NSEC3 is used when signing the zone. You query for [0-9a-z].. For each of these that return NOERROR you scan for [0-9a-z].. Repeat until you have the entire 128 bits for all registered nodes in the /48. > >> Also, only the provider can give you reverse DNS. > > > > The provider can delegate reverse DNS. That is a problem with > > uncooperative providers. > > True, and well, that's a matter of making a business case. If the > customer is willing to pay for it, or if it creates a competitive > advantage, then yes. I suspect that there is just not enough money in it > to make it worth their effort. There are existing DNS servers that make automatic delegation trivial to support. There is deployed code that allows clients to update the delegation of a /48 that was designed to allow 6to4 reverses to be delegated in band using TCP as the authenticator. If the update request comes from the /48 over TCP it is accepted otherwise it is rejected. This code supports any /48. It is trivial to make it support /52, /56, /60 and /64 (20 minutes work). zone "8.B.D.0.1.0.0.2.ip6.arpa" { type master; file "8.B.D.0.1.0.0.2.ip6.arpa"; update-policy { grant dhcpserver subdomain 8.B.D.0.1.0.0.2.ip6.arpa ANY; // cleanup when lease expires grant * 6to4-self . NS DNAME DS; // CPE added these using a TCP }; }; It was designed to be used like this where updates could be done over both IPv4 (constructs the matching 2.0.0.2.IP6.ARPA /48 reverse) and IPv6. Geoff/APNIC went with a HTTP interface rather than a DNS interface. zone "2.0.0.2.IP6.ARPA" { type master; file "2.0.0.2.ip6.arpa"; update-policy { grant * 6to4-self . NS DNAME DS; }; }; Finer grained control is available so you can allow this for subsets of the reverse space. zone "8.B.D.0.1.0.0.2.ip6.arpa" { type master; file "8.B.D.0.1.0.0.2.ip6.arpa"; update-policy { grant local:path external . NS DNAME DS; }; }; > > Otherwise accurate rDNS is site local only, but at least it is > > accurate at the site. > > >> Whereas the provider-delegated domain can be a fully automatic feature, > >> setting up a personal domain requires the user to do some work. > >> Registering a domain (could be made simple, from a gateway's web UI), > >> pointing a nameserver at his gateway (could be automated, DynDNS-style). > >> It is only logical that a user should also have to disable the secure > >> default source address restriction of DNS requests. > > > > If the user wants no work, the provider delegated subdomain can be > > reduced to zero work on the part of the customer, and a one time > > mechanical configuration on the part of the provider at the time that > > service is initiated (when new customer buys service for first time). > > > > Working with a registrar could be made simpler by the registrar, but > > most homes will never need a *vanity* domain in a TLD. > > Exactly. > It isn't necessarily a registrar that needs to offer the option though. > A DynDNS provider could offer a vanity non-TLD domain, and delegate > queries to the gateway. It's even perfect to combine the existing IPv4 > service (e.g. foo.homeunix.net from dyn.com) with the new IPv6 > delegation (router.foo.homeunix.net, printer.foo.homeunix.net, > mylaptop.foo.homeunix.net, ...) > > >> Nonetheless, it is a perfectly valid use case; the IPv6 functional > >> equivalent of widely used DynDNS in the IPv4 world today. And, of > >> course, not every operator may implement the automated domain delegation. > > > > It seems that today, getting operators to do anything is difficult. > > Too bad we have so little competition in Internet service. :-( > > Note the list of authors on the drafts. ;-) I realised that without > operator cooperation, nothing is likely to happen, so I was delighted > when an operator contacted me, and even more delighted when they showed > a working proof of concept implementation, and were willing to co-author > the draft. > _______________________________________________ > 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 jhw@apple.com Tue Aug 28 18:35: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 093E921F8528 for ; Tue, 28 Aug 2012 18:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.555 X-Spam-Level: X-Spam-Status: No, score=-110.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32wAikvPVsGa for ; Tue, 28 Aug 2012 18:35:50 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id A83D621F8526 for ; Tue, 28 Aug 2012 18:35:50 -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 <0M9H00J0HTR7RKH2@mail-out.apple.com> for homenet@ietf.org; Tue, 28 Aug 2012 18:35:50 -0700 (PDT) X-AuditID: 11807130-b7f9b6d000000bad-b7-503d71f6f57c Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 14.EB.02989.6F17D305; Tue, 28 Aug 2012 18:35:50 -0700 (PDT) Received: from [17.193.15.103] by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0M9H003D9TROK260@aniseed.apple.com> for homenet@ietf.org; Tue, 28 Aug 2012 18:35:50 -0700 (PDT) From: james woodyatt In-reply-to: <20120829004231.EA8402448A7C@drugs.dv.isc.org> Date: Tue, 28 Aug 2012 18:35:48 -0700 Message-id: <596BC785-38EA-407C-A8DA-E4E854E64AD4@apple.com> References: <201208211403.q7LE3TWa039352@gateway2.orleans.occnc.com> <503D528D.3000504@softathome.com> <20120829004231.EA8402448A7C@drugs.dv.isc.org> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1486) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUi2FAsrvut0DbA4Pd/AYv3iw6xODB6LFny kymAMYrLJiU1J7MstUjfLoErY1PzLvaC86wVl5cGNDAeZOli5OSQEDCROLDtFiuELSZx4d56 ti5GLg4hgSlMEi9OT2KGcJqZJC4+eMoIUsUsoCWxfudxJhCbV0BP4su+rWDdwgJGEj+7msBq 2ARUJL5dvgtUw8HBKWAtMeFJDUiYRUBVYvuLbnaIMdoST95dYIUYYyPx//ARqF0zGSVu9z0G u05EQF/i6ZFfbBDXyUrsv7+PcQIj/ywkZ8xCcsYsJHMXMDKvYhQsSs1JrDQ01EssKMhJ1UvO z93ECA6xQoMdjGt/8h9iFOBgVOLhPfjXJkCINbGsuDL3EKMEB7OSCO9TU9sAId6UxMqq1KL8 +KLSnNTiQ4zSHCxK4rzyLkApgfTEktTs1NSC1CKYLBMHp1QDo5wO5/35pxJVVzwMW/H4bfjP 93XXpuYt+OPLckS7ZouTc8MSz1dZq/7+Vni1LlSG61ZHxvUVlzaWXzm4K07Fhftoy9Jtsx6/ jdzG0av4YuLPrI7c35X5jnt6AosSNh2SvXW29t4178drJl8vs7COajtewPepXmCJiHSa47ZH ed8+/LY8d/6U9XQlluKMREMt5qLiRADn05EsLQIAAA== Subject: Re: [homenet] naming, what's the problem? 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, 29 Aug 2012 01:35:52 -0000 On Aug 28, 2012, at 17:42 , Mark Andrews wrote: > > Repeat until you have the entire 128 bits for all registered nodes in the /48. You shouldn't expect to get the temporary addresses. Only the persistent ones, and some nodes-- particularly the ones that host only clients and no services-- should neither be listening at persistent addresses, nor advertising pointers to their persistent addresses in ip6.arpa. I'm not terribly exercised about the other kinds of nodes. The problem of globally reachable servers being findable by iterating the ip6.arpa reverse domain name system doesn't seem very pressing to me. Sounds like a feature not an error. --james From marka@isc.org Tue Aug 28 18:50: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 100F821F854F for ; Tue, 28 Aug 2012 18:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.883 X-Spam-Level: X-Spam-Status: No, score=0.883 tagged_above=-999 required=5 tests=[AWL=-2.607, BAYES_05=-1.11, MANGLED_DOMAIN=2.3, MANGLED_GLBLLY=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+Vhk+trUgUM for ; Tue, 28 Aug 2012 18:50:47 -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 6DA3821F852B for ; Tue, 28 Aug 2012 18:50:47 -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 BACDDC9428; Wed, 29 Aug 2012 01:50:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:3412:bd6d:96eb:b7ba]) (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 77DAC216C6F; Wed, 29 Aug 2012 01:50:38 +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 9EF24244918D; Wed, 29 Aug 2012 11:50:22 +1000 (EST) To: james woodyatt From: Mark Andrews References: <201208211403.q7LE3TWa039352@gateway2.orleans.occnc.com> <503D528D.3000504@softathome.com> <20120829004231.EA8402448A7C@drugs.dv.isc.org> <596BC785-38EA-407C-A8DA-E4E854E64AD4@apple.com> In-reply-to: Your message of "Tue, 28 Aug 2012 18:35:48 MST." <596BC785-38EA-407C-A8DA-E4E854E64AD4@apple.com> Date: Wed, 29 Aug 2012 11:50:20 +1000 Message-Id: <20120829015022.9EF24244918D@drugs.dv.isc.org> Cc: "homenet@ietf.org Group" Subject: Re: [homenet] naming, what's the problem? 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, 29 Aug 2012 01:50:48 -0000 In message <596BC785-38EA-407C-A8DA-E4E854E64AD4@apple.com>, james woodyatt wri tes: > On Aug 28, 2012, at 17:42 , Mark Andrews wrote: > > > > Repeat until you have the entire 128 bits for all registered nodes in the / > 48. > > You shouldn't expect to get the temporary addresses. Only the persistent one > s, and some nodes-- particularly the ones that host only clients and no servi > ces-- should neither be listening at persistent addresses, nor advertising po > inters to their persistent addresses in ip6.arpa. This is debatable. There are enough services that require a working reverse for not registering to be a problem. One can always register like this and still maintain anonymity. PTR AAAA > I'm not terribly exercised about the other kinds of nodes. The problem of gl > obally reachable servers being findable by iterating the ip6.arpa reverse dom > ain name system doesn't seem very pressing to me. Sounds like a feature not > an error. I don't think it is a error either. Just a observation that one should be aware of. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ajs@anvilwalrusden.com Tue Aug 28 23:31: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 F152021F84C8 for ; Tue, 28 Aug 2012 23:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QrmtYyyErHC for ; Tue, 28 Aug 2012 23:31:20 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id C3ACF21F84C4 for ; Tue, 28 Aug 2012 23:31:20 -0700 (PDT) Received: from mx1.yitter.info (unknown [205.201.170.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id ADBCF8A031 for ; Wed, 29 Aug 2012 06:31:18 +0000 (UTC) Date: Wed, 29 Aug 2012 02:31:17 -0400 From: Andrew Sullivan To: homenet@ietf.org Message-ID: <20120829063116.GB51970@mx1.yitter.info> References: <201208211403.q7LE3TWa039352@gateway2.orleans.occnc.com> <503D528D.3000504@softathome.com> <20120829004231.EA8402448A7C@drugs.dv.isc.org> <596BC785-38EA-407C-A8DA-E4E854E64AD4@apple.com> <20120829015022.9EF24244918D@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120829015022.9EF24244918D@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [homenet] naming, what's the problem? 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, 29 Aug 2012 06:31:22 -0000 On Wed, Aug 29, 2012 at 11:50:20AM +1000, Mark Andrews wrote: > There are enough services that require a working reverse for not > registering to be a problem. Please name one. When we went through this argument in DNSOP some years ago, we were unable to reach consensus on that claim. I'd be delighted to learn it is true, but I haven't so far found a convincing story. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Wed Aug 29 00:38: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 9ED3F21F84EC for ; Wed, 29 Aug 2012 00:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.483 X-Spam-Level: X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[AWL=0.801, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCqQvHcqvLhB for ; Wed, 29 Aug 2012 00:38:50 -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 8DFC721F84D4 for ; Wed, 29 Aug 2012 00:38:48 -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 77241C951E; Wed, 29 Aug 2012 07:38:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:3412:bd6d:96eb:b7ba]) (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 3F3C4216C6B; Wed, 29 Aug 2012 07:38:40 +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 D03A1244DB4E; Wed, 29 Aug 2012 17:38:06 +1000 (EST) To: Andrew Sullivan From: Mark Andrews References: <201208211403.q7LE3TWa039352@gateway2.orleans.occnc.com> <503D528D.3000504@softathome.com> <20120829004231.EA8402448A7C@drugs.dv.isc.org> <596BC785-38EA-407C-A8DA-E4E854E64AD4@apple.com> <20120829015022.9EF24244918D@drugs.dv.isc.org> <20120829063116.GB51970@mx1.yitter.info> In-reply-to: Your message of "Wed, 29 Aug 2012 02:31:17 -0400." <20120829063116.GB51970@mx1.yitter.info> Date: Wed, 29 Aug 2012 17:38:06 +1000 Message-Id: <20120829073806.D03A1244DB4E@drugs.dv.isc.org> Cc: homenet@ietf.org Subject: Re: [homenet] naming, what's the problem? 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, 29 Aug 2012 07:38:50 -0000 In message <20120829063116.GB51970@mx1.yitter.info>, Andrew Sullivan writes: > On Wed, Aug 29, 2012 at 11:50:20AM +1000, Mark Andrews wrote: > > > There are enough services that require a working reverse for not > > registering to be a problem. > > Please name one. Millions of SMTP servers or are we going to force SMTP MTAs to not use temporary addresses when transmitting mail? I know it is a useless test but it exists. Do you think ISP generate fake IPv4 reverse entries for no reason? There are just enough sites that do this that it is a pain to not provide the entries. > When we went through this argument in DNSOP some > years ago, we were unable to reach consensus on that claim. I'd be > delighted to learn it is true, but I haven't so far found a convincing > story. > > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > 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 swmike@swm.pp.se Wed Aug 29 01:07: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 0BC7621F856C for ; Wed, 29 Aug 2012 01:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2vx6+djF+sU for ; Wed, 29 Aug 2012 01:07:33 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 2872A21F8567 for ; Wed, 29 Aug 2012 01:07:32 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D04BB9C; Wed, 29 Aug 2012 10:07:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C98C89A; Wed, 29 Aug 2012 10:07:30 +0200 (CEST) Date: Wed, 29 Aug 2012 10:07:30 +0200 (CEST) From: Mikael Abrahamsson To: Andrew Sullivan In-Reply-To: <20120829063116.GB51970@mx1.yitter.info> Message-ID: References: <201208211403.q7LE3TWa039352@gateway2.orleans.occnc.com> <503D528D.3000504@softathome.com> <20120829004231.EA8402448A7C@drugs.dv.isc.org> <596BC785-38EA-407C-A8DA-E4E854E64AD4@apple.com> <20120829015022.9EF24244918D@drugs.dv.isc.org> <20120829063116.GB51970@mx1.yitter.info> 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: homenet@ietf.org Subject: Re: [homenet] naming, what's the problem? 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, 29 Aug 2012 08:07:34 -0000 On Wed, 29 Aug 2012, Andrew Sullivan wrote: > On Wed, Aug 29, 2012 at 11:50:20AM +1000, Mark Andrews wrote: > >> There are enough services that require a working reverse for not >> registering to be a problem. > > Please name one. When we went through this argument in DNSOP some > years ago, we were unable to reach consensus on that claim. I'd be > delighted to learn it is true, but I haven't so far found a convincing > story. If the incoming TCP/25 call comes from an IPv4 address with working forward/reverse is used as one of many parameters to rate liklyhood of the email being a spam. I am not saying this is going to work the same in IPv6, but my money would be that serious MTA owners would continue to emulate this, by not running SLAAC on their MTA:s and just having a single static address and giving a proper forward/reverse DNS to this address. -- Mikael Abrahamsson email: swmike@swm.pp.se From sm@resistor.net Wed Aug 29 14:36: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 21D6311E80EA for ; Wed, 29 Aug 2012 14:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.192 X-Spam-Level: X-Spam-Status: No, score=-102.192 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pklHeVEljQP6 for ; Wed, 29 Aug 2012 14:36:14 -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 906AC11E80A5 for ; Wed, 29 Aug 2012 14:36:14 -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 q7TLa8H5008412; Wed, 29 Aug 2012 14:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346276173; bh=OHeLkJ9cGM5hV8qFFoLSCK240Gao3RoV2ZeN20F07rg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ioX8mweclTcJZfDvYtdXss4rBb4LbzruImYfKb5k7zK2rmav6VMnV/UNgLcmHMr52 16IkDQgToOyTEmxvBDcG9agNf/XL6ivSPrCt43wD91+2im2hTCaicMHW8PA857e1J5 nFkolvxeT4pV0XgS3umYuJgsJnr7HmhLZu5q++q0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1346276173; i=@resistor.net; bh=OHeLkJ9cGM5hV8qFFoLSCK240Gao3RoV2ZeN20F07rg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=XplddIH8vAaEDjzZ3ZfMTY+e4ALNzy7jUxtDG7hAzVnkQvO1v1wtLVoF65gTTubIo r9mOjZKEn8saxOVGgMpcMjW8AMiqaBoh3bC0W0lllDrdEZ3XNVP49vNLt09JwsMHCV atoLHwOUvOPUmht+oJ/cQCM21z56ezew4M2fj1cU= Message-Id: <6.2.5.6.2.20120829142221.08f03790@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Aug 2012 14:31:58 -0700 To: Mikael Abrahamsson From: SM In-Reply-To: References: <201208211403.q7LE3TWa039352@gateway2.orleans.occnc.com> <503D528D.3000504@softathome.com> <20120829004231.EA8402448A7C@drugs.dv.isc.org> <596BC785-38EA-407C-A8DA-E4E854E64AD4@apple.com> <20120829015022.9EF24244918D@drugs.dv.isc.org> <20120829063116.GB51970@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: homenet@ietf.org Subject: Re: [homenet] naming, what's the problem? 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, 29 Aug 2012 21:36:15 -0000 At 01:07 29-08-2012, Mikael Abrahamsson wrote: >I am not saying this is going to work the same in IPv6, but my money >would be that serious MTA owners would continue to emulate this, by >not running SLAAC on their MTA:s and just having a single static >address and giving a proper forward/reverse DNS to this address. It's easier not to run SLAAC on the MTA. Regards, -sm From richard.mortier@gmail.com Fri Aug 31 23:36: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 5087211E80BF for ; Fri, 31 Aug 2012 23:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYhJUuZLnl-L for ; Fri, 31 Aug 2012 23:36:14 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAD311E80A3 for ; Fri, 31 Aug 2012 23:36:14 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so4592248vcb.31 for ; Fri, 31 Aug 2012 23:36:13 -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=hEIUc9ktHG/e5Ct4SltejgtD1NOUVYBKr2ZYk1dTv70=; b=U0CY5XJQHWRUKhQHxgEXx8zofLcTCTk1m/lKFzazvFjEJXPMXC6/cvb+f3ZTsyGQH1 +nayX5sq2OFhdnV5W1e9mGox1ZJTlBAtqsxE6L5eQpiwekMasYEAy/p1hjnaFJy8VBWG uhZ+JXktJM1M2FVaHxrNOFKOo1PBNnd2sSvgL3PSVdcbayY6ZTP7gyKVndyVRIZK5gxQ 7O+98eHi5Mj+whZzp7JUhJdMbWpYcN+S70A0ai3fmceerhrj8l5aCXXQlhUWB0lmxNeU Cyr4QqqlRvTinq06fKvSS1KSybi5PeVeNnzBAEeyxQvTim4HNsmOiSfxevXIRqRsqluq D+Sw== MIME-Version: 1.0 Received: by 10.220.157.1 with SMTP id z1mr7239582vcw.12.1346481373517; Fri, 31 Aug 2012 23:36:13 -0700 (PDT) Sender: richard.mortier@gmail.com Received: by 10.58.79.74 with HTTP; Fri, 31 Aug 2012 23:36:13 -0700 (PDT) In-Reply-To: <201208151830.q7FIUkrP033557@gateway.ipv6.occnc.com> References: <201208151830.q7FIUkrP033557@gateway.ipv6.occnc.com> Date: Sat, 1 Sep 2012 07:36:13 +0100 X-Google-Sender-Auth: oj7A90KDsQBRSBDLyMXDhngY2UA Message-ID: From: Richard Mortier To: curtis@occnc.com Content-Type: text/plain; charset=ISO-8859-1 Cc: Michael Richardson , homenet@ietf.org Subject: Re: [homenet] Tunnels to 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: Sat, 01 Sep 2012 06:36:15 -0000 (apologies for the delay replying, have been catching up after a trip away.) On 15 August 2012 19:30, Curtis Villamizar wrote: > > In message > Richard Mortier writes: > >> On 13 August 2012 20:04, Michael Richardson wrote: >> > >> ... >> > which would permit you to validate who I am, even though neither of >> > have connectivity at the time.. I would cache my DNSSEC path, and of >> > course, we each would already have the root DNSSEC key. (no different >> > than how PKIX works...) >> > >> > I see signposts as being additional local trust anchors that can be >> > used. >> >> yes, i think we would too :) > > You did trim out the example, where due to the trust, whitehouse.gov > and billthecat.whitehouse.gov are all DNSSEC signed domains. I > suppose that is why the smiley. the smiley is because (as anil's reply said), signpost uses dnssec precisely to get that trust. a smiley of agreement if you will. >> specifically: in the "common case" we'd envisage that each person >> would have at least one publicly visible signpost, probably hosted in >> the cloud (whether or not operated directly by them, or through some >> "signpost-as-a-service" provider) unless they have suitable local >> resources. > > ... and the difference between signed untrustworthy source of > information and an unsigned untrustworthy is ... what? not sure what you mean here - could you expand? > This is putting yet another service in the cloud that need not be > there, though global DNS could be considered "in the cloud" as > commonly practiced for the home user. > > What we are trying to accomplish is getting a local name service that > is somehow authoritative for the local site, and optionally can be > made global. > > Putting the mapping to the local printer in the cloud would break > printing if the cloud were not accessible (hopefully temporarily) but > for some devices, like home alarms, utility metering, the fridge, > ... the kitchen sink, with low power wireless, the cloud might often > not be there. we view both the local and global (ie., visible to the public, probably hosted in the cloud in most cases) as part of the same federated service. the local service (eg., at home) will continue to work if you are disconnected. the global service provides for access to the "local" services from outside that physical network. -- Richard Mortier mort@cantab.net